VPC Peering e Routing

1) Porquê o Peering e quando ele é apropriado

• Separação de ambientes e domínios (prod/estágio/dave) com uma conectividade privada comum;
• levar plataformas compartilhadas (loging, KMS/Vault, artefatos) para a rede shared;
• acesso de aplicativos a PaaS controlados através de caminhos privados (via hub/endpoint's).

Quando o melhor não for o peering, mas o hub: mais de 10 a 20 redes, necessidade de trânsito, egress centralizado, interconexões → use o Transit Gateway/Virtual WAN/Cloud Router.

2) Modelos e restrições

2. 1 Tipos de piringa

Intra-region peering - dentro da região, atrasos mínimos e custo.
Inter-region peering - entre regiões, normalmente pago pelo tráfego interregional.
Cross-project/account - uma piringa entre diferentes contas/projetos (com delegação).

2. 2 Transito e NAT

O clássico VPC/VNet Peering não é transitivo: rede A↔B e B↔C não significa A↔C.
A NAT através de uma rede intermediária de trânsito é anti-pattern (quebra IP de origem, auditoria complexa).
Para transitar, hab-pneu: AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Road.

2. 3 Overlapping CIDR

• Excesso de endereços (melhor opção);
• Domínios NAT/Proxy VPC com esquemas unilaterais (com base em auditorias e logs);
• Para específicos, sem acesso L3.

3) Design de direcionamento e rotas

3. 1 Planejamento CIDR

Uma supernet única (por exemplo, '10. 0. 0. 0/8 ') → dividimos por' region/eng/vpc '.
Reserve as faixas para os futuros VPC/Tenantes (growth-buffers).
O IPv6 é um plano antecipado: '/56 'em VPC, '/64' na subrede.

3. 2 Rotação

Rota táveis: em cada VPC/Subrede rotas explícitas no peer/hub.
Prioridades: prefixo mais específico ganha; evite catch-all através da piringa.
Proteção Blackhole: rotas duplicadas/antiquadas marcem e limpem.

3. 3 Domínios e papéis

Spoke (aplicativos) ↔ Hub (serviços gerais, egress, inspeção).
Píeres só spoke↔hub; spoke↔spoke - através do hab (segmentação e controle).

4) Pattern topologias

4. 1 «Simples» mesh (≤5 VPC)

Pin-to-pin direto (A↔B, A↔C...). Benefícios: um mínimo de componentes; contras: O (N ²) laços e regras.

4. 2 Hub-and-Spoke

Todos os spoke com hub VPC/VNet; no hub - GW/Virtual WAN/Cloud Router, NAT/egress, inspeção. Escalável, basta controlar.

4. 3 Região Multi

Hub local em cada região; entre os hub - inter-region peering ou auto-estrada (TGW-to-TGW/VWAN-to-VWAN).

5) Segurança e segmentação

Stateful no hóspede: SG/NSG - a principal barreira; NACL/sub-LCA é uma vedação bruta/leny-listras.
L7 políticas em mesh/proxy (Istio/Envoy/NGINX) - permissão por mTLS/JWT/claims.
Controle Egress: O spoke não deve «ver» diretamente a Internet - apenas através da entrada egress/Private Link.
Flow Logs e inspeção em hub (GWLB, IDS/IPS) para tráfego mage-VPC.

6) DNS и split-horizon

Cada área privada é visível em VPC (Private Hosted Zonas/Private DNS/Zonas).
Para PaaS através de PrivateLink/PSC, os registos privados para IP endpoint 'ov são privados.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Nome: 'svc. env. region. internal. corp '- sem PII; fixe o TTL (30-120s) sob o feelover.

7) Observabilidade e testes

Métricas: aceited/denied em SG/NSG, bytes per peer, PTT/jitter entre regiões, top-talkers.
Logi: VPC Flow Logs/NSG Flow Logs no SIEM, rastreamento com 'trace _ id' para a coralização de L7↔L3.
Testes de alcançabilidade: sintético TCP/443/DB-portos de diferentes subsetores/AZ/regiões; reachability analyzer.
Rede Chaos: atrasos/perdas entre peer/hub; verificação de temporizações/retrações/idempotação.

8) Desempenho e custo

inter-region é quase sempre tarifado; conte o egress com antecedência (custeado por logs/bacaps).
MTU/PMTUD: Dentro do provedor, MTU padrão, mas nos limites (VPN, FW, NAT-T), leve em conta o MSS-clamp.
Escala horizontal de inspeção (GWLB/scale sets) sem estreitamentos; ECMP para hub.
O dinheiro/edge e o SWR reduzem o tráfego interregional.

9) Características e exemplos na nuvem

9. 1 AWS (VPC Peering / Transit Gateway)

VPC Peering: Criando uma conexão peering, adicionando rotas em tabelas de subtítulos.
Não há trânsito através de um peering normal. Para trânsito e modelo centralizado - Transit Gateway.

hcl resource "aws_vpc_peering_connection" "a_b" {
vpc_id    = aws_vpc. a. id peer_vpc_id  = aws_vpc. b. id peer_owner_id = var. peer_account_id auto_accept  = false tags = { Name = "a-b", env = var. env }
}

resource "aws_route" "a_to_b" {
route_table_id     = aws_route_table. a_rt. id destination_cidr_block = aws_vpc. b. cidr_block vpc_peering_connection_id = aws_vpc_peering_connection. a_b. id
}

9. 2 Azure (VNet Peering / Virtual WAN)

VNet Peering (incluindo global): bandeiras Allow forwarded traffic, Use remote gateway para circuitos hab.
Para hub e trânsito - Virtual WAN/Hub c Rota Táveis e Polices.

bash az network vnet peering create \
--name spokeA-to-hub --vnet-name spokeA --remote-vnet hub \
--resource-group rg --allow-vnet-access --allow-forwarded-traffic

9. 3 GCP (VPC Peering / Cloud Router)

VPC Peering sem trânsito; para o centro - Cloud Rouster + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernetes em redes de piringas

Cluster em spoke, serviços compartilhados (loging/armazenamento/artefatos) - em hub; Acesso a endereços privados.
NetworkPolicy «deny-all» e egress explícito para hab/Private Link.
Não «leve» Pod CIDR entre VPC; Roda o Node CODR e use o Ingress/Gateway.

11) Trapachuting (espartilho)

1. Os CIDR não se cruzam? Verifique os supersalários/subtetos antigos.
2. Tabelas de rota: Há algum caminho para os dois lados? Não há uma rota mais específica para interceptar o tráfego?
3. SG/NSG/NACL: stateful-in/out correspondem? Será que a LCA subnacional bloqueia o tráfego inverso?
4. DNS: gravações privadas corretas/forwarders? Verificar 'dean + short' de ambas as redes.
5. MTU/MSS/PMTUD: Não há fragmentação ou temporizações silenciosas?
6. Verificação de flow logs: há SYN/SYN-ACK/ACK? Quem está a drenar?
7. Inter-region: quotas/limites de piringa/política de organização/tags de rotação.

12) Antipattern

«Casual» mesh de dezenas de píeres sem hub → explosão de complexidades e omissões LCA.
O Overlapping CIDR «um dia faremos NAT's» → quebra a auditoria/identificação completa.
Egress público em cada spoke → superfície descontrolada e custo.
Não há split-horizonte DNS → vazamento de nomes/ressalvas batidas.
Grandes rotas '0. 0. 0. 0/0 'através do peer → asimetria inesperada de tráfego.
Edição manual no console sem IaC ou revisão.

13) Especificidades do iGaming/Finanças

O PCI CDE e os circuitos de pagamento - apenas através do hab com inspeção; Não há spoke↔spoke para contornar.
Data residency: PII/logs de transação - dentro das jurisdições; interregionalmente - unidades/anónimo.
Multi-PSP: Private Link/canal privado para PSP, proxy centralizado egress por allowlist FQDN e mTLS/HMAC.
Auditoria/WORM: flow-logs e alterações de rotas no armazenamento imutável, retensas de acordo com as normas.
Cortes SLO: per region/VPC/tenant; alertas para «fuga de egress» e a degradação da RPT interregional.

14) Folha de cheque pró-prontidão

• Plano CIDR sem interseções (IPv4/IPv6), pool de crescimento reservado.
• Topologia hub-and-spoke; píeres - apenas spoke↔hub; transitar através do TGW/VWAN/Cloud Router.
• Road table: caminhos claros, sem catch-all via peer, controle blackhole.
• SG/NSG/NACL aplicados; Políticas L7 em mesh; egress somente através do hab/Private Link.
• Private DNS/PHZ configurados; conditional-forwarders между on-prem/cloud/regions.
• Flow logs incluídos; dashboards peer/region; sintética e testes PMTUD.
• IaC (Terraform/CLI) e Policy-as-Code (OPA/Conftest) para as regras/rotas/DNS.
• São documentados runbook 'e (adicionar peer, desativar rotas, desativar spoke).
• Exercício: desativação do hub/píer, medição de RTO/RPO real.
• Para o iGaming/Finanças: isolamento PCI, PrivateLink para PSP, auditoria WORM, SLO/alertas de jurisdição.

15) TL; DR

Use o VPC/VNet Peering para uma simples conectividade privada ponto-a-ponto, mas não se baseie nele para transitar - para isso você precisa de um hab (TGW/VWAN/Cloud Router). Planeje o CIDR sem interseções, mantenha as rotas explícitas e específicas, aplique o status SG/NSG e as políticas L7 em mesh, o DNS em split-horizonte. Inclua logs flow, sintéticos e verificações PMTUD. Para o iGaming/Finanças - isolamento PCI, canais privados para PSP e auditoria imutável.