Accès sortant à un sous-réseau privé AWS avec NAT

Introduction

Une application de livraison fonctionne dans un sous-réseau privé et doit contacter un service externe sans recevoir d’adresse publique. Vous créerez une passerelle NAT publique, ajouterez sa route sortante et utiliserez de vraies requêtes HTTP pour observer la traduction de l’adresse source et la protection contre les connexions entrantes non sollicitées.

Terminez d’abord Control Application Access with Security Groups. Cet environnement neuf fournit sa propre application, ses sous-réseaux public et privé, sa route publique vers Internet et ses règles de sécurité. La CLI est déjà configurée. Conservez ces ressources et le réseau de référence sans rapport avec l’exercice ; créez puis supprimez uniquement votre passerelle NAT, son adresse Elastic IP et la route privée par défaut.

Correspondance avec les certifications

Ce laboratoire permet de pratiquer les thèmes d’examen suivants.

Cloud Practitioner (CLF-C02) · Tâche 3.5 : Rôles des sous-réseaux et passerelles dans un VPC.
Solutions Architect – Associate (SAA-C03) · Tâche 1.2 : Segmentation élémentaire des sous-réseaux publics et privés avec des tables de routage et NAT.
CloudOps Engineer – Associate (SOA-C03) · Tâches 5.1 et 5.3 : Configuration d’une passerelle NAT et diagnostic d’une route privée manquante.
Advanced Networking – Specialty (ANS-C01) · Tâche 3.1 : Pratique fondamentale de maintenance d’une route VPC statique et vérification de son effet sur la connectivité.

Examiner l’application privée et allouer une adresse NAT

Vous examinerez le réseau fourni, observerez l’absence de chemin sortant et allouerez une adresse à la future passerelle NAT.

Exécutez les commandes CLI dans Terminal et ouvrez AWS View à côté. Cette vue lit le même état des ressources. L’application utilise l’IPv4 privée 10.20.2.10 dans private-subnet, pas dans public-subnet.

cd /home/labex/project

Sélectionnez le VPC de l’application grâce à son étiquette Name. --filters limite les résultats, --query sélectionne l’identifiant et $(...) l’enregistre dans une variable shell :

VPC_ID=$(aws ec2 describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[0].VpcId' \
  --output text)

Sélectionnez le sous-réseau public de ce VPC. La passerelle NAT y disposera d’un chemin vers Internet :

PUBLIC_SUBNET_ID=$(aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-subnet \
  --query 'Subnets[0].SubnetId' \
  --output text)

Sélectionnez la table de routage existante du sous-réseau privé. Vous modifierez sa route par défaut en conservant son association au sous-réseau :

PRIVATE_RT_ID=$(aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=private-routes \
  --query 'RouteTables[0].RouteTableId' \
  --output text)

Examinez les deux tables fournies. La projection après []. sélectionne des champs lisibles pour chaque table :

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'RouteTables[].{Name:Tags[?Key==`Name`].Value|[0],Routes:Routes,Associations:Associations}' \
  --output json

Les deux tables nommées contiennent la route local du VPC. Une table principale sans nom peut aussi apparaître ; ne la modifiez pas. Les tables nommées ont des associations explicites aux sous-réseaux : utilisez donc la table sélectionnée private-routes. La table publique dirige aussi 0.0.0.0/0 vers une passerelle Internet ; la table privée n’a pas de route par défaut. Un sous-réseau privé n’a pas de route directe vers la passerelle Internet. Une passerelle NAT publique permet aux applications privées d’initier des connexions IPv4 avec son adresse publique. Elle appartient au sous-réseau public, dont la route Internet est déjà fournie.

Dans AWS View, cliquez sur Request outbound service. La requête HTTP privée renvoie Connection failed : elle n’a pas de route vers le service externe 198.51.100.20:9000. Cliquez sur Request private application from outside ; cette requête HTTP non sollicitée vers 10.20.2.10:80 échoue également. L’application conserve son adresse privée.

Une adresse Elastic IP est une adresse IPv4 publique allouée. Allouez-en une dans le domaine VPC et ajoutez des étiquettes pour identifier votre ressource d’exercice. La valeur de --tag-specifications entre guillemets est un seul argument décrivant le type de ressource et ses étiquettes :

ALLOCATION_ID=$(aws ec2 allocate-address \
  --domain vpc \
  --tag-specifications 'ResourceType=elastic-ip,Tags=[{Key=Name,Value=parcel-nat-address},{Key=Project,Value=parcel}]' \
  --query 'AllocationId' \
  --output text)

Consultez l’adresse allouée :

aws ec2 describe-addresses \
  --allocation-ids "$ALLOCATION_ID" \
  --query 'Addresses[].{Allocation:AllocationId,PublicIP:PublicIp,Domain:Domain}' \
  --output table

Le résultat contient un identifiant d’allocation, une IPv4 publique et le domaine vpc. Notez l’adresse publique pour la comparaison ultérieure avec le trafic. Elle appartient à la future passerelle NAT ; ne l’associez pas à l’application. Gardez ce Terminal ouvert pour conserver vos identifiants.

Créer une passerelle NAT publique

Vous placerez une passerelle NAT dans le sous-réseau public et vérifierez que sa création seule ne configure pas le routage de l’application privée.

NAT nécessite deux ressources existantes : le sous-réseau public et l’Elastic IP allouée. --subnet-id sélectionne son emplacement, --allocation-id son adresse publique et --connectivity-type public une passerelle pour le trafic vers Internet. Le type natgateway applique les étiquettes de propriété. Enregistrez l’identifiant généré :

NAT_ID=$(aws ec2 create-nat-gateway \
  --subnet-id "$PUBLIC_SUBNET_ID" \
  --allocation-id "$ALLOCATION_ID" \
  --connectivity-type public \
  --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=parcel-nat},{Key=Project,Value=parcel}]' \
  --query 'NatGateway.NatGatewayId' \
  --output text)

La création peut répondre avant que la passerelle soit prête. Un waiter CLI consulte son état à répétition jusqu’à satisfaire la condition nommée. Attendez available avant d’ajouter une route :

aws ec2 wait nat-gateway-available --nat-gateway-ids "$NAT_ID"

Un waiter réussi se termine sans sortie. Consultez l’état, le sous-réseau et l’association d’adresse :

aws ec2 describe-nat-gateways \
  --nat-gateway-ids "$NAT_ID" \
  --query 'NatGateways[].{ID:NatGatewayId,State:State,Subnet:SubnetId,Addresses:NatGatewayAddresses}' \
  --output json

State vaut available, Subnet correspond à votre sous-réseau public et NatGatewayAddresses contient l’identifiant d’allocation et l’adresse publique. Son PrivateIp se trouve dans la plage publique 10.20.1.0/24 : c’est l’adresse privée de l’interface NAT, distincte de l’Elastic IP et de l’adresse de l’application. NAT est une ressource séparée ; l’application privée n’a pas reçu cette adresse.

AWS View affiche maintenant NAT. Cliquez à nouveau sur Request outbound service. La requête échoue toujours, car la table privée n’a pas de route par défaut. Créer la passerelle fournit un prochain saut possible, sans le sélectionner automatiquement pour le sous-réseau privé. La route publique existante vers la passerelle Internet reste intacte.

Router le trafic sortant privé via NAT

Vous ajouterez la route privée par défaut et comparerez l’adresse privée de l’application à l’adresse source observée par le service externe.

Une route sélectionne un prochain saut pour une plage de destinations. 0.0.0.0/0 correspond aux destinations IPv4 sans route plus spécifique. --nat-gateway-id choisit votre NAT plutôt que la passerelle Internet. Ajoutez cette route uniquement à la table privée enregistrée :

aws ec2 create-route \
  --route-table-id "$PRIVATE_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id "$NAT_ID"

La réponse confirme la création. Consultez les routes de la table privée :

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

La route locale reste présente. La nouvelle route par défaut contient votre NatGatewayId et l’état active. Le chemin des paquets devient : application privée → NAT dans le sous-réseau public → passerelle Internet → service externe.

Quand AWS View affiche la route privée par défaut, cliquez sur Request outbound service. La réponse indique Success. Son corps contient l’IPv4 source réellement observée par le service HTTP externe. Comparez-la à l’adresse publique allouée :

aws ec2 describe-addresses \
  --allocation-ids "$ALLOCATION_ID" \
  --query 'Addresses[0].PublicIp' \
  --output text

Les deux adresses correspondent. La traduction d’adresses réseau (NAT) remplace l’adresse source privée par l’adresse publique de la passerelle et suit la connexion pour renvoyer la réponse à son initiateur. L’adresse de l’application reste 10.20.2.10.

L’application privée atteint le service externe grâce à sa route NAT

Exemple AWS View : l’application reste à 10.20.2.10, la route privée par défaut choisit la passerelle NAT disponible et le corps HTTP indique l’adresse publique allouée. Les identifiants et adresses générés peuvent varier.

Cliquez sur Request private application from outside. La requête renvoie toujours Connection failed. L’accès sortant et son trafic de retour ne créent pas de chemin entrant public vers l’application privée. NAT n’accepte pas une connexion Internet non sollicitée pour cette application.

Diagnostiquer et restaurer une route privée manquante

Vous supprimerez une route, observerez l’échec puis rétablirez la connectivité sans recréer NAT.

Une passerelle peut être disponible alors que son client n’a aucune route utilisable. Supprimez uniquement la route privée par défaut en conservant NAT et la route publique vers Internet :

aws ec2 delete-route --route-table-id "$PRIVATE_RT_ID" --destination-cidr-block 0.0.0.0/0

La suppression réussie ne produit aucune sortie. Examinez la table privée :

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

Seule la route locale du VPC reste présente. AWS View affiche toujours NAT disponible, mais aucune route privée par défaut. Cliquez sur Request outbound service : une nouvelle requête échoue. Le succès précédent constitue un historique, pas le résultat de cette nouvelle requête.

Restaurez la même route vers la même passerelle :

aws ec2 create-route \
  --route-table-id "$PRIVATE_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id "$NAT_ID"

Consultez à nouveau les routes :

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

La route par défaut active réapparaît. Dans AWS View, envoyez une nouvelle Request outbound service ; elle réussit et indique la même adresse publique NAT. Request private application from outside échoue toujours. Ces observations distinguent une passerelle disponible d’un chemin de routage client complet.

Supprimer le chemin NAT d’exercice et libérer son adresse

Vous supprimerez votre route et NAT, libérerez son adresse publique et démontrerez que le réseau privé fourni reste intact.

Supprimez la route privée par défaut avant son prochain saut. Sinon, la table peut conserver une route vers une passerelle supprimée :

aws ec2 delete-route --route-table-id "$PRIVATE_RT_ID" --destination-cidr-block 0.0.0.0/0

La suppression réussie ne produit aucune sortie. Supprimez uniquement votre NAT :

aws ec2 delete-nat-gateway --nat-gateway-id "$NAT_ID"

La réponse identifie la passerelle demandée. Utilisez le waiter de suppression avant de libérer son adresse :

aws ec2 wait nat-gateway-deleted --nat-gateway-ids "$NAT_ID"

Le waiter réussi se termine sans sortie. Supprimer NAT retire son interface réseau et désassocie son Elastic IP, mais ne libère pas l’allocation. Consultez l’adresse avant de la libérer :

aws ec2 describe-addresses \
  --allocation-ids "$ALLOCATION_ID" \
  --query 'Addresses[].{Allocation:AllocationId,PublicIP:PublicIp,Association:AssociationId}' \
  --output json

L’allocation et l’adresse publique restent présentes, tandis que Association vaut null : l’adresse est allouée, mais plus attachée. Libérez cette ressource séparée :

aws ec2 release-address --allocation-id "$ALLOCATION_ID"

La libération réussie ne produit aucune sortie. Consultez l’inventaire complet des passerelles plutôt que des étiquettes qui peuvent être retirées :

aws ec2 describe-nat-gateways \
  --query 'NatGateways[].{ID:NatGatewayId,State:State,Subnet:SubnetId}' \
  --output table

Votre passerelle peut rester listée avec l’état deleted ; aucune passerelle NAT d’exercice ne doit être active. Un enregistrement de suppression conservé ne signifie pas que la passerelle peut encore transférer du trafic. Vérifiez l’inventaire complet des adresses :

aws ec2 describe-addresses \
  --query 'Addresses[].{Allocation:AllocationId,PublicIP:PublicIp}' \
  --output table

L’allocation d’exercice est absente. Consultez maintenant les routes privées :

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

La route locale du VPC reste présente et la route par défaut est absente. L’application, les sous-réseaux, les règles de sécurité, la passerelle Internet publique et le réseau de référence fournis sont conservés. Une requête d’inventaire échouée ne prouve pas une suppression.

Dans AWS View, cliquez sur Request outbound service : la requête échoue à nouveau, car vous avez volontairement supprimé son chemin NAT. Request private application from outside reste bloquée. Ces résultats correspondent à l’état initial du réseau privé.

Exécutez la vérification de cette étape.

Résumé

Vous avez alloué une adresse publique, placé NAT dans le sous-réseau public et routé les requêtes sortantes d’une application privée par cette passerelle. Le service externe a observé l’adresse NAT traduite, tandis que les requêtes entrantes non sollicitées sont restées bloquées. Supprimer puis restaurer la route privée par défaut a montré pourquoi la disponibilité de la passerelle seule ne suffit pas à établir la connectivité.

Vous avez ensuite supprimé votre route et NAT, libéré l’adresse et vérifié la conservation de l’état initial du réseau privé.

Donner un accès sortant à un sous-réseau privé