Surveiller les pics de trafic inattendus sur les NAT Gateways AWS sans faire exploser le budget

Gérer les pics de trafic inattendus sur le service NAT (Network Address Translation) Gateways d'AWS peut s'avérer complexe. Si les VPC Flow Logs offrent des informations précieuses sur le trafic réseau, leur enregistrement permanent entraîne des coûts de stockage superflus et un déluge de données rarement pertinentes en exploitation normale.

Et si vous pouviez activer les VPC Flow Logs de manière sélective, uniquement lorsqu'un pic de trafic est détecté ?

Cet article présente une solution qui crée dynamiquement un enregistreur VPC Flow Logs temporaire dès qu'un seuil de trafic prédéfini est dépassé. Cette approche garantit la maîtrise des coûts en réduisant le stockage des données au minimum, tout en fournissant les informations essentielles pour analyser et comprendre les schémas de trafic inattendus.

L'utilisation des NAT Gateways a un coût. Vous payez leur fonctionnement, soit 0,045 $ par heure dans la région North Virginia. Vous payez également le volume de trafic qui les traverse, à 0,045 $ par Go en entrée/sortie. Et ce, pour tout ce qui transite par la NAT Gateway, y compris vers une ressource régionale comme S3.

L'addition peut grimper rapidement, car pour chaque To de données, vous paierez :

1 024 Go x 0,045 $ = 46,08 $

Pour 10 To, cela représente 460 $.

Et ainsi de suite.

Cet article est né de la demande d'un client confronté à un trafic inattendu via NAT Gateway, qui grimpait aléatoirement à 35 To et lui coûtait 1 600 $ supplémentaires et imprévus à chaque pic. Il ignorait l'origine du phénomène et ne souhaitait pas activer les VPC Flow Logs sur tout le mois (voir plus bas la section sur les coûts des VPC Flow Logs pour comprendre pourquoi).

Pour reprendre la documentation AWS, qui l'explique clairement :

VPC Flow Logs est une fonctionnalité qui permet de capturer des informations sur le trafic IP entrant et sortant des interfaces réseau de votre VPC. Les données des journaux de flux peuvent être publiées vers les destinations suivantes : Amazon CloudWatch Logs, Amazon S3 ou Amazon Data Firehose. Une fois un journal de flux créé, vous pouvez récupérer et consulter ses enregistrements dans le groupe de journaux, le bucket ou le flux de diffusion configuré.

Les journaux de flux sont utiles pour plusieurs tâches, notamment :

\* Diagnostiquer des règles de groupe de sécurité trop restrictives

\* Surveiller le trafic atteignant votre instance

\* Déterminer le sens du trafic depuis et vers les interfaces réseau

Les données des journaux de flux sont collectées en dehors du chemin du trafic réseau, et n'affectent donc ni le débit ni la latence du réseau. Vous pouvez créer ou supprimer des journaux de flux sans aucun risque d'impact sur les performances réseau.

Cet article et son dépôt associé portent sur l'enregistrement du trafic et son ingestion dans un groupe de journaux dédié dans Amazon CloudWatch Logs, où l'ensemble des journaux de trafic sont conservés et disponibles pour analyse.

Par défaut, si vous activez les VPC Flow Logs pour une NAT Gateway, les journaux suivront le format ci-dessous et seront visibles dans leur groupe de journaux CloudWatch respectif :

Enregistrements typiques de Flow Logs dans CloudWatch Logs

Cet article traite du stockage des données enregistrées dans des groupes de journaux CloudWatch ; il est donc important de comprendre les coûts liés à l'ingestion de ces données. Consultez la grille tarifaire de CloudWatch Logs ici.

Imaginons que vous utilisiez 10 NAT Gateways, chacune envoyant 1 000 requêtes par seconde de vos services vers Internet et recevant une seule réponse par requête. Enregistrer ce trafic avec les VPC Flow Logs entraînera l'ingestion de 2 000 enregistrements (1 000 envoyés + 1 000 réponses) par seconde dans CloudWatch Logs via les VPC Flow Logs.

Supposons que chaque enregistrement pèse 100 octets (cela peut être plus ou moins, selon le niveau de détail souhaité). Chaque mois, CloudWatch Logs ingérera des enregistrements pour un volume total de :

10 (NAT Gateways) X 2 000 (enregistrements par seconde) X 100 (octets par enregistrement) X 86 400 (secondes par jour) X 30,5 (jours moyens par mois) = 5 270 400 000 000 octets.

Soit environ 5,2 To ingérés par mois.

Le coût d'un mois d'ingestion de ces données se calcule sur la base du tarif de 0,5 $ par Go pour l'ingestion jusqu'à 10 To :

5 200 Go * 0,5 ($ par Go ) = 2 600 $ par mois (ce coût peut être divisé par deux, soit seulement 1 300 $, si vous ingérez vers un groupe de journaux CloudWatch configuré en classe Infrequent Access Log).

Imaginons maintenant que les pics de trafic à capturer ne surviennent qu'une ou deux fois par mois, durent à peine 15 minutes et fassent transiter une grande quantité de données par la NAT Gateway pendant ce laps de temps.

Notez que la quantité de données transmises ne se traduit pas nécessairement par davantage d'enregistrements dans le VPC Flow Log.

Prenez par exemple la différence entre faire transiter un fichier de 10 Mo ou un fichier de 1 Ko via une NAT Gateway. Chaque fichier transféré ne génère qu'un seul enregistrement. Le fichier de 10 Mo ne produira pas plus d'un enregistrement VPC Flow Log, même s'il est plus volumineux que celui de 1 Ko, qui ne génèrera lui aussi qu'un seul enregistrement.

Le coût du trafic NAT Gateway, lui, sera multiplié par 10⁴ en raison du volume de trafic bien plus élevé.

L'objectif : capturer ces pics sans payer un mois entier d'enregistrement de VPC Flow Logs.

La solution garantit que les VPC Flow Logs ne sont enregistrés que lorsque le trafic d'une NAT Gateway dépasse un certain seuil. Par exemple, si le trafic habituel d'une NAT Gateway est de 10 Mo par minute, vous pouvez configurer une alarme qui se déclenche dès que le trafic dépasse 100 Mo par minute pendant une durée donnée.

Cette solution n'est pas adaptée aux pics de trafic très brefs, car les VPC Flow Logs ne sont créés qu'une fois le pic détecté. Le pic n'a pas besoin d'être très long pour être capturé, mais il doit durer plus de 3 minutes pour que l'enregistrement du trafic soit effectivement lancé.

La solution crée une alarme CloudWatch pour chaque NAT Gateway que vous spécifiez lors de l'installation.

Ces alarmes sont associées à une règle EventBridge qui déclenche une Step Function.

La Step Function est chargée de démarrer l'enregistrement des VPC Flow Logs pour la NAT Gateway en état d'alarme. Elle supprime ensuite le processus d'enregistrement des VPC Flow Logs, mais conserve les données enregistrées. À la fin de l'enregistrement, SNS envoie un e-mail à l'adresse fournie lors de l'installation.

La solution est implémentée avec AWS SAM et se compose de deux stacks CloudFormation. La première stack déploie des macros CloudFormation pour fluidifier le déploiement. Ces macros incluent :

• Une macro qui génère automatiquement les alarmes CloudWatch pour chaque NAT Gateway spécifiée, simplifiant la configuration.
• Une autre macro qui contourne une limitation de CloudFormation : l'incapacité de convertir des paramètres de type chaîne en entiers.

La seconde stack crée les composants centraux de la solution :

• Table DynamoDB : cette table stocke le nombre d'enregistrements effectués par NAT Gateway et conserve un jeton de rappel utilisé lorsque l'alarme repasse à l'état OK.

(Un jeton de rappel est généré à l'intérieur d'une tâche d'une Step Function. Lors de son exécution, cette tâche attend une notification avant de passer à l'étape suivante. La fonction Lambda déclenchée par le retour de l'alarme à l'état OK lit ce jeton et l'utilise pour signaler à la Step Function de cesser d'attendre et de reprendre son exécution.)

Cela facilite la gestion du processus d'enregistrement et garantit une reprise fluide après la résolution d'une alarme.

• Alarmes CloudWatch : ces alarmes surveillent les NAT Gateways spécifiées pour repérer tout trafic dépassant le seuil défini.
• Règles EventBridge : deux règles EventBridge orchestrent le workflow. L'une déclenche une Step Function lors de l'activation de l'alarme CloudWatch, l'autre déclenche une fonction Lambda lorsque l'alarme repasse à OK. Cette approche événementielle garantit une réponse rapide aux variations de trafic.
• Step Function : la Step Function orchestre la création, la gestion et la suppression des VPC Flow Logs. Elle comprend les étapes suivantes :

— Vérification que le nombre maximal d'enregistrements souhaités n'a pas été atteint, afin d'éviter les enregistrements superflus.

— Création des VPC Flow Logs pour chaque ENI associée à la NAT Gateway, capturant des informations détaillées sur le trafic.

— État d'attente qui suspend le workflow jusqu'à ce que l'alarme repasse à OK ou qu'une durée prédéfinie soit atteinte, afin que l'enregistrement dure suffisamment longtemps.

— Suppression de la configuration des VPC Flow Logs tout en conservant les journaux enregistrés pour la durée choisie lors du déploiement de la stack CloudFormation.

— Envoi d'une notification SNS par e-mail aux destinataires désignés afin de fournir des mises à jour en temps utile sur l'état de l'enregistrement.

• Fonctions Lambda :

Il existe deux fonctions. La première est appelée depuis la Step Function pour récupérer les ENIs de la NAT Gateway en état d'alarme et créer les VPC Flow Logs pour ces ENIs. La seconde est déclenchée par la règle EventBridge lorsque l'alarme CloudWatch repasse à OK. Elle récupère le jeton de rappel de la Step Function depuis DynamoDB et appelle la Step Function pour qu'elle reprenne son exécution.

La structure de la Step Function est visible ci-dessous :

Cette solution s'appuie sur la classe de stockage Infrequent Access des groupes de journaux CloudWatch pour stocker les VPC Flow Logs. Cette classe offre une option économique tout en permettant des requêtes et des analyses efficaces avec CloudWatch Logs Insights.

À la fin d'une session d'enregistrement de VPC Flow Logs, un e-mail est envoyé : il contient un lien direct vers le groupe de VPC Flow Logs créé ainsi que le préfixe des flux de journaux enregistrés.

La solution fournit un format de requête prédéfini pour CloudWatch Logs Insights, permettant aux utilisateurs d'extraire des informations exploitables des données collectées. Vous pouvez exécuter la requête CloudWatch Logs Insights ci-dessous sur le Flow Log en vous rendant dans CloudWatch Logs Insights et en sélectionnant la requête nommée Serverless Auto VPC Flow Log Recorder dans la section Saved Queries pour obtenir un résultat lisible.

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

Voici un exemple de résultat de cette requête, montrant que le VPC S3 Gateway Endpoint n'avait pas été configuré dans le VPC. Conséquence : le trafic vers S3 transite par la NAT Gateway et par Internet.

La solution met également en évidence la capacité à identifier le trafic transitant par Internet plutôt que par des VPC endpoints. Lorsque du trafic est dirigé vers un service AWS via Internet, le nom du service apparaît dans les champs SrcService ou DstService du résultat CloudWatch Logs Insights (voir l'exemple ci-dessus pour le trafic vers le service S3). Cette information permet de déterminer si des VPC endpoints doivent être configurés pour certains services afin de renforcer la sécurité et de réduire les coûts.

Vous pouvez consulter et suivre les instructions d'installation de cette solution dans ce dépôt GitHub.

J'espère que cet article vous aura apporté des éclairages utiles. Si vous souhaitez en savoir plus ou si nos services vous intéressent, n'hésitez pas à nous contacter ici.

• AWS Step Functions
• Règles AWS EventBridge
• Alarmes AWS CloudWatch sur plusieurs métriques avec une expression mathématique
• AWS SAM
• Journalisation du trafic IP avec les VPC Flow Logs
• Classes de journaux CloudWatch Logs
• Analyser les données avec CloudWatch Logs

Le dépôt GitHub associé propose une nouvelle branche nommée JSONata. Elle contient une Step Function ASL mise à jour qui exploite JSONata et des variables pour un code plus compact, plus clair et plus intelligent. L'ASL elle-même a été extraite du template YAML SAM dans son propre fichier JSON, référencé depuis le template.