

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# AWS-Infrastruktur
<a name="aws-infrastructure"></a>

 Dieser Abschnitt enthält eine Zusammenfassung der AWS globalen Infrastruktur und der Grenzen der Fehlerisolierung, die sie bereitstellt. Darüber hinaus bietet dieser Abschnitt einen Überblick über das Konzept der Steuerebenen und Datenebenen, die entscheidende Unterschiede bei der AWS Gestaltung seiner Services sind. Diese Informationen bieten eine Grundlage, um zu verstehen, wie die Grenzen der Fehlerisolierung und die Steuerebene und die Datenebene eines Services auf die AWS Servicetypen angewendet werden, die wir im nächsten Abschnitt besprechen. 

**Topics**
+ [Availability Zones](availability-zones.md)
+ [Regionen](regions.md)
+ [AWS Lokale Zonen](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [Points of Presence](points-of-presence.md)
+ [Partitionen](partitions.md)
+ [Steuerebenen und Datenebenen](control-planes-and-data-planes.md)
+ [Statische Stabilität](static-stability.md)
+ [Übersicht](summary.md)

# Availability Zones
<a name="availability-zones"></a>

 AWS arbeitet über 100 Availability Zones in mehreren -Regionen weltweit (aktuelle Nummern finden Sie hier: [AWS Globale Infrastruktur).](https://aws.amazon.com/about-aws/global-infrastructure/) Eine Availability Zone ist ein oder mehrere diskrete Rechenzentren mit unabhängiger und redundanter Strominfrastruktur, Netzwerk und Konnektivität in einem AWS-Region. Availability Zones in einer Region sind deutlich voneinander entfernt, bis zu 60 Fuß (\$1100 km), um korrelierte Ausfälle zu vermeiden, aber nahe genug, um die synchrone Replikation mit Latenz im einstelligen Millisekundenbereich zu verwenden. Sie sind so konzipiert, dass sie nicht gleichzeitig von einem Szenario mit gemeinsam genutztem Kabel wie Netzstrom, Wasserunterbrechung, Glasfaserisolierung, Erdbeben, Bränden, Tornados oder Überflutungen betroffen sind. Häufige Fehlerquellen, wie Generatoren und Schutzausrüstung, werden nicht über Availability Zones hinweg gemeinsam genutzt und sind für die Bereitstellung durch unabhängige Stromunterstations konzipiert. Wenn Updates für seine Services AWS bereitstellt, werden Bereitstellungen in Availability Zones in derselben Region zeitlich getrennt, um korrelierte Ausfälle zu vermeiden. 

 Alle Availability Zones in einer Region sind mit Netzwerken mit hoher Bandbreite und niedriger Latenz über vollständig redundante, dedizierte -Metro-Glasfaser miteinander verbunden. Jede Availability Zone in einer Region stellt über zwei Transitzentren eine Verbindung zum Internet her, in denen AWS Peers mit mehreren [Tier-1-Internetanbietern](https://en.wikipedia.org/wiki/Tier_1_network) verbunden sind (weitere Informationen finden Sie unter [Übersicht über Amazon Web Services](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card)).** 

 Diese Funktionen bieten eine starke Isolation der Availability Zones voneinander, was wir als Availability Zone Independence (A Bol) bezeichnen. Das logische Konstrukt von Availability Zones und ihre Konnektivität zum Internet ist in der folgenden Abbildung dargestellt. 

![\[Dieses Image zeigt, wie Availability Zones aus einem oder mehreren physischen Rechenzentren bestehen, die redundant miteinander und mit dem Internet verbunden sind.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)


# Regionen
<a name="regions"></a>

 Jede besteht AWS-Region aus mehreren unabhängigen und physisch separaten Availability Zones innerhalb eines geografischen Gebiets. Alle Regionen verfügen derzeit über drei oder mehr Availability Zones. Die Regionen selbst sind isoliert und unabhängig von anderen Regionen, mit einigen Ausnahmen, die später in diesem Dokument erwähnt werden [(siehe Globale Einzelregionsoperationen).](global-services.md#global-single-region-operations) Diese Trennung zwischen Regionen beschränkt Servicefehler auf eine einzelne Region, wenn sie auftreten. Der normale Betrieb anderer Regionen bleibt in diesem Fall davon unberührt. Darüber hinaus sind die Ressourcen und Daten, die Sie in einer Region erstellen, in keiner anderen Region vorhanden, es sei denn, Sie verwenden explizit eine Replikations- oder Kopierfunktion, die von einem -AWSService angeboten wird, oder replizieren die Ressource selbst. 

![\[Dieses Image veranschaulicht die aktuellen und geplanten AWS-Regionen ab Dezember 2022.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)


# AWS Lokale Zonen
<a name="aws-local-zones"></a>

 [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) sind eine Art der Infrastrukturbereitstellung, bei der Datenverarbeitungs-, Speicher-, Datenbank- und andere [ausgewählte -AWSServices](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) in der Nähe großer Populations- und Industriezentren platziert werden. Sie können -AWSServices wie Datenverarbeitungs- und Speicherservices in der Local Zone verwenden, um Anwendungen mit niedriger Latenz am Edge auszuführen oder Hybrid-Cloud-Migrationen zu vereinfachen. Local Zones verfügen über lokales Internet, um die Latenz zu reduzieren, sind aber auch über das redundante private Netzwerk von Amazon mit hoher Bandbreite mit ihrer übergeordneten Region verbunden, sodass Anwendungen, die in AWS Local Zones ausgeführt werden, schnell, sicher und nahtlos auf das gesamte Spektrum an -Services zugreifen können. 

# AWS Outposts
<a name="aws-outposts"></a>

 [AWS Outposts](https://aws.amazon.com/outposts/) ist eine Familie von vollständig verwalteten Lösungen, die AWS Infrastruktur und Services für praktisch jeden On-Premises- oder Edge-Standort für ein wirklich konsistentes Hybrid-Erlebnis bereitstellen. Outposts-Lösungen ermöglichen es Ihnen, native AWS Services On-Premises zu erweitern und auszuführen und sind in einer Vielzahl von Formfaktoren verfügbar, von 1U- und 2U-Outposts-Servern bis hin zu 42U-Outposts-Racks und mehreren Rack-Bereitstellungen. 

 Mit können Sie [ausgewählte -AWSServices](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services) lokal ausführen und eine Verbindung zu einer Vielzahl von Services herstellenAWS Outposts, die in der übergeordneten verfügbar sindAWS-Region. AWS Outposts sind vollständig verwaltete und konfigurierbare RechenAWS- und Speicher-Racks, die mit von entwickelter Hardware erstellt wurden, die es Kunden ermöglicht, Rechenleistung und Speicher On-Premises auszuführen und gleichzeitig nahtlos eine Verbindung mit AWSder breiten Palette von Services in der Cloud herzustellen. 

# Points of Presence
<a name="points-of-presence"></a>

 Zusätzlich zu den Availability Zones AWS-Regionen und betreibt AWS auch ein global verteiltes Point of Presence (PoP)-Netzwerk. Diese PoPs hosten Amazon CloudFront, ein Content Delivery Network (CDN), Amazon Route 53, einen öffentlichen Domain Name System (DNS)-Auflösungsservice, und AWS Global Accelerator (AGA), einen Edge-Netzwerkoptimierungsservice. Das globale Edge-Netzwerk besteht derzeit aus über 410 PoPs, darunter mehr als 400 Edge-Standorte, und 13 regionalen Zwischenspeichern der mittleren Ebene in über 90 Städten in 48 Ländern (der aktuelle Status finden Sie hier: [Amazon CloudFront Key Features ](https://aws.amazon.com/cloudfront/features/)). 

![\[Dieses Bild zeigt das CloudFront globale Edge-Netzwerk von Amazon\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)


 Jeder PoP ist von den anderen isoliert, was bedeutet, dass ein Fehler, der sich auf einen einzelnen PoP- oder metropolitanen Gebiet auswirkt, sich nicht auf den Rest des globalen Netzwerks auswirkt. Die AWS Netzwerk-Peers mit Tausenden von Tier-1/2/3-Telekommunikationsanbietern weltweit sind gut mit allen wichtigen Zugriffsnetzwerken verbunden, um eine optimale Leistung zu erzielen, und verfügen über Hunderte von Terabit an bereitgestellter Kapazität. Edge-Standorte sind AWS-Regionen über das AWS Netzwerk-Backbone, eine vollständig redundante, mehrere 100GbE-Parallelfaser, die die Welt umkreist und mit Zehntausenden von Netzwerken verknüpft ist, um Ursprungsabrufe und dynamische Inhaltsbeschleunigung zu verbessern. 

# Partitionen
<a name="partitions"></a>

 AWS gruppiert Regionen in [Partitionen ](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Jede -Region befindet sich genau in einer -Partition, und jede Partition hat eine oder mehrere Regionen. Partitionen haben unabhängige Instances von AWS Identity and Access Management (IAM) und bieten eine feste Grenze zwischen Regionen in verschiedenen Partitionen. AWS kommerzielle Regionen befinden sich in der -`aws`Partition, Regionen in China sind in der -`aws-cn`Partition und AWS GovCloud Regionen sind in der -`aws-us-gov`Partition. Einige -AWSServices sind so konzipiert, dass sie regionsübergreifende Funktionen bieten, z. B. [regionsübergreifende Replikation in Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario) oder [AWS regionsübergreifendes Transit-Gateway-Peering](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html). Diese Arten von Funktionen werden nur zwischen Regionen in derselben Partition unterstützt. Sie können keine IAM-Anmeldeinformationen von einer Partition verwenden, um mit Ressourcen in einer anderen Partition zu interagieren. 

# Steuerebenen und Datenebenen
<a name="control-planes-and-data-planes"></a>

 AWS unterteilt die meisten Services in die Konzepte der *Steuerebene* und der *Datenebene *. Diese Begriffe stammen aus der Welt des Netzwerks, insbesondere aus Routern. Die Datenebene des Routers, bei der es sich um ihre Hauptfunktionalität handelt, verschiebt Pakete basierend auf Regeln. Die Routing-Richtlinien müssen jedoch von irgendwo aus erstellt und verteilt werden, und dort kommt die Steuerebene ein. 

 Steuerebenen stellen die administrativen APIs bereit, die zum Erstellen, Lesen/Beschreiben, Aktualisieren, Löschen und Auflisten (CRUDL) von Ressourcen verwendet werden. Im Folgenden finden Sie beispielsweise alle Aktionen auf Steuerebene: Starten einer neuen [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2)-Instance, Erstellen eines [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3)-Buckets und Beschreiben einer [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) (Amazon SQS)-Warteschlange. Wenn Sie eine EC2-Instance starten, muss die Steuerebene mehrere Aufgaben ausführen, z. B. das Auffinden eines physischen Hosts mit Kapazität, das Zuweisen der Netzwerkschnittstelle(n), das Vorbereiten eines [Amazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS)-Volumes, das Generieren von IAM-Anmeldeinformationen, das Hinzufügen der Sicherheitsgruppenregeln und vieles mehr. Steuerebenen sind in der Regel komplizierte Orchestrierungs- und Aggregationssysteme. 

 Die Datenebene stellt die primäre Funktion des Services bereit. Im Folgenden sind beispielsweise alle Teile der Datenebene für jeden der beteiligten Services aufgeführt: die laufende EC2-Instance selbst, das Lesen und Schreiben auf ein EBS-Volume, das Abrufen und Einfügen von Objekten in einen S3-Bucket und Route 53, das DNS-Abfragen beantwortet und Zustandsprüfungen durchführt. 

 Datenebenen sind absichtlich weniger kompliziert, mit weniger sich bewegenden Teilen als Steuerebenen, die normalerweise ein komplexes System von Workflows, Geschäftslogik und Datenbanken implementieren. Dadurch ist es statistisch weniger wahrscheinlich, dass Fehlerereignisse auf der Datenebene als auf der Steuerebene auftreten. Während sowohl die Daten- als auch die Steuerebene zum Gesamtbetrieb und Erfolg des Services beitragen, AWS betrachtet sie als unterschiedliche Komponenten. Diese Trennung hat sowohl Leistungs- als auch Verfügbarkeitsvorteile. 

# Statische Stabilität
<a name="static-stability"></a>

 Eines der wichtigsten Resilienzmerkmale von AWS Services ist die AWS statische Stabilität. Dieser Begriff bedeutet, dass Systeme in einem statischen Zustand betrieben werden und weiterhin normal funktionieren, ohne dass Änderungen während des Ausfalls oder der Nichtverfügbarkeit von Abhängigkeiten vorgenommen werden müssen. Eine Möglichkeit hierfür besteht darin, Zirkelbezüge in unseren Services zu verhindern, die verhindern könnten, dass einer dieser Services erfolgreich wiederhergestellt wird. Eine andere Möglichkeit, dies zu tun, besteht darin, den vorhandenen Status beizubehalten. Wir berücksichtigen die Tatsache, dass Steuerebenen statistisch wahrscheinlicher fehlschlagen als Datenebenen. Obwohl die Datenebene in der Regel von Daten abhängt, die von der Steuerebene kommen, behält die Datenebene ihren vorhandenen Zustand bei und funktioniert auch bei Beeinträchtigung der Steuerebene. Der Zugriff auf Ressourcen auf Datenebene, sobald er bereitgestellt wurde, ist nicht von der Steuerebene abhängig und ist daher nicht von einer Beeinträchtigung der Steuerebene betroffen. Mit anderen Worten, auch wenn die Fähigkeit zum Erstellen, Ändern oder Löschen von Ressourcen beeinträchtigt ist, bleiben vorhandene Ressourcen verfügbar. Dadurch sind AWS Datenebenen statisch stabil für eine Beeinträchtigung auf der Steuerebene. Sie können verschiedene Muster implementieren, um bei verschiedenen Arten von Abhängigkeitsfehlern statisch stabil zu sein. 

 Ein Beispiel für statische Stabilität finden Sie in Amazon EC2. Sobald eine EC2-Instance gestartet wurde, ist sie genauso verfügbar wie der physische Server in einem Rechenzentrum. Es ist nicht von APIs der Steuerebene abhängig, um weiter ausgeführt zu werden oder nach einem Neustart wieder ausgeführt zu werden. Die gleiche Eigenschaft gilt für andere AWS Ressourcen wie VPCs, Amazon-S3-Buckets und -Objekte sowie Amazon-EBS-Volumes. Amazon S3 

 Statische Stabilität ist ein Konzept, das bei der AWS Gestaltung seiner Services tief verwurzelt ist, aber es ist auch ein Muster, das von Kunden verwendet werden kann. Tatsächlich besteht ein Großteil der bewährten Methoden für die ausfallsichere Verwendung der verschiedenen Arten von AWS Services darin, statische Stabilität für Produktionsumgebungen zu implementieren. Die zuverlässigsten Wiederherstellungs- und Abschwächungsmechanismen sind diejenigen, die die wenigsten Änderungen erfordern, um eine Wiederherstellung zu erreichen. Anstatt sich darauf zu verlassen, dass die EC2-Steuerebene neue EC2-Instances startet, um sich von einer ausgefallenen Availability Zone zu erholen, trägt die Vorabbereitstellung dieser zusätzlichen Kapazität dazu bei, eine statische Stabilität zu erreichen. Daher trägt die Beseitigung von Abhängigkeiten von Steuerebenen (den APIs, die Änderungen an Ressourcen implementieren) in Ihrem Wiederherstellungspfad zu ausfallsichereren Workloads bei. Weitere Informationen zur statischen Stabilität, zu Steuerebenen und zu Datenebenen finden Sie im [ArtikelStatische Stabilität der Amazon Builders' Library mit Availability Zones ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones). 

# Übersicht
<a name="summary"></a>

 AWS verwendet verschiedene Fehlercontainer in unserer Infrastruktur, um eine Fehlerisolierung zu erstellen. Die Kerninfrastruktur-Fehlercontainer sind Partitionen, Regionen, Availability Zones, Steuerebenen und Datenebenen. Als Nächstes untersuchen wir verschiedene Arten von AWS Services, wie diese Fehlercontainer in ihrem Design verwendet werden und wie Sie Workloads mit ihnen so gestalten sollten, dass sie ausfallsicher sind. 