Amazon SOA-C02: Reti e distribuzione di contenuti — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

La sezione Reti e distribuzione di contenuti copre le basi del VPC, le connessioni ibride, il DNS e il routing globale, il caching perimetrale con CloudFront e il ciclo di vita dei certificati TLS — tutti elementi critici per la disponibilità, la sicurezza e le prestazioni. La padronanza operativa garantisce che i carichi di lavoro siano raggiungibili, resilienti ai guasti e sicuri sia on-premise che nel cloud. Questa sezione si concentra su schemi di configurazione pratici, esempi di CLI/console e criteri decisionali che utilizzerai come amministratore SysOps a supporto dei sistemi di produzione.

Progettazione di VPC, sottoreti, routing e connettività

Progetta lo spazio CIDR del VPC tenendo conto della crescita futura: alloca un VPC sufficientemente grande (ad esempio /16 o /20 a seconda della scala) e suddividilo in sottoreti locali per AZ (10.0.0.0/24, 10.0.1.0/24 per AZ) per evitare dipendenze cross-AZ. Crea tabelle di routing esplicite per tipo di sottorete: le sottoreti pubbliche utilizzano una rotta verso l’Internet Gateway (IGW) — es.,

undefined

; le sottoreti private instradano 0.0.0.0/0 verso un NAT Gateway nella stessa AZ per costi di egress prevedibili e latenza inferiore.

Comprendi il comportamento del NAT e le sfumature del routing: il NAT Gateway/Instance esegue il source NAT per le connessioni IPv4 in uscita e richiede che il traffico di ritorno segua la tabella di routing della sottorete per tornare attraverso il NAT. Per IPv6, utilizza un egress-only internet gateway. Usa la AWS CLI per creare un NAT Gateway e associare un Elastic IP:

undefined

. Usa la propagazione delle rotte con gli attachment di Transit Gateway o VPN per gestire automaticamente le rotte dinamiche.

Il confronto tra security group e NACL e il flusso del traffico devono essere gestiti deliberatamente: i security group sono stateful (se consenti il traffico in entrata, quello di ritorno è automaticamente permesso) e sono collegati alle ENI; le NACL sono stateless e valutate a livello di sottorete con regole ordinate, quindi devi consentire esplicitamente sia le porte effimere in entrata che in uscita. Comandi di esempio:

undefined

;

undefined

. Criteri decisionali: usa i security group per il controllo degli accessi a livello di istanza e le NACL per il perimetro, il filtraggio ad alte prestazioni e l’isolamento cross-account.

VPN, Direct Connect e reti ibride

Seleziona la connettività in base alle esigenze di larghezza di banda, latenza e resilienza. La Site-to-Site VPN fornisce tunnel IPsec crittografati su Internet ed è rapida da implementare usando

undefined

. Configura due tunnel VPN per l’alta disponibilità (HA); usa BGP per il routing dinamico e la propagazione delle rotte tramite Virtual Private Gateway o Transit Gateway. Usa AWS Managed VPN per un’implementazione rapida e come failover per Direct Connect.

Direct Connect offre connettività privata, a banda larga e a bassa latenza. Effettua il provisioning di una connessione (o LAG) con la console Direct Connect e crea interfacce virtuali private (VIF) verso i VPC tramite un Direct Connect Gateway per l’accesso multi-regionale. Usa BGP con l’ASN appropriato e preferisci una soluzione ibrida DX + VPN: annuncia i prefissi critici su DX con la VPN come backup automatico. Criteri decisionali:

Usa la VPN per esigenze a breve termine, con larghezza di banda medio-bassa, o come backup crittografato basato su Internet.
Usa Direct Connect quando un throughput elevato e sostenuto e una latenza prevedibile giustificano i costi della porta e del cross-connect.
Usa Transit Gateway per centralizzare molte connessioni VPC e on-premise se hai bisogno di una scalabilità hub-and-spoke e di una gestione semplificata delle rotte.

Checklist operativa: conferma che le sessioni BGP siano attive, assicurati della propagazione delle tabelle di routing (per TGW usa

undefined

) e testa il failover disattivando un tunnel o modificando i percorsi BGP.

Route 53 DNS, health check e policy di routing

Route 53 è sia un DNS autoritativo che un piano di controllo per il routing. Implementa health check per gli endpoint (HTTP/HTTPS/TCP) e abbinali a record di tipo failover o weighted. Esempio: crea un record di failover con tipi di record primario/secondario nella console di Route 53 o usa

undefined

con una policy di routing Failover e un HealthCheckId. Usa la regolazione del TTL in base allo SLA di failover previsto — TTL basso (30-60s) per il failover attivo, più lungo (300s+) per endpoint stabili.

Scegli la policy di routing in base all’obiettivo:

Simple: restituisce un singolo valore; da usare per endpoint non critici o singoli.
Failover: primario/secondario con health check per la gestione dei disastri.
Weighted: spostamento graduale del traffico per implementazioni blue/green o canary.
Latency-based: instrada gli utenti verso la regione con la latenza più bassa.
Geolocation/geoproximity: per rispettare la residenza dei dati o fornire contenuti mirati.

Punti chiave per le decisioni:

Per applicazioni globali con regioni active-active ed ELB: usa record Alias che puntano ad ALB/ELB per evitare costi aggiuntivi e sfruttare l’health degli endpoint.
Per migrazioni pianificate o traffic shaping: usa record Weighted e modifica i pesi in modo incrementale tramite CLI (

undefined

Per un ripristino rapido da guasti al data center: usa il routing Failover con TTL bassi e health check robusti.

CloudFront CDN, strategie di caching e invalidazione

CloudFront accelera la distribuzione dei contenuti tramite la cache nelle edge location e riducendo il carico sull’origine. Configura i Cache Behavior per ogni pattern di percorso; controlla la cache usando gli header Cache-Control ed Expires dall’origine o sovrascrivili tramite i Forwarded Values e i TTL minimo/massimo nelle impostazioni della distribuzione. Usa Origin Shield per ridurre il carico sull’origine proveniente da più edge location.

Strategie di cache chiave:

Asset statici: TTL lunghi, usa il fingerprinting (versioning degli oggetti) in modo che l’invalidazione non sia necessaria.
Contenuti dinamici: imposta Cache-Control: no-cache o un TTL minimo e usa Lambda@Edge o una Cache Policy per mettere in cache selettivamente in base a header/cookie.
API: considera una cache regionale (API Gateway + CloudFront) con TTL brevi.

Pattern di invalidazione e gestione:

undefined

per una rimozione immediata; nota che l’invalidazione ha un costo per pattern di grandi dimensioni.

Preferisci il versioning degli oggetti (modificando il nome del file o usando una versione nella query string) per evitare invalidazioni frequenti.
Assicura la corretta configurazione dell’origine: un’origine S3 dovrebbe essere protetta con Origin Access Control (OAC) o OAI in modo che solo CloudFront possa leggere; per un’origine ALB, assicurati che gli health check e le impostazioni di stickiness siano allineate con il comportamento di CloudFront.

Certificati TLS, ACM e ciclo di vita dei certificati

Usa AWS Certificate Manager (ACM) per fornire i certificati per ELB, CloudFront e API Gateway. Richiedi certificati pubblici con

undefined

per la validazione DNS, che permette il rinnovo automatico. Importante: CloudFront richiede certificati ACM nella regione us-east-1; i servizi regionali (ALB, API Gateway regional) richiedono certificati nella regione di destinazione.

Pattern di validazione e rotazione:

La validazione DNS automatizza il rinnovo ed è il metodo preferito per la produzione; crea i record CNAME in Route 53 tramite la console o con

undefined

Per certificati manuali o importati, usa

undefined

e monitora la scadenza con

undefined

Ruota i certificati distribuendo il nuovo certificato accanto a quello vecchio (aggiungendolo all’ALB o alla distribuzione CloudFront), verifica il traffico, e poi rimuovi il vecchio certificato prima della sua scadenza.

Criteri decisionali: usa ACM per i certificati pubblici associati a endpoint gestiti da AWS. Usa certificati importati solo quando sono richieste CA private o trust anchor esterni.

Errori Comuni e Criteri Decisionali

Regole errate nei security group o nelle route table che causano istanze non raggiungibili — verifica le regole in entrata e in uscita dei security group e le voci 0.0.0.0/0 nella route table; ricorda che i security group sono stateful, mentre i NACL sono stateless e richiedono autorizzazioni esplicite per le porte effimere.
TTL DNS mal configurati che causano routing obsoleto dopo un failover — imposta i TTL in base alle finestre di failover (TTL brevi per failover attivi) e testa il failover con gli health check abilitati.
Trascurare la configurazione dell’origine di CloudFront e OAC/OAI — proteggi le origini S3 in modo che i bucket non siano pubblici e assicurati che l’identità dell’origine di CloudFront possa leggere gli oggetti.
Affidarsi a Direct Connect senza un backup VPN — progetta sempre un’architettura ibrida DX + VPN per la resilienza e valida il comportamento di failover BGP.
Posizionare i NAT Gateway in una sola AZ — crea NAT gateway per ogni AZ per evitare percorsi di dati cross-AZ e fallimenti dell’egress in una singola AZ.
Dimenticare le regole di regione di ACM per CloudFront — richiedi i certificati pubblici in us-east-1 per CloudFront; i servizi federati o regionali richiedono certificati regionali.

Problema Pratico: Scenario d’Uso

AcmePayments gestisce un’app di pagamenti globale con ALB regionali, un sito statico basato su S3 e un datacenter on-premise che richiede collegamenti ad alta velocità per la liquidazione (settlement). Hanno bisogno di latenza prevedibile, distribuzione sicura per i contenuti statici e un failover rapido in caso di degrado di una regione.

Progetta VPC con subnet pubbliche e private locali per ogni AZ; distribuisci NAT Gateway per ogni AZ e configura le route table in modo che le subnet private utilizzino il NAT locale per l’egress.
Effettua il provisioning di un Direct Connect con una VIF privata verso la Regione più vicina e configura una VPN Site-to-Site ridondante come failover automatico usando BGP con un’adeguata propagazione delle route verso un Transit Gateway.
Usa il routing basato sulla latenza di Route 53 per gli ALB con health check e TTL bassi per gli endpoint critici; implementa record ponderati per test di failover graduali.
Distribuisci CloudFront per il sito statico con un’origine S3 protetta da Origin Access Control e imposta TTL lunghi più il versioning degli oggetti per evitare l’invalidazione; usa Lambda@Edge per la manipolazione degli header richiesta.
Richiedi certificati ACM tramite validazione DNS (in us-east-1 per CloudFront) e distribuisci i nuovi certificati accanto a quelli esistenti per una rotazione blue/green, quindi rimuovi i vecchi prima della scadenza.

Logica: questi passaggi isolano i domini di errore, forniscono un routing globale a bassa latenza, proteggono e mettono in cache gli asset statici sull’edge e assicurano che il ciclo di vita dei certificati sia automatizzato e non dirompente — allineandosi con le best practice di disponibilità operativa e sicurezza.

← Sicurezza · Tutti i domini · Archiviazione e gestione dei dati →

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