Audit AWS

Un compte AWS qui grossit vite finit par accumuler des angles morts : permissions trop larges, buckets oubliés, factures qui dérivent, sauvegardes jamais testées. Un audit AWS sert à éclairer ces angles morts avant qu'ils ne deviennent une fuite de données, un incident de production ou une dépense impossible à justifier. Cette page détaille tout : ce qu'on regarde, comment, ce que vous recevez, combien de temps et combien ça coûte.

Qu'est-ce qu'un audit AWS et à quoi sert-il ?

Un audit AWS est un examen méthodique et indépendant d'un environnement Amazon Web Services, destiné à mesurer son niveau de sécurité, de maîtrise des coûts, de performance, de fiabilité et de conformité, puis à produire un plan d'action priorisé pour le corriger.

Il ne s'agit pas d'un simple scan automatique. Un scan vous donne une liste de findings ; un audit vous donne une lecture de ces findings : ce qui est grave, ce qui est cosmétique, ce qui doit être traité cette semaine et ce qui peut attendre le prochain trimestre. La différence se joue dans l'analyse et la priorisation, pas dans l'outil.

Les motifs qui déclenchent un audit AWS dans nos missions sont presque toujours les mêmes :

• Une dérive de coûts : la facture mensuelle a doublé sans que personne ne sache exactement pourquoi.
• Un événement de sécurité : une alerte GuardDuty, une clé d'accès retrouvée dans un dépôt Git public, un départ d'administrateur.
• Une exigence de conformité : un client, un assureur ou un régulateur demande une preuve de maîtrise (RGPD, ISO 27001, SOC 2, DORA, HDS).
• Un changement d'équipe : reprise d'un compte AWS hérité, départ du prestataire historique, fusion de SI.
• Une préparation à l'échelle : avant de migrer une charge critique ou d'ouvrir l'environnement à de nouveaux services.

L'angle mort le plus coûteux n'est pas technique, il est organisationnel. Dans la plupart des comptes audités via notre réseau, personne ne possède une vue consolidée de l'ensemble : la sécurité est chez le RSSI, les coûts chez le DAF, l'exploitation chez la DSI. L'audit réunit ces trois regards sur une même réalité.

L'audit AWS appartient à la famille plus large de l'audit d'infrastructure cloud ; c'est sa déclinaison spécifique au cloud d'Amazon, qui possède ses propres services, ses propres pièges et ses propres outils natifs.

Concrètement, un audit AWS répond à cinq objectifs qui structurent l'ensemble de la mission :

• Sécurité : réduire la surface d'attaque, fermer les accès non maîtrisés, garantir la traçabilité.
• Coûts : supprimer le gaspillage, dimensionner au plus juste, engager intelligemment.
• Performance : vérifier que les services choisis et leur dimensionnement correspondent à la charge réelle.
• Fiabilité : s'assurer que l'environnement résiste aux pannes et sait récupérer dans des délais acceptables.
• Conformité : aligner la configuration sur les référentiels applicables (CIS, ISO 27001, RGPD, DORA, HDS, PCI DSS, SOC 2).

Un audit ne hiérarchise pas ces objectifs à votre place. Selon le contexte, la sécurité prime (après un incident), les coûts dominent (après une dérive de facture) ou la conformité commande (avant une certification). Le cadrage initial sert précisément à fixer ce curseur.

Audit AWS, audit de sécurité, Well-Architected Review : ne pas confondre

Trois termes circulent et désignent des périmètres différents. Les distinguer évite de payer pour un livrable qui ne répond pas à votre besoin.

| Type d'examen | Question centrale | Périmètre | Référentiel | |---|---|---|---| | Audit de sécurité AWS | Suis-je exposé ? | IAM, réseau, données, journalisation, détection | CIS AWS Benchmark, bonnes pratiques sécurité | | AWS Well-Architected Review | Mon architecture est-elle saine sur les 6 piliers ? | Architecture globale, dont sécurité, coûts, fiabilité, perf, ops, durabilité | AWS Well-Architected Framework | | Audit AWS (complet, au sens de cette page) | Où en suis-je vraiment, et que dois-je corriger en priorité ? | Sécurité + FinOps + fiabilité + conformité + IaC + organisation | Well-Architected plus CIS, ISO 27001, RGPD, DORA/HDS selon le secteur |

Un AWS Well-Architected Review suit la grille officielle d'Amazon, gratuite et structurée, mais reste cadré par le framework du fournisseur. Un audit de sécurité cloud creuse en profondeur l'exposition mais ignore les coûts et la fiabilité. L'audit AWS complet que nous décrivons ici intègre les trois, plus la dimension conformité réglementaire française et européenne que le framework AWS ne couvre pas.

Well-Architected Review, audit indépendant, audit de conformité : lever la confusion

C'est la confusion la plus coûteuse du marché. Trois prestations portent des noms voisins, coûtent des sommes différentes et ne servent pas le même objectif. Voici la table de décision que nous remettons systématiquement en cadrage.

| | Well-Architected Review | Audit AWS indépendant | Audit de conformité certifiant | |---|---|---|---| | Qui le mène | AWS ou un partenaire AWS, avec l'outil Well-Architected Tool | Intermédiaire indépendant (comme Architecte Cloud) | Organisme de certification accrédité (COFRAC, etc.) | | Objectif | Conversation d'amélioration sur les 6 piliers | Mesurer l'écart réel et prioriser la remédiation | Délivrer un certificat opposable (ISO 27001, HDS, PCI DSS) | | Logique | Pas de note pass/fail, blame-free, pédagogique | Scoring risque/effort, findings qualifiés, plan d'action | Conformité binaire à un référentiel, échantillonnage de preuves | | Coût | Gratuit (via AWS ou partenaire) | Sur devis, voir notre fourchette plus bas | Élevé (plusieurs jours d'auditeur certifié + frais d'organisme) | | Incitation | Jusqu'à 5 000 $ de crédits AWS par charge revue, sous conditions, pour financer les remédiations issues du review | Aucune incitation fournisseur, c'est le gage d'indépendance | Aucune ; le certificat est l'objectif | | Indépendance | Cadré par AWS, oriente vers les services AWS | Sans parti pris fournisseur | Indépendance de l'organisme certificateur | | Quand le choisir | Pour amorcer une démarche, gratuitement, sur une charge | Pour une décision d'investissement objective et multicloud | Quand un client, un assureur ou un régulateur exige un certificat |

Le piège classique. Un Well-Architected Review « gratuit » mené par un partenaire revendeur n'est jamais tout à fait neutre : son modèle économique repose sur la consommation AWS qu'il vous aide à générer. C'est un excellent point de départ, à condition de savoir qu'il ne remplace ni un audit indépendant, ni un audit de conformité certifiant. Les trois sont complémentaires, pas substituables.

Les crédits AWS Well-Architected (jusqu'à 5 000 $ par charge éligible, selon les conditions du programme AWS en vigueur) sont une vraie opportunité de financement, mais ils s'obtiennent en passant par la grille AWS, qui ne mesure ni vos coûts réels au centime, ni votre conformité RGPD/DORA, ni votre dette IaC. D'où l'intérêt de combiner : un review pour les crédits, un audit indépendant pour la décision.

Le modèle de responsabilité partagée : ce qui est de votre ressort

Avant de définir le périmètre d'un audit, il faut clarifier qui est responsable de quoi. AWS fonctionne selon un modèle de responsabilité partagée que beaucoup d'équipes comprennent mal, ce qui crée de fausses certitudes.

• AWS est responsable de la sécurité du cloud : les datacenters, le matériel, l'hyperviseur, le réseau physique, la disponibilité des services managés.
• Vous êtes responsable de la sécurité dans le cloud : vos données, le chiffrement, la configuration IAM, les security groups, les correctifs de vos instances EC2, la gestion des accès.

La frontière se déplace selon le service. Sur une instance EC2 (IaaS), vous gérez le système d'exploitation et tout ce qui est au-dessus. Sur Amazon RDS (managé), AWS gère le moteur et les correctifs de base de données, mais vous restez responsable des comptes applicatifs, du chiffrement et des règles d'accès réseau. Sur AWS Lambda (serverless), AWS gère l'exécution, mais le code, les permissions et les secrets restent vôtres.

Conséquence directe sur le périmètre d'audit. Un audit AWS ne juge pas la sécurité des datacenters d'Amazon, c'est inutile et hors de votre contrôle. Il se concentre exclusivement sur votre part : configuration, accès, données, code. Tout findings d'audit correspond à un levier que vous pouvez actionner.

Cette clarification a aussi une portée juridique. Au sens du RGPD, AWS agit comme sous-traitant (article 28) et vous restez responsable de traitement. L'audit vérifie que cette répartition est correctement matérialisée : accord de traitement en place, localisation des données maîtrisée, mesures techniques à votre charge effectivement implémentées.

Le AWS Well-Architected Framework : la grille de fond

L'audit s'appuie sur le AWS Well-Architected Framework, le référentiel de conception d'Amazon, structuré en six piliers. Nous l'utilisons comme grille de lecture systématique pour ne laisser aucun domaine dans l'ombre.

1. Excellence opérationnelle : capacité à exploiter, observer et améliorer en continu (automatisation, infrastructure as code, observabilité, gestion des incidents).
2. Sécurité : protection des données, des systèmes et des accès (IAM, chiffrement, détection, traçabilité).
3. Fiabilité : capacité à résister aux pannes et à récupérer (haute disponibilité multi-AZ, sauvegardes, PRA, RTO/RPO).
4. Efficacité des performances : bon dimensionnement et bon choix des services pour la charge réelle.
5. Optimisation des coûts : dépenser au plus juste, supprimer le gaspillage, engager là où c'est rentable.
6. Durabilité : réduire l'empreinte environnementale (rightsizing, régions, services managés efficients).

Chaque pilier devient une section de scoring dans notre rapport. Cela permet qu'un audit ne se réduise pas à la sécurité ou aux coûts, mais couvre l'ensemble du cycle de vie.

Ce que contient un audit AWS, domaine par domaine

Audit de sécurité IAM

La gestion des identités et des accès (IAM) est le premier point d'entrée d'un attaquant et la source la plus fréquente de findings critiques. Nous vérifions :

• Le compte root : usage résiduel (il ne doit jamais servir au quotidien), MFA matériel ou applicatif activé, clés d'accès root supprimées, alertes de connexion.
• L'authentification multifacteur (MFA) : généralisée à tous les utilisateurs humains, en priorité ceux disposant de privilèges.
• Le moindre privilège (least privilege) : chasse aux policies *:*, aux droits administrateurs distribués par confort, aux permissions jamais utilisées.
• Les clés d'accès : ancienneté, rotation, clés actives non utilisées depuis des mois, clés codées en dur dans du code ou des images.
• Les rôles et la fédération : usage de rôles plutôt que d'utilisateurs IAM, déploiement d'IAM Identity Center pour centraliser les accès humains, suppression des comptes dormants.
• IAM Access Analyzer : détection des accès externes non intentionnels (ressources partagées hors de votre organisation, rôles assumables depuis l'extérieur).

Le finding IAM le plus courant que nous constatons : des utilisateurs créés « pour dépanner » trois ans plus tôt, dotés de droits administrateurs, sans MFA, avec une clé d'accès jamais désactivée. Chacun de ces comptes est une porte ouverte.

L'audit IAM ne se limite pas à dresser un inventaire. Il analyse les chemins de privilège : comment, en partant d'un compte peu privilégié, un attaquant pourrait s'élever jusqu'aux droits administrateurs en s'appuyant sur des rôles assumables ou des permissions mal cloisonnées (iam:PassRole, sts:AssumeRole trop ouverts). Cette analyse de l'escalade de privilèges distingue un véritable audit d'un simple relevé de configuration.

Audit de la configuration réseau

Une mauvaise configuration réseau expose des services qui devraient rester privés. Nous examinons :

• L'architecture VPC : segmentation en sous-réseaux publics/privés, usage des passerelles NAT, cloisonnement des environnements (prod/préprod/dev).
• Les security groups et NACL : règles trop ouvertes (0.0.0.0/0 sur SSH, RDP ou des bases de données), ports inutilement exposés, règles mortes accumulées.
• L'exposition publique : instances EC2, bases RDS, fonctions ou équilibreurs de charge accessibles depuis Internet sans nécessité.
• Les VPC Flow Logs : activation effective de la journalisation du trafic réseau, sans laquelle aucune investigation post-incident n'est possible.
• Les points d'accès privés : usage des VPC endpoints (PrivateLink) pour atteindre les services AWS sans transiter par Internet, et donc sans exposition inutile.
• Le périmètre DNS et la résolution : zones publiques exposant des enregistrements internes, sous-domaines orphelins susceptibles d'être détournés (subdomain takeover).

Un finding réseau classique : une base de données RDS placée dans un sous-réseau public avec un security group autorisant 0.0.0.0/0 sur le port 5432, « le temps d'un test » qui dure depuis dix-huit mois. La donnée est à un scan de distance de l'exposition.

Audit du stockage et de la donnée

La donnée est ce que vous protégez vraiment. L'audit couvre :

• Les buckets Amazon S3 : politiques d'accès, désactivation du blocage d'accès public, buckets exposés par erreur, versioning, journalisation des accès, règles de cycle de vie.
• Le chiffrement au repos (at rest) : activation sur S3, EBS, RDS, snapshots ; usage de AWS KMS avec des clés gérées correctement plutôt que des clés par défaut systématiques.
• Le chiffrement en transit (in transit) : TLS imposé, certificats valides, absence de protocoles obsolètes.
• La gestion des secrets : usage de AWS Secrets Manager ou Parameter Store, plutôt que des mots de passe et tokens en clair dans des variables d'environnement, du code ou des fichiers IaC.
• La classification des données sensibles : détection des données personnelles ou réglementées dispersées, où Amazon Macie apporte une valeur réelle pour le RGPD.

Journalisation et détection

Sans traçabilité, un incident est invisible et un audit de conformité impossible. Nous contrôlons l'activation et la couverture de :

• AWS CloudTrail : journalisation de toutes les actions d'API, dans toutes les régions, avec protection contre l'altération des journaux.
• Amazon CloudWatch : métriques, journaux applicatifs, alarmes sur les seuils critiques.
• Amazon GuardDuty : détection des menaces (comportements anormaux, communications avec des adresses malveillantes connues, exfiltration).
• AWS Config : suivi de la configuration des ressources dans le temps et évaluation par rapport à des règles de conformité.
• AWS Security Hub : agrégation des findings de sécurité (CSPM) et mesure de conformité par rapport aux standards (CIS, AWS Foundational Security Best Practices).
• Amazon Inspector : analyse des vulnérabilités sur les instances EC2, les images de conteneurs et les fonctions Lambda.

L'audit ne vérifie pas seulement que ces services sont activés, mais qu'ils sont exploités : une console GuardDuty qui génère des alertes que personne ne lit ne vaut guère mieux qu'un GuardDuty éteint. Nous évaluons donc la chaîne complète (activation, couverture multi-régions, destination des alertes, processus de réponse) et la rétention des journaux, souvent insuffisante pour répondre aux exigences de conformité (qui demandent fréquemment 6 à 12 mois minimum).

Audit FinOps : l'optimisation des coûts

Un audit AWS qui ignore la facture passe à côté du sujet le plus immédiatement rentable. L'audit FinOps est souvent celui qui finance le reste de la démarche. Nous analysons :

• Le gaspillage direct : ressources orphelines (volumes EBS détachés, IP élastiques non associées, snapshots obsolètes, équilibreurs sans cible), environnements de test allumés la nuit et le week-end.
• Le rightsizing : instances EC2 et bases surdimensionnées par rapport à leur usage réel, identifiées via AWS Compute Optimizer et Cost Explorer.
• Les engagements : pertinence des Savings Plans, Reserved Instances et Spot Instances selon la stabilité de la charge, un sujet d'arbitrage, pas de réservation aveugle.
• L'étiquetage (tagging) : qualité et couverture des tags, sans lesquels aucune allocation de coûts par projet, équipe ou environnement n'est possible.
• Le stockage : classes S3 inadaptées (données froides en standard), absence de règles de cycle de vie, snapshots qui s'accumulent.

Sur les comptes audités via notre réseau, une réduction de 20 à 35 % de la facture mensuelle est fréquemment atteignable, principalement par suppression du gaspillage et engagement raisonné. Ce chiffre est une observation moyenne, jamais une garantie : il dépend du niveau de maturité déjà atteint.

L'audit FinOps applique le cadre de la FinOps Foundation : informer (visibilité et allocation des coûts par tag), optimiser (rightsizing, engagements, suppression du gaspillage) et opérer (gouvernance continue, alertes de budget, responsabilisation des équipes). Le tagging est la clé de voûte de tout l'édifice : sans étiquetage fiable, impossible de répondre à la question « combien coûte ce projet ? », et donc impossible de responsabiliser qui que ce soit. C'est souvent par là que commence un chantier FinOps sérieux.

Audit de fiabilité et de continuité

La fiabilité se mesure à la capacité à survivre à une panne. Nous évaluons :

• La haute disponibilité : déploiement multi-zones de disponibilité (multi-AZ), points de défaillance uniques, dépendances critiques mono-région.
• Les sauvegardes : existence, automatisation, et test de restauration, une sauvegarde jamais restaurée n'est qu'une hypothèse.
• Le PRA/PCA : plan de reprise et de continuité, objectifs RTO (durée maximale d'interruption acceptable) et RPO (perte de données maximale acceptable) définis, documentés et testés.
• La résilience applicative : gestion des limites de service (quotas), reprise automatique, dégradation gracieuse, dépendances à des services managés mono-région.
• L'observabilité : alarmes effectivement configurées sur les signaux critiques, tableaux de bord exploitables, capacité à détecter une panne avant le client.

La question qui révèle la vraie fiabilité d'un environnement : « À quand remonte votre dernier test de restauration complète ? » Quand la réponse est « jamais » ou « on ne sait plus », le PRA est une fiction. Un audit le met noir sur blanc.

Audit des conteneurs : EKS et ECS

Les environnements Kubernetes sur AWS ajoutent une couche de complexité que peu d'audits couvrent réellement. Pour Amazon EKS et Amazon ECS, nous examinons :

• Le RBAC Kubernetes : qui peut faire quoi dans le cluster, intégration avec IAM, comptes de service surprivilégiés.
• Les network policies : segmentation du trafic entre pods, par défaut souvent totalement ouverte.
• L'admission control : politiques d'admission, validation des manifestes, blocage des images non signées ou vulnérables.
• Le Pod Security : exécution en root, privilèges élevés, montages sensibles, conformité aux standards Pod Security.
• L'exposition : services exposés publiquement, endpoints d'API serveur, gestion des secrets dans le cluster.

Ce périmètre relève aussi de l'audit Kubernetes, que nous mobilisons quand l'environnement conteneurisé est central.

Audit de l'infrastructure as code et du drift

Quand l'infrastructure est décrite en Terraform ou CloudFormation, l'audit ne s'arrête pas à la réalité observée : il compare le code à la réalité. C'est l'analyse du drift.

• L'état (state) : où est stocké le state Terraform, est-il chiffré, verrouillé, versionné, partagé proprement.
• Le drift : écarts entre ce que le code déclare et ce qui existe réellement (modifications manuelles dans la console qui ne reviendront jamais dans le code).
• La qualité du code : modularité, réutilisation, secrets en clair, absence de revue, versions épinglées.
• La couverture : quelle part de l'infrastructure est réellement gérée par le code, et quelle part vit hors contrôle.

Un environnement où 40 % des ressources ont été créées à la main, hors IaC, est un environnement où chaque audit devient obsolète le lendemain. Réduire le drift est souvent le quick win le plus structurant.

Audit multi-comptes et Landing Zone

À l'échelle, un compte AWS unique devient ingérable. Les organisations matures séparent les charges en plusieurs comptes pilotés centralement. Les prestataires de notre réseau auditent :

• AWS Organizations : structure des unités organisationnelles, séparation prod/hors-prod, compte de facturation consolidé.
• AWS Control Tower / Landing Zone Accelerator : existence et bonne configuration d'une Landing Zone, garde-fous automatisés.
• Les SCP (Service Control Policies) : politiques de contrôle au niveau de l'organisation, qui interdisent par construction certaines actions dangereuses (désactiver CloudTrail, déployer dans des régions non autorisées).
• La centralisation de la sécurité : compte d'audit et compte de log dédiés, agrégation de Security Hub et de GuardDuty au niveau de l'organisation, gestion centralisée des accès via IAM Identity Center.

Un environnement multi-comptes bien conçu transforme la sécurité d'un problème répété sur chaque compte en un garde-fou appliqué une fois, partout. À l'inverse, un seul gros compte « fourre-tout » est l'un des findings structurels les plus lourds à corriger, car il mêle des charges aux niveaux de criticité différents sans cloisonnement possible.

Top 10 des erreurs de configuration AWS les plus fréquentes

Voici les findings que nous rencontrons le plus souvent en mission. Ils sont représentatifs, pas exhaustifs.

| # | Finding | Risque | Effort de remédiation | |---|---|---|---| | 1 | Compte root sans MFA et clés root actives | Critique | Faible | | 2 | Buckets S3 sans blocage d'accès public généralisé | Critique | Faible | | 3 | Security groups ouverts en 0.0.0.0/0 sur SSH/RDP/bases | Élevé | Faible | | 4 | Policies IAM en *:* distribuées largement | Élevé | Moyen | | 5 | CloudTrail désactivé dans certaines régions | Élevé | Faible | | 6 | Absence de chiffrement au repos sur volumes/snapshots/RDS | Élevé | Moyen | | 7 | Secrets en clair dans le code, l'IaC ou les variables | Élevé | Moyen | | 8 | Clés d'accès jamais renouvelées et comptes dormants | Moyen | Faible | | 9 | Aucune sauvegarde testée / PRA non documenté | Élevé | Élevé | | 10 | Ressources orphelines et instances surdimensionnées | Moyen (coût) | Faible |

La leçon récurrente : la majorité des risques critiques se corrigent avec un effort faible. Ce sont des quick wins. Le rôle de l'audit est de les rendre visibles et prioritaires avant qu'ils ne soient exploités.

Checklist d'audit AWS : 30 points à vérifier vous-même

Voici une checklist actionnable, exploitable dès aujourd'hui par votre équipe pour un premier auto-diagnostic. Elle ne remplace pas un audit qualifié, elle vous donne une première mesure de votre exposition.

Identités et accès (IAM)

1. Le compte root a-t-il le MFA activé et ses clés d'accès supprimées ?
2. Tous les utilisateurs humains disposant de privilèges ont-ils le MFA ?
3. Existe-t-il des policies attachées en *:* (administrateur de fait) ?
4. Les accès humains passent-ils par IAM Identity Center plutôt que par des utilisateurs IAM dispersés ?
5. IAM Access Analyzer est-il activé pour repérer les accès externes non intentionnels ?
6. Les clés d'accès inutilisées depuis 90 jours sont-elles désactivées ?

Réseau et exposition

7. Des security groups autorisent-ils 0.0.0.0/0 sur SSH (22), RDP (3389) ou des ports de bases de données ?
8. Les bases de données sont-elles dans des sous-réseaux privés ?
9. Les VPC Flow Logs sont-ils activés ?
10. Les services AWS sont-ils atteints via des VPC endpoints (PrivateLink) plutôt que par Internet ?

Données et chiffrement

11. Le blocage d'accès public S3 est-il activé au niveau du compte ?
12. Le chiffrement au repos (KMS) est-il généralisé sur S3, EBS, RDS et snapshots ?
13. Les secrets sont-ils dans Secrets Manager / Parameter Store, jamais en clair dans le code ou l'IaC ?
14. Le versioning et les règles de cycle de vie S3 sont-ils configurés ?

Journalisation et détection

15. CloudTrail est-il actif dans toutes les régions, avec protection contre l'altération ?
16. GuardDuty est-il activé et ses alertes sont-elles effectivement traitées ?
17. AWS Config suit-il la configuration des ressources ?
18. Security Hub mesure-t-il votre conformité aux CIS Benchmarks et aux Foundational Security Best Practices ?
19. La rétention des journaux couvre-t-elle au moins 6 à 12 mois ?

Fiabilité et continuité

20. Les charges critiques sont-elles déployées en multi-AZ ?
21. Les sauvegardes sont-elles automatisées et testées par restauration ?
22. Vos RTO et RPO sont-ils définis, documentés et testés ?
23. Existe-t-il des points de défaillance uniques mono-région non assumés ?

Coûts (FinOps)

24. Reste-t-il des ressources orphelines (EBS détachés, IP élastiques, snapshots, load balancers sans cible) ?
25. Les instances et bases sont-elles dimensionnées sur leur usage réel (Compute Optimizer) ?
26. Les environnements hors-prod sont-ils éteints en dehors des heures ouvrées ?
27. Des Savings Plans ou Reserved Instances couvrent-ils les charges stables ?
28. Le tagging permet-il d'allouer les coûts par projet, équipe et environnement ?

Gouvernance et IaC

29. Quelle part de l'infrastructure est réellement gérée en Terraform / CloudFormation (et quel drift) ?
30. AWS Organizations et des SCP encadrent-ils les comptes (CloudTrail non désactivable, régions limitées) ?

Si vous répondez « non » ou « je ne sais pas » à plus de cinq de ces points, l'environnement mérite un audit qualifié. Le diagnostic en ligne reprend cette logique et vous oriente en quelques minutes.

Les outils natifs AWS d'audit

AWS fournit une boîte à outils riche que les prestataires de notre réseau exploitent systématiquement, en complément de scanners tiers.

• AWS Trusted Advisor : recommandations transverses (sécurité, coûts, performance, tolérance aux pannes, quotas de service). Bon point de départ, niveau de détail variable selon le plan de support.
• AWS Security Hub : posture de sécurité consolidée (CSPM), mesure de conformité aux standards CIS et AWS Foundational Security Best Practices.
• AWS Config : suivi de configuration et règles de conformité (conformance packs), pierre angulaire de la surveillance continue.
• AWS Compute Optimizer : recommandations de rightsizing fondées sur l'usage réel.
• AWS Cost Explorer : analyse et projection des coûts, identification des dérives.

Le cas AWS Audit Manager : une actualité à intégrer

AWS Audit Manager automatise la collecte de preuves pour les audits de conformité (mapping vers des frameworks comme CIS, ISO 27001, PCI DSS, SOC 2). C'est un outil utile, mais un point d'actualité change la donne.

AWS a annoncé la fin de la commercialisation d'AWS Audit Manager aux nouveaux clients. Selon la communication d'AWS, le service cesse d'être ouvert aux nouveaux clients à compter du 30 avril 2026. Les clients déjà utilisateurs conservent l'accès, mais toute nouvelle organisation doit envisager les alternatives.

Pour une équipe qui démarre aujourd'hui, mieux vaut donc bâtir sa collecte de preuves de conformité sur les briques pérennes :

• AWS Security Hub pour la posture (CSPM) et la mesure continue par rapport aux standards.
• AWS Config conformance packs pour les règles de conformité versionnées et auditables.
• Une couche d'orchestration et de reporting maison ou tierce pour consolider les preuves.

C'est précisément le genre de décision où un audit indépendant apporte de la valeur : éviter d'investir dans un outil dont la trajectoire produit se referme.

Méthodologie d'un audit AWS

Notre démarche se déroule en quatre temps. Elle combine systématiquement scan automatisé et revue manuelle : l'outil trouve, l'expert qualifie.

1. Cadrage et collecte

Définition du périmètre (comptes, régions, charges concernées), des objectifs (sécurité, coûts, conformité ou tout) et du référentiel applicable. Mise en place d'un accès en lecture seule via un rôle IAM dédié, nous n'avons besoin d'aucun droit de modification pour auditer.

2. Scan automatisé

Exécution de scanners de référence open source, complémentaires aux outils natifs :

• Prowler : centaines de contrôles de sécurité et de conformité (CIS, RGPD, ISO 27001, PCI DSS, HIPAA), avec scoring.
• ScoutSuite : cartographie multi-services de la posture de sécurité, lisible et exhaustive.

Le scan produit une base de findings brute, datée et reproductible.

3. Analyse et qualification manuelle

C'est l'étape qui distingue un audit d'un export d'outil. Chaque finding est :

• Vérifié (élimination des faux positifs).
• Contextualisé (un port ouvert sur un VPC isolé n'a pas la même gravité que sur un sous-réseau public).
• Scoré selon une matrice risque × effort.
• Relié à une exigence métier ou réglementaire quand elle existe.

4. Restitution

Remise du rapport, présentation orale à la DSI et, quand c'est pertinent, à la direction. Le langage est double : technique pour les équipes, clair (coûts/risques/délais) pour les décideurs.

Pourquoi le scan seul ne suffit jamais. Un scanner ne connaît pas votre métier. Il signalera un port ouvert avec la même gravité qu'il soit sur un bastion volontairement exposé ou sur une base de production. Il ne saura pas qu'une instance « surdimensionnée » porte en réalité un pic saisonnier. La revue manuelle transforme une liste anxiogène de centaines d'alertes en une poignée de décisions justes. C'est là que se trouve la valeur d'un audit, et c'est exactement ce qu'une page de checklist purement technique ne peut pas livrer.

Audit interne ou audit externe : un comparatif honnête

La question revient souvent, et la réponse n'est pas toujours « externe ».

| Critère | Audit interne | Audit externe indépendant | |---|---|---| | Connaissance du contexte | Excellente | À construire (rapide en lecture seule) | | Objectivité | Biais de l'équipe qui a construit le système | Regard tiers sans parti pris | | Valeur de preuve (clients, régulateurs) | Faible | Forte | | Couverture des angles morts | Limitée à ce que l'équipe sait chercher | Référentiels et findings issus de dizaines de contextes | | Coût direct | Temps interne | Prestation |

L'audit interne est précieux pour la surveillance continue. L'audit externe apporte ce que l'interne ne peut structurellement pas offrir : un regard non biaisé et une valeur de preuve vis-à-vis d'un client, d'un assureur ou d'un régulateur. Les deux sont complémentaires, pas concurrents. Le biais le plus dangereux étant celui de l'équipe qui audite sa propre construction, l'externe trouve presque toujours ce que l'interne a cessé de voir.

Conformité réglementaire appliquée à AWS

Un audit AWS bien mené relie la configuration technique aux exigences réglementaires. C'est le rôle de l'audit de conformité cloud.

• CIS AWS Benchmarks : le socle de durcissement reconnu, mesurable directement via Security Hub. Notre point de départ technique.
• ISO 27001 : système de management de la sécurité de l'information. L'audit alimente les preuves techniques attendues. Architecte Cloud s'inscrit dans une démarche ISO 27001 ; l'audit ne délivre pas de certification, il en prépare et documente les preuves.
• RGPD : localisation des données, chiffrement, traçabilité, répartition responsable de traitement / sous-traitant (article 28). L'audit vérifie l'effectivité des mesures à votre charge.
• PCI DSS : pour les environnements traitant des données de paiement, durcissement et segmentation spécifiques.
• SOC 2 : preuves de contrôle attendues par les clients B2B, en particulier dans le SaaS.

DORA et HDS : les exigences sectorielles françaises et européennes

Deux cadres rarement reliés à AWS dans les contenus francophones, alors qu'ils sont déterminants :

• DORA (Digital Operational Resilience Act) : applicable au secteur de la finance et de l'assurance, il impose la résilience opérationnelle, les tests, la gestion du risque lié aux prestataires tiers (dont AWS) et la réversibilité. Un audit AWS dans ce cadre vérifie la documentation des dépendances, les plans de sortie et les tests de continuité.
• HDS (Hébergement de Données de Santé) : pour le secteur de la santé, les données de santé doivent être hébergées chez un partenaire certifié HDS. AWS dispose d'offres éligibles ; l'audit vérifie que le périmètre et la configuration respectent les conditions de cette certification, qui s'applique à l'hébergeur, pas à votre configuration applicative.
• PSSI-E et doctrine « cloud au centre » : pour le secteur public, les administrations sont tenues par la Politique de Sécurité des Systèmes d'Information de l'État et la doctrine d'usage du cloud par l'État. Un audit AWS dans ce contexte objective l'écart de configuration au regard des exigences de l'ANSSI et de la sensibilité des données hébergées.

Pour relier chaque exigence à un contrôle d'audit concret, voici une table de correspondance synthétique.

| Référentiel | Secteur / portée | Ce que l'audit AWS vérifie en priorité | |---|---|---| | RGPD (art. 28) | Toute donnée personnelle | Accord de sous-traitance, localisation, chiffrement, traçabilité, mesures à votre charge | | ISO 27001 | Démarche SMSI transverse | Preuves techniques de contrôle des accès, chiffrement, journalisation, gestion des actifs | | PCI DSS | Données de paiement | Segmentation réseau, chiffrement, durcissement, restriction des accès | | SOC 2 | SaaS / B2B | Contrôles de sécurité, disponibilité et confidentialité attendus par vos clients | | HDS | Santé | Hébergement chez un partenaire certifié HDS, périmètre et configuration éligibles | | DORA | Finance / assurance | Résilience opérationnelle, tests, risque tiers (AWS), plan de sortie et réversibilité | | PSSI-E / ANSSI | Secteur public | Conformité à la doctrine cloud de l'État selon la sensibilité des données |

Aucun de ces référentiels n'est « coché » par AWS à votre place. Le modèle de responsabilité partagée s'applique aussi à la conformité : AWS fournit des briques éligibles, mais c'est votre configuration, celle qu'un audit mesure, qui fait foi.

Le livrable : rapport, scoring et plan de remédiation

Un audit ne vaut que par ce qu'il vous laisse entre les mains. Vous recevez :

Le rapport d'audit

Un document structuré comprenant : synthèse exécutive (une page pour la direction), méthodologie, findings détaillés par domaine et par pilier Well-Architected, et annexes techniques reproductibles (exports de scan datés).

La grille de scoring de maturité

Chaque domaine reçoit une note, consolidée en un score global. Exemple de structure :

| Domaine | Score /100 | Niveau de maturité | |---|---|---| | Sécurité IAM | 58 | À renforcer | | Réseau & exposition | 72 | Correct | | Données & chiffrement | 65 | À renforcer | | Journalisation & détection | 80 | Bon | | FinOps & coûts | 49 | Insuffisant | | Fiabilité & PRA | 55 | À renforcer | | Conformité | 60 | À renforcer |

Les chiffres ci-dessus illustrent le format ; les vôtres reflètent votre réalité.

Le plan de remédiation priorisé 30 / 60 / 90 jours

C'est le cœur opérationnel du livrable. Chaque action est positionnée dans une feuille de route et sur une matrice risque/effort.

• 0–30 jours (quick wins) : MFA root, fermeture des security groups ouverts, blocage d'accès public S3, activation de CloudTrail multi-régions, suppression des ressources orphelines. Risque élevé, effort faible.
• 30–60 jours (chantiers structurants) : moindre privilège IAM, chiffrement généralisé, gestion des secrets, rightsizing et engagements FinOps.
• 60–90 jours (transformation) : Landing Zone, surveillance continue, PRA testé, réduction du drift IaC, mise en conformité documentée.

Chaque quick win FinOps est chiffré en économie mensuelle estimée, ce qui permet souvent d'autofinancer la suite.

Réversibilité et indépendance : ce que vous gardez

Un point sur lequel Architecte Cloud se distingue, et que vous devez exiger de tout prestataire : à qui appartient le résultat ?

• Le rapport vous appartient. Vous pouvez le partager avec un autre prestataire, un client ou un régulateur sans restriction.
• Le code IaC (Terraform) reste dans vos dépôts, à votre nom. Si une remédiation est produite, elle vit chez vous, pas chez nous.
• Vos comptes AWS restent à votre nom. Les prestataires interviennent via des accès délégués que vous pouvez révoquer en une action.
• Aucun enfermement. Notre travail vous rend plus autonome, il ne vous lie pas.

L'indépendance n'est pas un slogan, c'est une mécanique. Nous n'avons aucun intérêt commercial à vous orienter vers AWS plutôt qu'Azure, ni à complexifier votre environnement pour sécuriser une infogérance. Le conseil sans parti pris est notre modèle.

Audit AWS, audit Azure, multicloud : choisir un prestataire qui n'est pas juge et partie

Beaucoup d'environnements ne sont plus mono-cloud. Une charge historique sur AWS, un Microsoft 365 et de l'analytique sur Azure, un fournisseur SaaS tiers : la réalité est souvent hybride. Auditer un tel ensemble demande un prestataire qui maîtrise les deux plateformes et n'a d'intérêt à en pousser aucune.

C'est précisément la limite d'un partenaire mono-cloud ou d'un revendeur : son audit conclut presque toujours qu'il faut consommer davantage de la plateforme qu'il revend. Les critères de choix d'un prestataire vraiment indépendant :

• Double compétence vérifiable : des prestataires du réseau certifiés et référencés sur AWS et sur Azure, pas seulement sur l'une. La déclinaison Azure de cette démarche, c'est l'audit Azure ; le socle commun, l'audit d'infrastructure cloud.
• Aucun modèle de revente captif : la rémunération ne dépend pas de votre consommation cloud. Le conseil n'est pas biaisé par une marge sur la facture.
• Réversibilité contractuelle : le prestataire vous rend autonome (code, comptes, documentation) au lieu de vous rendre dépendant de lui.
• Comparabilité des findings : un même référentiel de scoring appliqué à AWS et à Azure permet de comparer objectivement vos deux empreintes et d'arbitrer (consolider ? répartir ? sortir d'une plateforme ?).

Un audit qui recommande systématiquement « plus de la plateforme du prestataire » n'est pas un audit, c'est un acte de vente déguisé. Le bon réflexe : demander qui paie le prestataire, et vérifier qu'aucune marge ne dépend de votre facture cloud.

Étude de cas représentative : audit AWS d'un éditeur SaaS (ETI)

L'exemple suivant est représentatif de missions menées sur des profils comparables. Les chiffres illustrent l'ordre de grandeur typique d'un audit ; ils ne constituent pas un engagement de résultat.

Contexte. Éditeur SaaS B2B, ~80 personnes, plateforme multi-locataire sur AWS répartie sur trois comptes (prod, staging, outillage), charge Kubernetes sur Amazon EKS, facture mensuelle d'environ 42 000 € en croissance rapide. Déclencheur : un prospect grand compte exige des preuves de sécurité (SOC 2 en ligne de mire) et la facture inquiète la direction financière.

Findings principaux (audit de 4 jours).

• Compte root d'un des trois comptes sans MFA, clé d'accès root active vieille de deux ans.
• Quatre security groups exposant des bases RDS en 0.0.0.0/0 sur l'environnement de staging.
• Aucun chiffrement KMS sur 60 % des volumes EBS et plusieurs snapshots.
• RBAC EKS quasi inexistant : la majorité des comptes de service héritaient de droits cluster-admin.
• Environnements de staging et d'outillage allumés 24/7, soit ~30 % de gaspillage de calcul.
• Aucune réservation ni Savings Plan sur des charges de production stables depuis 18 mois.
• IaC Terraform couvrant 55 % de l'infrastructure ; le reste créé à la console, donc invisible et non reproductible.

Plan de remédiation et effets observés.

| Action | Délai | Effet observé | |---|---|---| | MFA root, fermeture des SG, blocage S3 public | 0–30 j | Surface d'attaque critique fermée, exigences SOC 2 amorcées | | Extinction planifiée staging/outillage + rightsizing | 0–30 j | ~22 % de facture en moins dès le mois suivant | | Savings Plans sur la prod stable | 30–60 j | ~12 % supplémentaires sur le calcul de production | | Durcissement RBAC EKS + network policies | 30–60 j | Cloisonnement effectif des comptes de service | | Reprise IaC vers 90 % de couverture Terraform | 60–90 j | Drift résorbé, environnement reproductible et auditable |

Sur ce profil, l'économie FinOps cumulée observée la première année a dépassé plusieurs fois le coût de l'audit. C'est fréquent sur les environnements jamais optimisés, mais le résultat dépend toujours de la maturité de départ, et n'est jamais garanti.

Combien coûte un audit AWS et combien de temps dure-t-il ?

C'est la question que tous se posent et qu'aucun concurrent ne chiffre clairement. Voici une fourchette indicative, à affiner sur devis selon le périmètre réel.

• Durée : de 2 à 5 jours d'intervention selon la taille de l'environnement (nombre de comptes, de régions, de charges, présence de Kubernetes et d'IaC).
• Budget indicatif : de 3 500 à 8 000 € HT, sur devis après cadrage.

| Périmètre | Profil | Durée | Budget indicatif | |---|---|---|---| | Compte unique, charge simple | TPE / PME | 2 jours | à partir de 3 500 € HT | | Plusieurs comptes, prod critique | PME / ETI | 3–4 jours | 5 000–6 500 € HT | | Multi-comptes, EKS, IaC, conformité | ETI / grand compte | 5 jours | jusqu'à 8 000 € HT |

Ces montants sont des fourchettes indicatives, pas un tarif ferme. Le devis définitif dépend du périmètre, des référentiels de conformité visés et de la profondeur attendue. Le diagnostic en ligne et le cadrage initial permettent de le préciser.

L'audit FinOps inclus se rembourse fréquemment de lui-même : les économies identifiées dès les quick wins dépassent souvent le coût de la prestation dès le premier ou le deuxième mois. C'est une observation de mission, pas une promesse contractuelle.

Fréquence d'audit et surveillance continue

Un audit est une photographie ; un environnement cloud est un film. La bonne pratique :

• Audit complet : au moins une fois par an, et à chaque événement majeur (migration, fusion, incident, nouvelle exigence réglementaire).
• Surveillance continue : entre deux audits, la posture se suit en temps réel via Security Hub, Config et GuardDuty, avec des alertes sur les écarts.

La surveillance continue ne remplace pas l'audit : elle détecte les dérives connues, là où l'audit redéfinit ce qu'il faut surveiller. Pour les organisations qui ont laissé leur environnement dériver, l'audit est souvent le point de départ d'une démarche plus large pour remettre de l'ordre dans son cloud ou documenter un cloud non documenté.

Que faire après l'audit : de la photographie au pilotage continu

Un audit livré et rangé dans un tiroir ne crée aucune valeur. Le rapport n'est pas une fin, c'est un point de départ. Trois suites possibles, selon votre maturité et vos ressources internes.

1. Exécuter la remédiation en autonomie

Si votre équipe a les compétences, le plan 30/60/90 jours est conçu pour être exécuté sans nous. Chaque action est décrite, priorisée et, pour l'IaC, livrée en Terraform dans vos dépôts. C'est le scénario que nous privilégions : vous rendre autonome. Nous restons disponibles en appui ponctuel, sans dépendance imposée.

2. Faire exécuter la remédiation puis reprendre la main

Pour les chantiers structurants (Landing Zone, durcissement IAM à grande échelle, refonte réseau, mise en place de la surveillance), vous pouvez nous confier la réalisation, puis reprendre l'exploitation. Le code et la documentation restent vôtres : la réversibilité est acquise dès le premier jour. Voir notre approche de la migration cloud et de l'infrastructure DevOps.

3. Mettre en place une gouvernance et une exploitation continues

Un environnement cloud dérive en permanence : nouveaux comptes, nouveaux droits, nouvelles charges. Entre deux audits annuels, la posture se pilote en continu via Security Hub, AWS Config et GuardDuty, avec des alertes sur les écarts et des revues régulières. Pour les organisations qui ne veulent pas internaliser cette charge, l'infogérance cloud prend le relais : exploitation, surveillance, FinOps continu et maintien de la conformité dans le temps.

La séquence saine : audit → remédiation → gouvernance continue. L'audit redéfinit ce qu'il faut surveiller ; la surveillance maintient l'acquis ; l'audit suivant mesure le chemin parcouru et redresse la barre. C'est ce cycle, et non un audit isolé, qui transforme durablement la maîtrise d'un environnement AWS. La gouvernance cloud en est le cadre.

Pourquoi confier votre audit AWS à Architecte Cloud

• 12 ans d'expertise cloud, de nombreux projets accompagnés, un réseau de clients établi et une satisfaction client élevée.
• AWS Partner (Advanced Tier Services) et Microsoft Azure Solutions Partner, une double compétence qui favorise un conseil sans parti pris fournisseur.
• Prestataires et experts qualifiés disposant des certifications requises : AWS DevOps Engineer Professional, Solutions Architect, CISSP, FinOps Certified Practitioner, Azure Security Engineer.
• Démarche ISO 27001 et membre de la FinOps Foundation.
• Indépendance, réversibilité, langage clair : vous repartez plus autonome, avec un rapport et un code qui vous appartiennent.

Pour aller plus loin, explorez nos services d'audit et de conseil, notre expertise en cybersécurité cloud ou notre approche du conseil en architecture. Notre guide du cloud et notre page À propos détaillent notre démarche.

Prêt à y voir clair ? Lancez votre diagnostic en ligne, réponse sous 48 h ouvrées, ou contactez-nous pour cadrer un audit AWS adapté à votre environnement.

FAQ

Qu'est-ce qu'un audit AWS et à quoi sert-il ?

Un audit AWS est un examen méthodique et indépendant de votre environnement Amazon Web Services, qui mesure son niveau de sécurité, de maîtrise des coûts, de performance, de fiabilité et de conformité. Il aboutit à un rapport, un scoring de maturité et un plan d'action priorisé. Son but : transformer des angles morts (permissions trop larges, données exposées, factures qui dérivent) en décisions claires.

Comment faire un audit de sécurité AWS ?

On procède en quatre temps : cadrage et accès en lecture seule via un rôle IAM dédié ; scan automatisé avec des outils comme Prowler et ScoutSuite plus les outils natifs (Security Hub, Config) ; qualification manuelle des findings pour éliminer les faux positifs et les scorer selon une matrice risque/effort ; restitution sous forme de rapport et de plan de remédiation. L'examen porte sur IAM, le réseau, les données, la journalisation et la détection.

Quels sont les outils d'audit AWS (Trusted Advisor, Security Hub, Audit Manager) ?

AWS fournit Trusted Advisor (recommandations transverses), Security Hub (posture de sécurité consolidée et CSPM), AWS Config (suivi de configuration et conformité), Compute Optimizer (rightsizing) et Cost Explorer (coûts). Audit Manager automatise la collecte de preuves de conformité. À ces outils natifs s'ajoutent des scanners open source comme Prowler et ScoutSuite, qui apportent profondeur et reproductibilité.

Qu'est-ce qu'AWS Audit Manager et est-il payant ?

AWS Audit Manager automatise la collecte de preuves pour les audits de conformité (CIS, ISO 27001, PCI DSS, SOC 2). C'est un service facturé à l'usage. Point d'actualité important : AWS a annoncé la fin de sa commercialisation aux nouveaux clients à compter du 30 avril 2026. Les nouveaux projets ont donc intérêt à bâtir leur collecte de preuves sur Security Hub et les conformance packs d'AWS Config.

Combien coûte un audit AWS et combien de temps dure-t-il ?

Un audit AWS dure généralement de 2 à 5 jours, pour un budget indicatif de 3 500 à 8 000 € HT, sur devis selon le périmètre. Un compte unique simple se situe en bas de fourchette ; un environnement multi-comptes avec Kubernetes, IaC et exigences de conformité atteint le haut. L'audit FinOps inclus se rembourse souvent de lui-même dès les premiers quick wins.

Quelle est la différence entre l'audit Well-Architected Review et un audit de sécurité ?

Un Well-Architected Review suit la grille officielle d'AWS sur ses six piliers (excellence opérationnelle, sécurité, fiabilité, performances, coûts, durabilité) : c'est une revue d'architecture cadrée par le fournisseur. Un audit de sécurité creuse uniquement l'exposition (IAM, réseau, données, détection) selon des référentiels comme les CIS Benchmarks. Un audit AWS complet combine les deux et y ajoute la conformité réglementaire.

À quelle fréquence faut-il auditer son environnement AWS ?

Au minimum une fois par an, et à chaque événement majeur : migration, fusion, incident de sécurité, nouvelle exigence réglementaire ou changement d'équipe. Entre deux audits, la posture se suit en surveillance continue via Security Hub, AWS Config et GuardDuty. La surveillance continue détecte les dérives ; l'audit redéfinit périodiquement ce qu'il faut surveiller.

Comment réduire ses coûts AWS grâce à un audit FinOps ?

L'audit FinOps identifie d'abord le gaspillage direct (ressources orphelines, environnements de test allumés en permanence), puis le rightsizing des instances surdimensionnées via Compute Optimizer et Cost Explorer, puis les engagements pertinents (Savings Plans, Reserved Instances, Spot) et enfin la qualité du tagging. Une réduction de 20 à 35 % de la facture est fréquemment observée, sans garantie, selon la maturité de départ.

Quelles sont les bonnes pratiques de sécurité IAM sur AWS ?

Ne jamais utiliser le compte root au quotidien et le protéger par MFA ; généraliser le MFA à tous les utilisateurs ; appliquer le moindre privilège en bannissant les policies *:* ; préférer les rôles aux utilisateurs et centraliser via IAM Identity Center ; faire tourner et supprimer les clés d'accès inutilisées ; utiliser IAM Access Analyzer pour détecter les accès externes non intentionnels.

Un audit AWS aide-t-il à se mettre en conformité (RGPD, ISO 27001, DORA) ?

Oui. L'audit relie la configuration technique aux exigences réglementaires : chiffrement et traçabilité pour le RGPD (avec la répartition responsable de traitement / sous-traitant de l'article 28), preuves techniques pour une démarche ISO 27001, résilience opérationnelle et réversibilité pour DORA dans la finance, hébergement chez un partenaire certifié HDS pour la santé. L'audit ne délivre pas la certification : il en prépare et documente les preuves.

Quel est le modèle de responsabilité partagée AWS ?

AWS est responsable de la sécurité du cloud (datacenters, matériel, hyperviseur, disponibilité des services) ; vous êtes responsable de la sécurité dans le cloud (vos données, le chiffrement, IAM, les security groups, les correctifs de vos instances). La frontière varie selon le service : plus il est managé, plus la part d'AWS augmente. Un audit ne porte que sur votre part, celle que vous pouvez réellement corriger.

Quels livrables attendre d'un audit AWS externe ?

Trois livrables : un rapport structuré avec synthèse exécutive et findings détaillés par domaine et par pilier Well-Architected ; une grille de scoring de maturité par domaine ; un plan de remédiation priorisé sur 30/60/90 jours avec matrice risque/effort et quick wins FinOps chiffrés. Le rapport, le code IaC et les comptes restent votre propriété : exigez cette réversibilité de tout prestataire.

Quels sont les 6 piliers du Well-Architected Framework d'AWS ?

Le AWS Well-Architected Framework repose sur six piliers : l'excellence opérationnelle (exploiter et améliorer en continu), la sécurité (protéger données, systèmes et accès), la fiabilité (résister aux pannes et récupérer), l'efficacité des performances (bon dimensionnement et bons choix de services), l'optimisation des coûts (dépenser au plus juste) et la durabilité (réduire l'empreinte environnementale). Un audit AWS complet score chaque pilier et y ajoute la conformité réglementaire.

Peut-on obtenir des crédits AWS après un audit ?

Oui, mais via la voie spécifique du Well-Architected Review, pas via un audit indépendant. Le programme AWS Well-Architected peut accorder jusqu'à 5 000 $ de crédits par charge éligible, sous conditions, pour financer les remédiations issues du review mené avec le Well-Architected Tool. Un audit indépendant, lui, n'ouvre pas droit à des crédits AWS, c'est le prix de sa neutralité. La bonne stratégie consiste souvent à combiner les deux : un review pour les crédits, un audit indépendant pour une décision sans parti pris.

Combien de temps faut-il pour mettre en œuvre les recommandations d'un audit AWS ?

Les quick wins (MFA root, fermeture des security groups ouverts, blocage S3 public, activation de CloudTrail) se traitent en quelques jours. Les chantiers structurants (moindre privilège IAM, chiffrement généralisé, rightsizing, engagements FinOps) s'étalent sur 30 à 60 jours. Les transformations de fond (Landing Zone, PRA testé, reprise de l'IaC, conformité documentée) demandent 60 à 90 jours, voire plus selon la taille. Le plan 30/60/90 jours structure cette mise en œuvre.