Dos comptes d'AWS, una xarxa local: quin camí?
Transit Gateway compartit, dues VPN independents o un proxy estret: tria pel propietari i pel radi d'impacte, no per quina ruta és més fàcil d'afegir avui.
L'enfocament obvi és peering contra VPN, i és l'enfocament equivocat. Una VPC interconnectada no pot manllevar la connexió VPN del seu veí per encaminar d'extrem a extrem, així que aquesta opció mai no era sobre la taula, digui el que digui una taula de rutes. Entre el que realment tries hi ha un concentrador de xarxa compartit, dos camins VPN independents i una entrada d'aplicació estreta. Cadascun respon una pregunta diferent sobre qui és el propietari de l'encaminament.
Tres opcions i la que no és una opció
Comença esborrant la idea del peering i després compara el que queda pel propietari i no per la simplicitat del diagrama. La taula següent és la decisió en forma comprimida.
| 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 el compte A necessita arribar a tota una xarxa local, la fila del proxy té la forma equivocada. Si el compte A necessita una API, les dues primeres files són més xarxa del que demana el requisit.
Quan guanya el Transit Gateway compartit
Un Transit Gateway connecta cada VPC i la VPN com a xarxes separades, i la compartició entre comptes permet als propietaris de les VPC fer servir el concentrador sense fusionar comptes. Aquest és l'atractiu: un lloc on els prefixos locals es troben amb les xarxes d'AWS, i un lloc per raonar quin adjunt aprèn quina ruta.
Adjuntar-ho tot no vol dir permetre-ho tot. L'associació i la propagació decideixen quin adjunt fa servir quina taula de rutes, així que dos prefixos de VPC poden arribar cadascun a un servei local mentre l'accés mutu queda exclòs pel disseny del concentrador. El costat local encara necessita rutes de tornada per als prefixos d'AWS, i això és un canvi d'un altre equip.
El cost és organitzatiu tant com financer. El propietari del concentrador controla relacions d'encaminament de què depenen altres equips, així que un canvi en un adjunt pot moure trànsit d'un servei del qual el propietari del concentrador no ha sentit mai a parlar. Les hores d'adjunt i el processament de dades sumen amb cada xarxa que adjuntes, i per això els concentradors solen créixer més de pressa que l'equip que els gestiona.
Quan guanyen VPN separades o un proxy estret
Dues VPN independents encaixen en un desplegament petit amb límits operatius reals: cada compte canvia els seus túnels i cap no pot trencar l'altre editant una taula de rutes. Els límits són al costat local. La passarel·la parella necessita capacitat per als túnels addicionals, els plans d'adreces no es poden solapar i dues configuracions que anuncien els mateixos prefixos necessiten una preferència deliberada en lloc d'esperança.
Un proxy és la interfície més estreta. Si el compte A necessita una base de dades o una API al compte B, un intermediari abastat et dona una entrada definida amb la seva pròpia història d'autenticació, registre i disponibilitat. També és l'opció que més fàcilment s'usa malament: un intermediari que reenvia a tota destinació privada s'ha convertit en un relé sense restriccions amb passos extra, i no es comportarà com un trànsit transparent de VPC a xarxa local per a res més.
Les restriccions del peering de VPC val la pena llegir-les abans de res d'això, perquè expliquen per què la quarta idea torna una i altra vegada i per què no pot funcionar.
Tria la interfície més estreta que compleixi el requisit
Ordena les preguntes: A necessita una xarxa, un conjunt de xarxes o un sol servei? L'equip local vol un camí o diversos? Qui pot canviar l'encaminament del trànsit de l'altre equip? La primera resposta que produeix la interfície més estreta és l'arquitectura, i tot el que ve després és implementació.
Registra la resposta amb el pla de prefixos, la propietat de les rutes, l'inventari de túnels o adjunts i el mode de fallada que cada costat espera. Quan algú pregunti més endavant per què el compte A no pot simplement fer servir la VPN del compte B, aquest registre és la resposta, i t'estalvia de tornar a discutir les mateixes tres opcions al proper projecte.