5.2 - DNS, diffusion de contenu et dépannage réseau
L'objectif 5.2 de l'AWS SysOps Administrator couvre le DNS, la diffusion de contenu et le dépannage réseau. Dans Amazon Route 53 tu choisis une politique de routage - simple, pondérée, par latence, failover, géolocalisation, géoproximité ou multivalue - tu utilises un enregistrement alias pour pointer l'apex de zone vers une cible CloudFront ou S3, et tu pilotes le failover DNS avec des contrôles de santé. Amazon CloudFront met le contenu en cache aux emplacements périphériques, verrouille l'origine S3 avec Origin Access Control, sert du contenu privé avec des URL ou cookies signés, et ajoute HTTPS avec un certificat ACM dans us-east-1 ; AWS Global Accelerator fournit des IP anycast statiques pour le trafic non HTTP. Pour dépanner la connectivité tu lis les VPC Flow Logs pour voir ACCEPT ou REJECT et si un security group ou une NACL a bloqué le trafic, et tu utilises Reachability Analyzer. Attends-toi à des mises en situation sur la bonne fonctionnalité réseau ou le bon diagnostic.
Pointer l'apex de zone vers CloudFront/S3 = enregistrement alias Route 53. Verrouiller l'origine S3 de CloudFront = Origin Access Control. Voir ce qui a bloqué le trafic (ACCEPT/REJECT) = VPC Flow Logs.
Questions d'entraînement
1. Vous voulez surveiller le taux de cache hit et le taux d'erreur d'une distribution CloudFront dans CloudWatch. Dans quelle région les métriques par défaut de CloudFront sont-elles publiées ?
- US East (Virginie du Nord), us-east-1 (bonne réponse)
- La région de l'edge location la plus proche de chaque requête utilisateur
- Chaque région AWS où au moins un cache hit s'est produit
- La région du bucket S3 ou du load balancer d'origine
CloudFront est un service global et publie ses métriques CloudWatch dans us-east-1, donc vous les consultez et créez les alarmes là-bas. Les métriques ne sont pas dispersées par edge ou par origine.
2. Vous voulez que CloudWatch alarme quand un Route 53 health check signale un point de terminaison comme unhealthy. Dans quelle région les métriques de health check Route 53 sont-elles disponibles ?
- US East (Virginie du Nord), us-east-1 (bonne réponse)
- La région qui héberge les ressources principales du point de terminaison
- Une région aléatoire choisie à la création du health check
- Toutes les régions simultanément via une réplication globale
Route 53 est un service global et ses métriques de health check (HealthCheckStatus, etc.) ne sont publiées que dans us-east-1, où vous créez l'alarme. Elles ne sont pas répliquées dans chaque région.
3. Vous attachez un target group à un Auto Scaling group. Comment les instances nouvellement lancées reçoivent-elles du trafic du load balancer ?
- Vous devez enregistrer chaque instance à la main
- Elles reçoivent du trafic seulement après un instance refresh
- Auto Scaling les enregistre automatiquement (bonne réponse)
- Un enregistrement Route 53 doit être édité à chaque fois
Quand un target group est attaché, Auto Scaling enregistre chaque nouvelle instance et désenregistre celles terminées automatiquement. Un enregistrement manuel, un refresh ou des édits Route 53 ne sont pas nécessaires pour cette intégration.
4. Les access logs CloudFront sont nécessaires pour de l'alerting quasi temps réel sur les taux d'erreur. Quel pipeline convient le mieux ?
- Logs CloudFront standard vers S3, puis un batch nocturne les parcourt
- Logs CloudFront real-time vers Kinesis Data Streams, puis un consommateur alerte (bonne réponse)
- Activer l'agent CloudWatch directement sur les edge locations CloudFront
- Faire passer les logs CloudFront par le Route 53 query logging pour l'immédiateté
Les logs real-time CloudFront streament vers Kinesis Data Streams où un consommateur (Lambda/analytics) peut alerter en quelques secondes. Les logs S3 standard sont différés et par lots, on ne met pas d'agent sur les edge locations, et le Route 53 query logging n'a aucun rapport.
5. Un canary doit tester une API interne sans IP publique, joignable uniquement dans un VPC. Que faut-il configurer ?
- Attribuer une adresse Elastic IP publique à l'API interne exposée
- Exécuter le canary dans le VPC avec subnets et security group (bonne réponse)
- Exposer l'API à internet via une internet gateway
- Désactiver le canary et se fier aux logs côté serveur
Un canary peut être configuré pour s'exécuter dans le VPC en attachant des subnets et un security group, atteignant ainsi des endpoints privés sans les exposer. Donner une IP publique à l'API ou une internet gateway casse le design privé, et désactiver le canary abandonne le test proactif.
6. Un canary attaché au VPC dans des subnets privés doit aussi joindre une URL HTTPS externe. Qu'active cette sortie ?
- Une NAT gateway avec une route depuis les subnets privés (bonne réponse)
- Une IP publique attribuée directement à la fonction canary
- Un appairage VPC vers le site web externe
- Un gateway endpoint S3 ajouté à la route table
Un canary dans des subnets privés atteint internet via une NAT gateway, la route table des subnets pointant 0.0.0.0/0 vers elle. Les canaries basés sur Lambda ne prennent pas d'IP publique directe, l'appairage VPC relie des VPC et non un site quelconque, et un gateway endpoint S3 ne joint que S3.