Amazon SAA-C03: Networking e Connettività — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Progettazione dei VPC e Pianificazione dei CIDR

Ogni VPC inizia con un blocco CIDR, e la scelta fatta al momento della creazione ha conseguenze a valle per il peering, gli attachment dei Transit Gateway e la connettività ibrida. Il CIDR primario deve essere compreso tra /16 e /28, scelto dallo spazio RFC 1918, e non deve sovrapporsi a nessuna rete con cui si intende effettuare il peering, instradare attraverso un Transit Gateway, o raggiungere tramite Direct Connect o VPN. I CIDR sovrapposti sono la causa più comune di malfunzionamenti nelle architetture ibride, poiché AWS non può instradare tra due reti che condividono lo stesso spazio di indirizzi — il Transit Gateway accetterà l’attachment, ma la propagazione fallirà o il traffico verrà scartato silenziosamente (blackhole).

Quando un VPC esaurisce lo spazio di indirizzi, non è necessario ricostruirlo. È possibile associare fino a quattro blocchi CIDR IPv4 secondari (e intervalli aggiuntivi da un pool più ampio per un totale predefinito di cinque, estensibile tramite un aumento della quota). I blocchi secondari possono provenire dallo stesso intervallo RFC 1918 o dallo spazio di indirizzi condiviso 100.64.0.0/10, il che è utile quando lo spazio 10.0.0.0/8 è stato esaurito o quando è necessario uno spazio per il carrier-grade NAT. I CIDR secondari consentono di ritagliare nuove subnet per l’espansione — il networking dei pod di EKS, un nuovo tier — senza dover rinumerare i workload esistenti.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Un’architettura robusta riserva un /17 o /18 per la crescita futura, allinea i confini delle subnet con le Availability Zone (un /20 per AZ per tier è un pattern comune) e lascia un margine di crescita (headroom) per le ENI consumate dagli endpoint di interfaccia, dai NAT gateway e dai load balancer.

Un VPC è un costrutto regionale partizionato in subnet, ognuna legata a una singola AZ. La distinzione tra “pubblica” e “privata” è puramente una decisione di routing: una subnet pubblica ha una rotta 0.0.0.0/0 → igw-xxxx che punta a un Internet Gateway, mentre una subnet privata o non ha una rotta di default o punta 0.0.0.0/0 a un dispositivo NAT. Le istanze in una subnet pubblica necessitano anche di un IP pubblico o Elastic IP per essere raggiungibili dall’esterno; l’IGW esegue un NAT 1:1 tra l’IP privato e quello pubblico.

NAT Gateway, Istanze NAT ed Egress IPv6

Per l’accesso a internet solo in uscita (outbound-only) in IPv4 dalle subnet private, i NAT gateway sono la primitiva corretta. Un NAT gateway gestito scala automaticamente fino a 45–100 Gbps, supporta 55.000 connessioni simultanee per destinazione unica, riceve le patch da AWS ed è ad alta disponibilità all’interno della sua AZ. I NAT gateway sono fatturati su base oraria e per GB elaborato.

Le istanze NAT — EC2 autogestite con il controllo source/destination disabilitato — sono una soluzione legacy. Sono limitate dal throughput di una singola istanza, richiedono script per il failover e diventano un collo di bottiglia (bottleneck) sotto carico sostenuto. Sono appropriate solo per esigenze atipiche come il filtraggio personalizzato, e anche in quel caso un’appliance Gateway Load Balancer è solitamente preferibile.

Il pattern canonico ad alta disponibilità prevede un NAT gateway per AZ, ciascuno nella subnet pubblica di quella AZ, con una tabella di routing privata distinta per ogni AZ la cui rotta di default punta al NAT gateway locale:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Implementare un singolo NAT gateway condiviso tra più AZ è una trappola per due motivi. Primo, costituisce un single point of failure: un’interruzione dell’AZ bloccherebbe l’egress per ogni subnet privata. Secondo, ogni pacchetto proveniente da istanze in altre AZ attraversa un confine di AZ, generando costi di trasferimento dati cross-AZ (attualmente $0.01/GB per direzione) in aggiunta ai costi di elaborazione del NAT gateway. Su workload che effettuano centinaia di TB di egress, questo costo supera di gran lunga quello dei NAT gateway aggiuntivi. Una seconda errata configurazione frequente è posizionare il NAT gateway stesso in una subnet privata — in tal caso non ha un percorso verso l’IGW e non funziona.

Per l’IPv6, il NAT non è né necessario né disponibile, poiché ogni indirizzo IPv6 è instradabile a livello globale. Per consentire solo il traffico IPv6 in uscita (outbound-only) bloccando quello in entrata non richiesto, si associa un egress-only internet gateway e si instrada ::/0 verso di esso dalle subnet private. Un normale IGW è bidirezionale ed esporrebbe le istanze.

Endpoint VPC: Gateway e Interface a confronto

Gli endpoint VPC mantengono il traffico tra il tuo VPC e i servizi AWS sulla backbone di AWS, evitando completamente internet, i NAT gateway e gli internet gateway. Esistono due implementazioni fondamentalmente diverse, e confonderle è uno degli errori architetturali più comuni.

I Gateway endpoint esistono solo per Amazon S3 e DynamoDB. Sono una voce nella tabella di routing — una prefix list (ad esempio pl-63a5400a per S3 in us-east-1) che punta all’endpoint stesso. Non c’è nessuna ENI, nessuna modifica al DNS, nessun costo orario e nessun security group (l’accesso è controllato dalla tabella di routing più la policy dell’endpoint). Poiché si basano sul routing, funzionano solo per le risorse all’interno del VPC — le reti on-premise che raggiungono S3 tramite Direct Connect non possono utilizzarli.

Gli Interface endpoint (AWS PrivateLink) sono ENI con indirizzi IP privati posizionate nelle tue subnet, con un costo orario per AZ più un costo per GB. Funzionano per quasi tutti gli altri servizi — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS e centinaia di altri — così come per servizi di terze parti pubblicati come endpoint service. Gli Interface endpoint supportano il DNS privato, che sovrascrive l’hostname pubblico del servizio per risolverlo con l’IP privato dell’endpoint, in modo che SDK e CLI non necessitino di modifiche al codice. Poiché sono basati su ENI, si applicano i security group.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

La logica dei costi è importante: qualsiasi traffico che esce da una subnet privata verso un servizio AWS pubblico attraversa di default un NAT gateway a circa 0,045 $/GB. Per un carico di lavoro containerizzato che invia 1 TB al giorno su S3, la differenza tra un percorso via NAT gateway e un gateway endpoint è di migliaia di dollari al mese. Gli Interface endpoint sono convenienti quando sostituiscono il traffico in uscita (egress) via NAT su larga scala o quando la compliance vieta il routing su internet.

Trappole: associare un security group a un gateway endpoint (non hanno ENI); presumere che un gateway endpoint sia raggiungibile da on-premise (non lo è — usare un interface endpoint o il pattern ibrido EC2 → gateway endpoint S3 → percorso DX separato); disabilitare il DNS privato su un interface endpoint e aspettarsi che le chiamate SDK non modificate funzionino (contatteranno l’endpoint pubblico via internet, vanificando completamente l’endpoint); creare un gateway endpoint ma dimenticare di associare la tabella di routing della subnet privata (il traffico continua silenziosamente a usare il percorso pubblico); provare a usare un gateway endpoint per un servizio che non ne ha uno (KMS, ad esempio) — solo S3 e DynamoDB sono idonei.

Connettività tra VPC: Peering e Transit Gateway a confronto

Il VPC peering è una connessione uno-a-uno, non transitiva, di Livello 3 tra due VPC, nello stesso account o in account diversi, nella stessa Regione o in Regioni diverse. Il traffico attraversa la backbone di AWS, non ci sono colli di bottiglia sulla larghezza di banda e non ci sono costi orari — si paga solo per il trasferimento dati tra AZ (cross-AZ) o tra Regioni (inter-Region). Due proprietà limitano il peering: (1) è non transitivo — se A è in peering con B e B è in peering con C, A non può raggiungere C attraverso B; e (2) gli intervalli CIDR non devono sovrapporsi. Connettere N VPC in una topologia full-mesh richiede N(N-1)/2 peering con modifiche alle tabelle di routing in entrambe le direzioni di ciascuno; con 30 VPC, si tratta di 435 peering. Aspettarsi che il peering scali a centinaia di VPC è una trappola.

Il Transit Gateway (TGW) è un router cloud regionale. Ogni VPC, VPN o Direct Connect gateway è un attachment, e le tabelle di routing del TGW controllano quale attachment può raggiungere quale prefisso. Questo converte una topologia mesh O(n²) in una topologia con O(n) attachment e abilita architetture hub-and-spoke in cui un VPC di sicurezza ospita firewall che ispezionano tutto il traffico tra VPC. Il TGW supporta il routing transitivo, termina nativamente le associazioni VPN e Direct Connect gateway, e può essere condiviso tra account di un’organizzazione AWS tramite Resource Access Manager, in modo che i team di networking centrali controllino il routing mentre gli account dei carichi di lavoro possiedono i VPC. Il TGW aggiunge un costo orario per attachment e circa 0,02 $/GB elaborati.

Per la connettività tra Regioni (inter-Region), il TGW peering connette TGW in Regioni diverse sulla backbone globale di AWS con traffico crittografato — un TGW per Regione, connessi in peering con un design a mesh o hub. Questo evita il problema N-quadro tra Regioni che il VPC peering inter-Region reintroduce.

L’igiene delle tabelle di routing è il killer silenzioso in questo contesto. Creare una connessione di peering o un attachment TGW non fa nulla finché non vengono aggiunte rotte CIDR esplicite nelle tabelle di routing delle subnet di entrambi i VPC che puntano al target pcx- o tgw-, e i security group non permettono il traffico. I fallimenti di connettività silenziosi sono quasi sempre riconducibili a una rotta mancante o a un deny implicito in un security group che fa riferimento a un CIDR di origine errato.

Connettività Ibrida: Site-to-Site VPN vs. Direct Connect

La scelta tra Site-to-Site VPN e Direct Connect è un compromesso tra velocità di implementazione e crittografia integrata da un lato, e latenza bassa e costante, larghezza di banda dedicata e throughput prevedibile dall’altro.

Site-to-Site VPN stabilisce due tunnel IPsec tra un customer gateway (router on-premise) e un Virtual Private Gateway o un Transit Gateway. Ogni tunnel ha un limite di circa 1,25 Gbps. Il traffico è crittografato a livello di rete, soddisfacendo i requisiti di crittografia a livello di rete e di sessione se combinato con TLS. Transita sulla rete internet pubblica, quindi la latenza e il jitter sono variabili, ma è disponibile in pochi minuti e costa pochi centesimi all’ora. Utilizzala quando la connettività è necessaria immediatamente, quando la larghezza di banda è modesta o come percorso di backup.

Direct Connect (DX) fornisce una connessione in fibra dedicata (1, 10 o 100 Gbps) da un router on-premise a una location AWS Direct Connect. Bypassa la rete internet pubblica, garantendo una latenza costante e un throughput più elevato. I prezzi di egress di DX sono sostanzialmente inferiori a quelli di internet, un fattore importante quando si spostano centinaia di gigabyte al giorno. Il provisioning richiede settimane — cross-connect, LOA, configurazione BGP.

Ci sono due trappole principali da evitare. Primo, Direct Connect da solo non crittografa il traffico. Un circuito privato non è un canale protetto crittograficamente. Per soddisfare un requisito di crittografia su DX, è necessario aggiungere un livello Site-to-Site VPN o utilizzare MACsec per la crittografia di Livello 2 su porte dedicate supportate. Secondo, una connessione DX di base non instrada di per sé il traffico verso più VPC. Una VIF privata si connette a un singolo Virtual Private Gateway collegato a un singolo VPC. Per raggiungere molti VPC — specialmente tra account e Regioni diverse — si utilizza un Direct Connect Gateway associato a un Transit Gateway tramite una transit VIF, e si collega ogni VPC al TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Il pattern di produzione canonico utilizza due connessioni DX in due location DX diverse che terminano su router cliente separati, con Site-to-Site VPN come failover BGP automatico — il BGP AS-path prepending o il MED indirizzano il traffico verso DX finché è attivo; se fallisce, BGP ritira le rotte DX e la VPN prende il sopravvento.

Load Balancer: ALB, NLB e GWLB

ALB è di Livello 7 e comprende la semantica HTTP — routing basato su host e path, WebSockets, reindirizzamenti, sessioni sticky basate su cookie. È lo strumento sbagliato per tutto ciò che non è HTTP: MQTT, TCP raw, syslog su UDP, SMTP. ALB utilizza un indirizzamento basato su DNS con IP che cambiano nel tempo; non gli si possono assegnare Elastic IP. Quando i client devono inserire in whitelist gli IP di destinazione, un ALB da solo non è adatto — si deve usare un NLB con EIP, o anteporre all’ALB i due IP statici anycast di Global Accelerator. Risolvere il DNS dell'ALB una sola volta e fissare gli IP nelle regole del firewall è una trappola: AWS li cambia senza preavviso.

NLB è di Livello 4 e scala fino a milioni di flussi al secondo. Conserva l’IP di origine reale del client di default (i target vedono il client effettivo), supporta l’assegnazione di un Elastic IP statico per ogni AZ e gestisce carichi di lavoro TCP/UDP ad alto throughput. Storicamente, NLB non supportava i security group sul load balancer stesso — i CIDR dei client dovevano essere permessi direttamente nel SG del target. AWS ha aggiunto i security group opzionali per NLB nel 2023, ma molti design assumono ancora il comportamento classico.

Il pattern canonico per l’esposizione pubblica è:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Fare riferimento al security group dell’ALB come origine nel backend — piuttosto che a un CIDR — è il pattern di least-privilege e copre automaticamente il traffico degli health check, che origina dagli ENI dell’ALB. L’ALB stesso si trova in subnet pubbliche in almeno due AZ (con rotte verso l’IGW); i target si trovano in subnet private. Posizionare un ALB internet-facing in una subnet privata è una classica configurazione errata — la registrazione del target ha successo ma i client non possono raggiungerlo.

Gateway Load Balancer (GWLB) è progettato appositamente per l’inserimento trasparente di appliance virtuali di terze parti (firewall, IDS/IPS, DPI). Opera a Livello 3, inoltrando tutti i protocolli IP utilizzando l’incapsulamento GENEVE su UDP 6081. Il traffico raggiunge il GWLB attraverso un GWLB endpoint (GWLBe) — un endpoint di interfaccia che si trova in una subnet e appare nelle tabelle di routing come target:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

L’endpoint inoltra i pacchetti tramite PrivateLink al GWLB, che li distribuisce sulla flotta di appliance utilizzando la flow stickiness, in modo che entrambe le direzioni di un flusso colpiscano la stessa appliance. In un design di ispezione hub-and-spoke, i VPC spoke si collegano a un TGW le cui tabelle di routing forzano il traffico est-ovest a passare attraverso il VPC di ispezione (che contiene il GWLB e le appliance) prima di raggiungere i VPC di destinazione. L’ispezione del traffico in ingresso (ingress) utilizza tabelle di routing di edge che reindirizzano il traffico dall’IGW al web-tier facendolo passare prima attraverso il GWLBe:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Questa è la risposta corretta per l’ispezione centralizzata e cross-account — soluzioni fai-da-te con EC2, hack personalizzati delle tabelle di routing e script di failover non fanno che reinventare ciò che GWLB fornisce nativamente.

PrivateLink per Servizi Consumer-to-Provider

Oltre a gestire gli endpoint di interfaccia per i servizi AWS, PrivateLink abilita la connettività privata a servizi pubblicati da terze parti o da altri account AWS. Il provider posiziona il proprio servizio dietro un NLB e crea un servizio di endpoint VPC. I consumer creano endpoint di interfaccia nei propri VPC che puntano a tale servizio.

La regola critica di direzionalità è: la connessione è sempre iniziata dal consumer verso il provider. Il provider non può iniziare connessioni verso il VPC del consumer. Il traffico non transita mai su internet, è raggiungibile solo il servizio di destinazione specifico (non l’intero VPC del provider, come avviene con il peering) e non sorgono problemi di sovrapposizione dei CIDR, poiché su ciascun lato vengono esposti solo gli IP degli endpoint. Questa è la soluzione canonica per un pattern di accesso a SaaS o a database di fornitori in cui il VPC del consumer non ha IGW, né VPN, né Direct Connect. Il VPC peering espone interi intervalli CIDR e richiede IP non sovrapposti; un collegamento TGW instrada in modo ampio; un’API pubblica su internet non è privata.

Global Accelerator e Route 53

AWS Global Accelerator assegna due indirizzi IPv4 anycast statici annunciati dalle edge location di AWS in tutto il mondo. Il traffico dei client entra nella edge location più vicina e viaggia sulla backbone di AWS fino all’endpoint regionale sano più prossimo (ALB, NLB, EIP o EC2). Questo risolve due problemi contemporaneamente: avere IP statici di fronte agli ALB (risolvendo il problema del whitelisting) e ridurre jitter e latenza per gli utenti distribuiti a livello globale, bypassando la rete internet pubblica. Accelera il traffico TCP/UDP non memorizzabile nella cache verso le origini dove CloudFront (che memorizza i contenuti nella cache) non è applicabile.

Route 53 risolve un problema diverso: l’indirizzamento del traffico a livello DNS. Global Accelerator agisce sul piano dati (data plane) stesso; Route 53 influisce solo sulla risoluzione DNS, dopodiché la connessione TCP si dirige ovunque si trovi l’IP risolto. I due servizi sono spesso combinati: un alias di Route 53 punta a un Global Accelerator che si trova di fronte ad ALB regionali.

Policy di routing di Route 53:

Latenza e geolocalizzazione vengono spesso confuse: la latenza minimizza l’RTT percepito dall’utente; la geolocalizzazione impone la residenza dei dati indipendentemente dalla latenza. Il failover multi-regionale richiede health check sul primario. I record Alias sono specifici di AWS, si risolvono direttamente in endpoint ALB, NLB, CloudFront, siti web S3 e API Gateway senza costi per le query e, a differenza dei CNAME, funzionano anche allo zone apex.

Route 53 Resolver risponde alle query DNS all’interno di un VPC tramite l’indirizzo .2 (base del CIDR del VPC + 2). Per il DNS ibrido, gli endpoint in entrata (inbound) consentono ai resolver on-premise di interrogare le zone ospitate private in AWS; gli endpoint in uscita (outbound) con regole di inoltro permettono alle risorse del VPC di risolvere i nomi on-premise. Senza di essi, le istanze EC2 non possono risolvere corp.internal e i server on-premise non possono risolvere db.prod.internal — un’interruzione subdola che emerge solo quando le applicazioni iniziano a effettuare ricerche tra ambienti diversi. Gli endpoint di interfaccia richiedono l’opzione Abilita DNS privato (Enable Private DNS) affinché le chiamate SDK raggiungano l’ENI dell’endpoint; senza di essa, le chiamate raggiungono comunque l’endpoint pubblico tramite internet, vanificandone lo scopo.

Security Group, NACL e Principio del Minimo Privilegio

I security group sono stateful — il traffico di ritorno è automaticamente permesso — e agiscono a livello di ENI. Le NACL sono stateless e agiscono al confine della sottorete. Qualsiasi regola TCP in una NACL richiede una regola esplicita sia in entrata (inbound) che in uscita (outbound); poiché i client scelgono una porta di origine dall’intervallo effimero, la regola per il traffico di ritorno deve consentire le porte 1024–65535 (Linux usa di default 32768–60999; l’intervallo più ampio copre Windows e altri stack). Dimenticare la regola per l’intervallo effimero di ritorno è una causa classica di connessioni che completano il SYN ma si bloccano in attesa della risposta.

Per applicare il principio del minimo privilegio tra i vari livelli (tier), le regole dei security group dovrebbero fare riferimento ad altri ID di security group, non a intervalli CIDR. Questo approccio scala con Auto Scaling ed evita di usare fragili whitelist di IP:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

Le NACL sono un controllo grossolano del raggio d’impatto (blast radius), non un sostituto dei security group. Restringere le NACL “per una difesa in profondità” senza adeguare le modifiche ai security group comunemente interrompe i flussi iniziati in uscita, come gli aggiornamenti yum/apt tramite un NAT gateway, perché il traffico di ritorno stateless viene scartato silenziosamente. Le tabelle di routing determinano in ultima analisi la raggiungibilità: anche un security group permissivo non può consegnare traffico se nella tabella di routing manca una voce per la destinazione e, viceversa, un gateway endpoint è efficace solo quando la rotta della prefix list di S3 è effettivamente installata nelle tabelle di routing delle sottoreti che ospitano il workload.

Riferimento per le decisioni

← Trasferimento e Migrazione dei Dati · Tutti i domini · Distribuzione dei Contenuti →

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

Sfoglia Amazon →