Amazon ANS-C01: Networking per Container e Serverless — 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.

Networking di EKS (CNI, networking dei pod)

Il networking dei pod in Amazon EKS è dominato dal plugin Amazon VPC CNI (amazon-vpc-cni-k8s), che assegna a ogni pod un indirizzo IP dal VPC e instrada il traffico dei pod direttamente sulla rete VPC. Questo design offre un controllo di sicurezza prevedibile a livello di VPC (gruppi di sicurezza, NACL) e un routing a bassa latenza, ma richiede un’attenta pianificazione della capacità degli indirizzi IP e delle ENI, poiché il numero di indirizzi IPv4 secondari per ENI e il numero di ENI per tipo di istanza sono limitati dall’hardware. Il daemonset aws-node gestisce l’allocazione degli IP e le operazioni di attach/detach; la sua ConfigMap viene modificata con kubectl per ottimizzare il comportamento (ad esempio, impostando WARM_IP_TARGET, WARM_ENI_TARGET o ENABLE_PREFIX_DELEGATION). La delega dei prefissi (prefix delegation) e le modalità ENI per pod riducono l’esaurimento degli IP per nodo, consentendo a un nodo di allocare interi prefissi /28 a una ENI (ENABLE_PREFIX_DELEGATION=true) o assegnando una ENI dedicata per ogni pod (utile per un isolamento ad alta sicurezza).

Alternative all’Amazon VPC CNI come Cilium (eBPF) o Calico possono offrire diversi compromessi. Cilium può sostituire kube-proxy e implementare un forwarding L3/L4 ad alte prestazioni utilizzando eBPF, abilitare la crittografia trasparente tra i nodi (WireGuard o IPsec) e ridurre la pressione sugli IP a livello di nodo utilizzando approcci di overlay o masquerading. Con Cilium ci si integra comunque con il routing del VPC per il traffico in uscita (egress) e in entrata (ingress), ma si evitano le frequenti operazioni di attach/detach delle ENI; questo è importante in caso di alti tassi di ricambio (churn) dei pod. Per un numero molto elevato di connessioni e un comportamento L7 rigoroso, si consideri anche l’ottimizzazione della modalità di kube-proxy (IPVS) e le impostazioni del kernel del nodo: regolare conntrack_max, tcp_tw_recycle/tcp_tw_reuse e ip_local_port_range, ed esporli tramite kubelet o script di init dei daemonset per evitare l’esaurimento delle porte effimere in presenza di migliaia di connessioni gRPC concorrenti e di lunga durata.

Modalità di networking di ECS e integrazione VPC di Lambda

Il networking dei task ECS ha tre modalità principali: bridge, host e awsvpc. La modalità awsvpc è la più paragonabile al networking dei pod di Kubernetes perché collega una ENI a ogni task (o gruppo di task) e assegna un IP privato e gruppi di sicurezza direttamente al task. Si configura awsvpc specificando awsvpcConfiguration con le sottoreti (subnets) e i gruppi di sicurezza (securityGroups) nelle chiamate API RunTask o CreateService. Fargate impone l’uso di awsvpc e fornisce quindi un isolamento di rete a livello di task, integrandosi con AWS Cloud Map per l’individuazione dei servizi (service discovery). Utilizzare awsvpc quando è necessario un filtraggio del traffico basato su gruppi di sicurezza per singolo task, o quando è necessario esporre il routing e le metriche standard del VPC.

Le funzioni Lambda che necessitano di accesso al VPC vengono collegate al VPC tramite ENI nelle sottoreti e nei gruppi di sicurezza configurati per la funzione. Queste ENI sono create e gestite dal control plane di Lambda, ma il provisioning delle ENI può aggiungere latenza di avvio a freddo (cold-start) e storicamente ha limitato il rapido scale-up, a meno che non venga mitigato con la concorrenza allocata (provisioned concurrency) o utilizzando endpoint VPC (AWS PrivateLink) e un’architettura di sottoreti attentamente progettata. Quando si collocano molte funzioni Lambda in un VPC, assicurarsi che le sottoreti dispongano di IP disponibili, utilizzare NAT Gateway o istanze NAT per il traffico in uscita (egress) se necessario, e preferire gli endpoint VPC (endpoint com.amazonaws.* tramite AWS::EC2::VPCEndpoint) per evitare, ove possibile, di instradare il traffico in uscita attraverso Internet. Monitorare le operazioni di attach/detach delle ENI utilizzando CloudWatch Logs e VPC Flow Logs per osservare il comportamento di scalabilità e risolvere problemi di throttling legati alla concorrenza.

App Mesh e individuazione dei servizi (service discovery)

AWS App Mesh utilizza sidecar Envoy come data plane e fornisce osservabilità L3–L7, traffic shaping, tentativi (retries) e controlli di origine/terminazione TLS. Si definiscono mesh, nodi virtuali e servizi virtuali tramite l’API di App Mesh (CreateMesh, CreateVirtualNode, CreateVirtualService) o il controller di App Mesh per Kubernetes. App Mesh supporta mTLS configurando il blocco TLS di un listener di VirtualNode con una clientPolicy e una certificate authority, ed è possibile integrarlo con AWS Certificate Manager (ACM) o SDS per la distribuzione dei certificati. Tuttavia, si noti che i sidecar di App Mesh terminano e ri-crittografano il traffico per design; se un requisito impone che il traffico dell’applicazione rimanga crittografato end-to-end tra il client e il pod dell’applicazione (senza decrittografia nel proxy di rete), è necessario assicurarsi che il TLS venga terminato solo a livello del pod ed evitare di terminarlo all’ingress della mesh o al load balancer.

L’individuazione dei servizi (service discovery) viene comunemente eseguita con i Service di Kubernetes e CoreDNS per EKS, con Cloud Map (CreateService, RegisterInstance) per ambienti multipiattaforma e con le zone ospitate private di Route 53 per la ricerca basata su DNS. AWS Cloud Map si integra direttamente con ECS e App Mesh, abilitando record SRV o A e health check gestiti tramite API. Per ambienti dinamici in cui le istanze scalano rapidamente, combinare TTL DNS brevi e health check di Cloud Map per evitare la risoluzione di record obsoleti; se è necessaria una consistenza immediata, utilizzare l’API del control plane di una service mesh per recuperare gli endpoint anziché affidarsi alla cache DNS.

Pattern di progettazione e compromessi

Quando si progetta per gRPC su larga scala tramite TLS con mTLS, è necessario decidere dove termina il TLS. La terminazione a livello del load balancer (ALB) consente di delegare la gestione dei certificati ad ACM e semplifica la rotazione dei certificati, ma interrompe la crittografia end-to-end e non può fornire il mutual TLS ai pod di backend, a meno che il backend non ristabilisca il TLS con le informazioni del certificato client inoltrate. Per un vero mTLS end-to-end in cui gli endpoint dell’applicazione autenticano direttamente i client, utilizzare un gateway passthrough L4 come un Network Load Balancer e lasciare che il pod/applicazione gestisca il TLS/mTLS. Combinare il target-type ip dell’NLB con l’annotazione dell’AWS Load Balancer Controller service.beta.kubernetes.io/aws-load-balancer-target-type: "ip" per registrare direttamente gli IP dei pod; questo pattern scala bene perché l’NLB è progettato per milioni di connessioni e supporta sessioni TCP/gRPC di lunga durata senza terminare il TLS.

Per l’ingress e il routing basato su percorsi (path-based) con terminazione HTTPS, l’Application Load Balancer è più appropriato perché supporta regole basate su host/percorso, reindirizzamenti e l’integrazione con WAF. Per preservare gli IP dei client quando l’ALB termina il TLS, fare affidamento sugli header X-Forwarded-For; i server web di backend devono utilizzare e registrare l’header X-Forwarded-For, e si dovrebbero abilitare gli access log dell’ALB per la verifica. Se è necessario l’indirizzo socket reale del client a livello del server (per software legacy), utilizzare un NLB con il proxy protocol v2 e assicurarsi che i servizi di backend supportino il proxy protocol.

La connettività dei servizi tra più account AWS e VPC scala in modo diverso a seconda del pattern utilizzato. Il VPC peering è semplice ma ha una complessità di gestione N^2; il Transit Gateway centralizza il routing e scala meglio per un numero elevato di VPC con la segregazione delle tabelle di routing; AWS PrivateLink (Interface VPC Endpoints) fornisce il modello di accesso più granulare per servizio e basato sull’identità, poiché si espone un servizio endpoint tramite NLB e i consumer creano endpoint di interfaccia nei loro VPC. Per servizi condivisi multi-account con un controllo degli accessi rigoroso e un onboarding scalabile, è preferibile utilizzare PrivateLink perché isola il routing (nessuna modifica alle tabelle di routing nei VPC dei consumer) e utilizza i security group per controlli granulari.

Errori comuni e criteri decisionali

Un errore ricorrente è presumere che lo stesso modello di networking si adatti a tutti i workload. I workload con connessioni stateful o a lunga durata (gRPC, database) prediligono il passthrough L4 (NLB) con terminazione TLS a livello di pod o pattern hostPort/hostNetwork per evitare la latenza indotta dal proxy; i microservizi HTTP che necessitano di routing basato sul percorso, WAF o terminazione WebSocket beneficiano delle funzionalità di ALB e App Mesh. Un altro errore è non tenere conto dei limiti di ENI/IP quando si scalano i nodi EKS o i task ECS in modalità awsvpc: consultare sempre la tabella dei tipi di istanza EC2 per ENI e IP-per-ENI e utilizzare la delegazione dei prefissi (prefix delegation) o gli overlay Cilium quando è necessaria un’alta densità di pod.

Il monitoraggio e il debug richiedono più fonti: VPC Flow Logs e metriche delle ENI per vedere il traffico in uscita/ingresso (egress/ingress), metriche CloudWatch per gli AWS Load Balancer (ActiveFlowCount, ProcessedBytes) e telemetria a livello di applicazione da Envoy/App Mesh o dall’agente AWS X-Ray. Per Lambda e Fargate, ricorda che i cold start legati alle operazioni sulle ENI possono essere mitigati con la concorrenza allocata (provisioned concurrency) o riprogettando i pattern di accesso per utilizzare endpoint VPC e PrivateLink, in modo che le funzioni non necessitino di un’ampia connettività in uscita.

Problema Pratico: Scenario d’uso

Azienda: Acme Payments Inc. Sfida: Acme Payments gestisce un servizio gRPC su Amazon EKS che deve supportare migliaia di connessioni TLS simultanee sulla porta TCP 443, utilizzare il TLS reciproco (mTLS) in modo che il certificato client sia convalidato dal servizio di backend e consentire al cluster EKS di eseguire l’autoscaling tramite Cluster Autoscaler e HPA senza interrompere la connettività o richiedere la terminazione TLS nel load balancer.

Approccio numerato:

Distribuire il servizio con TLS a livello di pod e autenticazione reciproca implementata nell’applicazione o in un sidecar che non termina la crittografia TLS end-to-end per i client esterni. Archiviare i certificati server/client in AWS Secrets Manager e montarli tramite il secrets store CSI di Kubernetes o utilizzare un meccanismo di distribuzione dei certificati che funzioni con il ciclo di vita del pod.
Utilizzare l’AWS Load Balancer Controller per creare un Network Load Balancer annotando il Service (service.beta.kubernetes.io/aws-load-balancer-type: "nlb") e impostando il tipo di target su IP (service.beta.kubernetes.io/aws-load-balancer-target-type: "ip"), quindi creare un listener TCP sulla porta 443. Ciò garantisce che l’NLB esegua un passthrough L4 e non termini la crittografia TLS.
Configurare il target group dell’NLB con protocollo TCP e registrare dinamicamente gli IP dei pod (il Load Balancer Controller chiamerà CreateTargetGroup e RegisterTargets). Assicurarsi che gli health check siano impostati su TCP o su una sonda di controllo personalizzata basata su TCP a un intervallo breve, in modo che i target vengano contrassegnati come sani rapidamente durante l’autoscaling (aws elbv2 create-target-group --protocol TCP --port 443 --target-type ip; aws elbv2 create-listener --protocol TCP --port 443 ...).
Ottimizzare l’Amazon VPC CNI per supportare un’alta densità di pod e ridurre il churn delle ENI: abilitare la delegazione dei prefissi se supportata (impostare ENABLE_PREFIX_DELEGATION=true nella ConfigMap aws-node), configurare WARM_IP_TARGET per mantenere indirizzi di riserva e monitorare le metriche di aws-node (log del daemonset kube-system e metriche personalizzate di CloudWatch). Se i limiti di IP a livello di nodo sono una preoccupazione, considerare Cilium con eBPF per una maggiore densità di pod e minori operazioni sulle ENI.
Scalare il cluster in sicurezza: assicurarsi che il Cluster Autoscaler abbia i tag dei gruppi di nodi e le autorizzazioni IAM corretti, impostare i PodDisruptionBudgets e verificare che gli health check del target group e il drenaggio delle connessioni (connection draining) dell’NLB siano configurati per evitare di interrompere connessioni gRPC a lunga durata durante lo scale-down.
Gestire in sicurezza la rotazione e la fiducia dei certificati: automatizzare la rotazione dei certificati con ACM Private CA o Secrets Manager e assicurarsi che i pod recuperino i bundle di certificati attendibili (trust bundle) aggiornati senza richiedere una riconfigurazione dell’NLB. Utilizzare probe di readiness/liveness di Kubernetes che riflettano la prontezza dell’handshake mTLS.

Logica di AWS: Un Network Load Balancer in modalità target IP preserva la crittografia TLS fino al pod (crittografia end-to-end reale) e supporta milioni di connessioni TCP persistenti, rendendolo appropriato per migliaia di sessioni gRPC simultanee. La registrazione diretta degli IP dei pod evita la complessità della registrazione dei target tramite hostPort per nodo o per istanza e funziona in modo pulito con Cluster Autoscaler/HPA, poiché l’AWS Load Balancer Controller registrerà e deregistrerà gli IP dei pod man mano che i pod scalano. L’ottimizzazione del VPC CNI o l’adozione di un data plane basato su eBPF previene l’esaurimento degli IP e riduce la latenza di attach/detach delle ENI, il che è essenziale per un autoscaling rapido e per workload con un alto numero di connessioni. L’archiviazione e la distribuzione degli artefatti mTLS tramite Secrets Manager o un provider CSI rende gestibile il ciclo di vita dei certificati senza intervenire sul load balancer.

← Automazione · Tutti i domini

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