5.1 - Réseau VPC et connectivité
L'objectif 5.1 de l'AWS SysOps Administrator couvre le réseau VPC et la connectivité. Tu planifies les plages CIDR, tu places des sous-réseaux publics et privés sur plusieurs zones, tu routes avec des tables de routage, tu atteins Internet via une Internet Gateway et tu laisses les sous-réseaux privés sortir par une NAT Gateway gérée et résiliente par zone. Les security groups sont à état au niveau de l'instance et autorisent automatiquement le trafic de retour, tandis que les Network ACL sont sans état au niveau du sous-réseau, ordonnées, et exigent des ports éphémères pour le trafic de retour - un piège de dépannage classique. Les gateway VPC endpoints atteignent S3 et DynamoDB gratuitement tandis que les interface endpoints utilisent PrivateLink pour un accès privé au coût horaire. Pour l'hybride et le multi-VPC tu utilises VPC peering, Transit Gateway, Site-to-Site VPN et Direct Connect. Attends-toi à des mises en situation sur le bon composant VPC ou correctif.
Sous-réseau privé qui atteint Internet = NAT Gateway (gérée, par zone). Les NACL sont sans état et exigent des ports de retour éphémères ; les security groups sont à état. Accès privé gratuit à S3/DynamoDB = gateway VPC endpoint.
Questions d'entraînement
1. Vous devez alarmer quand un Application Load Balancer commence à renvoyer beaucoup d'erreurs 5XX depuis le load balancer lui-même. Quelle métrique convient ?
- HTTPCode_ELB_5XX_Count (bonne réponse)
- HTTPCode_Target_2XX_Count agrégé sur toutes les cibles saines
- RequestCountPerTarget sur l'instance enregistrée la plus chargée
- HealthyHostCount moyenné sur la dernière heure complète de trafic
HTTPCode_ELB_5XX_Count compte les réponses 5XX générées par le load balancer (pas par les cibles), signalant des problèmes côté ALB. Target 2XX compte les succès, et HealthyHostCount suit la santé des cibles, pas les erreurs.
2. Vous diagnostiquez une NAT gateway saturée. Quelles DEUX métriques CloudWatch aident à repérer le goulot d'étranglement ? (Choisissez DEUX réponses.)
- BytesOutToDestination sur la NAT gateway (bonne réponse)
- ErrorPortAllocation, comptant les allocations de port source échouées (bonne réponse)
- CPUUtilization rapportée par l'hôte managé sous-jacent de la NAT gateway
- DiskReadOps sur le volume de stockage managé de la NAT gateway
Les métriques de NAT gateway comme BytesOutToDestination (débit) et ErrorPortAllocation (épuisement de ports) révèlent la saturation. Une NAT gateway est entièrement managée et n'expose ni CPU ni disque, donc ces options sont des pièges.
3. Pour rendre un Auto Scaling group hautement disponible derrière un Application Load Balancer, comment configurer ses sous-réseaux ?
- Un sous-réseau dans une seule AZ
- Des sous-réseaux dans au moins deux AZ (bonne réponse)
- Uniquement des sous-réseaux publics, aucun privé
- Un sous-réseau partagé avec les seuls noeuds ALB
Répartir les instances sur des sous-réseaux dans au moins deux AZ maintient l'app si une AZ tombe, en phase avec le design multi-AZ de l'ALB. Une seule AZ est un point unique de défaillance, et les contraintes tout-public ou partage ALB ne sont pas des exigences de HA.
4. Vous voulez lancer des requêtes Logs Insights directement sur les VPC Flow Logs. Quelle destination choisir ?
- CloudWatch Logs, pour que Insights interroge les enregistrements de flux (bonne réponse)
- Amazon S3, puis charger chaque objet dans Athena avant toute requête
- Kinesis Data Firehose, qui laisse Logs Insights lire la stream en direct
- Un volume EBS attaché à un jump host qui parse les fichiers de flux en local
Envoyer les Flow Logs vers CloudWatch Logs permet de les interroger directement avec Logs Insights. S3 exige Athena au lieu d'Insights, Firehose est une stream de livraison non interrogeable par Insights, et un hôte de parsing EBS n'est pas une option native.
5. Une fonction Lambda s'exécute mais vous ne trouvez aucun log. Quelle exigence n'est probablement pas remplie ?
- La fonction doit être attachée à un VPC avant de pouvoir logger
- Un subscription filter doit exister sinon Lambda n'écrit rien dans les logs
- Le rôle d'exécution n'a pas la permission d'écrire dans CloudWatch Logs (bonne réponse)
- Un metric filter doit d'abord être créé pour que Lambda sache où logger
Lambda écrit dans CloudWatch Logs via son rôle d'exécution ; des logs absents signifient donc souvent que le rôle manque logs:CreateLogGroup/CreateLogStream/PutLogEvents. L'attachement VPC, les subscription filters et les metric filters ne sont pas des prérequis pour logger.
6. Vous devez surveiller la disponibilité d'un site mondial et le parcours utilisateur complet. Quels deux outils contribuent ? (Choisir DEUX.)
- Des Route 53 health checks pour la disponibilité (bonne réponse)
- Un metric filter CloudWatch sur les VPC flow logs du site
- Un Synthetics canary rejouant le parcours d'achat (bonne réponse)
- Une bucket policy S3 limitant les téléchargements
Les Route 53 health checks sondent les endpoints depuis des emplacements mondiaux pour la disponibilité et pilotent le failover DNS, tandis qu'un Synthetics canary valide le parcours multi-étapes. Un metric filter sur flow logs mesure le trafic réseau, et une bucket policy S3 gère l'accès, aucun ne surveillant le parcours.