Amazon ANS-C01: Distribuzione di Contenuti e Networking Edge — Guida allo studio

Fa parte della AWS Advanced Networking Specialty ANS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Concetti fondamentali

La distribuzione di contenuti (content delivery) e il networking perimetrale (edge networking) separano due responsabilità correlate: trasportare il traffico dei client con bassa latenza e agire come un livello di cache/calcolo distribuito vicino agli utenti finali. CloudFront è una CDN HTTP(S) e una piattaforma di edge computing che memorizza nella cache le risposte HTTP, termina la connessione TLS all’edge e può eseguire codice nelle edge location utilizzando Lambda@Edge (runtime Lambda completo replicato nelle region) o CloudFront Functions per JavaScript leggero a livello di richiesta/risposta del visualizzatore (viewer). Il comportamento di CloudFront è guidato da oggetti di configurazione della distribuzione creati con

undefined

e ottimizzati tramite oggetti

undefined

e

undefined

. I campi della policy di cache come

undefined

,

undefined

e

undefined

e l’insieme di intestazioni, cookie e stringhe di query inclusi nella chiave di cache determinano il rapporto di riscontri in cache (cache hit ratio) e il carico sull’origine. I controlli sull’origine includono S3 OAC/OAI per origini S3 private (

undefined

) e URL firmati o cookie firmati (

undefined

,

undefined

e il processo di firma degli URL) per proteggere i contenuti privati.

Global Accelerator e Anycast operano al di sotto del livello HTTP. Global Accelerator annuncia due indirizzi IP anycast statici dalla rete edge di AWS e instrada i flussi TCP/UDP verso endpoint regionali sani (Network Load Balancer, Application Load Balancer, istanze EC2 o IP elastici). Poiché Global Accelerator è di livello L3/L4, preserva la crittografia TLS end-to-end se configurato per il pass-through TCP e migliora l’instradamento globale utilizzando la backbone interna di AWS per l’“ultimo miglio” verso gli endpoint regionali. Per protocolli non HTTP o quando è necessario preservare una vera crittografia end-to-end e il mutual TLS (mTLS) tra client e backend, un percorso di pass-through TCP che utilizza Global Accelerator davanti a un Network Load Balancer (NLB) è il pattern canonico: gli NLB operano a livello L4, scalano fino a milioni di connessioni e possono registrare target IP per pod o nodi in Amazon EKS.

Le funzioni Lambda@Edge sono associate ai comportamenti (behavior) di CloudFront e devono essere distribuite (

undefined

con

undefined

) e associate nelle

undefined

della distribuzione per i trigger

undefined

,

undefined

,

undefined

e

undefined

. Poiché Lambda@Edge si replica in più regioni edge, le versioni e la semantica di pubblicazione sono importanti; utilizzare oggetti Lambda versionati e gestire attentamente le distribuzioni per evitare comportamenti incoerenti durante gli aggiornamenti.

Servizi e configurazioni chiave

La configurazione di una distribuzione CloudFront si basa su tre oggetti strettamente accoppiati: la distribuzione stessa (

undefined

/

undefined

), gli oggetti

undefined

che determinano la chiave di cache e i TTL (

undefined

), e gli oggetti

undefined

che determinano quali intestazioni/cookie/stringhe di query vengono inviati all’origine (

undefined

). Per contenuti S3 privati, utilizzare

undefined

o la legacy origin access identity, e proteggere ulteriormente gli accessi con URL firmati / cookie firmati utilizzando

undefined

e

undefined

; l’SDK o le utility

undefined

generano l’URL firmato o il documento di policy e la firma RSA. Le operazioni di invalidamento vengono eseguite con

undefined

per eliminare selettivamente gli oggetti memorizzati nella cache.

La configurazione di Global Accelerator viene creata tramite le chiamate API

undefined

,

undefined

e

undefined

. Il listener può essere

undefined

per gRPC o qualsiasi altra porta TCP e inoltrerà i flussi a gruppi di endpoint che puntano a un NLB o ALB regionale. Quando si utilizza Global Accelerator per il pass-through TCP al fine di preservare TLS end-to-end e mTLS, abbinarlo a un Network Load Balancer che abbia listener TCP sulla porta 443 e gruppi di target che registrano IP di pod (

undefined

) o porte dei nodi (node port). In Kubernetes EKS, questo si ottiene tipicamente creando un

undefined

con annotazioni come

undefined

e

undefined

, o utilizzando l’AWS Load Balancer Controller per creare un NLB con

undefined

. Preservare l’IP di origine del client per il logging impostando

undefined

sul Service o utilizzando il passthrough dell’NLB, che mantiene l’IP di origine originale.

L’applicazione delle regole a livello di rete tra Global Accelerator e gli endpoint regionali utilizza le prefix list gestite da AWS per ridurre l’onere amministrativo. La chiamata AWS CLI

undefined

elenca le prefix list gestite; quella denominata

undefined

può essere referenziata nelle regole dei security group (

undefined

con

undefined

) per consentire solo il traffico proveniente dall’accelerator verso un ALB/NLB. Laddove un ALB termina la connessione TLS, utilizzare le intestazioni

undefined

per il logging dell’IP del client; quando si utilizza il passthrough dell’NLB con Global Accelerator, gli IP dei client vengono preservati nativamente e i backend devono gestire la terminazione TLS/mTLS.

Pattern di progettazione e trade-off

Quando il requisito è la cache dei contenuti, l’edge compute e risposte HTTP a bassa latenza, CloudFront è lo strumento giusto. CloudFront dovrebbe terminare il TLS all’edge quando la confidenzialità dell’origine non è richiesta; utilizzare CachePolicy e OriginRequestPolicy per minimizzare le richieste all’origine escludendo header e cookie dalla chiave di cache dove è sicuro farlo. Per la personalizzazione dinamica che beneficia comunque della cache, utilizzare la normalizzazione della chiave di cache (variando su un set minimo di header o cookie firmati) e progettare l’invalidazione della cache tramite chiavi di oggetto versionate piuttosto che con chiamate frequenti a CreateInvalidation.

Per i protocolli che richiedono TLS end-to-end, flussi HTTP/2 e gRPC che non devono essere decifrati fino al backend (per mTLS), posizionare un percorso TCP/L4 davanti utilizzando Global Accelerator + NLB con TLS passthrough. Il trade-off è la perdita delle capacità di caching HTTP e di edge compute di CloudFront; tuttavia, Global Accelerator fornisce indirizzi IP statici anycast, routing migliorato e failover regionale. ALB supporta HTTP/2 e gRPC quando l’ALB termina il TLS, il che abilita il routing a livello di applicazione (basato su host/percorso) e l’integrazione con WAF, ma la terminazione sull’ALB interrompe l’mTLS end-to-end e sposta la gestione dei certificati sul load balancer. Per un numero massiccio di connessioni concorrenti, gli NLB scalano meglio a L4 — gli NLB sono ottimizzati per la velocità di connessione e preservano l’IP di origine, mentre gli ALB sono progettati per il routing a livello HTTP e funzionalità come le regole del listener per il routing a livello di host/percorso e l’integrazione con Cognito/OIDC.

I controlli di sicurezza e i pattern di isolamento regionale richiedono un’attenta selezione tra VPC peering condiviso, Transit Gateway, PrivateLink e endpoint di Load Balancer. PrivateLink fornisce controlli di accesso granulari a livello di servizio e scala bene per molti consumatori, poiché ogni consumatore crea un endpoint di interfaccia nel proprio VPC. Transit Gateway è appropriato per la centralizzazione ad alta larghezza di banda ma manca dei controlli granulari per servizio e della visibilità a livello di SNI/host che un endpoint PrivateLink fornisce. La progettazione deve considerare i limiti di routing, i permessi cross-account e la capacità di applicare i security group al confine del servizio.

Errori comuni e criteri decisionali

Un errore frequente è mescolare in modo errato i controlli della cache: lasciare che gli header Cache-Control impostati dall’origine guidino la cache all’edge mentre si applicano anche le policy di cache di CloudFront può creare TTL inaspettati; preferire oggetti CachePolicy espliciti e non dipendere unicamente dagli header dell’origine, a meno che non sia una scelta deliberata. Un altro errore comune è selezionare un ALB quando sono richiesti TLS end-to-end o milioni di connessioni TCP simultanee; il TLS terminato sull’ALB impedisce l’mTLS e può diventare il collo di bottiglia per una concorrenza di connessioni molto elevata. Le configurazioni di sicurezza che tentano di limitare l’accesso a un ALB esposto su Internet spesso dimenticano di bloccare l’accesso utilizzando la prefix list di Global Accelerator o una regola WAF; senza regole di allow esplicite, l’ALB rimarrà raggiungibile tramite il suo DNS pubblico. Infine, le implementazioni di Lambda@Edge che non utilizzano funzioni Lambda versionate possono causare un comportamento incoerente durante i rollout, poiché l’associazione nella distribuzione è legata a una specifica versione pubblicata.

Problema Pratico: Scenario d’Uso

Azienda: AcmeTelemetrics — sfida: una flotta globale di distributori automatici IoT utilizza gRPC su TCP:443 verso un backend in us-east-1 in esecuzione su Amazon EKS; il requisito è avere TLS reciproco (mTLS) end-to-end in modo che il traffico non venga mai decifrato in transito, supportare migliaia di connessioni concorrenti e avere indirizzi IP statici programmati nelle macchine.

Approccio:

  1. Creare un Global Accelerator (aws globalaccelerator create-accelerator) con due indirizzi IP statici anycast e un listener TCP sulla porta 443 (create-listener). Configurare un gruppo di endpoint che punti a un Network Load Balancer regionale in us-east-1 (create-endpoint-group).
  2. Effettuare il provisioning di un NLB in us-east-1 con un listener TCP su 443 e un target group di tipo ip. In Kubernetes, creare un Service di tipo LoadBalancer con le annotazioni service.beta.kubernetes.io/aws-load-balancer-type: "nlb" e service.beta.kubernetes.io/aws-load-balancer-target-type: "ip", impostare externalTrafficPolicy: Local e registrare gli IP dei pod come target in modo che il TLS venga passato direttamente ai pod (passthrough).
  3. Eseguire il deploy dei server gRPC in EKS e terminare il TLS/mTLS nei processi dei pod. Archiviare i certificati e il materiale di trust nei Secret di Kubernetes; configurare il server per richiedere la verifica del certificato client per il TLS reciproco.
  4. Bloccare l’accesso diretto all’NLB in modo che solo Global Accelerator possa raggiungerlo, aggiornando il security group dell’NLB per consentire l’ingresso solo dalla prefix list gestita da AWS per Global Accelerator (individuabile tramite aws ec2 describe-managed-prefix-lists e referenziando tale prefix list nelle regole del security group), impedendo alle macchine di bypassare l’accelerator e colpire direttamente l’NLB.
  5. Monitorare la concorrenza delle connessioni e lo scaling configurando HorizontalPodAutoscaler e Cluster Autoscaler di Kubernetes, e assicurarsi che lo slow start e il deregistration delay del target group dell’NLB siano ottimizzati per uno scale-in graduale (modify-target-group-attributes). Utilizzare le metriche di CloudWatch da Global Accelerator, NLB ed EKS per monitorare il numero di connessioni e lo stato di salute.

Logica di AWS: Global Accelerator fornisce gli indirizzi IP statici anycast richiesti dai distributori automatici e instrada i flussi TCP sulla backbone di AWS verso l’NLB regionale, migliorando l’affidabilità e la latenza. L’NLB preserva la connessione TCP e l’IP di origine del client originale e supporta un numero massiccio di connessioni concorrenti, consentendo ai pod di eseguire la terminazione mTLS senza una terminazione TLS intermedia. L’utilizzo della prefix list gestita di Global Accelerator nelle regole del security group impedisce il bypass diretto dell’accelerator e impone che il traffico arrivi solo tramite gli IP anycast. Questa combinazione soddisfa i requisiti di crittografia end-to-end, mTLS, alta concorrenza, IP statici e autoscaling in EKS.


Sicurezza della Rete e Conformità · Tutti i domini · Prestazioni della Rete e Monitoraggio

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Supera l'esame →

Sfoglia Amazon →

Related guides

Accesso tutto incluso

Un abbonamento. Ogni esame.

Ogni piano sblocca la ricerca illimitata di risposte, test pratici, spiegazioni AI e la libreria completa di risorse — in oltre 20 lingue.

Mensile
24.87
Just €0.83/day
Tutto incluso:
  • Ricerca risposte illimitata
  • Test pratici illimitati
  • Spiegazioni basate su AI
  • Libreria completa di risorse
  • Oltre 20 lingue
  • Aggiornamenti settimanali dei contenuti
  • Premi e referral
  • Supporto prioritario
Inizia la prova gratuita

Nessuna carta di credito richiesta*

Miglior valore
12 mesi
179.87
Just €0.49/daySave 40%
Tutto incluso:
  • Ricerca risposte illimitata
  • Test pratici illimitati
  • Spiegazioni basate su AI
  • Libreria completa di risorse
  • Oltre 20 lingue
  • Aggiornamenti settimanali dei contenuti
  • Premi e referral
  • Supporto prioritario
Inizia la prova gratuita

Nessuna carta di credito richiesta*

✓ Piano gratuito incluso · ✓ Annulla in qualsiasi momento · ✓ Tutti i piani sbloccano il prodotto completo