Diagramme VPC AWS : sous-réseaux, tables de routage et NAT bien dessinés

La plupart des diagrammes VPC sont dessinés une seule fois, au début du projet, en recopiant la carte des ressources de la console. Ils montrent chaque ressource et ne répondent à aucune des questions qu'on vient réellement leur poser : Internet peut-il atteindre cette base de données ? Pourquoi l'application peut-elle télécharger des paquets mais pas recevoir de connexions ? Qu'est-ce qui casse si une zone de disponibilité tombe ?

Ce guide montre comment dessiner un diagramme VPC AWS qui répond à ces questions. Nous prenons une topologie courante, un VPC sur deux zones de disponibilité avec des sous-réseaux publics, privés et de données, et passons en revue les éléments qui déterminent l'accessibilité : sous-réseaux, tables de routage, passerelles, points de terminaison et groupes de sécurité.

Les questions auxquelles un diagramme VPC doit répondre

• Qu'est-ce qu'Internet peut atteindre ? Uniquement les ressources des sous-réseaux publics qui ont une route vers une passerelle Internet, et seulement si leurs groupes de sécurité l'autorisent.
• Comment les ressources privées sortent-elles ? En général par une passerelle NAT, parfois par des points de terminaison VPC, parfois pas du tout.
• Comment le trafic circule-t-il entre les niveaux ? De l'équilibreur de charge vers l'application, de l'application vers la base de données, et sur quels ports.
• Que se passe-t-il si une AZ tombe ? Quelles ressources existent dans chaque zone, et lesquelles sont partagées.

Si le dessin ne permet pas de répondre facilement à l'une de ces questions, il lui faut moins de ressources et plus de structure.

Les briques de base

Élément	Ce que c'est	Comment le dessiner
VPC	Votre réseau privé, avec un bloc CIDR comme 10.0.0.0/16	Le cadre extérieur, CIDR dans l'étiquette
Zone de disponibilité	Un emplacement isolé dans la région	Une colonne ou un cadre dans le VPC
Sous-réseau	Une plage du CIDR du VPC dans une seule AZ	Un cadre dans son AZ, CIDR dans l'étiquette
Table de routage	Des règles qui envoient le trafic d'un sous-réseau vers une cible	Une petite table par niveau de sous-réseaux
Passerelle Internet	La porte du VPC vers Internet	Sur la bordure du VPC, côté Internet
Passerelle NAT	Permet aux sous-réseaux privés d'ouvrir des connexions sortantes	Zonale : dans un sous-réseau public, une par AZ. Régionale : une passerelle pour toutes les AZ, sans sous-réseau
Point de terminaison VPC	Un chemin privé vers les services AWS	Points de terminaison de passerelle pour S3 et DynamoDB ; points de terminaison d'interface dans les sous-réseaux
Groupe de sécurité	Pare-feu avec état sur chaque interface réseau	Règles de ports en étiquettes de liens, pas en boîtes
ACL réseau	Filtre sans état au niveau du sous-réseau	Une note sur le sous-réseau, seulement si vous utilisez des règles personnalisées

Deux faits structurent toute la disposition. Un sous-réseau se trouve dans exactement une zone de disponibilité : il ne peut donc jamais s'étendre sur plusieurs colonnes d'AZ de votre diagramme. Et une passerelle NAT standard (zonale) se trouve dans une seule AZ : si la seule passerelle est dans l'AZ a, les sous-réseaux privés de l'AZ b perdent leur accès sortant quand l'AZ a tombe. Depuis novembre 2025, AWS propose aussi des passerelles NAT régionales, qui s'étendent d'elles-mêmes sur les AZ et n'ont pas besoin de sous-réseau public ; cet exemple utilise des passerelles zonales.

L'exemple : deux AZ, trois niveaux

Le VPC utilise 10.0.0.0/16 dans deux zones de disponibilité, avec trois sous-réseaux dans chacune :

Niveau	AZ a	AZ b	Route pour 0.0.0.0/0
Public	10.0.0.0/24	10.0.1.0/24	Passerelle Internet
Application (privé)	10.0.10.0/24	10.0.11.0/24	Passerelle NAT de la même AZ
Données (privé)	10.0.20.0/24	10.0.21.0/24	Aucune

Chaque table de routage contient aussi la route local pour 10.0.0.0/16, qui permet aux sous-réseaux du VPC de se joindre entre eux ; ce sont ensuite les groupes de sécurité qui décident de ce qui est réellement autorisé. AWS réserve cinq adresses dans chaque sous-réseau, donc un /24 vous donne 251 adresses utilisables.

Ce qui tourne où :

• Un Application Load Balancer a des nœuds dans les deux sous-réseaux publics et accepte le trafic HTTPS venant d'Internet.
• Les serveurs d'application (instances EC2 ou tâches ECS) tournent dans les deux sous-réseaux d'application et n'acceptent que le trafic provenant du groupe de sécurité de l'ALB.
• Une instance principale RDS PostgreSQL tourne dans un sous-réseau de données, avec une instance de secours dans l'autre. RDS exige un groupe de sous-réseaux de base de données avec des sous-réseaux dans au moins deux AZ.
• Une passerelle NAT dans chaque sous-réseau public donne aux serveurs d'application un accès sortant pour les mises à jour et les API tierces.
• Un point de terminaison de passerelle pour S3 permet aux serveurs d'application d'atteindre S3 sans passer par la passerelle NAT, ce qui économise aussi des frais de traitement des données NAT.

Voici le diagramme :

Des règles de mise en page pour rester lisible

Des colonnes pour les AZ, des lignes pour les niveaux

Placez les zones de disponibilité côte à côte et les niveaux de haut en bas : public en haut, puis application, puis données. L'accessibilité se lit alors de haut en bas, et une ressource absente d'une colonne saute aux yeux.

Placer la passerelle Internet sur la bordure

La passerelle Internet est attachée au VPC entier, pas à un sous-réseau. Dessinez-la sur le cadre du VPC, entre Internet et les sous-réseaux publics.

Montrer les routes dans une table, pas avec des flèches partout

Une flèche de chaque sous-réseau vers chaque passerelle transforme le diagramme en toile d'araignée. Une petite table de routage par niveau, comme celle ci-dessus, dit la même chose avec précision. Ne tracez des flèches que pour les principaux chemins de trafic.

Mettre les règles des groupes de sécurité sur les liens

Les groupes de sécurité appartiennent aux interfaces réseau, pas aux sous-réseaux : les cadres ne sont donc pas la bonne forme pour les représenter. Étiquetez plutôt les liens : HTTPS 443 from internet, 8080 from ALB SG, 5432 from app SG. C'est l'information que les gens cherchent.

Garder l'appairage et le VPN en bordure

Les passerelles de transit, les connexions d'appairage et les VPN Site-to-Site relient le VPC à d'autres réseaux. Dessinez-les sur la bordure du VPC, avec les CIDR distants dans l'étiquette, et gardez le côté distant sur son propre diagramme.

Erreurs fréquentes

• Un sous-réseau qui s'étend sur deux AZ. Cela ne peut pas exister. Dessinez un sous-réseau par AZ, même s'ils sont jumeaux.
• Une seule passerelle NAT zonale pour les deux AZ, sans le signaler. C'est peut-être un choix de coût délibéré ; écrivez-le sur le diagramme pour que personne ne suppose que les zones sont indépendantes.
• Des groupes de sécurité dessinés comme des boîtes imbriquées. Ils se chevauchent librement et s'appliquent par interface ; l'imbrication suggère des règles qui n'existent pas.
• Recopier la carte des ressources de la console, avec chaque interface réseau et chaque association de table de routage. Utile pour un audit, illisible pour la conception.
• Pas de CIDR. Ce sont les plages qui se chevauchent qui bloquent l'appairage plus tard. Indiquez le CIDR sur chaque cadre de VPC et de sous-réseau.

Construire ce diagramme dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack Réseau, ajoutez un cadre VPC et réglez son CIDR sur 10.0.0.0/16.
3. À l'intérieur, ajoutez des éléments Cadre du pack Base pour les deux AZ, puis des cadres Sous-réseau du pack Réseau dans chaque AZ, avec leurs CIDR.
4. Ajoutez un nœud Internet du pack Réseau à l'extérieur du VPC et un Routeur sur la bordure du VPC pour la passerelle Internet.
5. Ajoutez depuis le pack Cloud un Répartiteur de charge cloud pour l'ALB, des nœuds Instance de calcul pour les serveurs d'application et des nœuds Base de données gérée pour les instances RDS principale et de secours. Utilisez des nœuds Routeur du pack Réseau pour les passerelles NAT.
6. Connectez les ports et étiquetez les liens avec les ports et les groupes de sécurité source.
7. Ajoutez un Tableau du pack Base avec les tables de routage, et une Note pour les décisions comme « une passerelle NAT par AZ ».

L'exemple complet dépasse les 15 nœuds de diagramme de l'offre Free : un diagramme VPC aussi détaillé convient bien à l'offre Pro. Pour les architectures multirégions, consultez le diagramme d'architecture AWS multirégion, et pour d'autres modèles réseau, la page de cas d'usage réseau.

FAQ

Faut-il faire figurer chaque sous-réseau sur le diagramme ? Sur le diagramme de conception du VPC, oui, car l'accessibilité dépend du sous-réseau et de la table de routage. Sur un diagramme d'application, un cadre par niveau suffit généralement.

Ai-je besoin d'une passerelle NAT dans chaque AZ ? Avec des passerelles NAT zonales, oui, pour que les zones restent indépendantes. Une seule passerelle NAT zonale fait économiser de l'argent, mais rend chaque AZ dépendante d'une seule zone pour le trafic sortant et ajoute des frais de transfert de données entre AZ. Une passerelle NAT régionale est une passerelle unique qui s'étend à chaque AZ où tournent des charges de travail. Quel que soit votre choix, écrivez-le sur le diagramme.

Où placer les points de terminaison VPC ? Les points de terminaison de passerelle (S3 et DynamoDB) sont des cibles dans les tables de routage : dessinez-les sur la bordure du VPC et mentionnez-les dans la table de routage. Les points de terminaison d'interface sont des interfaces réseau dans vos sous-réseaux : dessinez-les dans les sous-réseaux qui les hébergent.

Groupes de sécurité ou ACL réseau sur le diagramme ? Les groupes de sécurité en étiquettes de liens, toujours. Les ACL réseau seulement en note sur le sous-réseau, et uniquement si vous avez modifié les valeurs par défaut.

Puis-je générer ce diagramme depuis mon compte AWS ? Archboard ne lit pas votre compte AWS. Dessinez l'architecture que vous visez, puis comparez-la avec la carte des ressources de la console lors des revues.

Commencez gratuitement — un siège, sans carte bancaire.