WISSEN > CLOUD INFRASTRUKTUR -> PUBLIC, PRIVATE UND HYBRID CLOUD
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Public Cloud, Private Cloud und Hybrid Cloud im Vergleich
Was NIST und ISO/IEC unter Deployment Models verstehen und wo sie abweichen
Das sollten Sie mitnehmen: FASLCH FALSCH
- WAN-Latenz lässt sich nicht wegkaufen, nur umgehen.
Edge File Services sorgen dafür, dass möglichst wenige Zugriffe den WAN-Pfad durchlaufen.
- Global verfügbar heißt nicht lokal gespeichert.
Für die Cache-Größe zählt der lokale Working Set, nicht die Gesamtkapazität.
- Caching und Locking lösen zwei verschiedene Probleme.
Das eine optimiert den Weg zu den Daten, das andere koordiniert konkurrierende Schreibzugriffe. Wer nur das erste plant, bekommt das zweite als Überraschung.
- Nicht jedes Produkt kann standortübergreifend sperren.
DFS Replication und Azure File Sync bieten kein globales Locking – das entscheidet die Auswahl früher als jede Performance-Kennzahl.
- Sizing braucht Nutzungsdaten, keine Kapazitätszahlen.
Aussagekräftig sind Dateianzahl, Änderungsverhalten und Zugriffsverhalten am Standort.
Was NIST und ISO/IEC unter Deployment Models verstehen und wo sie abweichen
Inhaltsverzeichnis
- Deployment Model und Service Model beantworten zwei verschiedene Fragen
- Public Cloud ist kein Standort, sondern eine Kontrollaussage
- Private Cloud bedeutet nicht On-Premises
- Exklusive Kontrolle verschiebt Betriebsverantwortung, sie beseitigt sie nicht
- Hybrid Cloud entsteht durch Integration, nicht durch Koexistenz
- NIST und ISO meinen mit Hybrid Cloud nicht dasselbe
- Multi-Cloud, Federated Cloud und Inter-Cloud sind eigene Modelle
- Die Integrationsschichten entscheiden über die Tragfähigkeit einer Hybrid-Architektur
- Compute und Storage folgen nicht zwangsläufig derselben Cloud
- Souveränität und Regulierung greifen an derselben Stelle an wie die Modelldefinition
- Fazit
- Quellen
Cloud-Infrastrukturen lassen sich unterschiedlich organisieren und betreiben. Public Cloud, Private Cloud und Hybrid Cloud bezeichnen dabei keine Technologien und keine Produkte, sondern Cloud Deployment Models: die Art, wie Cloud-Ressourcen bereitgestellt, kontrolliert und zwischen Nutzern oder Organisationen geteilt werden.
Diese Unterscheidung ist deshalb wichtig, weil die Begriffe im Sprachgebrauch regelmäßig zu Standortaussagen verkürzt werden. Private Cloud heißt nicht automatisch „im eigenen Rechenzentrum". Hybrid Cloud heißt nicht, dass ein Unternehmen neben lokaler IT irgendeinen Cloud-Dienst nutzt. In unserer Projektarbeit begegnen uns beide Verkürzungen so häufig, dass sie regelmäßig zu Architekturentscheidungen führen, die auf einer Modellbezeichnung statt auf einer Kontroll- und Datenpfadanalyse beruhen.
Die maßgeblichen Definitionen stammen aus zwei Quellen, die sich nicht vollständig decken. NIST unterscheidet in seiner Cloud-Definition vier Deployment Models: Private Cloud, Community Cloud, Public Cloud und Hybrid Cloud. ISO/IEC 22123-1:2023 definiert dieselben Begriffe teilweise enger und ergänzt Multi-Cloud, Hybrid Multi-Cloud, Federated Cloud und Inter-Cloud. Wo die beiden Systematiken auseinanderlaufen, entstehen die Missverständnisse, um die es in diesem Artikel geht.
Deployment Model und Service Model beantworten zwei verschiedene Fragen
Zunächst sind zwei Klassifikationen zu trennen, die im Gespräch oft vermischt werden.
Ein Deployment Model beschreibt nach ISO/IEC 22123-1:2023, wie Cloud Computing auf Basis von Kontrolle und gemeinsamer Nutzung physischer oder virtueller Ressourcen organisiert wird. Dazu gehören Public, Private und Hybrid Cloud.
Ein Service Model beschreibt dagegen, welche Ebene der IT-Infrastruktur als Dienst bereitgestellt wird. NIST unterscheidet Software as a Service, Platform as a Service und Infrastructure as a Service. Bei IaaS werden grundlegende Ressourcen wie Compute, Storage und Netzwerk bereitgestellt; der Kunde kontrolliert Betriebssysteme, Storage und die eingesetzten Anwendungen, nicht aber die darunterliegende physische und virtuelle Infrastruktur.
Beide Klassifikationen sind frei kombinierbar. Eine Organisation kann IaaS aus einer Public Cloud beziehen oder eine IaaS-Plattform innerhalb einer Private Cloud betreiben. Die Frage nach Public oder Private beantwortet deshalb etwas anderes als die Frage nach IaaS, PaaS oder SaaS – und eine Architekturdiskussion, die beide Achsen zusammenwirft, produziert Scheinalternativen.
[BILD 1: Zweiachsige Matrix. Horizontal die Deployment Models Public, Private, Hybrid; vertikal die Service Models IaaS, PaaS, SaaS. Die Zellen sind gleichwertig eingefärbt, um zu zeigen, dass jede Kombination möglich ist. Beschriftung an den Achsen: „Wer kontrolliert die Ressourcen?" und „Welche Ebene wird als Dienst bezogen?"]
[QUERVERWEIS: Was ist Cloud-Infrastruktur?]
Public Cloud ist kein Standort, sondern eine Kontrollaussage
Bei einer Public Cloud werden Cloud Services einem potenziell beliebigen Kundenkreis angeboten. ISO/IEC 22123-1:2023 formuliert das über zwei Merkmale: Die Services stehen potenziell jedem Cloud Service Customer zur Verfügung, und die Ressourcen werden vom Cloud Service Provider kontrolliert. NIST beschreibt Public Cloud entsprechend als Infrastruktur für die offene Nutzung durch die Allgemeinheit.
NIST ergänzt an dieser Stelle eine Aussage, die für den weiteren Verlauf des Artikels wichtig ist: Die Infrastruktur einer Public Cloud existiert auf dem Gelände des Cloud Providers. Anders als bei der Private Cloud gibt es hier keine Wahlfreiheit beim Standort.
Hinzu kommen die allgemeinen Cloud-Eigenschaften. NIST zählt fünf davon: On-Demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity und Measured Service. Beim Resource Pooling werden Ressourcen des Providers zusammengefasst und mehreren Nutzern bedarfsgerecht zugewiesen.
Public Cloud bedeutet deshalb nicht einfach „Server bei einem externen Anbieter". Gemietete dedizierte Hardware in einem fremden Rechenzentrum erfüllt die Definition nicht, solange die Bereitstellung nicht die Eigenschaften eines Cloud-Modells besitzt. Für den Anwender verschiebt sich zugleich die technische Verantwortungsgrenze: Welche Schichten er kontrolliert und welche der Provider betreibt, ergibt sich aus dem Service Model, nicht aus dem Deployment Model.
Private Cloud bedeutet nicht On-Premises
Eine Private Cloud stellt Cloud Services exklusiv für einen einzelnen Cloud Service Customer bereit. Nach ISO/IEC 22123-1:2023 werden die Ressourcen dabei von genau diesem Cloud Service Customer kontrolliert. NIST beschreibt Private Cloud als Infrastruktur zur exklusiven Nutzung durch eine einzelne Organisation, die mehrere interne Nutzer oder Organisationseinheiten umfassen kann.
Damit ist die verbreitetste Verkürzung widerlegt. NIST stellt ausdrücklich fest, dass eine Private Cloud durch die Organisation selbst, einen Dritten oder eine Kombination aus beiden betrieben werden kann und sich sowohl on premises als auch off premises befinden kann. Der physische Standort entscheidet also nicht darüber, ob eine Infrastruktur eine Private Cloud ist. Genau hier liegt die Asymmetrie zur Public Cloud, deren Infrastruktur definitionsgemäß beim Provider liegt.
Die Umkehrung gilt ebenso. Ein klassisches virtualisiertes Rechenzentrum wird nicht dadurch zur Private Cloud, dass die Server ausschließlich einem Unternehmen gehören. Nach der NIST-Systematik kommen die grundlegenden Cloud-Eigenschaften hinzu: On-Demand Self-Service, Resource Pooling, Rapid Elasticity und Measured Service. Virtualisierung kann die technische Grundlage einer Private Cloud sein, ist aber nicht mit Cloud Computing gleichzusetzen.
Ein Detail verdient dabei Aufmerksamkeit, weil es in Diskussionen regelmäßig als Widerspruch vorgebracht wird. Resource Pooling ist in beiden Normen providerbezogen definiert – als Zusammenfassung der Ressourcen eines Cloud Service Providers zur Bedienung mehrerer Kunden. In einer Private Cloud gibt es aber nur einen Cloud Service Customer. Aufgelöst wird das über die NIST-Formulierung, nach der die nutzende Organisation mehrere Consumer umfasst, etwa Geschäftsbereiche. Das Pooling findet dann zwischen internen Organisationseinheiten statt, nicht zwischen fremden Mandanten.
[BILD 2: Gegenüberstellung der Standortaussagen. Links Public Cloud mit einer festen Verortung beim Provider, rechts Private Cloud mit zwei gleichwertigen Verortungsoptionen on premises und off premises. Ein durchgezogener Rahmen markiert jeweils, wer die Ressourcen kontrolliert, nicht wo sie stehen.]
Exklusive Kontrolle verschiebt Betriebsverantwortung, sie beseitigt sie nicht
Die exklusive Nutzung der Ressourcen verändert die Kontroll- und Verantwortungsgrenzen in beide Richtungen.
Bei einer selbst betriebenen Private Cloud liegen deutlich mehr Aufgaben innerhalb der eigenen Organisation als beim Bezug eines vergleichbaren Public-Cloud-Dienstes. Je nach Architektur und Betriebsmodell gehören dazu Hardware, Virtualisierung, Netzwerk, Storage, Automatisierung, Monitoring, Kapazitätsplanung und Lifecycle Management. Wird die Private Cloud dagegen von einem externen Anbieter betrieben, verschieben sich diese Verantwortlichkeiten wieder – ohne dass sich am Deployment Model etwas ändert.
Aus diesem Grund halten wir die Bezeichnung „Private Cloud" für eine Architekturentscheidung allein nicht für ausreichend. Sie beantwortet die Frage nach der Exklusivität, aber nicht die Frage danach, wer welche Schicht der Infrastruktur besitzt, kontrolliert und betreibt. Erst diese Aufschlüsselung macht Aufwand, Risiko und Abhängigkeiten vergleichbar.
Hybrid Cloud entsteht durch Integration, nicht durch Koexistenz
Eine Hybrid Cloud verbindet mehrere eigenständige Cloud-Umgebungen zu einer gemeinsamen Architektur. ISO/IEC 22123-1:2023 definiert sie als Deployment Model, das eine Private Cloud und eine Public Cloud verwendet.
Die NIST-Definition beschreibt den technischen Zusammenhang genauer. Eine Hybrid Cloud besteht dort aus zwei oder mehr eigenständigen Cloud-Infrastrukturen, die eigenständige Einheiten bleiben, aber durch standardisierte oder proprietäre Technologien so miteinander verbunden werden, dass Daten- und Applikationsportabilität möglich wird.
Der entscheidende Bestandteil ist die Verbindung. Ohne sie liegen zwei Infrastrukturen nebeneinander, aber keine Hybrid Cloud vor. Daraus folgt die Abgrenzung, die in der Praxis am häufigsten fehlt: Ein Unternehmen kann klassische On-Premises-Infrastruktur betreiben und parallel einen Public-Cloud-Service nutzen, ohne dass daraus nach der NIST-Definition eine Hybrid Cloud entsteht. Vorausgesetzt wird die Kopplung eigenständiger Cloud-Infrastrukturen, die Daten- oder Applikationsportabilität ermöglicht.
Für eine belastbare Architekturbeschreibung reicht der Begriff deshalb nicht aus. Anzugeben ist, welche Umgebungen tatsächlich verbunden sind und wie diese Verbindung realisiert wird.
NIST und ISO meinen mit Hybrid Cloud nicht dasselbe
An dieser Stelle laufen die beiden maßgeblichen Systematiken auseinander, und die Abweichung wird in der Fachliteratur regelmäßig eingeebnet.
ISO/IEC 22123-1:2023 verlangt für eine Hybrid Cloud die Kombination aus einer Private Cloud und einer Public Cloud. NIST verlangt lediglich zwei oder mehr eigenständige Cloud-Infrastrukturen und nennt als mögliche Bestandteile ausdrücklich private, community und public. Nach NIST kann damit auch die Kopplung einer Community Cloud mit einer Public Cloud eine Hybrid Cloud sein – und je nach Auslegung sogar die portabilitätsfähige Verbindung zweier Public Clouds.
Die Abweichung ist nicht historisch gewachsen, sondern jung. Die zweite Edition von ISO/IEC 22123-1 aus dem Februar 2023 hat die Definition der Hybrid Cloud ausdrücklich geändert und die Terminologie zu Multi-Cloud neu aufgenommen. Wer eine ältere Quelle zitiert, zitiert eine andere Definition.
Praktisch bedeutet das: Dieselbe Konstellation kann nach ISO Multi-Cloud und nach NIST Hybrid Cloud heißen. Wir empfehlen deshalb, in Architekturdokumenten nicht das Modelllabel zu führen, sondern die beteiligten Umgebungen und die Art ihrer Kopplung zu benennen. Das Label ist eine Abkürzung; die Kopplung ist der Gegenstand.
[BILD 3: Vergleichsgrafik der drei Modelle über sechs Kriterien – Nutzerkreis, Ressourcenkontrolle, Standort, Skalierungsgrenze, Datenpfade, Betriebsverantwortung. Public Cloud, Private Cloud und Hybrid Cloud als drei Spalten in der ASSISTRA-Blauskala, ohne Wertung oder Rangfolge; Hybrid-Spalte durch eine zusätzliche Verbindungsebene zwischen den beiden anderen Spalten dargestellt.]
Multi-Cloud, Federated Cloud und Inter-Cloud sind eigene Modelle
Mit der Nutzung mehrerer Provider werden weitere Abgrenzungen nötig, die ISO/IEC 22123-1:2023 sauber trennt.
Multi-Cloud bezeichnet ein Deployment Model, bei dem ein Cloud Service Customer Public-Cloud-Services von mindestens zwei Cloud Service Providern verwendet. Die Norm hält in einer Anmerkung fest, dass die Verantwortung für Integration und Management dieser Services beim Cloud Service Customer liegt. Hybrid Cloud verbindet demgegenüber Private und Public Cloud; Hybrid Multi-Cloud bezeichnet die Kombination aus beidem.
Federated Cloud beschreibt ein Modell, in dem die Cloud Services von Mitgliedern einer Cloud Service Federation erbracht werden – also von mehreren Providern, die durch vereinbarte Richtlinien, Prozesse und Vertrauensbeziehungen verbunden sind.
Inter-Cloud ist architektonisch der interessanteste dieser Begriffe, weil er eine Abhängigkeit beschreibt, die der Kunde nicht unmittelbar sieht. Ein Cloud Service Provider erbringt seinen Dienst dabei unter Nutzung eines oder mehrerer Dienste anderer Provider, typischerweise über Vermittlung, Aggregation oder Arbitrage. Für eine Verfügbarkeitsbetrachtung ist das erheblich: Die Failure Domain reicht dann über den vertraglich gebundenen Provider hinaus.
Diese Begriffe beschreiben unterschiedliche Architekturmerkmale und sollten nicht synonym verwendet werden.
Die Integrationsschichten entscheiden über die Tragfähigkeit einer Hybrid-Architektur
Die beteiligten Umgebungen bleiben in einer Hybrid Cloud eigenständig. Genau daraus entstehen die Integrationsaufgaben, an denen sich entscheidet, ob die Architektur trägt.
Netzwerk
Private und Public Cloud benötigen einen definierten Kommunikationspfad. Je nach Anforderung wird er über öffentliche IP-Netze mit verschlüsselten Verbindungen oder über dedizierte Netzwerkverbindungen realisiert.
Die Eigenschaften des zugrunde liegenden Netzes verschwinden dabei nicht. Daten müssen zwischen den Umgebungen übertragen werden, und Bandbreite, Latenz, Paketverluste sowie die verfügbaren Netzwerkpfade prägen das Verhalten der Anwendung. Ein Netzwerkpfad, der im Normalbetrieb ausreicht, kann im Wiederanlauf nach einem Ausfall zur bestimmenden Größe werden.
Identity und Berechtigungen
Benutzer, Systeme und Anwendungen benötigen über Umgebungsgrenzen hinweg definierte Identitäten und Zugriffsrechte. Werden unterschiedliche Identity-Systeme verwendet, ist zu klären, wie Authentication und Authorization zwischen den Umgebungen funktionieren. Authentication beantwortet die Frage, wer eine Identität besitzt; Authorization bestimmt, auf welche Ressourcen diese Identität zugreifen darf. Beides sind getrennte Funktionen, und beide müssen konsistent über beide Umgebungen wirken, sonst entsteht an der Nahtstelle eine Berechtigungslücke.
Daten
Eine Anwendung kann Daten in einer Umgebung erzeugen und in einer anderen verarbeiten. Damit entsteht ein Datenpfad von der Quelle über das Netzwerk zum Zielsystem. Je nach Architektur werden Daten vollständig übertragen, repliziert, synchronisiert oder über Schnittstellen remote angesprochen. Datenlokalität, Bandbreite und Latenz werden dadurch zu Architekturparametern und nicht zu nachgelagerten Betriebsdetails.
Management
Auch die Betriebsmodelle müssen zusammengeführt werden. Monitoring, Provisionierung, Logging, Security Policies und Lifecycle-Prozesse unterscheiden sich zwischen Private und Public Cloud regelmäßig. Die NIST Cloud Computing Reference Architecture behandelt Cloud Service Management mit Business Support, Provisioning and Configuration sowie Portability and Interoperability deshalb als eigenständige Bestandteile einer Cloud-Architektur.
[QUERVERWEIS: Cloud-native und cloud-enabled Infrastruktur]
Compute und Storage folgen nicht zwangsläufig derselben Cloud
Eine Infrastruktur besteht nicht aus einer einzelnen Ressource. Compute, Storage, Netzwerk, Datenbanken und Anwendungen haben unterschiedliche technische Anforderungen, und in einer verteilten Architektur muss nicht jede Ressource am selben Ort oder innerhalb desselben Cloud-Dienstes liegen.
Gerade in Hybrid-Architekturen ist deshalb der Datenpfad zu betrachten. Liegen Compute und die benötigten Daten in unterschiedlichen Umgebungen, muss die Anwendung über die verbindende Infrastruktur auf die Daten zugreifen oder die Daten müssen bewegt werden. Beides hat Konsequenzen für Latenz, Bandbreite und Kosten.
Damit hängen Compute- und Storage-Entscheidungen zusammen. Eine theoretisch verfügbare Compute-Kapazität sagt nichts darüber aus, mit welcher Latenz oder Bandbreite die benötigten Daten erreichbar sind. Nach unserer Erfahrung ist das die Stelle, an der Hybrid-Architekturen im Betrieb am häufigsten hinter den Erwartungen zurückbleiben: nicht an der Rechenleistung, sondern an der Erreichbarkeit der Daten.
Die Cloud-Entscheidung lautet deshalb nicht nur, wo die Anwendung läuft, sondern auch, wo die Daten liegen, wie sie zur Anwendung gelangen und welche Abhängigkeiten dabei entstehen.
[BILD 4: Datenpfaddarstellung einer Hybrid-Architektur. Compute-Instanz in der Public Cloud, primärer Datenbestand in der Private Cloud, dazwischen die Verbindungsschicht mit den Parametern Latenz, Bandbreite und Übertragungsvolumen. Zwei alternative Pfade sind angedeutet: Remote-Zugriff und Datenbewegung.]
[QUERVERWEIS: Cloud Storage – Block, File und Object]
[QUERVERWEIS: Hybrid Cloud Storage]
Souveränität und Regulierung greifen an derselben Stelle an wie die Modelldefinition
Die Modelldefinitionen sind älter als die regulatorische Diskussion, die derzeit viele Cloud-Entscheidungen im deutschen Markt prägt. Beide treffen sich jedoch an einem Punkt: der Kontrolle über die Ressourcen.
Genau dieses Kriterium unterscheidet in ISO/IEC 22123-1:2023 die Private von der Public Cloud. Souveränitätsanforderungen sind damit keine Zusatzbedingung neben der Modellwahl, sondern eine Präzisierung derselben Frage – wer kontrolliert welche Schicht, und unter welcher Rechtsordnung.
Für Hybrid- und Multi-Cloud-Architekturen kommt eine wirtschaftliche Komponente hinzu, die sich derzeit verschiebt. Der EU Data Act regelt in Artikel 29 den schrittweisen Wegfall von Switching-Gebühren: Bis zum 12. Januar 2027 dürfen Anbieter nur noch kostendeckende Gebühren für einen Anbieterwechsel erheben, danach keine mehr. Datenausleitungsgebühren für den Wechsel fallen unter diese Regelung.
Architektonisch bedeutsam ist die Abgrenzung dazu. Artikel 34 Absatz 2 lässt es weiterhin zu, Egress-Kosten für den parallelen Betrieb mehrerer Dienste in Rechnung zu stellen, begrenzt auf die tatsächlichen Kosten. Die Kosten des Ausstiegs sinken damit auf null, die laufenden Kosten der Datenbewegung in einer Hybrid- oder Multi-Cloud-Architektur bleiben bestehen. Wer die Regelung als generelle Entlastung für verteilte Architekturen liest, verwechselt einen einmaligen Wechselvorgang mit einem Dauerbetrieb.
[QUERVERWEIS: Storage-Entscheidungen unter Kostendruck]
Fazit
Die Wahl zwischen Public, Private und Hybrid Cloud ist eine Architekturentscheidung und keine Produktentscheidung. Keines der Modelle ist grundsätzlich besser; sie beschreiben unterschiedliche Kontroll- und Integrationsverhältnisse.
Eine Public Cloud kann sinnvoll sein, wenn Ressourcen bedarfsgerecht über einen Provider bereitgestellt werden sollen und die technischen, regulatorischen und wirtschaftlichen Anforderungen mit dessen Services und Verantwortungsmodell vereinbar sind. Eine Private Cloud kann sinnvoll sein, wenn eine Organisation Cloud-Eigenschaften benötigt, die Ressourcen aber exklusiv kontrollieren will – wobei die zugrunde liegende Infrastruktur dadurch nicht verschwindet, sondern weiterhin durch die Organisation oder einen beauftragten Betreiber bereitgestellt werden muss. Eine Hybrid Cloud kann sinnvoll sein, wenn Workloads oder Daten aus technischen oder organisatorischen Gründen auf beide Umgebungen verteilt werden sollen und die Integration beherrschbar ist. Der zusätzliche Freiheitsgrad erzeugt dabei zusätzliche Architekturfragen.
Wir bewerten Cloud-Architekturen deshalb nicht entlang des Modelllabels, sondern entlang einer Reihe konkreter Fragen. Wo dürfen und müssen Daten gespeichert und verarbeitet werden? Welche Systeme kommunizieren miteinander, und welche Latenzen entstehen dabei? Welche Datenmengen bewegen sich zwischen Standorten oder Cloud-Umgebungen, und in welchem Zeitfenster? Welche Ressourcen müssen dynamisch erweiterbar sein, und wo liegen die harten Grenzen? Welche Infrastrukturkomponenten muss die Organisation selbst kontrollieren, und welche Schichten betreibt der Provider? Von welchen Rechenzentren, Netzwerken, Providern und lokalen Systemen hängt der Dienst ab, und wie weit reicht die Failure Domain tatsächlich – bis zum Vertragspartner oder darüber hinaus? Wie werden Netzwerk, Identity, Anwendungen, Management und Daten zwischen den Umgebungen verbunden? Und welche Kosten entstehen nicht nur für Ressourcen, sondern für Betrieb, Netzwerk und Datenbewegung im Dauerbetrieb?
Erst die Kombination dieser Faktoren ergibt eine belastbare Architekturentscheidung. Das Deployment Model ist dann das Ergebnis dieser Analyse, nicht ihr Ausgangspunkt.
[QUERVERWEIS: Enterprise Storage Grundlagen]
Quellen
National Institute of Standards and Technology (NIST): Mell, P.; Grance, T.: The NIST Definition of Cloud Computing. NIST Special Publication 800-145, September 2011. DOI 10.6028/NIST.SP.800-145. https://doi.org/10.6028/NIST.SP.800-145
National Institute of Standards and Technology (NIST): Liu, F.; Tong, J.; Mao, J.; Bohn, R.; Messina, J.; Badger, L.; Leaf, D.: NIST Cloud Computing Reference Architecture. NIST Special Publication 500-292, September 2011. DOI 10.6028/NIST.SP.500-292. https://doi.org/10.6028/NIST.SP.500-292
ISO/IEC: ISO/IEC 22123-1:2023 – Information technology — Cloud computing — Part 1: Vocabulary. Edition 2, Februar 2023. ISO/IEC JTC 1/SC 38. Ersetzt ISO/IEC 17788:2014 und ISO/IEC 22123-1:2021. https://www.iso.org/standard/82758.html
ISO/IEC: ISO/IEC 22123-2:2023 – Information technology — Cloud computing — Part 2: Concepts. Edition 1, 2023. ISO/IEC JTC 1/SC 38. https://www.iso.org/standard/80351.html
Europäische Union: Verordnung (EU) 2023/2854 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung (Data Act). Amtsblatt der Europäischen Union, 22. Dezember 2023. Hier insbesondere Artikel 29 (schrittweiser Wegfall der Wechselentgelte) und Artikel 34 Absatz 2 (Datenausleitungskosten bei parallelem Betrieb).
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
