Une entreprise compte 20 équipes de service, chacune dans son propre compte AWS et chaque VPC utilisant 192.168.0.0/22. Les services s'exécutent sur des instances EC2 derrière des ALB et communiquent actuellement via l'internet public. La sécurité exige désormais que tout le trafic inter-services utilise HTTPS sur un réseau privé sans passer par l'internet. La solution doit minimiser les changements requis par chaque équipe. Quelle approche répond à ces exigences ?

L'option correcte est de créer un NLB dans chaque VPC de microservice et de l'exposer via AWS PrivateLink. PrivateLink permet une connectivité privée entre les VPC, les services AWS et les réseaux sur le réseau AWS, sans exposer le trafic à l'internet public. En créant des points d'accès VPC (VPC Endpoints) pour ces NLB dans chaque compte et en s'y abonnant, les services peuvent communiquer de manière sécurisée et privée en utilisant les noms DNS des points d'accès VPC, minimisant ainsi les modifications pour chaque équipe. Les autres options sont moins optimales : La création d'un nouveau compte et le partage de sous-réseaux via RAM nécessiteraient le redéploiement des services dans de nouveaux sous-réseaux partagés, ce qui est une modification majeure. Le peering VPC entre tous les VPC (20 équipes = 190 connexions de peering) ne serait pas évolutif et la gestion des tables de routage serait complexe. L'utilisation d'une passerelle de transit partagée est une bonne solution pour la connectivité inter-VPC, mais elle ne fournit pas intrinsèquement la connectivité privée au niveau du service comme PrivateLink, et le trafic transiterait toujours par la passerelle de transit, ce qui pourrait être moins direct que PrivateLink pour la communication service-à-service.