Introduction
Une application de livraison est prête dans un VPC, mais son service public ne peut pas encore recevoir de requête externe. Vous allez établir le chemin manquant : une passerelle Internet attachée au VPC, une route par défaut dans la table de routage du sous-réseau de l’application et une adresse publique associée à son interface réseau.
Terminez d’abord Créer un VPC avec des sous-réseaux d’application. Ce nouvel environnement fournit son propre VPC, ses sous-réseaux, son application et ses règles d’accès ; il ne réutilise pas votre VM précédente. La CLI est déjà configurée. Conservez le réseau de référence sans rapport avec l’exercice et toutes les ressources d’application fournies.
Liens avec les certifications
Ce laboratoire permet de pratiquer les thèmes d’examen suivants.
- Cloud Practitioner (CLF-C02) · Tâche 3.5 : Composants de passerelle VPC et leur rôle.
- Solutions Architect – Associate (SAA-C03) · Tâche 3.4 : Conditions élémentaires de routage et d’adressage d’un sous-réseau public.
- CloudOps Engineer – Associate (SOA-C03) · Tâches 5.1 et 5.3 : Configuration élémentaire d’une passerelle Internet et des routes, et diagnostic d’une route VPC manquante.
- Advanced Networking – Specialty (ANS-C01) · Tâche 2.2 : Pratique fondamentale de la configuration du routage dans une conception de connectivité à VPC unique.
Attacher une passerelle Internet
Dans cette étape, vous inspecterez le réseau d’application fourni et attacherez une passerelle Internet à son VPC.
Utilisez Terminal pour les commandes et cliquez sur AWS View à côté. Cette vue lit le même état des ressources que la CLI. Le VPC application-network contient public-subnet et private-subnet ; l’application fournie utilise l’adresse privée 10.20.1.10 dans public-subnet.
cd /home/labex/project
Sélectionnez le VPC de l’application avec son étiquette Name. --filters limite les résultats du serveur ; --query sélectionne l’ID. $(...) capture cet ID dans une variable du shell pour les étapes suivantes :
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Consultez les sous-réseaux du réseau sélectionné :
aws ec2 describe-subnets \
--filters "Name=vpc-id,Values=$VPC_ID" \
--query 'Subnets[].{CIDR:CidrBlock,ID:SubnetId}' \
--output table
Les plages sont 10.20.1.0/24 et 10.20.2.0/24. Le réseau de référence distinct 10.99.0.0/16 est sans rapport avec l’exercice ; conservez-le.
HTTP est le protocole de requête et de réponse utilisé par le point d’accès de cette application. Un port identifie le service destinataire ; l’application écoute sur le port TCP 80. Dans AWS View, cliquez sur Request application · client A. Cela envoie une requête externe depuis le client fourni 198.51.100.10. Le résultat est Connection failed avec No public address. L’application existe, mais son chemin d’accès public est incomplet.
Une passerelle Internet (IGW) relie le chemin de routage public d’un VPC à Internet. Sa création et son attachement sont deux opérations distinctes. Étiquetez la nouvelle passerelle pour identifier votre ressource d’exercice ; la spécification entre guillemets constitue un seul argument :
IGW_ID=$(aws ec2 create-internet-gateway \
--tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=parcel-internet},{Key=Project,Value=parcel}]' \
--query 'InternetGateway.InternetGatewayId' \
--output text)
Attachez uniquement cette passerelle au VPC d’application sélectionné :
aws ec2 attach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"
Un attachement réussi ne produit aucune sortie de commande. Interrogez plutôt la relation :
aws ec2 describe-internet-gateways \
--internet-gateway-ids "$IGW_ID" \
--query 'InternetGateways[].{ID:InternetGatewayId,Attachments:Attachments}' \
--output json
L’attachement désigne votre VPC et présente l’état available. AWS View affiche maintenant cette passerelle sous le VPC. L’attachement seul ne fournit ni route de sous-réseau ni adresse publique pour l’application. Gardez ce Terminal ouvert pour conserver les ID enregistrés.
Ajouter la route par défaut du sous-réseau public
Dans cette étape, vous dirigerez le trafic Internet du sous-réseau public vers la passerelle attachée.
Une table de routage associe des plages de destination à des cibles. Chaque sous-réseau utilise sa table associée, ou la table principale du VPC s’il n’a aucune association explicite. Ici, la préparation a fourni deux tables associées séparément : public-routes et private-routes. Choisissez public-routes dans le VPC de votre application :
PUBLIC_ROUTE_TABLE_ID=$(aws ec2 describe-route-tables \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-routes \
--query 'RouteTables[0].RouteTableId' \
--output text)
Consultez ses routes et ses associations :
aws ec2 describe-route-tables \
--route-table-ids "$PUBLIC_ROUTE_TABLE_ID" \
--query 'RouteTables[].{ID:RouteTableId,Routes:Routes,Associations:Associations}' \
--output json
L’association identifie public-subnet ; la route existante 10.20.0.0/16 a pour cible local, ce qui maintient le trafic du VPC à l’intérieur du VPC. Ne supprimez pas cette route locale et ne modifiez pas private-routes.
Une route par défaut, 0.0.0.0/0, couvre les destinations IPv4 qui ne correspondent pas à une route plus précise. --gateway-id définit la passerelle Internet comme cible :
aws ec2 create-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id "$IGW_ID"
La réponse contient Return: true. Interrogez de nouveau la table :
aws ec2 describe-route-tables \
--route-table-ids "$PUBLIC_ROUTE_TABLE_ID" \
--query 'RouteTables[].Routes[].{Destination:DestinationCidrBlock,Target:GatewayId,State:State}' \
--output table
La route par défaut cible votre igw-... et son état est active ; la route locale demeure. AWS View affiche 0.0.0.0/0 sous public-routes, vers la même passerelle. Cliquez à nouveau sur Request application · client A. La requête échoue encore avec No public address. Le sous-réseau a désormais une route publique, mais l’application a besoin de sa propre adresse IPv4 publique.
Associer une adresse publique et tester HTTP
Dans cette étape, vous associerez une IP élastique à l’application fournie et enverrez une requête externe réussie.
Une IP élastique est une adresse IPv4 publique allouée à votre compte qui peut être associée à une ressource compatible. Son ID d’allocation identifie l’adresse réservée ; son ID d’association identifie le lien avec une ressource. Vous supprimerez le lien et l’allocation lors du nettoyage.
Une interface réseau (ENI) fournit la connexion réseau et l’IP privée d’une application. Ce laboratoire fournit l’interface d’application ; vous n’avez pas besoin de créer une instance ni de configurer son système d’exploitation. Sélectionnez-la par VPC et par nom :
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=application-interface \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Allouez une adresse pour une utilisation dans un VPC et enregistrez son ID d’allocation :
ALLOCATION_ID=$(aws ec2 allocate-address \
--domain vpc \
--query 'AllocationId' \
--output text)
Associez-la à l’interface de l’application et enregistrez l’ID d’association :
ASSOCIATION_ID=$(aws ec2 associate-address \
--allocation-id "$ALLOCATION_ID" \
--network-interface-id "$ENI_ID" \
--query 'AssociationId' \
--output text)
Consultez l’état résultant de l’interface :
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,PrivateIP:PrivateIpAddress,PublicIP:Association.PublicIp}' \
--output table
L’adresse privée reste 10.20.1.10 ; le champ public contient maintenant une adresse. Dans AWS View, la carte de l’application affiche cette adresse publique et la route vers la passerelle. Cliquez sur Request application · client A.
Le résultat est Success, avec l’adresse source 198.51.100.10, le port de destination 80 et le corps Application online. Il s’agit d’une réponse HTTP de l’application fournie. Une liste de ressources configurées ne suffirait pas à prouver que la requête fonctionne.
Exemple de résultat : le sous-réseau public affiche la route vers la passerelle et l’adresse de l’application ; la requête renvoie Application online. Les ID et les adresses allouées varient.
Les règles d’accès préparées autorisent ce client et ce port. Le laboratoire suivant enseignera comment contrôler ces règles ; laissez-les inchangées ici.
Observer et restaurer une route défaillante
Dans cette étape, vous supprimerez une route, observerez une requête en échec, puis restaurerez le chemin fonctionnel.
Une adresse publique ne remplace pas le routage. Supprimez uniquement la route par défaut que vous avez créée ; conservez la route locale fournie :
aws ec2 delete-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0
Confirmez que l’adresse publique est toujours associée :
aws ec2 describe-addresses \
--allocation-ids "$ALLOCATION_ID" \
--query 'Addresses[].{PublicIP:PublicIp,Interface:NetworkInterfaceId}' \
--output table
Dans AWS View, public-routes ne contient désormais que la route locale. Une réponse antérieure peut être étiquetée Previous request ; elle ne décrit pas la configuration modifiée. Cliquez sur Request application · client A pour envoyer une nouvelle requête. Le résultat devient Connection failed, même si l’adresse publique demeure.
Exemple de diagnostic : l’application conserve son adresse publique, public-routes ne contient que sa route locale et la nouvelle requête échoue.
Restaurez la route vers la même passerelle attachée :
aws ec2 create-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id "$IGW_ID"
La réponse contient Return: true. Une fois la route réapparue dans AWS View, cliquez à nouveau sur Request application · client A. Success et Application online réapparaissent. Vous avez isolé le routage comme condition modifiée, sans changer plusieurs paramètres simultanément.
Supprimer votre chemin d’accès public
Dans cette étape, vous supprimerez uniquement l’adresse, la route et la passerelle que vous avez créées, en conservant les réseaux d’application et de référence fournis.
Les ressources ont des dépendances. Commencez par dissocier l’adresse de l’interface :
aws ec2 disassociate-address --association-id "$ASSOCIATION_ID"
Libérez ensuite l’allocation ; une dissociation seule conserve une ressource allouée :
aws ec2 release-address --allocation-id "$ALLOCATION_ID"
Supprimez votre route par défaut avant de détacher sa passerelle :
aws ec2 delete-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0
aws ec2 detach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"
Enfin, supprimez la passerelle détachée :
aws ec2 delete-internet-gateway --internet-gateway-id "$IGW_ID"
Ces commandes de suppression ne produisent aucune sortie en cas de réussite. Interrogez les inventaires complets pour établir l’absence des ressources, sans vous fier aux étiquettes :
aws ec2 describe-addresses --query 'Addresses' --output json
aws ec2 describe-internet-gateways --query 'InternetGateways' --output json
Les deux renvoient [] dans ce nouvel environnement. Vérifiez à nouveau les routes du sous-réseau fourni :
aws ec2 describe-route-tables \
--route-table-ids "$PUBLIC_ROUTE_TABLE_ID" \
--query 'RouteTables[].Routes[].{Destination:DestinationCidrBlock,Target:GatewayId}' \
--output table
Seule la route locale demeure. Le VPC, les sous-réseaux et l’interface d’application fournis existent toujours. AWS View n’affiche plus votre passerelle ni votre adresse publique. Cliquez une dernière fois sur Request application · client A ; le chemin public supprimé ne peut pas traiter la requête. Une interrogation d’inventaire en échec ne prouve pas le nettoyage des ressources.
Exécutez la vérification de cette étape.
Résumé
Vous avez attaché une passerelle Internet, ajouté une route par défaut dans la table associée du sous-réseau de l’application et associé une IP élastique. Vous avez testé un accès HTTP réel, démontré que supprimer la route fait échouer la requête malgré l’adresse publique, restauré la route et supprimé uniquement vos ressources d’exercice.
Poursuivez avec Contrôler l’accès aux applications avec les groupes de sécurité pour limiter les requêtes externes qui peuvent atteindre l’application.
