Amazon VPC Cheat Sheet

1. VPC en une phrase

Amazon VPC, ou Virtual Private Cloud, permet de créer un réseau virtuel isolé dans AWS, dans lequel vous déployez vos ressources comme EC2, RDS, Lambda, ECS, EKS ou des Load Balancers.

À retenir :

• Un VPC est un réseau privé dédié à votre compte AWS.
• Vous choisissez la plage d’adresses IP du réseau.
• Vous créez des subnets pour organiser vos ressources.
• Vous contrôlez les routes, les accès Internet, les flux privés et les règles de sécurité réseau.
• Amazon VPC est la base réseau de nombreuses architectures AWS. AWS décrit un VPC comme un réseau virtuel logiquement isolé dans le cloud AWS.

Ressource officielle :

• Documentation AWS : What is Amazon VPC?

2. Les concepts essentiels VPC

• VPC
  • Réseau virtuel isolé dans AWS.
  • Il contient vos subnets, routes, gateways, interfaces réseau et ressources cloud.
• CIDR Block
  • Plage d’adresses IP du VPC.
  • Exemple : 10.0.0.0/16.
  • À choisir avec soin pour éviter les conflits avec d’autres réseaux.
• Subnet
  • Sous-réseau à l’intérieur d’un VPC.
  • Chaque subnet appartient à une seule Availability Zone.
  • Un subnet peut être public, privé ou isolé selon sa table de routage.
• Route Table
  • Définit où le trafic réseau doit aller.
  • Exemple : trafic local dans le VPC, trafic Internet via Internet Gateway, trafic privé via NAT Gateway, Transit Gateway ou VPC Peering.
• Internet Gateway
  • Permet à un VPC d’avoir une connectivité Internet entrante et sortante pour les ressources publiques.
• NAT Gateway
  • Permet aux ressources dans des subnets privés de sortir vers Internet sans être directement accessibles depuis Internet.
• Security Group
  • Pare-feu virtuel attaché à une ressource comme une instance EC2, une interface réseau, une base RDS ou un Load Balancer.
  • Il contrôle le trafic entrant et sortant au niveau de la ressource.
• Network ACL, ou NACL
  • Pare-feu au niveau subnet.
  • Il contrôle le trafic entrant et sortant pour les subnets associés.
• VPC Flow Logs
  • Permet de capturer les informations sur le trafic IP entrant et sortant d’un VPC, subnet ou interface réseau.
  • Utile pour le troubleshooting, la sécurité et l’audit.

3. VPC, subnet et Availability Zone

À comprendre dès le départ :

• Un VPC est régional.
• Un subnet est lié à une seule Availability Zone.
• Pour une application résiliente, il faut généralement utiliser plusieurs subnets dans plusieurs Availability Zones.
• Les ressources d’un même VPC peuvent communiquer entre elles via le routage local, si les règles de sécurité l’autorisent.
• Les subnets servent à organiser les couches réseau : publique, privée, base de données, administration, inspection, etc.

Exemple de logique de découpage :

• Subnets publics :
  • Load Balancers publics.
  • Bastion hosts, si nécessaire.
  • Ressources qui doivent recevoir du trafic Internet directement.
• Subnets privés :
  • Instances applicatives.
  • Conteneurs ECS ou EKS.
  • Bases de données.
  • Services internes.
• Subnets isolés :
  • Ressources sans accès Internet direct.
  • Bases de données sensibles.
  • Workloads très contrôlés.

Ressource officielle :

• Documentation AWS : Subnets for your VPC

4. Public subnet, private subnet et isolated subnet

Public subnet

Un subnet est généralement considéré comme public lorsqu’il possède une route vers une Internet Gateway.

À utiliser pour :

• Application Load Balancer public.
• Bastion host, si vous l’utilisez encore.
• Ressources qui doivent être accessibles depuis Internet.

À retenir :

• Une instance dans un subnet public doit aussi avoir une adresse IP publique ou Elastic IP pour être joignable depuis Internet.
• Le subnet public ne rend pas automatiquement toutes les ressources publiques.
• Les Security Groups et NACLs continuent de contrôler le trafic.

Private subnet

Un subnet privé n’a pas de route directe vers une Internet Gateway.

À utiliser pour :

• Serveurs applicatifs.
• Bases de données.
• Services internes.
• Tâches ECS ou workloads backend.

À retenir :

• Les ressources privées peuvent sortir vers Internet via une NAT Gateway si nécessaire.
• Elles ne sont pas directement joignables depuis Internet.
• C’est le choix recommandé pour la majorité des composants applicatifs non publics.

Isolated subnet

Un subnet isolé n’a pas de route vers Internet, ni directe ni via NAT Gateway.

À utiliser pour :

• Bases de données très sensibles.
• Workloads internes.
• Environnements réglementés.
• Ressources qui n’ont pas besoin d’Internet.

À retenir :

• Très bon niveau d’isolation.
• Il faut prévoir des endpoints privés ou des routes internes si les ressources doivent accéder à des services AWS.

5. Tables de routage

Une table de routage indique comment le trafic quitte un subnet.

À retenir :

• Chaque subnet est associé à une route table.
• Une route table contient des routes.
• La route locale du VPC existe par défaut.
• Une route vers 0.0.0.0/0 indique la destination par défaut pour le trafic IPv4 externe.
• Pour Internet public, 0.0.0.0/0 pointe généralement vers une Internet Gateway.
• Pour un subnet privé, 0.0.0.0/0 peut pointer vers une NAT Gateway.
• Pour un réseau d’entreprise, une route peut pointer vers Transit Gateway, Virtual Private Gateway ou Direct Connect selon l’architecture.

Exemples de routes courantes :

• 10.0.0.0/16 -> local
  • Trafic interne au VPC.
• 0.0.0.0/0 -> Internet Gateway
  • Sortie vers Internet pour un subnet public.
• 0.0.0.0/0 -> NAT Gateway
  • Sortie Internet contrôlée depuis un subnet privé.
• 192.168.0.0/16 -> Transit Gateway
  • Routage vers un autre réseau.

Bonnes pratiques :

• Séparer les route tables publiques et privées.
• Nommer clairement les route tables.
• Éviter de placer une route Internet dans des subnets qui n’en ont pas besoin.
• Documenter les routes vers les réseaux externes.
• Vérifier les routes lors du troubleshooting réseau.

6. Security Groups

Un Security Group est un pare-feu virtuel attaché à une ressource réseau.

À retenir :

• Il agit au niveau de la ressource.
• Il contrôle le trafic entrant et sortant.
• Il est stateful.
• Si une requête entrante est autorisée, la réponse sortante est automatiquement autorisée.
• Il ne contient que des règles d’autorisation, pas de règles de refus explicite.
• Les règles peuvent utiliser des CIDR, des Security Groups ou des préfixes gérés comme source ou destination.

AWS recommande les Security Groups comme point de départ pour contrôler le trafic entre les ressources qui utilisent des Elastic Network Interfaces, comme EC2, ECS, EKS ou RDS.

Exemples d’usages

• Autoriser HTTP 80 depuis Internet vers un Load Balancer.
• Autoriser HTTPS 443 depuis Internet vers un Load Balancer.
• Autoriser le trafic applicatif depuis le Load Balancer vers les instances EC2.
• Autoriser MySQL 3306 uniquement depuis le Security Group de l’application.
• Autoriser PostgreSQL 5432 uniquement depuis le Security Group backend.
• Autoriser SSH 22 uniquement depuis une IP d’administration précise, ou préférer Session Manager.

Bonnes pratiques Security Groups

• Ouvrir uniquement les ports nécessaires.
• Éviter 0.0.0.0/0 sur SSH ou RDP.
• Préférer les références entre Security Groups plutôt que les IP fixes internes.
• Créer des Security Groups par rôle :
  • sg-alb-public
  • sg-app-private
  • sg-db-private
• Séparer les règles par couche applicative.
• Supprimer les règles inutilisées.
• Documenter les règles sensibles.
• Garder les règles sortantes restrictives si le contexte de sécurité l’exige.
• Utiliser VPC Flow Logs pour diagnostiquer les flux autorisés ou bloqués.

Ressource officielle :

• Documentation AWS : Control traffic to your AWS resources using security groups

7. Network ACLs, ou NACLs

Une Network ACL est une couche de filtrage réseau appliquée au niveau du subnet.

À retenir :

• Une NACL est associée à un ou plusieurs subnets.
• Chaque subnet est associé à une seule NACL à la fois.
• Une NACL contrôle le trafic entrant et sortant au niveau subnet.
• Elle est stateless.
• Il faut donc autoriser explicitement le trafic dans les deux sens.
• Elle supporte des règles Allow et Deny.
• Les règles sont évaluées dans l’ordre croissant des numéros.
• La première règle qui correspond au trafic est appliquée.
• Si aucune règle ne correspond, le trafic est refusé.

Default NACL

À retenir :

• Chaque VPC possède une NACL par défaut.
• La NACL par défaut autorise tout le trafic entrant et sortant.
• Elle contient aussi une règle finale implicite qui refuse le trafic non correspondant.

Custom NACL

À retenir :

• Une NACL personnalisée peut être créée pour autoriser ou refuser du trafic spécifique au niveau subnet.
• Les règles par défaut d’une NACL personnalisée refusent le trafic si aucune règle explicite ne l’autorise.
• Elle est utile comme couche de sécurité supplémentaire.

Bonnes pratiques NACLs

• Utiliser les NACLs comme couche complémentaire, pas comme seul contrôle.
• Garder les règles simples.
• Utiliser les Security Groups pour la majorité des contrôles fins.
• Utiliser les NACLs pour bloquer rapidement certains CIDR au niveau subnet.
• Prévoir les ports éphémères pour les réponses réseau.
• Éviter une complexité excessive qui rend le troubleshooting difficile.
• Documenter les règles Deny.
• Tester les changements avec prudence.

Ressource officielle :

• Documentation AWS : Control subnet traffic with network access control lists

8. Security Groups vs NACLs

Security Groups

À retenir :

• Niveau ressource.
• Stateful.
• Règles Allow uniquement.
• Toutes les règles applicables sont évaluées.
• Idéal pour contrôler précisément l’accès à EC2, RDS, ALB, ECS, EKS, etc.
• Très utilisé au quotidien.

NACLs

À retenir :

• Niveau subnet.
• Stateless.
• Règles Allow et Deny.
• Règles évaluées par numéro, de la plus petite à la plus grande.
• Première règle correspondante appliquée.
• Utile comme barrière supplémentaire au niveau réseau.

AWS résume la différence ainsi : les Security Groups contrôlent le trafic au niveau de l’instance ou de la ressource, tandis que les Network ACLs contrôlent le trafic au niveau subnet.

Tableau de comparaison

9. Exemple de logique réseau courante

Load Balancer public

Security Group du Load Balancer :

• Autoriser HTTP 80 depuis 0.0.0.0/0, si nécessaire.
• Autoriser HTTPS 443 depuis 0.0.0.0/0.
• Sortie autorisée vers le Security Group applicatif.

Security Group de l’application :

• Autoriser le port applicatif uniquement depuis le Security Group du Load Balancer.
• Ne pas autoriser directement Internet.

Application privée

Security Group applicatif :

• Entrée autorisée depuis le Load Balancer.
• Sortie autorisée vers la base de données ou les services nécessaires.
• Accès administratif via Systems Manager Session Manager de préférence.

Base de données privée

Security Group base de données :

• Autoriser le port DB uniquement depuis le Security Group applicatif.
• Refuser tout accès direct depuis Internet.
• Ne pas placer la base de données dans un subnet public.

À retenir :

• Internet ne doit généralement pas accéder directement aux instances applicatives ou aux bases de données.
• Le Load Balancer public reçoit le trafic.
• Les ressources applicatives et données restent dans des subnets privés.
• Les Security Groups contrôlent précisément les flux entre couches.

10. Internet Gateway, NAT Gateway et VPC Endpoints

Internet Gateway

À utiliser pour :

• Donner un accès Internet aux ressources dans des subnets publics.
• Permettre à un Load Balancer public d’être accessible.
• Permettre à une instance publique d’envoyer et recevoir du trafic Internet.

À retenir :

• Le subnet doit avoir une route vers l’Internet Gateway.
• La ressource doit avoir une IP publique pour être accessible depuis Internet.
• Les Security Groups et NACLs doivent autoriser le trafic.

NAT Gateway

À utiliser pour :

• Permettre à des ressources privées de sortir vers Internet.
• Télécharger des mises à jour.
• Appeler des APIs publiques.
• Accéder à Internet sans rendre les ressources privées accessibles en entrée.

À retenir :

• La NAT Gateway est généralement placée dans un subnet public.
• Les subnets privés pointent vers elle via leur route table.
• Elle peut générer des coûts importants.
• Pour la haute disponibilité, prévoir une NAT Gateway par Availability Zone.

VPC Endpoints

À utiliser pour :

• Accéder à certains services AWS sans passer par Internet.
• Réduire l’exposition réseau.
• Améliorer la sécurité et parfois réduire certains coûts de data transfer.

Types principaux :

• Gateway Endpoint
  • Utilisé notamment pour S3 et DynamoDB.
• Interface Endpoint
  • Basé sur AWS PrivateLink.
  • Utilisé pour de nombreux services AWS.

À retenir :

• Les VPC Endpoints sont très utiles pour les workloads privés.
• Ils évitent souvent d’avoir besoin d’un accès Internet pour joindre des services AWS.
• Ils s’intègrent bien avec une stratégie de subnets privés ou isolés.

11. VPC Flow Logs

VPC Flow Logs permet de journaliser les flux IP au niveau :

• VPC.
• Subnet.
• Interface réseau.

À utiliser pour :

• Diagnostiquer un problème réseau.
• Comprendre pourquoi une connexion échoue.
• Auditer les flux réseau.
• Détecter du trafic inattendu.
• Vérifier si une règle Security Group ou NACL est trop permissive ou trop restrictive.

À retenir :

• Les logs peuvent être publiés vers CloudWatch Logs ou Amazon S3.
• Flow Logs ne remplace pas un outil complet d’inspection applicative.
• C’est une ressource essentielle pour le troubleshooting réseau.

Bonnes pratiques :

• Activer Flow Logs sur les VPC critiques.
• Centraliser les logs.
• Définir une durée de rétention.
• Analyser régulièrement les flux rejetés.
• Utiliser les logs pour valider les règles réseau.

12. Bonnes pratiques VPC

Design réseau

• Choisir un CIDR suffisamment large pour la croissance future.
• Éviter les CIDR qui se chevauchent avec les réseaux d’entreprise.
• Prévoir plusieurs Availability Zones.
• Séparer les couches réseau avec des subnets dédiés.
• Éviter de tout placer dans un seul subnet.
• Utiliser des noms clairs pour les subnets, route tables, Security Groups et NACLs.
• Prévoir l’adressage IP avant de lancer les ressources.
• Documenter les choix de routage.

Sécurité

• Placer les ressources publiques uniquement quand c’est nécessaire.
• Garder les bases de données dans des subnets privés ou isolés.
• Ne pas ouvrir SSH ou RDP à tout Internet.
• Utiliser Systems Manager Session Manager pour l’administration.
• Utiliser les Security Groups comme contrôle principal.
• Utiliser les NACLs comme couche supplémentaire si nécessaire.
• Activer VPC Flow Logs sur les environnements critiques.
• Utiliser Network Access Analyzer pour identifier les accès réseau non souhaités.
• Appliquer une approche de défense en profondeur.

Coût

• Surveiller les coûts des NAT Gateways.
• Éviter de faire passer tout le trafic privé par une NAT Gateway si un VPC Endpoint est plus adapté.
• Utiliser des Gateway Endpoints pour S3 et DynamoDB quand pertinent.
• Supprimer les VPC, NAT Gateways, endpoints et Elastic IP inutilisés.
• Éviter les architectures réseau inutilement complexes.
• Surveiller les coûts de data transfer inter-AZ, inter-région et vers Internet.

Exploitation

• Utiliser des tags pour identifier les composants réseau.
• Activer la journalisation sur les environnements sensibles.
• Tester les règles réseau avant la production.
• Automatiser la création réseau avec CloudFormation, CDK ou Terraform.
• Garder une documentation simple des flux autorisés.
• Utiliser Reachability Analyzer pour tester les chemins réseau.
• Revoir régulièrement les règles Security Groups et NACLs.

13. Erreurs fréquentes à éviter

• Choisir un CIDR trop petit.
• Utiliser un CIDR qui chevauche le réseau d’entreprise.
• Mettre toutes les ressources dans un seul subnet.
• Placer une base de données dans un subnet public.
• Croire qu’un subnet public rend automatiquement toutes les instances publiques.
• Oublier qu’une instance doit avoir une IP publique pour être joignable depuis Internet.
• Ouvrir SSH 22 ou RDP 3389 à 0.0.0.0/0.
• Utiliser les NACLs pour des règles trop fines et difficiles à maintenir.
• Oublier que les NACLs sont stateless.
• Bloquer involontairement les ports éphémères avec une NACL.
• Confondre route table et Security Group.
• Oublier de créer une route vers la NAT Gateway pour les subnets privés.
• Créer une seule NAT Gateway pour plusieurs AZ sans comprendre l’impact résilience et data transfer.
• Ne pas activer VPC Flow Logs sur les environnements critiques.
• Ne pas documenter les règles réseau sensibles.

14. Mini méthode LCF pour concevoir un VPC

Avant de créer un VPC, posez-vous ces questions :

• Quel est le besoin du réseau ?
  • Application web, plateforme e-learning, backend API, data platform, lab, environnement de production ?
• Quelle plage CIDR utiliser ?
  • Éviter les chevauchements avec les autres VPC, bureaux, VPN ou réseaux clients.
• Combien d’Availability Zones utiliser ?
  • Pour la production : au moins deux AZ dans la majorité des cas.
• Quels subnets créer ?
  • Publics pour les points d’entrée.
  • Privés pour les applications.
  • Isolés pour les bases de données ou ressources sensibles.
• Quelles routes sont nécessaires ?
  • Internet Gateway pour le public.
  • NAT Gateway pour la sortie Internet privée.
  • VPC Endpoints pour accéder aux services AWS sans Internet.
  • Transit Gateway ou VPN si connexion avec d’autres réseaux.
• Quels flux doivent être autorisés ?
  • Internet vers Load Balancer.
  • Load Balancer vers application.
  • Application vers base de données.
  • Application vers services AWS.
  • Administration via Session Manager ou accès restreint.
• Quels contrôles appliquer ?
  • Security Groups au niveau ressource.
  • NACLs au niveau subnet si besoin.
  • Flow Logs pour audit et diagnostic.
  • Tags et documentation.

15. Ressources officielles AWS pour approfondir

• Amazon VPC User Guide
  • Guide principal pour comprendre et administrer Amazon VPC.
• How Amazon VPC works
  • Explication officielle du fonctionnement d’un VPC, des subnets, gateways et Security Groups.
• Subnets for your VPC
  • Documentation officielle sur les subnets.
• Control traffic to your AWS resources using security groups
  • Documentation officielle sur les Security Groups.
• Control subnet traffic with network access control lists
  • Documentation officielle sur les NACLs.
• Security groups and network ACLs
  • Ressource AWS comparant Security Groups et NACLs dans une logique de défense en profondeur.
• Security best practices for your VPC
  • Bonnes pratiques de sécurité pour Amazon VPC.
• AWS Well-Architected Framework — Security Pillar
  • Livre blanc AWS pour appliquer les bonnes pratiques de sécurité, y compris la protection réseau.
• Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
  • Livre blanc AWS pour concevoir des architectures réseau AWS évolutives et sécurisées.

16. Résumé à mémoriser

• Un VPC est un réseau virtuel isolé dans AWS.
• Un VPC est régional.
• Un subnet appartient à une seule Availability Zone.
• Les subnets publics ont généralement une route vers une Internet Gateway.
• Les subnets privés n’ont pas d’accès Internet entrant direct.
• Les NAT Gateways permettent aux ressources privées de sortir vers Internet.
• Les VPC Endpoints permettent d’accéder à certains services AWS sans passer par Internet.
• Les Security Groups contrôlent le trafic au niveau ressource.
• Les Security Groups sont stateful.
• Les NACLs contrôlent le trafic au niveau subnet.
• Les NACLs sont stateless.
• Les Security Groups sont le contrôle principal dans la majorité des cas.
• Les NACLs ajoutent une couche de défense supplémentaire.
• VPC Flow Logs est essentiel pour comprendre et diagnostiquer les flux réseau.
• Une bonne conception VPC repose sur l’isolation, le routage maîtrisé, la sécurité par couche et la visibilité.