Amazon DOP-C02: Networking e Distribuzione di Contenuti — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Networking, Sicurezza e Accelerazione all’Edge

Amazon CloudFront è una CDN globale che accelera i contenuti statici e dinamici con caching all’edge e percorsi di rete ottimizzati. Una distribuzione definisce:

• Origini (Origins): S3, origini personalizzate (ALB/NLB/EC2/API Gateway) o gruppi di origini per il failover. Abilita Origin Shield per un ulteriore livello di cache intermedio (mid-tier) per ridurre il carico sull’origine.
• Comportamenti (Behaviors): routing basato su percorsi e metodi verso le origini, policy di cache e di richiesta all’origine (inoltro di header/cookie/query), policy del protocollo del visualizzatore (viewer) (HTTP→HTTPS), compressione, URL/cookie firmati e function hook (CloudFront Functions per richieste leggere del visualizzatore; Lambda@Edge per la manipolazione di richieste/risposte).
• Caching: regola i TTL tramite le policy di cache, varia le chiavi solo in base alle dimensioni necessarie e utilizza le policy di richiesta all’origine per minimizzare la frammentazione della cache. Per le API, evita di inoltrare header/cookie/query non necessari. Usa la crittografia a livello di campo (field-level encryption) dove necessario.
• Invalidamento (Invalidation): emetti invalidamenti per i percorsi modificati o utilizza chiavi oggetto versionate per aggiornamenti della cache senza downtime. Automatizza gli invalidamenti post-distribuzione per gli asset non versionati.

AWS WAF protegge le applicazioni a livello L7. Una web ACL contiene regole e gruppi di regole valutati in ordine, con un’azione predefinita. Utilizza le AWS Managed Rules per le protezioni di base (es. CommonRuleSet, WordPress, SQLi/XSS) e i gruppi di regole di partner selezionati quando necessario. Aggiungi regole personalizzate utilizzando istruzioni di corrispondenza (match statement) (set di IP, header, URI, corpo JSON, corrispondenza di etichette) e combinale con operatori logici. Le regole basate sulla frequenza (rate-based) limitano i client che superano una frequenza di richieste configurata in una finestra temporale, opzionalmente con istruzioni di riduzione dell’ambito (scope-down) per mirare a percorsi o header specifici. Associa le web ACL a distribuzioni CloudFront, Application Load Balancer, API Gateway (REST/HTTP) e AppSync. Monitora la capacità (WCU), abilita i log campionati (sampled logs) verso CloudWatch Logs o Kinesis Data Firehose e utilizza le azioni CAPTCHA/Challenge per mitigare i bot senza bloccare il traffico legittimo.

AWS Global Accelerator fornisce indirizzi IP anycast statici che fungono da front-end per gli endpoint regionali e accelera il traffico TCP/UDP sulla rete globale di AWS. Opera a livello L4/7 con routing basato sullo stato di salute (health-based) e failover rapido. Configura:

• Gruppi di endpoint (endpoint group) per Regione con health check e pesi.
• Selettori di traffico (traffic dial) per controllare la percentuale di traffico inviata a una Regione (es. 1% per un canary o 0% durante la manutenzione) indipendentemente dai pesi degli endpoint. Gli endpoint supportati includono ALB, NLB, istanze EC2 e Elastic IP. Utilizza Global Accelerator per protocolli non-HTTP, sensibili alla latenza, stateful, o quando sono richiesti IP statici e un failover deterministico. CloudFront rimane la scelta principale per il caching HTTP/S e l’esecuzione di funzioni all’edge; i due servizi sono complementari.

Punti di Ingresso per le API: Domini, Certificati e Strategia degli Endpoint

Amazon API Gateway fornisce API REST e HTTP con tre tipi di endpoint:

• Ottimizzato per l’edge (solo API REST): API Gateway crea e gestisce una distribuzione CloudFront; ottimale per client globali con terminazione TLS nelle edge location. I certificati per domini personalizzati devono trovarsi in us-east-1 (N. Virginia) tramite ACM.
• Regionale: per client nella stessa Regione o quando si desidera anteporre ad API Gateway la propria distribuzione CloudFront o Global Accelerator. I certificati per domini personalizzati devono trovarsi nella stessa Regione dell’API.
• Privato: raggiungibile solo dall’interno dei propri VPC tramite endpoint VPC di interfaccia; nessun percorso tramite internet pubblico.

I domini personalizzati unificano il routing e il TLS tra stage e API. Utilizzare i mapping dei percorsi di base per mappare i percorsi agli stage. Archiviare i certificati in ACM; scegliere RSA/ECDSA in base al supporto dei client. Per gli endpoint ottimizzati per l’edge, richiedere/importare il certificato in us-east-1. Per quelli Regionali, richiederlo/importarlo nella Regione. Applicare policy TLS che corrispondano alla propria postura di conformità. Integrare con WAF associando una web ACL direttamente alle API Regionali o proteggendo la distribuzione CloudFront antistante l’API. Per ottenere API globali a bassissima latenza con caching avanzato e normalizzazione degli header, posizionare una distribuzione CloudFront di fronte a un’API Regionale, usare il controllo dell’accesso all’origine e le richieste firmate se necessario, e ottimizzare le policy di cache e di richiesta all’origine per evitare un eccessivo ingombro della cache. Combinare con authorizer Lambda o Amazon Cognito per l’autenticazione e sfruttare i piani di throttling e di utilizzo per proteggere i backend, in aggiunta alle regole basate sulla frequenza di WAF.

Scenario di Problema Pratico

Shopify sta implementando un nuovo microservizio di checkout globale per servire i merchant in tutto il mondo. Requisiti: traffico est-ovest privato tra microservizi distribuiti su oltre 20 account, nessuna esposizione pubblica per le API interne, latenza bassa e deterministica per gli utenti finali durante il checkout, robuste protezioni L7 con limitazione adattiva della frequenza e connettività ibrida resiliente verso i motori di rischio on-premise.

Approccio passo-passo:

1. Segmentare la rete con un design hub-and-spoke basato su Transit Gateway

• Creare un account di networking centralizzato con un AWS Transit Gateway regionale. Collegare tutti i VPC dei carichi di lavoro (spoke) di ogni account tramite attachment TGW condivisi via RAM. Utilizzare più tabelle di routing TGW per imporre la segmentazione (prod vs servizi-condivisi vs dev) e propagare solo le route necessarie.
• Perché TGW: Scala il routing transitivo e semplifica la gestione delle route rispetto a un full-mesh di peering; supporta attachment ibridi.

2. Pubblicare i microservizi interni con AWS PrivateLink

• In ogni VPC producer, posizionare un NLB di fronte ai target group dei microservizi interni e creare un servizio di endpoint VPC. Nei VPC consumer, creare endpoint di interfaccia per tali servizi e abilitare il DNS privato specifico per l’endpoint.
• Perché PrivateLink: Connettività a livello di servizio, solo TCP, non transitiva e senza esposizione delle route; i producer rimangono isolati e non necessitano di permessi in ingresso nei SG per interi blocchi CIDR.

3. Stabilire una connettività ibrida ridondante con Direct Connect e VPN

• Effettuare il provisioning di due connessioni Direct Connect da 10 Gbps in location DX separate, terminate su router on-premise distinti. Creare un Direct Connect Gateway con un Transit VIF verso il TGW. Configurare BGP su entrambi i lati con ASN e policy MED/local-pref distinti. Aggiungere un attachment Site-to-Site VPN al TGW come backup, con due tunnel abilitati per BGP.
• Perché questo mix: DX fornisce larghezza di banda deterministica e jitter inferiore; BGP più il backup VPN offrono failover automatico e alta disponibilità.

4. Anteporre AWS Global Accelerator al checkout pubblico

• Creare un acceleratore con due listener (80/443 → 443). Definire gruppi di endpoint in us-east-1 e eu-west-1, ciascuno puntato verso gli ALB del servizio di checkout. Impostare i selettori di traffico (traffic dials) su 50/50 per lo stato stazionario e abilitare gli health check sugli endpoint di health degli ALB. Abilitare l’affinità del client se è richiesto il pinning della sessione.
• Perché Global Accelerator: IP statici anycast, failover regionale rapido e ottimizzazione TCP per flussi di checkout stateful a bassa latenza.

5. Proteggere all’edge con CloudFront e AWS WAF

• Posizionare CloudFront di fronte all’API Gateway Regionale (per GET idempotenti e asset statici) e direttamente di fronte agli ALB che servono contenuti dinamici che possono beneficiare della normalizzazione degli header e dell’offload TLS. Configurare le policy di cache per limitare la varianza agli header/query necessari, abilitare Origin Shield per ridurre il carico sull’origine e automatizzare le invalidazioni per gli asset non versionati.
• Associare una web ACL di AWS WAF a CloudFront con le AWS Managed Rules, un gruppo di regole personalizzato per il filtraggio della logica di business e una regola basata sulla frequenza con uno statement di scope-down sui percorsi di checkout. Abilitare il CAPTCHA per picchi sospetti e registrare i log su Kinesis Data Firehose per l’analisi.
• Perché CloudFront + WAF: Terminazione TLS globale, caching dove sicuro, controlli L7 basati sull’edge e assorbimento degli attacchi DDoS tramite AWS Shield.

6. Esporre le API con domini personalizzati e TLS robusto

• Utilizzare endpoint Regionali di API Gateway per i metodi API con carichi di scrittura intensi, protetti dietro CloudFront. Creare domini personalizzati in ACM per Regione, applicare policy TLS restrittive e mappare i percorsi di base agli stage. Per le API di amministrazione interne, implementare API Private e accedervi tramite endpoint VPC di interfaccia; associare security group con il principio del minimo privilegio.
• Perché questa suddivisione: Gli endpoint Regionali più CloudFront offrono flessibilità con controlli all’edge; le API Private mantengono le superfici interne fuori da internet.

7. Mettere in sicurezza i VPC con controlli a più livelli

• Applicare security group stateful con il principio del minimo privilegio, facendo riferimento a SG di producer/consumer dove possibile. Mantenere le NACL semplici (allow all) ad eccezione di blocchi mirati su subnet, necessari per la conformità. Abilitare i VPC Flow Logs con filtri di metrica CloudWatch per rilevare sorgenti anomale. Posizionare un NAT gateway per AZ e instradare le subnet private verso il NAT locale per evitare dipendenze cross-AZ.
• Perché controlli a più livelli: Gli SG gestiscono la maggior parte delle intenzioni con il tracciamento delle connessioni; le NACL forniscono barriere di sicurezza generiche; il NAT zonale migliora la resilienza e i costi.

Questo design fornisce connettività est-ovest privata e segmentata (Transit Gateway + PrivateLink), percorsi ibridi nord-sud resilienti (DX + VPN con BGP), un punto di ingresso pubblico accelerato e protetto a livello globale (Global Accelerator + CloudFront + WAF) e controlli operativi allineati con le best practice AWS per il routing, i gateway e il filtraggio dei VPC.

← Storage · Tutti i domini · Systems Manager →

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

Sfoglia Amazon →