Amazon ANS-C01: DNS et Route 53 — Guide d'étude

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Fait partie du AWS Advanced Networking Specialty ANS-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Concept de base

Le DNS est le liant entre les noms conviviaux pour les humains et les points de terminaison distribués, mais dans AWS, il devient un plan de contrôle actif pour le routage basé sur la latence, le basculement tenant compte de l’état de santé et la résolution de noms privés multi-comptes. Amazon Route 53 prend en charge le DNS public faisant autorité via des zones hébergées publiques et le DNS privé pour la résolution au niveau du VPC via des zones hébergées privées. Les zones hébergées privées sont associées à un ou plusieurs VPC et ne renvoient des réponses que pour les requêtes provenant de ces VPC ou via les points de terminaison entrants de Route 53 Resolver. Ce comportement de type split-horizon — avoir des réponses différentes pour le même nom en fonction de la source — vous permet d’exposer un point de terminaison public pour les clients Internet tout en résolvant le même nom en adresses IP privées au sein de vos VPC.

Route 53 intègre également une logique de décision de routage et des bilans de santé actifs dans le DNS. Les stratégies de routage incluent Simple, Weighted, Latency, Failover (primaire/secondaire), Geolocation et Multi-Value Answer, ainsi que Traffic Flow (géoproximité et flux complexes). Les bilans de santé créés avec

undefined

permettent à Route 53 de supprimer les points de terminaison défaillants des réponses DNS ou de piloter les jeux d’enregistrements de basculement ; les bilans de santé sont configurables avec les champs

undefined

tels que Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval et FailureThreshold. Comme le DNS est mis en cache par les résolveurs et les clients, le TTL de Route 53 et les interrogations fréquentes des bilans de santé (minimum 10 secondes sous certaines conditions) doivent être équilibrés avec le comportement de propagation DNS pour les changements de routage pondéré et de basculement.

Services et configuration clés

Lors de l’exposition de ressources AWS, utilisez des enregistrements Alias pour pointer le DNS directement vers les ressources AWS lorsque cela est pris en charge, évitant ainsi les sauts supplémentaires ou les CNAME. Les enregistrements Alias utilisent un AliasTarget qui référence l’ID de la zone hébergée et le nom DNS de la ressource AWS (par exemple, un Elastic Load Balancer, un domaine personnalisé API Gateway, une distribution CloudFront ou un point de terminaison de site web S3). La création ou la modification d’enregistrements se fait via l’API

undefined

; pour les flux de travail programmatiques, utilisez

undefined

avec les actions

undefined

pour l’identification de la stratégie de routage. Pour le basculement (failover), vous créez deux enregistrements avec le même nom et Failover défini sur PRIMARY et SECONDARY, chacun référençant un bilan de santé via

undefined

que vous créez avec

undefined

Pour la résolution DNS inter-comptes et hybride, Route 53 Resolver fournit des points de terminaison entrants et sortants créés avec

undefined

. Un point de terminaison entrant permet aux résolveurs sur site (on-premises) de transférer les requêtes vers les VPC (utile pour résoudre les zones hébergées privées), tandis qu’un point de terminaison sortant permet aux ressources du VPC de transférer les requêtes vers des serveurs DNS sur site ou d’autres résolveurs. Les règles de résolveur (

undefined

) vous permettent de transférer les requêtes pour des domaines spécifiques vers des adresses IP, et vous associez les règles aux VPC en utilisant

undefined

. Pour une architecture DNS centrale, vous pouvez créer des règles de transfert dans un compte central et utiliser

undefined

avec les VPC d’autres comptes, en utilisant éventuellement AWS Resource Access Manager (RAM) et

undefined

pour contrôler les associations.

Route 53 Resolver DNS Firewall fournit un filtrage et une journalisation basés sur les domaines. Vous créez des listes de domaines avec

undefined

, des groupes de règles avec

undefined

, puis vous utilisez

undefined

pour les associer aux VPC afin d’appliquer les règles. Les règles du pare-feu peuvent

undefined

(bloquer),

undefined

(autoriser) ou

undefined

(réécrire) les réponses, et vous pouvez journaliser les évaluations dans CloudWatch Logs ou S3. Utilisez

undefined

pour la gestion et pour appliquer des règles priorisées, notamment pour limiter l’exfiltration via le DNS ou pour bloquer les domaines malveillants depuis les ressources attachées au VPC.

Patrons de conception et compromis

Pour les services hautement disponibles et distribués mondialement, utilisez le routage basé sur la latence ou la géolocalisation pour diriger les clients vers le point de terminaison sain le plus proche, associé à des bilans de santé pour supprimer les points de terminaison régionaux défaillants. Le routage par latence dépend des tables de latence régionales de Route 53 et convient aux conceptions multi-régions actif-actif ; le routage par basculement (failover) est plus adapté à la reprise après sinistre actif-passif où une seule région doit recevoir du trafic à la fois. Le routage pondéré (weighted) prend en charge les basculements de trafic progressifs (déploiements blue-green ou canary) en attribuant des valeurs de poids aux enregistrements et en les modifiant avec

undefined

. Le routage à réponses multiples (multi-value answer) peut renvoyer plusieurs adresses IP pour la répartition de charge côté client et nécessite des bilans de santé pour garantir que seules les adresses IP saines sont retournées.

Les zones hébergées privées et les points de terminaison de résolveur sont les modèles canoniques pour la résolution de noms multi-comptes et multi-VPC. Pour de nombreuses unités commerciales, un VPC de services partagés central hébergeant des zones hébergées privées ou des points de terminaison de résolveur simplifie la gestion : créez une zone hébergée privée et utilisez

undefined

pour attacher les VPC de service, ou exécutez des points de terminaison entrants/sortants et des règles de transfert Route 53 Resolver pour que chaque compte conserve l’isolement de son VPC tout en s’appuyant sur une politique DNS centrale. Le compromis est que les zones hébergées privées associées à de nombreux VPC compliquent l’IAM et le contrôle des changements, et les associations inter-comptes nécessitent une étape d’autorisation. Le transfert via le résolveur introduit une surcharge opérationnelle centrale mais s’adapte bien (scales) car vous n’avez pas besoin d’associer chaque VPC directement à chaque zone hébergée ; à la place, vous associez des règles de résolveur.

Lorsque vous imposez des chemins d’accès stricts — comme exiger que le trafic passe uniquement par Global Accelerator — vous devez concevoir les groupes de sécurité et les contrôles réseau pour qu’ils correspondent au DNS. Route 53 peut pointer vers Global Accelerator en créant des enregistrements A avec les adresses IP statiques de l’accélérateur ou en utilisant des CNAME vers un domaine géré par l’accélérateur, mais l’application des règles se fait au niveau du groupe de sécurité de l’ALB et de la couche ACL réseau. Le groupe de sécurité de l’ALB ne doit autoriser le trafic entrant (ingress) que depuis les adresses IP statiques de Global Accelerator ; Global Accelerator garantit que ces adresses IP statiques seront la source du trafic entrant, donc la limitation du trafic entrant préserve l’exigence d’un accès uniquement via l’accélérateur.

Pièges courants et critères de décision

Un piège typique est de supposer que les bilans de santé (health checks) de Route 53 suppriment instantanément les points de terminaison ; la mise en cache DNS (TTL) et le comportement du résolveur client signifient que le basculement n’est pas instantané. Maintenez des TTL bas pour les noms de domaine critiques nécessitant un basculement, mais n’oubliez pas que des TTL plus faibles augmentent le volume de requêtes et les coûts. Une autre erreur courante est de dupliquer des noms entre des zones hébergées publiques et privées sans comprendre les associations de VPC : une zone hébergée privée portant le même nom qu’une zone hébergée publique masquera les réponses publiques pour les requêtes provenant des VPC associés, ce qui est généralement souhaitable pour le split-horizon mais peut être surprenant si ce n’est pas documenté.

Choisissez soigneusement entre les enregistrements Alias et CNAME : les enregistrements Alias pour ELB et CloudFront sont préférables car ils évitent les recherches DNS supplémentaires et sont pris en charge par la logique de propagation des changements de Route 53, mais ils sont liés aux ID de zone hébergée des ressources AWS et ne peuvent pas être utilisés pour des points de terminaison externes arbitraires. Lors de la conception d’un DNS inter-comptes, préférez les règles et les points de terminaison du résolveur à l’association directe de nombreux VPC à une seule zone hébergée privée lorsque l’échelle ou les frontières administratives sont des préoccupations ; les règles du résolveur offrent un contrôle plus granulaire et sont plus faciles à auditer avec CloudTrail.

Problème pratique : Scénario d’utilisation

Entreprise : NimbusPay — défi : Fournir des services gRPC sécurisés à faible latence sur TLS avec authentification TLS mutuelle (mTLS) à un backend EKS, imposer l’accès au front-end web uniquement via Global Accelerator, et permettre à plusieurs VPC d’unités commerciales réparties sur plusieurs comptes de consommer des services de données partagés avec des contrôles DNS centralisés.

Pour le service gRPC nécessitant un chiffrement TLS de bout en bout avec authentification mutuelle et des milliers de connexions simultanées, déployez un Network Load Balancer (NLB) avec des écouteurs TCP sur le port 443 en utilisant le type de cible ip afin que les adresses IP des pods soient enregistrées directement. Configurez les annotations de l’AWS Load Balancer Controller

undefined

et définissez le protocole du groupe cible sur TCP ; ne terminez pas la connexion TLS au niveau du NLB (pas d’écouteur TLS) afin que l’authentification TLS mutuelle soit transmise aux conteneurs des pods où les certificats de serveur et la vérification des certificats clients sont appliqués. Utilisez des enregistrements A (Alias) de Route 53 pointant vers le NLB via

undefined

; préférez des TTL bas uniquement si vous avez besoin d’un basculement rapide, sinon conservez un TTL conservateur pour la stabilité du DNS.

Pour garantir que l’ALB du front-end web n’accepte que le trafic provenant de Global Accelerator, provisionnez un accélérateur et attribuez ses deux adresses IP statiques à NimbusPay. Configurez les enregistrements publics de Route 53 pour résoudre le nom public vers les adresses IP de l’accélérateur (enregistrements A avec les IP statiques). Sur l’ALB, définissez les règles d’entrée (ingress) du groupe de sécurité pour n’autoriser que ces adresses IP statiques et fermez 0.0.0.0/0. Cela garantit que seul le trafic arrivant des adresses IP statiques de l’accélérateur peut atteindre l’ALB. Utilisez CloudWatch Logs et VPC Flow Logs pour valider les adresses IP sources entrantes et pour auditer que le trafic non-accélérateur est bloqué.
Pour les multiples VPC d’unités commerciales répartis sur plusieurs comptes ayant besoin d’accéder à des services partagés, déployez une paire de points de terminaison (endpoints) entrants/sortants Route 53 Resolver dans le compte des services partagés en utilisant

undefined

et placez les points de terminaison dans des sous-réseaux privés. Créez des règles de transfert (

undefined

) dans le compte partagé pour les domaines de service partagés et partagez les règles en utilisant AWS RAM ou utilisez

undefined

pour autoriser les associations. Chaque unité commerciale associe la règle du résolveur à ses VPC (

undefined

), permettant la résolution de noms sans attacher directement tous les VPC à des zones hébergées privées. Pour des contrôles sensibles, attachez des groupes de règles Route 53 Resolver DNS Firewall (

undefined

) au VPC partagé pour bloquer l’exfiltration de données non désirée ou pour appliquer des listes de domaines autorisés (allowlists). La justification : le passthrough TCP du NLB préserve l’authentification TLS mutuelle et s’adapte à de nombreuses connexions simultanées, la restriction de l’entrée de l’ALB aux adresses IP statiques de Global Accelerator impose un accès unique via l’accélérateur, et les points de terminaison du résolveur avec des règles gérées de manière centralisée permettent de faire évoluer la résolution DNS entre les comptes tout en préservant les limites IAM et l’audit par compte.

← Transit Gateway et topologie réseau · Tous les domaines · Équilibrage de charge et gestion du trafic →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →