Ce qu'une revue d'architecture AWS trouve vraiment : les défaillances récurrentes des comptes réels

D’un compte AWS réel à l’autre, une revue d’architecture trouve toujours les mêmes huit problèmes, et presque aucun n’est exotique : une base de données sans instance de secours, une seule passerelle NAT qui porte toute la sortie, des sauvegardes qui existent mais n’ont jamais été restaurées, des utilisateurs IAM avec des clés plus vieilles que les stagiaires, des groupes de sécurité ouverts sur le monde, des alarmes branchées sur une boîte de courriels que personne ne lit, aucune imputabilité sur les coûts, et une infrastructure qui n’existe que sous forme de clics dans la console. Si vous voulez savoir ce qu’une revue de votre compte dirait, cette liste en couvre l’essentiel — et une bonne partie se vérifie en un après-midi.

Ce que vous décidez

Une revue d’architecture est une décision sur l’affectation d’un temps d’ingénierie limité : lesquelles des faiblesses du compte vont réellement faire mal, dans quel ordre, et combien coûte chaque correction. Le livrable qui compte n’est pas un document de 60 pages — c’est une courte liste de constats classés, avec un scénario de défaillance attaché à chacun (« si la zone us-east-1a se dégrade, la base de données est hors service le temps d’une restauration; dernière restauration vérifiée : jamais »). Une revue sans scénarios de défaillance est un artéfact de conformité. Une revue avec, c’est un plan de travail.

Il vaut la peine d’être honnête sur ce qu’une revue n’est pas. Elle n’améliore pas l’environnement par elle-même; les constats non corrigés vieillissent comme des problèmes dentaires non traités. Et elle reflète un moment précis — les comptes dérivent en quelques mois à mesure que l’équipe livre. La valeur est de forcer des décisions explicites : chaque constat est corrigé, planifié, ou accepté par écrit. Le risque silencieux devient un risque choisi, et c’est ça, la vraie amélioration.

Quoi vérifier en premier

Les cinq constats les plus fréquents, classés grossièrement selon la gravité de leur fin :

• Base de données mono-AZ. RDS sans Multi-AZ, ou une base autogérée sur une seule instance EC2. Un événement de zone ou une instance qui plante, et l’entreprise est arrêtée pour la durée d’une restauration.
• Sauvegardes jamais testées. Les instantanés existent; personne n’en a jamais restauré un, chronométré la restauration, ou vérifié que l’application démarre dessus.
• Une seule passerelle NAT. Chaque sous-réseau privé route sa sortie par un seul NAT dans une seule zone — un problème de zone devient une panne de tout l’environnement.
• Prolifération IAM. Des utilisateurs humains avec des clés d’accès à longue durée de vie, AdministratorAccess attaché largement, aucune exigence de MFA, des clés inutilisées depuis des mois mais toujours actives.
• Des alarmes qui n’avisent personne. Des alarmes CloudWatch qui tirent dans un sujet SNS sans abonnés, ou vers un alias de courriel dont personne n’est responsable.

Comment vérifier

La plupart des grands constats tombent avec une poignée de commandes :

# Bases de données sans instance de secours
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,DBInstanceClass]' --output table

# Combien de passerelles NAT, et dans quelles zones?
aws ec2 describe-nat-gateways \
  --query 'NatGateways[].[NatGatewayId,SubnetId,State]' --output table

# Groupes de sécurité ouverts sur Internet
aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].[GroupId,GroupName]' --output table

# Hygiène des identifiants IAM : âge et dernier usage de chaque clé
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d

# Les sujets d'alarmes ont-ils le moindre abonné?
aws sns list-subscriptions --query 'Subscriptions[].[TopicArn,Protocol,Endpoint]' --output table

# Une restauration a-t-elle déjà roulé?
aws backup list-restore-jobs \
  --query 'RestoreJobs[].[CreationDate,Status]' --output table

Dans la console, Trusted Advisor (les vérifications varient selon le plan de soutien — voyez https://aws.amazon.com/premiumsupport/) et Security Hub > Findings feront ressortir une partie de tout ça automatiquement s’ils sont activés — leur activation est en soi un constat.

La démarche

Une revue qui vaut son prix, ou qui vaut la peine d’être menée à l’interne, avance en six passes :

1. Passe de fiabilité. Les points de défaillance uniques : dépôts de données mono-AZ, NAT unique, instance seule sans répartiteur de charge, vérifications de santé qui testent le TCP au lieu de l’application. La logique de décision de Multi-AZ ou multi-région est la référence pour la couche de données.
2. Passe de protection des données. La couverture des sauvegardes contre un inventaire réel, la rétention contre les obligations déclarées, au moins une restauration chronométrée, et le chiffrement au repos pour les dépôts qui l’exigent.
3. Passe de sécurité. Le rapport d’identifiants IAM, l’usage du compte racine et son MFA, l’exposition publique (groupes de sécurité, politiques de compartiments S3), et l’activation de CloudTrail et GuardDuty dans toutes les régions.
4. Passe d’observabilité. Qu’est-ce qui réveillerait un humain aujourd’hui si le disque de la base de données principale se remplissait? Parcourez de vrais scénarios de défaillance contre les alarmes existantes et trouvez les silencieuses.
5. Passe de coûts. L’utilisation contre la capacité provisionnée, les ressources orphelines, la couverture d’engagements, et la présence d’une revue mensuelle de la facture.
6. Classer et décider. Chaque constat reçoit une sévérité, un effort et un scénario de défaillance. Le livrable est une file : corriger maintenant, planifier, ou accepter par écrit — avec des noms attachés.

Quand c’est la mauvaise approche

Une revue complète est prématurée si l’environnement s’apprête à être reconstruit — révisez la conception du nouvel environnement plutôt que d’auditer le condamné. C’est aussi le mauvais outil pendant un incident en cours; les revues sont un travail de temps calme. Et si le compte a un problème critique évident, connu et non corrigé (mettons que tout le monde sait déjà qu’il n’y a pas de sauvegardes), dépensez l’argent à le corriger avant de payer quelqu’un pour le redécouvrir.

Erreurs fréquentes

• Traiter le rapport de revue comme le livrable. Le livrable est la file de correction avec responsables et dates; le PDF, c’est l’emballage.
• Corriger les constats dans l’ordre de découverte plutôt que de sévérité. Des équipes brûlent des semaines sur l’hygiène des étiquettes pendant que la base de données de production mono-AZ attend.
• La faire une fois et plus jamais. Les comptes dérivent; une cadence annuelle, ou une revue après chaque lancement majeur, garde la liste de constats honnête.
• Laisser le réviseur corriger son propre examen. Si l’équipe ou le fournisseur qui a bâti l’environnement mène la revue, les incitatifs penchent vers des constats doux.

Garder le contrôle

• Tenez un registre de constats vivant — sévérité, responsable, statut — plutôt que des rapports figés qui pourrissent dans un lecteur partagé.
• Automatisez les vérifications peu coûteuses : les normes Security Hub, les règles AWS Config, et une exécution mensuelle scriptée des commandes ci-dessus.
• Revérifiez les deux affirmations qui se dégradent le plus vite : restauration testée, alarmes qui rejoignent un humain. Chaque trimestre, avec preuves.
• Exigez une vérification d’architecture avant chaque lancement significatif, pas après.
• Suivez la métrique plate qui prédit tout le reste : le nombre de constats critiques ouverts, et depuis combien de temps.

La plupart des environnements AWS n’échouent pas de façon originale — ils échouent sur cette liste. 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.