Amazon ANS-C01: Bilanciamento del Carico e Gestione del Traffico — Guida allo studio

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

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.

Concetto fondamentale

Il bilanciamento del carico in AWS opera su due livelli fondamentali: L4 (trasporto) e L7 (applicazione). Il Network Load Balancer (NLB) fornisce una distribuzione a livello L4 (TCP/UDP/TLS) ed è ottimizzato per prestazioni estreme, preservando l’IP di origine del client e supportando milioni di connessioni simultanee con latenza molto bassa e ridotta rotazione delle connessioni. L’Application Load Balancer (ALB) opera a livello L7 (HTTP/HTTPS/WebSocket e HTTP/2/gRPC), fornisce routing basato su host e percorso, ispezione degli header, controlli di integrità basati su HTTP e stickiness basata su cookie, ed esegue la terminazione TLS quando configurato con certificati in ACM. Il Gateway Load Balancer (GWLB) è un load balancer appositamente creato per scalare appliance virtuali di terze parti (firewall, IDS/IPS) utilizzando l’incapsulamento GENEVE e gli endpoint del Gateway Load Balancer (GWLBe), consentendo l’ispezione del traffico inline senza scalabilità manuale delle appliance.

I listener e le regole dei listener sono i punti di ingresso L4/L7 che mappano protocolli/porte ai gruppi di destinazione. Un listener su un ALB può avere regole complesse che ispezionano host, percorso, header, CIDR dell’IP di origine e inoltrano il traffico a diversi gruppi di destinazione; l’ALB può anche effettuare l’offload del TLS (terminazione) e presentare gli header X-Forwarded-For, X-Forwarded-Proto e X-Forwarded-Port alle destinazioni. Un listener NLB è tipicamente un listener TCP/UDP/TLS che inoltra il traffico ai gruppi di destinazione senza analizzare il payload (a meno che non si abiliti la terminazione TLS sull’NLB): quando si utilizza il passthrough TCP, si preserva il TLS end-to-end, quindi il backend deve presentare e convalidare i certificati per il TLS reciproco. I gruppi di destinazione sono il collegamento tra un listener del load balancer e l’insieme di endpoint (istanza, IP o Lambda) ed espongono attributi come protocollo/porta/percorso del controllo di integrità, ritardo di deregistrazione (connection draining) e proprietà di stickiness.

Servizi chiave e configurazione

Scegliere il bilanciatore giusto per le caratteristiche del traffico e i requisiti di sicurezza. Utilizzare l’ALB quando si necessita di routing basato su host/percorso, funzionalità HTTP/HTTPS come WebSockets o HTTP/2/gRPC con routing application-aware e stickiness basata su cookie. Configurare i listener dell’ALB con CreateListener o tramite AWS::ElasticLoadBalancingV2::Listener, associare i certificati da ACM e impostare le regole del listener utilizzando CreateRule con condizioni (Field=path-pattern, host-header, http-header). Abilitare la stickiness sui gruppi di destinazione dell’ALB con ModifyTargetGroupAttributes impostando Key=stickiness.enabled,Value=true e Key=stickiness.lb_cookie.duration_seconds,Value=<seconds> per utilizzare i cookie generati dal load balancer.

Utilizzare l’NLB per connessioni TCP a lunga durata e con throughput elevato, e quando è richiesta la conservazione dell’IP di origine del client nel backend. Creare un NLB con aws elbv2 create-load-balancer --name my-nlb --type network --subnets <subnet-ids> e aggiungere un listener TCP con aws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn>. Per il passthrough TLS e mTLS, configurare il listener dell’NLB come TCP in modo che il TLS sia terminato dal backend; impostare il gruppo di destinazione su target-type ip durante la registrazione degli IP dei pod per Kubernetes. Utilizzare ModifyTargetGroupAttributes per impostare Key=deregistration_delay.timeout_seconds,Value=<seconds> per consentire il connection draining; per l’NLB è anche possibile abilitare l’affinità basata sull’IP di origine (stickiness del gruppo di destinazione), ove appropriato.

Il Gateway Load Balancer è configurato con CreateLoadBalancer Type=gateway e supportato da gruppi di destinazione delle istanze delle appliance (o da uno scale set in un gruppo di autoscaling), e utilizza un endpoint del Gateway Load Balancer nei VPC consumer per indirizzare il traffico verso le appliance nel VPC di servizio. Utilizzare questo pattern quando si necessita di ispezione trasparente e si desidera che le appliance scalino automaticamente con il traffico; creare listener sulla porta 6081 (incapsulamento GENEVE) e registrare le ENI delle appliance nel gruppo di destinazione del GWLB.

Le impostazioni operative da controllare programmaticamente includono il bilanciamento del carico tra zone (cross-zone load balancing), il ritardo di deregistrazione (connection draining) e l’ottimizzazione dei controlli di integrità. Per il bilanciamento tra zone, impostare gli attributi sul load balancer (aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=true) per garantire la distribuzione del traffico tra le AZ anziché sbilanciare la capacità per singola AZ. Impostare l’intervallo dei controlli di integrità, il timeout e le soglie di healthy/unhealthy sui gruppi di destinazione per evitare il flapping durante gli eventi di autoscaling.

Pattern di progettazione e compromessi

Per la crittografia TLS end-to-end e il mutual TLS (mTLS), dove il traffico deve rimanere crittografato e i certificati client devono essere presentati al backend, è preferibile utilizzare il passthrough a livello L4 tramite un NLB con listener TCP. Questo mantiene intatta la sessione TLS, consentendo ai backend di convalidare i certificati X.509 del client; configurare i target group per utilizzare target di tipo IP, in modo che gli indirizzi IP dei pod Kubernetes possano essere registrati direttamente e l’AWS Load Balancer Controller possa gestire il ciclo di vita dei target. Il compromesso è la perdita delle funzionalità L7 dell’ALB, come il routing basato su host/path, le integrazioni con Web Application Firewall e la stickiness nativa dei cookie HTTP a livello di load balancer.

Quando sono necessari routing basato sul contenuto, terminazione TLS e funzionalità HTTP avanzate, utilizzare un ALB e terminare la sessione TLS a livello dell’ALB (con certificati gestiti da ACM). Per conservare l’IP del client per il logging e le regole WAF, leggere l’header X-Forwarded-For, che viene popolato dall’ALB, oppure utilizzare un livello che inserisca l’IP originale del client negli header. Se è necessario che lo stack di rete/OS del backend veda l’IP del client a livello di socket, utilizzare un NLB (o abilitare il Proxy Protocol per passare l’IP originale), ma tenere presente che il Proxy Protocol deve essere abilitato sul target group e che l’applicazione o il proxy (ad esempio, Envoy) deve essere in grado di analizzarlo.

La gestione delle sticky session in un ambiente con autoscaling richiede un’attenta valutazione. La stickiness dei cookie dell’ALB può vincolare un client a un target per un certo periodo, il che può ostacolare una scalabilità bilanciata tra i pod in caso di traffico di sessione intenso; i pattern alternativi includono l’uso di una stickiness di breve durata combinata con l’esternalizzazione dello stato di sessione su ElastiCache (Redis) o DynamoDB, oppure l’uso di un proxy sidecar (Envoy) per gestire l’affinità di sessione con il consistent hashing. Il connection draining (deregistration delay) è fondamentale per uno spegnimento controllato (graceful shutdown): impostare deregistration_delay.timeout_seconds su una durata superiore a quella della richiesta RPC/HTTP più lunga per evitare terminazioni improvvise ed errori lato client durante la terminazione del pod; configurare i preStop hook di Kubernetes per coordinare il ciclo di vita del pod con la deregistrazione.

GWLB è il pattern appropriato quando è necessaria un’ispezione inline scalabile su più VPC e si desiderano controlli di sicurezza centralizzati. Combinare GWLB con architetture basate su Transit Gateway o VPC peering secondo necessità; il costo e la complessità operativa della gestione delle appliance rappresentano il compromesso rispetto all’utilizzo di servizi gestiti come AWS Network Firewall.

Errori comuni e criteri decisionali

Un errore frequente è terminare il TLS a livello dell’ALB senza tenere conto delle esigenze a valle per l’autenticazione del client o per l’IP di origine. Se i backend richiedono il certificato client o l’IP di origine reale a livello TCP (per logging o autorizzazione), è necessario terminare il TLS sul backend tramite passthrough con un NLB o utilizzare il Proxy Protocol, assicurandosi che l’applicazione sia in grado di analizzarlo. Un altro errore comune è abilitare le sessioni permanenti (sticky) senza uno storage esterno per le sessioni quando si utilizza l’Horizontal Pod Autoscaler: quando i pod scalano in aumento o in diminuzione, l’affinità permanente può creare hotspot e capacità sprecata; è preferibile utilizzare backend stateless o esternalizzare lo stato della sessione.

Errori operativi possono derivare anche da controlli di integrità (health check) configurati in modo errato e da ritardi di deregistrazione che portano alla perdita di richieste durante la scalabilità. Impostare sempre i percorsi e le soglie dei controlli di integrità in modo che riflettano la fase di avvio (warm-up) dell’applicazione e utilizzare deregistration_delay.timeout_seconds per consentire il drenaggio (drain) delle connessioni a lunga durata. Il bilanciamento del carico tra zone (cross-zone) deve essere impostato intenzionalmente: abilitarlo riduce la latenza di coda e distribuisce uniformemente il carico, ma può aumentare i costi di trasferimento dati tra AZ; valutare questa opzione in base alla capacità delle AZ e ai pattern di traffico. Infine, il GWLB introduce l’overhead dell’incapsulamento (GENEVE) e della gestione delle appliance: è consigliabile automatizzare la registrazione delle appliance utilizzando le API di AWS (CreateTargetGroup/RegisterTargets) e strumentarle con i parametri di CloudWatch per guidare le policy di autoscaling.

Problema pratico: scenario d’uso

Azienda: Acme Telemetry. Sfida: Fornire crittografia end-to-end per un servizio gRPC (gRPC su TLS sulla porta TCP 443) distribuito in un cluster Amazon EKS, supportare migliaia di connessioni simultanee a lunga durata, utilizzare Kubernetes Cluster Autoscaler e HPA, e richiedere TLS reciproco (mTLS) in modo che il certificato client sia convalidato dal backend (ovvero, il traffico non deve essere decrittato da alcun load balancer intermedio).

1. Approccio di implementazione del caso d’uso: Provisionare un Network Load Balancer con un listener TCP sulla porta 443 e un gruppo di destinazione di tipo “ip” che punti agli IP dei pod. Creare l’NLB con aws elbv2 create-load-balancer –name acme-nlb –type network –subnets <subnet-ids>, creare il gruppo di destinazione con aws elbv2 create-target-group –name tg-grpc –protocol TCP –port 443 –target-type ip –vpc-id <vpc-id>, registrare le destinazioni tramite le annotazioni dell’AWS Load Balancer Controller per Kubernetes (service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip”) in modo che il controller registri automaticamente gli IP dei pod, e creare il listener con aws elbv2 create-listener –load-balancer-arn <arn> –protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn>. Impostare l’attributo del gruppo di destinazione deregistration_delay.timeout_seconds su un valore appropriato (ad esempio 300) utilizzando aws elbv2 modify-target-group-attributes per abilitare il drenaggio graduale (graceful draining).

2. Configurazione TLS e mTLS del backend: Terminare il TLS ed eseguire il TLS reciproco a livello dei pod. Distribuire sidecar Envoy o fare in modo che i server gRPC accettino direttamente il TLS, memorizzando i certificati del server e i bundle della CA nei Secrets di Kubernetes e montandoli nel pod. Configurare i backend per convalidare i certificati client rispetto alla propria CA e configurare i controlli di integrità per utilizzare TCP, al fine di evitare la terminazione del TLS a livello del load balancer. Assicurarsi che gli hook del ciclo di vita di HPA e Cluster Autoscaler si coordinino con la deregistrazione del gruppo di destinazione implementando hook preStop che consentano ai pod di completare il drenaggio prima di terminare.

3. Scalabilità e controlli operativi: Abilitare il bilanciamento del carico tra zone (cross-zone) sull’NLB, se necessario, con aws elbv2 modify-load-balancer-attributes –load-balancer-arn <arn> –attributes Key=load_balancing.cross_zone.enabled,Value=true per distribuire uniformemente le connessioni tra le AZ. Monitorare le connessioni simultanee e le velocità di flusso con i parametri di CloudWatch (NetworkPackets, ActiveFlowCount per l’NLB) e impostare policy di autoscaling per l’appliance (se si utilizza un sidecar) e per i nodi worker. Utilizzare ModifyTargetGroupAttributes per il drenaggio delle connessioni e ottimizzare gli intervalli dei controlli di integrità per un rilevamento dei guasti più rapido e senza flapping. Infine, automatizzare la rotazione dei certificati utilizzando AWS Secrets Manager e l’integrazione con cert-manager di Kubernetes.

Logica di AWS: L’NLB in modalità TCP preserva la sessione TLS end-to-end, consentendo al backend di eseguire la convalida mTLS; la sua architettura L4 è progettata per milioni di flussi simultanei e connessioni a lunga durata, e l’uso del target-type ip permette all’AWS Load Balancer Controller di registrare direttamente gli IP dei pod, consentendo a HPA/Cluster Autoscaler di scalare in modo trasparente. Il drenaggio delle connessioni (deregistration_delay) e i controlli di integrità prevengono la perdita di richieste durante la terminazione dei pod, mentre il bilanciamento tra zone (cross-zone) assicura una distribuzione uniforme tra le AZ, bilanciando il costo del trasferimento dati inter-AZ con le prestazioni.

← DNS e Route 53 · Tutti i domini · Sicurezza della Rete e Conformità →

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

Sfoglia Amazon →