Cloud Beratung – Wir schaffen die erfolgreiche Transformation.

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“.

Die Nutzung von Cloud-Plattformen ist längst fester Bestandteil der modernen IT. Mit STACKIT bietet die Schwarz Gruppe eine leistungsfähige deutsche Cloud Plattform, die sich zunehmend als Alternative zu den US-Hyperscalern positioniert.
Ähnlich wie die US-Hyperscaler bietet die STACKIT Cloud ebenfalls mehrere Wege, um mit dem Resource Mangager zu interagieren. Hierzu gehören zahlreiche Tools wie zum Beispiel Terraform, eigene SDKs und APIs oder die STACKIT CLI.

In diesem Beitrag zeigen wir, wie Sie die STACKIT CLI installieren, welche Befehle wirklich nützlich sind und warum sich dieses Tool für Cloud Administratoren und DevOps Teams lohnt.

Was ist die STACKIT CLI?

Die STACKIT CLI ist ein Kommandozeilen-Tool zur direkten Steuerung der STACKIT Cloud. Sie ermöglicht es, Ressourcen schnell, wiederholbar und automatisierbar zu verwalten, etwa zur Erstellung von Projekten, zur Bereitstellung von virtuellen Maschinen oder für die Integration in CI/CD-Prozesse. Die STACKIT CLI basiert auf die STACKIT API.

Die STACKIT CLI befindet sich zum Zeitpunkt dieses Blogposts noch in der Beta. Sie bietet Ihnen die Möglichkeit, Services bereitzustellen, die Sie im Web-Portal von STACKIT nicht bereitstellen können (z.B. Application Load Balancer). Auf der anderen Seite unterstützt die STACKIT CLI leider auch noch nicht alle Produkte, die Sie im Web-Portal konfigurieren können (z.B. Cloud Foundry).

Die STACKIT CLI wird als Open-Source Projekt in GitHub geführt:
https://github.com/stackitcloud/stackit-cli/tree/main

Installation der STACKIT CLI:

Windows

1. Zip Datei aus GitHub Release downloaden
   • Auf GitHub das neueste Release der STACKIT CLI öffnen und das passende Windows‑ZIP‑Archiv herunterladen.
2. Binary bereitstellen
   • stackit.exe entpacken und in einen Ordner Ihrer Wahl kopieren (z. B. C:\REWION\).
   • Tipp: Legen Sie stackit.exe in C:\Windows\System32, um die Anwendung systemweit verfügbar zu machen.
3. Umgebungsvariable setzen (Alternative zu System32):
   Nutzen Sie den folgenden Befehl in der PowerShell, um den Pfad der STACKIT CLI für Sie im System zu hinterlegen:

   [Environment]::SetEnvironmentVariable("Path", $Env:Path + ";C:\REWION","User")

4. Starten Sie die PowerShell Instanz neu
5. Prüfen & Nutzen
   Nutzen Sie die folgenden Befehle in der neuen PowerShell Instanz, um zu prüfen, ob die STACKIT CLI korrekt vom System gefunden wird und verwendet werden kann:

   where.exe stackit      # zeigt den Pfad
   stackit --version      # zeigt die installierte Version 

macOS

Unter macOS installieren Sie die STACKIT CLI am einfachsten über Homebrew:

1. Homebrew einrichten
   Falls noch nicht vorhanden, führen Sie im Terminal folgenden Befehl aus, um Homebrew zu installieren:

   /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. STACKIT Tap hinzufügen
   Registrieren Sie das offizielle STACKIT-Repository aus Homebrew:

   brew tap stackitcloud/tap

3. STACKIT CLI installieren
   Installieren Sie die aktuelle Version als Cask—so bleiben auch Profil-Daten erhalten:

   brew install --cask stackit

4. Installation prüfen
   Verifizieren Sie, dass das Programm erreichbar ist und zeigen Sie die installierte Version an:

   which stackit  # zeigt den Pfad
   stackit --version # zeigt die installierte Version

Linux

Für Linux-Systeme stehen mehrere Varianten zur Verfügung. Die beiden meistgenutzten Methoden sind Snap und das Debian/Ubuntu-Repository (APT).

Snap (alle Distributionen)

1. Snap installieren (falls nötig)
   Ubuntu & Co. bringen Snap meist vorinstalliert mit. Ansonsten:

   sudo apt update sudo apt install snapd

2. STACKIT CLI per Snap ausrollen
   Holen Sie sich die aktuellste Version:

   sudo snap install stackit --beta --classic

3. Funktionstest
   Überprüfen Sie die Verfügbarkeit und Version:

   snap list stackit  # zeigt den Pfad
   stackit --version # zeigt die installierte Version

Debian/Ubuntu (APT)

1. Voraussetzungen
   Stellen Sie sicher, dass curl und gnupg installiert sind:

   sudo apt-get update sudo apt-get install curl gnupg

2. STACKIT-Signing-Key importieren
   Laden Sie den öffentlichen Schlüssel herunter und wandeln ihn ins passende Format um:

   curl https://packages.stackit.cloud/keys/key.gpg \ | sudo gpg --dearmor -o /usr/share/keyrings/stackit.gpg

3. Paketquelle hinzufügen
   Fügen Sie das STACKIT-Repository Ihrer Quellenliste hinzu:

   echo "deb [signed-by=/usr/share/keyrings/stackit.gpg] \ https://packages.stackit.cloud/apt/cli stackit main" \ | sudo tee /etc/apt/sources.list.d/stackit.list

4. Installation durchführen
   Aktualisieren Sie die Paketliste und installieren das CLI-Paket:

   sudo apt-get update
   sudo apt-get install stackit

5. Installation testen
   Prüfen Sie, ob der Befehl verfügbar ist und welche Version installiert wurde:

   which stackit  # zeigt den Pfad
   stackit --version # zeigt die installierte Version

Erste Schritte & nützliche Befehle

Nach der Anmeldung per stackit auth login (für Benutzer-Accounts) oder stackit auth activate-service-account (für Service-Accounts) können Sie direkt loslegen. Passen Sie zuerst Ihre Grundeinstellungen an:

1. 1. Projekt festlegen

      stackit config set --project-id <deine-project-id>

   2. Ausgabe-Tiefe einstellen

      stackit config set --verbosity <debug-level>

   3. Weitere Optionen anzeigen

      stackit config set --help
      

   4. Beispiele für die Operative Nutzung
      

      stackit --help #zeigt alle verfügbaren Befehle an stackit server list # zeigt alle virtuellen Maschinen in Ihrem aktuellen Projekt an stackit curl https://iaas.api.eu01.stackit.cloud/v1/projects//servers/ # zeigt das Wartungsfenster einer konkreten STACKIT VM an

Tipp: Für verschiedene Umgebungen (z. B. „Dev“ und „Prod“) legen Sie separate Profile an:

stackit config set --profile dev --project-id 11111111-2222-3333-4444-555555555555
stackit config set --profile prod --project-id 66666666-7777-8888-9999-000000000000

Das FinOps Framework unterstützt Unternehmen dabei, ihre Kosten für Cloud und Technologie besser zu verstehen, zu steuern und kontinuierlich zu optimieren. Wichtiger Bestandteil des Frameworks sind die FinOps Domänen, die die Geschäftsergebnisse definieren, die Teams mit einer FinOps Aktivität erreichen möchten. Welche Domänen es gibt und wie sie in Verbindung mit den einzelnen Fähigkeiten stehen, erklären wir in diesem Artikel.

Was sind FinOps Domänen und wie hängen sie mit Fähigkeiten zusammen?

Bei den FinOps Domänen handelt es sich um die Definition der zentralen Geschäftsergebnisse, die Unternehmen durch den Einsatz des FinOps Frameworks erreichen wollen. Sie schaffen eine klare Struktur, nach der Teams die relevanten Aktivitäten und Fähigkeiten verstehen und wählen können. Insgesamt gibt es vier Domänen, die wiederum spezifische Fähigkeiten enthalten, die Teams entwickeln können, um die gewünschten Ergebnisse zu erzielen. Die Auswahl und Priorisierung dieser Fähigkeiten hängt wiederum vom individuellen Reifegrad des Teams sowie von den individuellen Anforderungen ab.

Bei den Domänen und Fähigkeiten geht es nicht darum, jede einzelne Fähigkeit bis zum höchsten Reifegrad zu entwickeln. Vielmehr geht es darum, genau die Fähigkeiten auszuwählen und zu entwickeln, die dem Unternehmen den größten Mehrwert bringen. In der Regel führen Unternehmen jedoch FinOps Aktivitäten in jeder der vier Domänen durch – lediglich bei den Fähigkeiten gibt es je nach Anforderungen entsprechende Unterschiede.

Die 4 FinOps Domänen im Überblick

Insgesamt gibt es 4 Domänen im FinOps Framework: Nutzung und Kosten verstehen, Geschäftswert quantifizieren, Nutzung und Kosten optimieren und FinOps Aktivitäten steuern. Wir haben zusammengefasst, worum es in den einzelnen Domänen gibt, welche Ziele sie haben und welche Fähigkeiten Teil von ihnen sind.

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

Nutzung und Kosten verstehen

Das Ziel dieser Domäne ist es, ein umfassendes Verständnis darüber zu gewinnen, wie Cloud-Ressourcen und andere Technologien im Unternehmen genutzt werden. Sowohl Nutzung als auch die zugehörigen Kosten stehen hier im Fokus.

Damit bildet die Domäne die Basis für FinOps, da sie alle nötigen Datenquellen und Organisationsstrukturen schafft, um Transparenz zu geben und Vergleiche möglich zu machen. Der Fokus liegt darauf, sämtliche relevanten Informationen zu sammeln und so aufzubereiten, dass sie in verschiedenen Bereichen und für verschiedene Rollen im Unternehmen nutzbar sind.

Diese Fähigkeiten sind Teil dieser Domäne

• Datenerfassung
• Kostenzuordnung
• Berichte & Analysen
• Erkennung & Verwaltung von Anomalien

Quantifizierung des Geschäftswerts

Das Ziel der nächsten Domäne ist es, den Zusammenhang zwischen Cloud-Nutzung, Kosten und dem daraus entstehenden Geschäftswert zu definieren und transparent zu machen.

Schlussendlich geht es darum, dass Teams die Cloud-Ausgaben einzelnen Budgets zuordnen, Prognosen erstellen und relevante Kennzahlen definieren können. Die wichtigste Frage lautet: Wofür entstehen aktuell Kosten, wofür sollen Budgets eingesetzt werden und wie können wir den Geschäftswert sinnvoll messen? Diese Domäne hilft dabei, technische und organisatorische Investitionen besser bewerten und steuern zu können.

Diese Fähigkeiten sind Teil dieser Domäne:

• Planung & Schätzung
• Prognosen
• Budgetierung
• Benchmarking
• Analyse wirtschaftlicher Einheiten

Nutzung und Kosten optimieren

Diese Domäne hat das Ziel, die Ressourcennutzung und die Kosten für Cloud und weitere Technologien so zu optimieren, dass maximale Effizienz und Wertschöpfung entstehen kann.

Dabei liegt der Fokus darauf, dass Cloud-Ressourcen nur dann genutzt werden sollen, wenn sie geschäftlichen Mehrwert liefern. Gleichzeitig sollen die Ressourcen zu möglichst niedrigen Kosten und mit hoher Nachhaltigkeit beschafft werden. Wichtige Themen sind an dieser Stelle beispielsweise auch eine moderne Cloud-Architektur, Sustainable IT und durchdachtes Lizenzmanagement.

Diese Fähigkeiten sind Teil dieser Domäne:

• Cloud-Architekturgestaltung
• Workload-Optimierung
• Kostenoptimierung
• Cloud-Nachhaltigkeit
• Lizenzierung & SaaS-Management

FinOps Aktivitäten steuern

Ziel dieser Domäne ist es, die organisatorischen Rahmenbedingungen zu schaffen, um FinOps dauerhaft erfolgreich in den Unternehmensalltag zu integrieren.

Dabei liegt der Fokus auf der kontinuierlichen Weiterentwicklung aller FinOps Aktivitäten, sowohl im menschlichen als auch im technologischen und organisatorischen Kontext. Es geht darum, eine fundierte Governance zu schaffen, Mitarbeitende mit Schulungen abzuholen und FinOps in bestehende Unternehmensprozesse zu integrieren.

Diese Fähigkeiten sind Teil dieser Domäne:

• FinOps Praxisbetrieb
• Policy & Governance
• Evaluierung des Reifegrads
• Tools & Services
• Fortbildung
• Rechnungen & Rückbuchung
• Workload-Onboarding
• Überschneidende Disziplinen

Domänen in der Praxis: so kann die Anwendung aussehen

Die FinOps Domänen finden in der Praxis nicht nacheinander, sondern parallel Anwendung. Oft arbeiten unterschiedliche Teams abhängig von ihren Aufgaben und ihrem Reifegrad in unterschiedlichen Domänen. Das bedeutet konkret: Ein Team kann gerade an der Nutzungsoptimierung arbeiten, während ein anderes Team an der Budgetierung und am Forecasting arbeitet. Auch die Fähigkeiten innerhalb der Domänen entwickeln sich individuell: Ein Team hat möglicherweise schon ausgereifte Reports, während ein anderes Team noch am Anfang der Datenaufnahme steht. Letztendlich greifen Domänen und Fähigkeiten eng ineinander und schaffen so ein ganzheitliches Modell, das Unternehmen in ihrem Kostenmanagement voranbringt.

Fazit: FinOps Domänen als zentraler Bestandteil des Frameworks

Der Fokus der ersten drei FinOps Domänen liegt auf der effektiven Nutzung von Cloud und Technologie – von Transparenz über Bewertung bis hin zur Optimierung. Die vierte Domäne wiederum schafft die organisatorischen Grundlagen, um FinOps dauerhaft in das Unternehmen und die einzelnen Teams zu integrieren. Das macht die Domänen zu einem so zentralen Bestandteil des FinOps Frameworks. Sie helfen den Teams dabei, ihre Aktivitäten klar auszurichten, die für sie relevanten Fähigkeiten zu entwickeln und messbare Geschäftsergebnisse zu erzielen. Am Ende entsteht eine gemeinsame Struktur, die eine Verbindung zwischen Finanzen, Technik und Business schafft und so den Weg zu einer nachhaltigen und unternehmensweiten FinOps Kultur ebnet.