Amazon ANS-C01: Transit Gateway e Topologia di Rete — Guida allo studio
Fa parte della AWS Advanced Networking Specialty ANS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Concetti fondamentali
AWS Transit Gateway (TGW) è un hub di transito di rete regionale che centralizza l’instradamento tra Amazon VPC, VPN, gateway Direct Connect e altri Transit Gateway. Nella sua forma più semplice, un TGW agisce come un piano di routing: si creano degli allegati (ad esempio con la chiamata API EC2 CreateTransitGatewayVpcAttachment per i VPC, CreateTransitGatewayAttachment per le appliance o CreateTransitGatewayPeeringAttachment per il peering) e poi si controlla come tali allegati scambiano le rotte associandoli e propagando le rotte in una o più tabelle di instradamento del Transit Gateway. Le tabelle di instradamento su un TGW forniscono le primitive di isolamento e segmentazione che consentono al TGW di agire come più router virtuali (VRF). Per ogni allegato si decide a quale tabella di instradamento del TGW associarlo (usando AssociateTransitGatewayRouteTable) e quali allegati propagano le loro rotte in quali tabelle (tramite le impostazioni di propagazione della tabella di instradamento). Il TGW inoltra i pacchetti in base alla corrispondenza del prefisso più lungo (longest-prefix match) tra tutte le tabelle di instradamento a cui l’allegato di origine è associato, quindi un’attenta progettazione dei confini di associazione/propagazione è il modo in cui si implementano topologie hub-and-spoke, hub segmentati o mesh parziali.
Il peering di Transit Gateway crea un percorso crittografato e privato tra regioni o account diversi (inter-region o inter-account) tra i TGW, che si basa comunque sulla configurazione della tabella di instradamento per abilitare il flusso di traffico. Si crea il peering con CreateTransitGatewayPeeringAttachment dal lato richiedente (requester) e poi si accetta con AcceptTransitGatewayPeeringAttachment dal lato accettante (accepter); dopodiché è necessario aggiungere le rotte alle tabelle di instradamento del TGW appropriate affinché l’allegato di peering venga utilizzato. Il peering non è transitivo: il traffico non fluirà da TGW-A a TGW-C tramite TGW-B a meno che non lo consentano peering espliciti e mappature delle tabelle di instradamento. TGW supporta anche gli allegati di tipo Connect per la connettività ad alte prestazioni con appliance SD-WAN o di terze parti, creati con l’API CreateTransitGatewayConnect, che abilita l’incapsulamento (GRE, VXLAN) e l’inoltro ad alta velocità (high-throughput) verso dispositivi specializzati.
Servizi chiave e configurazione
Configurare gli allegati VPC utilizzando CreateTransitGatewayVpcAttachment e assicurarsi di impostare le opzioni necessarie per l’allegato: ad esempio, abilitare ApplianceModeSupport sugli allegati VPC che inoltrano il traffico ad appliance di rete, in modo che il TGW mantenga la destinazione originale quando invia il traffico all’appliance. Dopo aver creato gli allegati, utilizzare CreateTransitGatewayRouteTable per creare tabelle di instradamento TGW aggiuntive oltre a quella predefinita, quindi chiamare AssociateTransitGatewayRouteTable e abilitare la propagazione per gli allegati scelti in modo che i loro prefissi compaiano nella tabella di instradamento. Per i casi d’uso multicast, creare un dominio multicast con CreateTransitGatewayMulticastDomain, quindi associare con AssociateTransitGatewayMulticastDomain gli allegati che parteciperanno e utilizzare RegisterTransitGatewayMulticastGroupMembers e RegisterTransitGatewayMulticastGroupSources per stabilire l’appartenenza al gruppo e le sorgenti; i domini multicast sono separati dalle tabelle di instradamento unicast e sono necessari per la consegna di gruppo in stile IGMP tra VPC e appliance.
Per la visibilità della topologia globale e l’applicazione delle policy, utilizzare AWS Transit Gateway Network Manager (parte di AWS Network Manager). Creare una Global Network in Network Manager (dalla console o con networkmanager:CreateGlobalNetwork) e registrare i Transit Gateway per ottenere una vista nord/sud (north/south) che attraversa regioni e connessioni on-premise. Network Manager fornisce monitoraggio automatizzato delle prestazioni, visualizzazioni core-periphery e analisi delle rotte; può acquisire le metriche di CloudWatch e i VPC flow log e correlarli con gli allegati TGW e i collegamenti VPN/Direct Connect. L’integrazione con AWS Resource Access Manager (RAM) consente di condividere un TGW gestito centralmente con altri account AWS utilizzando CreateResourceShare e gli allegati principal appropriati; ricordare di impostare l’opzione del TGW AutoAcceptSharedAttachments o di gestire le accettazioni in modo programmatico.
Pattern di progettazione e compromessi
Una topologia hub-and-spoke implementata con un singolo Transit Gateway è il pattern più comune per le architetture multi-VPC e multi-account perché centralizza la connettività, semplifica la distribuzione delle route e consente di consolidare servizi condivisi, appliance di sicurezza e connettività on-premise. Utilizzare una o più tabelle di routing del TGW per fornire segmentazione tra le business unit: associare gli spoke a una tabella di routing specifica per lo spoke e propagare i prefissi dei servizi condivisi solo nelle tabelle che devono vederli. Il compromesso è che la centralizzazione può diventare un singolo collo di bottiglia (chokepoint) per il traffico e un singolo raggio d’impatto (blast radius) in caso di errata configurazione; grandi flussi est-ovest attraverso il TGW possono richiedere un’attenta ingegneria del traffico (traffic engineering), l’implementazione di collegamenti di tipo Connect per appliance ad alto throughput o il posizionamento di TGW regionali per mantenere il traffico locale.
Una topologia full mesh (peering a coppie tra TGW o numerosi collegamenti di peering VPC) fornisce connettività diretta e riduce la dipendenza da un hub centrale per alcuni pattern di traffico, ma introduce complessità operativa all’aumentare del numero di collegamenti e complica l’applicazione delle policy di sicurezza su molti domini amministrativi. Il peering di Transit Gateway (CreateTransitGatewayPeeringAttachment + AcceptTransitGatewayPeeringAttachment) consente la connettività di backbone tra regioni con crittografia attraverso la rete globale di AWS ed è utile quando si desidera l’isolamento regionale più alcuni servizi condivisi, ma è necessario gestire esplicitamente le mappature delle tabelle di routing e accettare che il peering non è transitivo. È possibile combinare i pattern: un TGW hub-and-spoke regionale per ogni regione e il peering tra gli hub per il traffico tra regioni spesso bilancia scalabilità, latenza e domini di errore (failure domains).
Quando si integrano reti on-premise, collegare il Direct Connect Gateway al TGW utilizzando le funzionalità di associazione di Direct Connect (configurare un’interfaccia virtuale privata su Direct Connect e creare un’associazione con il TGW tramite la console o l’API di Direct Connect). Valutare se utilizzare VPN basate su route (BGP su IPSec) per il routing dinamico o route statiche per flussi strettamente controllati. Per i casi d’uso di ispezione basata su appliance e terminazione TLS reciproca (mutual TLS), evitare di terminare il TLS su un’appliance centrale se è richiesta la crittografia end-to-end tra client e backend; eseguire invece la terminazione TLS a livello di applicazione (ad esempio, sui pod in EKS) e utilizzare il routing del TGW per instradare il traffico attraverso un ALB o un Network Load Balancer che preservi gli IP dei client con il Proxy Protocol o utilizzi gli header X-Forwarded-For dell’ALB.
Errori comuni e criteri decisionali
Un errore operativo comune è presumere che il TGW fornisca una segmentazione implicita; non è così. È necessario creare e associare esplicitamente le tabelle di routing e abilitare la propagazione per controllare quali collegamenti (attachment) possono raggiungere quali prefissi. Un’altra trappola frequente è la configurazione errata dei security group e delle NACL: il TGW gestisce solo il routing, quindi tutti i security group e le NACL dei VPC rimangono validi e devono essere allineati con la connettività end-to-end desiderata. Bisogna aspettarsi che i security group stateful vengano valutati a livello di istanza o di load balancer; se è necessario preservare l’IP del client attraverso la terminazione TLS sull’ALB, abilitare l’header X-Forwarded-For dell’ALB e, per i Network Load Balancer, preservare l’IP di origine utilizzando il tipo di target IP e il proxy-protocol dove richiesto.
Le decisioni sulla scalabilità dipendono spesso dal volume di traffico e dai confini amministrativi. Centralizzare molti flussi ad alta velocità attraverso un singolo TGW può complicare le prestazioni e il ripristino in caso di guasto; utilizzare i collegamenti (attachment) di tipo Transit Gateway Connect per link ad alta larghezza di banda verso appliance, considerare l’uso di più TGW con peering per l’isolamento e usare Network Manager per monitorare e attivare allarmi in caso di saturazione. Rivedere sempre i limiti soft per il numero di collegamenti (attachment), tabelle di routing e domini multicast e richiedere aumenti dove necessario invece di fare affidamento sulle quote predefinite.
Problema Pratico: Scenario d’Uso
Azienda: Atlas Financial Services. Sfida: Atlas deve connettere dieci VPC di business unit in us-east-1 a un VPC centrale di servizi condivisi, applicare un accesso di rete basato sul principio del privilegio minimo tra le unit e i servizi condivisi, scalare per supportare decine di altre business unit nel tempo e fornire una contabilizzazione del traffico per singola business unit per risolvere i picchi che occasionalmente saturano il loro link Direct Connect.
Approccio (numerato):
- Provisionare un Transit Gateway regionale con
CreateTransitGatewaye creare una tabella di routing del Transit Gateway dedicata per ogni business unit più una per i servizi condivisi usandoCreateTransitGatewayRouteTable; ciò consente una segmentazione per unit senza l’esplosione di peering tra VPC. - Collegare ogni VPC di business unit tramite
CreateTransitGatewayVpcAttachmente associarlo conAssociateTransitGatewayRouteTablealla tabella di routing della rispettiva unit; collegare il VPC dei servizi condivisi e associarlo solo alla tabella di routing dei servizi condivisi. - Abilitare la propagazione in modo selettivo: fare in modo che il collegamento di ogni business unit propaghi le rotte nella propria tabella di routing e che il collegamento dei servizi condivisi propaghi i suoi prefissi in una tabella separata per i servizi condivisi; quindi, aggiungere rotte statiche nella tabella di routing di ogni unit che puntano al collegamento dei servizi condivisi per i prefissi consentiti, applicando il principio del privilegio minimo non propagando i prefissi delle unit nella tabella dei servizi condivisi.
- Condividere il TGW con altri account AWS usando AWS RAM (
CreateResourceShare) in modo che l’onboarding di una nuova business unit richieda solo un collegamento VPC e un’associazione di tabella di routing, minimizzando l’overhead amministrativo. - Per la contabilizzazione e il troubleshooting del traffico, abilitare i Flow Logs sul TGW e sui VPC associati, e integrare il TGW in AWS Network Manager (
CreateGlobalNetworke registrare il TGW) per visualizzare la topologia e monitorare la larghezza di banda. Correlare i flow log del TGW e le metriche di CloudWatch per identificare quale collegamento sta causando la saturazione del Direct Connect. - Se la capacità del Direct Connect viene saturata durante picchi prevedibili, creare un Direct Connect Gateway e usare un’associazione Direct Connect al TGW; implementare il tagging delle rotte per singola business unit e, se necessario, configurare policy di routing (community BGP on-premise o filtri di rotta) a livello del Direct Connect Gateway per limitare o modellare il traffico per unit.
Logica di AWS: L’uso di un TGW con tabelle di routing per singola unit fornisce una segmentazione robusta e scala linearmente man mano che si aggiungono altre unit, senza la complessità del peer-to-peer. La condivisione del TGW con AWS RAM minimizza la gestione cross-account. La propagazione selettiva e le voci di rotta statiche applicano il principio del privilegio minimo a livello di routing, mentre i security group e le NACL applicano il controllo degli accessi a livello di istanza. I Flow Logs insieme a Network Manager forniscono la visibilità necessaria per individuare quale collegamento o business unit sta saturando il Direct Connect, consentendo ad Atlas di applicare controlli di quota o richiedere aumenti di capacità mirati all’unit responsabile.
← Connettività Ibrida: VPN e Direct Connect · Tutti i domini · DNS e Route 53 →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →