Dúas contas de AWS, unha rede local: que camiño?
Transit Gateway compartido, dúas VPN independentes ou un proxy estreito: escolla pola propiedade e o radio de impacto, non por que ruta é máis doada de engadir hoxe.
O enfoque obvio é peering fronte a VPN, e é o enfoque equivocado. Unha VPC emparellada non pode tomar prestada a conexión VPN da súa veciña para encamiñar de extremo a extremo, así que esa opción nunca estivo sobre a mesa, diga o que diga unha táboa de rutas. O que realmente escolle é entre un concentrador de rede compartido, dúas rutas VPN independentes e unha entrada de aplicación estreita. Cada unha responde a unha pregunta distinta sobre quen é dono do encamiñamento.
Tres opcións e a que non é unha opción
Comece borrando a idea do peering e despois compare o que queda pola propiedade e non pola simplicidade do diagrama. A táboa seguinte é a decisión 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 |
Se a conta A necesita chegar a toda unha rede local, a fila do proxy ten a forma equivocada. Se a conta A necesita unha API, as dúas primeiras filas son máis rede do que pide o requisito.
Cando gaña o Transit Gateway compartido
Un Transit Gateway conecta cada VPC e a VPN como redes separadas, e a compartición entre contas permite aos donos das VPC usar o concentrador sen fusionar contas. Ese é o atractivo: un lugar onde os prefixos locais se atopan coas redes de AWS, e un lugar para razoar que conexión aprende que ruta.
Conectar todo non significa permitilo todo. A asociación e a propagación deciden que conexión usa que táboa de rutas, así que dous prefixos de VPC poden chegar cada un a un servizo local mentres o seu acceso mutuo queda excluído polo deseño do concentrador. O lado local aínda necesita rutas de volta para os prefixos de AWS, e iso é un cambio doutro equipo.
O custo é organizativo tanto como financeiro. O dono do concentrador controla relacións de encamiñamento das que dependen outros equipos, así que un cambio nunha conexión pode mover tráfico dun servizo do que o dono do concentrador nunca oíu falar. As horas de conexión e o procesamento de datos acumúlanse con cada rede que conecta, e por iso os concentradores adoitan medrar máis rápido que o equipo que os xestiona.
Cando gañan VPN separadas ou un proxy estreito
Dúas VPN independentes encaixan nun despregamento pequeno con límites operativos reais: cada conta cambia os seus propios túneles e ningunha pode romper a outra editando unha táboa de rutas. Os límites están no lado local. A pasarela parella necesita capacidade para os túneles adicionais, os plans de enderezos non deben solaparse e dúas configuracións que anuncian os mesmos prefixos necesitan unha preferencia deliberada en lugar de esperanza.
Un proxy é a interface máis estreita. Se a conta A necesita unha base de datos ou unha API na conta B, un intermediario acoutado dálle unha entrada definida coa súa propia historia de autenticación, rexistro e dispoñibilidade. Tamén é a opción máis propensa a un uso indebido: un intermediario que reenvía a calquera destino privado converteuse nun relé sen restricións con pasos extra, e non se comportará como tránsito transparente de VPC a rede local para nada máis.
Paga a pena ler as restricións do peering de VPC antes de todo isto, porque explican por que a cuarta idea volve unha e outra vez e por que non pode funcionar.
Escolla a interface máis estreita que cumpra o requisito
Ordene as preguntas: A necesita unha rede, un conxunto de redes ou un só servizo? O equipo local quere un camiño ou varios? Quen pode cambiar o encamiñamento do tráfico do outro equipo? A primeira resposta que produce a interface máis estreita é a arquitectura, e todo o demais é implementación.
Rexiste a resposta co plan de prefixos, a propiedade das rutas, o inventario de túneles ou conexións e o modo de fallo que espera cada lado. Cando alguén pregunte máis adiante por que a conta A non pode simplemente usar a VPN da conta B, ese rexistro é a resposta, e aforra volver discutir as mesmas tres opcións no próximo proxecto.