Amazon ANS-C01: DNS e Route 53 — 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.
Concetto fondamentale
Il DNS è il collante tra i nomi intuitivi per l’uomo e gli endpoint distribuiti, ma in AWS diventa un piano di controllo attivo per il routing basato sulla latenza, il failover basato sullo stato di salute e la risoluzione di nomi privati multi-account. Amazon Route 53 supporta il DNS pubblico autoritativo tramite hosted zone pubbliche e il DNS privato per la risoluzione con scope a livello di VPC tramite hosted zone private. Le hosted zone private sono associate a uno o più VPC e restituiscono risposte solo per le query provenienti da tali VPC o tramite gli endpoint in ingresso di Route 53 Resolver. Questo comportamento split-horizon — ovvero fornire risposte diverse per lo stesso nome a seconda dell’origine — consente di esporre un endpoint pubblico per i client Internet, risolvendo al contempo lo stesso nome in indirizzi IP privati all’interno dei propri VPC.
Route 53 integra inoltre nel DNS la logica decisionale di routing e gli health check attivi. Le policy di routing includono Semplice (Simple), Ponderata (Weighted), Basata sulla latenza (Latency), Failover (primario/secondario), Geolocalizzazione (Geolocation), Risposta multivalore (Multi-Value Answer) e Flusso di traffico (Traffic Flow, per geoproximity e flussi complessi). Gli health check creati con CreateHealthCheck permettono a Route 53 di rimuovere gli endpoint non integri dalle risposte DNS o di pilotare i record set di failover; gli health check sono configurabili con i campi di HealthCheckConfig come Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval e FailureThreshold. Poiché il DNS viene memorizzato nella cache da resolver e client, il TTL di Route 53 e il polling frequente degli health check (minimo 10 secondi in configurazioni specifiche) devono essere bilanciati con il comportamento di propagazione del DNS per le modifiche di failover e di routing ponderato.
Servizi e configurazioni chiave
Quando si espongono risorse AWS, utilizzare i record Alias per puntare il DNS direttamente alle risorse AWS, dove supportato, evitando hop aggiuntivi o CNAME. I record Alias utilizzano un AliasTarget che fa riferimento all’ID della hosted zone e al nome DNS della risorsa AWS (ad esempio, un Elastic Load Balancer, un dominio personalizzato di API Gateway, una distribuzione CloudFront o un endpoint di sito web S3). La creazione o la modifica dei record avviene tramite l’API ChangeResourceRecordSets; per i flussi di lavoro programmatici, utilizzare ChangeBatch con le azioni UPSERT/DELETE e SetIdentifier per l’identificazione della policy di routing. Per il failover, si creano due record con lo stesso nome e Failover impostato su PRIMARY e SECONDARY, ciascuno dei quali fa riferimento a un health check tramite HealthCheckId, creato con CreateHealthCheck.
Per la risoluzione DNS ibrida e cross-account, Route 53 Resolver fornisce endpoint in ingresso (inbound) e in uscita (outbound) creati con CreateResolverEndpoint. Un endpoint in ingresso permette ai resolver on-premise di inoltrare le query ai VPC (utile per risolvere le hosted zone private), mentre un endpoint in uscita consente alle risorse del VPC di inoltrare le query a server DNS on-premise o ad altri resolver. Le regole del resolver (CreateResolverRule) consentono di inoltrare le query per domini specifici a indirizzi IP, e si associano le regole ai VPC utilizzando AssociateResolverRule. Per un’architettura DNS centralizzata, è possibile creare regole di inoltro (forwarding rules) in un account centrale e usare AssociateResolverRule con i VPC di altri account, utilizzando opzionalmente AWS Resource Access Manager (RAM) e PutResolverRulePolicy per controllare le associazioni.
Route 53 Resolver DNS Firewall fornisce funzionalità di filtraggio e logging basate sui domini. Si creano liste di domini con CreateFirewallDomainList, gruppi di regole con CreateFirewallRuleGroup e poi si associa il gruppo di regole ai VPC con AssociateFirewallRuleGroup per applicare le regole. Le regole del firewall possono bloccare (BLOCK), consentire (ALLOW) o sovrascrivere (OVERWRITE) le risposte, ed è possibile registrare le valutazioni su CloudWatch Logs o S3. Utilizzare CreateFirewallRule e PutFirewallRuleGroupPolicy per la gestione e per applicare regole con priorità, specialmente per limitare l’esfiltrazione di dati tramite DNS o per bloccare domini malevoli dalle risorse collegate al VPC.
Pattern di progettazione e compromessi
Per servizi ad alta disponibilità distribuiti a livello globale, utilizzare il routing basato sulla latenza o sulla geolocalizzazione per indirizzare i client all’endpoint integro più vicino, abbinandolo a health check per rimuovere gli endpoint regionali non integri. Il routing basato sulla latenza dipende dalle tabelle di latenza regionali di Route 53 ed è adatto a design multi-regione di tipo attivo-attivo; il routing di failover è più indicato per il disaster recovery di tipo attivo-passivo, dove solo una regione alla volta dovrebbe ricevere traffico. Il routing ponderato supporta spostamenti graduali del traffico (deployment blue-green o canary) assegnando valori di peso ai record e modificandoli con ChangeResourceRecordSets. Il routing con risposta multivalore può restituire più indirizzi IP per la distribuzione del carico lato client e richiede health check per garantire che vengano restituiti solo gli IP integri.
Le hosted zone private e gli endpoint del resolver sono i pattern canonici per la risoluzione dei nomi in ambienti multi-account e multi-VPC. Per organizzazioni con molte business unit, un VPC centrale di servizi condivisi che ospita hosted zone private o endpoint del resolver semplifica la gestione: si crea una hosted zone privata e si utilizza AssociateVPCWithHostedZone per collegare i VPC dei servizi, oppure si implementano endpoint di Route 53 Resolver in uscita/ingresso e regole di inoltro, in modo che ogni account mantenga l’isolamento del proprio VPC pur affidandosi a una policy DNS centrale. Il compromesso è che le hosted zone private associate a molti VPC complicano la gestione di IAM e il controllo delle modifiche, e le associazioni cross-account richiedono un passaggio di autorizzazione. L’inoltro tramite resolver introduce un overhead operativo centrale ma è scalabile, poiché non è necessario associare ogni VPC direttamente a ogni hosted zone; si associano invece le regole del resolver.
Quando si impongono percorsi di accesso rigorosi — come richiedere che il traffico fluisca solo tramite Global Accelerator — è necessario progettare i security group e i controlli di rete in modo che corrispondano al DNS. Route 53 può puntare a Global Accelerator creando record A con gli indirizzi IP statici dell’accelerator o utilizzando CNAME verso un dominio gestito dall’accelerator, ma l’applicazione delle regole (enforcement) avviene a livello di security group dell’ALB e di network ACL. Il security group dell’ALB dovrebbe consentire il traffico in ingresso solo dagli indirizzi IP statici di Global Accelerator; Global Accelerator garantisce che tali IP statici saranno l’origine del traffico in entrata, quindi limitare l’ingresso preserva il requisito di accesso esclusivo tramite l’accelerator.
Insidie comuni e criteri decisionali
Un’insidia tipica è presumere che gli health check di Route 53 rimuovano istantaneamente gli endpoint; la cache DNS (TTL) e il comportamento del resolver del client fanno sì che il failover non sia istantaneo. Mantenete i TTL bassi per i nomi critici soggetti a failover, ma ricordate che TTL più bassi aumentano il volume delle query e i costi. Un altro errore comune è duplicare i nomi tra zone ospitate pubbliche e private senza comprendere le associazioni dei VPC: una zona ospitata privata con lo stesso nome di una pubblica maschererà (shadowing) le risposte pubbliche per le query provenienti dai VPC associati, il che è solitamente desiderabile per lo split-horizon ma può sorprendere se non documentato.
Scegliete attentamente tra record Alias e CNAME: i record Alias per ELB e CloudFront sono preferibili perché evitano lookup DNS aggiuntivi e sono supportati dalla logica di propagazione delle modifiche di Route 53, ma sono legati agli ID delle zone ospitate delle risorse AWS e non possono essere utilizzati per endpoint esterni arbitrari. Quando si progetta un DNS cross-account, preferite le regole e gli endpoint del resolver piuttosto che associare direttamente molti VPC a una singola zona ospitata privata quando la scalabilità o i confini amministrativi sono una preoccupazione; le regole del resolver offrono un controllo più granulare e sono più facili da auditare con CloudTrail.
Problema pratico: scenario d’uso
Azienda: NimbusPay — sfida: Fornire servizi gRPC sicuri e a bassa latenza su TLS con TLS reciproco a un backend EKS, imporre l’accesso al front-end web solo tramite Global Accelerator e consentire a più VPC di diverse business unit e account di utilizzare servizi dati condivisi con controlli DNS centralizzati.
- Per il servizio gRPC che richiede TLS end-to-end con autenticazione reciproca e migliaia di connessioni simultanee, distribuire un Network Load Balancer (NLB) con listener TCP sulla porta 443 utilizzando il tipo di target
ipin modo che gli IP dei pod vengano registrati direttamente. Configurare le annotazioni dell’AWS Load Balancer Controller
undefined
e impostare il protocollo del target group su TCP; non terminare il TLS a livello di NLB (nessun listener TLS) in modo che il TLS reciproco venga passato (passthrough) ai container dei pod dove vengono applicati i certificati del server e la verifica del certificato del client. Utilizzare record A di Route 53 (Alias) che puntano all’NLB tramite ChangeResourceRecordSets; preferire TTL bassi solo se è necessario un failover rapido, altrimenti mantenere un TTL conservativo per la stabilità del DNS.
Per garantire che l’ALB del front-end web accetti traffico solo da Global Accelerator, effettuare il provisioning di un acceleratore e assegnare i suoi due indirizzi IP statici a NimbusPay. Configurare i record pubblici di Route 53 per risolvere il nome pubblico negli IP dell’acceleratore (record A con gli IP statici). Sull’ALB, impostare le regole di ingresso (ingress) del security group per consentire solo quegli indirizzi IP statici e chiudere
0.0.0.0/0. Questo impone che solo il traffico proveniente dagli IP statici dell’acceleratore possa raggiungere l’ALB. Utilizzare CloudWatch Logs e VPC Flow Logs per convalidare gli IP di origine in entrata e per verificare che il traffico non proveniente dall’acceleratore sia bloccato.Per più VPC di diverse business unit e account che necessitano di accedere a servizi condivisi, distribuire una coppia di endpoint di Route 53 Resolver (outbound/inbound) nell’account dei servizi condivisi utilizzando
CreateResolverEndpointe posizionare gli endpoint in subnet private. Creare regole di inoltro (forwarding) (CreateResolverRule) nell’account condiviso per i domini dei servizi condivisi e condividere le regole utilizzando AWS RAM o usarePutResolverRulePolicyper consentire le associazioni. Ogni business unit associa la regola del resolver ai propri VPC (AssociateResolverRule), abilitando la risoluzione dei nomi senza collegare direttamente tutti i VPC alle zone ospitate private. Per controlli sensibili, collegare gruppi di regole di Route 53 Resolver DNS Firewall (CreateFirewallRuleGroupeAssociateFirewallRuleGroup) al VPC condiviso per bloccare l’esfiltrazione di dati indesiderata o per applicare allowlist di domini. La logica: il passthrough TCP dell’NLB preserva il TLS reciproco e scala a molte connessioni simultanee, la restrizione dell’ingresso dell’ALB agli IP statici di Global Accelerator impone l’accesso solo tramite l’acceleratore, e gli endpoint del resolver con regole gestite centralmente scalano la risoluzione DNS tra più account preservando i confini IAM e l’auditing per singolo account.
← Transit Gateway e Topologia di Rete · Tutti i domini · Bilanciamento del Carico e Gestione del Traffico →
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 →