VPC Peering y enrutamiento

1) Por qué Peering y cuándo es apropiado

• separar entornos y dominios (prod/stage/dev) con conectividad privada compartida;
• emisión de plataformas comunes (lógica, KMS/Vault, artefactos) en una red compartida;
• acceso desde aplicaciones a PaaS administradas a través de rutas privadas (a través de hubs/endpoint's).

Cuando sea mejor no peering, sino hub: más de 10-20 redes, necesidad de enrutamiento de tránsito, egresos centralizados, interconexiones → use Transit Gateway/Virtual WAN/Cloud Router.

2) Modelos y limitaciones

2. 1 Tipos de piringa

Intra-región peering - dentro de la región, retrasos mínimos y costo.
Peering inter-regional - entre regiones, generalmente se paga el tráfico interregional.
Cross-project/account - piring entre diferentes cuentas/proyectos (con delegación).

2. 2 Tránsito y NAT

El VPC/VNet Peering clásico no es transitivo: la red A↔B y B↔C no significa A↔C.
NAT a través de una red intermedia para el tránsito - anti-patrón (rompe las IP originales, auditoría compleja).
Para el tránsito - hub-bus: AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Router.

2. 3 Overlapping CIDR

• Encuadernación de direcciones (mejor opción);
• Dominios NAT/Proxy VPC con esquemas unidireccionales (teniendo en cuenta la auditoría y la lógica);
• Para PaaS específicos, PrivateLink/PSC sin acceso L3.

3) Diseño de direccionamiento y rutas

3. 1 Planificación CIDR

Un único supernote (por ejemplo, '10. 0. 0. 0/8 ') → dividido por' región/env/vpc '.
Reserve los rangos para futuros VPC/tenantes (growth-buffers).
IPv6 es un plan de antemano: '/56 'en VPC, '/64' en subred.

3. 2 Enrutamiento

Tablas de ruta: en cada VPC/subred, las rutas explícitas en peer/hub.
Prioridades: gana un prefijo más específico; evite el catch-all a través del piring.
Blackhole-protection: las rutas duplicadas/obsoletas marcan y limpian.

3. 3 Dominios y roles

Spoke (aplicaciones) ↔ Hub (servicios compartidos, egresos, inspección).
Las fiestas son sólo spoke↔hub; spoke↔spoke - a través del hub (segmentación y control).

4) Patrones de topologías

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

Piras pin-tu-pin rectas (A↔B, A↔C...). Ventajas: mínimo de componentes; contras: O (N ²) vínculos y reglas.

4. 2 Hub-and-Spoke

Todos los spoke pierden con Hub VPC/VNet; en el hub - TGW/Virtual WAN/Cloud Router, NAT/egress, inspección. Escalable, fácil de administrar.

4. 3 Multi-región

Hubs locales en cada región; entre los hubs se encuentra el peering inter-regional o troncal (TGW-to-TGW/VWAN-to-VWAN).

5) Seguridad y segmentación

Stateful en host: SG/NSG es la principal barrera; NACL/ACL subred - cerca áspera/hojas de deny.
Política L7 en mesh/proxy (Istio/Envoy/NGINX) - Autorización para mTLS/JWT/claims.
Control Egress: spoke no debe «ver» internet directamente - sólo a través de la puerta de enlace egress/PrivateLink.
Flow Logs e inspección en el hub (GWLB, IDS/IPS) para el tráfico entre VPC.

6) DNS и split-horizon

Cada zona privada es visible en los VPC deseados (Zonas Privadas Hosted/DNS/Zonas Privadas).
Para PaaS a través de PrivateLink/PSC - registros privados en IP privados endpoint's.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Nomenclatura: 'svc. env. region. internal. corp '- sin PII; Fije el TTL (30-120c) debajo del failover.

7) Observabilidad y pruebas

Métricas: accepted/denied en SG/NSG, bytes per peer, RTT/jitter entre regiones, top-talkers.
Logs: VPC Flow Logs/NSG Flow Logs en SIEM, trazando con 'trace _ id' para corear L7↔L3.
Pruebas de viabilidad: sintéticos TCP/443/puertos DB de diferentes subredes/AZ/regiones; reachability analyzer.
Red Chaos: retrasos/pérdidas entre peer/hub; verificación de temporizadores/retraídos/idempotencia.

8) Rendimiento y costo

La Inter-región casi siempre se tarifica; contar el egress de antemano (atesora en las guarniciones/backups).
MTU/PMTUD: dentro del proveedor, MTU estándar, pero en los límites (VPN, FW, NAT-T) tenga en cuenta MSS-clamp.
Escala horizontal de inspección (GWLB/scale sets) sin cuellos de botella; ECMP para hubs.
El caché/edge y el SWR reducen el tráfico interregional.

9) Características y ejemplos en la nube

9. 1 AWS (VPC Peering / Transit Gateway)

VPC Peering: creamos una conexión peering, agregamos rutas en las tablas de subredes.
No hay tránsito a través del peering convencional. Para el tránsito y el 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 (incluyendo global): banderas Allow forwarded traffic, Use remote gateway para circuitos hub.
Para hubs y tránsito - Virtual WAN/Hub c Route Tables y Policies.

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 sin tránsito; para el centro - Cloud Router + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernetes en redes de piratería

Clúster en spoke, servicios compartidos (lógica/almacenamiento/artefactos) - en hub; Acceso a direcciones privadas.
NetworkPolicy «deny-all» y egresos explícitos en el hub/PrivateLink.
No «arrastre» el Pod CIDR entre VPC; enrutar Node CIDR y utilizar Ingress/Gateway.

11) Trablshuting (trampolín)

1. ¿Los CIDR no se cruzan? Comprobar supersets/subredes antiguas.
2. Tablas de rutas: ¿hay un camino en ambos lados? ¿No hay una ruta más específica que intercepte el tráfico?
3. SG/NSG/NACL: ¿stateful-in/out coinciden? ¿La ACL subred no bloquea el tráfico inverso?
4. DNS: ¿los registros privados/forwarders correctos? Compruebe 'nat + short' de ambas redes.
5. MTU/MSS/PMTUD: ¿No hay fragmentación y taimautas «silenciosos»?
6. Comprobación de logs flow: ¿existe SYN/SYN-ACK/ACK? ¿Quién duerme?
7. Inter-región: cuotas/límites de peer/políticas de organización/etiquetas de enrutamiento.

12) Antipatternas

Un mesh «aleatorio» de decenas de pires sin hub → una explosión de complejidades y saltos de ACL.
Overlapping CIDR "de alguna manera experimentará NAT 's' → la auditoría/identificación de extremo a extremo se rompe.
Egresos públicos en cada spoke → superficie incontrolable y costo.
Ningún split-horizon DNS → fugas de nombres/resolve rotos.
Rutas amplias '0. 0. 0. 0/0 'vía peer → asimetría inesperada de tráfico.
Edición manual en consola sin IaC y revisión.

13) Especificidad de iGaming/finanzas

CDE PCI y circuitos de pago - sólo a través de un hub con inspección; No hay spoke↔spoke de elusión.
Residencia de datos: registros PII/transaccional - dentro de las jurisdicciones; interregional - agregados/anónimos.
Multi-PSP: PrivateLink/canales privados a PSP, proxy egress centralizado por allowlist FQDN y mTLS/HMAC.
Auditoría/WORM: flow logs y cambios de rutas en almacenamiento de información inmutable, retoque por norma.
Cortes SLO: per region/VPC/tenant; alertas a la «fuga de egresos» y la degradación de las RTT interregionales.

14) Lista de comprobación prod

• Plan CIDR sin intersecciones (IPv4/IPv6), grupos de crecimiento reservados.
• Topología del hub-and-spoke; pires - sólo spoke↔hub; tránsito a través de TGW/VWAN/Cloud Router.
• Tablas de ruta: caminos explícitos, sin catch-all a través de peer, control blackhole.
• Se han aplicado SG/NSG/NACL; Políticas L7 en mesh; sólo egresa a través del hub/PrivateLink.
• DNS/PHZ privados están configurados; conditional-forwarders между on-prem/cloud/regions.
• Flow Logs habilitados; dashboards por peer/region; sintética de la alcanzabilidad y pruebas PMTUD.
• IaC (Terraform/CLI) y Policy-as-Code (OPA/Conftest) para reglas/rutas/DNS.
• Documentado runbook 'y (añadir peer, rodar rutas, desactivar spoke).
• Enseñanzas: desconexión del hub/fiesta, medición de las rutas de red RTO/RPO reales.
• Para iGaming/finanzas: aislamiento de PCI, PrivateLink a PSP, auditoría WORM, SLO/alertas por jurisdicciones.

15) TL; DR

Use VPC/VNet Peering para una conectividad privada simple punto a punto, pero no confíe en él para el tránsito - para ello necesita un hub (TGW/VWAN/Cloud Router). Planifique CIDR sin intersecciones, mantenga las rutas explícitas y específicas, aplique políticas stateful SG/NSG y L7 en mesh, DNS - split-horizon. Habilite los registros flow, sintéticos y verificaciones PMTUD. Para iGaming/finanzas: aislamiento de PCI, canales privados a PSP y auditorías inmutables.