Connectivité Avancée dans AWS

Dans le cloud AWS, les entreprises évoluent souvent vers des architectures multi-réseaux où plusieurs VPC (Virtual Private Cloud) doivent communiquer entre eux ou avec des réseaux externes de manière privée. AWS propose plusieurs solutions de connectivité avancée pour répondre à ces besoins, notamment l’appairage de VPC (VPC Peering), AWS Transit Gateway et AWS PrivateLink. Ce cours présente ces trois services en expliquant leur fonctionnement, leurs cas d’usage, ainsi que leurs avantages, limites et bonnes pratiques d’utilisation. Le ton se veut professionnel mais accessible, pour guider pas à pas des élèves de niveau débutant à intermédiaire à travers ces concepts de réseautique AWS.

Appairage de VPC (VPC Peering)

Fonctionnement de l’appairage de VPC

L’appairage de VPC est une connexion réseau privée établie directement entre deux VPC distincts. Cette connexion permet aux ressources des deux VPC de communiquer entre elles via des adresses IP privées, comme si elles faisaient partie du même réseau interne. Il n’y a aucun appareil ou passerelle intermédiaire en jeu : le trafic passe de l’un à l’autre au sein du backbone d’AWS, sans transiter par Internet[^1][^2]. Les deux VPC peuvent appartenir à des comptes AWS différents et même être situés dans des régions AWS différentes, tant que leurs plages d’adresses ne se chevauchent pas.

Une fois la connexion de peering créée (acceptée par les deux parties), chaque propriétaire de VPC doit mettre à jour sa table de routage pour y ajouter une route pointant vers le VPC pair afin que le trafic privé soit effectivement acheminé par le peering. Il est également souvent nécessaire d’ajuster les groupes de sécurité des instances pour autoriser le trafic provenant du VPC appairé. L’appairage de VPC supporte tous les protocoles IP (TCP, UDP, ICMP, etc.) de manière bidirectionnelle. En somme, il s’agit d’un moyen simple et direct pour interconnecter deux environnements VPC et permettre une communication interne sécurisée (aucun trafic ne sort vers Internet).

Illustration schématique de l’appairage de VPC

Illustration – Schéma d’une connexion d’appairage VPC entre deux comptes AWS. Dans cet exemple, le VPC 3 d’un compte tiers est appairé aux VPC 1 et VPC 2 d’un autre compte (votre compte). Chaque liaison représente une connexion de peering distincte. Le trafic réseau peut ainsi circuler de manière privée entre le VPC 3 et le VPC 1, ainsi qu’entre le VPC 3 et le VPC 2. Notez que VPC 1 et VPC 2 ne sont pas appairés directement entre eux : s’ils devaient communiquer, il faudrait établir un peering séparé entre ces deux VPC, car le routage transitif via le VPC 3 n’est pas pris en charge.

Cas d’usage de l’appairage de VPC

Un cas d’usage courant de l’appairage de VPC est la communication entre environnements de production et de développement. Par exemple, imaginez un déploiement où l’environnement production est isolé dans un VPC distinct de l’environnement développement pour des raisons de sécurité. Si une application en développement doit accéder à certaines données ou API du VPC de production, un appairage de VPC permet d’établir cette communication de manière contrôlée et privée.

De même, l’appairage de VPC peut relier des VPC de deux filiales ou unités distinctes d’une entreprise, ou encore connecter les VPC de deux comptes AWS afin de partager des services internes sans passer par Internet. Par exemple, une base de données dans le VPC A peut être consultée par une application dans le VPC B via un peering, à condition de configurer les routes et autorisations nécessaires. En résumé, dès qu’il s’agit de faire communiquer deux réseaux AWS de façon relativement simple et qu’il n’y a pas un trop grand nombre de VPC à interconnecter, l’appairage de VPC est une solution adaptée.

Avantages de l’appairage de VPC

• Simplicité et performance : L’appairage est facile à mettre en place entre deux VPC et n’implique aucune infrastructure supplémentaire. Le trafic reste sur le réseau privé d’AWS, ce qui assure une faible latence et évite l’exposition aux menaces d’Internet[^1]. Le lien de peering supporte le trafic bidirectionnel sur tous les ports/protocoles IP, comme sur un réseau local.
• Inter-régions et inter-comptes : Un peering peut relier des VPC situés dans des régions AWS différentes (le trafic inter-région est alors chiffré automatiquement par AWS) ou dans des comptes AWS distincts. Cela offre de la flexibilité pour connecter des environnements globaux ou multi-comptes.
• Pas de coût fixe (tarification simple) : AWS ne facture pas l’établissement d’une connexion d’appairage en soi ; on paye uniquement les données transférées via le peering (similaires aux coûts de transfert de données entre zones ou entre régions)[^3]. Ainsi, pour des volumes modérés ou des connexions occasionnelles, le coût reste prévisible et souvent négligeable comparé à des solutions plus complexes.

Limites de l’appairage de VPC

• Absence de routage transitif : L’appairage de VPC ne prend pas en charge les relations transitives. Si le VPC A est appairé avec le VPC B, et que le VPC A est aussi appairé avec un VPC C, le VPC B ne peut pas communiquer avec le VPC C via A. Chaque paire de VPC qui doit échanger du trafic doit être reliée par un peering direct[^4]. Cette limitation signifie que dans une topologie comportant de nombreux VPC, le nombre de peering à gérer augmente de manière exponentielle dès que l’on veut un maillage complet, rendant l’architecture difficile à faire évoluer.
• Pas de chevauchement d’adresses IP : Il est impossible d’établir un peering entre deux VPC dont les plages d’adresses se chevauchent (même partiellement)[^5]. Chaque VPC doit donc avoir un espace d’adressage IP distinct. Ceci peut poser problème lors de la connexion avec un réseau externe ou un compte tiers dont on ne maîtrise pas le plan d’adressage, ou si l’allocation initiale des CIDR n’a pas été anticipée correctement.
• Portée de la connexion limitée à deux VPC : Un peering connecte uniquement les deux VPC concernés. Il n’offre pas de mécanisme de mutualisation ou de hub central. Par exemple, si trois VPC doivent tous communiquer entre eux, il faudra établir trois connexions (A<->B, B<->C, A<->C), avec des routes à configurer dans chaque VPC. Cette limitation est directement liée à l’absence de transitivité évoquée plus haut. À grande échelle (dizaines de VPC), la gestion des peering et des routes devient complexe et sujette à erreur.
• Partage limité des services réseau : Avec un peering, chaque VPC conserve ses propres services de sortie. Par exemple, si le VPC A possède une Internet Gateway ou un NAT Gateway pour sortir sur Internet, le VPC B appairé ne peut pas en profiter – il doit avoir sa propre passerelle pour accéder à Internet. De même, un VPC appairé ne peut pas emprunter la connexion VPN ou Direct Connect de l’autre VPC vers un datacenter externe[^6][^7]. Chaque VPC garde donc une certaine isolation dans ses accès externes, ce qui est sécurisant mais peut entraîner de la duplication de ressources (par ex. deux connexions VPN séparées vers le même réseau on-premise).
• Gestion manuelle : L’appairage de VPC nécessite de modifier manuellement les tables de routage de chaque côté pour annoncer les préfixes du VPC distant, et éventuellement d’ajuster les règles de sécurité. Il n’y a pas d’apprentissage dynamique de routes comme on pourrait l’avoir avec un routeur traditionnel. Cette gestion manuelle peut devenir lourde en cas de nombreux VPC connectés ou de changements fréquents.

Bonnes pratiques pour l’appairage de VPC

• Planifier l’adressage IP à l’avance : Afin d’éviter le problème de chevauchement des CIDR, définissez une plage d’adresses unique pour chaque VPC dès le départ (p. ex. en segmentant un bloc global en sous-réseaux). Une bonne gouvernance IP au niveau de l’organisation évite les conflits d’adresses et facilite l’intégration de nouveaux VPC via peering.
• Limiter le maillage excessif : Utilisez le peering pour relier quelques VPC entre eux (par exemple deux ou trois environnements), mais évitez les architectures “full mesh” avec des dizaines de peering dans tous les sens. Si votre réseau AWS commence à comporter de nombreux VPC nécessitant interconnexion, envisagez de passer à une architecture hub-and-spoke avec Transit Gateway pour une meilleure scalabilité.
• Sécuriser avec des règles de filtrage : Même si le trafic passe en privé, appliquez le principe de moindre privilège. Configurez des Security Groups ou ACL réseau pour n’autoriser que les ports et sources nécessaires depuis le VPC pair. Par exemple, si seul un service doit être accessible, verrouillez les règles en conséquence au lieu d’ouvrir tout le VPC. Par ailleurs, pensez à activer l’option de résolution DNS privée sur la connexion de peering si vos applications utilisent les noms de domaine internes (cela permet aux noms DNS privés de se résoudre en adresses IP privées de part et d’autre du peering).
• Superviser les coûts de transfert de données : Le peering lui-même n’est pas facturé, mais les transferts de données entre VPC le sont. Surveillez ces coûts, en particulier pour du trafic inter-région (dont le coût est plus élevé). Si possible, regroupez des services intensifs en bande passante dans un même VPC ou une même région pour limiter les transferts transversaux.
• Documenter et taguer les connexions : Dans une organisation, il est recommandé de taguer chaque connexion de peering (par exemple avec les noms des VPC ou projets associés) et de tenir à jour une documentation de votre topology d’appairage. Cela facilitera la maintenance, le dépannage et les éventuelles opérations de nettoyage si un VPC est supprimé ou si la configuration évolue.

AWS Transit Gateway

Présentation et architecture de Transit Gateway

AWS Transit Gateway (TGW) est un service managé agissant comme un hub de routage central pour interconnecter de multiples réseaux. On peut le visualiser comme un routeur cloud auquel on attache différents réseaux, qu’il s’agisse de VPC ou de connexions vers un environnement externe (VPN IPSec ou AWS Direct Connect). Chaque nouveau réseau est connecté une seule fois à la Transit Gateway, et celle-ci se charge de router le trafic de manière transitive entre toutes les connexions attachées[^8]. Grâce à ce modèle hub-and-spoke (moyeu-rayons), on évite de devoir créer des dizaines de peering entre chaque paire de VPC. La Transit Gateway fournit un point de connexion unique par VPC, ce qui simplifie énormément la topologie réseau en cas d’architecture à grande échelle[^9].

Techniquement, lorsque vous créez une Transit Gateway dans une région AWS, vous pouvez y attacher des VPC (de la même région) ainsi que des Gateway VPN ou une Direct Connect Gateway. Chaque attachement peut être configuré avec des tables de routage spécifiques au sein de la TGW, permettant de contrôler quels réseaux peuvent communiquer entre eux. Par exemple, on peut isoler certains VPC en ne propageant pas leurs routes vers d’autres attachements. Une Transit Gateway supporte un grand nombre de connexions (plusieurs milliers de VPC attachés potentiellement), et AWS assure sa haute disponibilité en la déployant de manière redondante dans plusieurs zones de disponibilité. Il est important de notez que la Transit Gateway opère au niveau L3 (couche réseau IP) et permet le trafic bidirectionnel sur tous types de protocoles IP (TCP, UDP, ICMP, etc.), sans restriction particulière sur les ports.

Intégration multi-VPC et avec Direct Connect

L’utilisation d’une Transit Gateway est particulièrement avantageuse dans des environnements multi-VPC et multi-comptes AWS. Plutôt que de gérer un maillage complexe de peering, toutes les VPC d’une organisation (par exemple celles des différentes équipes/projets) peuvent être reliées à la même Transit Gateway, ce qui centralise le routage. On peut ainsi établir un réseau interne unifié où chaque VPC attaché peut communiquer avec les autres (selon des règles définies) via le hub central.

De plus, AWS Transit Gateway s’intègre étroitement avec AWS Direct Connect pour connecter les réseaux on-premise. En attachant une Direct Connect Gateway à la Transit Gateway, on peut permettre à un data center d’entreprise (connecté à AWS via Direct Connect) d’accéder à tous les VPC attachés à la TGW au travers d’une seule connexion physique dédiée. Cela évite d’avoir à configurer un lien Direct Connect par VPC. L’ensemble formé par Transit Gateway + Direct Connect agit comme un routeur distribuant la connectivité du réseau d’entreprise vers plusieurs VPC AWS (et vice-versa)[^10]. En résumé, Transit Gateway offre une plateforme d’interconnexion globale : non seulement entre VPC multiples, mais aussi entre ces VPC et des réseaux externes, le tout de façon optimisée (chemin privé à haut débit, évitant Internet, et rationalisant le nombre de connexions nécessaires).

Illustration schématique de Transit Gateway

Illustration – Schéma simplifié d’une architecture hub-and-spoke avec AWS Transit Gateway. Au centre, la Transit Gateway (icône violette) sert de nœud central relié à plusieurs VPC. Dans cet exemple, deux VPC (VPC 1 et VPC 2) du côté « Votre compte » AWS et deux VPC (VPC 3 et VPC 4) d’un compte tiers sont attachés à la Transit Gateway. Chaque attachement de VPC à la TGW importe les routes du VPC dans la table de routage de la TGW, permettant le routage du trafic vers les autres VPC connectés. Grâce à la Transit Gateway, tous ces VPC peuvent communiquer entre eux via le hub central sans avoir à établir de peering direct entre chaque paire. La TGW supporte également la connexion d’un lien Direct Connect ou VPN externe (non illustré ici) qui serait traité comme un attachement supplémentaire, offrant la connectivité du réseau on-premise aux quatre VPC via ce même hub.

Cas d’usage de AWS Transit Gateway

AWS Transit Gateway est particulièrement indiqué dans les scénarios où l’on a besoin de connecter un grand nombre de VPC entre eux ou avec un réseau externe. Par exemple, une entreprise ayant des dizaines de comptes AWS (chacun contenant plusieurs VPC pour différentes applications ou environnements) pourra déployer une Transit Gateway au niveau du compte principal réseau et attacher tous les VPC de l’organisation à ce hub. Ceci permet, par exemple, à un environnement de production multi-comptes de communiquer avec un environnement de test situé dans un autre compte via la TGW, au lieu de devoir configurer un peering n-uple entre chaque VPC.

Un autre cas d’usage fréquent est la connexion hybride centralisée : une Transit Gateway peut agréger les flux de multiples VPC et les faire transiter par une unique connexion VPN ou Direct Connect vers le data center de l’entreprise. Cela simplifie énormément le schéma réseau : sans TGW, il aurait fallu configurer une connexion VPN point-à-point entre chaque VPC et le réseau on-premise, ou utiliser des appliances de transit VPC complexes. Avec Transit Gateway, on obtient une topologie claire où le réseau on-premise est considéré comme un attachement de plus, ce qui facilite le partage des ressources (ex: un serveur de licences on-premise accessible depuis tous les VPC, ou une application centralisée). Enfin, pour les architectures souhaitant implémenter des services partagés ou transverses (par ex. une VPC de services communs contenant des solutions de sécurité, d’annuaire, etc.), la Transit Gateway permet d’y centraliser des inspections de trafic. On peut imaginer un VPC dédié aux firewalls ou à AWS Network Firewall, que la TGW fait traverser pour filtrer les communications entre VPC, réalisant ainsi un point d’inspection centralisé du trafic réseau.

Avantages de AWS Transit Gateway

• Connectivité transitive et évolutivité : Transit Gateway permet le routage transitif, c’est-à-dire que tous les réseaux connectés via la TGW peuvent communiquer selon les règles de routage définies, sans configuration de peering direct entre eux. Cela résout la limitation principale du VPC peering et rend possible des architectures à grande échelle (on peut connecter des centaines de VPC à une seule TGW)[^11][^12]. L’ajout d’un nouveau VPC se fait en une seule attache à la TGW, au lieu de N peering à configurer.
• Simplification de la gestion du réseau : En centralisant les connexions, la TGW simplifie la topologie et la configuration. On gère les routes en un point central (dans la TGW) au lieu de disperser des entrées dans chaque table de routage de VPC. On peut segmenter le trafic via plusieurs tables de routage au sein de la TGW pour contrôler qui parle à qui (par exemple isoler les environnements de dev et prod). La visibilité et le contrôle sur les flux réseau sont accrus, ce qui facilite le dépannage et le monitoring global de l’architecture.
• Flexibilité multi-environnements : Une seule Transit Gateway peut être partagée entre plusieurs comptes AWS de votre organisation grâce à AWS Resource Access Manager (RAM). Cela évite d’avoir à déployer une TGW par compte et favorise une topologie réseau unifiée au niveau de l’entreprise. De plus, il est possible de peerer des Transit Gateway entre elles (même entre régions différentes) si besoin, ce qui ouvre la voie à un réseau mondial privé traversant les régions AWS.
• Intégration on-premise optimisée : Couplée à Direct Connect, la TGW offre une intégration fluide des réseaux d’entreprise. Vous pouvez centraliser une unique liaison physique haut débit (par ex. un DX 10 Gbps) vers la TGW, qui se charge ensuite de distribuer la connectivité vers tous les VPC. Cela améliore la bande passante et la cohérence des performances par rapport à des connexions Internet classiques (VPN sur Internet), et réduit les coûts réseau en mutualisant les liens privés[^13].
• Support de tous les protocoles et trafic bidirectionnel : Contrairement à PrivateLink (orienté service) qui limite les flux à certains ports/protocoles, la Transit Gateway transporte n’importe quel trafic IP de manière transparente. Qu’il s’agisse de flux Web, de bases de données, de RPC internes, etc., ils peuvent passer via la TGW, à condition que les routes et règles de sécurité soient en place. Le trafic circule en privé (aucune sortie Internet) et peut être chiffré sur certaines sections (ex: sur un lien VPN ou inter-région).

Limites de AWS Transit Gateway

• Coût plus élevé : Transit Gateway est un service payant dont la tarification combine un coût horaire par attachement de VPC et un coût au volume de données traitées via la TGW. À l’inverse d’un peering quasi gratuit, une TGW active connectant de nombreux VPC peut engendrer des coûts non négligeables (comptez quelques centimes par heure et par attachement, plus quelques centimes par Go transféré, variable selon les régions). Ce surcoût se justifie par les fonctionnalités avancées, mais il faut le budgeter. Néanmoins, notez que les transferts entre deux TGW peerées ne sont pas facturés en data processing, et que le coût de data processing s’applique seulement au VPC émetteur du trafic[^14][^15]. En somme, TGW est à envisager lorsque les bénéfices l’emportent sur son coût dans votre contexte (grande échelle, complexité réduite, etc.).
• Pas de CIDR qui se chevauchent : Comme pour le peering, AWS Transit Gateway ne supporte pas les plages d’adresses IP dupliquées ou chevauchantes entre ses attachements[^16]. Si deux VPC ont des adresses qui se recoupent, elles ne pourront pas être reliées simultanément à la même TGW (le trafic ne saurait être routé correctement). Il faut donc également soigner le plan d’adressage IP dans le cas d’utilisation de TGW, surtout dans un contexte multi-comptes étendu.
• Latence ajoutée et modèle partagé : Le passage par un composant centralisé peut ajouter une légère latence (généralement de l’ordre de la milliseconde ou moins, car la TGW est hautement optimisée). Pour la plupart des applications c’est négligeable, mais dans de rares cas ultra-sensibles à la latence, un peering direct entre deux VPC dans la même AZ pourrait offrir un poil moins de délai. Par ailleurs, la bande passante de Transit Gateway est partagée entre tous les flux (avec des limites élevées cependant, par ex. jusqu’à 50 Gbps par attachement VPC). Il convient de s’assurer qu’aucun VPC ne monopolise toute la bande passante de la TGW si d’autres échanges critiques cohabitent.
• Complexité initiale : La mise en place d’une TGW introduit de la complexité dans la configuration (création de la TGW, paramétrage des attachements, des routes, partage via RAM, etc.). Pour des très petits environnements (2–3 VPC), cela peut être perçu comme surdimensionné par rapport à un simple peering. Il faut aussi outiller la gestion (Infrastructure as Code recommandée) pour déployer et maintenir la configuration de la Transit Gateway dans le temps. Cependant, une fois en place, la TGW simplifie la gestion continue par rapport à l’alternative de dizaines de peering à administrer[^17][^18].
• Contrôle par le fournisseur tiers (limitation dans certains cas d’usage) : Dans un scénario de connectivité avec un partenaire externe (par ex. un fournisseur SaaS différent), celui-ci peut être réticent à utiliser votre Transit Gateway, car cela l’oblige à partager un composant réseau avec vous ou à vous déléguer une partie du contrôle (soit en utilisant votre TGW via RAM, soit en mettant en place un peering entre votre TGW et la sienne). Certains fournisseurs préfèrent généralement PrivateLink ou des peering directs pour garder la maîtrise de leur côté. Ce point est surtout pertinent dans les intégrations inter-entreprises : en environnement purement interne (org AWS d’une même société) ce n’est pas un problème.

Bonnes pratiques pour AWS Transit Gateway

• Segmenter les domaines de routage : Profitez de la flexibilité des tables de routage multiples de la TGW pour segmenter votre réseau. Par exemple, vous pouvez créer une table de routage pour les environnements de production et une autre pour les environnements de développement, de sorte que les deux groupes de VPC ne communiquent pas entre eux via la TGW (isolant ainsi prod et dev). De même, si vous attachez un VPC dédié à l’inspection (firewall), vous pouvez rediriger sélectivement certains flux vers lui en ajustant les routes.
• Utiliser AWS Resource Access Manager (RAM) : Dans un contexte multi-comptes, il est recommandé de partager la Transit Gateway au niveau de l’organisation AWS (via RAM) plutôt que d’en créer une par compte. Cela centralise la gouvernance réseau. Vous pouvez par exemple désigner un compte « réseau central » qui héberge la TGW, et tous les autres comptes y attachent leurs VPC. Cette approche facilite aussi le suivi financier (les coûts TGW étant alors principalement dans le compte réseau) et la gestion d’accès (contrôler qui peut attacher/détacher des VPC).
• Automatiser la gestion des routes : Pour éviter les erreurs manuelles, scriptez ou automatisez la mise à jour des associations et propagations de routes dans la TGW. Par exemple, si vous ajoutez régulièrement de nouveaux VPC, prévoyez un mécanisme (Terraform, CloudFormation, ou Lambda pilotée par événement) qui attachera le VPC et configurera les routes nécessaires dans les tables appropriées. Cela assure la cohérence et évite les oublis qui pourraient créer des trous de communication.
• Surveiller l’utilisation et le débit : Utilisez Amazon CloudWatch pour monitorer le trafic sur la Transit Gateway (métriques de volume de données par attachement, etc.) afin d’identifier les flux importants ou anormaux. Cela peut aider à distribuer des charges si un attachement particulier consomme beaucoup de bande passante. De plus, paramétrez des alarmes sur les coûts de la TGW si besoin, pour être averti en cas de dépassement inhabituel (par exemple un pic de data transfer inattendu).
• Sécurité et conformité : Bien que la TGW facilite la communication, assurez-vous de conserver des contrôles de sécurité appropriés. Les Security Groups ne traversent pas la TGW (ils s’appliquent par VPC uniquement), donc envisagez d’utiliser des Network ACL ou AWS Network Firewall si vous devez filtrer au niveau réseau entre VPC. Pensez aussi à activer VPC Flow Logs sur les attachements TGW pour conserver une trace des flux inter-VPC (via les logs des VPC eux-mêmes). Enfin, intégrez la TGW dans votre modèle de sécurité en définissant clairement quels VPC peuvent échanger du trafic, et évitez d’attacher à la TGW des VPC contenant des environnements qui doivent rester totalement isolés.

AWS PrivateLink

Fonctionnement de AWS PrivateLink

AWS PrivateLink est un service/fonctionnalité qui permet d’exposer ou de consommer un service de manière privée via des points de terminaison (endpoints) VPC. Plutôt que de connecter deux réseaux entiers comme avec le peering ou la TGW, PrivateLink opère à un niveau plus granulaire, centré sur un service ou une application spécifique. Le concept se base sur deux rôles : un fournisseur de service (service provider) qui héberge l’application à partager dans son VPC, et un ou plusieurs consommateurs (service consumers) qui vont accéder à ce service depuis leurs propres VPC.

Concrètement, le fournisseur configure son application (par exemple une API REST, un serveur web, etc.) derrière un Network Load Balancer (NLB) dans son VPC, puis crée une Endpoint Service côté AWS pour le publier. Les clients, de leur côté, créent dans chacun de leurs VPC un VPC Endpoint de type Interface (point de terminaison d’interface) qui va pointer vers le service du fournisseur. Ce VPC Endpoint se matérialise comme une interface réseau virtuelle ayant une adresse IP privée locale dans le sous-réseau du client. Lorsqu’une ressource du VPC client envoie du trafic vers le service, elle vise l’adresse privée (ou le nom DNS associé) de ce endpoint ; le trafic est alors automatiquement et transparent acheminé via le réseau privé AWS jusqu’au NLB du fournisseur, qui le transfère vers l’application cible. Tout ce chemin se fait sans jamais passer par Internet, et sans nécessiter de peering ni de Transit Gateway entre les VPC[^19][^20]. PrivateLink permet ainsi un accès unidirectionnel initié par le VPC client vers le service du VPC fournisseur : le fournisseur n’a pas de route vers les clients, c’est uniquement une exposition contrôlée d’un service. Techniquement, PrivateLink utilise des connexions au niveau du TLS entre endpoints et NLB, et supporte principalement les protocoles TCP (et TLS) – il est conçu pour les communications type API, services web, base de données, etc., et ne transporte pas de trafic UDP ou ICMP.

Illustration schématique de AWS PrivateLink

Illustration – Schéma d’utilisation d’AWS PrivateLink pour consommer un service hébergé dans un VPC tiers. À gauche, le compte fournisseur expose son service dans un VPC via un Network Load Balancer répartissant le trafic vers des instances dans des sous-réseaux privés (zones de disponibilité 1 et 2). À droite, votre compte déploie un VPC Endpoint (de type interface) dans un VPC client, également dans deux zones de disponibilité pour la haute dispo. Le service AWS PrivateLink (représenté par l’icône violette) connecte les endpoints clients au NLB fournisseur de manière transparente. Ainsi, les instances du VPC client peuvent accéder au service du VPC fournisseur en utilisant l’adresse privée locale du endpoint, comme s’il s’agissait d’un service local. Le trafic ne sort pas du réseau AWS et aucun peering direct n’est nécessaire entre les deux VPC.

Cas d’usage de AWS PrivateLink

Un usage typique de PrivateLink est l’exposition d’un service interne au sein d’une organisation de façon sécurisée. Par exemple, supposons que vous disposiez d’un micro-service critique (API, base de données gérée, etc.) hébergé dans un VPC backend isolé pour des raisons de sécurité. D’autres VPC (par exemple ceux de différentes équipes ou d’autres environnements) ont besoin de consommer ce service. Avec PrivateLink, vous pouvez publier ce service via un Endpoint Service dans le VPC backend, et chaque VPC consommateur crée un Endpoint interface pour y accéder. Ainsi, vos équipes accèdent à l’API interne sans que le trafic ne sorte jamais sur Internet, et sans devoir ouvrir l’ensemble du VPC backend via un peering.

PrivateLink est également très répandu pour les solutions SaaS : de nombreux fournisseurs SaaS sur AWS proposent à leurs clients une connexion via PrivateLink. Dans ce modèle, le VPC du fournisseur SaaS est le fournisseur de service, et chaque client établit un endpoint dans son propre VPC. Cela permet une intégration client-fournisseur privée où les données ne transitent pas par le web public et où le client n’a pas besoin d’ouvrir son réseau à des adresses IP externes du fournisseur (il consomme via l’endpoint interne). Enfin, AWS PrivateLink s’utilise pour accéder à certains services AWS managés depuis un VPC sans passer par une IP publique. Par exemple, on peut créer des Interface Endpoints vers des services comme AWS SNS, SQS, API Gateway, etc. ou des Gateway Endpoints spécifiques pour S3 et DynamoDB. Cela permet à des ressources dans un VPC privé (sans Internet Gateway) d’appeler ces services AWS entièrement via le réseau interne AWS. En somme, PrivateLink est indiqué dès que l’on veut partager un service précis de manière sécurisée, cloisonnée et simple : que ce soit en interne (service commun), en B2B (SaaS) ou pour consommer des services AWS sans sortie Internet.

Avantages de AWS PrivateLink

• Sécurité renforcée du trafic : Le principal avantage est que le trafic client-serveur ne sort jamais du réseau AWS et ne transite pas sur Internet, réduisant de fait la surface d’exposition aux attaques externes[^19]. Cela permet de consommer ou fournir des services de façon privée, y compris depuis des environnements qui n’ont aucune connexion Internet (parfait pour des VPC hautement sécurisés). De plus, PrivateLink offre des contrôles additionnels : côté fournisseur, on peut restreindre l’accès à son Endpoint Service à des comptes AWS ou VPC spécifiques (whitelist), et côté client on peut attacher une policy d’endpoint et des Security Groups au VPC Endpoint pour filtrer les connexions[^19]. On obtient ainsi un contrôle très précis de qui accède à quoi, tout en conservant le trafic dans un périmètre privé.
• Simplicité pour le consommateur (réseau transparent) : Pour un client, consommer un service via PrivateLink est très simple : il n’a pas besoin de configurer de routes, ni de peering, ni de gérer des plages IP du fournisseur, etc.[^19] Le point de terminaison s’attache automatiquement au sous-réseau du VPC client et devient accessible via un nom DNS .vpce interne ou même un nom DNS personnalisé. Aucune modification n’est requise dans la topologie réseau du client : pas de NAT, pas de firewall supplémentaire. Cette transparence est un gros atout, notamment quand on intègre le service d’un tiers : le client n’a pas à se soucier des détails réseau du fournisseur, il crée juste un endpoint comme il le ferait pour un service AWS.
• Isolation et réduction du risque lié aux IP : PrivateLink ne connecte pas deux réseaux entiers, mais seulement un service spécifique. Par conséquent, le fournisseur et le consommateur restent isolés l’un de l’autre en dehors de ce flux précis. Le client ne “voit” pas l’architecture du VPC fournisseur (il n’a pas besoin de connaître ses IP ou ses sous-réseaux), et inversement le fournisseur ne connaît rien du réseau client. Cela apporte une couche d’isolation très appréciable en B2B. De plus, PrivateLink autorise sans problème les CIDR chevauchants ou identiques entre le VPC client et fournisseur[^21]. Étant donné qu’aucune route IP directe n’est établie entre les réseaux (on passe par des endpoints), peu importe si les deux VPC utilisent par exemple 10.0.0.0/16 chacun. Ceci lève un obstacle fréquent qu’on rencontre avec le peering ou la TGW lorsqu’on intègre un partenaire externe (où les plans d’adressage peuvent entrer en conflit).
• Évolutivité (one-to-many) : Un Endpoint Service PrivateLink (côté fournisseur) peut être consommé par des dizaines voire des centaines de VPC clients simultanément, même répartis sur de nombreux comptes. Le fournisseur n’a pas besoin de créer une connexion dédiée pour chaque client (contrairement au peering qui est 1-1) : il lui suffit d’approuver les demandes des clients sur son service endpoint. De même, du côté client, on peut créer autant de endpoints que nécessaire vers différents services. Cette capacité à faire du one-to-many en conservant un découplage des réseaux rend PrivateLink très adapté aux modèles multi-clients (SaaS) ou architectures micro-services partagés. Par ailleurs, AWS assure une haute performance pour PrivateLink : chaque endpoint interface peut par défaut supporter jusqu’à 10 Gbps de trafic et s’ajuster automatiquement jusqu’à 100 Gbps[^19], ce qui permet de répondre aux besoins des applications à fort volume d’échanges.
• Pas de dépendance aux protocoles applicatifs : PrivateLink fonctionne au niveau de la connexion réseau, indépendamment du contenu applicatif. Il est donc compatible avec toute application utilisant TCP (HTTP/HTTPS, SQL, etc.). Pour le client, appeler un service via PrivateLink revient exactement au même que d’appeler une URL ou une IP interne, ce qui facilite l’intégration dans les applications existantes (pas besoin de gérer de VPN ou de tunnels spécifiques).

Limites de AWS PrivateLink

• Portée limitée du service (accès unidirectionnel) : PrivateLink assure un accès depuis le client vers le service du fournisseur uniquement. Le fournisseur ne peut pas initier de connexions vers le client (il n’a d’ailleurs pas d’IP de celui-ci). Ce modèle client-serveur unidirectionnel convient bien à la majorité des cas (consommation d’API, etc.), mais ne couvre pas les scénarios où deux environnements auraient besoin d’une communication bidirectionnelle générale. Dans ces derniers cas (par ex. réplication mutuelle de bases de données entre deux VPC), un peering ou une TGW sera plus approprié. En outre, PrivateLink est conçu pour un service à la fois : chaque endpoint cible un Endpoint Service (NLB) précis. Si un client a besoin d’accéder à 5 services différents dans le VPC fournisseur, il devra créer 5 endpoints distincts. Cela peut introduire un peu de complexité côté client lorsque le nombre de services exposés grandit (bien que l’automatisation puisse aider à gérer cela).
• Limité à une seule région AWS : Un Endpoint Service PrivateLink et ses endpoints consommateurs doivent résider dans la même région AWS. Il n’est pas possible, nativement, de consommer un service PrivateLink d’une région depuis un VPC dans une autre région. En cas de besoin multi-régions, il faut déployer des Endpoint Services séparés dans chaque région ou bien recourir à des solutions additionnelles (par ex. combiner avec Transit Gateway pour étendre un accès PrivateLink à travers des TGW peerées entre régions[^19][^20]). Cela ajoute de la complexité si l’on vise une portée géographique large. À l’inverse, le VPC peering supporte directement l’inter-région. C’est donc un élément à considérer selon vos besoins : PrivateLink est idéal en intra-région, mais pour un accès cross-région, d’autres approches pourraient être nécessaires.
• Restrictions sur les protocoles et le type de trafic : PrivateLink s’appuie sur des NLB et des interfaces ENI ; il est essentiellement conçu pour du trafic TCP (et plus récemment certains cas UDP via NLB, bien que ce soit moins courant) et ne transporte pas des protocoles de bas niveau ni de la communication ICMP. Par exemple, on ne peut pas faire passer du ping ou du traceroute via PrivateLink, ni du protocole UDP arbitraire (sauf à encapsuler dans du TCP). De plus, il ne supporte pas le multicast ou d’autres fonctionnalités réseau avancées. En somme, ce n’est pas un outil de “routage” général, mais vraiment une connectivité orientée service.
• Coûts associés aux endpoints : Chaque VPC Endpoint créé est facturé à l’heure, tant qu’il est provisionné, ainsi qu’au volume de données transitant via lui (frais de Data Processing PrivateLink). Pour un usage ponctuel, ces coûts sont minimes (quelques centimes de l’heure et par GB), mais si l’on déploie de très nombreux endpoints dans une organisation, la facture peut grimper. Il convient donc d’auditer régulièrement l’utilisation des endpoints – par exemple, supprimer ceux qui ne sont plus nécessaires – et de regrouper si possible les accès (un endpoint peut desservir toute une appli dans le VPC client, pas besoin d’en dupliquer par sous-réseau s’il n’y a pas de contrainte). Comparativement, un VPC peering n’a pas de coût horaire et peut parfois revenir moins cher si le volume de données est faible et qu’on n’a pas besoin de la granularité de PrivateLink.
• Configuration côté fournisseur plus technique : Mettre en place PrivateLink en tant que fournisseur de service demande un peu de configuration (NLB, Endpoint Service, approbation des demandes des clients). Cela nécessite aussi que l’application puisse s’intégrer derrière un NLB (par ex. service TCP sur port fixe, support du balancier en front). De plus, toutes les applications ne sont pas facilement “PrivateLinkables” (ex: si c’est quelque chose qui ne fonctionne pas bien derrière un NLB ou qui nécessite de connaître l’IP source du client, etc., bien que des solutions existent via Proxy Protocol v2 ou autres). En comparaison, exposer un service via un simple peering peut être plus direct (le client se connecte à l’IP de l’instance distante). Néanmoins, dans la plupart des cas d’usage web ou base de données, PrivateLink est tout à fait applicable.

Comparaison avec VPC Peering

Bien que PrivateLink et VPC Peering permettent tous deux d’accéder aux ressources d’un VPC depuis un autre, leurs approches et cas d’utilisation diffèrent grandement. Le tableau suivant résume les principales différences :

En pratique, cela signifie que :

• PrivateLink est idéal pour partager une application précise (ex: une API, une base de données) de manière restreinte.
• VPC Peering convient pour établir une communication globale entre deux environnements (par ex. intégrer entièrement deux segments réseau).

Il est envisageable de combiner les deux : par exemple, on pourrait appairer deux VPC entre régions différentes, puis exposer un PrivateLink du premier VPC vers un client dans le second, mais ce scénario est avancé et généralement on choisit l’une ou l’autre techno en fonction du besoin.

Bonnes pratiques pour AWS PrivateLink

• Architecture haute disponibilité : Lorsque vous exposez un service via PrivateLink, assurez-vous de déployer le Network Load Balancer du côté fournisseur sur au moins deux zones de disponibilité (si possible trois) et idem pour les endpoints du côté client (un endpoint par AZ utilisée). Cela garantira que la connexion PrivateLink reste fonctionnelle même si une zone AWS subit une panne. Côté client, vous pouvez améliorer la résilience DNS en activant l’option qui accepte les réponses multi-IP (le mécanisme de résolution du nom DNS du Endpoint fait tourner les IP des endpoints AZ).
• Contrôle d’accès minimal : Appliquez les filtres d’accès disponibles : par exemple, côté fournisseur, restreignez l’Endpoint Service aux seuls comptes AWS clients légitimes (ou même à des VPC spécifiques via leur ID s’ils sont dans le même compte). Côté client, associez un Security Group au VPC Endpoint pour limiter les sources internes autorisées à utiliser le service (par ex., seulement les instances de votre subnet d’app tier, etc.). Si le service exposé est sensible, n’hésitez pas à utiliser les Policies d’Endpoint pour n’autoriser que certaines actions/URLs vers l’API cible.
• Observation et audit : Utilisez AWS CloudTrail pour tracer les événements de création/acceptation des endpoints et des Endpoint Services (ainsi vous saurez qui a exposé quoi et qui s’y connecte). Activez également les Flow Logs sur vos endpoints (ce sont en fait des ENI dans votre VPC) afin de surveiller le trafic réseau qui y transite. Cela peut vous aider à détecter une utilisation abusive ou inattendue du service privé.
• Nommage et DNS : Par défaut, AWS attribue un nom DNS par endpoint (du style .vpce.amazonaws.com). Il est souvent pratique de créer un enregistrement DNS personnalisé (par ex. monservice.prive.local) dans votre Route 53 Private Hosted Zone pointant vers le DNS du endpoint. Ainsi, vos applications clientes utilisent un nom facile à retenir. Vérifiez aussi les paramètres DNS du VPC (enableDnsHostnames/enableDnsSupport) pour que la résolution fonctionne bien. Si plusieurs comptes sont impliqués, unificez le nommage DNS via des zones DNS partagées si possible.
• Nettoyage et gestion des connexions : Côté fournisseur, surveillez les demandes de connexion en attente sur votre Endpoint Service. Il est préférable de les approuver ou refuser rapidement pour éviter d’éventuels points morts. Côté client, supprimez les endpoints non utilisés pour éviter les coûts inutiles et réduire la surface d’attaque. De plus, tenez à jour un inventaire des services consommés via PrivateLink au sein de votre orga, pour garder une vision claire des dépendances (surtout si plusieurs équipes publient des services en interne).
• Comparer les alternatives : Enfin, gardez en tête que PrivateLink n’est pas la seule solution de connectivité privée. Dans certains cas, un VPC Endpoint Gateway (pour S3/DynamoDB) peut suffire plutôt qu’un PrivateLink, ou un AWS Service Accelerator (AWS Global Accelerator) couplé à des Endpoint Groups peut offrir une connectivité optimisée. Évaluez donc PrivateLink lorsque le besoin correspond (accès privé, cross-comptes, overlap CIDR, etc.), sinon un simple peering ou une TGW peut parfois être plus approprié si c’est du réseau global que vous voulez. Utilisez chaque outil AWS pour ce pour quoi il est le plus efficace, en vous référant aux critères de cas d’usage vus précédemment.

Conclusion

En conclusion, VPC Peering, Transit Gateway et PrivateLink sont trois solutions complémentaires pour la connectivité avancée dans AWS. Le VPC Peering convient à l’interconnexion directe de deux environnements de manière simple, la Transit Gateway apporte une structure centralisée et scalable pour mailler de nombreux VPC et réseaux, et PrivateLink offre une approche fine et sécurisée pour exposer des services sans ouvrir les réseaux. En comprenant leurs fonctionnements, cas d’usage et limites respectives, vous serez en mesure de choisir la solution adéquate pour chaque besoin de votre architecture cloud. Chaque service requiert de suivre certaines bonnes pratiques de conception et de sécurité, mais bien utilisés, ils vous permettront de construire un réseau AWS fiable, sécurisé et évolutif, répondant aux exigences modernes des environnements multi-cloud et hybrides.