Transit Gateway: il cuore della topologia many-to-many

AWS Transit Gateway (TGW) è il router regionale hub-and-spoke che sostituisce la maglia di VPC peering quando le VPC diventano decine o centinaia. Il punto chiave d’esame: il VPC peering non è transitivo e cresce in modo quadratico (N VPC completamente connesse richiedono N(N-1)/2 peering). TGW centralizza il routing: ogni VPC, ogni Site-to-Site VPN e ogni Direct Connect gateway si collega come attachment, e più route table sul TGW permettono la segmentazione — per esempio isolare produzione da sviluppo, oppure creare una shared-services VPC raggiungibile da tutte senza dare visibilità reciproca. In scenari multi-account, il TGW si condivide con l’organizzazione tramite AWS Resource Access Manager (RAM), evitando un TGW per account. Per il traffico tra region si usa il TGW peering (inter-region). Il trade-off: TGW ha un costo per attachment e per GB elaborato; per due sole VPC il peering resta più economico e a latenza leggermente inferiore.

Direct Connect, Site-to-Site VPN e ridondanza ibrida

AWS Direct Connect (DX) fornisce una connessione fisica dedicata verso AWS: banda stabile, latenza prevedibile e costi di trasferimento dati inferiori rispetto a Internet. Non è cifrato di per sé (per la cifratura L2 si usa MACsec sulle porte dedicate che lo supportano). Il pattern architetturale enterprise tipico è DX come primario + Site-to-Site VPN come backup, con failover gestito via BGP: l’AS-path prepending o le local preference determinano quale percorso è preferito, e in caso di caduta del DX il traffico converge automaticamente sulla VPN. Per raggiungere VPC in region diverse da un’unica connessione DX si usa il Direct Connect gateway, un oggetto globale che associa una o più VIF private a VGW/TGW in region multiple. Una singola VPN non basta come SLA: per alta disponibilità servono tunnel ridondanti, idealmente su Customer Gateway distinti e, per DX, due connessioni su location o dispositivi separati.

AWS PrivateLink permette di consumare un servizio in modo privato tramite un interface VPC endpoint (una ENI con IP privato nella tua subnet), senza attraversare Internet, senza Internet Gateway e senza peering. La caratteristica decisiva a livello professional: funziona anche con CIDR sovrapposti. Poiché il consumer parla con una ENI locale nel proprio spazio di indirizzamento e il provider pubblica il servizio dietro un Network Load Balancer, non serve alcuna route diretta tra le due reti — cosa che rende PrivateLink la scelta obbligata quando fondi con partner o acquisizioni che hanno range IP conflittuali. È unidirezionale e orientato al singolo servizio: se serve connettività di rete bidirezionale e generica tra VPC, la risposta è TGW o peering, non PrivateLink.

DNS ibrido con Route 53 Resolver

La risoluzione DNS tra on-premises e AWS si realizza con Route 53 Resolver tramite due tipi di endpoint. L’inbound endpoint consente ai server DNS on-premises di risolvere i nomi delle Private Hosted Zone su AWS (il traffico entra verso AWS). L’outbound endpoint, insieme alle resolver rule, inoltra le query per specifici domini dai resolver AWS verso i DNS aziendali on-premises (il traffico esce da AWS). Le resolver rule possono essere condivise tra account via RAM. Serve conoscere la direzione: chi deve risolvere cosa determina quale endpoint creare, ed è un classico punto di confusione d’esame.

Trappole tipiche d’esame

  • Molte VPC + on-premises con routing transitivo → soluzione: Transit Gateway, non VPC peering; il peering non è transitivo e non scala oltre poche VPC.
  • CIDR sovrapposti tra due VPC/aziende → soluzione: PrivateLink (interface endpoint + NLB); peering e TGW richiedono range IP non sovrapposti e falliscono qui.
  • Backup del Direct Connect con failover automatico → soluzione: Site-to-Site VPN in parallelo, con BGP a governare la preferenza di percorso; non una seconda VPN come primario.
  • Una VPC on-premises deve risolvere nomi di una Private Hosted Zone AWS → soluzione: Route 53 Resolver inbound endpoint; l’outbound serve al caso opposto (AWS → DNS aziendale).
  • Accesso a VPC in più region da un solo DX → soluzione: Direct Connect gateway (oggetto globale); una VIF privata da sola resta confinata alla sua region.
  • TGW condiviso su decine di account → soluzione: condivisione via AWS RAM con l’organizzazione, non un Transit Gateway replicato per ogni account.