Globale AWS-Infrastruktur: Regionen, Availability-Zonen und Edge-Standorte verstehen

Letztere fungieren als Cache-Locations für das AWS-eigene Content-Delivery-Netzwerk CloudFront. Sie hosten zu diesem Zweck nur diesen einen Service, sowie Route 53, den DNS-Dienst von AWS. Derzeit existieren 18 Regionen, verteilt auf 55 Availability-Zonen und ca. 105 Edge-Standorte.

In Europa gibt es aktuell die 4 Regionen Dublin, London, Frankfurt und Paris mit einer unter­schiedlichen Anzahl von Availability-Zonen. In Frankfurt sind es drei. Lediglich in Afrika, Grönland und Russland ist AWS nicht mit eigenen Regionen vertreten. Jeglicher Traffic innerhalb einer Region fließt  über AWS-eigene Netzwerke.

AWS-eigenes Netzwerk zwischen den AZs

So garantiert AWS auf Basis seiner eigenen Glasfaser­ver­bindungen für die Latenz der Availability-Zonen unter­einander einen Wert von 1 bis 2 ms. Damit können Nutzer auf einfache Weise hochver­fügbare Setups auch für solche Kompo­nenten realisieren, bei denen es eine AWS-eigene Hochver­fügbarkeit nicht gibt. Das gilt etwa für Web-Server oder Datenbanken auf Basis eigener virtueller Maschinen.

Intern verteilt sich jede Availability-Zone je nach Größe auf 2 bis 6  Datacenter mit einer Latenz < 0,25 ms. Jedes Datacenter ist mit 50.000 bis 80.000 Commodity-Servern bestückt. Kein Rechenzentrum ist "cold", und entsprechend hosten sie immer Kunden-Kapazität. Dabei halten sie aber auch eine gewisse Über­kapazität vor, um Kunden­anfragen jeden Umfangs jederzeit bedienen zu können.

Replikation innerhalb von Regionen

AWS nutzt die verteilte Infrastruktur aus Datacenter und AZs für die interne Replikation und realisiert so die jeweils garantierte Verfügbarkeit von Diensten mit eingebauter Verfüg­barkeit, beispielsweise für S3 oder ELB (Elastic Load Balancing).

AWS repliziert niemals Ressourcen ohne Wissen oder Einver­ständnis des Kunden aus einer be­stimmten Region heraus, es sei denn, dieser tut dies explizit selbst, wie etwa beim Kopieren eines Snapshots oder AMIs in eine andere Region.

Verfügbarkeitszonen als kleinste Einheiten

Der Kunde kommt allerdings an ein bestimmtes Datacenter logisch nicht heran. Die kleinste Entität, die der Nutzer bei der Provisionierung einer Ressource wie einer virtuellen Maschine wählen kann, ist die Availability-Zone.

Stellt man beispiels­weise eine virtuelle Maschine bereit, dann muss sich der Nutzer nach der Wahl der Region für ein Subnetz in der gewünschten Availability-Zone entscheiden. So hört die Region Frankfurt beispielsweise auf den AWS-Namen eu-central-1, und die erste Verfügbar­keitszone dort heißt eu-central-1a.

Availability-Zonen dürfen untereinander  keine sich überlappenden Sicherheits­profile aufweisen, sie verfügen also über eine jeweils eigene Strom­versorgung und Internet-Anbindung. Außerdem stehen sie nie auf der gleichen Erdbeben- oder Über­schwemmungs­zone.

Wahl der Region

Vor der Wahl von Virtual Private Clouds (VPCs) und Subnetzen (AZ) steht die Auswahl der "richtigen" Region. Dazu eines vorab: Nicht alle AWS-Services haben einen regionalen Bezug. Einige Dienste wie IAM oder Route 53 sind global.

In der Regel bietet AWS aber zur Reduzierung der Datenlatenz für die weitaus meisten AWS-Dienste regionale Endpunkte an. Ein solcher ist immer eine URL, die als Eintrittspunkt für einen Web-Service fungiert. Zum Beispiel ist https://dynamodb.eu-central-1.amazonaws.com ein Endpunkt für den Service Amazon DynamoDB.

Einige Services wie IAM unterstützen aber wie gesagt keine Regionen, so dass die zugehörigen Endpunkte auch keine Region beinhalten. Unterstützt ein Service Regionen, dann sind aber auf jeden Fall alle Ressourcen in den jeweiligen Regionen unab­hängig voneinander.

Erstellt man etwa eine Amazon EC2-Instance in der Region Frankfurt, dann ist sie unabhängig von den Instanzen in einer anderen Region. Die Entscheidung für eine Region sollte dabei immer aufgrund einer der 4 Kriterien Datenschutz, Verfügbarkeit, Kosten oder Latenz (Daten zu Benutzer, Daten zur Compute-Kapazität) erfolgen:

1. Datenschutz: Dazu stellt man sich zum Beispiel folgende Fragen: Erfüllt die gewünschte Region die Datenhoheit und die Compliance-Anforderungen der eigenen geplanten Anwendung oder genügt sie den Datenschutz­gesetzen des Landes und der Region, in der die Daten gespeichert werden sollen?
   Dazu muss man wissen, dass die die Daten eines AWS-Nutzers (oder seiner Kunden) den Gesetzen des Landes und der Region unterliegen, in der sie gespeichert sind. Darüber hinaus schreiben einige Gesetze zwingend vor, dass Daten nirgendwo anders gespeichert sein dürfen, wenn das eigene Unter­nehmen zu einer bestimmten Branche mit besonderen Compliance-Standards gehört.
   Die weitaus meisten deutschen AWS-Nutzer treffen ihre Entscheidung für die Region Frankfurt aufgrund von Datenschutz­erwägungen und können daher sicher sein, dass ihre Daten immer und ausschließlich dort verarbeitet werden.

2. Dienst­verfügbarkeit: Da AWS seine globale Infrastruktur sukzessive aufbaut, ist ein neuer Dienst nicht gleich in jeder Region zu jeder Zeit verfügbar. Die Tabelle der Regionen gibt darüber Auskunft. Da beispielsweise in Europa die Region Irland die erste war, bietet sie die meisten Dienste.
   Nicht immer ist aber das Alter einer Region maßgeblich für die Bereit­stellung von neuen Diensten durch AWS. So wird beispiels­weise die Region China auch in Zukunft nicht alle Services erhalten, und zwar aufgrund der dortigen rechtlichen Bestimmungen
3. Das dritte Kriterium sind die Service-Kosten. Diese variieren von Region zu Region, werden aber immer in USD berechnet, weil AWS das Währungsrisiko nicht übernimmt.
4. Latenz: Diese betrifft beispiels­weise jene der Daten zum Endbenutzer oder zu den Berechnungs­ressourcen. So sind verschiedene hybride Nutzungs­szenarien im Kontext von AWS denkbar. Beim Hosten von Web-Anwendungen zählt zwar in erster Linie die Latenz zum Endbenutzer, jedoch hängt es auch hier im Detail von der Architektur der Anwendung ab (Load Balancer, Content Delivery), wo diese entsteht.

4. Global aufgestellte Unternehmen nutzen auch häufig die Routing-Policy latenzbasiertes Routing im Route 53, um einen globalen DNS-Failover zu realisieren. In jeden Fall kann man mit Hilfe des AWS-Dienstes Cloudping jederzeit die Verfüg­barkeit und Latenz der jeweiligen Regionen von eigenen Standort aus prüfen.