NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure.

TL;DR — NAT Gateway vs NAT Instance

Critère NAT Gateway NAT Instance
Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA
Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration
Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2
Modèle de coût Coût horaire + frais de transfert de données Coût de l'instance EC2 + frais de transfert de données
Security Groups Non applicable (géré par AWS) Configurable sur l'instance
Port forwarding Non supporté Supporté via iptables
Cas d'usage recommandé Production, workloads critiques Dev/test, besoins très spécifiques

Comment fonctionne la translation d'adresse NAT dans un VPC AWS

Dans un VPC, les instances d'un sous-réseau privé n'ont pas de route directe vers internet. Pour qu'elles puissent initier des connexions sortantes — télécharger des packages, appeler des API externes — il faut un composant qui effectue la translation d'adresse réseau (NAT) : il remplace l'adresse IP privée source par une adresse IP publique, puis route la réponse en retour vers l'instance d'origine.

AWS propose deux mécanismes pour remplir ce rôle. Le premier est le NAT Gateway, un service managé déployé dans un sous-réseau public, associé à une Elastic IP. Le second est la NAT Instance, une instance EC2 classique sur laquelle vous activez le forwarding IP et configurez des règles iptables, avec la vérification source/destination désactivée.

Dans les deux cas, la table de routage du sous-réseau privé doit pointer le trafic destiné à 0.0.0.0/0 vers le composant NAT. C'est le même modèle conceptuel — la différence réside dans qui opère le plan de données.

graph LR A["Instance privée
(sous-réseau privé)"] -->|"0.0.0.0/0"| B["Composant NAT
(sous-réseau public)"] B -->|"Elastic IP"| C["Internet Gateway"] C --> D["Internet"] D -->|"Réponse"| C C --> B B -->|"Retranscription adresse"| A
  1. Instance privée initie une requête vers internet (ex. : apt-get update).
  2. La table de routage du sous-réseau privé dirige le trafic 0.0.0.0/0 vers le composant NAT (Gateway ou Instance).
  3. Le composant NAT, situé dans le sous-réseau public, remplace l'IP privée source par son IP publique (Elastic IP) et transmet vers l'Internet Gateway.
  4. L'Internet Gateway route le paquet vers internet.
  5. La réponse revient au composant NAT, qui retranscrit l'adresse et renvoie le paquet à l'instance privée d'origine.

NAT Gateway : le service managé AWS

Le NAT Gateway est le choix par défaut pour la grande majorité des architectures de production. AWS gère intégralement le plan de données, la scalabilité et la redondance interne à l'intérieur d'une zone de disponibilité. Vous n'avez pas d'OS à patcher, pas de démon à surveiller.

Un point que beaucoup de gens ratent au départ : le NAT Gateway est zonal. Il est déployé dans une AZ spécifique. Si vous avez des instances privées dans plusieurs AZ, la bonne pratique est de déployer un NAT Gateway par AZ — sinon, le trafic inter-AZ génère des frais supplémentaires et crée une dépendance à une seule AZ.

Déploiement d'un NAT Gateway

# Créer une Elastic IP
aws ec2 allocate-address \
  --domain vpc \
  --region us-east-1

# Créer le NAT Gateway dans le sous-réseau public
aws ec2 create-nat-gateway \
  --subnet-id subnet-0abc12345def67890 \
  --allocation-id eipalloc-0abc12345def67890 \
  --region us-east-1

# Attendre que le NAT Gateway soit disponible
aws ec2 wait nat-gateway-available \
  --nat-gateway-ids nat-0abc12345def67890 \
  --region us-east-1

# Ajouter la route dans la table de routage du sous-réseau privé
aws ec2 create-route \
  --route-table-id rtb-0abc12345def67890 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0abc12345def67890 \
  --region us-east-1

Vérification de l'état

aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-0abc12345def67890 \
  --query 'NatGateways[*].{ID:NatGatewayId,State:State,AZ:SubnetId}' \
  --output table \
  --region us-east-1

Politique IAM minimale pour gérer un NAT Gateway

🔽 Cliquer pour afficher la politique IAM 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNatGateway",
        "ec2:DeleteNatGateway",
        "ec2:DescribeNatGateways",
        "ec2:AllocateAddress",
        "ec2:ReleaseAddress",
        "ec2:CreateRoute",
        "ec2:DeleteRoute",
        "ec2:DescribeRouteTables"
      ],
      "Resource": "*"
    }
  ]
}
Pensez au NAT Gateway comme à un load balancer réseau : vous ne savez pas combien de processus tournent derrière, et vous n'avez pas besoin de le savoir. AWS gère la capacité — vous gérez la route.

NAT Instance : contrôle total, responsabilité totale

La NAT Instance est une instance EC2 classique sur laquelle vous activez le forwarding IP au niveau du noyau Linux et configurez iptables pour masquer les adresses sources. AWS fournissait historiquement des AMIs préconfigurées (amzn-ami-vpc-nat), mais pour les déploiements actuels, vous pouvez utiliser Amazon Linux 2 ou Amazon Linux 2023 et configurer le NAT manuellement.

La contrainte la plus souvent oubliée : vous devez désactiver la vérification source/destination sur l'interface réseau de l'instance. Sans ça, le noyau EC2 rejette les paquets dont l'IP source ne correspond pas à l'instance — ce qui est exactement le trafic NAT que vous voulez transiter.

Configuration d'une NAT Instance

# Désactiver la vérification source/destination sur l'ENI
aws ec2 modify-instance-attribute \
  --instance-id i-0abc12345def67890 \
  --no-source-dest-check \
  --region us-east-1

# Sur l'instance EC2 (via SSH) — activer le forwarding IP et configurer iptables
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Rendre le forwarding persistant
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf

# Sauvegarder les règles iptables (Amazon Linux 2)
sudo service iptables save

# Ajouter la route dans la table de routage du sous-réseau privé
# (pointer vers l'instance EC2, pas vers un NAT Gateway)
aws ec2 create-route \
  --route-table-id rtb-0abc12345def67890 \
  --destination-cidr-block 0.0.0.0/0 \
  --instance-id i-0abc12345def67890 \
  --region us-east-1

Vérification de la configuration source/destination

aws ec2 describe-instance-attribute \
  --instance-id i-0abc12345def67890 \
  --attribute sourceDestCheck \
  --query 'SourceDestCheck.Value' \
  --region us-east-1

La commande doit retourner false. Si elle retourne true, le trafic NAT sera silencieusement rejeté par l'hyperviseur — aucun log applicatif ne vous l'indiquera.

Diagnostic d'un problème fréquent : le trafic sortant ne passe pas

Symptôme classique : vos instances privées ne peuvent pas atteindre internet après configuration. Les logs applicatifs ne montrent rien — timeout pur. On pense immédiatement à un Security Group trop restrictif ou à une ACL réseau mal configurée. On passe 30 minutes à vérifier les règles entrantes. Ce n'est pas là.

graph TD S["Timeout — instance privée
ne joindra pas internet"] --> Q1{"Route 0.0.0.0/0 présente
dans la table de routage privée ?"} Q1 -->|"Non"| F1["Ajouter la route vers le NAT"] Q1 -->|"Oui"| Q2{"NAT dans un
sous-réseau public ?"} Q2 -->|"Non"| F2["Déplacer le NAT dans
un sous-réseau public"] Q2 -->|"Oui"| Q3{"Sous-réseau public a
une route vers IGW ?"} Q3 -->|"Non"| F3["Ajouter route vers Internet Gateway"] Q3 -->|"Oui"| Q4{"NAT Instance ?"} Q4 -->|"Oui"| Q5{"sourceDestCheck
désactivé ?"} Q5 -->|"Non"| F4["Désactiver sourceDestCheck
sur l'ENI"] Q5 -->|"Oui"| F5["Vérifier iptables MASQUERADE"] Q4 -->|"Non — NAT Gateway"| F6["Vérifier état NAT Gateway
(available ?)"] style F1 fill:#d4edda style F2 fill:#d4edda style F3 fill:#d4edda style F4 fill:#d4edda style F5 fill:#d4edda style F6 fill:#d4edda

La vraie cause, dans la majorité des cas observés en production :

  • Pour une NAT Instance : la vérification source/destination est encore activée (sourceDestCheck: true). Les paquets arrivent à l'instance mais sont rejetés avant même d'atteindre iptables.
  • Pour un NAT Gateway : la route dans la table de routage du sous-réseau privé pointe encore vers l'ancienne NAT Instance supprimée, ou la route 0.0.0.0/0 est absente.
  • Dans les deux cas : le NAT est dans la mauvaise AZ ou le mauvais sous-réseau — il est dans un sous-réseau privé au lieu d'un sous-réseau public avec une route vers l'Internet Gateway.
# Vérifier les routes de la table de routage du sous-réseau privé
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0abc12345def67890 \
  --query 'RouteTables[*].Routes' \
  --output table \
  --region us-east-1

# Vérifier que le sous-réseau du NAT a bien une route vers un Internet Gateway
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-PUBLIC-ID \
  --query 'RouteTables[*].Routes[?GatewayId!=null]' \
  --output table \
  --region us-east-1

Si la route 0.0.0.0/0 du sous-réseau public ne pointe pas vers un igw-*, le NAT lui-même n'a pas de chemin vers internet — peu importe la configuration en aval.

Choisir entre NAT Gateway et NAT Instance : guide de décision

graph TD START(["Besoin de NAT
pour sous-réseau privé"]) --> Q1{"Environnement
de production ?"} Q1 -->|"Oui"| GW["NAT Gateway ✓"] Q1 -->|"Non"| Q2{"Budget très
contraint ?"} Q2 -->|"Non"| GW Q2 -->|"Oui"| Q3{"Port forwarding
ou iptables custom ?"} Q3 -->|"Non"| GW Q3 -->|"Oui"| INST["NAT Instance"] GW --> G1["1 NAT Gateway par AZ
pour la HA"] INST --> I1["Désactiver sourceDestCheck
+ configurer iptables"] style GW fill:#cce5ff style INST fill:#fff3cd

Quand NAT Gateway est le bon choix

  • Workloads de production où la disponibilité est critique
  • Équipes sans capacité opérationnelle pour gérer des instances supplémentaires
  • Besoins de scalabilité imprévisibles ou élevés
  • Conformité nécessitant un composant réseau sans surface d'attaque OS

Quand une NAT Instance peut avoir du sens

  • Environnements de développement ou de test avec budget très contraint
  • Besoin de port forwarding entrant (cas rare, mais réel)
  • Contrôle fin du trafic via iptables pour des cas d'usage très spécifiques
  • Architectures legacy migrées depuis on-premises avec des contraintes réseau particulières
La NAT Instance, c'est comme gérer votre propre serveur de messagerie au lieu d'utiliser un service managé : vous avez plus de contrôle, mais vous êtes aussi responsable de tout ce qui peut mal tourner à 3h du matin.

Surveillance et observabilité du NAT Gateway

Le NAT Gateway publie des métriques dans CloudWatch. Les deux métriques les plus utiles en production sont ErrorPortAllocation — qui indique que le NAT ne peut plus allouer de ports source — et PacketsDropCount — qui signale des paquets rejetés. Une augmentation soudaine de ErrorPortAllocation indique généralement un nombre de connexions simultanées trop élevé vers peu de destinations distinctes.

aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name ErrorPortAllocation \
  --dimensions Name=NatGatewayId,Value=nat-0abc12345def67890 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

Conclusion et prochaines étapes — NAT Gateway vs NAT Instance

Pour la quasi-totalité des workloads AWS, le NAT Gateway managé est le choix approprié. La NAT Instance reste pertinente dans des scénarios très spécifiques — essentiellement quand vous avez besoin de fonctionnalités réseau que le NAT Gateway ne supporte pas, comme le port forwarding, ou dans des environnements de développement à budget très serré.

Si vous optez pour le NAT Gateway en production, déployez-en un par zone de disponibilité pour éviter les dépendances inter-AZ et les frais de transfert associés. Si vous choisissez une NAT Instance, traitez-la comme n'importe quelle instance critique : Auto Scaling Group, monitoring, stratégie de patch.

Glossaire

Terme Définition
NAT (Network Address Translation) Mécanisme qui remplace l'adresse IP source d'un paquet par une autre adresse avant de le transmettre, permettant à des hôtes avec des adresses privées d'initier des connexions vers internet.
Elastic IP Adresse IPv4 publique statique allouée à votre compte AWS, associable à une ressource comme un NAT Gateway ou une instance EC2.
Vérification source/destination Contrôle effectué par l'hyperviseur EC2 qui rejette les paquets dont l'IP source ou destination ne correspond pas à l'instance. Doit être désactivé sur une NAT Instance.
Internet Gateway (IGW) Composant VPC qui permet la communication entre les ressources du VPC et internet. Requis dans le sous-réseau public hébergeant le NAT.
Table de routage Ensemble de règles qui déterminent où le trafic réseau d'un sous-réseau est dirigé. La route 0.0.0.0/0 vers le NAT est la configuration clé pour les sous-réseaux privés.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite