Für jede AWS-Workload muss festgelegt werden, wo Benutzer, Daten und Fehlergrenzen (Fault Boundaries) angesiedelt sind.
In diesem Kurs erfahren wir, wie sich AWS-Standorte auf Latenz, Resilienz, Compliance und hybride Konnektivität auswirken.
Wir entwickeln ein mentales Modell, das bei der größten Grenze beginnt und schrittweise zu kleineren Ebenen übergeht.
Zudem verfolgen wir durchgehend das Beispiel einer kleinen Workload, um die Abwägungen bei der Standortwahl konkret zu veranschaulichen.
Unter Platzierung (Placement) versteht man die Entscheidung, in welcher AWS-Standortgrenze eine Workload-Komponente oder deren Daten gehostet werden.
Diese Entscheidung beeinflusst die Netzwerkdistanz, die Rechtsordnung (Jurisdiktion) und den Auswirkungsradius (Blast Radius) von Fehlern.
Die Latenz wird durch die physische Entfernung und die Anzahl der Netzwerksprünge (Hops) zwischen Benutzern und der Workload bestimmt.
Die Fehlerisolierung hängt davon ab, welche Komponenten dieselbe physische und betriebliche Grenze teilen.
Vorgaben zum Datenstandort (Residency Constraints) schränken ein, wo Daten gespeichert und verarbeitet werden dürfen, was die Auswahl der Regionen einschränken kann.
Hybride Anforderungen können eine lokale Verarbeitung in Unternehmensnähe oder eine berechenbare Konnektivität zurück zu AWS erfordern.
Betrachten wir nun die wichtigsten Standortebenen, die wir im Verlauf dieses Kurses verwenden werden.
Ein AWS-Konto ist eine Sicherheits- und Abrechnungsgrenze, der Ressourcen und Identitäten zugeordnet sind.
Kontogrenzen sind wichtig, da Zugriffssteuerungen und Audit-Nachweise auf Kontoebene ausgewertet werden.
Eine AWS-Region ist ein eigenständiges geografisches Gebiet, in dem AWS Infrastruktur bündelt.
Regionen sind so konzipiert, dass sie zur Gewährleistung der Fehlertoleranz von anderen Regionen isoliert sind.
Die meisten AWS-Dienste erstellen regionale Ressourcen, die nur in der ausgewählten Region existieren.
Die Replikation über Regionen hinweg ist dienstspezifisch; AWS repliziert nicht automatisch alle Daten.
Eine Availability Zone (Verfügbarkeitszone) ist ein isolierter Standort innerhalb einer Region.
Jede Availability Zone besteht aus einem oder mehreren eigenständigen Rechenzentren in getrennten Einrichtungen.
Availability Zones innerhalb einer Region sind über ein redundantes Netzwerk mit geringer Latenz und hoher Bandbreite miteinander verbunden.
Es gilt als bewährte Methode, produktive Workloads zur Erhöhung der Verfügbarkeit über mehrere Availability Zones hinweg zu betreiben.
Ein Endpunkt ist der Netzwerkzugangspunkt, an den wir API-Anfragen für einen Dienst innerhalb eines bestimmten Bereichs (Scope) senden.
Die Auswahl einer Region in den verwendeten Tools führt oft dazu, dass ein regionaler Endpunkt für die API des jeweiligen Dienstes gewählt wird.
Die Control Plane (Steuerungsebene) ist der Teil eines Dienstes, der Ressourcen erstellt und konfiguriert.
Die Datenebene (Data Plane) ist der Teil eines Dienstes, der den Laufzeit-Datenverkehr und Datenoperationen abwickelt.
Diese Ebenen können unterschiedliche Fehlermodi aufweisen; daher müssen wir jede einzelne anhand geeigneter Nachweise überprüfen.
Arbeitsannahme Wir betrachten Region und Availability Zone (Verfügbarkeitszone) als die Standardgrenzen für die Fehlerisolierung, sofern nicht anders angegeben.
Wir verwenden eine einfache globale Webanwendung als Grundlage für unsere Entscheidungen.
Die Anwendung verwaltet Benutzerprofile, die auch bei Infrastrukturausfällen verfügbar bleiben müssen.
Zudem stellt die Anwendung Medieninhalte bereit, die von einer räumlichen Nähe zu den Endbenutzern profitieren.
Dieses Szenario ermöglicht es uns, bei der Betrachtung der einzelnen Grenzen stets dieselbe Frage zu stellen:
Wo sollten die für den Benutzer sichtbaren Bereitstellungskomponenten und wo die dauerhaften Profildaten angesiedelt sein – unter Berücksichtigung der Anforderungen an Latenz und Fehlerisolierung?
Lassen Sie uns die Workload-Komponenten im Kontext der soeben definierten Standortebenen visualisieren.