Cloud Beratung – Wir schaffen die erfolgreiche Transformation.

Sicherheit in der Cloud ist keine Zusatzfunktion, die sich nachträglich einbauen lässt. Sie muss von Beginn an Teil der Architektur sein. Diesen Grundsatz verfolgt der Cloud Security by Design Ansatz. Sicherheitsmechanismen werden bereits in der Planungsphase berücksichtigt und in jede Schicht der Infrastruktur integriert. So schützen Unternehmen ihre Cloud-Infrastruktur zuverlässig vor bekannten Bedrohungen und schaffen die Grundlage für künftige Anforderungen. Wir erklären in diesem Artikel die Hintergründe des Security by Design Ansatzes, gehen auf Umsetzungsmöglichkeiten ein und geben Tipps für den sicheren Aufbau der Cloud-Infrastruktur.

Was bedeutet der Cloud Security by Design Ansatz?

Cloud Security by Design steht für den Grundsatz, Sicherheit von Beginn an als zentralen Bestandteil der Cloud-Architektur zu verstehen, statt das Thema wie ein Add-on zu behandeln. Statt Sicherheitsmaßnahmen reaktiv nach Vorfällen einzuführen, werden Schutzmechanismen von Anfang an in Design-Entscheidungen eingebettet. Konkret können das verschiedene Mechanismen sein:

• Auswahl sicherer Services
• Definition von Zugriffsrechten
• Verschlüsselung von Daten
• Kontinuierliche Überwachung der Infrastruktur

Ziel ist es, Schwachstellen zu minimieren, die Reaktionszeiten bei Angriffen zu verkürzen und sicherzustellen, dass Compliance-Anforderungen automatisch erfüllt werden. Wichtig ist auch, dass Entwicklungsteams, Platform Engineers und Sicherheitsexperten eng zusammenarbeiten, um gemeinsam eine sichere und resiliente Cloud-Umgebung zu schaffen.

Wie kann Cloud Security by Design umgesetzt werden?

Für eine erfolgreiche Umsetzung von Cloud Security by Design braucht es eine Kombination aus technischen Maßnahmen, organisatorischen Prozessen und kulturellem Wandel. Unternehmen können in der Entwicklung ihrer Cloud-Infrastruktur verschiedene Maßnahmen implementieren.

Zero-Trust-Ansatz
Das Prinzip „Never trust, always verify“ gilt als Fundament moderner Cloud-Sicherheit. Anders als traditionelle Netzwerkmodelle, die innerhalb des eigenen Netzwerks Vertrauen voraussetzen, behandelt Zero Trust jede Anfrage, unabhängig von ihrer Herkunft, als potenziell gefährlich. Jeder Zugriff wird einzeln validiert, Nutzer und Geräte werden kontinuierlich überprüft und Zugriffsrechte werden auf das absolute Minimum beschränkt. Dieser Ansatz verhindert laterale Bewegungen von Angreifern innerhalb der Infrastruktur und minimiert so den Schaden im Falle einer Kompromittierung.

Identity & Access Management (IAM)
Die richtige Verwaltung von Identitäten und Zugriffsrechten ist unumgänglich für den Aufbau einer sicheren Cloud-Umgebung. IAM-Systeme stellen sicher, dass nur autorisierte Personen und Services auf bestimmte Ressourcen zugreifen können. Durch rollenbasierte Zugriffskontrollen erhalten Nutzer genau die Berechtigungen, die sie für ihre Aufgaben benötigen. Multi-Faktor-Authentifizierung fügt eine zusätzliche Sicherheitsebene hinzu, zudem reduzieren zeitlich begrenzte Zugriffstoken das Risiko kompromittierter Zugänge.

Automatisierte Sicherheitsprüfungen
Manuelle Sicherheitsüberprüfungen sind fehleranfällig und können mit der Geschwindigkeit moderner Cloud-Deployments kaum Schritt halten. Automatisierte Sicherheitstests sollten daher fester Bestandteil jeder CI/CD-Pipeline sein. Tools scannen Code auf Schwachstellen, überprüfen Konfigurationen auf Fehleinstellungen und identifizieren unsichere Abhängigkeiten noch vor dem Deployment. Regelmäßige Penetrationstests und Schwachstellenscans ergänzen diese kontinuierlichen Prüfungen und stellen sicher, dass auch produktive Systeme laufend auf Sicherheitslücken untersucht werden.

Compliance-Anforderungen
Regulatorische Vorgaben wie die DSGVO oder ISO 27001 setzen klare Standards für den Umgang mit Daten und Sicherheitsprozessen. Cloud Security by Design berücksichtigt diese Anforderungen bereits in der Architekturphase, sodass Compliance nicht nachträglich zum Problem wird. Dazu gehören Mechanismen zur Datenverschlüsselung, Protokollierung von Zugriffen, Löschkonzepte und Dokumentation von Sicherheitsmaßnahmen. Durch die Integration dieser Anforderungen von Beginn an vermeiden Unternehmen teure Nachbesserungen und potenzielle Strafen.

CSPM (Cloud Security Posture Management)
CSPM-Tools überwachen die Cloud-Umgebung kontinuierlich auf Fehlkonfigurationen, Compliance-Verstöße und Sicherheitsrisiken. Sie erkennen beispielsweise öffentlich zugängliche Speicher-Buckets, übermäßig permissive Firewalls oder veraltete Verschlüsselungsstandards. Durch automatisierte Warnungen und Empfehlungen helfen CSPM-Lösungen IT-Teams dabei, den Sicherheitsstatus der Cloud-Infrastruktur hoch zu halten und Schwachstellen zu schließen, bevor sie ausgenutzt werden können.

3 Tipps für sicheres Cloud Platform Engineering

Neben den grundlegenden Sicherheitskonzepten gibt es noch einige konkrete Maßnahmen, die IT-Teams im Aufbau ihrer Cloud-Infrastruktur umsetzen können, um ihre Umgebung abzusichern.

• Verschlüsselung überall implementieren: Daten sollten sowohl im Ruhezustand als auch während der Übertragung verschlüsselt sein. Moderne Cloud-Plattformen arbeiten mit nativen Verschlüsselungsmechanismen, die sich mit wenig Aufwand aktivieren lassen. Besonders wichtig ist das Management der Verschlüsselungsschlüssel: Sie sollten getrennt von den Daten gespeichert und regelmäßig rotiert werden. Durch sichere Verschlüsselung schützen Unternehmen sich sowohl vor externen Angreifern als auch vor internen Risiken.
• Least Privilege Prinzip konsequent anwenden: Jeder Nutzer, jede Anwendung und jeder Service sollte soweit möglich nur die minimalen Berechtigungen erhalten, die für die jeweilige Aufgabe notwendig sind. Übermäßige Rechte gelten als eine der häufigsten Ursachen für erfolgreiche Angriffe. Durch regelmäßige Überprüfungen der vergebenen Berechtigungen stellt die IT sicher, dass keine ungenutzten oder veralteten Zugriffsrechte bestehen bleiben. Automatisierte Tools können dabei helfen, diese Reviews effizient durchzuführen.
• Logging und Monitoring als Frühwarnsystem nutzen: Umfassendes Logging aller Aktivitäten in der Cloud-Umgebung schafft Transparenz und ermöglicht die Nachverfolgung von Sicherheitsvorfällen. Kombiniert mit intelligenten Monitoring- und Alerting-Systemen kann die IT verdächtige Aktivitäten in Echtzeit erkennen. Ergänzend können SIEM-Lösungen dabei helfen, aus der großen Anzahl an Logdaten relevante Sicherheitsereignisse herauszufiltern und schnelle Reaktionen zu ermöglichen.

Fazit: Cloud Security by Design als Grundlage für jede Entwicklung

Arbeiten Unternehmen im Aufbau ihrer Cloud-Infrastruktur nach dem Security by Design Ansatz, folgen sie damit einer heute notwendigen Grundhaltung. Indem sie Sicherheit von Anfang an in Planung und Umsetzung integrieren, minimieren sie Risiken, erfüllen Compliance-Anforderungen und sparen langfristig Kosten. Eine Kombination aus automatisierten Sicherheitsprüfungen, IAM und kontinuierlichem Monitoring legt ein sicheres Fundament. Wichtig ist, dass Unternehmen Sicherheit zum zentralen Bestandteil jeder Cloud-Lösung machen, statt sie als nachträglichen Gedanken zu vernachlässigen.

Die Cloud-Infrastruktur bildet die Grundlage einer modernen Unternehmens-IT. Wer sorgt aber eigentlich dafür, dass Anwendungen zuverlässig laufen, schnell skalieren und rund um die Uhr verfügbar sind? Hinter jeder erfolgreichen Cloud-Lösung steht ein komplexes Zusammenspiel verschiedener Fachbereiche. Platform Engineers, Site Reliability Engineers und DevOps Engineers arbeiten zusammen, um stabile, effiziente und zukunftssichere Infrastrukturen aufzubauen. Wir gehen in diesem Artikel auf die einzelnen Bereiche und ihre spezifischen Aufgaben ein. Außerdem zeigen wir, wie sie gemeinsam zur erfolgreichen Entwicklung einer Cloud-Infrastruktur beitragen und im Anschluss ihren Betrieb sicherstellen und optimieren.

Was ist Teil einer Cloud-Infrastruktur?

Eine Cloud-Infrastruktur besteht aus weit mehr als nur Servern in einem Rechenzentrum. Sie umfasst virtuelle Maschinen, Container, Speicherlösungen, Netzwerkkomponenten und Datenbanken, die flexibel über das Internet bereitgestellt werden. Hinzu kommen Orchestrierungstools, die den Betrieb automatisieren, Monitoring-Systeme für die Überwachung und Sicherheitsmechanismen zum Schutz der Daten. All diese Komponenten müssen nahtlos zusammenarbeiten und sich dynamisch an wechselnde Anforderungen anpassen können.

Komplexität entsteht einerseits natürlich durch die Technik selbst, andererseits aber auch durch die Verwaltung, Aktualisierung und Optimierung der einzelnen Elemente. Moderne Cloud-Infrastrukturen stellen Automatisierung, Skalierbarkeit und hohe Verfügbarkeit in den Mittelpunkt. Um diese Eigenschaften zu erreichen, braucht es spezialisierte Fachkräfte und durchdachte Prozesse.

Wer arbeitet an der Entwicklung der Cloud-Infrastruktur und wie überschneiden sich die Bereiche?

Die Entwicklung einer Cloud-Infrastruktur ist Teamarbeit und wird besonders von drei zentralen Rollen gesteuert: Platform Engineers schaffen die technische Grundlage, Site Reliability Engineers sorgen für Stabilität und Performance und DevOps Engineers ermöglichen reibungslose Entwicklungs- und Deployment-Prozesse. Jeder Bereich bringt zwar spezifisches Know-how mit, die Grenzen verschwimmen aber immer stärker. Wichtig ist vor allem, dass alle Bereiche ineinandergreifen, damit eine Infrastruktur entsteht, die innovativ und zeitgleich zuverlässig ist.

Platform Engineering

Platform Engineers legen das Fundament für die gesamte Cloud-Infrastruktur. Sie entwickeln und pflegen die Plattformen, auf denen Anwendungen betrieben werden und schaffen damit die technische Basis für alle anderen Teams.

• Skalierung: Platform Engineers implementieren Mechanismen, die es ermöglichen, Ressourcen automatisch an die aktuelle Last anzupassen und Lastspitzen problemlos zu bewältigen.
• Cloud-Infrastruktur: Sie definieren und verwalten die grundlegende Architektur in der Cloud, von Netzwerken über Storage bis hin zu Compute-Ressourcen.
• Application Lifecycle Management: Die Verwaltung des gesamten Lebenszyklus aller Anwendungen, von der Entwicklung über den Betrieb bis zur Ablösung, liegt in ihrem Verantwortungsbereich.
• Containerisierung: Platform Engineers setzen Container-Technologien ein, um Anwendungen portabel, konsistent und ressourceneffizient zu betreiben.
• Service Orchestrierung: Sie koordinieren verschiedene Services und sorgen dafür, dass sie automatisiert zusammenspielen und effizient verwaltet werden können.

SRE

Site Reliability Engineers (SRE) verbinden Software Engineering mit Systemadministration. Ihr Fokus liegt auf der Zuverlässigkeit und Performance der Infrastruktur. Sie stellen sicher, dass Systeme laufen, wenn sie gebraucht werden.

• Monitoring: SREs implementieren umfassende Überwachungssysteme, die den Zustand der Infrastruktur dauerhaft im Blick behalten und frühzeitig auf Anomalien hinweisen.
• Zuverlässigkeit: Sie entwickeln Strategien und technische Lösungen, um Ausfallzeiten zu minimieren und die Stabilität der Systeme zu verbessern.
• Verfügbarkeit: Sie sorgen dafür, dass Services rund um die Uhr erreichbar sind. Dafür kommen Redundanzen und Failover-Mechanismen zum Einsatz.
• Incident Response: Bei Störungen reagieren SREs schnell und strukturiert, analysieren die Ursachen und implementieren Maßnahmen, die ähnliche Vorfälle zukünftig vermeiden.
• Service Level Objectives: Sie definieren messbare Ziele für die Servicequalität und stellen sicher, dass sie kontinuierlich eingehalten und überwacht werden.

DevOps Engineering

DevOps Engineers bilden die Schnittstelle zwischen Entwicklung und Betrieb der Cloud-Infrastruktur. Sie schaffen die Prozesse und Tools, die es Teams ermöglichen, Software schneller und sicherer auszuliefern.

• Kollaboration: DevOps Engineers fördern die Zusammenarbeit zwischen Entwicklungs- und Operations-Teams und brechen mit Hierarchien und festgefahrenen Strukturen.
• Automatisierung: Sie automatisieren wiederkehrende Aufgaben im Entwicklungs- und Deployment-Prozess, um Fehler zu reduzieren und die Geschwindigkeit zu erhöhen.
• Deployment: Die Verantwortung für eine reibungslose und zuverlässige Bereitstellung von Software in verschiedenen Umgebungen liegt beim DevOps Team.
• CI & CD: DevOps Engineers implementieren CI/CD Pipelines, die automatisierte Tests und Auslieferungen ermöglichen und so die Time-to-Market verkürzen.

Welche Schnittmengen haben die verschiedenen Bereiche und wie wirken sie zusammen?

Die drei Bereiche ergänzen sich in verschiedenen Situationen.

Platform Engineers und DevOps Engineers teilen die Verantwortung für Cloud-Infrastruktur-Management und Deployment-Automatisierung: Platform Engineers stellen die grundlegende Plattform bereit, DevOps Engineers nutzen sie für effiziente Auslieferungsprozesse.

DevOps Engineers und SREs arbeiten eng bei kontinuierlicher Verbesserung, Monitoring und Alerting zusammen: DevOps-Prozesse liefern die Basis für schnelle Iterationen, SREs sorgen dafür, dass dabei die Stabilität nicht leidet.

Platform Engineers und SREs wiederum legen gemeinsam den Fokus auf Performance-Optimierung und Kapazitätsplanung: Sie stellen sicher, dass die Infrastruktur funktioniert und effizient dimensioniert ist.

Im Idealfall entsteht so ein Kreislauf: Platform Engineers schaffen die technische Grundlage, DevOps Engineers ermöglichen schnelle Deployments, und SREs gewährleisten, dass alles zuverlässig läuft. Feedback aus dem Betrieb fließt zurück in die Plattform-Entwicklung, sodass sich die Infrastruktur kontinuierlich verbessert.

Fazit: Zusammenspiel zwischen allen Bereichen als Basis für eine funktionale Cloud-Infrastruktur

Eine effiziente Cloud-Infrastruktur entsteht durch das koordinierte Zusammenwirken mehrerer Spezialisten. Platform Engineers, SREs und DevOps Engineers bringen jeweils eigene Perspektiven und Fähigkeiten ein, die sich gegenseitig ergänzen und verstärken. Die Rollen setzen zwar unterschiedliche Schwerpunkte, verfolgen aber alle ein Ziel: eine stabile, skalierbare und zukunftssichere Cloud-Infrastruktur. Unternehmen können durch dieses Zusammenspiel von kürzeren Entwicklungszyklen und höherer Systemzuverlässigkeit profitieren und sind zeitgleich fähig, schnell auf Marktveränderungen zu reagieren.

Viele Unternehmen nutzen heute die Cloud, doch zwischen „Cloud nutzen“ und „Cloud richtig nutzen“ können Welten liegen. Während einige ihre Cloud-Infrastruktur als strategischen Vorteil einsetzen, kämpfen andere mit ineffizienten Systemen, steigenden Kosten und starren Strukturen. Der Unterschied liegt unter anderem in der Architektur: Wer von Anfang an auf eine durchdachte Cloud-Architektur setzt, schafft die Grundlage für Skalierbarkeit, Sicherheit und Effizienz. In diesem Artikel zeigen wir, was für den Aufbau einer Cloud-Architektur wichtig ist und wie die verschiedenen Ebenen zusammenwirken.

4 Ebenen für den erfolgreichen Aufbau einer Cloud-Architektur

Eine zukunftssichere Cloud-Architektur entsteht durch bewusste Entscheidungen auf verschiedenen Ebenen. Von der grundlegenden Cloud-Strategie über die Anwendungsstruktur bis hin zur Automatisierung und Betriebsstabilität. Jede Ebene baut auf der vorherigen auf und trägt zum Gesamterfolg bei. Die folgenden vier Dimensionen bilden das Fundament einer leistungsfähigen Cloud-Plattform, die mit Ihrem Unternehmen wachsen kann.

Multi-Cloud vs. Single-Cloud: die strategische Grundentscheidung

Eine der ersten Fragen beim Aufbau einer Cloud-Architektur lautet: Setzen wir auf einen einzigen Cloud-Anbieter oder verteilen wir unsere Workloads auf mehrere? Beide Ansätze haben eigene Vor- und Nachteile.

• Der Single-Cloud-Ansatz konzentriert sich auf einen Anbieter wie AWS, Azure oder Google Cloud. Der Vorteil liegt in einer tiefen Integration, in einfacherem Management und oft simplerer Kostenoptimierung durch gebündelte Verträge. Teams müssen nur eine Plattform verstehen und die Services sind optimal aufeinander abgestimmt. Nachteil ist einer der Gründe für die hohe Nachfrage nach souveränen Cloud-Lösungen: Es kann eine Abhängigkeit vom gewählten Anbieter entstehen, der sogenannte Vendor Lock-In.
• Eine Multi-Cloud hingegen kombiniert mehrere Anbieter und nutzt die Stärken jedes einzelnen. Unternehmen können für jeden Workload den passenden Service wählen und sind flexibler bei Verhandlungen. Allerdings steigt damit die Komplexität: Mehrere Plattformen bedeuten höhere Anforderungen an Know-how, Monitoring, Basisbetriebskosten und Kostenmanagement.

Die richtige Wahl hängt von Ihren Anforderungen ab: Unternehmen mit hohen Compliance-Anforderungen oder dem Wunsch nach Souveränität tendieren zu Multi-Cloud-Ansätzen. Wer Effizienz und schnelle Markteinführung priorisiert, fährt mit einem Single-Cloud-Ansatz oft besser. Wichtig ist: Die Entscheidung sollte strategisch getroffen werden, nicht zufällig oder nach dem Bauchgefühl.

Modularität & Microservices: Flexibilität durch Entkopplung

Moderne Cloud-Architekturen setzen auf Modularität statt auf monolithische Anwendungen. Das Microservices-Prinzip zerlegt komplexe Anwendungen in kleinere, eigenständige Services, die unabhängig voneinander entwickelt, deployed und skaliert werden können.

Die Vorteile liegen auf der Hand: Teams können parallel arbeiten, einzelne Komponenten lassen sich gezielt skalieren und Technologiewechsel betreffen nur Teilbereiche statt des gesamten Systems. Wenn beispielsweise der Payment-Service mehr Last erfährt als der Rest der Anwendung, skaliert nur dieser und nicht die gesamte Infrastruktur.

Allerdings bringt diese Flexibilität auch Herausforderungen mit sich. Microservices erfordern kleinteilige Orchestrierung, durchdachtes API-Design und robustes Monitoring. Microservices erfordern eine sichere und kostenbewusste Konfiguration aller Services und ihrer Interaktionen. Container-Technologien wie Kubernetes oder Cloud Foundry helfen dabei, diese Komplexität zu meistern. Für Cloud Platform Engineering sind Microservices ideal, weil sie genau die Selbstverwaltung und Autonomie ermöglichen, die Teams brauchen.

Infrastructure as Code: die Grundlage für Automatisierung

Infrastructure as Code (IaC) ist das Fundament jeder modernen Cloud-Architektur. Statt Server und Netzwerke manuell zu konfigurieren, wird die gesamte Infrastruktur in Code beschrieben. Dadurch wird sie versioniert, testbar und reproduzierbar. Darüber hinaus ermöglicht IaC alle Vorteile etablierter Softwareentwicklungs-Workflows. Änderungen können vor dem Merge geprüft, dokumentiert und freigegeben werden, Konfigurationen automatisiert getestet werden, und fehlerhafte oder unsichere Setups lassen sich erkennen, bevor sie in produktive Umgebungen ausgerollt werden.

Tools wie Terraform, Pulumi, Azure Bicep oder AWS CloudFormation ermöglichen es, Infrastruktur wie Software zu behandeln. Die Vorteile dahinter sind groß:

• Entwicklungsumgebungen lassen sich auf Knopfdruck erstellen.
• Änderungen werden nachvollziehbar dokumentiert.
• Fehler werden durch automatisierte Tests früh erkannt.
• Die Zusammenarbeit im Team wird erleichtert, weil alle Mitarbeitenden auf denselben Code-Stand zugreifen.

In Kombination mit GitOps entsteht ein besonders leistungsfähiger Ansatz: Infrastruktur-Änderungen werden ausschließlich über Git-Workflows gesteuert und von CI/CD-Pipelines automatisiert ausgerollt. Das beschleunigt Prozesse und erhöht die Sicherheit, da manuelle Eingriffe auf ein Minimum reduziert werden.

Skalierbarkeit und Ausfallsicherheit: Resilienz von Anfang an

Ein zukunftssicherer Aufbau einer Cloud-Architektur muss zwei zentrale Anforderungen erfüllen: Er muss mit wachsenden Anforderungen skalieren und gleichzeitig hochverfügbar bleiben.

• Skalierbarkeit bedeutet, dass Ressourcen automatisch angepasst werden: nach oben bei steigender Last und nach unten bei geringerer Nutzung. Durch Auto-Scaling-Mechanismen und Load Balancer können Unternehmen sicherstellen, dass Anwendungen auch bei Lastspitzen funktionieren. Da bei geringerer Nachfrage wieder nach unten skaliert werden kann, braucht es keine dauerhaft überdimensionierte Infrastruktur.
• Ausfallsicherheit erfordert Redundanz der entsprechenden Systeme. Mit Multi-Availability-Zone-Deployments können Unternehmen sicherstellen, dass der Ausfall eines Rechenzentrums nicht dazu führt, dass das vollständige System ausfällt. Neben der Hochverfügbarkeit sind dafür auch regelmäßige Backups, definierte Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) relevant. Durch moderne Ansätze wie Chaos Engineering können Teams die Resilienz proaktiv testen, indem sie Ausfälle kontrolliert simulieren.

Wichtig ist aber: Hochverfügbarkeit hat ihren Preis. Unternehmen müssen abwägen, welche Systeme kritisch sind und welches Ausfallrisiko akzeptabel ist. Nicht jede Anwendung braucht eine >99,99%-Verfügbarkeit.

Das Zusammenspiel beim Aufbau einer Cloud-Architektur: Architekturprinzipien für erfolgreiches Cloud Platform Engineering

Erst das Zusammenspiel aller Elemente stellt den erfolgreichen Aufbau einer Cloud-Architektur dar. Eine durchdachte Cloud-Architektur kombiniert die richtige Cloud-Strategie mit modularem Design, automatisierter Infrastruktur und eingebauter Resilienz. Unterstützen können dabei spezielle Frameworks wie das AWS, Google oder Azure Well-Architected Framework sowie Cloud Adoption Frameworks. Diese definieren Best Practices für Sicherheit, Kostenoptimierung, Betrieb und Performance. Durch den Security by Design Ansatz sorgen sie zudem dafür, dass Sicherheit von Beginn an berücksichtigt und integriert wird.

Weiterhin wichtig ist FinOps für eine kontinuierliche Kostenoptimierung. Cloud-Ressourcen sind zwar flexibel, können aber ohne Kontrolle schnell zu Kostenexplosionen führen. Monitoring, Tagging und regelmäßige Reviews sind dazu da, ein gutes Verhältnis zwischen Performance und Wirtschaftlichkeit zu schaffen.

Fazit: Der Aufbau der Cloud-Architektur als Produkt

Im Cloud Platform Engineering geht es vor allem darum, die Cloud-Infrastruktur als Produkt zu verstehen. Sie ist eine Plattform, die kontinuierlich an die Bedürfnisse der Nutzer angepasst wird. Die optimale Cloud-Architektur gibt es deshalb nicht als Standardlösung. Jedes Unternehmen muss basierend auf seinen Anforderungen, Ressourcen und Zielen die individuell richtigen Entscheidungen treffen. Ob Single- oder Multi-Cloud, Microservices oder modulare Monolithen, umfassende Redundanz oder akzeptables Risiko, die Architektur muss zur Organisation passen.

Wichtig ist, ein Verständnis für die grundlegenden Prinzipien zu schaffen. Infrastructure as Code ermöglicht Automatisierung, Flexibilität entsteht durch Modularität und durchdachte Skalierbarkeit und Ausfallsicherheit bringen Resilienz. Durch die Berücksichtigung dieser Elemente können Unternehmen eine zukunftssichere Cloud-Architektur schaffen, die mit dem Unternehmen wächst.

Viele Unternehmen nutzen heute Cloud-Dienste. Oft bedeutet das aber nur, Server bei Amazon, Microsoft oder Google zu mieten, statt im eigenen Rechenzentrum zu betreiben. Cloud Platform Engineering geht einen entscheidenden Schritt weiter: Es verwandelt diese gemieteten Ressourcen in eine maßgeschneiderte, selbstverwaltete Arbeitsumgebung für Teams. In diesem Artikel erklären wir, was genau dahintersteckt, wie Cloud Platform Engineering Teams aussehen und für welche Unternehmen sich dieser Ansatz lohnt.

Was ist Cloud Platform Engineering und gibt es überhaupt Unterschiede zu einfachem Cloud Hosting?

Bei Cloud Platform Engineering geht es um den systematischen Aufbau und die Verwaltung von Cloud-Infrastrukturen als wiederverwendbare, selbstverwaltete Plattformen. Konkret bedeutet das: Viele Unternehmen setzen Cloud-Dienste einzeln und unabhängig voneinander ein, sodass jeder User sich mit allen Bestandteilen auseinandersetzen, sie verstehen und zusammenbauen muss. Cloud Platform Engineering funktioniert wie eine Art Bausatz-System und verwandelt die komplexen Einzelteile in standardisierte, einfach nutzbare Werkzeuge, die jeder im Team sofort verwenden kann. So wird die Cloud-Infrastruktur als Produkt behandelt, das kontinuierlich verbessert und an die Bedürfnisse der internen Nutzer angepasst wird.

Der Unterschied zur reinen Cloud-Administration ist dabei grundlegend. Cloud-Admins kümmern sich darum, dass Server laufen, Updates installiert werden und alles funktioniert. Cloud Platform Engineering hingegen gestaltet eine komplette Arbeitsumgebung, in der Teams selbstständig agieren können. Dabei verfolgt Platform Engineering drei zentrale Ziele:

• Skalierbarkeit bedeutet, dass die IT-Infrastruktur mit den Anforderungen des Unternehmens mitwachsen kann. Cloud Platform Engineering ermöglicht genau das. Durch den Einsatz von Infrastructure as Code (IaC) und Container-Orchestrierung können Ressourcen automatisch hoch- oder herunterskaliert werden, ohne dass Mitarbeitende manuell eingreifen müssen.
• Automatisierung reduziert wiederkehrende Aufgaben. CI/CD-Pipelines, automatisierte Tests und Self-Service-Portale ermöglichen es beispielsweise Entwicklern, Anwendungen schneller zu deployen. Tests laufen also von selbst, Sicherheitsüberprüfungen erfolgen automatisch und Anwendungen gehen mit deutlich weniger menschlichem Zutun live. Das spart Zeit und verhindert zeitgleich Fehler und entlastet die Operations-Teams.
• Sicherheit ist von Anfang an eingebaut. Jede neue Anwendung erhält automatisch die richtigen Sicherheitseinstellungen, Passwörter werden sicher verwahrt und Zugriffe werden kontrolliert. Nach diesem „Security-by-Design“-Ansatz werden Compliance-Anforderungen automatisch erfüllt.

Wer setzt Cloud Platform Engineering um? Rollen & Verantwortlichkeiten im Unternehmen

Damit Cloud Platform Engineering funktioniert, braucht es klar definierte Aufgaben und Verantwortlichkeiten. Ein Platform Engineering Team besteht dabei aus verschiedenen Rollen:

• Platform Engineers sind die Architekten der internen Entwicklerplattform. Sie designen, implementieren und warten die Tools und Services, die Mitarbeitende von Developern über AI Engineers bis zu Data Scientists nutzen. Ihre Aufgabe ist es, komplizierte Cloud-Technologien so zu verpacken, dass Teams sie einfach nutzen können. Sie etablieren Best Practices gemeinsam mit Cloud-Architekten und arbeiten auf Grundlage der Frage „Wie können wir andere Teams bestmöglich regelkonform enablen?“
• DevOps-Engineers sorgen dafür, dass der Weg von der Programmierung bis zur fertigen Anwendung reibungslos läuft. Sie automatisieren Deployment-Prozesse und optimieren CI/CD-Pipelines. Damit sind sie die Brücke zwischen der Plattform und den Anwendungen, die darauf laufen.
• Product Owner definieren die Roadmap der Plattform basierend auf den Bedürfnissen der internen Nutzer. Sie entscheiden, welche Funktionen die Plattform als Nächstes bekommt, sammeln Feedback von den Usern und priorisieren, was den größten Nutzen bringt.
• Entwicklerteams profitieren als eine der zentralen Nutzergruppe von der Plattform. Sie können sich auf das konzentrieren, was sie am besten können: Software entwickeln. Sie müssen nicht mehr verstehen, wie Server konfiguriert werden oder welche Sicherheitsregeln gelten. Durch Self-Service-Funktionen gewinnen sie Autonomie ohne die Notwendigkeit, tiefgreifende Cloud-Expertise aufzubauen.
• Weitere Nutzergruppen wie beispielsweise Data Scientists oder AI Engineers nutzen die Cloud Platform für die Aufbereitung von Daten für Unternehmensentscheidungen, die IT-Abteilung für das Deployment von Servern für interne Apps. Die Anwendungsbereiche sind weit gefasst und von Unternehmen zu Unternehmen unterschiedlich.

Die Verantwortlichkeiten sind jedoch klar getrennt: Das Platform Team stellt die Infrastruktur bereit, DevOps optimiert Prozesse und Teams nutzen die Plattform für verschiedene Zwecke. Diese klare Aufgabenteilung schafft Effizienz und ermöglicht es jedem Team, sich auf seine Kernkompetenzen zu konzentrieren. Grundsätzlich geht es darum, eine funktionale Plattform für alle Nutzergruppen zu schaffen: Das kann beispielsweise ein lockeres Zusammenklicken von Services in einer Sandbox-Umgebung sein, aber auch das Enablement von Teams zum compliance-gerechten Deployment eines Workloads.

Für wen lohnt sich Cloud Platform Engineering?

Cloud Platform Engineering ist kein Muss für jedes Unternehmen. Die Investition in eine umfassende Platform-Strategie lohnt sich vor allem unter bestimmten Kriterien:

Mehrere Nutzergruppen in einem Unternehmen

Unternehmen mit mehreren potenziellen Nutzergruppen profitieren am meisten. Wenn zehn oder mehr Mitarbeitende regelmäßig Cloud-Ressourcen nutzen, zahlt sich die Investition schnell aus. So bastelt nicht mehr jedes Team einzelne Lösungen, sondern alle nutzen dieselbe optimierte Plattform. Die Standardisierung reduziert Reibungsverluste und beschleunigt die Entwicklung über alle Teams hinweg.

Compliance im Mittelpunkt

Organisationen mit hohen Compliance-Anforderungen wie Banken, Versicherungen oder das Gesundheitswesen finden in Platform Engineering einen Verbündeten. Sie müssen nachweisen, dass ihre Systeme bestimmte Sicherheitsstandards erfüllen. Eine gut aufgebaute Plattform stellt automatisch sicher, dass jede Anwendung diese Anforderungen erfüllt, ohne dass Nutzer an unzählige Details denken müssen.

Wachstumsorientierung

Skalierungsorientierte Unternehmen, die schnelles Wachstum erwarten oder erleben, benötigen flexible Infrastrukturen. Wer in kurzer Zeit deutlich mehr Kunden erwartet, kann nicht auf manuelle Prozesse setzen. Cloud Platform Engineering ermöglicht es, neue Märkte schnell zu erschließen und Lastspitzen problemlos zu bewältigen.

Zu Beginn der Cloud-Migration

Unternehmen, die eine Cloud-Migration planen, sollten Platform Engineering von Beginn an berücksichtigen. Statt verschiedene Cloud-Services einzeln zu nutzen, schafft eine durchdachte Plattform-Strategie von Anfang an Struktur und vermeidet späteren Refactoring-Aufwand.

Weniger geeignet ist der Ansatz für sehr kleine Teams, Start-ups in frühen Phasen mit begrenzten Ressourcen oder Projekte mit einfachen Anforderungen, die sich kaum ändern. Hier ist der Aufwand oft größer als der Nutzen.

Fazit: Effizienz, Skalierbarkeit und Sicherheit durch Cloud Platform Engineering

Cloud Platform Engineering geht weit über traditionelles Cloud Hosting hinaus und entwickelt sich zur wichtigen Grundlage für moderne Cloud-Infrastrukturen in Unternehmen. Statt einfach nur Server zu mieten, schaffen Unternehmen eine maßgeschneiderte Arbeitsumgebung, die Teams in der Anwendung das Leben erleichtert und gleichzeitig Sicherheit, Skalierbarkeit und Effizienz garantiert. Die verschiedenen Rollen arbeiten dabei Hand in Hand: Platform Engineers bauen die Grundlage, DevOps optimiert die Prozesse und Endnutzer können sich auf ihre jeweiligen Stärken konzentrieren. Für Unternehmen mit mehreren Nutzergruppen, hohen Sicherheitsanforderungen oder Wachstumsambitionen ist Cloud Platform Engineering eine strategische Investition, die sich langfristig auszahlt und den entscheidenden Wettbewerbsvorteil bringen kann.

Die Europäische Union stellt die Cloud-Souveränität immer weiter in den Mittelpunkt: In aktuellen Ausschreibungen kommt erstmals ein umfassendes Cloud Sovereignty Framework zum Einsatz, das digitale Souveränität einerseits definiert und sie andererseits messbar macht. Unternehmen können dieses Framework damit als praktischen Leitfaden für ihre eigene Cloud-Strategie einsetzen. Denn die Frage nach Kontrolle, Unabhängigkeit und Rechtssicherheit in der Cloud betrifft längst nicht mehr nur öffentliche Organisationen, sondern alle Unternehmen, die kritische Daten und Workloads in die Cloud verlagern. Erfahren Sie in diesem Artikel, was das Cloud Sovereignty Framework beinhaltet und wie Sie es in der Praxis einsetzen können.

Die 8 Dimensionen des Cloud Sovereignty Frameworks

Das von der EU-Kommission entwickelte Cloud Sovereignty Framework basiert auf acht klar definierten Souveränitätszielen. Sie decken verschiedene Aspekte digitaler Unabhängigkeit ab und schaffen so einen ganzheitlichen Rahmen:

• Strategische Souveränität bewertet, inwiefern ein Cloud-Anbieter im europäischen Rechts-, Finanz- und Industrieumfeld verankert ist und ob er EU-Prioritäten unterstützt.
• Rechtliche und jurisdiktionelle Souveränität prüft die Abhängigkeit gegenüber außereuropäischen Rechtssystemen wie dem US CLOUD Act oder chinesischen Cybersecurity-Gesetzen.
• Daten- und KI-Souveränität stellt sicher, dass Unternehmen die Kontrolle über ihre Daten behalten und dass KI-Modelle unter EU-Kontrolle entwickelt werden.
• Operative Souveränität fokussiert sich auf die praktische Fähigkeit europäischer Unternehmen, Technologie unabhängig zu betreiben, zu warten und weiterzuentwickeln, inklusive der Verfügbarkeit von EU-basiertem Know-how und Support.
• Die Supply Chain Souveränität adressiert die geografische Herkunft kritischer Komponenten, von Hardware-Fertigung über Firmware bis zu Software-Updates.
• Technologische Souveränität bewertet Offenheit, Interoperabilität und die Vermeidung vom Vendor Lock-in.
• Sicherheits- und Compliance-Souveränität stellt sicher, dass Security Operations und Audit-Rechte unter EU-Jurisdiktion bleiben.
• Ökologische Nachhaltigkeit berücksichtigt langfristige Resilienz in Bezug auf Energieabhängigkeit und Ressourcenknappheit.

Das Cloud Sovereignty Framework als Bewertungssystem: SEAL-Level und Scoring

Einer der wichtigsten Faktoren des Cloud Sovereignty Frameworks ist die Möglichkeit zur praktischen Anwendung als Bewertungsinstrument in Unternehmen. Die EU nutzt ein zweistufiges Bewertungssystem, das Mindestanforderungen definiert und Differenzierung ermöglicht. Darauf können sich auch Unternehmen in ihrer eigenen Bewertung rund um die souveräne Cloud stützen.

Eine fünfstufige Skala (SEAL-Level: Sovereignty Effectiveness Assurance Levels) von SEAL-0 bis SEAL-4 definiert den Grad der Souveränität.

• SEAL-0 bedeutet keine Souveränität: Der Service ist unter exklusiver Kontrolle von Nicht-EU-Providern.
• SEAL-1 beschreibt rein jurisdiktionelle Souveränität, bei der EU-Recht formal gilt, aber kaum durchsetzbar ist.
• Ab SEAL-2 greift Datensouveränität mit durchsetzbarem EU-Recht, es verbleiben jedoch Abhängigkeiten.
• SEAL-3 steht für digitale Resilienz mit starkem, aber nicht vollständigem EU-Einfluss.
• SEAL-4 beschreibt vollständige digitale Souveränität ohne kritische Nicht-EU-Abhängigkeiten.

Ergänzend zum SEAL-Level berechnet die EU einen gewichteten Sovereignty Score. Die Gewichtung ist strategisch durchdacht: Operative Souveränität und Supply Chain Souveränität erhalten jeweils 20 %, da sie die praktische Unabhängigkeit und Resilienz am stärksten beeinflussen. Strategische und Technologie-Souveränität werden mit je 15 % gewichtet. Daten- und KI-, Rechts- und Sicherheitssouveränität erhalten je 10 %, da diese Bereiche bereits durch andere Regularien wie DSGVO, NIS2 oder DORA abgesichert sind. Nachhaltigkeit fließt mit 5 % ein.

Die anschließende Bewertung erfolgt durch offene und geschlossene Fragen an Cloud-Anbieter und wird ergänzt durch Nachweise und öffentliche Dokumentation. Gibt es Schwächen in einzelnen Bereichen, wird der Provider im Gesamtlevel heruntergestuft. Durch diesen Ansatz stellt die EU sicher, dass die Gesamtbewertung nicht durch gute Werte in einzelnen Bereichen beeinflusst werden kann.

Das Cloud Sovereignty Framework in der Praxis für Unternehmen

Das Cloud Sovereignty Framework ist nicht nur für EU-Ausschreibungen relevant. Vielmehr können auch Unternehmen es als Grundlage für ihre eigene Cloud-Souveränitätsstrategie nutzen. Möglichkeiten zur Anpassung gibt es verschiedene:

• Definieren Sie zunächst, welche Souveränitätsdimensionen für Ihr Unternehmen kritisch sind. Firmen in der Finanzbranche werden beispielsweise rechtliche und Datensouveränität höher gewichten, Industrieunternehmen wiederum stellen eher operative und Supply Chain Souveränität in den Mittelpunkt.
• Für die Bewertung Ihrer Cloud-Anbieter können Sie das SEAL-Level-System übernehmen und Anforderungen für jede Dimension festlegen. Kritische Workloads erfordern möglicherweise SEAL-3 oder höher, während für unkritische Systeme SEAL-2 ausreicht.
• Im Sovereignty Score können Sie die Gewichtung an Ihre Unternehmensanforderungen anpassen. Stark regulierte Unternehmen können beispielsweise Sicherheits- und Compliance-Souveränität höher gewichten, andere Unternehmen wiederum die Nachhaltigkeit.

Einerseits kann dieser Ansatz Unternehmen dabei helfen, die passenden Cloud Provider auszuwählen, andererseits kann auch die ganze Cloud-Strategie daran ausgerichtet werden. Das Cloud Sovereignty Framework schafft in jedem Fall einen sachlichen Rahmen, der Kriterien messbar und mit den individuellen Geschäftsanforderungen verknüpfbar macht.

Fazit: Das Cloud Sovereignty Framework als möglicher Zukunftsstandard

Sowohl im öffentlichen Sektor als auch in der freien Wirtschaft hat das Cloud Sovereignty Framework die Chance, zum neutralen Standard für die Bewertung souveräner Cloud-Lösungen zu werden. Die Kombination aus acht klar definierten Dimensionen, einem abgestuften Bewertungssystem und einer transparenten Scoring-Methode schafft einen objektiven und vergleichbaren Rahmen für ein bisher oft individuell und subjektiv diskutiertes Thema. Unternehmen können das Framework als strategischen Leitfaden für ihre eigene Cloud-Strategie einsetzen und die einzelnen Kriterien an individuelle Bedürfnisse anpassen. Statt auf schwammige Souveränitätsversprechen zu vertrauen, können CIOs und IT-Verantwortliche jetzt konkrete Anforderungen definieren und ihren Fortschritt nachvollziehbar bewerten.

Das Thema digitale Souveränität gewinnt immer mehr an Bedeutung. Unternehmen und öffentliche Einrichtungen haben die wichtige Aufgabe, die Vorteile der Cloud-Nutzung mit strengen Anforderungen an Datenschutz, Compliance und nationale Sicherheit zusammenzubringen. Microsoft bietet mit der Microsoft Sovereign Cloud eine Lösung für diese Herausforderungen, die speziell auf Unternehmen mit höchsten Anforderungen an Datensouveränität und -sicherheit fokussiert ist. Wie diese Lösung aussieht und wozu Microsoft sich mit der Sovereign Cloud verpflichtet, erklären wir in diesem Artikel.

Was bietet Microsoft mit der Sovereign Cloud an?

Microsoft definiert digitale Souveränität als die Befähigung von Einzelpersonen und Institutionen, sicher, unabhängig und mit selbstbestimmten Kontrollen an der digitalen Wirtschaft teilzunehmen. Das Unternehmen berücksichtigt dabei auch, dass die Anforderungen abhängig vom Land, der Branche und Organisation stark unterschiedlich aussehen können. Ihre Sovereign Cloud basiert grundsätzlich auf drei Säulen:

Operative Souveränität

Mit operativer Souveränität ist gemeint, dass Kunden die Kontrolle über den Betrieb und die Compliance-Mechanismen ihrer Cloud-Umgebung haben. Sie können selbst festlegen, wer Zugriff auf Systeme und Daten hat und haben die Kontrolle über Wartungs- und Betriebsprozesse.

Datensouveränität

Microsoft stellt mit verschiedenen Mechanismen sicher, dass Kundendaten in definierten geografischen Regionen verbleiben und den lokalen Datenschutzgesetzen entsprechen. Kunden können durch benutzerdefinierte Richtlinien kontrollieren, wo ihre Ressourcen verwendet und gespeichert werden. Sowohl im Ruhezustand als auch während der Übertragung werden die Daten verschlüsselt, während der Verarbeitung können Unternehmen Azure Confidential Computing für die Verschlüsselung nutzen.

KI-Souveränität

Auch KI-Souveränität wird inzwischen immer wichtiger. Sie bezieht sich auf die Nutzung von KI-Systemen, die ethisch, transparent und verantwortlich sind. Microsoft integriert Souveränitätsprinzipien in seine KI-Dienste, um Kunden die Kontrolle über ihre KI-Modelle und die dabei verarbeiteten Daten zu geben.

Die Ziele der Microsoft Sovereign Cloud

Was möchte Microsoft mit der Sovereign Cloud überhaupt erreichen? Vor allem geht es darum, die Cloud an die wachsenden Anforderungen an Datensicherheit und Compliance anzupassen und auf die geopolitischen Entwicklungen zu reagieren, um den globalen Handel weiter zu unterstützen. Es gibt daher 3 große Ziele der Microsoft Sovereign Cloud:

• Kontrolle & Innovation maximieren: Kunden sollen die volle Kontrolle über ihre Cloud-Umgebung erhalten, ohne dabei auf Innovation verzichten zu müssen. Umgesetzt wird das durch integrierte Richtlinien für Systeme, die gängige Compliance-Frameworks erfüllen und durch den Zugriff auf Innovationen der Microsoft Cloud.
• Zugang schützen und von globaler Sicherheit profitieren: Die Sovereign Cloud ermöglicht starke Zugriffskontrollen und Schutzmaßnahmen. Ebenso sollen Kunden von den Sicherheitsinvestitionen von Microsoft selbst profitieren: Microsoft hat eines der größten Cybersicherheitsteams weltweit aufgebaut.
• Kosten für Public und Private Cloud managen: Die hybride und adaptive Cloud-Architektur von Microsoft unterstützt Multi-Cloud-Szenarien, gehostete Optionen von Partnern und den Betrieb von On Premises Lösungen. So sollen Unternehmen die richtige Balance zwischen Public und Private Cloud finden und Investitionen entsprechend ihrer spezifischen Anforderungen optimieren können.

Welche Produkte gibt es in der Microsoft Sovereign Cloud?

Microsoft bietet drei verschiedene Produkte an, die sich in ihren Souveränitätslevels unterscheiden und deshalb sowohl für Unternehmen in der freien Wirtschaft als auch für regulierte Unternehmen und öffentliche Einrichtungen geeignet sind.

Sovereign Public Cloud

Die Sovereign Public Cloud richtet sich an europäische Kunden, die die volle Leistungsfähigkeit der Microsoft Cloud nutzen möchten, aber dennoch nach einer souveränen Lösung suchen. Sie umfasst mehrere Funktionen:

• Datenspeicherung in Europa unter europäischem Recht
• Kontrolle von Betrieb und Zugriff durch in Europa ansässige Mitarbeiter
• Souveräne Kontrollen für Policy-Durchsetzung, sodass Kunden detaillierte Richtlinien definieren und durchsetzen können
• Keine Migration erforderlich, da die Features automatisch auf alle bestehenden europäischen Rechenzentren angewendet werden

Sovereign Private Cloud

Die Sovereign Private Cloud kombiniert Azure Local mit Microsoft 365 Local und bietet eine integrierte Cloud- und Produktivitätslösung für Umgebungen, die hybride oder vollständig isolierte Infrastrukturen benötigen. Diese Lösung ist besonders relevant für:

• Organisationen mit strengen Datenschutzanforderungen
• Umgebungen mit Anforderungen an niedrige Latenz
• Umgebungen, die Geschäftskontinuität auch bei Netzwerkunterbrechungen erfordern
• Behörden und kritische Infrastruktur mit höchsten Sicherheitsanforderungen

Sowohl Azure als auch Microsoft 365 Services können in diesem Modell in einer privaten, souveränen Cloud betrieben werden, sowohl vor Ort, in Partner-Rechenzentren oder einfach im eigenen Land. Zusätzlich gibt es Virtualisierungsdienste und ein validiertes Partner-Ökosystem, auf das Unternehmen zurückgreifen können. So bietet die Sovereign Private Cloud maximale Kontrolle und Isolation, gewährleistet aber auch eine konsistente Entwicklungs- und Betriebserfahrung mit den öffentlichen Cloud-Diensten von Microsoft.

National Partner Clouds

Für Regierungen und Betreiber kritischer Infrastrukturen, die noch strengere Anforderungen haben, bietet Microsoft die National Partner Clouds an. Diese Clouds werden von staatlich genehmigten lokalen Betreibern geführt, die vollständig unabhängig von Microsoft sind.

• Delos Cloud (Deutschland): In Deutschland arbeitet Microsoft mit der SAP Tochtergesellschaft Delos Cloud zusammen. Delos Cloud betreibt eine souveräne Cloud für den deutschen öffentlichen Sektor, die die Anforderungen der deutschen Regierung an Cloud-Plattformen erfüllt.
• Bleu (Frankreich): In Frankreich hat Microsoft eine Vereinbarung mit Bleu getroffen, einem Joint Venture zwischen Orange und Capgemini. Bleu betreibt eine „Cloud de Confiance“ für den französischen öffentlichen Sektor und Betreiber kritischer Infrastrukturen.

Diese National Partner Clouds ermöglichen Zugriff auf die üblichen Funktionen von Microsoft 365 und Microsoft Azure, werden aber in einer unabhängigen Umgebung mit lokaler Eigentümerschaft und isolierter Infrastruktur betrieben. Sie kombinieren also die Technologie von Microsoft mit lokaler Kontrolle und Governance, die für hochsensible Anwendungsfälle benötigt wird.

Für wen eignet sich die Microsoft Sovereign Cloud?

Besonders relevant sind souveräne Cloud-Angebote für den öffentlichen Sektor und Unternehmen in der kritischen Infrastruktur wie im Gesundheitswesen oder im Finanzbereich. Dennoch steigt auch in anderen Unternehmen das Interesse an souveränen Lösungen immer weiter, insbesondere durch geopolitische Entwicklungen und mögliche Risiken für Datenzugriffe aus den USA, begründet durch den Cloud Act. Dass Microsoft souveräne Produkte anbietet, sorgt einerseits für Sicherheit für europäische Unternehmen, andererseits aber auch für Kundenbindung von Seiten Microsofts. Um die Strategie nachhaltig zu festigen, hat Microsoft einige Digital Commitments erarbeitet, die die Richtung vorgeben und das Fundament der Sovereign Cloud Strategie bilden:

1. Aufbau eines breiten KI- und Cloud-Ökosystems in Europa: Microsoft investiert massiv in europäische Infrastruktur, Partnerschaften und Kompetenzen.
2. Wahrung der digitalen Resilienz Europas auch bei geopolitischer Volatilität: Microsoft verpflichtet sich, die Verfügbarkeit und Zuverlässigkeit seiner Dienste in Europa auch in unsicheren geopolitischen Zeiten zu gewährleisten.
3. Schutz der Privatsphäre europäischer Daten: Der Datenschutz bleibt eine Priorität, unterstützt durch technische und organisatorische Maßnahmen wie die EU Data Boundary und den Data Guardian.
4. Kontinuierlicher Schutz und Verteidigung der Cybersicherheit Europas: Microsoft nutzt seine globalen Sicherheitsressourcen, um europäische Kunden vor Cyberbedrohungen zu schützen.
5. Stärkung der wirtschaftlichen Wettbewerbsfähigkeit Europas, einschließlich Open Source: Microsoft unterstützt die europäische Wirtschaft durch Investitionen, Partnerschaften und die Förderung von Open-Source-Initiativen.

Diese Verpflichtungen werden durch einen separaten europäischen Beirat überwacht, der die Einhaltung und kontinuierliche Weiterentwicklung sicherstellt.

Wichtig ist allerdings auch: Auch mit souveränen Cloud-Angeboten bleibt Microsoft der Mutterkonzern. Unternehmen, die vollständig unabhängig von US-Unternehmen agieren möchten, können stattdessen auf deutsche oder EU-Lösungen zurückgreifen, beispielsweise auf STACKIT. Dabei ist auch der Cloud-Anbieter in der EU beheimatet und unterliegt den entsprechenden Regulatorien unabhängig von weltweiten Entwicklungen.

Fazit: Souveränität im Mittelpunkt der Microsoft Cloud

Die Microsoft Sovereign Cloud bietet mit drei Modellen mehrere Lösungen für verschiedene Anforderungsprofile. Klare Stärke liegt in der Kombination aus technischer Kontrolle, organisatorischen Maßnahmen und vertraglichen Verpflichtungen. Services wiederum können wie gewohnt genutzt werden. Souveränität gilt demnach nicht als Kompromiss gegenüber Innovation: Kunden sollen weiter von kontinuierlichen Innovationen profitieren, gleichzeitig aber Kontrolle über ihre Daten behalten. Vor allem der öffentliche Sektor, aber auch immer mehr Unternehmen in der freien Wirtschaft zeigen Interesse an souveränen Cloud-Lösungen und können so weiterhin in gewohnter Microsoft-Umgebung arbeiten.

Unternehmen, die das FinOps Framework in ihren Arbeitsalltag integrieren, möchten damit die Kosten für die Nutzung von Cloud und Technologie verstehen und optimieren. Die einzelnen Fähigkeiten aus den vier FinOps Domänen helfen dabei, die Kosten zu kontrollieren, Transparenz zu schaffen und den Geschäftswert zu maximieren. Worum es bei den einzelnen Fähigkeiten geht und wie Unternehmen sie im Arbeitsalltag einsetzen können, erklären wir mit diesem Artikel.

Alle FinOps Fähigkeiten im Überblick

Einsortiert in ihre zugehörigen FinOps Domänen haben wir die verschiedenen FinOps Fähigkeiten zusammengefasst und erklären, wie sie eingesetzt werden können.

Quelle: FinOps Framework der FinOps Foundation, adaptiert an das Rewion Corporate Design

Cloud-Nutzung und Kosten verstehen

• Datenerfassung: Durch die Sammlung, Aufbereitung und Bereitstellung von Cloud-Daten können Teams fundierte Analysen durchführen. Diese Analysen wiederum schaffen die Datengrundlage für alle weiteren FinOps Fähigkeiten und Entscheidungsprozesse.
• Kostenzuordnung: Mit Tags, Labels und Accounts können Teams Cloud-Kosten transparent und übersichtlich zuordnen. Sie erhalten so die Verantwortung für ihre Ausgaben und fördern Kostenkontrolle und Fairness im Unternehmen.
• Berichte & Analysen: Aufbereitete Daten können über Dashboards zur Verfügung gestellt werden. So schaffen sie Transparenz, identifizieren Kostentreiber und unterstützen gezielte Entscheidungen zur Optimierung der Cloud-Ausgaben.
• Erkennung & Verwaltung von Anomalien: Diese Fähigkeit ermöglicht Teams die frühzeitige Erkennung und Meldung von Kostenabweichungen. Das Unternehmen kann dadurch schnell reagieren, die Ursachen abklären und weitere finanzielle Schäden oder die Verschwendung von Ressourcen vermeiden.

Quantifizierung des Geschäftswerts

• Planung & Schätzung: Teams rechnen unterschiedliche Szenarien durch, bevor neue Anwendungen in Betrieb genommen werden. Das hilft dabei, fundierte Entscheidungen über die Cloud-Kosten und ihren Wert für das Unternehmen treffen zu können.
• Prognosen: Mithilfe historischer Daten, Informationen zu geplanten Änderungen und neuen Modellen werden die zukünftigen Cloud-Kosten vorhergesagt. Teams können dadurch vorausschauend handeln und finanziell besser planen.
• Budgetierung: Mit einem strukturierten Prozess können Teams finanzielle Grenzen für ihre Cloud-Ausgaben festlegen. Durch regelmäßiges Monitoring stellen sie sicher, dass Investitionen planbar bleiben und den Geschäftszielen entsprechen.
• Benchmarking: Um sich ein Bild von der eigenen Cloud-Effizienz und möglichen Potenzialen für Verbesserungen zu machen, können Unternehmen Kennzahlen sowohl intern zwischen Teams als auch extern mit anderen Unternehmen vergleichen.
• Analyse wirtschaftlicher Einheiten: Welche Cloud-Kosten sind welchem Produkt, Service oder Prozess zugeordnet und wie effizient sind sie im Verhältnis zum Geschäftswert? Mit dieser Fähigkeit können Teams diese Fragen beantworten.

Cloud-Nutzung und Kosten optimieren

• Cloud-Architekturgestaltung: Neben Anforderungen an die Leistung der Cloud-Architektur berücksichtigen Teams auch Kosten und Nachhaltigkeit. Ziel ist es, die Architektur effizient, wirtschaftlich und in Einklang mit FinOps Zielen zu gestalten.
• Workload-Optimierung: Cloud-Ressourcen werden auf die tatsächliche Nutzung abgestimmt, um die Buchung zu vieler Kapazitäten zu vermeiden und sicherzustellen, dass die eingesetzten Lösungen wirtschaftlich und wirksam sind.
• Lizenzierung & SaaS-Management: Softwarelizenzen und SaaS-Lösungen sollten effizient eingesetzt werden. Eine regelmäßige Überprüfung bestehender Verträge sorgt dafür, dass Kosten und Verträge möglicherweise optimiert werden können.
• Ratenoptimierung: Durch die Nutzung von Rabatten, Reserved Instances oder entsprechenden Verträgen können Unternehmen die Kosten für ihre Ressourcen senken, ohne Einbußen bei Performance oder Flexibilität hinzunehmen.
• Cloud-Nachhaltigkeit: Indem Nachhaltigkeit in die Cloud integriert wird, können Unternehmen eine verantwortungsvolle IT-Infrastruktur aufbauen. In der Cloud-Nutzung können sie die ökologischen Auswirkungen berücksichtigen und technische Entscheidungen in Hinblick auf die Nachhaltigkeitsziele des Unternehmens treffen.

Orchestrieren der FinOps Praxis

• FinOps Praxisbetrieb: Bei dieser Fähigkeit geht es um die organisatorische und praktische Umsetzung von FinOps, inklusive aller Rollen, Prozesse und Kommunikation. Nur so kann FinOps im Unternehmen nachhaltig integriert werden und seine Wirkung zeigen.
• FinOps Fortbildung: Mit einem gemeinsamen Verständnis von FinOps Konzepten stärken Teams ihre Zusammenarbeit innerhalb verschiedener Bereiche wie Technik, Finanzen und Management. Durch Schulungen und Trainings entsteht unternehmensweite FinOps Kompetenz und der Kulturwandel kann angestoßen werden.
• Cloud Policy & Governance: Mit verbindlichen Vorgaben für die Cloud-Nutzung stellen Unternehmen sicher, dass sie gesetzliche Anforderungen erfüllen, die Unternehmensziele unterstützen und Ressourcen effizient einsetzen.
• Rechnungen & Rückbuchungen: Sowohl Rechnungen als auch mögliche Erstattungen sollten analysiert, strukturiert verarbeitet und zugeordnet werden. Damit entsteht eine klare Verbindung zwischen den Cloud-Ausgaben und der internen Verantwortung der einzelnen Teams.
• Evaluierung des Reifegrads: Durch regelmäßige Bewertungen der FinOps Praxis können Teams ihre Reifegrade, Lücken und Optimierungspotenziale erkennen. So können sie ihre FinOps Praktiken weiterentwickeln und an die Unternehmensziele anpassen.
• Workload-Onboarding: Die strukturierte Einführung neuer Workloads in die Cloud sichert Transparenz über Kosten und Nutzung. Gleichzeitig stellt diese Fähigkeit sicher, dass Systeme effizient und zielgerichtet in Betrieb gehen.
• FinOps Tools & Services: Mit spezialisierten Tools und Services können Teams Daten analysieren, Prozesse automatisieren und ihre Erkenntnisse in konkrete Maßnahmen umsetzen.
• Überschneidende Disziplinen: FinOps lebt von der Abstimmung mit anderen Abteilungen wie Controlling, Einkauf oder IT. Durch gemeinsame Prozesse und Projekte können Teams die Effizienz fördern und einheitliche Ziele definieren.

3 Tipps, wie Unternehmen die nötigen FinOps Fähigkeiten wählen können

Bei FinOps geht es nicht darum, alle Fähigkeiten bis zum maximalen Reifegrad zu entwickeln. Vielmehr haben Unternehmen die Aufgabe, die Fähigkeiten zu wählen, die die jeweiligen Teams benötigen. Dabei können einige Tipps helfen.

An der Reife der FinOps Praxis orientieren
Zuerst ist es sinnvoll den aktuellen Fortschritt von FinOps im Unternehmen zu bewerten. Wird FinOps gerade erst implementiert, sind vor allem grundlegende Fähigkeiten wie Kostenzuordnung, Datenerfassung und die Erstellung erster Dashboards sinnvoll. Wer bereits fortgeschritten ist, profitiert eher von Forecasting, Benchmarking oder Ratenoptimierung. Grundsätzlich ist es sinnvoll, die passenden Fähigkeiten systematisch in jedem Team aufzubauen, statt alles gleichzeitig umzusetzen.

Geschäftliche Ziele in den Mittelpunkt stellen
Wichtigste Grundlage für die Wahl der FinOps Fähigkeiten schaffen immer die strategischen Ziele des Unternehmens. Wächst ein Unternehmen beispielsweise schnell und möchte die Cloud-Kosten unter Kontrolle halten, sind Forecasting und Budgetierung zentrale Fähigkeiten. Steht Nachhaltigkeit im Mittelpunkt, sind Cloud-Nachhaltigkeit und die Architekturgestaltung entsprechend wichtig. FinOps Fähigkeiten haben immer dann den größten Nutzen, wenn sie eine konkrete Herausforderung im geschäftlichen Bereich adressieren.

Mit Stakeholdern aus allen Bereichen abstimmen
Der Erfolg von FinOps basiert stark auf der Zusammenarbeit zwischen IT, Finanzen und Business. Wichtig ist also, dass die relevanten Stakeholder in die Auswahl der Fähigkeiten einbezogen werden. Durch ihre unterschiedlichen Perspektiven kann eine ausgewogene Priorisierung entstehen. Ziel ist ein breit aufgestellter Plan, der technische Effizienz ebenso wie die wirtschaftliche Steuerbarkeit berücksichtigt und gleichzeitig für interne Akzeptanz sorgt.

Fazit: Mit individuellen Fähigkeiten zur erfolgreichen FinOps Praxis

Die erfolgreiche Umsetzung von FinOps im Unternehmen basiert nicht einfach auf der Aneinanderreihung und Weiterentwicklung einzelner Fähigkeiten. Vielmehr haben Unternehmen die Aufgabe, die Fähigkeiten zu finden, die den größten Beitrag zu den aktuellen Herausforderungen und Zielen leisten können. Durch ein systematisches Vorgehen, das Einbinden von Stakeholdern und die Berücksichtigung der Reife der eigenen FinOps Praxis können Unternehmen FinOps nachhaltig und erfolgreich in ihren Alltag integrieren.

Kurzüberblick zum Object-Storage-Dienst in STACKIT

Der STACKIT Object Storage ist ein skalierbarer, verteilter Objektspeicher für Backups, Medien, Logs und beliebige Blob-Daten. Er ist auf hohe Verfügbarkeit und Kostenoptimierung ausgelegt und lässt sich in bestehende Anwendungen integrieren, ohne dass deren Grundarchitektur angepasst werden muss.

Für Betreiber und Entwickler bedeutet das: stabile Speicherung großer Datenmengen bei freier Wahl der Werkzeuge zur Verwaltung und Nutzung.

Der Dienst ist S3-kompatibel und speichert Daten automatisch zonenredundant in europäischen Rechenzentren, was ein Plus für Verfügbarkeit und Datenhoheit ist. Zudem punktet STACKIT mit transparenten Kosten: Für den Ingress und Egress von Daten innerhalb der STACKIT Cloud fallen keine Netzwerkkosten an. Alle gespeicherten Daten und Daten im Transit sind standardmäßig mit AES-256 verschlüsselt.

Was „S3-API-Kompatibilität“ praktisch bedeutet

„S3-kompatibel“ heißt, dass API-Schnittstelle, Authentifizierungsmechanismen und die grundlegenden Operationen (Put/Get/List/Delete, Multipart Uploads, Presigned URLs etc.) dem De-facto-Standard von Amazon S3 folgen.

Das ermöglicht Ihnen, bewährte Tools und SDKs direkt einzusetzen. Achten Sie jedoch auf Details, wie:

• Path-Style vs. Virtual-Host-Style

• Signatur-Versionen (v2/v4)

• mögliche Feature-Unterschiede

Diese Feinheiten testen Sie am besten in einem kurzen Proof-of-Concept.

In 3 einfachen Schritten zum managed Object Store in STACKIT:

1. Dienst aktivieren:
   

2. Bucket erstellen:
   

   

3. Zugangsdaten anlegen: 

   
   
   
   

   Die Access Key ID und der Secret Access Key, die Ihnen in dieser Maske angezeigt werden, sollten Sie unbedingt speichern. Sie sind nur einmalig zugänglich; andernfalls müssten neue Zugangsdaten erstellt werden. Mit diesen beiden Werten können Sie anschließend über S3-kompatible Tools auf Ihren Bucket zugreifen und mit ihm arbeiten.

Bucket Policies: Zugriffsrechte flexibel steuern

Eine Bucket Policy ist eine Zugriffsrichtlinie in Form eines JSON-Dokuments, das direkt an einen Bucket angehängt wird. Sie legt fest:

• Wer (Principal) auf den Bucket oder Objekte zugreifen darf

• Welche Aktionen (z. B. s3:GetObject, s3:PutObject) erlaubt sind

• Auf welche Ressourcen sich die Rechte beziehen

Neue Buckets sind in STACKIT standardmäßig privat. Mit Policies können Sie dieses Verhalten erweitern oder anpassen.

Typische Anwendungsfälle:

• Zugriff für Nutzer aus anderen Portal-Projekten

• Öffentliche Inhalte (z. B. Bilder oder Dateien für Websites)

Beispiel: Alle Objekte im Bucket öffentlich lesbar machen:

{
  "Statement": [
  {
    "Sid": "Public GET",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::BUCKETNAME/*"
  }
  ]
}

Weitere Konfigurationsbeispiele finden Sie in der STACKIT-Dokumentation.

Erweiterte Konfigurationsmöglichkeiten

Neben den Basisfunktionen unterstützt STACKIT Object Storage auch erweiterte Features:

• S3 Lifecycle Configurations: Regeln für automatische Übergänge oder Löschungen nach definierten Zeiträumen

• Pre-Signed URLs: Temporäre, signierte Links für den sicheren, zeitlich begrenzten Zugriff auf private Objekte

• Server-Side Encryption (SSE/SSE-C): Verschlüsselung direkt im Storage, mit STACKIT-Schlüsseln oder eigenen Kundenschlüsseln

• CORS (Cross-Origin Resource Sharing): Kontrolle, von welchen Domains Browser-Apps direkt auf Buckets zugreifen dürfen

• Bucket Versioning: Mehrere Versionen desselben Objekts speichern, um versehentliche Löschungen oder Überschreibungen rückgängig zu machen

Praktische GUI-Tools für S3-kompatible Buckets

Da das STACKIT-Portal aktuell keine integrierte Objekt-Browser-Ansicht bietet, empfiehlt sich für die Verwaltung ein externer Client. Besonders S3 Browser (Windows) ist leichtgewichtig, einfach einzurichten und speziell auf S3-Workflows ausgerichtet, was ideal für Nutzer ist, die Buckets und Dateien per Drag & Drop verwalten möchten.

Alternativ können Sie auch Cyberduck (Windows/macOS) verwenden. 

Für Automatisierungen und Skripte eignen sich ergänzend Tools wie s3cli oder rclone.

Besonderheiten bei Infrastructure-as-Code und Provider-Kompatibilität

Bei der Verwendung von Infrastructure-as-Code (IaC) mit STACKIT Object Storage ergeben sich spezielle Abhängigkeiten zwischen Ressourcen und Providern, die bei der Planung berücksichtigt werden müssen. Ressourcen wie Buckets, Credential-Gruppen und Secrets werden zunächst über den STACKIT Provider erstellt. Nachfolgend am Beispiel von Terraform dargestellt:

resource "stackit_objectstorage_bucket" "bucket" {
  project_id = var.project_id
  name       = "example-bucket"
}

resource "stackit_objectstorage_credentials_group" "credentials_group" {
  project_id = var.project_id
  name       = "example-bucket"
}

resource "stackit_objectstorage_credential" "bucket_credentials" {
  project_id           = var.project_id
  credentials_group_id = stackit_objectstorage_credentials_group.credentials_group.credentials_group_id
}

Erst danach können diese Informationen genutzt werden, um mit dem AWS Provider auf die S3-kompatible Schnittstelle von STACKIT zuzugreifen, z. B. beim Setzen einer Bucket Policy:

resource "aws_s3_bucket_policy" "public_read_access" {
  bucket = stackit_objectstorage_bucket.bucket.name
  policy = <<POLICY
  {
    "Statement": [
      {
        "Sid": "Public GET",
        "Effect":"Allow",
        "Principal":"*",
        "Action":"s3:GetObject",
        "Resource": "arn:aws:s3:::${stackit_objectstorage_bucket.bucket.name}/*"
      }
    ]
  }
  POLICY
}

Damit dies funktioniert, müssen jedoch alle für den AWS Provider Block benötigten Informationen bereits existieren, bevor dieser initialisiert wird. Anders als Ressource-Blöcke unterstützen Provider-Blöcke keine depends_on-Angaben. Der AWS Provider Block muss daher direkt auf die bereits erstellten Credentials zugreifen und den Endpoint korrekt gesetzt bekommen:

provider "aws" {
  region                      = "eu01"
  skip_credentials_validation = true
  skip_region_validation      = true
  skip_requesting_account_id  = true
  access_key                  = stackit_objectstorage_credential.bucket_credentials.access_key
  secret_key                  = stackit_objectstorage_credential.bucket_credentials.secret_access_key
  endpoints {
    s3 = "https://object.storage.eu01.onstackit.cloud"
  }
}

Take-Away: Um Fehler zu vermeiden, dass der Provider auf nicht vorhandene Credentials zugreifen möchte, empfiehlt es sich, die STACKIT-Ressourcen in einem ersten Apply-Schritt zu erstellen und den AWS Provider erst im zweiten Schritt zu verwenden. So wird sichergestellt, dass alle Informationen bei der Initialisierung der Providerblöcke bereits vorhanden sind.

Fazit

Der STACKIT Object Storage bietet eine leistungsfähige, S3-kompatible Lösung für Unternehmen, die Wert auf Datenhoheit, Sicherheit und Kostentransparenz legen. Dank der API-Kompatibilität lassen sich bestehende Tools und Workflows nahezu nahtlos weiterverwenden.

Ob für Backups, Medien-Assets oder Logs: Mit Features wie Lifecycle-Regeln, Pre-Signed URLs und Bucket Policies behalten Sie jederzeit Kontrolle über Datenzugriff und Speicheroptimierung. Externe Clients wie Cyberduck oder S3 Browser ergänzen die Verwaltung sinnvoll.

Kurz gesagt: ein flexibler, sicherer und zukunftsfähiger Object Storage „Made in Europe“.