Amazon ANS-C01: Progettazione di VPC e Networking Avanzato — 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.
Architettura VPC e fondamenti del subnetting
Un VPC è il confine di rete fondamentale in AWS e la forma delle tue allocazioni CIDR definisce tutto ciò che segue. Pianifica i blocchi CIDR tenendo a mente la crescita futura e la connettività tra account: alloca spazi di indirizzi ampi e non sovrapposti per ogni account/regione (ad esempio, un /16 per ambiente) e suddividili in sottoreti /20–/24 per isolare i carichi di lavoro per funzione e zona di disponibilità. Ricorda che EKS e altre piattaforme di container consumano indirizzi IP per le ENI dei pod o per IP secondari; l’AWS VPC CNI assegna gli IP dei pod dalla sottorete del VPC e i limiti di ENI/IP per istanza (DescribeInstanceTypes) limitano la densità massima dei pod. Per l’adozione di IPv6, preferisci un design dual-stack per trasferire i servizi esposti pubblicamente su IPv6, mantenendo IPv4 per l’integrazione con sistemi legacy; associa un blocco CIDR IPv6 fornito da Amazon con la chiamata API aws ec2 associate-vpc-cidr-block –vpc-id <vpc> –amazon-provided-ipv6-cidr-block e abilita l’assegnazione IPv6 a livello di sottorete con create-subnet e l’opzione –ipv6-cidr-block. Pianifica le risorse NAT per l’egress IPv4 e, per IPv6, utilizza un Egress-Only Internet Gateway, creato con CreateEgressOnlyInternetGateway e collegato al VPC.
Le tabelle di routing e il posizionamento delle sottoreti sono il modo in cui imponi la topologia e la resilienza. Crea tabelle di routing distinte per ogni scopo della sottorete (pubblica, privata con NAT, privata con Direct Connect e isolata) utilizzando CreateRouteTable e CreateRoute. Utilizza più NAT Gateway (o istanze NAT con autoscaling) distribuite tra le AZ per evitare un single point of failure nell’egress di una singola AZ; sii esplicito riguardo alle route propagate quando usi un Transit Gateway (CreateTransitGateway, CreateTransitGatewayRouteTable) in modo che i prefissi on-premise vengano iniettati solo dove previsto. Per la service discovery interna a un account, utilizza le zone ospitate private di Route 53 e associale ai VPC che necessitano dei record per evitare la fuoriuscita (leakage) di DNS oltre i confini.
Servizi chiave e dettagli di configurazione
Per la connettività privata, ci sono tre costrutti dominanti da comprendere: VPC Peering, AWS Transit Gateway e AWS PrivateLink (VPC endpoint di tipo interfaccia). Il VPC Peering (CreateVpcPeeringConnection, AcceptVpcPeeringConnection) è una connettività punto-punto semplice e a basso costo che richiede voci nella tabella di routing e non supporta il routing transitivo. Il Transit Gateway (CreateTransitGateway, CreateTransitGatewayVpcAttachment) è l’hub scalabile che supporta migliaia di VPC, il controllo centralizzato delle route e l’integrazione con il Direct Connect Gateway per la connettività ibrida; utilizza la propagazione e le associazioni delle tabelle di routing nel Transit Gateway per controllare il flusso est-ovest (east-west). PrivateLink (CreateVpcEndpointServiceConfiguration per registrare un servizio basato su NLB e CreateVpcEndpoint per creare endpoint di interfaccia) espone i servizi tra account senza esporre un VPC al routing, fornendo sicurezza granulare per servizio e controlli semplificati dei gruppi di sicurezza; scala bene perché i consumer creano endpoint di interfaccia e il traffico rimane a livello di NIC.
Il bilanciamento del carico e la conservazione dell’IP del client sono scelte di progettazione comuni da implementare correttamente. L’Application Load Balancer (ALB) termina la connessione TLS, instrada a livello L7 (CreateLoadBalancer Type application) e inietta gli header X-Forwarded-For/X-Forwarded-Proto di cui i backend devono fidarsi per registrare l’IP del client. Il Network Load Balancer (NLB) preserva gli IP di origine per i gruppi di destinazione (target group) e supporta milioni di connessioni; per un vero pass-through TLS verso i backend, utilizza un NLB con un listener TCP (CreateListener Protocol TCP) e registra le destinazioni (target) per IP, in modo che le sessioni crittografate raggiungano intatte i pod o le istanze. Per gRPC e un numero molto elevato di connessioni, preferisci un NLB davanti a EKS con tipo di destinazione (target type) ip e l’annotazione dell’AWS Load Balancer Controller service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” per registrare direttamente gli IP dei pod; questa combinazione mantiene l’IP di origine, supporta la terminazione mTLS a livello del pod e scala con gli autoscaler.
I VPC endpoint eliminano la necessità di egress verso Internet per le API di AWS e i servizi più diffusi. I Gateway endpoint per S3 e DynamoDB (CreateVpcEndpoint con –service-name com.amazonaws.<region>.s3) aggiungono route a una lista di prefissi dell’endpoint e sono gratuiti. Gli Interface endpoint (CreateVpcEndpoint con –vpc-endpoint-type Interface) creano interfacce di rete elastiche (ENI) con IP privati e gruppi di sicurezza; sono fatturati su base oraria e per GB, ma abilitano un consumo in stile PrivateLink e l’accesso tra account se abbinati a un servizio basato su NLB.
Pattern di progettazione e compromessi
Per un servizio centrale condiviso utilizzato da molte business unit su più account, PrivateLink e i servizi di endpoint rappresentano il pattern più sicuro e scalabile quando si richiede controllo e isolamento per singola connessione. Ospitare il servizio dietro un Network Load Balancer nel VPC dei servizi condivisi, creare un servizio di endpoint VPC (CreateVpcEndpointServiceConfiguration) e fare in modo che gli account consumer creino endpoint di interfaccia che vengono approvati. Questo evita una topologia full mesh e impedisce il routing transitivo, e i security group sugli endpoint di interfaccia consentono di limitare quali consumer possono connettersi. Il compromesso è il costo per endpoint e un certo overhead di gestione per accettare e verificare le connessioni degli endpoint.
Transit Gateway eccelle quando si hanno molti VPC che necessitano di connettività estesa, ispezione centrale e un unico punto per annunciare i prefissi on-premise tramite Direct Connect (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Utilizzare la segmentazione delle tabelle di routing e i controlli di propagazione per evitare movimenti laterali accidentali; Transit Gateway supporta la prioritizzazione delle route e le associazioni di tabelle di routing, in modo da poter isolare il traffico di produzione dalle reti a minore affidabilità. Il compromesso è che Transit Gateway centralizza il traffico e può comportare costi per il traffico tra VPC che altrimenti sarebbe locale; inoltre, modifica i domini di errore e richiede un’attenta pianificazione dei CIDR per prevenire la sovrapposizione degli indirizzi.
Per architetture ibride con riutilizzo limitato dei CIDR, considerare la combinazione di Direct Connect con Transit Gateway e Direct Connect Gateway (CreateDirectConnectGateway) per ridurre il numero di interfacce virtuali. Se è necessario l’isolamento della larghezza di banda per singola business unit sul collegamento fisico condiviso, configurare più interfacce virtuali private e monitorare le metriche CloudWatch per VIF (nomi di metriche come AWS/DX: BytesIn, BytesOut) e utilizzare allarmi CloudWatch a livello di VIF. Per identificare i consumatori intensivi, abilitare i VPC Flow Logs (CreateFlowLogs) verso S3 o CloudWatch Logs e analizzarli con Athena o CloudWatch Logs Insights; per la cattura dei pacchetti per singola VM, utilizzare Traffic Mirroring (CreateTrafficMirrorSession) per brevi intervalli di tempo.
L’adozione di IPv6 e i design dual-stack riducono la dipendenza dal NAT, abbassano i costi di throughput del NAT Gateway e semplificano l’indirizzamento lato client. Utilizzare la chiamata API aws ec2 associate-vpc-cidr-block per assegnare un prefisso IPv6 fornito da Amazon e creare sottoreti con blocchi CIDR IPv6. Attenzione al fatto che alcuni servizi e appliance di terze parti potrebbero non essere pronti per IPv6; utilizzare il dual-stack sui load balancer (CreateLoadBalancer con IpAddressType dualstack) per supportare sia i client IPv4 che IPv6 mentre i sistemi di backend rimangono su IPv4.
Insidie comuni e criteri decisionali
Trascurare il consumo di indirizzi IP da parte dei pod Kubernetes è una fonte frequente di interruzione del servizio. Tenere conto dei limiti di ENI e di IP secondari per tipo di istanza e utilizzare le impostazioni del CNI del VPC come WARM_IP_TARGETS o la delega dei prefissi per migliorare la disponibilità di IP. La mancata conservazione degli IP dei client a livello L7 è un’altra lacuna comune: se il TLS deve essere terminato sul load balancer, è necessario assicurarsi che l’applicazione legga l’header X-Forwarded-For e che i controlli di sicurezza dell’ALB limitino l’accesso diretto in modo che gli header possano essere considerati affidabili. Presumere che il VPC peering possa scalare indefinitamente porta spesso a topologie mesh ingestibili; preferire Transit Gateway per l’esposizione di servizi many-to-many e PrivateLink per quella one-to-many, dove sono richiesti sicurezza granulare e isolamento del traffico.
Le policy di sicurezza dovrebbero utilizzare i security group e le network ACL in combinazione con controlli a livello di namespace. Per imporre in modo rigoroso l’accesso tramite Global Accelerator invece che tramite gli URL diretti dell’ALB, affidarsi a una combinazione di IP set di AWS WAF popolati con gli intervalli IP di Global Accelerator (automatizzato tramite il file ip-ranges.json pubblicato) oppure progettare l’ALB come interno e anteporgli un NLB che funge da target per Global Accelerator, per poi esporre solo il punto di accesso di Global Accelerator. Automatizzare sempre gli aggiornamenti di qualsiasi controllo basato su IP e convalidarli utilizzando DescribePrefixLists e l’ingestion regolare di ip-ranges.json.
Problema Pratico: Scenario d’Uso
Azienda: Equinox Payments. Sfida: Equinox gestisce un servizio gRPC basato su EKS che richiede mTLS end-to-end per migliaia di connessioni simultanee, autoscaling tramite Cluster Autoscaler e HPA, e la conservazione degli IP dei client per il logging. Approccio: 1) Distribuire il servizio dietro un Network Load Balancer configurato con un listener TCP sulla porta 443 tramite l’AWS Load Balancer Controller, utilizzando l’annotazione service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” in modo che gli IP dei pod vengano registrati come target; 2) terminare il TLS a livello dei pod (non del NLB) e implementare il mutual TLS nell’applicazione (validazione dei certificati server e client), utilizzando i Kubernetes Secrets per i certificati e i readiness probe per guidare la registrazione dei target; 3) utilizzare il tipo di target ‘ip’ per conservare gli IP di origine dei client, abilitare il proxy protocol solo se necessario per appliance intermedie, e affidarsi al logging lato pod per catturare l’IP del client dalla connessione TCP; 4) configurare gli health check come readiness probe TCP o consapevoli di gRPC, e assicurarsi che le policy del Cluster Autoscaler e i tipi di istanza dei nodi abbiano una capacità sufficiente di ENI e IP; 5) implementare CloudWatch Container Insights e VPC Flow Logs (CreateFlowLogs) per monitorare il numero di connessioni e la telemetria a livello di VPC. Logica AWS: L’NLB con listener TCP preserva le sessioni crittografate e gli IP di origine, scalando fino a milioni di connessioni; il tipo di target ‘ip’ consente ai pod di ricevere l’IP di origine direttamente senza NAT; la terminazione del mTLS sui pod soddisfa i requisiti di crittografia end-to-end e di autenticazione a due vie; l’autoscaling funziona perché la prontezza (readiness) dei pod influisce direttamente sulla registrazione dei target e l’NLB scala in modo trasparente con il carico delle connessioni.
Tutti i domini · Connettività Ibrida: VPN e Direct Connect →
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 →