Applikationen in der AWS Cloud brauchen meist einen Zugang zum Internet. Wie sollten wir auch sonst einen Webserver oder ein API erreichen? Bei nachgelagerten Services, etwa Datenbanken oder Redis Caches, soll zudem sichergestellt werden, dass diese nicht direkt aus dem Internet für jedermann erreichbar sind. Hier kommen sogenannte „Private Subnets“ ins Spiel. Wie der Name erahnen läßt, sind diese Netze besonders geschützt und nicht direkt über Routing mit der Welt verbunden.
Wir bezeichnen ein AWS VPC (“Virtual Private Cloud”) gern auch als virtuelles Rechenzentrum. Hier finden sich neben der notwendigen Netzwerkinfrastruktur auch die Routingtabellen, die Gateways und natürlich auch unsere Loadbalancer, Datenbanken und Applikationen.
Welche Netze gibt es überhaupt?
Öffentliche („Public“) Netze stellen Applikationen oder Services direkt oder über Loadbalancer bereit. Beispiele hierfür sind EC2 Instances, Application Loadbalancer und API Gateways.
Nicht-öffentliche („Private“) Netze beherbergen Server oder Services, die wir besonders schützen wollen. Beispiele hierfür sind MySQL-Datenbanken, Fileserver und Kubernetes Cluster Nodes. Da es keinen direkten Routing-Weg vom und ins Internet gibt, müssen wir genau planen, wie wir diese Dienste erreichen können. Ein typisches Szenario zeigt folgendes Bild:
Hier gelangt User Traffic nur über den Loadbalancer zu den „dahinterliegenden“ Webservern. Und auch unsere Datenbank, die von den Webservern benötigt wird, ist im „private subnet“ extra geschützt.
Die “Intra Subnets” bilden eine Sonderform der “Private Subnets”: hierbei ist überhaupt nicht vorgesehen, dass Traffic das VPC verläßt. Es geht sprichwörtlich nichts rein und nichts raus. Ein typischer Anwendungsfall sind Lambda Functions, die nur VPC-intern ihre Aufgaben erledigen und maximal auf andere Amazon-Dienste zugreifen müssen (Spoiler: dafür braucht es nicht einmal ein NAT Gateway – doch später dazu mehr).
Wo liegt nun überhaupt das Problem?
Stellt euch vor, ihr plant alles richtig und setzt eure Infrastruktur nach dem bekannten “Three Tier Application”-Prinzip um: eure Webserver landen selbstverständlich aus Sicherheitsgründen in privaten Subnetzen und haben somit auch keinen direkten Draht ins Internet.
Linux Package Updates? Fehlanzeige. Testweise ein fremdes API per HTTPS ansprechen? Ebenfalls nicht möglich. Das Standard-Routing innerhalb eines VPC verbietet die direkte Konnektivität.
NAT Gateways to the Rescue!
Während Services in öffentlichen Netzen über das sogenannte Internet Gateway Zugriff nach draussen erhalten, lösen NAT Gateways auf der anderen Seite dieses Verbindungsproblem. Mit $0,052 pro NAT-Gateway-Stunde sowie $0,052 pro verarbeiteten Daten (Gigabyte) haben wir einen nicht gerade günstigen Service am Start: Rund $38 pro Monat und NAT Gateway – ohne Daten inbegriffen. Die Amazon-Website verrät ferner im Detail:
Falls Sie sich dafür entscheiden, ein NAT-Gateway in Ihrer VPC zu erstellen, wird Ihnen jede „NAT-Gateway-Stunde“ in Rechnung gestellt, für die Ihr Gateway bereitgestellt wird und verfügbar ist. Für jedes Gigabyte an Daten, die durch das NAT-Gateway verarbeitet werden, fallen Datenverarbeitungsgebühren an, unabhängig von Quelle oder Ziel der Datenübertragung. Angebrochene NAT-Gateway-Stunden werden als volle Stunden abgerechnet. Sie übernehmen zudem alle Kosten im Zusammenhang mit dem AWS-Datentransfer für alle über das NAT-Gateway transferierten Daten. Wenn Sie nicht mehr länger für ein NAT-Gateway zahlen möchten, können Sie das NAT-Gateway einfach über die AWS-Managementkonsole, die Befehlszeilen-Schnittstelle oder die API löschen.
Zu beachten gilt: Preise sind – wie häufig – regional leicht verschieden!
Verschiedene Szenarien
Im Folgenden wollen wir einige Szenarien genauer betrachten.
Single NAT Gateway pro Subnet
Daumen hoch für hochverfügbare Anwendungen; aber Achtung bei den Kosten: bei 3 Subnets haben wir eine stattliche monatliche Rechnung von über $100 – nur für die NAT Gateways und ohne etwaigen Datentransfer.
Single NAT Gateway pro AZ
Auch hier erfüllen wir die Hochverfügbarkeitskriterien und steigern die Kosten. Achtung: die Anzahl der Subnets pro AZ kann >= 1 sein!
Ein VPC & ein NAT Gateway
Was kann schon schiefgehen? Wenn wir lediglich ein NAT Gateway in einer Availability Zone (“AZ”) konfigurieren, haben wir zumindest in Teilen kein wirklich hochverfügbares Netzwerk. Fällt die Zone temporär aus oder sollte es Performance-Engpässe geben, funktioniert ausgehender Datenverkehr nicht.
Dieses Setup sollte man also z. B. für unkritische Umgebungen wie etwa Staging-Systeme wählen. Und bei 3 AZs einer Region: statt 3 zahlt man auch nur 1 NAT Gateway!
Einmal „Routing Speciale“, bitte!
Serverless mit AWS Lambda Functions ist eine feine Sache. Sollte eure Applikation nur innerhalb von AWS auf Dienste zugreifen müssen, könnt ihr euch an dieser Stelle ein NAT Gateway möglicherweise komplett sparen. VPC Endpoints sind dann das Mittel der Wahl: für S3 und DynamoDB in der selben Region nutzt ihr die sogenannten Gateway Endpoints ohne zusätzliche Gebühren.
Eine Alternative: VPC Endpoints
VPC Endpoints ermöglichen eine interne (“private”) Verbindung zwischen eurer Applikation hin zu verschiedenen AWS Services. Dabei entfällt der manchmal unnötige Routing-Umweg über das Internet.
Hier für euch die wichtigsten Unterschiede zwischen Gateway- und Interface Endpoints:
Interface Endpoints
- Wird von vielen AWS-eigenen Diensten sowie AWS-Marketplace-Partnern unterstützt
- Basiert auf AWS PrivateLink
- Nutzt eine (private) IP-Adresse
- Traffic von on-premises-Diensten möglich
- Inter-Regions Routing möglich via VPC Peering und Transit Gateway
- Zusätzliche Kosten fallen an
- Zuweisung auf Subnet-Level
Gateway Endpoints
- Nur S3 und DynamoDB
- Kein virtuelles Netzwerk Interface (“ENI”) nötig
- Nur innerhalb einer Region möglich
- Innerhalb des gleichen VPC
- Kostenlos
- Um das Traffic Routing kümmert sich der eigentliche AWS-Service
Key Takeaways
Wenn ihr etwas aus diesem Beitrag mitnehmt, dann sollten es diese vier Key Takeaways sein:
- Analysiert und versteht euren Datenverkehr! Wir wissen, dass dieser Punkt gerade zu Beginn super schwer ist. Hilfreich sind hierbei zusätzliche Dienste wie VPC FlowLogs und CloudWatch Logs.
- Plant die künftige Infrastruktur genau und lasst eure Zielarchitektur von einer dritten Partei gegenchecken.
- Wägt zwischen NAT Gateway und/oder VPC Endpoints ab: wenn eure Applikation intern “nur” mit S3 oder DynamoDB kommunizieren muss, sind kostenlose Gateway Endpoints eine schlaue Alternative zum NAT Gateway.
- Ermittelt die benötigte Verfügbarkeitsanforderung: für Umgebungen, die keinen strikten Anforderungen hinsichtlich “High Availability” unterliegen aber dennoch auf die Funktion eines NAT Gateways angewiesen sind, reicht meist ein einziges NAT Gateway pro VPC. Beispiel: eine Staging-Umgebung.
Zum Schluß verweisen wir wie so oft gern auf die Nutzung von Infrastructure as Code, z. B. mit HashiCorp Terraform. Es existieren fertige und weit verbreitete Module, die euch beim Aufbau einer so komplexen Sache wie einem VPC unter die Arme greifen:
- Terraform Modul für VPC
- Beispiel Modul für die Aktivierung der VPC Flowlogs
- Terraform Modul mit Beispielen für VPC Endpoints
Und ganz zum Schluss dann noch eine Kleinigkeit, aber die habt ihr bestimmt auch schon gelesen: Terraform Code läßt sich jetzt noch besser testen!
Just one more thing …
Wir versorgen euch regelmässig mit Neuigkeiten sowie Tipps & Tricks aus dem AWS-Universum. Hier eine kleine Auswahl der letzten Themen:
Schreibe einen Kommentar