Amazon SAA-C03: Distribuzione dei Contenuti, Edge e Ottimizzazione delle Prestazioni — 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.

Amazon CloudFront: Cos’è e perché è utile

Amazon CloudFront è una rete di distribuzione di contenuti (CDN) distribuita a livello globale e basata su oltre 600 punti di presenza (PoP). Il suo compito è terminare la connessione TLS del client nell’edge location più vicina e servire immediatamente risposte dalla cache oppure inoltrare le richieste non in cache (cache miss) verso l’origine attraverso il backbone privato di AWS. Il vantaggio in termini di prestazioni è duplice: le risposte dalla cache (cache hit) riducono il tempo di andata e ritorno (RTT) a pochi millisecondi e sgravano completamente l’origine, mentre i cache miss beneficiano comunque della terminazione TLS/TCP ottimizzata all’edge, del supporto a HTTP/2 e HTTP/3, del riutilizzo delle connessioni keep-alive verso l’origine e del transito sul backbone che evita la congestionata rete internet pubblica.

Un malinteso comune è che CloudFront acceleri solo gli asset statici. Posizionare un ALB dietro CloudFront con una policy CachingDisabled migliora comunque le prestazioni delle API dinamiche, perché l’handshake del client si completa nel PoP locale anziché attraversare internet fino alla Regione di origine. Combinando questo con un carico di lavoro misto — ad esempio /static/* servito da S3 e /api/* servito da un ALB — una singola distribuzione può gestire entrambi:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

I record alias di Route 53 puntano quindi www.example.com al d123.cloudfront.net della distribuzione — i record alias sono gratuiti e si risolvono direttamente negli indirizzi IP anycast di CloudFront.

I certificati risiedono in us-east-1

Per qualsiasi distribuzione CloudFront servita su un dominio personalizzato, il certificato TLS esposto al client in AWS Certificate Manager deve essere emesso in us-east-1 (N. Virginia), indipendentemente da dove si trovino il bucket di origine, l’ALB o gli utenti. CloudFront è un servizio globale il cui control plane è ancorato in us-east-1; le edge location recuperano il certificato da quella Regione. Richiedere un certificato ACM in eu-west-1 perché il proprio bucket S3 si trova lì è un pattern errato — la distribuzione non lo vedrà mai.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Se si termina la connessione TLS una seconda volta tra CloudFront e un’origine ALB, quel certificato rivolto verso l’origine risiede nella Regione dell’ALB. Solo il certificato per il client è vincolato a us-east-1. La stessa regola si applica ai domini personalizzati di tipo edge-optimized di API Gateway (che utilizzano internamente una distribuzione CloudFront gestita da AWS): il certificato deve essere in us-east-1. Gli endpoint regionali di API Gateway, al contrario, utilizzano un certificato della stessa Regione dell’API.

Origin Access Control per origini S3

Mettere CloudFront di fronte a un bucket S3 lasciando il bucket pubblico vanifica lo scopo: i client aggirano CloudFront accedendo direttamente all’endpoint REST di S3, eludendo WAF, restrizioni geografiche, URL firmati e i benefici della cache — e potenzialmente esponendo dati.

La soluzione moderna è l’Origin Access Control (OAC), che sostituisce la vecchia Origin Access Identity (OAI). OAC utilizza la firma SigV4, supporta SSE-KMS, funziona in ogni Regione S3 (incluse quelle lanciate dopo il 2022) e supporta richieste dinamiche. L’opzione Block Public Access rimane attiva, non sono necessarie ACL e la policy del bucket concede l’accesso in lettura solo al service principal di CloudFront, ulteriormente limitato dall’ARN della distribuzione specifica:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI funziona ancora ma dovrebbe essere considerata obsoleta — scegliere sempre OAC per i nuovi progetti.

Correttezza della cache

L’efficacia della cache dipende dagli header Cache-Control e Expires restituiti dall’origine, combinati con i TTL minimo/predefinito/massimo della policy di cache di CloudFront. Gli asset immutabili con fingerprinting dovrebbero essere messi in cache in modo aggressivo; i template HTML che li referenziano dovrebbero avere una durata breve per propagare le nuove distribuzioni; il JSON autenticato non dovrebbe essere affatto messo in cache sulla CDN condivisa:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Due trappole simmetriche sono comuni. Primo, se l’origine non emette header di cache, CloudFront ricade sul TTL predefinito della distribuzione e può mettere in cache silenziosamente risposte dinamiche per ore. Secondo, un Cache-Control: no-cache indiscriminato su asset che dovrebbero essere messi in cache forza ogni richiesta a tornare all’origine e vanifica la CDN.

La trappola più pericolosa è mettere in cache risposte personalizzate senza gli header appropriati. Se /account/dashboard restituisce HTML specifico per l’utente A ma l’origine omette no-store e la policy di cache non include un header di autenticazione o un cookie nella chiave di cache, l’edge location servirà senza problemi la pagina dell’utente A all’utente B. È necessario o contrassegnare tali risposte come private, no-store, oppure includere l’identificatore di sessione nella chiave di cache e accettare un hit ratio inferiore.

In uno scenario di ottimizzazione dei costi in cui un gruppo di Auto Scaling di istanze EC2 On-Demand serve contenuti statici, la riprogettazione corretta consiste nello spostare gli asset su S3, mettere CloudFront di fronte con OAC ed eliminare o ridurre l’ASG. Questo sposta il costo da un modello basato sul calcolo orario a uno basato sulla distribuzione per richiesta, che è ordini di grandezza più economico per carichi di lavoro statici.

URL firmati, cookie firmati e restrizione geografica

CloudFront supporta URL firmati (accesso limitato nel tempo e opzionalmente ristretto per IP a un singolo oggetto — il download di un video acquistato, un link a un PDF una tantum) e cookie firmati (accesso a più oggetti che corrispondono a un pattern di percorso — un abbonato autenticato che naviga in un catalogo). Entrambi utilizzano un gruppo di chiavi attendibile (trusted key group) la cui chiave pubblica è caricata su CloudFront; la chiave privata firma una policy che specifica la scadenza, l’intervallo di IP di origine o il pattern dell’URL.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Questo è diverso da un URL pre-firmato di S3, che aggira CloudFront e concede accesso diretto al bucket. Abbinando gli URL firmati di CloudFront con OAC, il bucket rimane privato end-to-end.

La restrizione geografica impone allow-list o block-list a livello di nazione a livello di distribuzione, prima che le richieste raggiungano la cache o l’origine. Utilizza il database GeoIP gestito da CloudFront ed è il meccanismo economico e a prova di bypass della cache per applicare embarghi legati alle licenze. Per una logica più granulare (a livello di stato, combinazioni di header), utilizzare una CloudFront Function o Lambda@Edge; per un motore di regole completo, usare WAF.

AWS Global Accelerator

Global Accelerator non è una CDN e non esegue la cache. Fornisce due indirizzi IPv4 anycast statici (o BYOIP) annunciati dalle edge location di AWS a livello globale. Le connessioni TCP o UDP dei client entrano nella backbone di AWS dall’edge più vicina e vengono instradate sulla rete privata di AWS verso l’endpoint più integro (ALB, NLB, EC2 o Elastic IP) in una o più Regioni, raggruppate in gruppi di endpoint con traffic dial e pesi.

Gli IP statici offrono tre vantaggi concreti: i client e le allowlist dei firewall non cambiano mai, anche se il backend viene riprogettato; il failover regionale si completa in pochi secondi spostando il traffico tra i gruppi di endpoint in base alle variazioni dei controlli di integrità, bypassando completamente la propagazione dei TTL del DNS; e l’handshake TCP termina all’edge, con il lungo tragitto che avviene sulla backbone di AWS.

Scegliere Global Accelerator quando:

• Il protocollo non è HTTP: UDP per gaming o VoIP, MQTT, SIP, SFTP, TCP personalizzato.
• Sono necessari IP statici per le allowlist aziendali o per app mobili che hanno indirizzi hardcoded.
• È necessario un failover regionale in meno di un minuto per implementazioni stateful active-active.
• Il carico di lavoro è dinamico e non memorizzabile nella cache, quindi una CDN offre scarso valore.

Scegliere CloudFront quando:

• Il contenuto è memorizzabile nella cache (immagini, segmenti video, HTML statico, risposte API con TTL).
• Si desidera l’edge compute tramite Lambda@Edge o CloudFront Functions.
• Sono necessari WAF, URL/cookie firmati o la crittografia a livello di campo all’edge.

Due trappole da evitare. Scegliere CloudFront per “rendere i nostri server di gioco più veloci a livello globale” è un errore perché il gaming è UDP e non memorizzabile nella cache — è necessario Global Accelerator. Al contrario, scegliere Global Accelerator per un sito web statico è costoso (tariffa oraria fissa più costo per GB) e preclude la cache — CloudFront ridurrebbe drasticamente l’egress dall’origine. Per un’API HTTP distribuita a livello globale ma in una singola Regione, dove gli utenti tollerano la latenza, un semplice routing basato sulla latenza di Route 53 potrebbe essere sufficiente e più economico di entrambi.

Policy di routing di Route 53 per il traffico globale

Route 53 sceglie a quale endpoint un client deve risolvere; CloudFront o Global Accelerator gestiscono quindi la connessione. Tre policy dominano le architetture globali.

Routing basato sulla latenza misura la latenza di rete effettiva dalla posizione del resolver a ciascuna Regione e restituisce quella più veloce. Usalo per stack identici in più Regioni quando vuoi che gli utenti siano indirizzati alla Regione che è più veloce in quel momento.

Routing di geoproximity è basato sulle coordinate anziché sulla latenza: si dichiara la posizione (o la Regione AWS) di ogni endpoint e Route 53 invia gli utenti a quello geograficamente più vicino. La sua caratteristica distintiva è un valore di bias (da -99 a +99) che espande o restringe l’area di servizio effettiva — utile per spostare gradualmente il traffico durante il lancio di una Regione o per svuotare una Regione per manutenzione. Il routing di geoproximity richiede il flusso di traffico di Route 53 (traffic policy) ed è tipicamente abbinato a un NLB o ALB regionale in ogni Regione.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Routing di failover utilizza una coppia primario/secondario legata a controlli di integrità. È un failover a livello di DNS, soggetto a TTL e alla cache del resolver, quindi è più lento del failover a livello di data plane di Global Accelerator — scegli il routing di failover per semplici configurazioni active-passive dove un minuto di propagazione DNS è tollerabile, e Global Accelerator quando hai bisogno di pochi secondi.

Queste policy possono essere combinate. Un pattern globale comune: record di latenza o geoproximity di Route 53 puntano a Global Accelerator (per TCP/UDP) o CloudFront (per HTTPS memorizzabile in cache), con record di failover basati su controlli di integrità sottostanti come rete di sicurezza. La stratificazione è intenzionale: Route 53 sceglie la Regione, Global Accelerator o CloudFront scelgono l’edge e il percorso attraverso la backbone, e un load balancer regionale sceglie il target all’interno della Regione.

Tipi di endpoint di API Gateway e domini personalizzati

API Gateway offre tre tipi di endpoint con topologie distinte:

Gli endpoint ottimizzati per l’edge avvolgono l’API in una distribuzione CloudFront gestita da AWS che non è possibile configurare direttamente. Questo è comodo per una rapida portata globale, ma limitante quando si desiderano comportamenti di cache, regole WAF o policy di richiesta all’origine personalizzate. Il pattern idiomatico per il massimo controllo è un endpoint Regionale preceduto da una distribuzione CloudFront gestita dal cliente.

Il posizionamento del certificato segue la regola di CloudFront: i domini personalizzati ottimizzati per l’edge richiedono un certificato ACM in us-east-1; gli endpoint Regionali richiedono il certificato nella stessa Regione dell’API. Le HTTP API impongono un minimo di TLS 1.2; le REST API supportano policy di sicurezza fino a TLS 1.3.

Certificati ACM: Emessi, Convalidati, Importati

ACM emette e rinnova automaticamente i certificati TLS pubblici senza costi e si integra direttamente con CloudFront, API Gateway, ALB, NLB e altri servizi AWS. La convalida può essere convalida DNS (ACM fornisce un CNAME da inserire in Route 53 o in qualsiasi altro provider DNS; finché il record persiste, ACM si rinnova automaticamente per sempre) o convalida via email (un clic manuale per ogni rinnovo, un metodo poco affidabile per l’automazione). La convalida DNS è l’opzione predefinita corretta per qualsiasi ambiente di produzione.

I certificati emessi da ACM non possono essere esportati e non possono essere utilizzati al di fuori dei servizi AWS integrati. Quando un requisito normativo o aziendale impone una specifica CA di terze parti — ad esempio, un’API REST che deve essere concatenata a un particolare emittente commerciale e imporre TLS 1.3 — non è possibile utilizzare un certificato emesso da ACM. Ottenete il certificato dalla CA richiesta e importatelo in ACM, quindi collegatelo a un dominio personalizzato regionale di API Gateway con una policy di sicurezza TLS 1.3.

La trappola con le importazioni è duplice: i certificati importati non si rinnovano automaticamente (è necessario reimportarli prima della scadenza, altrimenti l’endpoint smetterà di funzionare bruscamente) e ACM non convalida la catena al momento dell’importazione — un certificato intermedio corrotto emergerà solo al momento dell’handshake da parte dei client reali. Testate l’intera catena con un client rigoroso prima del rilascio in produzione.

S3 Transfer Acceleration vs. CloudFront

CloudFront ottimizza i download; S3 Transfer Acceleration ottimizza gli upload. Transfer Acceleration utilizza la stessa rete edge di CloudFront in senso inverso: le richieste PUT entrano dall’edge più vicino e viaggiano sulla backbone di AWS fino alla Regione del bucket di destinazione. Dà il meglio di sé quando un insieme di utenti distribuiti a livello globale carica oggetti di dimensioni considerevoli in un bucket situato in una singola Regione — ad esempio, tecnici sul campo in tutto il mondo che caricano disegni da svariati gigabyte su us-east-1.

Le due funzionalità possono coesistere sullo stesso bucket: abilitate Transfer Acceleration ed esponete una distribuzione CloudFront con OAC per i download. Per oggetti di piccole dimensioni o per client già vicini alla Regione del bucket, Transfer Acceleration aggiunge costi senza apportare benefici — utilizzate lo strumento di confronto della velocità di S3 Transfer Acceleration per effettuare misurazioni prima di adottarlo. I client devono utilizzare l’endpoint s3-accelerate affinché l’accelerazione si attivi.

AWS WAF per la Protezione di Livello 7

AWS WAF ispeziona le richieste HTTP(S) prima che raggiungano la risorsa protetta. Si collega a distribuzioni CloudFront, ALB, stage di API Gateway, API AppSync, user pool di Cognito, servizi App Runner e istanze di Verified Access. Una web ACL contiene regole che effettuano il matching su URI, header, stringhe di query, corpo (fino a 8 KB per impostazione predefinita, espandibile a 64 KB su ALB/API Gateway), set di IP e geolocalizzazione.

I componenti fondamentali più comuni sono le AWS Managed Rules: AWSManagedRulesCommonRuleSet e AWSManagedRulesKnownBadInputsRuleSet coprono i principali exploit della top 10 OWASP; AWSManagedRulesSQLiRuleSet e le istruzioni di matching per XSS gestiscono le injection. Le regole personalizzate aggiungono la corrispondenza geografica (allowlist/blocklist di paesi per la conformità), il matching su set di IP e le regole basate sulla frequenza (rate-based rules) — che contano le richieste per IP di origine in una finestra mobile di cinque minuti e bloccano una volta superata una soglia. Le regole basate sulla frequenza sono la prima linea di difesa contro gli attacchi di tipo flood HTTP e credential stuffing:

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Le regole sulla Regione sono importanti. Le web ACL per CloudFront sono globali e devono essere create in us-east-1. Le web ACL per le risorse Regionali (ALB, API Gateway, ecc.) vengono create nella stessa Regione della risorsa.

Per proteggere un sito statico su S3, non è possibile collegare WAF al bucket — S3 non è una risorsa supportata da WAF. Il pattern corretto è utilizzare CloudFront + OAC davanti al bucket, con la web ACL collegata alla distribuzione. Il fatto che il bucket sia irraggiungibile se non tramite CloudFront è ciò che rende effettivo il principio di “ispezionare tutto il traffico”.

Firewall Manager per la Governance WAF Multi-Account

La gestione di WAF un account alla volta non è scalabile. All’interno di un’Organization, un team potrebbe creare un nuovo ALB senza collegare la baseline aziendale, causando una regressione silenziosa della postura di conformità. AWS Firewall Manager risolve questo problema con policy a livello di organizzazione, applicate agli account e alle risorse inclusi nell’ambito (in-scope).

Prerequisiti: AWS Organizations con tutte le funzionalità (all-features) abilitate, un account amministratore designato per Firewall Manager e AWS Config abilitato in ogni account membro. I tipi di policy coprono AWS WAF, AWS Shield Advanced, gruppi di sicurezza (per audit e utilizzo), Network Firewall, Route 53 Resolver DNS Firewall e firewall di terze parti.

Una policy WAF può imporre un gruppo di regole “first” (valutato prima delle regole definite dall’applicazione), un gruppo di regole “last” (valutato dopo), oppure sostituire completamente la web ACL. I nuovi ALB o le nuove distribuzioni CloudFront che corrispondono all’ambito delle risorse ricevono automaticamente il set di regole aziendale, e le risorse non conformi vengono segnalate e — a seconda delle impostazioni di remediation — corrette automaticamente. Ogni volta che uno scenario menziona “più account”, “gestire centralmente” o “regole WAF coerenti in tutta l’organizzazione”, la risposta è Firewall Manager, non la gestione di WAF per singolo account.

Confronto tra Shield Standard e Shield Advanced

Presumere che WAF da solo possa fermare un attacco DDoS è un errore critico. WAF opera sulle richieste che lo raggiungono — è eccellente contro i flood a livello di applicazione, il credential stuffing e le firme di exploit noti — ma gli attacchi volumetrici su larga scala ai Livelli 3/4 (SYN flood, UDP reflection) vengono assorbiti da AWS Shield.

Shield Standard è attivo di default senza costi aggiuntivi. Difende automaticamente dagli attacchi L3/L4 più comuni e si applica a CloudFront, Route 53 e Global Accelerator, con una protezione di base per ELB, EC2 e altre risorse. Tuttavia, non fornisce visibilità specifica sull’attacco, l’intervento dello Shield Response Team o la protezione dei costi.

Shield Advanced (3.000 $ al mese per organizzazione, con un impegno di un anno) aggiunge:

Presumere che Shield Standard sia sufficiente per “attacchi DDoS su larga scala con protezione dei costi e risposta di esperti” è sbagliato, proprio perché la versione Standard non offre visibilità, protezione dei costi e accesso all’SRT. Quando l’origine è un’istanza EC2 dietro un ELB e il DNS è gestito da terze parti (quindi non è possibile usare i record alias di Route 53), il pattern raccomandato è abilitare Shield Advanced sull’ELB e posizionare CloudFront (anch’esso protetto da Shield Advanced) di fronte all’applicazione, per spostare il perimetro di mitigazione sull’edge e ridurre la superficie d’attacco che raggiunge la Regione.

La postura di sicurezza stratificata corretta è: Shield per gli attacchi volumetrici L3/L4, WAF per il filtraggio L7, CloudFront o Global Accelerator come punto di ingresso all’edge a cui entrambi i servizi si collegano, e Firewall Manager per applicare la policy su tutti gli account.

← Networking e Connettività · Tutti i domini · Database e Caching →

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

Sfoglia Amazon →