Amazon ANS-C01: Connettività Ibrida: VPN e Direct Connect — 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
La connettività ibrida in AWS è la combinazione di circuiti di rete forniti privatamente e tunnel IP crittografati per estendere le reti on-premise nel cloud AWS. Site-to-Site VPN fornisce tunnel IPsec (IKEv1/IKEv2) che terminano su un Virtual Private Gateway (VGW) o un Transit Gateway; AWS effettua il provisioning di due tunnel indipendenti per ogni connessione VPN per garantire la resilienza e supporta BGP per il routing dinamico o, se necessario, rotte statiche. Client VPN è un endpoint gestito basato su OpenVPN che supporta l’autenticazione reciproca tramite certificati (ACM Private CA o certificati client caricati) o la federazione SAML per l’identità utente, la propagazione delle rotte in un VPC o Transit Gateway e lo split-tunneling lato client per limitare il traffico che passa in AWS.
AWS Direct Connect offre una connessione fisica dedicata tra la tua sede e AWS. Le connessioni possono essere dedicate (fornite da AWS) o ospitate (fornite da un partner); è possibile aggregare più connessioni utilizzando un Link Aggregation Group (LAG) per presentare un’unica interfaccia logica e aumentare la larghezza di banda; Direct Connect supporta interfacce virtuali private (VIF private) verso i VPC, VIF pubbliche per gli endpoint pubblici di AWS e VIF di transito verso un Direct Connect Gateway per la connettività multi-regione o con un Transit Gateway. Per la protezione dei dati sul collegamento fisico, MACsec è disponibile nelle località supportate per fornire la crittografia dei frame di livello 2 tra l’edge del cliente e l’edge di AWS, mentre la crittografia in transito a livello 3 rimane responsabilità degli endpoint IPsec o TLS.
L’affidabilità e il routing richiedono un controllo esplicito del failover e della selezione del percorso. Gli attributi BGP (local-preference, AS path prepending) vengono utilizzati per preferire Direct Connect rispetto alla VPN per ottenere bassa latenza e throughput elevato, con Site-to-Site VPN o una connessione DX secondaria che fungono da backup automatico. Quando è richiesto il TLS end-to-end, o quando le applicazioni richiedono la conservazione dell’IP di origine del client e un numero molto elevato di connessioni TCP di lunga durata (ad esempio, gRPC su TLS sulla porta 443), si utilizzano pattern di passthrough TCP/TLS come un Network Load Balancer (NLB) o endpoint pubblici diretti sui nodi EKS con controlli di sicurezza appropriati; quando la terminazione al perimetro (edge) è accettabile, l’Application Load Balancer (ALB) supporta HTTP/2 e gRPC, termina la connessione TLS e inserisce gli header X-Forwarded-For in modo che i pod di backend possano registrare gli IP dei client.
Servizi chiave e configurazione
Quando si crea una Site-to-Site VPN, si utilizza l’API EC2 CreateVpnConnection (aws ec2 create-vpn-connection) e tipicamente si collega la vpn-connection risultante a un virtual private gateway (create-vpn-gateway e attach-vpn-gateway) o a un transit gateway specificando il transit-gateway-id. Configurare il dispositivo customer gateway con i parametri del tunnel generati: versione IKE, algoritmi di crittografia (AES-GCM), hashing (SHA-2), gruppo Diffie-Hellman, lifetime e la chiave pre-condivisa. Per il routing dinamico, abilitare BGP e impostare l’ASN e l’IP del neighbor BGP; per un rilevamento più rapido del failover a livello di router, utilizzare BFD dove supportato tra i dispositivi on-premise e l’edge di AWS.
Gli endpoint di Client VPN vengono creati tramite l’API EC2 CreateClientVpnEndpoint (aws ec2 create-client-vpn-endpoint). Si fornisce un certificato server da ACM, un’opzione di autenticazione (certificato o SAML) e si associa l’endpoint a una o più sottoreti del VPC per creare interfacce di rete elastiche. Utilizzare authorize-client-vpn-ingress per aprire le reti consentite per ogni regola di autorizzazione e create-client-vpn-route per inserire (push) le rotte nel VPC. Per popolazioni di utenti numerose e per l’accesso condizionale, integrare Client VPN con AWS Directory Service o identity provider SAML, e scalare in modo concorrente assegnando intervalli di indirizzi CIDR sufficienti all’endpoint di Client VPN.
Il provisioning di Direct Connect utilizza le API di Direct Connect come create-connection o, per le connessioni tramite partner, il partner effettua il provisioning di una connessione ospitata e si utilizzano le API allocate-hosted-connection o accept-virtual-interface. Per aggregare i collegamenti fisici, chiamare create-lag e poi create-private-virtual-interface o create-transit-virtual-interface per collegare un’interfaccia virtuale a un VPC o a un Direct Connect Gateway. Per MACsec, collaborare con il partner o con il portale di ordinazione AWS per richiedere MACsec sulla connessione; la configurazione include lo scambio di chiavi e la corrispondenza della cipher suite sullo switch dell’edge del cliente, e i comandi operativi sono solitamente coordinati al momento del provisioning. Per architetture multi-VPC, è preferibile un Direct Connect Gateway con una VIF di transito per connettersi a un Transit Gateway — questa soluzione scala meglio della creazione di molte VIF private e permette un routing centralizzato attraverso le tabelle di rotta del TGW.
Pattern di progettazione e compromessi
Scegliere un’architettura active-active per un throughput elevato e un tempo di failover ridotto, posizionando due connessioni Direct Connect in diverse location, annunciando prefissi identici con BGP e utilizzando LAG per il raggruppamento dei link all’interno di un sito. La modalità active-active con BGP multipath offre prestazioni superiori e una vera condivisione del carico; tuttavia, richiede un routing simmetrico, un BGP on-premise compatibile e un’attenta ottimizzazione di AS-path e local-preference. Utilizzare Site-to-Site VPN come backup active-passive automatico poiché i tunnel IPsec sono resilienti e raggiungibili a livello globale, ma aspettarsi jitter più elevato, throughput inferiore e tempi di failover più lunghi rispetto a Direct Connect. Laddove è obbligatoria una connettività deterministica e a bassa latenza, una seconda connessione DX è preferibile nonostante il costo più elevato.
Per i requisiti TLS a livello di applicazione, le scelte di progettazione dipendono dal fatto che il load balancer sia autorizzato o meno a vedere il traffico decifrato. Se è richiesto il mutual TLS end-to-end, terminare il TLS sul backend utilizzando un NLB in modalità TCP/TLS passthrough e lasciare che i pod di Kubernetes Ingress gestiscano mTLS; utilizzare il target type ip per EKS in modo che i pod possano scalare e il Cluster Autoscaler possa aggiungere nodi senza modificare la configurazione dell’NLB, e abilitare il proxy protocol v2 se è necessario l’indirizzo IP di origine del client originale a livello del pod. Se la terminazione TLS sull’ALB è accettabile, utilizzare un ALB con un listener HTTPS, configurare i certificati in ACM, abilitare HTTP/2 per il supporto a gRPC e fare affidamento su X-Forwarded-For per gli IP dei client; l’ALB offre un routing basato sul percorso (path-based) verso più target group per l’inoltro basato su URL.
Per la connettività multi-account e multi-VPC dove sono richieste sicurezza granulare e scalabilità, un pattern hub-and-spoke con Transit Gateway e un Direct Connect Gateway centralizzato offre la migliore scalabilità. Collegare ogni VPC di business unit a un Transit Gateway (TGW) e associare il TGW a un Direct Connect Gateway tramite una transit VIF. Utilizzare le tabelle di routing del TGW per imporre la segregazione e usare policy a livello di risorsa, Security Group e Network ACL per controlli granulari. Il compromesso è la complessità operativa nella gestione delle tabelle di routing del TGW e la necessità di progettare attentamente i confini di IAM e degli account.
Insidie comuni e criteri decisionali
Un errore frequente è fare affidamento su una singola VIF per VPC senza considerare i limiti delle VIF e la complessità operativa all’aumentare del numero di VPC; utilizzare un Direct Connect Gateway e VIF di transito quando si prevedono molti VPC o più Regioni. Un’altra trappola comune è presumere che VPN e Direct Connect si comportino in modo identico: le rinegoziazioni delle chiavi IPsec, le implicazioni sulla MTU e le differenze di throughput per tunnel significano che la VPN è un backup affidabile ma non un equivalente in termini di prestazioni. La configurazione errata della terminazione TLS e delle aspettative sull’IP del client downstream è un’altra fonte di errori: scegliere il passthrough del NLB per un vero TLS end-to-end con mTLS, oppure la terminazione sull’ALB e l’elaborazione di X‑Forwarded‑For se l’edge può terminare il TLS.
Infine, il monitoraggio e la visibilità sono essenziali. Abilitare le metriche di CloudWatch per Direct Connect (ConnectionBpsEgress/Ingress), i flow log per la visibilità del VPC e utilizzare gli allarmi di CloudWatch per attivare automazioni che spostino il traffico o notifichino gli ingegneri di rete. Per l’attribuzione forense del traffico quando più unità di business condividono la larghezza di banda su un LAG, correlare le statistiche delle VIF e i flow log del VPC e considerare controlli di banda per VPC a livello di edge per evitare problemi di “noisy neighbor”.
Problema Pratico: Scenario d’Uso
Azienda: Meridian Medical Analytics. Sfida: Meridian gestisce una flotta globale di dispositivi di imaging medicale che utilizzano gRPC sulla porta TCP 443 per caricare flussi crittografati ad alto volume verso un backend ospitato in un cluster Amazon EKS in us-east-1. I dispositivi richiedono il mutual TLS per l’autenticazione client bidirezionale e migliaia di connessioni simultanee e di lunga durata. Il cluster EKS scala automaticamente con Cluster Autoscaler e HPA. Meridian necessita di una bassa latenza deterministica dal proprio datacenter primario e di un failover automatico verso la VPN cloud.
Approccio:
- Provisionare un Network Load Balancer (NLB) davanti al servizio EKS con listener TCP sulla porta 443 e tipo di target impostato su IP, in modo che gli endpoint dei pod possano essere target diretti; configurare l’NLB per il passthrough TLS (non terminare il TLS sull’NLB) affinché il mutual TLS venga negoziato con i pod del backend. Utilizzare
undefined
e
undefined
per configurare l’NLB e i target group. 2. Configurare i container dei pod EKS (Ingress o sidecar) per terminare il mutual TLS utilizzando certificati server e client da una CA privata (ACM Private CA per emettere i certificati server; certificati client provisionati sui dispositivi). Assicurarsi che i pod supportino HTTP/2 gRPC e scalino tramite HPA e Cluster Autoscaler; utilizzare un ritardo di deregistrazione del target group ottimizzato per connessioni di lunga durata. 3. Per la connettività on-premise, provisionare una connessione dedicata Direct Connect (
undefined
) aggregata con un LAG se sono disponibili più circuiti fisici, e creare un’interfaccia virtuale privata (
undefined
) verso un Direct Connect Gateway collegato al proprio Transit Gateway per il routing verso il VPC di EKS. Abilitare MACsec durante il provisioning se il carrier e la località lo supportano per proteggere il trasporto a livello 2. 4. Implementare una Site-to-Site VPN (
undefined
verso un Transit Gateway) come percorso di failover automatico; controllare il failover con gli attributi BGP preferendo Direct Connect (local-preference più alto) e lasciando che la VPN erediti una preferenza più bassa. Utilizzare BFD dove supportato per un rilevamento più rapido dei guasti del percorso. Monitorare le metriche di Direct Connect e VPN in CloudWatch e impostare allarmi per attivare modifiche di ingegneria del traffico o notifiche.
Logica di AWS: Il passthrough TCP del NLB preserva il mutual TLS end-to-end, in modo che i certificati client dei dispositivi siano convalidati dai pod del backend, il che soddisfa il requisito che il traffico non venga decrittato all’edge. Il tipo di target IP e il supporto del NLB consentono di scalare a migliaia di connessioni simultanee e di lunga durata, preservando l’IP del client con il proxy protocol o leggendo l’IP del client dalla sessione TLS, se necessario. Direct Connect fornisce connettività deterministica e a banda larga verso us-east-1 con LAG per la capacità e MACsec per la crittografia del link fisico; la Site-to-Site VPN fornisce un percorso di backup crittografato e raggiungibile a livello globale con failover mediato da BGP. Questo design bilancia sicurezza, prestazioni e scalabilità, allineandosi al contempo con le best practice di configurazione di AWS Direct Connect e VPN.
← Progettazione di VPC e Networking Avanzato · Tutti i domini · Transit Gateway e Topologia di Rete →
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 →