Audit AWS : Un impératif stratégique pour une transformation cloud réussie

Chez TeamWork, nous accueillons régulièrement de nouveaux clients, pour une migration cloud ou pour fournir un Maintien en Condition Opérationnelle (MCO) via notre Global Delivery Center.

Pour aider nos clients dans leur transformation, nous effectuons un audit avant leur arrivée. Découvrons ensemble les bienfaits de cet exercice.

La nécessité d'un regard externe objectif

L'un des principaux écueils auxquels font face les entreprises dans leur parcours cloud réside dans leur propre perception de leur infrastructure. Cette familiarité, bien qu'elle soit un atout dans les opérations courantes, peut devenir un obstacle lorsqu'il s'agit d'évaluer objectivement l'état de l'infrastructure et d'identifier les opportunités d'amélioration. Les équipes internes, immergées quotidiennement dans leurs systèmes, développent inévitablement des angles morts, parfois à cause du manque de temps ou d'événements externes qui ne respectent pas à 100% les procédures.

Avez-vous le bon point de vue ?

Un audit externe apporte cette perspective critique nécessaire. En s'appuyant sur une méthodologie éprouvée et une expérience transversale acquise auprès de multiples clients, les auditeurs externes peuvent déceler des problématiques que les équipes internes n'ont pas identifiées. Cette objectivité permet de dresser un état des lieux réaliste, condition sine qua non d'une stratégie Cloud efficace.

Pour réaliser cette photo dans les meilleures conditions, il faut partager que cet audit n'est là que pour comprendre la vraie maturité de l'entreprise.

Il n'est pas là pour chercher des coupables, mais pour lister ce qui manque, que ce soit des procédures ou des documents. L'auditeur devra donc échanger avec des personnes de plusieurs horizons, pour pouvoir se faire une opinion au plus juste de la situation. Les équipes techniques seront bien évidemment mises à contribution, mais il peut être nécessaire d'échanger avec la direction ou les services administratifs pour comprendre certaines décisions ou certaines contraintes.

Notre méthodologie

Nous divisons l'audit en 3 parties.

Audit boîte noire

Nous partons de la facture AWS et nous identifions les services utilisés. Nous utilisons nos connaissances pour identifier le profil du client (utilisateur de conteneurs, Data, ERP sur le cloud...).

À partir de ces deux premiers points, nous effectuons une première analyse sur les faiblesses classiques, nous identifions les points qui doivent être discutés, les ressources sur- ou sous-utilisées, ainsi que les opportunités d'évolution.

Nous notons également les anti-patterns et les points sur lesquels nous avons des doutes, pour échanger ensuite avec les équipes et avoir les raisons qui ont mené à cette implémentation.

Nous en profitons pour faire une liste des ressources oubliées ou des points à revérifier :

• Il y a X volumes EBS non attachés. Est-ce que c'est voulu (ce n'est bien souvent pas le cas) ?
• Les alertes de budgets sont-elles à jour ?
• Une grande quantité de snapshots, etc.

Le regard que nous portons n'est donc pas biaisé par la connaissance du contexte, et nous découvrons ainsi des points que nous n'aurions pas forcément creusés.

Nous pouvons également utiliser les serveurs MCP d'AWS si le client nous donne son accord, pour profiter d'un autre angle de vue sur les ressources à auditer. Nous avons donc créé une bibliothèque de requêtes, ce qui accélère l'audit en boîte noire. Nous générons des rapports comme celui-ci :

📊 Analyse détaillée des rôles IAM
🔍 Rôles NON-managés par AWS (créés par l'utilisateur)
Basé sur l'analyse détaillée, voici les 10 rôles personnalisés identifiés :

1. Rôles Cloud Custodian (Gouvernance)

C7n-Mail - Notifications Cloud Custodian
✅ Permissions appropriées (SQS, SNS, SES, CloudWatch, Logs)
🎯 Usage : Lambda pour envoi d'emails de conformité

C7N-guardian ⚠️ ATTENTION
🚨 AdministratorAccess - Permissions très larges
🎯 Usage : Lambda Cloud Custodian avec accès complet

2. Rôles d'accès organisationnel

ORG_BreakGlass ⚠️ CRITIQUE
🚨 Administrator - Rôle d'urgence
🔗 Assumable depuis le compte 06079 (compte maître)
⚠️ Condition : Seulement par des utilisateurs (pas de services)

OrganizationAccessRole ⚠️ CRITIQUE
🚨 Administrator
🔗 Assumable depuis le compte 9054

3. Rôles techniques

GlueETL - AWS Glue ETL
✅ Permissions appropriées (AWSGlueServiceRole + S3FullAccess)
🎯 Usage : Jobs Glue pour traitement de données

ORG-SSM - Gestion EC2
✅ Permissions appropriées (SSM + S3ReadOnly)
🎯 Usage : Instances EC2 avec Systems Manager

SSM_Instance - Profil d'instance
✅ Permissions minimales (SSMManagedInstanceCore)
🎯 Usage : Instances EC2 basiques

4. Rôles AWS avec personnalisation

AmazonBedrockForAgents_* - Amazon Bedrock
✅ Rôle généré par AWS mais personnalisé
🎯 Usage : Agents Bedrock AI
🏭 Rôles managés par AWS



~70 rôles avec préfixes :
AWSServiceRoleFor* - Service-linked roles (path : /aws-service-role/)
AWSReservedSSO_* - Rôles AWS SSO
aws-controltower-* - Control Tower
AWS-QuickSetup-* - QuickSetup multi-régions


⚠️ Rôles à risque identifiés
🚨 Permissions excessives
C7N-guardian - AdministratorAccess pour Lambda
ORG_BreakGlass - Rôle d'urgence avec accès complet
OrganizationAccessRole - Accès admin cross-account

🔍 Recommandations de sécurité
Audit C7N-guardian - Vérifier si AdministratorAccess est vraiment nécessaire
Monitoring des rôles d'urgence - Alertes sur l'utilisation de ORG_BreakGlass
Révision des accès cross-account - Valider les comptes autorisés
Principe du moindre privilège - Réduire les permissions où possible

Nous commençons à organiser nos notes suivant les piliers du Well-Architected Framework

Audit boîte blanche

Nous commençons cette phase en parcourant toutes les documentations fournies par notre client. Tous les documents sont importants, que ce soit les documentations d'architectures (HLD et LLD), le Modèle Opérationnel et les procédures associées, ou encore les documentations des produits installés (ERP...).

Avec toutes ces nouvelles informations, nous pouvons revoir notre avis sur certains points de la phase 1.

Exemple :

• boîte noire : Il y a une base Oracle, cela pourrait être intéressant de passer sur PostgreSQL.
• boîte blanche : Ils utilisent JD Edwards comme ERP, PostgreSQL n'est pas supporté, oublions cette proposition.

Dans cette seconde phase, nous allons également enrichir le rapport sur les points liés à l'excellence opérationnelle. Ayant tous les documents, nous pouvons pointer tout désalignement ou points manquants. Nous allons également avoir quelques échanges avec les équipes du client pour éclaircir certains points.

Nous allons revoir notre stratégie d'audit pour mettre l'accent sur les points chauds de l'architecture. Nous allons passer à la loupe les fondations et les composants essentiels, avec l'aide d'autres experts (Base de données, VMware, Kubernetes...).

Restitution et réflexions sur les prochaines actions

Après un travail de mise en forme, nous présentons le résultat de l'audit à toutes les parties prenantes chez le client.

Pour faciliter les échanges et la définition de la roadmap, nous avons défini les indicateurs suivants :

• Maturité (M) : donne une appréciation de la connaissance du sujet évoqué.
  Exemple :

  • Point d'attention : Les budgets AWS sont revus une fois par an, nous vous conseillons de faire une revue tous les 2 ou 3 mois.
  • La maturité reste néanmoins avancée car le client a mis en place des alertes de budgets envoyées aux bons responsables.

• Difficulté (D) : une estimation de l'énergie nécessaire pour mettre en place cette proposition

  • Risque (R) : le degré d'attention à apporter et l'influence que ce changement peut avoir sur l'architecture ou la disponibilité du service

  • Gain (G) : que va-t-on gagner en effectuant cette modification. Le gain peut être de différente nature : sécurité, financier, résilience, opérationnel etc.

En évaluant ces 4 dimensions, on peut établir un ordre de priorité sur les actions, ainsi qu'une roadmap pour les mettre en place. Si une action est peu risquée avec une difficulté moyenne, nous pouvons la faire rapidement (Quick Wins) même si le gain est moyen.

C'est ici que l'on voit l'importance d'avoir toutes les parties prenantes. Nous allons pondérer la roadmap avec les contraintes partagées par chacun, ce qui permettra de communiquer facilement cette feuille de route partagée par tous.

Le Well-Architected Framework : Une boussole pour l'excellence

Les résultats de l'audit peuvent facilement s'intégrer avec le Well-Architected Framework d'AWS, qui constitue un référentiel reconnu dans l'industrie. Ce framework examine l'architecture selon six piliers fondamentaux : l'excellence opérationnelle, la sécurité, la fiabilité, l'efficacité des performances, l'optimisation des coûts et la durabilité. Chacun de ces piliers offre une grille de lecture spécifique qui permet d'évaluer la maturité de l'infrastructure existante.

Nous pouvons utiliser le Well-Architected Tool pour enregistrer les résultats dans une revue, et faire une nouvelle revue dans un an via cet outil. Ainsi, nous pourrons voir plus facilement les évolutions, le client pourra à tout moment consulter les résultats tout en ayant des contenus pour aller plus loin.

Bien qu'il n'existe pas d'outils pour automatiser la revue, nous pouvons néanmoins utiliser l'IA générative pour fournir un résultat intéressant qu'il faudra ensuite inclure dans l'outil. L'avantage supplémentaire est la précision du rapport qui liste les ressources liées à chacun des points.

🎯 Résumé de la révision
Score global : 6.7/10
La révision couvre les 6 piliers du AWS Well-Architected Framework :

🔒 Sécurité (7/10) - Bonne gouvernance mais permissions excessives à corriger
🏗️ Fiabilité (6/10) - Sauvegarde OK, mais manque de monitoring
⚡ Performance (5/10) - Services managés bien utilisés, mais pas de métriques
💰 Coûts (8/10) - Bien contrôlés pour un environnement sandbox
♻️ Durabilité (6/10) - Services serverless efficaces, optimisations possibles
🎯 Excellence opérationnelle (8/10) - Forte automatisation, documentation à améliorer
🚨 Actions prioritaires identifiées
Réduire les permissions des 3 rôles avec AdministratorAccess
Activer GuardDuty pour la détection de menaces
Configurer CloudWatch Alarms pour le monitoring
Documenter l'architecture et les procédures
📊 Points forts du compte
AWS Control Tower bien configuré
Cloud Custodian pour la gouvernance automatisée
Chiffrement S3 et protection des accès publics
Multi-régions avec AWS QuickSetup
Coûts maîtrisés pour un environnement de test

Exemple de détails sur la partie sécurité : 

#### Gouvernance et conformité
- **AWS Control Tower** activé avec baseline de sécurité
- **AWS Config** configuré pour la conformité
- **CloudTrail** activé pour l'audit (`aws-controltower-CloudTrail`)
- **Cloud Custodian** déployé pour la gouvernance automatisée

Contrôle et stabilité financière

Chez TeamWork, nous savons que 2 points sont essentiels pour assurer une stabilité financière de votre landing zone.

La facture AWS : Révélateur d'opportunités cachées

Au-delà de l'architecture technique, l'audit AWS inclut une analyse approfondie de la facturation. Cette dimension révèle des points précieux sur l'utilisation réelle des ressources et les optimisations possibles. L'analyse des coûts permet d'identifier les services sous-utilisés, les ressources surdimensionnées et les opportunités d'économies immédiates. Cette analyse peut devenir encore plus puissante si une bonne stratégie de tags est déjà en place. Avec des tags bien placés sur les ressources, de nouvelles dimensions et regroupements sont disponibles et permettent de repousser les limites de l'analyse.

Cette approche FinOps devient particulièrement critique dans un contexte où les coûts cloud peuvent rapidement échapper à tout contrôle. Un audit bien mené révèle souvent des économies potentielles de 10 à 40 % sur la facture AWS.

La dette technique : Un enjeu souvent sous-estimé

L'un des apports majeurs d'un audit externe réside dans sa capacité à quantifier et qualifier la dette technique accumulée. Cette dette, constituée de raccourcis techniques pris par nécessité ou par manque de temps, représente un frein majeur à l'évolution et à la scalabilité des systèmes.

L'audit permet de cartographier cette dette technique et de la prioriser selon son impact sur les performances, la sécurité et les coûts. Cette cartographie devient la base d'un plan de remédiation structuré.

De l'autoréflexion constructive à la feuille de route actionnable

L'audit AWS ne doit pas être perçu comme un exercice punitif, mais plutôt comme un catalyseur d'autoréflexion constructive. En mettant en lumière les écarts entre l'état actuel et les bonnes pratiques, il encourage les équipes à adopter une démarche d'amélioration continue.

Cette réflexion débouche naturellement sur l'élaboration d'une feuille de route claire et actionnable. Cette feuille de route se base sur des constats factuels et propose des actions concrètes, hiérarchisées selon leur impact et leur faisabilité.

L'audit permet également de mettre en place les bons indicateurs (KPIs) pour mettre en valeur les efforts et les gains apportés par les modifications mises en place. Ainsi, tous les gains (sécurité, résilience, méthodologie...) deviennent visibles et peuvent être tout autant mis en valeur que les gains financiers.

L'auditeur TeamWork dans cette phase s'efface un peu et laisse le devant de la scène aux Transition Managers (TM) et Service Delivery Managers (SDM) du GDC pour qu'ils puissent définir avec le client la feuille de route. Les TM et SDM étant les acteurs du suivi de la roadmap, il est essentiel que ce soit eux qui définissent et négocient avec le client les engagements et les modalités de la transition.

La transition en parallèle : action immédiate et vision à long terme

Une feuille de route efficace équilibre intelligemment les victoires rapides et les objectifs de transformation à long terme. Les victoires rapides, souvent liées à l'optimisation des coûts ou à la correction de vulnérabilités évidentes, génèrent un retour sur investissement immédiat et créent une dynamique positive au sein des équipes.

Parallèlement, les objectifs à long terme, tels que la modernisation de l'architecture ou l'implémentation de pratiques DevOps avancées, assurent la pérennité et l'évolutivité de la solution. Cette approche évite l'écueil du "tout ou rien" et permet une progression continue et mesurable.

Cet exercice devient plus simple avec les résultats de l'audit. Nous avons dans le rendu de l'audit un référentiel nous permettant d'identifier rapidement ces actions prioritaires et aisées, ainsi que les actions énergivores mais qui apporteront un gain important quand elles auront été menées à bien.

Vers une migration réussie et résiliente

L'audit AWS externe constitue le fondement d'une migration cloud réussie. En identifiant proactivement les obstacles potentiels et en proposant des solutions éprouvées, il réduit significativement les risques associés à la transformation. Il permet également d'identifier l'état actuel des ressources, pour permettre des discussions objectives entre le client et les équipes de TeamWork

L'audit AWS externe n'est pas un luxe, mais une nécessité stratégique pour toute organisation souhaitant tirer pleinement parti du cloud. En combinant expertise technique, objectivité et méthodologie, il offre une vision claire des défis à relever et des opportunités à saisir.