Réseaux AWS : VPC, sous-réseaux et routage

Sur AWS, toute ressource réseau — instance EC2, base de données RDS, répartiteur de charge, conteneur — s'exécute dans un VPC (Virtual Private Cloud). Bien concevoir son VPC dès le départ évite des migrations douloureuses : adressage qui chevauche le réseau de l'entreprise, sous-réseaux trop petits, ressources exposées par erreur.

Objectif : concevoir un VPC AWS à plusieurs zones de disponibilité, avec des sous-réseaux publics et privés, un routage correct et un filtrage robuste. Les concepts généraux sont présentés dans Cloud networking : principes et composants.

Régions, zones de disponibilité et VPC

• Une région (par exemple eu-west-3) regroupe plusieurs zones de disponibilité (AZ), centres de données physiquement séparés avec alimentation et réseau indépendants.
• Un VPC appartient à une région et s'étend sur toutes ses zones.
• Un sous-réseau appartient à une seule zone de disponibilité.

Pour la résilience, chaque niveau de l'application doit disposer d'un sous-réseau dans au moins deux zones.

Le plan d'adressage

Un VPC reçoit un bloc CIDR IPv4 principal, de /16 (65 536 adresses) à /28. On peut ajouter des blocs secondaires et un bloc IPv6.

Exemple pour un environnement de production :

VPC : 10.20.0.0/16, choisi pour ne pas chevaucher les réseaux de l'entreprise ni les autres VPC.

Adresses réservées : dans chaque sous-réseau, AWS réserve cinq adresses : l'adresse réseau, la suivante (routeur du VPC), la troisième (DNS), la quatrième (réservée pour un usage futur) et la dernière. Un /24 offre donc 251 adresses utilisables.

Créer le VPC et les sous-réseaux

aws ec2 create-vpc --cidr-block 10.20.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=vpc-prod}]'

aws ec2 create-subnet --vpc-id vpc-0abc1234 --cidr-block 10.20.0.0/24 \
  --availability-zone eu-west-3a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-a}]'

aws ec2 modify-vpc-attribute --vpc-id vpc-0abc1234 --enable-dns-hostnames '{"Value":true}'

Le routage

Chaque sous-réseau est associé à une table de routage. Toute table contient une route locale (le bloc du VPC), qui permet à tous les sous-réseaux de communiquer entre eux (sous réserve du filtrage). On ne peut pas la supprimer.

Sous-réseaux publics

Un sous-réseau est « public » parce que sa table de routage contient une route vers une Internet Gateway (IGW) :

aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --internet-gateway-id igw-0123 --vpc-id vpc-0abc1234
aws ec2 create-route-table --vpc-id vpc-0abc1234
aws ec2 create-route --route-table-id rtb-pub --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0123
aws ec2 associate-route-table --route-table-id rtb-pub --subnet-id subnet-public-a

Une instance d'un sous-réseau public n'est joignable depuis Internet que si elle possède une adresse IPv4 publique (ou une Elastic IP) et que les règles de filtrage l'autorisent. AWS facture les adresses IPv4 publiques : limitez-les aux ressources qui en ont réellement besoin.

Sous-réseaux privés et NAT Gateway

Les instances privées ont souvent besoin de sortir vers Internet (mises à jour, API externes) sans être joignables depuis l'extérieur. On place une NAT Gateway dans un sous-réseau public, et la table de routage privée envoie le trafic Internet vers elle :

Une NAT Gateway par zone de disponibilité, avec une table de routage privée par zone : si une zone tombe, les autres conservent leur accès sortant. Une seule NAT Gateway partagée est moins chère mais crée un point de défaillance et des transferts entre zones facturés.

Accès privé aux services AWS

Pour joindre Amazon S3 ou DynamoDB sans passer par la NAT Gateway (et sans frais de traitement NAT), on crée un point de terminaison de passerelle (gateway endpoint) ajouté aux tables de routage. Pour les autres services, les points de terminaison d'interface (AWS PrivateLink) placent une interface réseau privée dans vos sous-réseaux.

Le filtrage : security groups et NACL

Security groups

Un security group est un pare-feu avec état appliqué aux interfaces réseau des ressources.

• Uniquement des règles d'autorisation ; tout le reste est refusé.
• Le trafic de retour d'une connexion autorisée est automatiquement accepté.
• Une règle peut référencer un autre security group comme source.

Exemple de chaîne applicative :

aws ec2 authorize-security-group-ingress --group-id sg-app \
  --protocol tcp --port 8080 --source-group sg-alb

Les serveurs ne sont joignables que par le répartiteur, la base de données que par les serveurs, quelles que soient leurs adresses IP.

Network ACL

Une NACL s'applique au sous-réseau, de façon sans état :

• règles numérotées, évaluées par ordre croissant ;
• règles d'autorisation et de refus ;
• les flux de retour doivent être explicitement autorisés (ports éphémères 1024–65535 dans le cas général).

La NACL par défaut autorise tout. On l'utilise comme seconde barrière grossière (par exemple bloquer une plage d'adresses), la logique fine restant dans les security groups.

Accès d'administration

N'ouvrez pas SSH ou RDP sur Internet. Options :

• AWS Systems Manager Session Manager : accès aux instances sans port entrant ouvert, avec journalisation ;
• EC2 Instance Connect Endpoint ;
• un bastion durci, ou un VPN vers le VPC.

Observer

• VPC Flow Logs : journaux des flux acceptés et refusés, au niveau du VPC, du sous-réseau ou de l'interface, envoyés vers CloudWatch Logs ou S3.
• Reachability Analyzer : analyse statique du chemin entre deux ressources, indiquant le composant qui bloque.

aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-0abc1234 \
  --traffic-type ALL --log-destination-type s3 --log-destination arn:aws:s3:::journaux-flux-prod

Interconnecter des VPC

• VPC Peering : liaison privée entre deux VPC, non transitive (A–B et B–C ne permettent pas A–C).
• Transit Gateway : routeur central régional reliant de nombreux VPC et connexions VPN/Direct Connect, avec tables de routage pour segmenter.

Voir VPN cloud et connectivité hybride.

Erreurs courantes

• CIDR qui chevauche le réseau de l'entreprise.
• Une seule zone de disponibilité.
• Une seule NAT Gateway pour toutes les zones, ou NAT Gateway placée dans un sous-réseau privé.
• Security groups ouverts à 0.0.0.0/0 sur SSH, RDP ou les bases de données.
• Oublier les ports éphémères dans une NACL personnalisée.
• Sous-estimer les coûts de NAT et de transferts entre zones.

Conclusion

Un VPC bien conçu s'appuie sur un adressage planifié, des sous-réseaux publics et privés dans plusieurs zones, une NAT Gateway par zone, des security groups qui se référencent entre eux et des journaux de flux activés. Formalisez cette architecture en code pour la reproduire à l'identique d'un environnement à l'autre.

Références

• AWS — Qu'est-ce qu'Amazon VPC ?
• AWS — Sous-réseaux et blocs CIDR (adresses réservées)
• AWS — NAT gateways
• AWS — Security groups
• AWS — Network ACLs
• AWS — VPC Flow Logs