Architecture Reseau multi compte

🌐 Architecture Réseau AWS : Connectivité, Partage et Gestion IP

1. Le Réseau Multi-Comptes : Connecter les VPC

Lorsque tu as des dizaines de VPC répartis dans plusieurs comptes, il faut les relier efficacement. Deux grands modèles s’affrontent.

Le VPC Peering (La connexion point à point)**

C’est la méthode la plus simple pour relier deux VPC, même s’ils sont dans des comptes ou des régions différentes.

• Le principe : Une connexion directe 1-à-1 entre un VPC A et un VPC B. Le trafic passe par le réseau privé d’AWS.

• La limite majeure (Pas de transitivité) : Si le VPC A est connecté au VPC B, et le VPC B est connecté au VPC C… Le VPC A ne peut pas communiquer avec le VPC C. Il faut créer une connexion Peering directement entre A et C.

• Le problème à l’échelle : Pour connecter tous les VPC entre eux (architecture “Full Mesh”), le nombre de connexions explose selon la formule mathématique $N(N-1)/2$ (où $N$ est le nombre de VPC). À 10 VPC, tu as déjà 45 connexions à gérer manuellement.

AWS Transit Gateway (Le routeur centralisé)**

C’est la solution moderne et évolutive pour le réseau multi-comptes.

• Le principe (Hub-and-Spoke) : Le Transit Gateway (TGW) agit comme un hub central. Tous tes VPC, tes VPN sur site, et tes connexions Direct Connect s’attachent au TGW.

• Routage centralisé : Le TGW possède des tables de routage. Il décide quel VPC peut parler à quel autre VPC, simplifiant drastiquement l’architecture.

• Support du multicast : Contrairement au VPC classique, le TGW supporte le trafic réseau Multicast.

---

2. Le Partage de Ressources : AWS RAM

Plutôt que de recréer les mêmes ressources dans chaque compte, AWS a créé un service dédié : AWS Resource Access Manager (RAM).

• Le rôle de RAM : Il permet à un compte AWS de partager des ressources spécifiques avec d’autres comptes de l’organisation.

• Intégration avec Organizations : Tu peux partager une ressource directement avec une Unité Organisationnelle (OU) entière. Si un nouveau compte rejoint cette OU, il reçoit automatiquement l’accès à la ressource partagée.

• Ce qu’on peut partager (Exemples clés) : Des sous-réseaux (Subnets), un Transit Gateway, des règles de pare-feu (Route 53 Resolver rules, Network Firewall policies), des licences (License Manager).

---

3. Le cas d’usage ultime : Le VPC Sharing

C’est une pratique de gouvernance très populaire, rendue possible par AWS RAM.

• Le concept : Un compte centralisé (ex: “Compte Network”) crée un grand VPC avec plusieurs sous-réseaux (Subnets). Il utilise AWS RAM pour partager certains sous-réseaux avec les comptes applicatifs (“Compte Dev A”, “Compte Dev B”).

• Séparation stricte des responsabilités (Separation of Duties) :

• L’équipe Réseau (Compte Network) : Gère le VPC, les plages d’adresses IP, les tables de routage, les passerelles (Internet Gateway, NAT) et les pare-feux (NACL).

• L’équipe Applicative (Comptes Dev) : Ne voit que le sous-réseau partagé. Elle peut y lancer ses instances EC2 ou bases de données RDS, et elle gère uniquement ses propres Security Groups (SG).

• L’avantage économique : Les ressources comme les NAT Gateways coûtent cher. En partageant le VPC, toutes les applications utilisent la même NAT Gateway gérée par le compte réseau, ce qui réduit considérablement la facture.

---

4. L’Overlapping IP : L’Ennemi du Réseau Multi-Comptes

L’overlapping se produit lorsque deux réseaux (VPC, ou un VPC et ton réseau sur site) utilisent la même plage d’adresses IP (le même bloc CIDR), par exemple 10.0.0.0/16.

Le problème de routage : Si une machine dans le VPC A (10.0.0.5) veut parler à une machine dans le VPC B (10.0.0.8) mais que les deux VPC utilisent la plage 10.0.0.0/16, le routeur est incapable de savoir si le paquet doit rester en local ou être envoyé vers l’autre VPC.

L’impact sur tes architectures AWS :

• VPC Peering : AWS bloque purement et simplement la création d’une connexion Peering si les blocs CIDR des deux VPC se chevauchent, même partiellement. C’est une impossibilité technique.

• Transit Gateway (TGW) : Le TGW te laissera attacher deux VPC avec des IP identiques, mais le routage entre eux sera impossible directement. Le trafic sera asymétrique ou se perdra.

• VPC Sharing : Comme tout se passe dans un seul grand VPC, l’overlapping est impossible par design (AWS empêche de créer deux Subnets avec la même plage dans un même VPC).

La solution de Gouvernance : AWS IPAM

Pour éviter que chaque équipe crée son VPC dans son coin avec le sempiternel 10.0.0.0/16, AWS propose un service dédié à la gouvernance réseau : Amazon VPC IP Address Manager (IPAM).

• Centralisation : IPAM s’intègre parfaitement avec AWS Organizations. Tu l’actives dans le compte réseau central.

• Pools d’adresses (IP Pools) : Tu définis ton méga-bloc d’IP d’entreprise (ex: 10.0.0.0/8), puis tu le découpes en sous-pools par région ou par environnement (Prod, Dev).

• Allocation automatisée : Quand un développeur crée un VPC, il ne tape plus d’adresse IP manuellement. Il demande simplement “Donne-moi un /24 depuis le pool de Dev”. IPAM lui attribue une plage unique, garantissant zéro chevauchement.

Comment faire quand l’overlapping est inévitable ? (Plan B)**

Parfois, tu n’as pas le choix (ex: ton entreprise rachète une autre entreprise qui a utilisé exactement les mêmes plages IP que toi).

• Private NAT Gateway : Tu peux utiliser des passerelles NAT privées pour faire de la traduction d’adresses (Network Address Translation). Les machines communiqueront via de fausses adresses IP qui seront traduites à la volée pour éviter le conflit. C’est complexe, coûteux, mais parfois indispensable.

---

💡 Aide-mémoire Obsidian (Réseau & IP)

• Peering vs TGW : Privilégier le VPC Peering pour 2 à 3 VPC isolés (coût très faible). Passer au Transit Gateway dès que l’architecture devient complexe ou nécessite du routage transitif.

• Limites de RAM : On ne partage jamais un VPC entier via RAM, on partage uniquement ses sous-réseaux (Subnets).

• Security Groups dans un VPC partagé : Bien qu’ils soient dans le même réseau, les comptes membres d’un VPC partagé ne peuvent pas se référencer mutuellement via l’ID de leurs Security Groups (à moins de faire des configurations spécifiques complexes).

• Transit Gateway inter-région : Pour connecter des régions (ex: Paris et Francfort), on crée un TGW dans chaque région, et on établit un “TGW Peering” entre les deux.

• Règle de base IP : Toujours planifier son adressage IP (Plan d’adressage) avant de créer des comptes et des VPC.

• Gouvernance IPAM : Utiliser AWS IPAM délégué à un compte “Network” pour automatiser la distribution des CIDR sans conflit à travers toute l’organisation.

• Taille des VPC : Ne jamais créer de VPC trop grands (comme des /16) si on n’a pas besoin de 65 536 IP. Préférer des /20 ou /24 pour économiser l’espace d’adressage.

• IPv6 : Si l’espace IPv4 vient à manquer ou que l’overlapping devient un cauchemar, le passage à IPv6 (qui offre une quantité quasi infinie d’adresses publiques uniques) est la recommandation d’AWS à long terme.