AWS Transit Gateway: Padrões de Projeto Multi-Conta em Alta Escala para 2026

Q: Por que não usar apenas VPC Peering, já que é gratuito para transferência de dados dentro da mesma AZ?

O VPC Peering cria uma confusão de complexidade n^2 e carece de roteamento transitivo. Embora seja mais barato para dados, a sobrecarga de gerenciamento é proibitiva em escala. Use o TGW para o backbone e o Peering apenas para fluxos "elephant flows" específicos de alta largura de banda.

Q: Como lidar com CIDRs sobrepostos em um ambiente TGW?

O TGW não suporta CIDRs sobrepostos em uma Route Table. Você deve usar Private NAT Gateways em VPCs spoke ou uma Translation VPC dedicada com recursos NAT para mapear endereços antes que entrem no core de trânsito.

Q: O TGW suporta multicast?

Sim, via TGW Multicast Domains. Você associa sub-redes VPC e usa IGMP para gerenciar grupos. Este é um recurso de nicho, mas vital para aplicações financeiras legadas ou de broadcast.

Q: Qual é a taxa de transferência máxima de um único TGW?

Cada anexo suporta até 50Gbps de throughput agregado, mas fluxos individuais de 5-tuple são tipicamente limitados a 10Gbps. Aplicações de alto desempenho devem utilizar múltiplos fluxos para atingir a largura de banda máxima.

Q: Devo usar o TGW Connect para integração com SD-WAN?

Sim. O TGW Connect usa túneis GRE e BGP para simplificar a integração com SD-WAN. Isso evita a sobrecarga e os problemas de MTU associados às VPNs IPsec padrão ao conectar appliances virtuais.

Q: Como o Appliance Mode resolve o problema de assimetria de fluxo?

O Appliance Mode garante que o TGW mantenha a simetria de fluxo, forçando o tráfego de retorno através da mesma AZ e ENI usada pelo tráfego de origem. Isso evita que firewalls stateful em uma Inspection VPC descartem pacotes.

Em 2026, o AWS Transit Gateway (TGW) continua sendo a espinha dorsal indiscutível de qualquer arquitetura multi-account de nível empresarial, mas a "lua de mel" do modelo hub-and-spoke acabou para engenheiros que não consideram a fadiga de peering, os limites de quotas e a necessidade absoluta de inspeção centralizada. Se você ainda está gerenciando conexões de VPC peering individuais ou propagação manual de rotas em uma rede com mais de 50 contas, você não está projetando; você está apenas esperando que um loop de roteamento ou uma exceção de "Quota Exceeded" derrube seu ambiente de produção. O projeto moderno do TGW requer um foco implacável na automação do Resource Access Manager (RAM), domínios de roteamento isolados e integração do Gateway Load Balancer (GWLB) para resolver a lacuna de segurança East-West.

A Realidade Multi-Account de 2026: Escale ou Perca

Os dias de uma única conta AWS monolítica já se foram. As organizações agora estão atingindo a marca de mais de 500 VPCs em centenas de contas gerenciadas via AWS Organizations. Nesta escala, o TGW se torna mais do que um roteador; é uma camada de abstração. Usando o AWS Resource Access Manager (RAM), você pode compartilhar um único TGW (residente em uma conta dedicada de Network Services/Hub) em toda a Organization. Isso evita o "shadow networking", onde desenvolvedores criam VPCs isoladas que satisfazem requisitos locais, mas violam as políticas corporativas de egress.

No entanto, escalar para mais de 1.000 VPCs introduz um conjunto específico de restrições. Embora o TGW teoricamente suporte 5.000 anexos por região, o verdadeiro gargalo é o limite da TGW Route Table (atualmente 20 por TGW) e as rotas por TGW route table (10.000). Para sobreviver à escala de 2026, você deve se afastar do roteamento plano e adotar uma abordagem semelhante a VRF dentro do TGW usando várias Route Tables adaptadas aos níveis de aplicação (por exemplo, Prod, Dev, Shared Services, Inspection).

Resource Access Manager (RAM) e o Pipeline de Automação

O compartilhamento manual de TGW via console é um erro grave. Em um ambiente CI/CD profissional, a conta Hub deve compartilhar automaticamente o recurso TGW com toda a Organizational Unit (OU). Quando uma nova conta é provisionada via Control Tower ou uma Account Factory customizada, ela deve receber automaticamente uma "TGW Attachment Request."

# Terraform snippet for RAM sharing
resource "aws_ram_resource_share" "tgw_share" {
  name                      = "central-tgw-share"
  allow_external_principals = false
}

resource "aws_ram_principal_association" "org_association" {
  principal          = data.aws_organizations_organization.current.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

resource "aws_ram_resource_association" "tgw_association" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

Uma dica crítica: Sempre desabilite default_route_table_association e default_route_table_propagation no TGW. Se você deixá-los ativados, cada novo anexo de VPC automaticamente despejará suas rotas locais em uma tabela global e receberá rotas para todas as outras VPCs. Este é um pesadelo de raio de explosão. Você quer roteamento explícito, baseado em intenção.

A VPC de Inspeção: Implementando o GWLB na Borda

Deep Packet Inspection (DPI) para tráfego East-West (VPC-to-VPC) e North-South (VPC-to-Internet) é inegociável. O padrão ouro para 2026 é o padrão Inspection VPC utilizando o Gateway Load Balancer (GWLB) e uma frota de appliances FortiGate ou Palo Alto VM-Series. Usando o TGW, você pode direcionar o tráfego de qualquer VPC spoke para a Inspection VPC antes que ele atinja seu destino.

Isso é conseguido via Appliance Mode. Certifique-se de que o appliance_mode_support esteja habilitado no anexo do TGW à Inspection VPC. Sem isso, o TGW não manterá a simetria de fluxo, enviando a requisição através do firewall de uma AZ e a resposta através de outra, fazendo com que o firewall stateful descarte o pacote. Para uma análise mais aprofundada da integração de firewall, consulte nosso guia sobre Padrões de Projeto FortiGate GWLB.

Traffic Engineering: Segregando Prod, Dev e Shared Services

Para limitar o raio de explosão, trate as TGW Route Tables como VRFs no mundo Cisco. Você deve ter, no mínimo:

Prod_RT: Contém rotas para VPCs de produção. Propaga para a Inspection VPC, mas NÃO para a Dev_RT.
Dev_RT: Contém rotas para ambientes de desenvolvimento. Isolada de Prod na camada TGW.
Inspection_RT: A tabela de "aterragem" para todo o tráfego que requer depuração. Esta tabela tem uma rota padrão (0.0.0.0/0) apontando para o endpoint do GWLB na Inspection VPC.
Edge_RT: Para anexos Direct Connect (DX) ou VPN.

O impacto de custo deste projeto é previsível, mas significativo. Cada anexo TGW custa aproximadamente US$ 36,50/mês por região (com base em US$ 0,05/hora) mais US$ 0,02 por GB de dados processados. Em um ambiente de 1.000 VPCs, você está olhando para US$ 36.500/mês apenas em taxas de anexo. Se você estiver empurrando 1PB de dados através do TGW, adicione mais US$ 20.000. Para necessidades de alta taxa de transferência e baixa latência, considere o VPC Peering para pares de alto volume específicos enquanto mantém o TGW como o plano de gerenciamento.

Mitigação de Raio de Explosão: Filtragem de Rotas e Blackholing

Uma única rota mal configurada em uma TGW Route Table pode facilitar um movimento lateral de ransomware em toda a sua empresa. Use Blackhole Routes estrategicamente. Se um intervalo CIDR específico nunca deveria ser alcançável via TGW (por exemplo, sua sub-rede de gerenciamento legada on-prem que tem seu próprio DX), faça um blackhole explícito nas Spoke Route Tables.

Além disso, implemente Service Control Policies (SCPs) para evitar que os desenvolvedores modifiquem as tabelas de rotas em suas VPCs locais para contornar o TGW. A tabela de rotas da VPC local deve ter um 0.0.0.0/0 ou um CIDR específico apontando para a interface TGW para que o tráfego regional seja inspecionado. Se um desenvolvedor mudar isso para um Internet Gateway (IGW) diretamente, ele terá contornado sua pilha de segurança. Use SCPs para negar ec2:CreateRoute e ec2:DeleteRoute onde o ID do gateway é um IGW, a menos que a conta esteja explicitamente na whitelist.

A Integração do Direct Connect Gateway (DXGW)

Conectar seu data center on-premises a um ambiente TGW multi-account requer um Transit VIF em seu Direct Connect. Não use Private VIFs para isso; eles não escalam e não funcionarão com TGW. O Transit VIF termina em um Direct Connect Gateway (DXGW), que é então associado ao TGW. Isso permite que até 3 TGWs (potencialmente em diferentes regiões) compartilhem a mesma conexão DX.

Em 2026, estamos vendo mais empresas optarem por Dedicated Connections de 100Gbps. Com essa largura de banda, o limite por fluxo do TGW (aproximadamente 10Gbps por fluxo de anexo de VPC) torna-se o gargalo. Para atingir velocidades mais altas, você deve usar múltiplos fluxos ou considerar o AWS Cloud WAN se sua pegada for verdadeiramente global em mais de 10 regiões, pois o Cloud WAN automatiza o peering inter-regional que o TGW exige que você construa manualmente.

Escalando Além de 1000 VPCs: TGW Peering vs. Cloud WAN

Uma vez que você excede os limites físicos ou lógicos de um único TGW, ou quando seus requisitos de latência entre Tóquio e US-East-1 se tornam críticos, você deve decidir entre TGW Peering e AWS Cloud WAN. TGW Peering é um processo estático e manual. Você cria o anexo de peering e então atualiza manualmente as tabelas de rotas em ambos os lados. É tedioso e propenso a "route rot."

O AWS Cloud WAN usa um Network Function Manager e uma Core Network Policy (um documento JSON) para definir como os segmentos (como Prod e Dev) interagem globalmente. Se você estiver operando no nível de uma Fortune 100, o Cloud WAN é o padrão de 2026. No entanto, para a maioria das empresas, um hub TGW regional com TGW Peering para as 2-3 regiões secundárias é mais econômico e fácil de solucionar problemas usando ferramentas padrão como o Reachability Analyzer.

Conclusão: O Veredito da TechLeague

Construir uma rede multi-account em 2026 sem um Transit Gateway é uma receita para a falência operacional. No entanto, o TGW é um roteador "burro" a menos que você o envolva em uma estrutura de política rigorosa. Use RAM para distribuição, múltiplas Route Tables para isolamento e GWLB para inspeção centralizada. Qualquer coisa menos é apenas uma rede plana com um preço de nuvem. Se sua equipe de networking está lutando para desvincular segurança de conectividade em escala, confira nossas auditorias de infraestrutura personalizadas em techleague.io.

Perguntas Frequentes

Por que não usar apenas VPC Peering, já que é gratuito para transferência de dados dentro da mesma AZ?

O VPC Peering cria uma confusão de complexidade n^2. Embora economize nas taxas de processamento de dados, a sobrecarga de gerenciamento de atualização de centenas de tabelas de rotas e security groups, combinada com a falta de roteamento transitivo, o torna impossível de gerenciar em escala. Use o TGW para o plano de gerenciamento e o VPC Peering apenas para fluxos de alta largura de banda "elephant flows" entre duas VPCs específicas.

Como lidar com CIDRs sobrepostos em um ambiente TGW?

O TGW não lida nativamente com CIDRs sobrepostos na mesma Route Table. Você deve usar Private NAT Gateway nas VPCs spoke para traduzir seus IPs de origem antes que cheguem ao TGW, ou usar TGW Route Tables separadas e mapeá-los via uma "Translation VPC" contendo mais instâncias NAT ou firewalls realizando DNAT/SNAT.

O TGW suporta multicast?

Sim, o TGW suporta multicast IGMP. Você deve criar um Multicast Domain no TGW e associar as sub-redes VPC específicas. Isso é crítico para aplicações financeiras legadas ou certos protocolos de streaming de mídia que não foram modernizados para ambientes de nuvem unicast.

Qual é a taxa de transferência máxima de um único TGW?

Enquanto a AWS diz que o TGW escala "dinamicamente", cada anexo de VPC é limitado a 50Gbps de throughput de burst. Crucialmente, um único fluxo TCP geralmente é limitado a 10Gbps. Se você precisar de 100Gbps entre duas VPCs, você precisa garantir que seu tráfego seja distribuído em muitos fluxos distintos de 5-tuple.

Devo usar o TGW Connect para integração com SD-WAN?

Absolutamente. Os anexos TGW Connect permitem que você execute túneis GRE sobre o TGW, permitindo BGP peering diretamente entre seus appliances virtuais SD-WAN (como Cisco SD-WAN ou Silver Peak) e o TGW. Isso elimina a necessidade de inúmeras VPNs IPsec e simplifica significativamente a tabela de roteamento.

Como o Appliance Mode resolve o problema de assimetria de fluxo?

Quando o Appliance Mode está habilitado em um anexo, o TGW garante que, durante a vida útil de um fluxo, ele selecione a mesma Network Interface (e, portanto, a mesma AZ) para o tráfego de retorno que foi usada para a requisição inicial. Isso é vital para firewalls stateful em uma Inspection VPC que, de outra forma, descartariam pacotes se vissem apenas um lado do handshake.