NAT-Gateway-Spitzen kostengünstig per Serverless aufspüren

Unerwartete Traffic-Spitzen im Network-Address-Translation-(NAT)-Gateway-Service von AWS können schnell zur Herausforderung werden. VPC Flow Logs liefern zwar wertvolle Einblicke in den Netzwerk-Traffic, doch eine permanente Aufzeichnung verursacht unnötige Speicherkosten und produziert eine Datenflut, die im Normalbetrieb meist irrelevant ist.

Was wäre, wenn sich VPC Flow Logs gezielt nur dann aktivieren ließen, sobald ein Traffic-Anstieg erkannt wird?

Dieser Blogpost stellt eine Lösung vor, die dynamisch einen temporären VPC-Flow-Logs-Recorder anlegt, sobald ein vordefinierter Traffic-Schwellenwert überschritten wird. So bleibt die Datenspeicherung schlank und kostengünstig – und liefert dennoch die entscheidenden Informationen, um unerwartete Traffic-Muster zu untersuchen und nachzuvollziehen.

Der Einsatz von NAT Gateways verursacht Kosten. Sie zahlen für den Betrieb – in der Region North Virginia 0,045 USD pro Stunde. Hinzu kommen Kosten für das durchgeleitete Datenvolumen: 0,045 USD pro GB ein- und ausgehend. Das gilt für sämtlichen Traffic durch das NAT Gateway, auch für regionale Ressourcen wie S3.

Das summiert sich schnell. Pro TB Daten zahlen Sie:

1.024 GB x 0,045 USD = 46,08 USD

Bei 10 TB sind es bereits 460 USD.

Und so weiter.

Anlass für diesen Blogpost war eine Kundenanfrage zu unerwartetem Traffic über ein NAT Gateway, der sporadisch auf 35 TB hochschoss und pro Spitze zusätzliche, ungeplante 1.600 USD verursachte. Der Kunde hatte keine Erklärung dafür, wollte aber auch nicht den ganzen Monat über VPC Flow Logs aktivieren (warum, erklärt der Abschnitt zu den Kosten von VPC Flow Logs weiter unten).

Aus der AWS-Dokumentation, die das prägnant zusammenfasst:

VPC Flow Logs ist ein Feature, mit dem Sie Informationen über den IP-Traffic erfassen können, der zu und von Netzwerkschnittstellen in Ihrer VPC fließt. Flow-Log-Daten lassen sich an folgende Ziele veröffentlichen: Amazon CloudWatch Logs, Amazon S3 oder Amazon Data Firehose. Nach dem Anlegen eines Flow Logs können Sie die Flow-Log-Records in der konfigurierten Log-Gruppe, dem Bucket oder dem Delivery Stream abrufen und einsehen.

Flow Logs unterstützen Sie unter anderem bei folgenden Aufgaben:

\* Diagnose zu restriktiver Security-Group-Regeln

\* Überwachung des Traffics, der Ihre Instance erreicht

\* Bestimmung der Richtung des Traffics zu und von den Netzwerkschnittstellen

Flow-Log-Daten werden außerhalb des Pfads Ihres Netzwerk-Traffics erfasst und beeinflussen daher weder Durchsatz noch Latenz. Sie können Flow Logs ohne Risiko für die Netzwerkleistung anlegen oder löschen.

Dieser Blogpost und das zugehörige Repository beziehen sich auf die Aufzeichnung des Traffics und dessen Ingestion in eine festgelegte Log-Gruppe in Amazon CloudWatch Logs, in der alle Traffic-Logs gespeichert und für die Analyse verfügbar bleiben.

Aktivieren Sie VPC Flow Logs für ein NAT Gateway, haben die Logs standardmäßig folgendes Format und sind in der zugehörigen CloudWatch-Log-Gruppe einsehbar:

Typische Flow-Log-Records in CloudWatch Logs

In diesem Blogpost geht es um die Speicherung der aufgezeichneten Daten in CloudWatch-Log-Gruppen. Daher lohnt sich ein Blick auf die Kosten für die in die Logs eingespeisten Daten. Die CloudWatch-Logs-Preise finden Sie zur Referenz hier.

Angenommen, Sie betreiben 10 NAT Gateways, die jeweils 1.000 Requests pro Sekunde von Ihren Services ins Internet schicken und für jeden Request genau eine Antwort erhalten. Werden diese Daten per VPC Flow Logs aufgezeichnet, landen pro Sekunde 2.000 Records (1.000 ausgehend + 1.000 antwortend) über VPC Flow Logs in CloudWatch Logs.

Nehmen wir an, jeder Record ist 100 Byte groß (je nach Detailtiefe kann es auch weniger oder mehr sein). Pro Monat werden in CloudWatch Logs damit Records mit folgender Gesamtgröße eingespeist:

10 (NAT Gateways) X 2.000 (Records pro Sekunde) X 100 (Byte pro Record) X 86.400 (Sekunden pro Tag) X 30,5 (durchschnittliche Tage pro Monat) = 5.270.400.000.000 Byte.

Das entspricht etwa 5,2 TB pro Monat.

Die Kosten für einen Monat Ingestion ergeben sich aus dem Tarif von 0,50 USD pro GB für bis zu 10 TB:

5.200 GB * 0,50 (USD pro GB ) = 2.600 USD pro Monat (oder die Hälfte – "nur" 1.300 USD –, wenn Sie in eine CloudWatch-Logs-Gruppe der Klasse Infrequent Access ingestieren)

Nehmen wir nun an, dass die Traffic-Spitzen, die Sie erfassen möchten, nur ein- bis zweimal pro Monat auftreten, jeweils nur 15 Minuten andauern und in dieser Zeit sehr viele Daten durch das NAT Gateway schleusen.

Wichtig: Mehr Datenvolumen bedeutet nicht automatisch mehr Records im VPC Flow Log.

Nehmen Sie etwa eine 10-MB-Datei und eine 1-KB-Datei, die durch ein NAT Gateway laufen. Jede Datei erzeugt nur einen einzigen Record. Die 10-MB-Datei produziert nicht mehr Einträge als die 1-KB-Datei, obwohl sie deutlich größer ist.

Die Kosten für den NAT-Gateway-Traffic steigen aufgrund des deutlich höheren Volumens dagegen um den Faktor 10⁰⁴.

Genau diese Spitzen wollen wir erfassen, ohne einen ganzen Monat VPC-Flow-Log-Aufzeichnung bezahlen zu müssen.

Die Lösung sorgt dafür, dass VPC Flow Logs nur dann aufgezeichnet werden, wenn der Traffic eines NAT Gateways einen bestimmten Schwellenwert überschreitet. Liegt das übliche Traffic-Niveau eines NAT Gateways beispielsweise bei 10 MB pro Minute, lässt sich ein Alarm konfigurieren, der auslöst, sobald der Traffic für einen bestimmten Zeitraum 100 MB pro Minute übersteigt.

Für sehr kurze Traffic-Spitzen ist diese Lösung weniger geeignet, da die VPC Flow Logs erst nach Erkennen der Spitze erstellt werden. Die Spitze muss nicht extrem lang sein, sollte aber länger als 3 Minuten andauern, damit die Aufzeichnung tatsächlich anläuft.

Die Lösung erstellt für jedes NAT Gateway, das Sie bei der Installation angeben, einen CloudWatch-Alarm.

Diese Alarme werden über eine EventBridge-Regel erfasst, die eine Step Function auslöst.

Die Step Function ist dafür zuständig, die VPC-Flow-Log-Aufzeichnung für das NAT Gateway im Alarmzustand zu starten. Anschließend entfernt sie den Aufzeichnungsprozess, lässt die aufgezeichneten Daten aber bestehen. Am Ende der Aufzeichnung schickt SNS eine E-Mail an die bei der Installation hinterlegte Adresse.

Implementiert ist die Lösung mit AWS SAM und besteht aus zwei CloudFormation-Stacks. Der erste Stack stellt CloudFormation-Macros bereit, die das Deployment vereinfachen. Dazu gehören:

• Ein Macro, das automatisch CloudWatch-Alarme für jedes angegebene NAT Gateway generiert und so die Konfiguration vereinfacht.
• Ein weiteres Macro, das eine CloudFormation-Einschränkung umgeht: dass sich String-Parameter nicht in Integer konvertieren lassen.

Der zweite Stack erstellt die Kernkomponenten der Lösung:

• DynamoDB-Tabelle: Diese Tabelle speichert die Anzahl der durchgeführten Aufzeichnungen pro NAT Gateway und enthält ein Callback-Token, das genutzt wird, sobald der Alarm in den Status "OK" zurückkehrt.

(Ein Callback-Token wird innerhalb eines Step-Function-Tasks generiert. Wird dieser Task ausgeführt, wartet er auf eine Benachrichtigung, bevor er zum nächsten Schritt übergeht. Die Lambda-Funktion, die durch die Rückkehr des Alarms in den Status "OK" ausgelöst wird, liest das Token und nutzt es, um der Step Function das Signal zum Weitermachen zu geben.)

So lässt sich der Aufzeichnungsprozess sauber steuern und nach Auflösung eines Alarms reibungslos fortsetzen.

• CloudWatch-Alarme: Diese Alarme überwachen die angegebenen NAT Gateways auf Traffic, der den definierten Schwellenwert überschreitet.
• EventBridge-Regeln: Zwei EventBridge-Regeln orchestrieren den Workflow. Eine Regel löst eine Step Function aus, sobald der CloudWatch-Alarm aktiv wird; die andere triggert eine Lambda-Funktion, sobald der Alarm wieder in den Status "OK" wechselt. Dieser Event-getriebene Ansatz sorgt für eine zeitnahe Reaktion auf Traffic-Schwankungen.
• Step Function: Die Step Function orchestriert das Erstellen, Verwalten und Löschen der VPC Flow Logs. Sie umfasst folgende Schritte:

— Eine Prüfung, ob die maximale Anzahl gewünschter Aufzeichnungen noch nicht erreicht ist, um unnötige Aufzeichnungen zu vermeiden.

— Erstellung von VPC Flow Logs für jede mit dem NAT Gateway verbundene ENI, um detaillierte Traffic-Informationen zu erfassen.

— Ein Wait-Status, der den Workflow pausiert, bis der Alarm entweder zu "OK" zurückkehrt oder ein vordefiniertes Zeitlimit erreicht ist – damit die Aufzeichnung lange genug läuft.

— Löschung der VPC-Flow-Log-Konfiguration, wobei die aufgezeichneten Logs für die beim Stack-Deployment gewählte Dauer erhalten bleiben.

— Versand einer SNS-E-Mail-Benachrichtigung an die festgelegten Empfänger mit aktuellen Informationen zum Aufzeichnungsstatus.

• Lambda-Funktionen:

Es gibt zwei Funktionen. Die eine wird aus der Step Function aufgerufen, um die ENIs des NAT Gateways im Alarmzustand zu ermitteln und die VPC Flow Logs für diese ENIs anzulegen. Die andere wird durch die EventBridge-Regel ausgelöst, sobald der CloudWatch-Alarm wieder zu "OK" wechselt. Sie holt das Callback-Token der Step Function aus DynamoDB und ruft die Step Function auf, damit diese ihre Verarbeitung fortsetzt.

Die Struktur der Step Function sehen Sie hier:

Diese Lösung nutzt die Speicherklasse Infrequent Access von CloudWatch-Log-Gruppen für die Ablage der VPC Flow Logs. Sie ist kostengünstig und ermöglicht effizientes Abfragen und Analysieren mit CloudWatch Logs Insights.

Am Ende einer VPC-Flow-Log-Aufzeichnung wird eine E-Mail mit einem Deep Link zur erstellten VPC-Flow-Logs-Gruppe und dem Präfix der aufgezeichneten Log-Streams verschickt.

Die Lösung liefert ein vordefiniertes Query-Format für CloudWatch Logs Insights, mit dem sich aussagekräftige Erkenntnisse aus den gesammelten Daten ziehen lassen. Sie können die folgende CloudWatch Logs Insight Query auf das Flow Log anwenden, indem Sie in CloudWatch Logs Insights unter "Saved Queries" die Query "Serverless Auto VPC Flow Log Recorder" auswählen, um eine gut lesbare Ausgabe zu erzeugen.

fields @timestamp, @message
| parse @message "* * * * * * * * * * * * * *" as action, flowDirection, trafficPathNum, srcAddr, srcPort, dstAddr, dstPort, proto, bytes, type, pkt_srcaddr, SrcService, pkt_dstaddr, DstService
| display @timestamp, action, flowDirection,
if(trafficPathNum == 1, "Through another resource in the same VPC",
if(trafficPathNum == 2, "Through an internet gateway or a gateway VPC endpoint",
if(trafficPathNum == 3, "Through a virtual private gateway",
if(trafficPathNum == 4, "Through an intra-region VPC peering connection",
if(trafficPathNum == 5, "Through an inter-region VPC peering connection",
if(trafficPathNum == 6, "Through a local gateway",
if(trafficPathNum == 7, "Through a gateway VPC endpoint (Nitro-based instances only)",
if(trafficPathNum == 8, "Through an internet gateway (Nitro-based instances only)",
"unknown")))))))) as trafficPath,
srcAddr, srcPort, dstAddr, dstPort,
if(proto == 6, "TCP",
if(proto == 17, "UDP",
proto)) as protocol,
bytes, type, pkt_srcaddr, SrcService, pkt_dstaddr, DstService
| sort @timestamp desc
| limit 1000

Unten sehen Sie ein Beispielergebnis dieser Query. Es zeigt, dass in der VPC kein VPC-S3-Gateway-Endpoint konfiguriert war. Dadurch lief der Traffic zu S3 über das NAT Gateway und das Internet.

Die Lösung zeigt außerdem, wie sich Traffic erkennen lässt, der über das Internet statt über VPC-Endpoints läuft. Wird Traffic über das Internet zu einem AWS-Service geleitet, erscheint der Servicename im Feld SrcService oder DstService der CloudWatch-Logs-Insights-Ausgabe (siehe das obige Beispiel mit Traffic an den S3-Service). Diese Information hilft bei der Entscheidung, ob für bestimmte Services VPC-Endpoints konfiguriert werden sollten, um Sicherheit und Kosten zu optimieren.

Die Lösung samt Installationsanleitung können Sie in diesem GitHub-Repository nachvollziehen.

Ich hoffe, dieser Blogpost hat Ihnen wertvolle Einblicke geliefert. Wenn Sie mehr erfahren möchten oder sich für unsere Services interessieren, melden Sie sich gerne. Sie erreichen uns hier.

• AWS Step Functions
• AWS EventBridge Rules
• AWS CloudWatch Alarms auf Basis mehrerer Metriken mit Math Expression
• AWS SAM
• IP-Traffic mit VPC Flow Logs protokollieren
• CloudWatch Logs Log Classes
• Daten mit CloudWatch Logs analysieren

Das zugehörige GitHub-Repository hat einen neuen Branch namens JSONata. Er enthält eine aktualisierte Step-Function-ASL, die mit JSONata und Variablen arbeitet – für kompakteren, klareren und intelligenteren Code. Die ASL selbst wurde aus dem SAM-YAML-Template in eine eigene JSON-Datei ausgelagert, die im Template referenziert wird.