Amazon ANS-C01: Automazione, IaC e Operazioni di Rete — 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

L’Infrastruttura come Codice (Infrastructure as Code) per il networking su AWS trasforma la topologia di rete, le policy di sicurezza e il routing in template dichiarativi e operazioni di lifecycle deterministiche. I template di CloudFormation (AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup) codificano lo stato desiderato, mentre le API di CloudFormation — operazioni CreateStack, UpdateStack, DeleteStack, DescribeStacks e ChangeSet — applicano le modifiche in modo atomico. Utilizzare stack nidificati e template modulari per isolare i domini di networking (servizi condivisi, VPC applicativi per account, zone di ingresso/uscita) e gli StackSets per propagare stack di rete coerenti attraverso AWS Organizations. Il rilevamento delle deviazioni (drift detection) (DetectStackDrift) e i set di modifiche (change set) forniscono meccanismi di protezione (guardrail) in modo che l’automazione possa rilevare e richiedere una revisione umana per le modifiche alla rete fuori banda.

L’automazione deve coprire anche le parti della rete che CloudFormation non può esprimere nativamente o che richiedono hook del ciclo di vita: la condivisione di risorse tra account, le integrazioni on-premise e la configurazione a runtime sugli host. Le risorse personalizzate (custom resource) di CloudFormation (supportate da Lambda) o i moduli di CloudFormation possono chiamare API come CreateResourceShare (AWS RAM) per condividere un Transit Gateway o una subnet, o chiamare SendCommand di Systems Manager (SSM) per iniettare certificati o policy di routing nelle istanze. Per Kubernetes in EKS, l’AWS Load Balancer Controller viene installato tramite Helm e gestito attraverso le annotazioni dei Service; CloudFormation può effettuare il provisioning del ruolo IAM, del provider OIDC e degli oggetti HelmRelease tramite AWS::EKS::Cluster e risorse personalizzate, ma la mappatura a runtime degli IP dei pod ai gruppi di destinazione (target group) dell’NLB è gestita dal controller.

Servizi e configurazioni chiave

Ci sono servizi e API AWS principali che utilizzerai ripetutamente quando si automatizzano le operazioni di rete: CloudFormation (CreateStack, UpdateStack, DetectStackDrift), AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare), AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute), Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes), AWS Lambda (CreateFunction, AddPermission, Invoke), Systems Manager (PutParameter, SendCommand, CreateDocument) e AWS Config (PutEvaluations, StartConfigurationRecorder). Questi servizi formano uno stack di automazione tipico per un networking sicuro e verificabile.

Quando si progettano template e automazioni, prestare attenzione agli attributi specifici delle risorse e alle annotazioni dei controller. Per i load balancer, scegliere il tipo e gli attributi corretti: un NLB con listener TCP preserva l’IP di origine e supporta il Proxy Protocol v2 tramite CreateLoadBalancer/ModifyTargetGroupAttributes e l’impostazione di “proxy_protocol_v2.enabled” sui gruppi di destinazione; un ALB (Application Load Balancer) termina il TLS, inserisce gli header X-Forwarded-For per gli IP dei client e supporta gRPC/HTTP2 se configurato con listener HTTPS. Per EKS si usano annotazioni come service.beta.kubernetes.io/aws-load-balancer-type: “nlb” o le annotazioni Ingress/Service dell’AWS Load Balancer Controller per controllare il passthrough TLS rispetto alla terminazione e per impostare il tipo di destinazione (target type) su ip per il targeting diretto dei pod. Per la condivisione tra account e le reti multi-account, si utilizzerà AWS RAM per condividere i Transit Gateway e gli StackSets di CloudFormation combinati con ruoli di amministratore delegato per creare collegamenti (attachment) e accessi negli account consumer.

Pattern di progettazione e compromessi

Due pattern comuni e contrastanti sono il modello hub-and-spoke con Transit Gateway e il VPC condiviso tramite AWS RAM. Il modello hub-and-spoke con un Transit Gateway centralizza il routing, l’ispezione e la connettività inter-VPC; è scalabile perché i collegamenti (attachment) e le tabelle di routing consentono la segmentazione, ed è possibile condividere il TGW usando RAM in modo che account diversi possano creare i propri collegamenti senza trasferire la piena proprietà. Il compromesso riguarda la propagazione delle rotte e i limiti delle tabelle di routing: le tabelle di routing e i limiti dei collegamenti (attachment) del Transit Gateway richiedono pianificazione e possono introdurre punti singoli in cui le policy devono essere applicate (usare più tabelle di routing e AWS Network Firewall per isolare il traffico). Il VPC condiviso (condivisione di VPC con AWS RAM) posiziona le subnet in un account host e consente agli account consumer di avviare risorse in quelle subnet, il che semplifica i controlli di sicurezza centrali per la connettività, ma riduce l’autonomia a livello di account e complica l’isolamento della rete per singola business unit, poiché la proprietà dei security group e i confini IAM devono essere gestiti con attenzione.

Per il traffico in ingresso (ingress) e la terminazione TLS, è necessario bilanciare la necessità di crittografia end-to-end con la scalabilità e la conservazione dell’IP del client. Se è richiesta la terminazione TLS a livello del load balancer (per WAF, centralizzazione dei certificati e routing HTTP), l’ALB è lo strumento giusto; aggiunge l’header X-Forwarded-For in modo che il logging applicativo possa catturare gli IP dei client, e l’ALB supporta il routing basato su percorso e host verso più gruppi di destinazione. Se si richiede una vera crittografia TLS end-to-end o mTLS, in cui il load balancer non deve decifrare il traffico, utilizzare un NLB in modalità TCP per inoltrare (passthrough) il traffico TLS agli endpoint di backend (pod o istanza) e configurare il target type su ip e externalTrafficPolicy: Local su Kubernetes per preservare l’IP di origine. Per migliaia di connessioni gRPC bidirezionali concorrenti con mTLS, un NLB che inoltra il traffico TLS grezzo alle porte dei pod, combinato con i pod che terminano l’mTLS, fornisce scalabilità e una vera crittografia end-to-end, utilizzando al contempo le annotazioni dell’AWS Load Balancer Controller per creare i listener e i gruppi di destinazione NLB appropriati.

Insidie comuni e criteri decisionali

Un’insidia frequente è confondere la posizione di terminazione TLS con i requisiti relativi all’IP del client: l’ALB fornisce l’header

undefined

quando termina la connessione TLS, ma non preserva l’IP di origine verso la destinazione come fa l’NLB. Se sono necessarie sia le funzionalità dell’ALB (routing basato su host/percorso, WAF) sia l’IP di origine originale nel backend, si può considerare di utilizzare un ALB per la terminazione HTTP e l’inoltro a reverse proxy o sidecar che ricostruiscono gli IP di origine dall’header

undefined

, oppure utilizzare un’architettura in cui un NLB effettua il passthrough TLS verso servizi che implementano mTLS e delegano il routing HTTP a proxy interni al cluster. Un’altra insidia è la configurazione errata dei permessi cross-account: quando si condivide un Transit Gateway o un’altra risorsa di rete con RAM, è fondamentale utilizzare una condivisione di risorse esplicita e il ruolo IAM e il principal RAM corretti; in caso contrario, si otterranno errori opachi di tipo “permission denied”.

Per quanto riguarda l’automazione della conformità, non archiviare chiavi private o materiale della CA non crittografati in testo semplice. Utilizzare SSM Parameter Store SecureString con una chiave KMS che abbia una policy della chiave minimale, consentendo l’accesso solo ai ruoli e ai principal che ne hanno bisogno. Utilizzare le regole gestite di AWS Config (ad esempio,

undefined

) e, laddove le regole gestite non coprano i propri criteri, implementare regole di Config basate su Lambda che richiamano

undefined

. La correzione dovrebbe essere automatizzata tramite documenti di SSM Automation o Systems Manager Run Command che l’azione di correzione di Config può invocare, ma è necessario prevedere sempre un percorso di avviso e approvazione per le modifiche ad alto rischio.

Problema Pratico: Scenario d’uso

Azienda: ApexTelemetrics — sfida: fornire un servizio gRPC ospitato su EKS, raggiungibile a livello globale, che richieda un vero TLS reciproco end-to-end (client e server si autenticano con mTLS), supporti migliaia di connessioni simultanee a lunga durata sulla porta TCP 443, esegua l’autoscaling dei pod e garantisca che la distribuzione e la rotazione dei certificati siano automatizzate e verificabili.

Approccio:

Provisioning della rete e del load balancer con CloudFormation: creare un NLB tramite

undefined

configurato con un listener TCP sulla porta 443 e gruppi di destinazione con

undefined

impostato su “ip” e controlli di integrità su TCP. Utilizzare CloudFormation

undefined

e stack nidificati modulari per VPC, sottoreti e NLB. Usare le annotazioni dell’AWS Load Balancer Controller sul Service di EKS (

undefined: “nlb”,
undefined: “ip”) in modo che ogni Service crei il gruppo di destinazione dell’NLB direttamente verso i pod.

Garantire il passthrough TLS e la terminazione mTLS a livello dei pod: configurare il Service di EKS per inoltrare il traffico TCP 443 direttamente alle porte dei pod; implementare un proxy sidecar o envoy all’interno di ogni pod che esegua la terminazione mTLS con il client e imponga l’autenticazione reciproca. Impostare

undefined: Local sul Service in modo che l’IP di origine venga preservato se necessario, e utilizzare l’autoscaling a livello di Pod (Horizontal Pod Autoscaler) con Cluster Autoscaler per scalare nodi e pod insieme.

Automatizzare il ciclo di vita e la distribuzione dei certificati: archiviare le chiavi private dei certificati del server e della CA in SSM Parameter Store SecureString, crittografate da una chiave KMS. Creare una risorsa personalizzata basata su AWS Lambda in CloudFormation per creare parametri SSM durante la creazione dello stack (

undefined

con il ruolo IAM appropriato, quindi risorsa personalizzata di CloudFormation per chiamare

undefined

). Utilizzare SSM Run Command o un DaemonSet immutabile che recupera i segreti da SSM tramite un ruolo IAM associato al pod (tramite IRSA) per iniettare i certificati nel sidecar. Per la rotazione, pianificare funzioni Lambda (

undefined

regola EventBridge) per generare nuovi certificati, usare

undefined

e utilizzare SSM o Kubernetes Jobs per eseguire riavvii progressivi. 4) Conformità e audit: abilitare le regole di AWS Config (regole gestite come

undefined

e regole personalizzate basate su Lambda che usano

undefined

) per verificare che i listener dell’NLB siano TCP e che nessun ALB termini la connessione TLS per questo servizio. Configurare la correzione di Config per invocare documenti di SSM Automation se viene rilevata una configurazione errata e inviare i rilevamenti ad AWS Security Hub e CloudWatch Events. Motivazione di AWS: l’NLB in modalità TCP fornisce il vero passthrough TLS necessario per l’mTLS end-to-end e scala fino a migliaia di connessioni simultanee con una ridotta impronta sulla CPU per connessione a livello di load balancer. Indirizzare i pod tramite

undefined

=ip rimuove un hop aggiuntivo e mantiene reattivo l’autoscaling. L’archiviazione e la rotazione delle chiavi in SSM Parameter Store, protetto da KMS, fornisce una gestione centralizzata e verificabile dei segreti con controlli IAM, e l’uso di CloudFormation con risorse personalizzate Lambda ed EventBridge garantisce che l’intero ciclo di vita sia codificato, ripetibile e osservabile.

← Prestazioni della Rete e Monitoraggio · Tutti i domini · Networking per Container e Serverless →

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