Demo Instructions : Comprendre les sous-réseaux publics et privés dans un VPC
Instruction de Labs
Comprendre les sous-réseaux publics et privés dans un VPC
Présentation
Un Amazon VPC peut être divisé en plusieurs subnets afin d’organiser les ressources et de contrôler leur connectivité réseau. On distingue notamment :
- les subnets publics ;
- les subnets privés.
Dans ce lab, vous allez comparer deux instances Amazon EC2 presque identiques :
- une instance placée dans un subnet public ;
- une instance placée dans un subnet privé.
Les deux instances sont déployées dans le même VPC et dans la même Availability Zone. En observant leurs adresses IP, leurs subnets et leurs tables de routage, vous allez comprendre concrètement ce qui différencie un subnet public d’un subnet privé.
Niveau : Débutant
Difficulté : Modérée
Durée estimée : 15 à 20 minutes
Région AWS : Europe (Ireland) — eu-west-1
Services AWS utilisés
- Amazon VPC
- Amazon EC2
- EC2 Instance Connect
Notions CLF-C02 couvertes
Cloud Technology and Services : Networking, Compute
Impact coût : Faible ; deux instances EC2 préinitialisées sont utilisées pendant le lab.
Nettoyage manuel requis : Non
Environnement du lab
Ressources préinitialisées
L’environnement suivant est disponible au démarrage du lab :
- VPC lab-vpc — CIDR 10.0.0.0/16 ;
- subnet public lab-public-subnet — CIDR 10.0.1.0/24 ;
- subnet privé lab-private-subnet — CIDR 10.0.2.0/24 ;
- table de routage lab-public-rt avec 0.0.0.0/0 vers lab-igw ;
- table de routage lab-private-rt avec uniquement la route locale du VPC ;
- Internet Gateway lab-igw attachée au VPC ;
- instance lab-public-ec2, t3.micro, Amazon Linux 2023, Running, avec IPv4 publique et privée ;
- instance lab-private-ec2, t3.micro, Amazon Linux 2023, Running, avec IPv4 privée uniquement.
Les Security Groups sont configurés pour permettre les tests prévus : la connexion SSH vers lab-public-ec2 et le trafic ICMP nécessaire entre les deux instances.
Attention sécurité
Pour simplifier ce lab temporaire, SSH sur le port 22 peut être autorisé depuis 0.0.0.0/0 vers l’instance publique. Cette configuration expose SSH à toutes les adresses IPv4 et ne doit pas être reproduite telle quelle dans un environnement de production.
Vérification avant de démarrer
Vérifiez que :
- les deux instances sont Running ;
- lab-public-ec2 possède une IPv4 publique ;
- lab-private-ec2 ne possède pas d’IPv4 publique ;
- les deux instances se trouvent dans lab-vpc et dans la même Availability Zone.
Objectifs pédagogiques
À la fin de ce lab, vous serez capable de :
- identifier les subnets d’un Amazon VPC ;
- différencier un subnet public d’un subnet privé ;
- identifier la table de routage associée à un subnet ;
- comprendre le rôle d’une Internet Gateway ;
- comprendre le rôle de la route 0.0.0.0/0 ;
- observer la différence entre une adresse IPv4 privée et une adresse IPv4 publique ;
- comprendre pourquoi une instance située dans un subnet privé n’est pas directement accessible depuis Internet ;
- comprendre que des ressources situées dans des subnets différents d’un même VPC peuvent communiquer entre elles.
Étape 1 — Accéder à Amazon EC2
- Connectez-vous à la console AWS.
- Dans la barre de recherche située en haut de la console, saisissez :
À retenir
Amazon VPC permet de créer un réseau virtuel isolé dans AWS et de contrôler son adressage IP, ses sous-réseaux et son routage.
Étape 2 — Vérifier la Région AWS
Vérifiez la Région sélectionnée en haut à droite de la console AWS. La Région doit être :
Europe (Ireland)
Son identifiant est :
EC2
- Sélectionnez EC2 dans les résultats.
- Dans le menu de gauche, sélectionnez :
Instances
Vous devriez trouver deux instances :
- lab-public-ec2 ;
- lab-private-ec2.
Étape 2 — Vérifier la Région AWS
Vérifiez la Région sélectionnée en haut à droite de la console. La Région doit être :
Europe (Ireland)
Son identifiant est :
eu-west-1
Si une autre Région est sélectionnée :
- cliquez sur le nom de la Région ;
- sélectionnez Europe (Ireland).
Étape 3 — Observer les deux instances
Dans :
EC2 → Instances
repérez :
lab-public-ec2
et :
lab-private-ec2
Vérifiez que les deux instances sont dans l’état :
Running
Observez également leur type. Les deux doivent utiliser :
t3.micro
À observer
Les deux instances possèdent donc une configuration de calcul comparable. La principale différence que vous allez étudier concerne leur configuration réseau.
Étape 4 — Examiner l’instance publique
Sélectionnez :
lab-public-ec2
Dans l’onglet Details, repérez les informations suivantes :
VPC ID
L’instance doit appartenir à :
lab-vpc
Subnet ID
L’instance doit appartenir à :
lab-public-subnet
Availability Zone
Notez l’Availability Zone.
Private IPv4 address
Vous devriez trouver une adresse appartenant au réseau :
10.0.1.0/24
Par exemple :
10.0.1.10
Public IPv4 address
L’instance possède également une adresse IPv4 publique. Par exemple :
54.x.x.x
Les valeurs exactes dépendent de votre environnement.
Étape 5 — Examiner l’instance privée
Sélectionnez maintenant :
lab-private-ec2
Repérez les mêmes informations.
VPC ID
L’instance appartient également à :
lab-vpc
Subnet ID
Cette fois, l’instance appartient à :
lab-private-subnet
Availability Zone
Comparez cette valeur avec celle de lab-public-ec2. Les deux instances doivent se trouver dans la même Availability Zone.
Private IPv4 address
L’instance possède une adresse privée appartenant au réseau :
10.0.2.0/24
Par exemple :
10.0.2.10
Public IPv4 address
Vous devriez constater que l’instance ne possède aucune adresse IPv4 publique.
Étape 6 — Comparer les deux instances
Vous pouvez déjà observer une première différence.
Les deux instances utilisent donc le même VPC et la même Availability Zone. La différence se situe au niveau de leurs subnets et de leur connectivité réseau.
Étape 7 — Accéder à Amazon VPC
Dans la barre de recherche de la console AWS, saisissez :
VPC
Sélectionnez :
VPC
Dans le menu de gauche, cliquez sur :
Your VPCs
Repérez :
lab-vpc
Sélectionnez-le.
Étape 8 — Vérifier le VPC
Avec lab-vpc sélectionné, vérifiez :
IPv4 CIDR
10.0.0.0/16
State
Available
Les deux instances EC2 appartiennent à ce même réseau.
À retenir
Un VPC représente un réseau virtuel dans AWS.
Un VPC peut être découpé en plusieurs subnets.
Étape 9 — Explorer la Resource map
Avec lab-vpc sélectionné, ouvrez :
Resource map
Observez les ressources réseau associées au VPC. Vous devriez notamment identifier :
- lab-public-subnet ;
- lab-private-subnet ;
- lab-public-rt ;
- lab-private-rt ;
- lab-igw.
Prenez quelques instants pour observer les relations entre ces ressources.
Étape 10 — Examiner les deux subnets
Dans le menu de gauche, sélectionnez :
Subnets
Filtrez si nécessaire sur :
lab-vpc
Vous devriez trouver :
Subnet public
lab-public-subnet
CIDR :
10.0.1.0/24
Subnet privé
lab-private-subnet
CIDR :
10.0.2.0/24
Observez la colonne :
Availability Zone
Les deux subnets doivent se trouver dans la même Availability Zone.
À retenir
Le fait que deux subnets soient dans la même Availability Zone ne signifie pas qu’ils disposent de la même connectivité réseau.
Étape 11 — Examiner la table de routage publique
Dans le menu de gauche, sélectionnez :
Route tables
Repérez :
lab-public-rt
Sélectionnez cette table. Ouvrez l’onglet :
Routes
Vous devriez observer au moins les routes suivantes.
Route locale
Destination
10.0.0.0/16
Target
local
Route vers Internet
Destination
0.0.0.0/0
Target
une Internet Gateway dont l’identifiant commence par :
igw-
Cette Internet Gateway correspond à :
lab-igw
Étape 12 — Comprendre la route locale
La route :
10.0.0.0/16 → local
correspond au réseau de :
lab-vpc
Elle permet au routeur du VPC de gérer les communications entre les ressources utilisant les adresses du VPC. Cette route permet notamment la communication entre :
10.0.1.0/24
et :
10.0.2.0/24
sous réserve des règles de sécurité appliquées aux ressources.
Étape 13 — Comprendre la route vers Internet
La deuxième route est :
0.0.0.0/0 → lab-igw
La destination :
0.0.0.0/0
représente toutes les destinations IPv4 qui ne correspondent pas à une route plus spécifique. Le trafic concerné est envoyé vers :
lab-igw
c’est-à-dire l’Internet Gateway du VPC.
À retenir
Un subnet dont la table de routage possède une route vers une Internet Gateway est considéré comme un subnet public.
Étape 14 — Vérifier que le subnet public utilise cette table
Toujours dans :
lab-public-rt
ouvrez :
Subnet associations
Vous devriez trouver :
lab-public-subnet
Le chemin réseau est donc :
lab-public-ec2
lab-public-subnet
lab-public-rt
0.0.0.0/0
lab-igw
Internet
Étape 15 — Examiner la table de routage privée
Sélectionnez maintenant :
lab-private-rt
Ouvrez :
Routes
Vous devriez trouver :
10.0.0.0/16 → local
En revanche, vous ne devriez pas trouver de route :
0.0.0.0/0 → lab-igw
La table de routage privée ne possède donc aucun chemin direct vers l’Internet Gateway.
Étape 16 — Vérifier que le subnet privé utilise cette table
Dans :
lab-private-rt
ouvrez :
Subnet associations
Vous devriez trouver :
lab-private-subnet
Le chemin réseau disponible est donc essentiellement :
lab-private-ec2
lab-private-subnet
lab-private-rt
Réseau local `10.0.0.0/16` Il n’existe pas de route directe vers :
Internet Gateway
Étape 17 — Comparer les tables de routage
Comparez les deux tables.
lab-public-rt
lab-private-rt
La différence essentielle se trouve ici :
0.0.0.0/0 → Internet Gateway
Cette route existe dans la table publique. Elle n’existe pas dans la table privée.
À retenir
Ce n’est pas le nom d’un subnet qui le rend public ou privé.
C’est principalement sa configuration de routage.
Étape 18 — Examiner l’Internet Gateway
Dans le menu de gauche, sélectionnez :
Internet gateways
Repérez :
lab-igw
Sélectionnez-la. Vérifiez :
State
Attached
VPC
lab-vpc
L’Internet Gateway est attachée au VPC.
À retenir
Une Internet Gateway est attachée au VPC.
La table de routage détermine quels subnets disposent d’un chemin vers cette passerelle.
Étape 19 — Se connecter à l’instance publique
Retournez dans :
EC2 → Instances
Sélectionnez :
lab-public-ec2
Cliquez sur :
Connect
Sélectionnez l’onglet :
EC2 Instance Connect
Choisissez :
Connect using a Public IP
Vérifiez que le nom d’utilisateur est :
ec2-user
Cliquez sur :
Connect
Un terminal Linux s’ouvre dans votre navigateur. Vous êtes connecté à l’instance située dans le subnet public.
Étape 20 — Vérifier l’accès à Internet depuis l’instance publique
Dans le terminal de lab-public-ec2, exécutez :
curl https://checkip.amazonaws.com
curl https://checkip.amazonaws.com
Une adresse IPv4 publique doit apparaître. Cette commande contacte un service disponible sur Internet. Cela confirme que l’instance peut initier une communication vers Internet.
Pourquoi cela fonctionne-t-il ?
Plusieurs éléments sont réunis :
- l’instance se trouve dans un subnet public ;
- sa table de routage possède une route vers l’Internet Gateway ;
- l’instance possède une adresse IPv4 publique ;
- ses règles de sécurité permettent le trafic nécessaire.
Étape 21 — Tester la communication avec l’instance privée
Revenez dans la console EC2. Sélectionnez :
lab-private-ec2
Repérez son :
Private IPv4 address
Copiez cette adresse. Par exemple :
10.0.2.10
Revenez ensuite dans le terminal de :
lab-public-ec2
Exécutez :
ping -c 4 ADRESSE_IP_PRIVEE
Remplacez ADRESSE_IP_PRIVEE par l’adresse IPv4 privée de lab-private-ec2. Par exemple :
ping -c 4 10.0.2.10
Vous devriez recevoir des réponses.
À observer
L’instance privée n’est pas directement accessible depuis Internet. Elle peut néanmoins communiquer avec d’autres ressources du même VPC lorsque les règles de sécurité l’autorisent.
À retenir
Privé ne signifie pas isolé du VPC.
Un subnet privé peut communiquer avec d’autres subnets du même VPC grâce au routage local.
Étape 22 — Essayer d’accéder à l’instance privée depuis Internet
Retournez dans :
EC2 → Instances
Sélectionnez :
lab-private-ec2
Cliquez sur :
Connect
Ouvrez :
EC2 Instance Connect
Observez les options proposées. Contrairement à lab-public-ec2, cette instance ne possède pas d’adresse IPv4 publique. Vous ne pouvez donc pas utiliser une connexion directe via une IPv4 publique pour joindre cette instance depuis Internet.
Pourquoi ?
L’instance cumule deux caractéristiques importantes :
- elle ne possède pas d’adresse IPv4 publique ;
- son subnet n’a pas de route vers une Internet Gateway.
Elle n’est donc pas directement accessible depuis Internet avec l’architecture actuelle.
Étape 23 — Comprendre pourquoi une IP publique seule ne suffit pas
Le caractère public d’un subnet ne dépend pas de la présence d’une adresse IPv4 publique sur une instance. Imaginez une instance possédant une IPv4 publique mais placée dans :
lab-private-subnet
Sa table de routage ne disposerait toujours pas de route vers :
lab-igw
L’instance ne disposerait donc pas du chemin réseau nécessaire pour communiquer avec Internet via cette Internet Gateway. À l’inverse, placer une instance dans un subnet public ne la rend pas automatiquement accessible depuis Internet. L’instance doit notamment disposer :
- d’une adresse IPv4 publique ou d’une Elastic IP pour les communications IPv4 directes via Internet Gateway ;
- de règles de Security Group appropriées.
À retenir
La connectivité Internet dépend de plusieurs éléments :
routage + adresse IP + règles de sécurité
Étape 24 — Comprendre le subnet privé
Dans l’architecture de ce lab, aucune NAT Gateway n’est présente. L’instance :
lab-private-ec2
ne dispose donc pas non plus d’un chemin permettant d’initier directement des communications vers Internet. Dans certaines architectures, une NAT Gateway peut être utilisée pour permettre aux ressources d’un subnet privé d’initier des connexions vers Internet sans les rendre directement accessibles depuis Internet. Ce mécanisme n’est pas configuré dans ce lab.
Étape 25 — Revenir à la Resource map
Retournez dans :
VPC → Your VPCs
Sélectionnez :
lab-vpc
Ouvrez :
Resource map
Essayez maintenant d’identifier les deux chemins.
Chemin du subnet public
lab-public-subnet
lab-public-rt
Internet Gateway
Internet
Chemin du subnet privé
lab-private-subnet
lab-private-rt
Réseau local du VPC
Pas de route directe vers l’Internet Gateway.
Étape 26 — Comparer subnet public et subnet privé
Vous pouvez maintenant résumer les différences observées.
Nettoyage du lab :
Aucune nouvelle ressource AWS n’a été créée pendant ce lab. Aucun nettoyage manuel n’est nécessaire.
Validation du lab :
Vous avez terminé le lab si vous avez réussi à :
- identifier lab-public-ec2 et lab-private-ec2 ;
- vérifier que les deux instances sont dans lab-vpc ;
- vérifier qu’elles sont dans la même Availability Zone ;
- identifier le subnet de chaque instance ;
- constater que l’instance publique possède une IPv4 publique ;
- constater que l’instance privée ne possède qu’une IPv4 privée ;
- identifier lab-public-rt ;
- identifier lab-private-rt ;
- observer 0.0.0.0/0 → lab-igw dans la table publique ;
- constater l’absence de cette route dans la table privée ;
- identifier lab-igw ;
- vous connecter à lab-public-ec2 avec EC2 Instance Connect ;
- vérifier l’accès à Internet depuis l’instance publique ;
- vérifier la communication privée entre les deux subnets ;
- comprendre pourquoi lab-private-ec2 n’est pas directement accessible depuis Internet.
En cas de problème
Je ne trouve pas les deux instances
Vérifiez que vous utilisez la Région :
Europe (Ireland) — eu-west-1
Puis ouvrez :
EC2 → Instances
Vous devriez trouver :
- lab-public-ec2 ;
- lab-private-ec2.
Une instance n’est pas encore dans l’état Running
Actualisez la page et attendez quelques instants. Les deux instances doivent atteindre l’état :
Running
avant de poursuivre.
Je ne trouve pas l’adresse IPv4 publique de lab-public-ec2
Sélectionnez l’instance puis ouvrez :
Details
Repérez :
Public IPv4 address
L’instance publique doit disposer d’une adresse IPv4 publique.
lab-private-ec2 n’a pas d’adresse IPv4 publique
C’est le comportement attendu. Cette instance a été configurée avec uniquement une adresse IPv4 privée.
EC2 Instance Connect ne fonctionne pas sur l’instance publique
Vérifiez que :
- lab-public-ec2 est dans l’état Running ;
- l’instance possède une adresse IPv4 publique ;
- son Security Group autorise la connexion SSH nécessaire ;
- vous utilisez l’option Connect using a Public IP.
Le ping vers l’instance privée ne fonctionne pas
Vérifiez :
- l’adresse IPv4 privée utilisée ;
- que lab-private-ec2 est dans l’état Running ;
- que vous exécutez la commande depuis lab-public-ec2.
L’environnement du lab doit également autoriser le trafic ICMP entre les deux instances.
La commande curl ne fonctionne pas
Vérifiez que :
- vous êtes connecté à lab-public-ec2 ;
- l’instance possède une IPv4 publique ;
- lab-public-subnet utilise lab-public-rt ;
- lab-public-rt possède la route 0.0.0.0/0 vers lab-igw.
Lab terminé :
Félicitations ! Vous savez maintenant :
- différencier un subnet public d’un subnet privé ;
- comprendre le rôle des tables de routage ;
- identifier une route vers Internet ;
- comprendre le rôle d’une Internet Gateway ;
- différencier une adresse IPv4 publique d’une adresse IPv4 privée ;
- comprendre qu’un subnet privé peut communiquer avec les autres ressources du VPC sans être directement accessible depuis Internet ;
- expliquer les principaux éléments nécessaires à la connectivité Internet d’une instance EC2.
