Créer un VPC AWS et des sous-réseaux applicatifs

Introduction

Une application de livraison de colis doit séparer les plages d’adresses de son service public et de ses processus internes. Vous créerez un VPC, placerez deux sous-réseaux sans chevauchement dans des zones de disponibilité différentes et examinerez le plan d’adressage dans AWS View.

Vous devez déjà savoir exécuter des commandes AWS CLI et lire les identifiants des ressources. La CLI est configurée pour cet environnement neuf. Vous terminerez en supprimant uniquement vos propres ressources.

Liens avec les certifications

Ce laboratoire propose une mise en pratique des sujets d’examen suivants.

Cloud Practitioner (CLF-C02) · Tâches 3.2 et 3.5 : composants VPC et sous-réseaux, et relation entre une région et ses zones de disponibilité.
Solutions Architect – Associate (SAA-C03) · Tâche 3.4 : placement élémentaire des niveaux de sous-réseaux et planification d’adresses IP sans chevauchement.
CloudOps Engineer – Associate (SOA-C03) · Tâche 5.1 : configuration élémentaire des VPC et sous-réseaux.

Créer le VPC de livraison

Dans cette étape, vous choisirez la plage d’adresses globale de l’application et créerez son VPC.

Un Virtual Private Cloud (VPC) est un réseau isolé pour les ressources d’une région AWS. Son bloc CIDR définit les adresses utilisables par ses sous-réseaux. La notation CIDR IPv4 associe une adresse de début et une longueur de préfixe : 10.20.0.0/16 couvre 10.20.0.0 à 10.20.255.255. Un préfixe plus petit laisse davantage de bits pour les adresses ; /16 est donc plus grand que /24.

Utilisez Terminal pour les commandes et cliquez sur l’onglet AWS View situé à côté. La vue lit le même état des ressources que la CLI et affiche les ressources réseau que vous créez. Gardez les deux interfaces accessibles.

Commencez dans votre répertoire de travail :

cd /home/labex/project

Consultez l’inventaire des VPC avant toute modification. --query sélectionne les champs ID et CIDR ; --output table facilite leur comparaison :

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

Un réseau de référence utilise 10.99.0.0/16. D’autres VPC préexistants peuvent apparaître. Préservez-les ; vous créerez puis supprimerez votre propre réseau 10.20.0.0/16.

Le groupe EC2 comprend les opérations réseau VPC. --cidr-block définit la plage ; --tag-specifications ajoute les étiquettes Name et Project lors de la création. Les guillemets regroupent crochets et virgules en un seul argument.

L’expression shell $(...) exécute une commande et capture sa sortie. L’affecter à VPC_ID conserve l’identifiant pour la suite. --query 'Vpc.VpcId' --output text renvoie uniquement cet ID :

VPC_ID=$(aws ec2 create-vpc \
  --cidr-block 10.20.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=delivery-network},{Key=Project,Value=parcel}]' \
  --query 'Vpc.VpcId' \
  --output text)

Une commande dont la sortie est capturée n’affiche pas son résultat. Relisez la ressource avec l’ID enregistré. "$VPC_ID" insère cette valeur sous forme d’un seul argument :

aws ec2 describe-vpcs \
  --vpc-ids "$VPC_ID" \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock,State:State}' \
  --output table

Le CIDR vaut 10.20.0.0/16 et l’état est available. AWS View affiche delivery-network avec ce CIDR, sans sous-réseaux applicatifs. Gardez ce Terminal ouvert pour conserver les ID enregistrés.

Ajouter le sous-réseau du service public

Dans cette étape, vous allouerez une plage plus petite dans le VPC et la placerez dans une zone de disponibilité.

Un sous-réseau est une portion de la plage d’adresses d’un VPC. Il appartient à une seule zone de disponibilité (AZ) de la région ; le VPC s’étend à toute la région. Un nom comme us-east-1a indique l’emplacement des ressources du sous-réseau.

Réservez 10.20.1.0/24 au futur service public. Cette plage couvre 10.20.1.0 à 10.20.1.255 et est incluse dans 10.20.0.0/16. AWS réserve les quatre premières adresses et la dernière d’un sous-réseau IPv4 ordinaire, laissant 251 adresses attribuables dans ce /24. N’attribuez pas les adresses réservées aux charges de travail.

Examinez les noms des zones disponibles. La région a été configurée au démarrage de l’environnement :

aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].{Zone:ZoneName,State:State}' \
  --output table

Utilisez us-east-1a pour ce sous-réseau et us-east-1b pour le suivant. --vpc-id choisit le réseau parent ; --availability-zone, l’emplacement. Enregistrez le nouvel ID pour le nettoyage :

PUBLIC_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-public},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

Relisez le parent, la plage et la zone :

aws ec2 describe-subnets \
  --subnet-ids "$PUBLIC_SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

L’ID VPC correspond à celui enregistré, la plage est 10.20.1.0/24 et la zone us-east-1a. AWS View place ce sous-réseau dans delivery-network.

Le nom delivery-public décrit l’usage prévu. Un nom ne rend pas un sous-réseau public : il faut aussi une route vers une passerelle Internet, que vous configurerez dans le laboratoire suivant.

Ajouter un sous-réseau distinct pour les processus internes

Dans cette étape, vous donnerez aux processus internes leur propre sous-réseau sans chevauchement et comparerez le plan complet.

Deux sous-réseaux d’un même VPC ne peuvent pas se chevaucher. Attribuer 10.20.2.0/24 aux processus internes sépare leur plage de 10.20.1.0/24. Les deux restent dans le /16 du VPC.

Placez ce sous-réseau dans us-east-1b pour voir qu’un VPC contient des sous-réseaux dans plusieurs zones. Cela illustre le placement ; vous n’avez pas encore déployé d’application redondante entre les zones.

PRIVATE_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.2.0/24 \
  --availability-zone us-east-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-private},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

Un filtre côté serveur sélectionne uniquement les sous-réseaux de votre VPC. Dans Name=vpc-id,Values=..., Name identifie le filtre et Values contient l’ID VPC correspondant :

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'Subnets[].{ID:SubnetId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

Les deux lignes représentent le plan suivant. Les ID générés et l’ordre peuvent varier :

Usage	CIDR	Zone de disponibilité
Service public	`10.20.1.0/24`	`us-east-1a`
Processus internes	`10.20.2.0/24`	`us-east-1b`

Essayez d’ajouter 10.20.1.128/25 pour observer la limite de chevauchement. Cette plage plus petite est déjà dans delivery-public ; elle ne peut pas constituer un autre sous-réseau de ce VPC :

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.128/25 \
  --availability-zone us-east-1a

L’erreur attendue contient InvalidSubnet.Conflict. Aucun troisième sous-réseau n’est créé. Conservez les deux plages /24 valides.

Comparez ces mêmes plages et zones dans AWS View. Aucun sous-réseau n’a encore de route Internet. Leurs plages distinctes permettent d’appliquer séparément les routes et règles d’accès dans les prochains laboratoires.

Le VPC de livraison contient deux sous-réseaux sans chevauchement dans des zones de disponibilité distinctes

Exemple : les deux CIDR sont inclus dans la plage du VPC ; chaque sous-réseau affiche sa zone. Les ID varient dans votre environnement.

Supprimer le réseau d’exercice

Dans cette étape, vous supprimerez vos deux sous-réseaux et votre VPC tout en préservant le réseau de référence existant.

Les ressources ont des dépendances : un VPC ne peut pas être supprimé tant qu’il contient vos sous-réseaux. Supprimez uniquement les ID enregistrés. Une suppression réussie ne produit aucune sortie :

aws ec2 delete-subnet --subnet-id "$PUBLIC_SUBNET_ID"

aws ec2 delete-subnet --subnet-id "$PRIVATE_SUBNET_ID"

Supprimez maintenant le VPC vide :

aws ec2 delete-vpc --vpc-id "$VPC_ID"

Relisez l’inventaire complet au lieu de vous fier à une étiquette modifiable pour prouver la suppression :

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

Il n’y a plus de VPC 10.20.0.0/16. La référence 10.99.0.0/16 et les autres réseaux préexistants restent présents. L’échec d’une requête d’inventaire ne prouve pas le nettoyage. AWS View indique l’absence de VPC applicatif.

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

Le laboratoire suivant démarre dans un environnement neuf avec sa propre application préparée. Vous apprendrez comment une passerelle Internet, une route et une adresse publique permettent à une requête externe d’atteindre cette application.

Résumé

Vous avez créé une plage VPC, l’avez divisée en deux sous-réseaux applicatifs sans chevauchement et placé chacun dans une zone de disponibilité. Vous avez vérifié les relations avec la CLI et AWS View, puis supprimé votre seul réseau d’exercice.

Poursuivez avec Connecter un sous-réseau public à Internet pour transformer ce plan en un chemin applicatif fonctionnel.

Créer un VPC avec des sous-réseaux applicatifs