EC2 sans accès Internet dans un VPC personnalisé : Passerelle Internet et Table de Routage

Vous venez de créer un VPC personnalisé, lancé une instance EC2 dans un sous-réseau public, et pourtant ping google.com ne répond pas. Ce scénario est l'un des plus fréquents en démarrage AWS — non pas parce que la configuration est complexe, mais parce que le VPC par défaut masque plusieurs étapes que AWS effectue silencieusement en arrière-plan, et qu'un VPC personnalisé exige explicitement.

Résumé (TL;DR) : EC2 sans accès Internet dans un VPC personnalisé

Composant	Problème fréquent	Action corrective
Internet Gateway (IGW)	Non créée ou non attachée au VPC	Créer et attacher l'IGW
Table de routage	Aucune route `0.0.0.0/0` vers l'IGW	Ajouter la route et associer au sous-réseau
Adresse IP publique	Instance sans IP publique ou Elastic IP	Activer l'auto-assign ou associer une EIP
Security Group	Règles sortantes trop restrictives	Autoriser le trafic sortant HTTPS/HTTP
Network ACL	Règles DENY sur le sous-réseau	Vérifier les règles entrantes et sortantes

Comment fonctionne la connectivité Internet dans un VPC AWS

Dans le VPC par défaut, AWS préconfigure automatiquement une Internet Gateway attachée, une table de routage avec une route par défaut vers cette passerelle, et l'attribution automatique d'adresses IP publiques. Rien de tout cela n'existe dans un VPC personnalisé à la création. Chaque couche doit être construite manuellement.

Le chemin d'un paquet sortant depuis une instance EC2 vers Internet traverse plusieurs couches de contrôle. Si l'une d'elles est manquante ou mal configurée, le paquet est silencieusement abandonné — sans message d'erreur explicite dans la console.

graph LR EC2["Instance EC2
IP privée: 10.0.1.10"] --> SG["Security Group
Filtre stateful"] SG --> NACL["Network ACL
Filtre stateless"] NACL --> RTB["Table de Routage
0.0.0.0/0 → IGW ?"] RTB --> IGW["Internet Gateway
SNAT: IP privée → IP publique"] IGW --> INET["Internet"] style EC2 fill:#2d6a9f,color:#fff style SG fill:#e8a838,color:#fff style NACL fill:#e8a838,color:#fff style RTB fill:#c0392b,color:#fff style IGW fill:#27ae60,color:#fff style INET fill:#555,color:#fff

Instance EC2 : génère le paquet vers l'IP de destination (ex. 8.8.8.8).
Security Group : filtre stateful au niveau de l'interface réseau — vérifie les règles sortantes.
Network ACL : filtre stateless au niveau du sous-réseau — vérifie les règles sortantes ET entrantes pour la réponse.
Table de routage : détermine la prochaine destination. Sans route 0.0.0.0/0 → IGW, le paquet n'a nulle part où aller.
Internet Gateway : effectue la traduction NAT source (SNAT) entre l'IP privée de l'instance et son IP publique, puis achemine vers Internet.

L'Internet Gateway n'est pas un simple routeur — elle effectue également la traduction d'adresse entre l'IP privée de l'instance et son IP publique assignée. Sans IP publique sur l'instance, l'IGW ne peut pas compléter cette traduction, même si la route existe.

Diagnostic : identifier la couche défaillante dans votre VPC personnalisé

Avant de corriger quoi que ce soit, confirmez exactement où la chaîne est rompue. Travailler dans le bon ordre évite de corriger une couche alors que le vrai problème est ailleurs.

Étape 1 — Vérifier l'Internet Gateway et son attachement au VPC

La première chose à confirmer est l'existence d'une IGW et son attachement à votre VPC spécifique. Une IGW peut exister dans votre compte mais être dans l'état detached — ce qui ne génère aucune alerte visible dans la console EC2.

# Lister toutes les Internet Gateways du compte
aws ec2 describe-internet-gateways \
  --query 'InternetGateways[*].{IGW_ID:InternetGatewayId,State:Attachments[0].State,VPC_ID:Attachments[0].VpcId}' \
  --output table

Si la colonne VPC_ID est vide ou si State est detached, l'IGW n'est pas opérationnelle pour votre VPC. Passez à l'étape de correction.

Étape 2 — Vérifier la table de routage associée au sous-réseau public

Une IGW correctement attachée ne suffit pas si la table de routage du sous-réseau ne contient pas de route par défaut pointant vers elle. C'est la cause la plus fréquente d'échec silencieux — l'IGW existe, mais le sous-réseau utilise encore la table de routage principale sans route externe.

# Identifier la table de routage associée à votre sous-réseau
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-XXXXXXXXXXXXXXXXX \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Routes:Routes}' \
  --output json

Dans la sortie JSON, cherchez une entrée avec "DestinationCidrBlock": "0.0.0.0/0" et "GatewayId" commençant par igw-. Si cette entrée est absente, la route par défaut manque.

Étape 3 — Vérifier l'adresse IP publique de l'instance

Même avec une IGW attachée et une route correcte, si l'instance n'a pas d'IP publique, l'IGW ne peut pas effectuer la traduction d'adresse. Vérifiez le champ PublicIpAddress — une valeur null confirme l'absence d'IP publique.

# Vérifier l'IP publique de l'instance
aws ec2 describe-instances \
  --instance-ids i-XXXXXXXXXXXXXXXXX \
  --query 'Reservations[0].Instances[0].{PrivateIP:PrivateIpAddress,PublicIP:PublicIpAddress,State:State.Name}' \
  --output table

Étape 4 — Vérifier les règles du Security Group

Les Security Groups AWS autorisent par défaut tout le trafic sortant lors de leur création initiale. Cependant, si quelqu'un a modifié les règles sortantes manuellement, le trafic HTTPS ou ICMP peut être bloqué. Les Security Groups sont stateful — une règle sortante autorisée permet automatiquement la réponse entrante correspondante.

# Vérifier les règles sortantes du Security Group attaché à l'instance
aws ec2 describe-security-groups \
  --group-ids sg-XXXXXXXXXXXXXXXXX \
  --query 'SecurityGroups[0].IpPermissionsEgress' \
  --output table

Étape 5 — Vérifier les Network ACLs du sous-réseau

Contrairement aux Security Groups, les Network ACLs sont stateless. Une règle autorisant le trafic sortant ne garantit pas que la réponse entrante sera acceptée — les deux directions doivent être explicitement autorisées. C'est souvent la couche oubliée lors d'un diagnostic de connectivité, surtout si les Security Groups semblent corrects.

# Vérifier les Network ACLs associées au sous-réseau
aws ec2 describe-network-acls \
  --filters Name=association.subnet-id,Values=subnet-XXXXXXXXXXXXXXXXX \
  --query 'NetworkAcls[*].{AclId:NetworkAclId,Entries:Entries}' \
  --output json

Recherchez des règles avec "RuleAction": "deny" qui pourraient bloquer le trafic sortant (ports 80, 443) ou le trafic entrant sur les ports éphémères (1024-65535 pour les réponses TCP).

graph TD START["ping google.com échoue"] --> Q1{"IGW attachée au VPC ?"} Q1 -- Non --> FIX1["Créer et attacher l'Internet Gateway"] Q1 -- Oui --> Q2{"Route 0.0.0.0/0 vers IGW dans RTB ?"} Q2 -- Non --> FIX2["Ajouter route par défaut et associer au sous-réseau"] Q2 -- Oui --> Q3{"Instance a une IP publique ?"} Q3 -- Non --> FIX3["Associer une Elastic IP"] Q3 -- Oui --> Q4{"Security Group autorise trafic sortant ?"} Q4 -- Non --> FIX4["Ajouter règles sortantes SG"] Q4 -- Oui --> Q5{"Network ACL bloque le trafic ?"} Q5 -- Oui --> FIX5["Corriger règles NACL entrées/sorties"] Q5 -- Non --> END["Vérifier logs système et routing OS"] style START fill:#c0392b,color:#fff style END fill:#27ae60,color:#fff style FIX1 fill:#2d6a9f,color:#fff style FIX2 fill:#2d6a9f,color:#fff style FIX3 fill:#2d6a9f,color:#fff style FIX4 fill:#2d6a9f,color:#fff style FIX5 fill:#2d6a9f,color:#fff

Correction complète : attacher une Internet Gateway et configurer la table de routage

Une fois le diagnostic confirmé, voici la séquence complète de correction. L'ordre est important — créer la route avant d'attacher l'IGW génère une erreur de validation.

Correction 1 — Créer et attacher une Internet Gateway

# Créer une nouvelle Internet Gateway
aws ec2 create-internet-gateway \
  --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=mon-igw}]' \
  --query 'InternetGateway.InternetGatewayId' \
  --output text

# Attacher l'IGW au VPC (remplacer les IDs par les vôtres)
aws ec2 attach-internet-gateway \
  --internet-gateway-id igw-XXXXXXXXXXXXXXXXX \
  --vpc-id vpc-XXXXXXXXXXXXXXXXX

Aucune sortie en cas de succès — c'est le comportement attendu pour cette commande. Vérifiez avec describe-internet-gateways que l'état est bien attached.

Correction 2 — Ajouter la route par défaut vers l'IGW

Si votre sous-réseau public utilise la table de routage principale du VPC, il est préférable de créer une table de routage dédiée pour les sous-réseaux publics plutôt que de modifier la table principale — cela évite d'exposer accidentellement d'autres sous-réseaux privés à Internet.

# Créer une table de routage dédiée pour les sous-réseaux publics
aws ec2 create-route-table \
  --vpc-id vpc-XXXXXXXXXXXXXXXXX \
  --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=rtb-public}]' \
  --query 'RouteTable.RouteTableId' \
  --output text

# Ajouter la route par défaut vers l'Internet Gateway
aws ec2 create-route \
  --route-table-id rtb-XXXXXXXXXXXXXXXXX \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-XXXXXXXXXXXXXXXXX

# Associer la table de routage au sous-réseau public
aws ec2 associate-route-table \
  --route-table-id rtb-XXXXXXXXXXXXXXXXX \
  --subnet-id subnet-XXXXXXXXXXXXXXXXX

Correction 3 — Assigner une IP publique à l'instance

Si l'instance a été lancée sans IP publique, vous ne pouvez pas en assigner une directement après le lancement sans passer par une Elastic IP. Pour les nouveaux lancements, activez l'auto-assign au niveau du sous-réseau.

# Activer l'attribution automatique d'IP publique sur le sous-réseau
aws ec2 modify-subnet-attribute \
  --subnet-id subnet-XXXXXXXXXXXXXXXXX \
  --map-public-ip-on-launch

Pour une instance déjà lancée sans IP publique, allouez et associez une Elastic IP :

# Allouer une Elastic IP
aws ec2 allocate-address \
  --domain vpc \
  --query 'AllocationId' \
  --output text

# Associer l'Elastic IP à l'instance
aws ec2 associate-address \
  --instance-id i-XXXXXXXXXXXXXXXXX \
  --allocation-id eipalloc-XXXXXXXXXXXXXXXXX

Correction 4 — Vérifier et corriger les règles sortantes du Security Group

Si les règles sortantes ont été supprimées, restaurez au minimum l'autorisation du trafic HTTPS et HTTP. Adaptez selon votre politique de sécurité.

🔽 Cliquer pour afficher la politique IAM et les commandes de correction du Security Group

# Autoriser le trafic HTTPS sortant
aws ec2 authorize-security-group-egress \
  --group-id sg-XXXXXXXXXXXXXXXXX \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# Autoriser le trafic HTTP sortant
aws ec2 authorize-security-group-egress \
  --group-id sg-XXXXXXXXXXXXXXXXX \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

# Autoriser ICMP sortant (pour ping)
aws ec2 authorize-security-group-egress \
  --group-id sg-XXXXXXXXXXXXXXXXX \
  --protocol icmp \
  --port -1 \
  --cidr 0.0.0.0/0

Cas réel : le sous-réseau 'public' qui ne l'était pas vraiment

Voici un scénario typique rencontré en production : une instance EC2 est lancée dans un sous-réseau étiqueté public-subnet-1a. L'IGW existe et est attachée. Le Security Group autorise tout le trafic sortant. Et pourtant, curl https://checkip.amazonaws.com timeout systématiquement.

Le diagnostic initial se concentre sur les Security Groups et les Network ACLs — tout semble correct. On vérifie l'IGW — attachée, état available. On inspecte la table de routage associée au sous-réseau... et là, la route 0.0.0.0/0 pointe vers l'IGW correcte. Tout semble en ordre.

La vraie cause : l'instance a été lancée avant l'activation de map-public-ip-on-launch sur le sous-réseau. Elle n'a donc pas d'IP publique. L'IGW reçoit le paquet, tente la traduction d'adresse, mais il n'y a aucune IP publique à utiliser comme source — le paquet est abandonné silencieusement. La commande describe-instances confirme PublicIpAddress: null.

La correction : associer une Elastic IP à l'instance. Connectivité rétablie immédiatement.

Un sous-réseau 'public' dans AWS n'est public que si trois conditions sont simultanément vraies : IGW attachée, route vers l'IGW, et IP publique sur l'instance.

Vérification finale de l'accès Internet EC2

Après avoir appliqué les corrections, validez la connectivité depuis l'intérieur de l'instance :

# Depuis l'instance EC2 (via Session Manager ou SSH)
curl -s https://checkip.amazonaws.com
ping -c 4 google.com

Si vous utilisez AWS Systems Manager Session Manager (recommandé pour éviter d'ouvrir le port 22), vérifiez que l'instance peut atteindre les endpoints SSM — ce qui confirme également la connectivité sortante HTTPS.

# Vérifier la connectivité depuis votre machine locale via SSM
aws ssm start-session \
  --target i-XXXXXXXXXXXXXXXXX

Prochaines étapes et bonnes pratiques pour votre VPC personnalisé

Une fois la connectivité Internet rétablie sur votre EC2 dans le VPC personnalisé, quelques points à consolider pour une architecture robuste :

Utilisez des sous-réseaux privés avec une NAT Gateway pour les instances qui n'ont pas besoin d'être accessibles depuis Internet — elles peuvent initier des connexions sortantes sans être exposées directement.
Activez les VPC Flow Logs sur votre VPC pour capturer les métadonnées de trafic réseau — indispensable pour diagnostiquer les problèmes de connectivité futurs sans accès à l'instance.
Utilisez AWS Network Manager Reachability Analyzer pour valider programmatiquement les chemins réseau entre deux points sans envoyer de trafic réel.

# Activer les VPC Flow Logs vers CloudWatch Logs
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-XXXXXXXXXXXXXXXXX \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/VPCFlowLogsRole

Pour aller plus loin, consultez la documentation officielle AWS sur les Internet Gateways et le guide Network ACLs AWS.

Glossaire : termes clés pour l'accès Internet EC2 dans un VPC

Terme	Définition opérationnelle
Internet Gateway (IGW)	Composant VPC géré par AWS qui permet la communication entre les instances d'un VPC et Internet. Effectue la traduction NAT source entre IP privée et IP publique.
Table de routage	Ensemble de règles déterminant où le trafic réseau est dirigé. Chaque sous-réseau est associé à exactement une table de routage.
Sous-réseau public	Sous-réseau dont la table de routage contient une route vers une Internet Gateway. Le terme 'public' est une convention de nommage — AWS ne le définit pas automatiquement.
Elastic IP (EIP)	Adresse IPv4 publique statique allouée à votre compte AWS, associable à une instance ou une interface réseau.
Network ACL (NACL)	Pare-feu stateless au niveau du sous-réseau. Les règles entrantes et sortantes sont évaluées indépendamment — contrairement aux Security Groups qui sont stateful.

Rechercher dans ce blog

SW BBANG F