AWS NAT Gateways entzaubert

AWS NAT Gateways entzaubert – alles, was ihr wissen müsst!

Avatar von Michael Krieg

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.

Gezeichnetes Ausrufezeichen in einem Kreis, das Ausrufezeichen ist gelb ausgemalt.

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:

  1. 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.
  2. Plant die künftige Infrastruktur genau und lasst eure Zielarchitektur von einer dritten Partei gegenchecken.
  3. 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.
  4. 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:

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:

Eco & Fast: AWS Graviton4
Eco & Fast: AWS Graviton4
AWS Housekeeping 2.0
AWS Housekeeping 2.0
AWS NAT Gateways entzaubert – alles, was ihr wissen müsst!
AWS NAT Gateways entzaubert – alles, was ihr wissen müsst!
Terraform: Testen auf (und mit) AWS
Terraform: Testen auf (und mit) AWS
4 Wege, sich mit EC2 zu verbinden
4 Wege, sich mit EC2 zu verbinden
Kostenanpassungen bei AWS: S3 und IPv4
Kostenanpassungen bei AWS: S3 und IPv4
Route53 Profiles für zentrale DNS-Konfigurationen
Route53 Profiles für zentrale DNS-Konfigurationen
Amazon Web Services: Lass Dir diese 7 kostenlosen Angebote nicht entgehen
Amazon Web Services: Lass Dir diese 7 kostenlosen Angebote nicht entgehen
AWS Saving Plans, RDS-SSL-Zertifikate, EC2 G6 und mehr
AWS Saving Plans, RDS-SSL-Zertifikate, EC2 G6 und mehr
myApplications – das Dashboard für deine Cloud-Apps
myApplications – das Dashboard für deine Cloud-Apps
CDK Migrate
CDK Migrate
EKS: Kubernetes 1.29 verfügbar
EKS: Kubernetes 1.29 verfügbar
Eco & Fast: AWS Graviton4
Eco & Fast: AWS Graviton4
AWS Housekeeping 2.0
AWS Housekeeping 2.0
AWS NAT Gateways entzaubert – alles, was ihr wissen müsst!
AWS NAT Gateways entzaubert – alles, was ihr wissen müsst!
Terraform: Testen auf (und mit) AWS
Terraform: Testen auf (und mit) AWS
4 Wege, sich mit EC2 zu verbinden
4 Wege, sich mit EC2 zu verbinden
Kostenanpassungen bei AWS: S3 und IPv4
Kostenanpassungen bei AWS: S3 und IPv4
Route53 Profiles für zentrale DNS-Konfigurationen
Route53 Profiles für zentrale DNS-Konfigurationen
Amazon Web Services: Lass Dir diese 7 kostenlosen Angebote nicht entgehen
Amazon Web Services: Lass Dir diese 7 kostenlosen Angebote nicht entgehen
AWS Saving Plans, RDS-SSL-Zertifikate, EC2 G6 und mehr
AWS Saving Plans, RDS-SSL-Zertifikate, EC2 G6 und mehr
myApplications – das Dashboard für deine Cloud-Apps
myApplications – das Dashboard für deine Cloud-Apps
CDK Migrate
CDK Migrate
EKS: Kubernetes 1.29 verfügbar
EKS: Kubernetes 1.29 verfügbar
previous arrow
next arrow
Avatar von Michael Krieg

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.