Conception de sous-réseaux multi-AZ pour un VPC 3-tiers réel — le plan CIDR qui tient en année trois

Le premier VPC d’un SaaS 3-tiers est découpé en un après-midi. Quelqu’un choisit 10.0.0.0/16, le tranche en six sous-réseaux /24 — public-a, public-b, private-a, private-b, db-a, db-b — et l’expédie en production. Deux ans plus tard, la plateforme s’est étendue à trois AZ parce que us-east-1c tombe régulièrement, la couche applicative doit héberger des tâches ECS plus des nœuds EKS plus la flotte EC2 historique tournant en parallèle pendant la migration vers EKS, et les sous-réseaux privés /24 sont à 240 IP utilisées sur 251 utilisables. Il n’y a plus de place pour qu’un ASG vert monte en charge, et l’équipe débat à savoir s’il faut reconstruire le VPC ou s’étaler sur un deuxième et vivre avec le routage inter-VPC. Les deux options prennent un trimestre. L’erreur, c’était le /24 initial. Voici la disposition qui ne vous coince pas dans ce coin.

Ce qui se passe

Un VPC /16 donne 65 536 adresses. AWS en réserve cinq par sous-réseau — les quatre premières (réseau, routeur VPC, DNS, usage futur) et la dernière (équivalent diffusion). Un sous-réseau /24 a 256 adresses moins cinq réservées, donc 251 utilisables. Cela paraît beaucoup jusqu’à ce qu’on se rappelle que chaque ENI sur une instance EC2 en consomme une, chaque tâche Fargate en consomme une, chaque Lambda dans un VPC en consomme une par invocation concurrente, chaque endpoint VPC d’interface en consomme une par AZ, chaque nœud ALB et NLB en consomme une par AZ, et un cluster EKS avec le CNI VPC en consomme une par pod.

Les nombres s’empilent vite. Un nœud EKS sur m6i.2xlarge peut héberger environ 58 pods sur le CNI VPC, chacun tenant un /32. Trois nœuds par AZ en pic, c’est 174 IP de pods par AZ avant même de compter le kubelet ou toute autre charge sur le sous-réseau. Un /24 ne suffit pas. Il faut un /22 minimum pour toute AZ qui héberge EKS avec le CNI par défaut, et un /22 ne laisse pas de place pour les nœuds ALB, les interfaces réseau Lambda, les endpoints d’interface et la charge future que vous n’avez pas encore conçue.

La forme du plan est : choisir les AZ d’abord, allouer généreusement par AZ, ne jamais réutiliser le même CIDR dans deux environnements. Un VPC /16 réparti sur trois AZ à /20 par AZ par tier (public, privé, base de données) est la valeur par défaut pour un SaaS qui embauchera son premier SRE avant l’année trois.

Comment vérifier

L’exemple travaillé pour us-east-1, VPC 10.20.0.0/16 :

La plage réservée compte. Quand l’équipe applicative décide qu’elle veut un quatrième tier de sous-réseaux pour ECS-sur-EC2 isolé des sous-réseaux EKS, ou un cinquième tier pour la flotte d’analytique qui ne doit pas voir le trafic de base de données client, ces sous-réseaux sortent de la plage réservée et utilisent la même taille /20, dans le même ordre d’AZ. Le motif reste cohérent entre les environnements et prévisible quand on lit la table de routage.

Les tables de routage suivent le tier, pas l’AZ :

• Une table de routage publique, attachée aux trois sous-réseaux publics. Route par défaut 0.0.0.0/0 vers l’internet gateway. Route locale pour le /16 du VPC.
• Trois tables de routage privées, une par AZ, attachée au sous-réseau privé de cette AZ. Route par défaut 0.0.0.0/0 vers la NAT Gateway locale à l’AZ. Route locale pour le /16 du VPC. La raison pour des tables de routage privées par AZ plutôt qu’une seule table partagée : le trafic sortant doit rester intra-AZ — envoyer le sortant de us-east-1a à travers une NAT Gateway de us-east-1b coûte du transfert inter-AZ et ajoute un mode de panne pour les pannes de us-east-1b.
• Table de routage base de données — aucune route Internet, seulement la route locale du VPC. Attachée aux trois sous-réseaux de base de données. Les sous-réseaux de base de données n’atteignent jamais Internet directement.

Inspecter avec :

aws ec2 describe-subnets \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'Subnets[].[CidrBlock,AvailabilityZone,Tags[?Key==`Name`]|[0].Value]' \
  --output table

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'RouteTables[].[Tags[?Key==`Name`]|[0].Value,Associations[].SubnetId,Routes[?DestinationCidrBlock==`0.0.0.0/0`].GatewayId]' \
  --output table

La sortie doit montrer trois sous-réseaux par tier, la table de routage publique avec une entrée, et trois tables de routage privées chacune avec un ID de NAT Gateway différent.

La correction

La procédure pour disposer un nouveau VPC, dans l’ordre :

1. Choisir le CIDR avant tout le reste. Réservez un /14 ou /12 contigu au niveau de l’organisation pour les VPC AWS, puis taillez un /16 par VPC. Production, recette et développement reçoivent chacun leur propre /16 sans chevauchement, même s’ils vivent dans des comptes différents. Vous les appairerez, ou les attacherez à un Transit Gateway, et dès que deux environnements partagent un CIDR le peering échoue. La convention que nous tenons : 10.0.0.0/8 pour AWS, partitionné par compte et environnement — 10.10.0.0/16 pour le compte de services partagés, 10.20.0.0/16 pour la production, 10.30.0.0/16 pour la recette, etc.

2. Choisir le nombre d’AZ. Trois pour la production. Deux pour la recette ou le développement, où le coût de la NAT Gateway supplémentaire et du transfert inter-AZ l’emporte sur la redondance. Jamais une seule — même un VPC de développement dans une seule AZ est à une panne d’AZ d’une demi-journée de travail perdue.

3. Allouer par AZ, puis par tier. Utilisez le défaut /20 par tier par AZ. Si la charge est connue petite (un seul service web à faible trafic), /22 par tier par AZ est le plancher. En dessous vous rachetez le problème dans dix-huit mois.

4. Étiqueter chaque sous-réseau avec le nom du tier. Name=prod-private-1a, pas Name=subnet-2. Le nom est ce que chaque module Terraform, chaque revue d’IaC et chaque alerte d’incident lit. Un sous-réseau nommé subnet-2 est celui qui se fait supprimer par erreur pendant un nettoyage.

5. Réserver des blocs /20 pour les tiers futurs. Documentez la plage réservée dans le jeu d’étiquettes du VPC et dans le runbook de l’équipe. La prochaine équipe qui ajoute un tier de sous-réseau ne devrait pas avoir à faire de l’archéologie de CIDR.

L’anti-motif qu’on voit le plus : le sous-réseau privé /24 qui a atteint 240 IP utilisées et la réponse de l’équipe a été de créer un deuxième VPC et de l’appairer. Maintenant il y a deux tables de routage à maintenir, deux jeux de NAT Gateway à payer, et le trafic applicatif traverse les VPC sans raison autre que le choix CIDR initial. Le coût de refaire le plan CIDR en année un est une fin de semaine. Le coût en année trois est un trimestre.

L’autre règle qu’on tient : ne dimensionnez pas un sous-réseau en fonction de ce que vous exécutez actuellement. Dimensionnez-le en fonction de ce qu’un cluster EKS, un endpoint d’interface par service, une flotte ECS Fargate et une flotte de concurrences Lambda consommeraient si vous les adoptiez demain. Ce nombre est approximativement (nœuds × max-pods-par-nœud) + (services × 3 endpoints) + (concurrence-lambda) + 20 % de marge. Pour un SaaS de taille moyenne le nombre est dans les bas milliers, ce qui explique pourquoi /22 est le plancher et /20 la valeur par défaut.

Pour la suite multi-VPC une fois que vous dépassez un seul, voir Transit Gateway en étoile. Pour le côté sortant de la conception, voir NAT Gateway vs instance NAT et Endpoints VPC.

Stack Harbor conçoit et audite les topologies VPC en production dans le cadre de Gestion AWS et des Environnements infogérés en continu. Si votre VPC a été découpé avant que l’entreprise n’embauche son premier SRE, commencez par une consultation d’infrastructure.