O Transit Gateway agora decide rotas por mais do que o IP de destino. Desde 30 de julho de 2026, o Policy-Based Routing (PBR) está disponível em todas as regiões comerciais onde o serviço existe, e encaminha pacotes por origem, destino, porta e protocolo.
Se você opera redes na AWS, isso elimina arquiteturas inteiras montadas só para contornar o roteamento por destino. Neste artigo você vê como o PBR funciona, três usos práticos, um exemplo completo com AWS CLI e CloudFormation e as armadilhas que derrubam tráfego em produção.
TL;DR
- O PBR escolhe qual route table o pacote usa, com base em origem, destino, portas e protocolo.
- A regra que casa primeiro vence, não a mais específica.
- Pacote sem regra correspondente é descartado (implicit deny).
- Um attachment usa policy table ou route table, nunca as duas.
- Não há cobrança extra além das tarifas padrão do TGW.
O que muda no Transit Gateway com o PBR
Antes do PBR, o TGW decidia a rota apenas pelo IP de destino. Para separar tráfego por origem ou por porta, o time montava várias VPCs, attachments extras e route tables adicionais, como descreve o anúncio oficial da AWS.
Com o PBR, o TGW classifica o pacote por até cinco atributos: CIDR de origem, porta de origem, CIDR de destino, porta de destino e protocolo. Todos são opcionais em cada regra.
Um detalhe muda a forma de pensar o desenho: o PBR não define o próximo salto. Ele seleciona qual route table o pacote consulta, e a rota final continua vindo dessa tabela.
A funcionalidade já vem habilitada em todos os TGWs. Não existe passo de ativação.
Como funciona uma policy table
Uma policy table é uma lista ordenada de regras. Cada regra combina critérios de classificação com uma route table de destino, e a tabela é associada a um attachment.
| Característica | Route table | Policy table |
|---|---|---|
| Critério de decisão | IP de destino | Origem, destino, portas e protocolo |
| Sem correspondência | Pacote descartado | Pacote descartado (implicit deny) |
| Associação ao attachment | Uma por attachment | Uma por attachment, exclusiva com a route table |
Ordem das regras no Transit Gateway
O TGW avalia as regras em ordem numérica crescente e aplica a primeira que casar. As regras do cliente usam números de 1 a 50.000.
Isso não funciona como roteamento por prefixo mais longo. Em um teste prático publicado pela Classmethod, uma regra ampla com número 50 passou na frente de uma regra específica com número 100 e mudou o resultado do tráfego.
Coloque as regras mais específicas nos números menores. Deixe intervalos entre os números (10, 20, 30 ou 100, 200, 300) para inserir regras depois sem renumerar tudo.
Sem regra, sem tráfego
Se nenhuma regra casar, o pacote é descartado. A documentação recomenda uma regra catch-all em um número alto quando você quer que o tráfego restante chegue a uma route table.
Decida isso no desenho: ou você cria o catch-all, ou omite de propósito para bloquear o que não foi previsto.
3 usos do PBR no Transit Gateway
A AWS destaca três cenários no anúncio do recurso. Todos resolvem problemas que antes exigiam mais VPCs.
1. Inspeção seletiva com firewall
Envie apenas o tráfego sensível pelo AWS Network Firewall ou por um appliance de terceiros. O restante segue direto para o destino, sem passar pela inspeção.
No exemplo da documentação, o tráfego de origem 10.1.10.0/24 usa a route table do firewall, e o resto cai em uma regra catch-all para a tabela padrão. Menos tráfego inspecionado significa menos custo de processamento no firewall.
2. Caminho por Direct Connect ou VPN
Direcione o tráfego de uma aplicação por Direct Connect ou por VPN com base em origem, porta ou protocolo. Antes, o destino era o único critério, e duas aplicações para o mesmo prefixo seguiam o mesmo caminho.
Lembre que critérios de porta só valem para TCP e UDP. Para ICMP, GRE ou qualquer protocolo, o TGW ignora os valores de porta.
3. Isolamento entre produção e desenvolvimento
Separe ambientes em domínios de roteamento distintos dentro do mesmo TGW para reduzir movimento lateral. Cada ambiente usa uma route table própria, e a policy table decide quem alcança o quê.
A documentação traz o exemplo de duas VPCs: o tráfego HTTP para 10.0.0.0/16 vai por uma route table de inspeção, e todo o restante usa a tabela padrão.
Exemplo prático com AWS CLI e CloudFormation
Antes de começar, confirme três itens:
- Seu usuário ou role tem as dez ações de PBR da documentação, como
ec2:CreateTransitGatewayPolicyTable,ec2:AssociateTransitGatewayPolicyTableeec2:CreateTransitGatewayPolicyTableEntry. - As route tables de destino já existem.
- O attachment de origem não está associado a uma route table. Se estiver, é preciso desassociar antes.
Atenção: depois de desassociar a route table e antes de associar a policy table, todo o tráfego que entra por esse attachment é descartado. Faça a troca em janela de manutenção.
O fluxo abaixo cria a tabela, duas regras e a associação. Substitua os IDs de exemplo pelos seus.
# 1. Criar a policy table
aws ec2 create-transit-gateway-policy-table \
--transit-gateway-id tgw-0bc994abffEXAMPLE
# 2. Regra 100: tráfego sensível vai pela route table do firewall
aws ec2 create-transit-gateway-policy-table-entry \
--transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
--policy-rule-number 100 \
--policy-rule '{"SourceCidrBlock": "10.1.10.0/24"}' \
--target-route-table-id tgw-rtb-firewall
# 3. Regra 200: catch-all para o restante do tráfego
aws ec2 create-transit-gateway-policy-table-entry \
--transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
--policy-rule-number 200 \
--policy-rule '{}' \
--target-route-table-id tgw-rtb-default
# 4. Desassociar a route table atual do attachment
aws ec2 disassociate-transit-gateway-route-table \
--transit-gateway-attachment-id tgw-attach-0def6EXAMPLE \
--transit-gateway-route-table-id tgw-rtb-CURRENTEXAMPLE
# 5. Associar a policy table ao attachment
aws ec2 associate-transit-gateway-policy-table \
--transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
--transit-gateway-attachment-id tgw-attach-0def6EXAMPLEPara casar por porta, informe protocolo e porta na regra. O exemplo a seguir envia HTTPS com destino à VPC 10.1.0.0/16 para uma tabela de inspeção:
aws ec2 create-transit-gateway-policy-table-entry \
--transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
--policy-rule-number 110 \
--policy-rule '{"DestinationCidrBlock":"10.1.0.0/16","Protocol":"6","DestinationPortRange":"443"}' \
--target-route-table-id tgw-rtb-inspecaoMesma configuração em CloudFormation
Os três tipos de recurso existem no CloudFormation:
AWS::EC2::TransitGatewayPolicyTable, AWS::EC2::TransitGatewayPolicyTableAssociation e AWS::EC2::TransitGatewayPolicyTableEntry.
O trecho abaixo cria a tabela e a regra 100:
Resources:
PolicyTablePBR:
Type: AWS::EC2::TransitGatewayPolicyTable
Properties:
TransitGatewayId: tgw-0bc994abffEXAMPLE
Tags:
- Key: Name
Value: pbr-inspecao
RegraInspecao:
Type: AWS::EC2::TransitGatewayPolicyTableEntry
Properties:
TransitGatewayPolicyTableId: !GetAtt PolicyTablePBR.TransitGatewayPolicyTableId
PolicyRuleNumber: "100"
TargetRouteTableId: tgw-rtb-firewall
PolicyRule:
SourceCidrBlock: 10.1.10.0/24Em um teste de julho de 2026, o cfn-lint ainda apontava erro de tipo inexistente para esses recursos, mas a stack foi criada normalmente. Não trate esse alerta como bloqueio.
Se você usa Terraform ou OpenTofu, confira a versão do provider AWS antes de migrar. Havia uma issue de suporte aberta no repositório do provider logo após o lançamento, e o Pulumi já documenta o recurso PolicyTableEntry.
Armadilhas e boas práticas em produção
Estes são os erros que mais derrubam tráfego quando você adota o PBR:
- Policy table e route table são exclusivas. Associar uma policy table a um attachment que já tem route table retorna erro
IncorrectState. Desassocie primeiro. - A primeira regra que casa vence. Uma regra ampla com número baixo esconde as específicas. Revise a ordem com
get-transit-gateway-policy-table-entries. - Sem catch-all, o resto é descartado. Se você quer fallback, crie a regra com número alto.
- Porta só com TCP ou UDP. A API rejeita porta para outros protocolos, e ICMP e GRE ignoram a faixa de portas.
- Planeje o caminho de volta. A classificação acontece quando o tráfego entra em um attachment associado à policy table. Como em qualquer inspeção centralizada, o retorno precisa ser simétrico para que um firewall stateful não derrube metade do fluxo.
- Route table usada como alvo não pode ser excluída enquanto alguma regra a referenciar.
- Cloud WAN: attachments de peering entre TGW e Cloud WAN não aceitam regras do cliente. As entradas gerenciadas pela AWS são avaliadas primeiro.
- Disponibilidade: o recurso cobre as regiões comerciais. A página do AWS GovCloud (US) listava o PBR como indisponível quando este artigo foi escrito, então confirme antes de planejar.
Custo, segurança e observabilidade
Custo. O PBR não tem cobrança adicional além das tarifas padrão do TGW. Na região US East (Ohio), a AWS cobra US$ 0,05 por hora por attachment de VPC e US$ 0,02 por GB processado (consulta em 26/10/2026). A economia aparece no que você deixa de construir.
Segurança. Aplique privilégio mínimo e conceda as ações de PBR apenas aos papéis de rede. Use condições de recurso para limitar quais attachments e policy tables cada papel altera. A documentação traz um exemplo por tag no AssociateTransitGatewayPolicyTable.
Observabilidade. Quando o TGW descarta um pacote sem regra correspondente, a métrica PacketDropCountNoPolicy incrementa no namespace AWS/TransitGateway. Monitore essa métrica desde o primeiro dia. Para um NOC, ela é o sinal mais direto de que alguém alterou uma regra e quebrou um fluxo.
aws cloudwatch put-metric-alarm \
--alarm-name tgw-pbr-sem-regra \
--namespace AWS/TransitGateway \
--metric-name PacketDropCountNoPolicy \
--dimensions Name=TransitGateway,Value=tgw-0bc994abffEXAMPLE \
--statistic Sum --period 300 --evaluation-periods 1 \
--threshold 0 --comparison-operator GreaterThanThreshold \
--treat-missing-data notBreaching \
--alarm-actions arn:aws:sns:<REGION>:<ACCOUNT_ID>:noc-alertasReferências
Consultadas em 26/10/2026.
- AWS announces general availability of Policy-Based Routing on AWS Transit Gateway (AWS What’s New)
- Policy table concepts in AWS Transit Gateway (documentação AWS)
- Associate a transit gateway policy table (documentação AWS)
- AWS Transit Gateway pricing (AWS)
- I tried out the new Transit Gateway feature, Policy-Based Routing (PBR) (DevelopersIO, teste prático de 31/07/2026)
