Deux comptes AWS, un réseau local : quel chemin ?
Transit Gateway partagé, deux VPN indépendants ou un proxy étroit : choisissez selon la propriété et le rayon d'impact, pas selon la route la plus facile à ajouter aujourd'hui.
Le cadrage évident est peering contre VPN, et c'est le mauvais cadrage. Un VPC appairé ne peut pas emprunter la connexion VPN de son voisin pour router de bord à bord, donc cette option n'a jamais été sur la table, quoi qu'en suggère une table de routage. Ce que vous choisissez réellement, c'est entre un hub réseau partagé, deux chemins VPN indépendants et une entrée applicative étroite. Chacun répond à une question différente sur qui possède le routage.
Trois options et celle qui n'en est pas une
Commencez par supprimer l'idée de peering, puis comparez ce qui reste selon la propriété plutôt que selon la simplicité du schéma. Le tableau ci-dessous est la décision sous forme compressée.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Si le compte A a besoin d'atteindre tout un réseau local, la ligne du proxy a la mauvaise forme. Si le compte A a besoin d'une API, les deux premières lignes font plus de réseau que l'exigence ne le demandait.
Quand le Transit Gateway partagé l'emporte
Un Transit Gateway rattache chaque VPC et le VPN comme des réseaux séparés, et le partage entre comptes permet aux propriétaires de VPC d'utiliser le hub sans fusionner les comptes. C'est l'attrait : un endroit où les préfixes locaux rencontrent les réseaux AWS, et un endroit pour raisonner sur quel rattachement apprend quelle route.
Tout rattacher ne signifie pas tout autoriser. L'association et la propagation décident quel rattachement utilise quelle table de routage, si bien que deux préfixes de VPC peuvent chacun atteindre un service local tandis que leur accès mutuel reste exclu par la conception du hub. Le côté local a toujours besoin de routes de retour pour les préfixes AWS, et c'est un changement pour une autre équipe.
Le coût est organisationnel autant que financier. Le propriétaire du hub contrôle des relations de routage dont dépendent d'autres équipes, si bien qu'un changement sur un rattachement peut déplacer le trafic d'un service dont le propriétaire du hub n'a jamais entendu parler. Les heures de rattachement et le traitement des données s'additionnent à chaque réseau que vous rattachez, et c'est pourquoi les hubs grossissent souvent plus vite que l'équipe qui les exploite.
Quand des VPN séparés ou un proxy étroit l'emportent
Deux VPN indépendants conviennent à un petit déploiement avec de vraies frontières opérationnelles : chaque compte modifie ses propres tunnels, et aucun ne peut casser l'autre en modifiant une table de routage. Les limites sont côté local. La passerelle homologue a besoin de capacité pour les tunnels supplémentaires, les plans d'adressage ne doivent pas se chevaucher, et deux configurations annonçant les mêmes préfixes ont besoin d'une préférence délibérée plutôt que d'espoir.
Un proxy est l'interface la plus étroite. Si le compte A a besoin d'une base de données ou d'une API dans le compte B, un intermédiaire délimité vous donne une entrée définie avec sa propre histoire d'authentification, de journalisation et de disponibilité. C'est aussi l'option la plus susceptible d'être mal utilisée : un intermédiaire qui relaie vers toute destination privée est devenu un relais sans restriction avec des étapes en plus, et il ne se comportera pas comme un transit transparent du VPC vers le réseau local pour quoi que ce soit d'autre.
Les restrictions du peering de VPC valent la peine d'être lues avant tout cela, car elles expliquent pourquoi la quatrième idée revient sans cesse et pourquoi elle ne peut pas fonctionner.
Choisissez l'interface la plus étroite qui satisfait l'exigence
Ordonnez les questions : A a-t-il besoin d'un réseau, d'un ensemble de réseaux ou d'un seul service ? L'équipe locale veut-elle un chemin ou plusieurs ? Qui est autorisé à changer le routage du trafic de l'autre équipe ? La première réponse qui produit l'interface la plus étroite est l'architecture, et tout ce qui suit est de la mise en œuvre.
Consignez la réponse avec le plan de préfixes, la propriété des routes, l'inventaire des tunnels ou des rattachements et le mode de défaillance attendu de chaque côté. Quand quelqu'un demandera plus tard pourquoi le compte A ne peut pas simplement utiliser le VPN du compte B, cette consignation est la réponse, et elle vous évite de reprendre les mêmes trois options au projet suivant.