Uma VPN site a site para várias VPC no AWS Transit Gateway

Duas VPC precisam da rede do escritório neste trimestre, e é no segundo túnel que a estimativa quebra. O AWS Transit Gateway pode funcionar como um hub de roteamento compartilhado: a VPN é anexada uma vez e cada VPC é anexada ao mesmo hub. A rede local passa então a alcançar cada VPC anexada por uma única conexão. Isso muda quem detém a decisão de roteamento, e é exatamente essa parte que a maioria dos projetos erra.

O anexo da VPN e os anexos das VPC são objetos separados no mesmo gateway, por isso as relações de roteamento têm de ser construídas depois.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Por que o peering não é o atalho que as pessoas esperam

A alternativa tentadora é terminar a VPN na VPC A e emparelhar a VPC B com ela. O peering comum de VPC não oferece trânsito de ponta a ponta pela conexão VPN de A. Um par alcança apenas os endereços que o próprio peering fornece, e uma borda VPN não é um deles. O trânsito é o que um hub oferece; o peering oferece um par.

Essa restrição é propriedade do peering, não uma cota que se possa elevar.

Associação e propagação fazem trabalhos diferentes

Dentro do gateway de trânsito, a associação escolhe a tabela de rotas usada para procurar o tráfego que chega de um anexo. A propagação decide quais tabelas recebem os prefixos aprendidos ou conectados de um anexo. Um único anexo pode ser associado a uma tabela enquanto propaga para várias. Confundir as duas é como um projeto termina com uma alcançabilidade que ninguém planeou.

Um hub pequeno totalmente conectado é o caso fácil.

Coloque cada anexo numa única tabela e a VPN, com ambos os prefixos de VPC, resolve-se de forma limpa. Isso também permite alcançabilidade entre VPC que a organização talvez nunca tenha querido, porque uma tabela compartilhada não conhece o conceito de spoke.

As rotas das cargas de trabalho vivem noutro lugar

Cada sub-rede de carga de trabalho ainda precisa da sua própria rota para o gateway de trânsito para os prefixos locais pretendidos. Essas tabelas de rotas das VPC são objetos separados das tabelas do próprio gateway de trânsito. Adicione os prefixos necessários e preserve as rotas existentes em vez de substituir cada destino por um novo default. Uma rota de sub-rede também não anuncia nada ao dispositivo do cliente.

Escolha roteamento dinâmico ou estático de forma deliberada; o peering não fornece nenhum dos dois.

Isole os spokes sem perder o acesso local

Quando A e B podem ambos chegar ao escritório mas não devem rotear um para o outro, separe as tabelas. A tabela associada do anexo da VPN contém os prefixos das VPC. A tabela associada dos anexos das VPC contém os prefixos locais, sem nenhuma rota que ligue A a B. É a propagação que produz essa relação, por isso nunca precisa de aceitar todas as associações predefinidas.

Isto é isolamento de roteamento, e não é autorização da aplicação.

Os grupos de segurança, as ACL de rede, as firewalls dos anfitriões e as permissões próprias de cada serviço continuam a decidir que tráfego é admitido. Se for necessária inspeção, desenhe o caminho suportado de forma explícita em vez de presumir que o hub a executa.

O que o hub não corrige

Os planos de endereçamento continuam a não poder sobrepor-se, porque o hub não permite que um prefixo identifique duas cargas de trabalho. Cada anexo de VPC precisa da cobertura de Availability Zone que as suas cargas de trabalho esperam. Com BGP, as rotas do dispositivo do cliente de volta a cada prefixo necessário têm de corresponder ao desenho e à sua política de importação. Um anúncio em falta parece exatamente um túnel quebrado.

A conexão VPN e o gateway de trânsito são agora infraestrutura compartilhada.

Planeie a redundância dos túneis, a capacidade dos dispositivos, a monitorização e a manutenção em torno de todas as VPC dependentes em vez de tratar cada uma como ligada de forma independente.

A migração de um esquema existente com virtual private gateway merece o mesmo plano explícito. Construa os anexos e as políticas, mova um caminho de carga de trabalho controlado e confirme as relações permitidas e recusadas antes de retirar o caminho antigo. A centralização ajuda quando dá à equipa de rede um único local para gerir a conectividade partilhada, e prejudica quando esconde quem pode chegar a quem atrás de uma única tabela grande.