Les comptes AWS n’échouent pas d’un coup; ils dérivent. Un identifiant que personne n’a tourné, une pile d’instantanés que personne n’a élaguée, une tâche de sauvegarde qui a commencé à échouer en mars et qu’on a remarquée en juin, une facture qui a grimpé de 8 % par mois jusqu’à ce que les finances posent des questions. La liste de contrôle mensuelle est le contrepoids : environ quatre-vingt-dix minutes, une fois aux 30 jours, à parcourir la même liste dans le même ordre et à mettre en billets ce qu’elle trouve. La valeur n’est dans aucune vérification en particulier — c’est que la dérive se fait attraper à un mois d’âge plutôt qu’à un an, quand tout est encore peu coûteux à corriger.
Ce que vous décidez
La vraie décision, c’est ce que « révisé mensuellement » veut dire pour votre compte, parce qu’une revue sans limites n’arrive jamais deux fois. La version disciplinée couvre sept surfaces, chacune avec une question concrète :
- Coûts : la dépense a-t-elle bougé plus que prévu, et peut-on nommer chaque mouvement significatif?
- Capacité et dimensionnement : qu’est-ce qui est surdimensionné, sous-dimensionné ou orphelin?
- Identité : quels accès ne devraient plus exister, et quelles clés sont assez vieilles pour marcher toutes seules?
- Sauvegardes : les tâches ont-elles tourné, et — trimestriellement — une restauration fonctionne-t-elle vraiment?
- Événements côté AWS : que prévoit AWS faire à vos ressources dans les 30 prochains jours?
- Correctifs : quel pourcentage de la flotte est en retard, et quelque chose est-il en retard sur un correctif critique?
- Alarmes : qu’est-ce qui a sonné, qu’est-ce qui était du bruit, et qu’est-ce qui a cessé de rapporter en silence?
Délibérément exclus : revues d’architecture, exercices de reprise et audits de sécurité. C’est du travail trimestriel ou annuel; les entasser dans la passe mensuelle, c’est comme ça que la passe mensuelle meurt.
Quoi vérifier en premier
Si vous n’avez que vingt minutes ce mois-ci, ces quatre attrapent le plus de dégâts :
- Cost Explorer mois sur mois, groupé par service — les anomalies annoncent la plupart des classes de trouble, des tâches emballées jusqu’à la compromission.
- Les échecs de tâches de sauvegarde — la trouvaille dont le coût se compose en silence chaque jour où elle reste invisible.
- Le tableau de bord AWS Health pour les changements planifiés — des échéances que vous n’avez pas fixées, et la seule partie qui les déplace, c’est vous.
- L’âge des identifiants IAM — les vieilles clés sont un risque permanent, et le rapport prend deux minutes.
Comment vérifier
La liste se déroule surtout au CLI, ce qui la rend scriptable en rapport mensuel :
# 1. Coûts : ce mois-ci contre le mois dernier, par service
aws ce get-cost-and-usage \
--time-period Start=2026-06-01,End=2026-07-01 \
--granularity MONTHLY --metrics UnblendedCost \
--group-by Type=DIMENSION,Key=SERVICE
# 2. Orphelins : volumes détachés et IP élastiques non associées
aws ec2 describe-volumes --filters Name=status,Values=available \
--query 'Volumes[].[VolumeId,Size,CreateTime]'
aws ec2 describe-addresses \
--query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]'
# 3. Identité : rapport complet d'identifiants (âge des clés, dernier usage, MFA)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > creds.csv
# 4. Sauvegardes : quelque chose échoue-t-il?
aws backup list-backup-jobs --by-state FAILED \
--by-created-after 2026-06-01T00:00:00Z \
--query 'BackupJobs[].[ResourceArn,CompletionDate,StatusMessage]'
# 5. Côté AWS : maintenance en attente sur les bases de données
aws rds describe-pending-maintenance-actions
# 6. Correctifs : sommaire de conformité SSM
aws ssm list-compliance-summaries \
--query 'ComplianceSummaryItems[?ComplianceType==`Patch`]'Équivalents console quand le visuel est plus rapide : Billing and Cost Management > Cost Explorer pour la courbe de tendance, AWS Backup > Jobs pour les échecs, Systems Manager > Patch Manager > Compliance reporting pour la vue de flotte. Trusted Advisor ajoute des vérifications automatisées dans ces catégories — l’ensemble complet exige un plan de soutien Business ou Enterprise, les vérifications de sécurité de base sont gratuites.
Le plan d’exécution
- Passe de coûts (20 min). Mois sur mois par service; nommez chaque mouvement au-delà d’un seuil que vous fixez (5 % ou un montant fixe). Les mouvements inexpliqués deviennent des billets, pas des haussements d’épaules. Vérifiez la couverture des Savings Plans et RI pendant que vous y êtes — les engagements qui expirent sont la surprise du mois prochain.
- Balayage des orphelins (10 min). Volumes détachés, IP élastiques non associées, instantanés manuels vieillissants, instances arrêtées depuis plus de 30 jours, répartiteurs de charge vides. Détruisez ce qui n’a pas de propriétaire; mettez en billet ce qui pourrait en avoir un.
- Coup d’œil au dimensionnement (10 min). Survolez les recommandations de Compute Optimizer pour les cinq pires cas de sur- et sous-provisionnement. Traitez les évidents; les marginaux peuvent attendre la fin du trimestre.
- Hygiène des identités (15 min). Rapport d’identifiants : clés d’accès de plus de 90 jours, utilisateurs sans activité depuis 90 jours, utilisateurs console sans MFA. Chaque trouvaille est tournée, retirée, ou reçoit une exception écrite.
- Vérification des sauvegardes (10 min). Zéro tâche échouée est la barre de passage; tout échec est un billet le jour même. Une fois par trimestre, cette étape s’étend en un vrai test de restauration — la stratégie de sauvegarde inter-régions couvre à quoi le plan devrait ressembler.
- Health et maintenance (10 min). Événements Health ouverts, changements planifiés, maintenance RDS en attente, et certificats qui expirent d’ici 45 jours. Tout ce qui porte une échéance reçoit un propriétaire et une entrée au calendrier maintenant.
- Revue des alarmes et des correctifs (15 min). Ce qui a sonné ce mois-ci et si c’était actionnable; ce qui est en INSUFFICIENT_DATA alors que ça rapportait avant; quel pourcentage de la flotte est conforme aux correctifs. Le bruit se règle, les trous se mettent en billets.
Terminez en écrivant cinq lignes : date, nombre de trouvailles, billets ouverts, ce qui est reporté, et le chiffre que vous surveillerez le mois prochain. Ce journal est ce qui rend le treizième mois plus facile que le premier — et c’est le dossier de preuves quand un client ou un auditeur demande comment le compte est opéré.
Quand c’est la mauvaise approche
La cadence mensuelle est mauvaise aux deux extrêmes. Une charge unique à faible changement avec deux ingénieurs peut faire ça trimestriellement sans grand risque ajouté — le taux de dérive est plus bas. Un environnement réglementé ou à fort changement a besoin que plusieurs éléments (échecs de sauvegarde, anomalies d’identifiants, correctifs critiques) soient des alertes continues, pas des découvertes mensuelles; la liste devient alors la vérification que l’automatisation fonctionne encore, pas la détection première. Et si les trois dernières revues n’ont rien trouvé, ne célébrez pas — les vérifications sont probablement devenues périmées par rapport à l’évolution du compte.
Erreurs fréquentes
- Faire la revue seulement quand ça sent mauvais, ce qui sélectionne précisément les mois où la dérive s’accumule sans témoin.
- Réviser sans mettre en billets — des trouvailles notées dans un document et corrigées jamais. Le produit de la revue, ce sont des billets, ou c’est du théâtre.
- Laisser la liste grossir jusqu’à prendre une demi-journée, après quoi elle cesse discrètement d’exister.
- Une seule personne propriétaire pour toujours : la revue meurt avec son départ, et ses angles morts deviennent ceux du compte.
Garder le contrôle
- Un bloc de calendrier récurrent, première semaine du mois, traité comme une rencontre client.
- Scripter la collecte de données pour que les quatre-vingt-dix minutes aillent au jugement, pas au copier-coller dans un chiffrier.
- Faire tourner le réviseur aux quelques mois; des yeux frais trouvent ce que les habitués ont normalisé.
- Suivre les trouvailles-par-mois comme tendance — en hausse, le compte a besoin de plus d’automatisation; vers zéro, les vérifications ont besoin d’être rafraîchies.
La liste est simple; la discipline de la faire aux 30 jours est la partie que les organisations ratent de façon fiable. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.