Como conectar várias VPCs com o AWS Transit Gateway

English version: How to connect multiple VPCs with AWS Transit Gateway

Duas aplicações na AWS. Cada uma vive na própria rede. Um dia um servidor de desenvolvimento precisa alcançar um diretório que mora em outra VPC, a de serviços compartilhados. A pergunta parece simples: como ligar essas redes?

A AWS oferece mais de um jeito. O primeiro, o VPC Peering, resolve bem o caso de duas redes. Quando a conta ganha homologação, produção e mais um serviço compartilhado, o mesmo desenho vira uma teia. O AWS Transit Gateway entra exatamente nesse ponto: um hub no meio, em vez de um cabo entre cada par.

Este texto não é um clique a clique no console. É o mapa da topologia: o que cada peça faz, por onde o pacote anda e quando o Peering ainda basta.

Antes dos desenhos, as palavras que o restante do artigo usa o tempo todo.

Uma VPC (Virtual Private Cloud) é a rede virtual da sua conta em uma região. Região é o conjunto de datacenters de um lugar, por exemplo us-east-1 (Norte da Virgínia). Dentro da VPC ficam as máquinas, os balanceadores, os bancos. Uma VPC não conversa com outra VPC por acaso. Elas nascem isoladas.

A AWS divide cada região em zonas de disponibilidade (Availability Zones): datacenters separados dentro da mesma região. Se uma zona cai, a outra continua. A letra no final do nome (us-east-1a, us-east-1b) é a zona.

CIDR é a forma de escrever o intervalo de IPs da rede. Em 10.0.0.0/16, os primeiros 16 bits identificam a rede. Restam 16 bits para os hosts: 65.536 endereços, de 10.0.0.0 a 10.0.255.255. O prefixo 10. é privado. Não serve como endereço na internet pública. Duas VPCs que vão se comunicar não podem usar o mesmo bloco. Se as faixas se sobrepõem, o Peering recusa a conexão. O Transit Gateway até aceita o attachment, mas não propaga o CIDR sobreposto e não roteia entre CIDRs iguais ou sobrepostos. Nos dois casos a conversa entre essas redes não acontece.

Uma sub-rede (subnet) é um pedaço da VPC em uma zona. A instância EC2 não “mora na VPC” de forma abstrata: ela recebe uma interface de rede elástica (ENI), o adaptador de rede virtual, e essa interface fica em uma sub-rede.

A tabela de rotas da VPC é a lista que a sub-rede consulta para saber o próximo salto. Destino 10.0.0.0/16 com alvo local significa: esse endereço é desta VPC, entregue aqui dentro. Qualquer outro destino precisa de uma linha extra. Sem essa linha, o pacote não sai.

Os quatro nomes deste artigo. Estes CIDRs são os do laboratório. Quando um diagrama oficial da AWS mostrar VPC A e 10.1.0.0/16, ignore os números do desenho e use a tabela:

1. Duas VPCs: o VPC Peering resolve

Comece com VPC-DEV (10.0.0.0/16) e VPC-SHARED (10.3.0.0/16). Um serviço em DEV precisa do diretório em SHARED. As duas redes estão na mesma região. Os CIDRs não se sobrepõem.

VPC Peering é uma conexão de rede entre exatamente duas VPCs. O tráfego usa IPs privados. Não passa pela internet pública. A AWS monta isso sobre a infraestrutura da VPC: não é um VPN, não é um hardware extra no meio do caminho, e a documentação trata a conexão como sem ponto único de falha e sem gargalo de banda próprio.

Fonte: VPC peering configurations with routes to an entire VPC, Amazon VPC. No diagrama, VPC A e VPC B. Leia A como VPC-DEV e B como VPC-SHARED. Os CIDRs do laboratório são os da tabela do início, não os que o desenho oficial eventualmente mostrar.

O Peering, sozinho, não move pacote nenhum. Cada VPC precisa de uma rota apontando o CIDR da outra para a conexão de peering (o identificador começa com pcx-).

Tabela de rotas da VPC-DEV:

Tabela de rotas da VPC-SHARED:

O caminho de um pacote, do servidor 10.0.10.20 em DEV até o diretório 10.3.10.5 em SHARED:

1. A sub-rede de DEV consulta a tabela de rotas da VPC.
2. 10.3.10.5 cai em 10.3.0.0/16. O alvo é o Peering.
3. A AWS entrega o pacote na VPC-SHARED pelo caminho privado.
4. Em SHARED, 10.3.10.5 é local. A interface do diretório recebe.
5. A resposta volta pelo mesmo Peering, porque a tabela de SHARED tem a rota inversa.

Para duas VPCs, isso é suficiente. Não há hub no meio. Não há tabela de rotas extra além das tabelas das VPCs. O controle é ponta a ponta: quem não tem a rota, não fala.

2. Várias VPCs: a teia do Peering

Acrescente VPC-HML (10.1.0.0/16) e VPC-PROD (10.2.0.0/16). Agora as quatro redes precisam falar entre si. O Peering DEV-SHARED da seção 1 continua. Faltam as outras.

Aqui aparece a regra que muda o desenho. O VPC Peering não é transitivo. Se DEV está peered com SHARED e DEV está peered com PROD, SHARED e PROD não se falam através de DEV. A AWS não deixa uma VPC servir de ponte.

Fonte: One VPC peered with two VPCs, Amazon VPC. VPC B e VPC C não trocam tráfego pela VPC A.

No diagrama, o centro parece um hub. Não é. Cada linha é um Peering separado. Sem a terceira linha, as pontas estão mudas uma para a outra.

Com três redes se falando, o total é três conexões. Depois da seção 1 você já tem DEV-SHARED. Faltam, por exemplo, DEV-HML, DEV-PROD, HML-PROD, HML-SHARED e PROD-SHARED se a malha for das quatro. A conta da malha completa é n × (n − 1) / 2. Três VPCs: três conexões. Quatro VPCs: seis.

Fonte: Three VPCs peered together, Amazon VPC. Três conexões, uma entre cada par. O padrão para quatro VPCs é o mesmo, com seis linhas. A documentação oficial não publica um diagrama exatamente com VPC-DEV, VPC-HML, VPC-PROD e VPC-SHARED. Um diagrama próprio com essas quatro caixas deixaria a conta mais óbvia. Enquanto ele não existir, use a tabela abaixo e, para ver a teia crescer de verdade, o desenho oficial de sete VPCs.

Fonte: Multiple VPCs peered together, Amazon VPC. Sete VPCs, 21 conexões.

Malha das quatro VPCs deste artigo:

A tabela de rotas da VPC-DEV, nesse desenho, deixa de ter uma linha extra. Ela passa a ter três: HML, PROD e SHARED, cada uma com o próprio pcx-. Quando entra a quinta VPC, cada uma das quatro antigas ganha mais uma rota e mais um Peering. A operação cresce no produto, não na soma.

O Peering continua certo para um par, ou para um centro que só precisa ser alcançado (o desenho “uma com duas”, sem as pontas se falarem). Ele deixa de ser o desenho confortável quando a malha vira regra.

3. O mesmo conjunto, agora num hub

O AWS Transit Gateway é um roteador virtual da região. Ele encaminha pacotes pelo endereço IP de destino (camada 3), não pelo endereço MAC da placa. As VPCs não se ligam mais umas às outras. Cada uma se liga uma vez ao gateway. O tráfego entre elas passa por esse centro. A AWS descreve isso como uma topologia hub-and-spoke: o Transit Gateway é o cubo, cada VPC é um raio.

Um attachment é a ligação de um recurso ao Transit Gateway. Para este artigo, o attachment que importa é o de VPC. A AWS também aceita VPN Site-to-Site, Direct Connect gateway, Connect (SD-WAN), peering entre Transit Gateways e, em cenários mais novos, network function attachments. Não vamos configurar esses outros tipos aqui. Eles existem para você não achar que o Transit Gateway só fala com VPC.

Quando você cria um VPC attachment, escolhe uma sub-rede por zona de disponibilidade. A AWS coloca uma ENI nessa sub-rede. Essa ENI é a porta de entrada e de saída do Transit Gateway naquela zona. Recurso em zona sem attachment não alcança o gateway. A recomendação da documentação é habilitar mais de uma zona.

Essa sub-rede do attachment não precisa ser a sub-rede da aplicação. A prática da AWS é reservar uma sub-rede pequena, por exemplo /28, só para o Transit Gateway, em cada zona que você habilitar. O network ACL dessa sub-rede fica aberto. As máquinas continuam nas sub-redes de carga. Essas sub-redes de carga, na mesma zona, ainda precisam da rota para o tgw- na tabela de rotas da VPC. Sem essa rota, o pacote da aplicação não chega na ENI do gateway.

O Transit Gateway é altamente disponível por desenho. Um segundo gateway na mesma região não é o que garante a disponibilidade. Serve para outro domínio de roteamento, para reduzir o raio de um erro de configuração, ou para outra região (disaster recovery).

O attachment, sozinho, também não move pacote. Faltam duas tabelas, de tipos diferentes.

Tabela de rotas da VPC. Continua na sub-rede, como no Peering. Em vez do alvo pcx-, o alvo passa a ser o Transit Gateway (tgw-…). Sem essa rota, o pacote nem sai da VPC.

Tabela de rotas do Transit Gateway. É outra tabela, dentro do gateway. Ela não substitui a da VPC. A da VPC responde: “este pacote deve ir ao Transit Gateway?”. A do Transit Gateway responde: “chegou aqui; para qual attachment mando?”.

Por padrão, o Transit Gateway nasce com uma tabela de rotas default. Essa tabela é a de associação default e a de propagação default. Se você desligar as duas opções na criação, a AWS não cria tabela default. Cada attachment se associa a exatamente uma tabela do gateway. O mesmo attachment pode propagar o CIDR da VPC para uma ou mais tabelas. Associação é o mapa que o attachment lê quando um pacote chega dele. Propagação é o anúncio: “esta rede existe, grave o CIDR nesta tabela”.

A documentação oficial do “roteador centralizado” mostra três VPCs e, no mesmo desenho, um VPN. O VPN não faz parte do laboratório das quatro VPCs. O cubo e os raios, sim. Ignore os CIDRs do print (10.1, 10.2, 10.3, 10.99.99). Use 10.0, 10.1, 10.2 e 10.3 da tabela do laboratório.

Fonte: How AWS Transit Gateway works, Amazon VPC. O desenho oficial tem três VPCs e um VPN. A quarta VPC deste artigo (VPC-SHARED) entra do mesmo jeito: mais um attachment, mais uma linha na tabela do gateway. Não existe diagrama oficial com exatamente essas quatro caixas; o padrão é o hub-and-spoke.

Quatro attachments, uma tabela default, associação e propagação default ligadas. A tabela do Transit Gateway fica assim:

Na VPC-DEV, a tabela da sub-rede de carga (sem mandar a internet inteira para o gateway):

A documentação do cenário centralizado usa 0.0.0.0/0 apontando para o Transit Gateway porque aquele exemplo também tem VPN: o que não for local vai ao gateway e, de lá, pode seguir ao escritório. Sem VPN e sem rota correspondente no gateway, um 0.0.0.0/0 para o tgw- engole o tráfego de internet da VPC e o derruba. Por isso o exemplo daqui lista os CIDRs vizinhos, um a um.

Caminho de 10.0.10.20 em DEV até 10.2.10.8 em PROD, agora pelo hub:

1. A tabela da sub-rede em DEV vê 10.2.0.0/16 → tgw-….
2. O pacote entra no Transit Gateway pelo attachment de DEV.
3. O gateway consulta a tabela associada a esse attachment. Com a default, encontra 10.2.0.0/16 → attachment de PROD.
4. Se o attachment de PROD existe na mesma zona de onde o pacote veio, o gateway usa essa zona. Se não existe, escolhe uma zona em que o attachment de PROD esteja presente.
5. Em PROD, a tabela da VPC entrega 10.2.10.8 como local.
6. A resposta faz o caminho inverso: tabela da sub-rede de PROD → Transit Gateway → attachment de DEV.

Quatro VPCs, quatro attachments. A quinta VPC pede o quinto attachment, uma rota no gateway (muitas vezes só a propagação do CIDR) e uma linha nas tabelas das VPCs que devem alcançá-la. A conta deixa de ser n × (n − 1) / 2 conexões e vira n raios.

O whitepaper de conectividade VPC-a-VPC da AWS resume o mesmo cubo, inclusive com Transit Gateways em mais de uma região ligados por peering. Esse desenho já é o passo seguinte: o Transit Gateway é um recurso regional; outra região pede outro gateway e um peering entre eles. Fica como referência, não como o laboratório deste texto.

Fonte: AWS Transit Gateway, whitepaper Amazon VPC Connectivity Options.

4. Separar ambientes sem desligar o hub

No cenário anterior, DEV alcança PROD. Em muita conta isso é exatamente o que você não quer. Homologação não deveria escrever no banco de produção. Produção não deveria depender de uma máquina de desenvolvimento.

O Transit Gateway não isola por mágica. A tabela default, com tudo associado e tudo propagado, é um roteador único: quem está ligado, fala. O isolamento vem de mais de uma tabela de rotas no gateway, escolhendo o que cada attachment lê e o que cada attachment anuncia.

A documentação oficial chama isso de “isolated routers that use a shared service”. Três VPCs de carga não se falam. Todas falam com uma VPC de serviços compartilhados (e, no desenho oficial, também com um VPN).

Fonte: Example: Isolated VPCs with shared services, Amazon VPC. Ignore os CIDRs deste print. No desenho oficial, VPC A 10.1.0.0/16, VPC B 10.2.0.0/16 e VPC C 10.3.0.0/16 são as isoladas; VPC D 10.4.0.0/16 é shared services; há um VPN 10.99.99.0/24. No laboratório: A/B/C são VPC-DEV (10.0.0.0/16), VPC-HML (10.1.0.0/16) e VPC-PROD (10.2.0.0/16). D é VPC-SHARED (10.3.0.0/16). O 10.3 do print é a VPC C isolada, não a SHARED. O VPN do print não entra no laboratório. O 0.0.0.0/0 que a documentação coloca nas tabelas das VPCs desse exemplo existe por causa do VPN. Sem VPN, não use 0.0.0.0/0 para o tgw-.

Duas tabelas no Transit Gateway:

• RT-ISOLATED, associada aos attachments de DEV, HML e PROD.
• RT-SHARED, associada ao attachment de SHARED.

Propagação, no mesmo espírito da documentação:

• DEV, HML e PROD propagam só para RT-SHARED. Assim SHARED aprende 10.0.0.0/16, 10.1.0.0/16 e 10.2.0.0/16.
• SHARED propaga para RT-ISOLATED. Assim as três de carga aprendem 10.3.0.0/16. A documentação também propaga SHARED para a tabela shared. O CIDR de SHARED na própria RT-SHARED não é o que encaminha o retorno: o tráfego que já está dentro de SHARED usa a rota local da VPC.

RT-ISOLATED (o que DEV, HML e PROD leem):

Não há linha para 10.0.0.0/16, 10.1.0.0/16 nem 10.2.0.0/16. Pacote de DEV para PROD chega ao gateway, a tabela associada não tem rota, o tráfego não segue. A documentação descreve esse caso: os pacotes “are blocked because there is no route for them in the transit gateway route table”.

RT-SHARED (o que SHARED lê):

Tabelas das VPCs neste cenário. DEV, HML e PROD só conhecem SHARED pelo tgw-. SHARED conhece as três.

VPC-DEV (HML e PROD iguais, trocando o local):

VPC-SHARED:

Caminho permitido, DEV → SHARED (10.0.10.20 para 10.3.10.5):

1. Tabela da VPC em DEV: 10.3.0.0/16 → tgw-….
2. Pacote entra pelo attachment de DEV. O gateway lê RT-ISOLATED.
3. Destino 10.3.10.5 casa com 10.3.0.0/16 → attachment de SHARED.
4. Em SHARED, a tabela da VPC entrega 10.3.10.5 como local.
5. A resposta: tabela da VPC em SHARED vê 10.0.0.0/16 → tgw-….
6. O pacote entra pelo attachment de SHARED. O gateway lê RT-SHARED, encontra 10.0.0.0/16 → DEV.
7. Em DEV, 10.0.10.20 é local.

Caminho bloqueado, DEV → PROD (10.0.10.20 para 10.2.10.8):

1. A tabela da VPC-DEV neste cenário não tem rota para 10.2.0.0/16. O pacote nem sai da VPC.
2. Se alguém acrescentar essa rota por engano, o pacote chega ao gateway e RT-ISOLATED não tem 10.2.0.0/16. O Transit Gateway não encaminha.

Duas observações que a documentação insiste e o iniciante costuma misturar.

Primeira: associar e propagar não são o mesmo clique. Um attachment associado a RT-ISOLATED não instala, só por isso, o CIDR dele em RT-ISOLATED. Se DEV, HML e PROD também propagassem para RT-ISOLATED, as três voltariam a se ver. A isolação deste cenário existe porque a propagação das VPCs de carga não cai na tabela que elas mesmas leem.

Segunda: a tabela da VPC e a tabela do Transit Gateway trabalham em sequência, não em paralelo. A VPC decide se o pacote sai rumo ao tgw-. O Transit Gateway decide o attachment de destino. Security groups e network ACLs continuam valendo na interface da instância. Rota no gateway não abre porta 3306 sozinha.

A AWS ainda permite rota blackhole na tabela do Transit Gateway: o prefixo casa e o pacote é descartado de propósito. É um reforço, não o mecanismo principal deste cenário.

5. Peering ou Transit Gateway

Não é uma escada em que o Transit Gateway substitui o Peering em todo desenho.

O Peering continua a escolha honesta quando o problema é “estas duas VPCs precisam se falar” e você não prevê uma malha. Ele não cobra o attachment por hora. A banda entre as duas VPCs não passa por um hop extra de roteador gerenciado.

O Transit Gateway passa a valer quando a pergunta muda: “estas dez VPCs, e as que ainda vão nascer, precisam de um lugar só para a política de quem fala com quem”. Aí o hop extra e a cobrança por attachment são o preço de não manter vinte e uma conexões pcx-.

Dois limites úteis, os dois da documentação, sem transformar o texto em lista de cota:

• Um Transit Gateway não leva dois VPC attachments da mesma VPC.
• A cota default é 5.000 attachments por gateway e 20 tabelas de rotas por gateway, ambas ajustáveis. O que encosta mais cedo, em conta pequena, é o desenho ruim: uma tabela default com tudo misturado.

Há também diferença de MTU. Uma conexão de VPC Peering na mesma região aceita até 9001 bytes. Entre VPCs, Direct Connect, Connect e peering de Transit Gateway, o gateway trabalha com MTU de 8500 bytes. VPN fica em 1500. Na migração de Peering para Transit Gateway, pacote jumbo que vai por um caminho e volta por outro pode cair. A AWS pede para atualizar os dois lados juntos.

O que ficou

VPC-DEV, VPC-HML, VPC-PROD e VPC-SHARED são quatro redes isoladas até alguém criar um caminho. O Peering cria o caminho de um par. Sem transitividade, a malha pede uma conexão para cada par. O Transit Gateway troca essa malha por raios em um hub. A tabela de rotas da VPC ainda decide se o pacote sai. A tabela de rotas do Transit Gateway decide para qual attachment ele vai. Associação e propagação, usadas com duas tabelas, separam DEV, HML e PROD e ainda deixam as três chegarem em SHARED.

O serviço não é obrigatório em conta de duas VPCs. Ele passa a fazer sentido quando a teia de pcx- vira o trabalho, ou quando a política “produção não fala com desenvolvimento, as duas falam com o compartilhado” precisa viver em um lugar só.

Referências oficiais usadas neste texto: What is VPC peering?, How VPC peering connections work, VPC peering configurations, What is a transit gateway?, How AWS Transit Gateway works, Amazon VPC attachments, Transit gateway route tables, Transit gateway design best practices, AWS Transit Gateway quotas, AWS Transit Gateway no whitepaper de multi-VPC, Amazon VPC Connectivity Options e AWS Transit Gateway pricing.