Amazon SAP-C02: Networking e connettività ibrida — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fa parte della AWS Solutions Architect Professional SAP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Architettura VPC e pattern di segmentazione

La progettazione della topologia VPC inizia con la gestione del blast radius (raggio d’impatto) e un routing prevedibile. Per implementazioni di piccole dimensioni, un singolo VPC con più subnet e security group restrittivi può essere efficiente, ma con la crescita dei team e delle applicazioni, il pattern a VPC singolo diventa fragile: quote delle risorse, governance tra team e noisy neighbors (vicini rumorosi) aumentano il rischio operativo. Il modello multi-VPC-per-team o account-per-team migliora l’isolamento e i confini IAM; si consiglia di utilizzare AWS Organizations con account separati per i team e un account per i servizi condivisi (shared services) per DNS, logging e identità. Per la connettività tra VPC, il VPC peering è semplice e a bassa latenza, ma non è transitivo e diventa oneroso da gestire su larga scala. Transit Gateway (TGW) sostituisce il pattern del “transit VPC”: supporta migliaia di collegamenti (attachment), centralizza le tabelle di routing e semplifica i pattern multicast o hub-and-spoke. PrivateLink (Interface VPC Endpoint) abilita l’isolamento a livello di servizio senza esporre i servizi a Internet, un aspetto critico per i microservizi cross-account. Le trappole comuni includono l’affidarsi esclusivamente ai security group per la segmentazione (sono stateful e troppo generici per il filtraggio east-west), dimenticare il comportamento stateless delle NACL e non pianificare l’allocazione dei CIDR (le sovrapposizioni ostacolano il peering e DX). Le decisioni dipendono dal compromesso tra costi e gestibilità: TGW ha costi per ogni collegamento (attachment), ma riduce la complessità rispetto al peering; l’isolamento multi-account aumenta l’overhead della landing zone, ma riduce il blast radius. Documentare sempre il piano dei CIDR, le regole di propagazione delle route e la proprietà dei servizi condivisi per evitare deviazioni (drift).

Connettività ibrida, routing e resilienza

Le scelte di connettività ibrida dipendono da throughput, jitter, latenza e dalla coerenza degli indirizzi IP pubblici di uscita (egress). I VIF privati di AWS Direct Connect (DX) forniscono una larghezza di banda deterministica e costi di egress inferiori rispetto a una VPN su Internet per flussi di traffico elevati e costanti; utilizzare un Direct Connect Gateway per estendersi su più Regioni o collegarsi a un Transit Gateway per un routing centralizzato. La Site-to-Site VPN (IPsec gestito con BGP) viene utilizzata per una configurazione rapida o come backup resiliente per DX; configurare il BGP con ASN e priorità di route appropriati per evitare il routing asimmetrico. Le principali trappole nel routing sono la sovrapposizione dei CIDR on-premise e cloud, la propagazione errata delle route in TGW e l’assumere che il routing sia transitivo tra VPC in peering. L’MTU e la frammentazione possono interrompere il traffico VPN: testare la Path MTU e regolare l’MSS sui dispositivi. Per architetture multi-regione, considerare connessioni DX attive/attive in più location o una combinazione di DX con failover su VPN. Compromessi: i link DX dedicati costano di più ma riducono il jitter e i costi di egress; la VPN è più economica e semplice ma meno stabile a throughput elevati. Progettare per un failover prevedibile con due tunnel indipendenti, connessioni DX ridondanti in location separate e tabelle di routing esplicite in TGW per controllare la selezione del percorso e i limiti.

DNS, PrivateLink e pattern di connettività dei servizi

Il DNS è un elemento centrale nel networking ibrido e multi-account. Utilizzare le Private Hosted Zone di Route 53 per la risoluzione dei nomi all’interno di un VPC e gli endpoint inbound/outbound di Route 53 Resolver per abilitare l’inoltro condizionale (conditional forwarding) tra il DNS on-premise e quello di AWS. Questo supporta lo split-horizon DNS, in cui i nomi interni vengono risolti in indirizzi IP privati mentre i record pubblici rimangono globali. PrivateLink (interface endpoint) fornisce connettività privata, basata su ENI, a servizi AWS o partner SaaS senza instradare il traffico sulla rete Internet pubblica; questo si contrappone ai Gateway Endpoint per S3 e DynamoDB, che sono più economici e utilizzano le tabelle di routing anziché le ENI. PrivateLink evita di esporre i servizi a conflitti di CIDR del VPC e supporta l’accesso da parte di consumer cross-account tramite policy di accettazione del servizio. Le trappole più comuni includono dimenticare di associare le private hosted zone a tutti i VPC consumer, non creare le regole di Route 53 Resolver per i domini on-premise e sottostimare il consumo di indirizzi IP per ogni ENI degli endpoint. Criteri decisionali: preferire i Gateway endpoint per l’accesso ad alta velocità a S3/DynamoDB per evitare i costi del NAT; utilizzare gli Interface endpoint quando è necessario un accesso privato a endpoint API o a servizi di terze parti con requisiti di sicurezza più stringenti. Monitorare la latenza del DNS e impostare i TTL con un processo di change control per gestire il comportamento del failover.

Egress, progettazione NAT, controlli di sicurezza e pratiche operative

L’architettura di egress influisce su costi, auditability e integrazioni con terze parti. Il NAT Gateway fornisce un egress IPv4 gestito e ad alta disponibilità per le subnet private, con scalabilità automatica per AZ; le NAT Instances sono più economiche per un utilizzo a basso throughput ma richiedono manutenzione operativa e script di failover. Centralizzare l’egress tramite un VPC di egress dedicato collegato a un Transit Gateway impone IP in uscita coerenti, punti di ispezione e policy semplificate, ma introduce l’hairpin routing e potenziali colli di bottiglia della larghezza di banda. Per l’IPv6, utilizzare un Egress-Only Internet Gateway. Sostituire i bastion host SSH con AWS Systems Manager Session Manager per l’auditing e per eliminare le credenziali pubbliche in entrata; Session Manager funziona tramite l’agente SSM senza aprire le porte SSH. Per filtri avanzati e DPI, implementare AWS Network Firewall o appliance di terze parti dietro il TGW. Compromessi costo/prestazioni: i NAT Gateway sono facili da usare ma aggiungono costi per GB: utilizzare gli endpoint VPC per ridurre i costi di egress da S3 e del NAT. Le trappole operative includono la mancata attivazione dei VPC Flow Logs per il troubleshooting del traffico, il mantenimento di regole di egress troppo ampie che consentono l’esfiltrazione di dati e l’uso di SCP o policy IAM che bloccano involontariamente le operazioni del ciclo di vita; applicare il principio del privilegio minimo e registrare tutto in un account centrale per l’analisi.

Problema Pratico: Acme Financial Services — Egress Centralizzato e Prevedibile per il Whitelisting di Terze Parti

Scenario: Acme Financial Services gestisce molteplici VPC applicativi in due Regioni AWS, collegati con un Transit Gateway e con data center on-premise tramite Direct Connect e VPN. Diverse applicazioni in account separati devono chiamare un’API di un partner che accetta richieste solo da un singolo blocco CIDR pubblico.

Sfida: Fornire un percorso di egress ad alta disponibilità e auditabile con un singolo blocco CIDR pubblico prevedibile per tutti i VPC applicativi tra le Regioni, minimizzando al contempo la latenza e l’overhead operativo.

Approccio Raccomandato:

Importare un CIDR IPv4 pubblico in AWS utilizzando BYOIP (Bring Your Own IP) e allocare Elastic IP da quel CIDR da utilizzare come indirizzi di egress.
Creare un VPC di egress centralizzato in ogni Regione con NAT Gateway in più AZ; associare gli Elastic IP BYOIP a tali NAT Gateway e collegare i VPC di egress al Transit Gateway.
Aggiornare le tabelle di routing del TGW in modo che tutti i VPC applicativi instradino 0.0.0.0/0 verso l’attachment del VPC di egress, abilitare la propagazione delle rotte e il failover con health check tra le AZ; configurare il routing on-premise per preferire l’egress locale dove richiesto.
Implementare Network Firewall o un IDS gestito nel VPC di egress per il filtraggio in uscita, abilitare i VPC Flow Logs e gli allarmi CloudWatch, e utilizzare Route 53 Resolver per eventuali esigenze di forwarding DNS.

Motivazione: Centralizzare l’egress tramite TGW e NAT Gateway con uno spazio IP fornito da BYOIP offre un CIDR prevedibile per il whitelisting, preservando al contempo l’alta disponibilità e il monitoraggio centralizzato. Questo approccio bilancia la semplicità operativa, i controlli di sicurezza e il requisito del partner di avere un singolo CIDR pubblico.

← Complessità organizzativa e strategia multi-account · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →