Passerelle NAT et sous-réseaux privés

Les ressources des subnets privés disposent uniquement d’adresses IP privées et d’aucune route vers un Internet Gateway ; elles ne peuvent donc pas établir de connexions sortantes vers Internet. Pourtant, elles doivent souvent pouvoir accéder à Internet : pour télécharger des correctifs de l’OS, récupérer des images Docker, appeler des API tierces ou mettre à jour des logiciels. La solution consiste à acheminer le trafic des subnets privés via un dispositif qui dispose d’un accès à Internet et effectue une NAT (traduction d’adresses réseau), en masquant les IP privées derrière une IP publique. AWS propose deux options : la NAT Gateway (gérée) et une NAT Instance autogérée (ancienne solution).

Une NAT Gateway est un service entièrement géré, hautement disponible, qui permet aux instances des subnets privés d’établir des connexions sortantes vers Internet tout en bloquant le trafic entrant non sollicité. Elle se trouve dans un subnet public, possède une adresse IP Elastic et augmente automatiquement sa capacité jusqu’à 100 Gbit/s. Vous n’avez jamais besoin d’appliquer de correctifs, de mettre à l’échelle ou de gérer l’infrastructure sous-jacente. La NAT Gateway traduit l’IP source privée des paquets sortants en sa propre EIP, puis renvoie les réponses à l’IP privée d’origine.

Après avoir créé un NAT Gateway, ajoutez une route à la table de routage du subnet privé : destination 0.0.0.0/0 → ID du NAT Gateway. Cela indique à tout le trafic à destination d’Internet provenant des instances du subnet privé de passer par le NAT Gateway, qui l’achemine ensuite via l’Internet Gateway vers Internet. La table de routage conserve également la route locale du VPC (par exemple, 10.0.0.0/16 → local) pour le trafic interne. Sans cette entrée de routage, les instances du subnet privé n’ont toujours pas accès à Internet, même si un NAT Gateway est déployé.

Un NAT Gateway est spécifique à une AZ : il ne gère que le trafic provenant des subnets de la même AZ. Pour assurer une haute disponibilité, déployez un NAT Gateway par AZ et créez des tables de routage privées propres à chaque AZ : la table de routage privée de l’AZ-a achemine 0.0.0.0/0 vers le NAT-GW de l’AZ-a ; celle de l’AZ-b achemine le trafic vers le NAT-GW de l’AZ-b. Cela évite les frais de transfert de données inter-AZ et garantit que, si l’AZ-a tombe en panne, les instances de l’AZ-b (avec leur propre NAT) continuent d’avoir accès à Internet.

Un NAT Instance est une instance EC2 gérée par vos soins qui exécute une AMI NAT : il s’agit de l’ancienne approche, utilisée avant l’existence des NAT Gateway. Les NAT Instances vous obligent à : désactiver la vérification de la source et de la destination sur l’instance EC2, gérer la bande passante et la mise à l’échelle, appliquer les correctifs au système d’exploitation et gérer les pannes. Elles sont moins coûteuses pour les cas d’utilisation nécessitant une très faible bande passante et peuvent servir d’hôtes bastion. Les NAT Gateways sont le choix recommandé en production : ils sont entièrement gérés, leur capacité est mise à l’échelle automatiquement, ils offrent un SLA de disponibilité de 99,99 % au sein d’une AZ et ne nécessitent pas l’application de correctifs. L’examen a régulièrement évalué cette comparaison.

La tarification des NAT Gateway comporte deux éléments : des frais horaires par NAT Gateway (environ 0,045 $ par heure dans us-east-1, soit environ 32 $ par mois) et des frais de traitement des données par Go (environ 0,045 $ par Go dans us-east-1). Pour les charges de travail qui transfèrent de grandes quantités de données via NAT (par exemple, le téléchargement de grandes images de conteneurs ou des téléchargements en masse), le coût du traitement des données peut devenir prépondérant. Optimisez les coûts de NAT en acheminant le trafic S3 et DynamoDB via des VPC Gateway Endpoints (ce qui contourne entièrement NAT et est gratuit), et en acheminant les appels d’API AWS via des VPC Interface Endpoints plutôt que via NAT.

Les instances de base de données situées dans des subnets privés ne doivent pas être routées via le NAT Gateway : elles n’ont aucune raison d’initier des connexions vers Internet. Les bases de données doivent uniquement recevoir des connexions du niveau applicatif (au sein du VPC) et éventuellement accéder à des services AWS tels que S3 (pour les exportations et importations) via un point de terminaison VPC. Pour l’application des correctifs et les mises à jour des bases de données, RDS est un service géré ; vous n’appliquez donc pas directement les correctifs du système d’exploitation. Pour les bases de données autogérées sur EC2, utilisez Systems Manager Patch Manager, qui peut appliquer les correctifs via SSM sans accès à Internet si vous avez configuré le point de terminaison SSM VPC.

NAT Gateway fournit un NAT sortant avec état uniquement : il autorise les connexions sortantes initiées et leurs réponses, mais bloque tout trafic entrant non sollicité. Ce n’est pas un pare-feu : il n’inspecte ni ne filtre le contenu du trafic. Pour filtrer le trafic sortant (par exemple, n’autoriser que certains domaines ou certaines adresses IP de destination depuis les subnets privés), vous avez besoin de contrôles supplémentaires : AWS Network Firewall déployé dans le VPC, ou une appliance pare-feu tierce derrière un Gateway Load Balancer. Les groupes de sécurité et les NACL s’appliquent toujours aux instances des subnets privés, indépendamment de NAT.

En plus des NAT Gateway publics (avec des EIP pour l’accès à Internet), AWS prend en charge les NAT Gateway privés sans EIP. Les NAT Gateway privés servent à traduire les adresses IP privées pour le trafic entre des VPC, ou entre un VPC et des réseaux sur site lorsque les plages CIDR se chevauchent. Par exemple, si le VPC-A (10.0.0.0/16) doit communiquer avec un réseau sur site qui utilise également 10.0.0.0/16, un NAT Gateway privé dans le VPC-A traduit les adresses IP source vers une plage non chevauchante avant l’acheminement via un Transit Gateway vers le réseau sur site.

Surveillez l’état et les performances du NAT Gateway au moyen des métriques CloudWatch. Métriques clés : ActiveConnectionCount (connexions TCP actuellement actives via NAT), BytesInFromDestination / BytesInFromSource (transfert de données dans les deux sens), PacketDropCount (paquets abandonnés : indique des limites de bande passante ou des erreurs) et ErrorPortAllocation (NAT a épuisé les allocations de ports : cela peut indiquer un épuisement des ports dû à un trop grand nombre de connexions). Chaque NAT Gateway prend en charge jusqu’à 55 000 connexions simultanées par destination unique ; au-delà, des connexions peuvent être abandonnées.

Toutes les charges de travail des subnets privés n’ont pas besoin d’un NAT Gateway. Examinez le schéma d’accès : si les instances doivent uniquement communiquer avec d’autres ressources du VPC et avec des services AWS accessibles via des points de terminaison VPC (S3, DynamoDB, SSM, ECR, Secrets Manager), vous pouvez supprimer entièrement le NAT Gateway, ce qui permet d’économiser environ 32 $ par mois et par AZ, ainsi que les frais de traitement des données. Il s’agit du schéma idéal pour des microservices entièrement privés qui utilisent des VPC Interface Endpoints pour tous leurs accès aux services AWS. Évaluez chaque service appelé par vos instances et vérifiez si un Gateway Endpoint gratuit ou un Interface Endpoint payant peut remplacer NAT.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : les NAT Gateways permettent aux instances des subnets privés d’accéder à Internet en sortie en traduisant leurs IP privées en Elastic IP ; vous devez ajouter une route 0.0.0.0/0 dans la table de routage du subnet privé, en la faisant pointer vers le NAT Gateway ; et vous devez déployer un NAT Gateway par AZ pour assurer une haute disponibilité et éviter les frais de transfert de données inter-AZ. Nous allons maintenant comparer les Network ACL et les Security Groups pour assurer une défense en profondeur du VPC.