Architecture VPC et blocs CIDR

Un Amazon Virtual Private Cloud (VPC) est un réseau privé isolé logiquement au sein d'une AWS Region, que vous définissez et contrôlez. Chaque compte AWS dispose d'un VPC par défaut (CIDR 172.31.0.0/16) dans chaque Region, mais les architectures de production utilisent toujours des VPCs personnalisés. Un VPC couvre toutes les Availability Zones de sa Region et vous donne un contrôle total sur l'adressage IP, les sous-réseaux, les tables de routage, les passerelles internet et la sécurité. Les ressources au sein d'un VPC sont isolées des autres VPCs et d'Internet, sauf si vous configurez explicitement une connectivité.

Un CIDR (Classless Inter-Domain Routing) block définit la plage d'adresses IP d'un VPC ou d'un sous-réseau au format x.x.x.x/prefix. La longueur du préfixe détermine le nombre d'adresses IP de la plage : /16 = 65 536 adresses, /24 = 256 adresses, /28 = 16 adresses (taille minimale d'un sous-réseau sur AWS). Pour les VPCs, AWS autorise les blocs CIDR de /16 (le plus grand) à /28 (le plus petit). Choisissez un CIDR de VPC qui : (1) ne chevauche pas les réseaux sur site (pour un futur VPN/Direct Connect), (2) est suffisamment grand pour vos sous-réseaux prévus et (3) utilise un espace d'adresses privées RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Un sous-réseau est un segment de la plage d'adresses IP d'un VPC, situé dans une seule Availability Zone. Les sous-réseaux sont classés comme publics (ils disposent d'une route vers une passerelle internet) ou privés (ils n'ont pas de route directe vers Internet). Bonne pratique pour une architecture classique à 3 niveaux : créez au moins trois niveaux de sous-réseaux — public (répartiteurs de charge, hôtes bastion), private-app (instances EC2, tâches ECS) et private-data (RDS, ElastiCache) — puis répliquez chaque niveau dans au moins deux AZ pour assurer une haute disponibilité.

Voici une conception CIDR courante pour un VPC doté du CIDR 10.0.0.0/16, réparti sur deux AZ et trois niveaux : Public AZ-a : 10.0.1.0/24 ; Public AZ-b : 10.0.2.0/24 ; Private-App AZ-a : 10.0.10.0/24 ; Private-App AZ-b : 10.0.11.0/24 ; Private-Data AZ-a : 10.0.20.0/24 ; Private-Data AZ-b : 10.0.21.0/24. Cette disposition laisse de la place pour ajouter des sous-réseaux AZ-c (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24) sans devoir repenser l'ensemble du schéma CIDR. Concevez toujours votre architecture en anticipant sa croissance.

AWS réserve la première adresse IP et les quatre dernières adresses IP de chaque sous-réseau. Pour un sous-réseau 10.0.1.0/24 : 10.0.1.0 (réseau), 10.0.1.1 (routeur VPC), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (utilisation future) et 10.0.1.255 (Broadcast). Un sous-réseau /24 possède 256 IP au total, moins 5 réservées, soit 251 utilisables. Un sous-réseau /28 (le minimum) possède 16 IP, moins 5, soit 11 utilisables. Cela compte lorsque vous dimensionnez les sous-réseaux en fonction du nombre de ressources (instances EC2, fonctions Lambda avec VPC, etc.) que vous prévoyez de déployer.

Vous pouvez ajouter jusqu’à quatre blocs CIDR secondaires à un VPC existant sans le recréer. Cela est utile lorsque votre CIDR principal est épuisé (tous les subnets sont complets) ou lorsque vous devez ajouter un espace d’adressage provenant d’une autre plage RFC 1918 pour un cas d’utilisation spécifique, comme la mise en réseau des pods Kubernetes. Les CIDR secondaires sont soumis à certaines restrictions : par exemple, vous ne pouvez pas ajouter un CIDR qui se chevauche avec un autre, et certaines plages publiques qui ne relèvent pas de la RFC 1918 ne peuvent pas être utilisées. Planifiez soigneusement le dimensionnement du CIDR du VPC dès le départ afin de réduire le besoin de CIDR secondaires.

L’appairage de VPC établit une connexion réseau privée entre deux VPC afin que leurs ressources puissent communiquer à l’aide d’adresses IP privées. Les VPC appairés peuvent se trouver dans le même compte, dans des comptes différents ou même dans des Régions différentes (appairage interrégional). Exigence : les CIDR des deux VPC ne doivent pas se chevaucher. Limitation : l’appairage est non transitif — si le VPC-A est appairé avec le VPC-B et que le VPC-B est appairé avec le VPC-C, le VPC-A ne peut pas communiquer avec le VPC-C via le VPC-B. Pour obtenir une connectivité en maillage complet entre de nombreux VPC, utilisez plutôt AWS Transit Gateway.

AWS Transit Gateway (TGW) joue le rôle de concentrateur réseau central — un routeur cloud — qui connecte plusieurs VPC, VPN et connexions Direct Connect. Au lieu de créer N*(N-1)/2 connexions d’appairage de VPC pour un maillage complet de N VPC, vous attachez chaque VPC et chaque connexion au Transit Gateway, qui achemine le trafic entre eux. TGW prend en charge des tables de routage qui vous permettent de contrôler les associations pouvant communiquer entre elles, ce qui permet de segmenter le réseau (par exemple, isoler les VPC de production des VPC de développement sur le même TGW).

Deux paramètres DNS contrôlent la résolution des noms dans un VPC. enableDnsSupport : lorsque la valeur est true (par défaut), le VPC utilise le résolveur DNS fourni par AWS à l’adresse 169.254.169.253 ou à la deuxième adresse IP du CIDR du VPC (par exemple, 10.0.0.2 pour 10.0.0.0/16). enableDnsHostnames : lorsque la valeur est true (ce paramètre doit être activé pour les VPC personnalisés et il est activé par défaut pour le VPC par défaut), les instances EC2 du VPC reçoivent des noms d’hôte DNS tels que ip-10-0-1-15.ec2.internal. Les deux paramètres doivent être activés pour que les zones hébergées privées Route 53 fonctionnent dans le VPC.

Les journaux de flux VPC capturent les métadonnées du trafic réseau qui traverse votre VPC : IP source et destination, port, protocole, octets transférés et indication précisant si le trafic a été accepté ou rejeté. Les journaux de flux peuvent être publiés dans CloudWatch Logs (pour effectuer des requêtes avec Logs Insights) ou dans S3 (pour les analyser avec Athena). Ils sont indispensables pour les analyses judiciaires de sécurité (qui s’est connecté à quoi), l’analyse du trafic (identifier les flux à grande largeur de bande) et le dépannage (pourquoi une connexion a-t-elle été rejetée ?). Les journaux de flux fonctionnent au niveau du VPC, du subnet ou de l’ENI individuel.

Avant de créer un VPC, planifiez tous les besoins futurs en matière de connectivité : connectivité sur site (VPN ou Direct Connect) — vérifiez que le CIDR du VPC ne chevauche pas les subnets sur site ; connectivité entre VPC (appairage ou Transit Gateway) — prévoyez des CIDR qui ne se chevauchent pas entre tous les VPC de votre organisation ; accès aux services AWS (points de terminaison de VPC pour S3, DynamoDB et SSM afin d’éviter que le trafic ne passe par Internet) ; et dimensionnement des subnets — laissez une marge dans chaque subnet pour la consommation d’adresses IP par les pods EKS, les fonctions Lambda et les interfaces réseau Elastic.

Dans cette leçon, vous avez appris que : un VPC est un réseau logiquement isolé dans une Région, défini par un bloc CIDR que vous divisez en subnets publics et privés répartis entre des AZ ; AWS réserve 5 IP dans chaque subnet, vous devez donc toujours dimensionner les subnets en tenant compte de cette réduction ; et l’appairage de VPC et Transit Gateway connectent les VPC de manière privée, mais les plages CIDR ne doivent pas se chevaucher. Nous allons ensuite découvrir les Internet Gateways et les tables de routage.