2.2 - Sauvegarde, restauration et reprise après sinistre
L'objectif 2.2 de l'AWS SysOps Administrator couvre la sauvegarde, la restauration et la reprise après sinistre. AWS Backup centralise les plans, les planifications, le cycle de vie vers le stockage froid et la copie inter-régions et inter-comptes, et Backup Vault Lock impose une rétention immuable et conforme. Tu copies les instantanés EBS, RDS et autres entre régions pour la reprise, et Data Lifecycle Manager automatise la création et le nettoyage des instantanés et des AMI. Les stratégies de reprise arbitrent coût et rapidité : backup and restore est le moins cher mais le plus lent, le pilot light ne garde que le cœur, le warm standby garde une copie réduite active pour une bascule plus rapide, et le multi-site actif-actif est le plus rapide et le plus cher - choisis selon le RTO et le RPO. Les contrôles de santé Route 53 avec routage failover basculent le trafic vers un site de secours. Attends-toi à des mises en situation sur la bonne stratégie de reprise.
Sauvegardes immuables et conformes = AWS Backup Vault Lock. Reprise la moins chère/lente = backup and restore ; copie réduite mais active = warm standby. Bascule DNS vers le secours = routage failover Route 53.
Questions d'entraînement
1. Comment un Auto Scaling group ajoute-t-il typiquement des instances en réponse à un CPU élevé et durable ?
- Une alarme CloudWatch déclenche une scaling policy sur le groupe (bonne réponse)
- Le groupe interroge directement l'OS de chaque instance toutes les secondes
- CloudWatch redémarre l'instance la plus chargée pour alléger sa charge
- Le groupe double la capacité selon un horaire fixe, sans tenir compte du CPU
Une alarme CloudWatch sur une métrique comme CPUUtilization invoque une scaling policy, qui demande à l'Auto Scaling group de lancer des instances. Le scheduled scaling existe mais dépend de l'heure, pas du CPU.
2. Quelle métrique CloudWatch indique que l'infrastructure côté AWS (matériel hôte ou réseau) supportant votre instance EC2 est défaillante ?
- StatusCheckFailed_System (bonne réponse)
- StatusCheckFailed_Instance, qui reflète les problèmes d'OS et de configuration
- CPUUtilization dépassant une valeur de seuil statique
- NetworkPacketsIn tombant à zéro pendant un moment
StatusCheckFailed_System signale les défaillances de l'infrastructure gérée par AWS et déclenche une action recover. StatusCheckFailed_Instance reflète des problèmes côté invité que vous devez corriger (un reboot aide souvent).
3. La conformité exige de garder sept ans de logs à bas coût pour d'éventuels audits. Quel stockage long terme est recommandé ?
- Exporter le log group vers Amazon S3 avec un lifecycle vers Glacier (bonne réponse)
- Monter la rétention CloudWatch Logs au maximum et la laisser ainsi
- Copier chaque log stream dans un second log group CloudWatch en backup
- Garder les logs actifs dans CloudWatch Logs et compter sur des copies cross-Region
L'export vers S3 avec transition lifecycle vers Glacier est l'archive durable et bon marché pour une rétention pluriannuelle. Le stockage CloudWatch Logs coûte plus cher pour des données froides, et dupliquer des streams ou garder les logs actifs n'est ni économique ni une stratégie d'archivage.
4. Pour la préparation au DR, quel réglage unique sur un log group contrôle le plus directement l'ancienneté des événements conservés ?
- La clé KMS attachée au log group pour le chiffrement au repos
- Le pattern du subscription filter qui décide des événements exportés
- Le réglage de rétention, qui définit l'âge d'expiration des événements (bonne réponse)
- Le metric filter, qui détermine quelles lignes deviennent des métriques
La rétention définit directement le nombre de jours de conservation avant suppression, le contrôle clé pour l'ancienneté exploitable en DR. KMS gère le chiffrement, les subscription filters routent, et les metric filters créent des métriques, sans régir l'âge des événements.
5. Sur votre dashboard d'exploitation, vous voulez voir l'état rouge/vert de chaque alarme à côté de son graphe. Que faut-il ajouter ?
- Un metric stream alimentant le dashboard en temps réel
- Un widget Contributor Insights listant les plus actifs
- Un widget d'état d'alarme sur le dashboard (bonne réponse)
- Un topic SNS distinct pour chaque alarme affichée
Les dashboards CloudWatch offrent un widget d'état d'alarme affichant l'état OK/ALARM à côté des graphes. Un metric stream exporte des données, Contributor Insights classe des contributeurs, et ajouter des topics SNS envoie des notifications sans afficher l'état.
6. Vous voulez une seule alarme 'service dégradé' qui se déclenche seulement si les alarmes de latence ET d'erreurs sont en ALARM. Quels deux faits s'appliquent ? (Choisir DEUX.)
- Il faut d'abord fusionner les deux métriques en une métrique custom
- Une composite alarm combine des alarmes enfants par une règle (bonne réponse)
- La règle utilise AND, donc les deux enfants doivent être en ALARM (bonne réponse)
- Les composite alarms ne peuvent pas notifier via un topic SNS
Une composite alarm évalue une règle sur des alarmes enfants existantes, et une règle AND ne se déclenche que si les deux enfants sont en ALARM, réduisant le bruit. Nul besoin de fusionner les métriques, et les composite alarms peuvent notifier via SNS.