Duas contas AWS, uma rede local: qual caminho?

O enquadramento óbvio é peering versus VPN, e é o enquadramento errado. Uma VPC emparelhada não pode tomar emprestada a conexão VPN da vizinha para encaminhamento de ponta a ponta, então essa opção nunca esteve sobre a mesa, diga o que disser uma tabela de rotas. O que você realmente escolhe é entre um hub de rede compartilhado, dois caminhos VPN independentes e uma entrada de aplicação estreita. Cada um responde a uma pergunta diferente sobre quem é dono do encaminhamento.

Três opções e a que não é opção

Comece apagando a ideia de peering e depois compare o que resta pela propriedade, não pela simplicidade do diagrama. A tabela abaixo é a decisão em forma comprimida.

Se a conta A precisa alcançar uma rede local inteira, a linha do proxy tem a forma errada. Se a conta A precisa de uma API, as duas primeiras linhas são mais rede do que o requisito pediu.

Quando o Transit Gateway compartilhado vence

Um Transit Gateway anexa cada VPC e a VPN como redes separadas, e o compartilhamento entre contas permite que os donos das VPCs usem o hub sem fundir contas. Esse é o atrativo: um lugar onde os prefixos locais encontram as redes da AWS, e um lugar para raciocinar sobre qual anexo aprende qual rota.

Anexar tudo não significa permitir tudo. A associação e a propagação decidem qual anexo usa qual tabela de rotas, então dois prefixos de VPC podem cada um alcançar um serviço local enquanto o acesso mútuo fica excluído pelo desenho do hub. O lado local ainda precisa de rotas de retorno para os prefixos da AWS, e isso é uma mudança de outro time.

O custo é organizacional tanto quanto financeiro. O dono do hub controla relações de encaminhamento das quais outros times dependem, então uma mudança em um anexo pode mover tráfego de um serviço do qual o dono do hub nunca ouviu falar. Horas de anexo e processamento de dados se acumulam com cada rede anexada, e por isso os hubs costumam crescer mais rápido que o time que os opera.

Quando VPNs separadas ou um proxy estreito vencem

Duas VPNs independentes servem a uma implantação pequena com fronteiras operacionais reais: cada conta muda seus próprios túneis e nenhuma pode quebrar a outra editando uma tabela de rotas. Os limites ficam no lado local. O gateway par precisa de capacidade para os túneis adicionais, os planos de endereços não podem se sobrepor, e duas configurações que anunciam os mesmos prefixos precisam de uma preferência deliberada em vez de esperança.

Um proxy é a interface mais estreita. Se a conta A precisa de um banco de dados ou de uma API na conta B, um intermediário delimitado dá uma entrada definida com sua própria história de autenticação, registro e disponibilidade. Também é a opção mais propensa a uso indevido: um intermediário que encaminha para qualquer destino privado tornou-se um relé sem restrições com passos extras, e não se comportará como trânsito transparente de VPC para rede local para mais nada.

Vale a pena ler as restrições de peering de VPC antes de tudo isso, porque explicam por que a quarta ideia volta sempre e por que não pode funcionar.

Escolha a interface mais estreita que atende ao requisito

Ordene as perguntas: A precisa de uma rede, de um conjunto de redes ou de um único serviço? O time local quer um caminho ou vários? Quem pode mudar o encaminhamento do tráfego do outro time? A primeira resposta que produz a interface mais estreita é a arquitetura, e tudo depois disso é implementação.

Registre a resposta com o plano de prefixos, a propriedade das rotas, o inventário de túneis ou anexos e o modo de falha que cada lado espera. Quando alguém perguntar mais tarde por que a conta A não pode simplesmente usar a VPN da conta B, esse registro é a resposta, e poupa você de rediscutir as mesmas três opções no próximo projeto.