Amazon ANS-C01: Prestazioni della Rete e Monitoraggio — 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.
Networking avanzato e fabric a bassa latenza
Il networking avanzato (Enhanced networking) in AWS è l’insieme di funzionalità a livello di sistema operativo e hypervisor che aumentano significativamente i pacchetti al secondo (packets-per-second), riducono la latenza e l’overhead della CPU, e mettono a disposizione un throughput più elevato per ogni interfaccia virtuale. Le tecnologie principali sono l’Elastic Network Adapter (ENA), che fornisce un networking ad alte prestazioni basato su SR-IOV per la maggior parte delle famiglie di istanze EC2 moderne, e l’Elastic Fabric Adapter (EFA), che è un dispositivo di tipo RDMA con bypass del sistema operativo (OS-bypass) progettato per carichi di lavoro HPC e strettamente accoppiati basati su MPI/libfabric. Per abilitare ENA, è necessario confermare che il tipo di istanza supporti ENA e che l’AMI Linux disponga del driver ENA; a livello di programmazione, è possibile abilitarlo o interrogarne lo stato con chiamate API EC2 come RunInstances con InterfaceType=efa quando necessario, o ModifyInstanceAttribute per il supporto ena. EFA viene collegato creando un’interfaccia di rete con InterfaceType=efa (aws ec2 create-network-interface –interface-type efa) o avviando istanze con un’interfaccia di rete abilitata per EFA; l’istanza deve eseguire un kernel supportato e il modulo del kernel libfabric/efa, e tipicamente deve essere posizionata in un gruppo di posizionamento di tipo cluster (cluster placement group) per ottenere la latenza intra-host più bassa e la massima larghezza di banda di bisezione (bisection bandwidth).
I gruppi di posizionamento (placement groups) influenzano le prestazioni controllando il posizionamento delle istanze all’interno del fabric di rete sottostante. Un gruppo di posizionamento di tipo cluster (cluster placement group) tende a posizionare le istanze su un singolo rack o in un dominio di rete a bassa latenza per consentire la massima larghezza di banda est-ovest (east-west) e una latenza costante — questo è un requisito per molti casi d’uso di EFA. Un gruppo di posizionamento di tipo spread (spread placement group) impone una distribuzione a livello di host per evitare guasti correlati, ma non migliora la latenza. Per scenari con picchi di traffico ad alto throughput, la famiglia di istanze e il numero di vCPU definiscono le quote di larghezza di banda di rete di base; ad esempio, alcune dimensioni di istanza pubblicizzano fino a 25 Gbps o 100 Gbps, ma l’elaborazione dei pacchetti e gli stack TCP possono diventare dei colli di bottiglia senza ENA/EFA. Quando si progetta un’architettura per migliaia di connessioni TCP simultanee (ad esempio, gRPC su TLS), è consigliabile scegliere tipi di istanza con un’elevata capacità di connessioni simultanee, abilitare ENA e preferire un NLB con target-type=ip per l’indirizzamento diretto dei pod quando si opera in EKS, al fine di evitare colli di bottiglia a livello di node port.
Servizi chiave e configurazione per l’osservabilità e l’applicazione delle policy
Il monitoraggio dello stato della rete e la diagnosi dei colli di bottiglia si basano su una combinazione di VPC Flow Logs, metriche di CloudWatch, Traffic Mirroring e degli analizzatori Reachability Analyzer e Access Analyzer. I VPC Flow Logs forniscono metadati per ogni flusso (IP di origine/destinazione, porte, pacchetti, byte, azione) che è possibile inviare a CloudWatch Logs o S3 e interrogare con CloudWatch Logs Insights per individuare i prefissi a volume elevato o i “top talker” (le fonti di traffico principali). Per l’ispezione a livello di pacchetto in tempo reale, Traffic Mirroring consente di creare una destinazione di mirroring (mirror target) e un filtro, e quindi di creare sessioni (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) per copiare il traffico dalle ENI verso un’appliance di ispezione in esecuzione su EC2 o verso partner AWS Network Packet Broker.
CloudWatch espone le metriche pertinenti per i diversi livelli: metriche delle istanze EC2 come NetworkIn/NetworkOut e NetworkPacketsIn/NetworkPacketsOut, metriche dell’Application Load Balancer sotto AWS/ApplicationELB come RequestCount, ActiveConnectionCount e ClientTLSNegotiationErrorCount, metriche del Network Load Balancer sotto AWS/NetworkELB come ProcessedBytes e NewFlowCount, e metriche di AWS/DirectConnect per l’interfaccia virtuale come BytesIn/BytesOut. Utilizzare CloudWatch Alarms e Contributor Insights sui flow log per rilevare flussi che causano saturazione. Per la convalida dei percorsi e della configurazione, Reachability Analyzer (tramite le API EC2 StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) consente di modellare e testare i percorsi dei pacchetti end-to-end attraverso tabelle di routing, NACL, gruppi di sicurezza e collegamenti VPN/Direct Connect, mentre Network Access Analyzer aiuta a rilevare percorsi di accesso alla rete non intenzionali all’interno dei propri VPC e di AWS Organizations.
Pattern di progettazione e compromessi relativi al bilanciamento del carico e all’accesso sicuro
Quando è necessario un vero TLS end-to-end con TLS reciproco (mutual TLS) sul backend, supportando al contempo migliaia di connessioni gRPC, un Network Load Balancer in modalità TCP è il pattern preferibile. Un NLB preserva l’IP di origine del client per impostazione predefinita e può essere creato dall’AWS Load Balancer Controller per i servizi EKS utilizzando annotazioni come service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" e target-type=ip per inviare il traffico direttamente agli IP dei pod. L’utilizzo del passthrough TCP sulla porta 443 significa che il pod di backend termina il TLS reciproco (verifica dei certificati client e server), quindi il traffico non viene mai decifrato nel bilanciatore del carico, preservando l’autenticazione a due vie. Questo pattern scala bene il numero di connessioni perché l’NLB è progettato per milioni di connessioni simultanee e un basso overhead per connessione.
Per le architetture che richiedono la terminazione TLS a livello del bilanciatore del carico e il routing basato sul percorso (path-based routing) verso più gruppi di destinazione, l’Application Load Balancer è la scelta giusta perché supporta HTTP/2 e gRPC, il routing basato sul percorso e le regole basate sull’host. Per fornire una registrazione accurata dell’IP del client quando l’ALB termina il TLS, assicurarsi che l’applicazione di backend analizzi gli header X-Forwarded-For (l’ALB li inserisce automaticamente) o utilizzare il protocollo PROXY con un NLB se è necessario preservare l’IP di origine a livello TCP. Se si utilizza Global Accelerator per fornire IP front-end statici anycast e si vuole impedire ai client di bypassare l’acceleratore e raggiungere direttamente l’URL dell’ALB, è necessario bloccare il gruppo di sicurezza (security group) dell’ALB per accettare traffico in entrata solo dagli IP statici dell’acceleratore (i due indirizzi statici assegnati all’acceleratore), in modo da negare l’accesso diretto da Internet.
Per servizi condivisi multi-account con controlli rigorosi per business unit e necessità di scalabilità, AWS PrivateLink (VPC Endpoint Services supportati da NLB interni) è spesso il pattern più sicuro e scalabile. Il VPC dei servizi condivisi pubblica i servizi tramite endpoint del Network Load Balancer (aws ec2 create-network-interface con gruppi di destinazione) e li espone come VPC Endpoint Service. Gli account consumer creano endpoint di interfaccia nei loro VPC che si collegano all’NLB del provider; il provider controlla l’accesso tramite policy degli endpoint e gruppi di sicurezza, e il traffico non attraversa mai un piano di routing centralizzato. Transit Gateway è appropriato quando si necessita di piena visibilità del routing e connettività transitiva, ma centralizza il routing ed è meno granulare di PrivateLink per il controllo degli accessi per singolo servizio.
Errori comuni e criteri decisionali
Un errore frequente è presumere che la larghezza di banda pubblicizzata per un’istanza sia illimitata; le famiglie e le dimensioni delle istanze impostano limiti di rete rigidi e lo scaling dovrebbe considerare la suddivisione tra più ENI e il posizionamento in placement group di tipo cluster per ottenere prestazioni costanti. Un’altra trappola è fare affidamento esclusivamente su CloudWatch NetworkIn/NetworkOut senza correlare i VPC Flow Logs per attribuire il traffico a un particolare VPC, sottorete o unità di business; i Flow Logs e il Traffic Mirroring sono necessari per isolare quale interfaccia virtuale o applicazione stia causando la saturazione di Direct Connect. Evitare inoltre di terminare il TLS a livello dell’ALB quando è richiesto il mutual TLS end-to-end: se la policy richiede che il backend veda il certificato del client, scegliere il passthrough TLS con un NLB o eseguire il TLS bridging con una corretta validazione dei certificati, ma essere espliciti su dove viene stabilita la fiducia (trust).
Quando si diagnostica una saturazione intermittente su collegamenti fisici condivisi come Direct Connect, è necessario correlare le metriche tra i vari livelli: le metriche di AWS/DirectConnect per le interfacce virtuali, i VPC Flow Logs per i conteggi di byte per sottorete/ENI e le metriche Network* di EC2 per il comportamento a livello di istanza. Utilizzare Reachability Analyzer per validare se il routing asimmetrico o una propagazione errata delle route stia causando problemi sul percorso di ritorno, e usare Traffic Mirroring per catturare dump di pacchetti per un’ispezione approfondita del protocollo.
Problema Pratico: Scenario d’Uso
AcmeIoT si trova di fronte a un problema in cui distributori automatici in tutto il mondo devono connettersi tramite gRPC con mutual TLS a un backend ospitato su EKS. Le connessioni devono essere nell’ordine delle migliaia, il servizio deve rimanere crittografato end-to-end e i pod del backend scalano dinamicamente con il Cluster Autoscaler e l’HPA.
Creare un AWS LoadBalancer di tipo Network Load Balancer per il servizio Kubernetes, utilizzando l’AWS Load Balancer Controller e le annotazioni per specificare NLB e target-type=ip (service.beta.kubernetes.io/aws-load-balancer-type: “nlb” e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: “ip”). Configurare un listener TCP sulla porta 443 in modo che l’NLB esegua un puro passthrough TCP; non configurare certificati TLS sull’NLB.
Implementare la terminazione e la validazione del mutual TLS nei pod dell’applicazione. Ogni pod dovrebbe presentare un certificato server e validare i certificati client, utilizzando un processo di rotazione dei certificati a breve durata integrato con AWS Secrets Manager o SSM Parameter Store. Assicurarsi che gli IP dei pod siano raggiungibili utilizzando target-type ip e che gli health check siano di tipo TCP o gRPC, configurati sul target group.
Garantire un’elevata scalabilità delle connessioni scegliendo istanze con supporto ENA e larghezza di banda di rete sufficiente, abilitare ENA (verificare la presenza del driver ENA nell’AMI e usare
undefined
per abilitare ena-support dove necessario) e distribuire i pod su più nodi, con il Cluster Autoscaler che scala i nodi in base alle richieste dei pod. Utilizzare i placement group per cluster strettamente accoppiati che necessitano di una latenza costante e distribuire un numero sufficiente di nodi tra le diverse AZ.
- Monitorare e validare utilizzando CloudWatch e VPC Flow Logs. Creare metriche e allarmi CloudWatch per ActiveFlowCount/NewFlowCount dell’NLB e per NetworkIn/Out delle istanze EC2 worker di EKS. Utilizzare i VPC Flow Logs per identificare eventuali “top-talker” (chi genera più traffico) e Reachability Analyzer (
undefined
/
undefined
) per validare i percorsi di routing durante gli eventi di autoscaling. Se è necessario un debug a livello di pacchetto, creare sessioni di Traffic Mirroring verso un’istanza di ispezione.
Logica di AWS: un Network Load Balancer in modalità TCP preserva l’IP di origine, supporta un numero massiccio di connessioni concorrenti e permette il TLS end-to-end perché non termina il TLS. Il target-type ip con l’AWS Load Balancer Controller si integra con la semantica di autoscaling di EKS, così i nuovi IP dei pod vengono registrati dinamicamente come target. ENA e il corretto dimensionamento delle istanze forniscono la capacità di rete grezza per gestire migliaia di connessioni TLS concorrenti senza esaurire la CPU dell’host, e la combinazione di CloudWatch, VPC Flow Logs, Reachability Analyzer e Traffic Mirroring fornisce l’osservabilità necessaria per rilevare e risolvere problemi di saturazione o di routing.
← Distribuzione di Contenuti e Networking Edge · Tutti i domini · Automazione →
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 →