Comparaison
AWS Control Tower ou zone d’atterrissage sur mesure
Pour la plupart des organisations qui n’utilisent qu’AWS, Control Tower est le bon point de départ : le service n’entraîne aucuns frais supplémentaires, AWS assure la maintenance du moteur, et la version 4.0 de la zone d’atterrissage a rendu ses intégrations facultatives. Landing Zone Accelerator ajoute un socle étendu, aligné sur des cadres de conformité, mais fonctionne comme un pipeline CDK écrit par AWS que vous déployez, déboguez et mettez à niveau ; un socle Terraform ou OpenTofu sur mesure convient quand vos fournisseurs infonuagiques ou votre structure ne cadrent ni avec l’un ni avec l’autre, et que vous acceptez de prendre en charge chaque ligne de code. Les trois peuvent permettre à votre équipe de provisionner un compte à partir d’un dépôt — la vraie différence, c’est à qui appartient le code que vous lisez quand quelque chose casse.
Fin 2026, il existe trois façons sérieuses de bâtir une zone d’atterrissage AWS multicompte. On les présente souvent comme interchangeables. Elles ne le sont pas : ce qui les distingue, c’est de savoir qui écrit le code qui transforme vos intentions en comptes, et qui doit le mettre à niveau.
| AWS Control Tower | Landing Zone Accelerator (LZA) | Terraform / OpenTofu sur mesure | |
|---|---|---|---|
| Nature | Un service AWS géré | Une solution AWS à code source ouvert que vous déployez et exploitez | Vos modules, sur les API d’AWS Organizations |
| Vos intentions sont décrites dans | Les paramètres de la zone, les contrôles et les bases de référence, gérés par son API ou par Terraform | Des fichiers de configuration YAML, dans Git ou S3 | Votre dépôt |
| Le moteur | Géré par AWS ; AFT ajoute un compte de pipeline que vous exploitez | L’application CDK d’AWS, dans votre CodePipeline | Vos modules, votre CI |
| « Dérive » signifie | Une ressource de Control Tower modifiée hors de Control Tower | L’état réel s’écarte du YAML ; la prochaine exécution du pipeline tranche | Ce que montre un plan exécuté à intervalles réguliers |
| Mises à niveau | Une nouvelle version de la zone, puis les comptes membres | Une nouvelle branche de version, puis une exécution complète du pipeline | Aucune cadence imposée, et aucune amélioration livrée |
| Modèle de prix | Aucuns frais pour le service ; vous payez ce qu’il configure | Vous payez les services AWS qu’elle exécute et déploie | Vous payez ce que vous déployez, plus l’ingénierie |
Les trois options peuvent réussir le test du compte 51
Dans Une zone d’atterrissage que vous ne pouvez pas appliquer vous-même n’est que le dépôt de quelqu’un d’autre, le test d’acceptation tenait en une question : un ingénieur qui n’a pas participé à la construction peut-il provisionner, à partir du dépôt, un compte qui hérite de tous les garde-fous ? Bien mises en place, les trois options le réussissent : une demande de compte AFT, une nouvelle entrée dans le fichier accounts-config.yaml de LZA ou un appel à votre propre module de provisionnement.
Il faut donc poser une deuxième question : quand le provisionnement échoue, ou qu’un garde-fou doit changer, qui a écrit le code que vous lisez ? La réponse détermine votre modèle de dérive et la facture de vos mises à niveau.
Quand Control Tower est la bonne réponse
Si vous n’utilisez qu’AWS et que votre structure est classique, commencez ici. Le service lui-même n’entraîne aucuns frais supplémentaires ; vous payez ce qu’il configure, comme AWS Config et CloudTrail. La version 4.0 de la zone d’atterrissage, sortie en novembre 2025, a rendu facultatives les intégrations Config, CloudTrail, Security Roles et Backup, n’exige plus d’OU Security et permet une configuration minimale, limitée aux contrôles. Depuis octobre 2025, l’inscription automatique, si vous l’activez, applique les bases de référence et les contrôles d’une OU à tout compte qu’on y déplace, peu importe l’outil qui l’a créé.
Vous ne renoncez pas au code pour autant. Le fournisseur Terraform pour AWS gère la zone d’atterrissage, ses contrôles et ses bases de référence comme des ressources. Au-delà de l’Account Factory de la console, qui repose sur Service Catalog, Account Factory for Terraform (AFT) transforme les demandes de compte en flux GitOps sur Terraform Community Edition, HCP Terraform ou Terraform Enterprise ; OpenTofu ne figure pas sur la liste d’AWS. En 2026, AFT a ajouté les exécutions en mode plan seulement, et il peut réappliquer les personnalisations quand un compte change d’OU. Son déploiement par défaut comprend une passerelle NAT et des points de terminaison PrivateLink, que vous payez.
Ce que vous cédez, c’est la paternité du moteur. Les ressources que Control Tower crée vous appartiennent ; la logique qui les crée et les réconcilie appartient à AWS. La dérive se définit selon les règles d’AWS : modifiez une SCP gérée, ou déplacez un compte d’une OU à une autre sans inscription automatique, et vous devrez corriger la situation à la manière de Control Tower. Les mises à niveau arrivent sous forme de versions de zone d’atterrissage que vous appliquez, puis propagez aux comptes membres, généralement en réenregistrant les OU. Et les versions changent le comportement : dans la version 4.0, les notifications de dérive sont passées de SNS à EventBridge, et désactiver la journalisation centralisée supprime désormais les ressources du compte de journalisation au lieu de simplement couper le journal de suivi. Lisez les changements clés de la version 4.0 avant de lancer la mise à jour, et choisissez votre Région d’origine avec soin : selon AWS, elle ne peut plus être modifiée après la mise en place.
Quand Landing Zone Accelerator convient
LZA s’adresse aux environnements réglementés qui veulent, dès le premier jour, un socle étendu et aligné sur des cadres de conformité. AWS la décrit comme une solution à faible code qui couvre plus de 35 services et se déploie dans toutes les Régions, y compris AWS GovCloud (US). Elle peut créer et gérer Control Tower pour vous, ou fonctionner avec AWS Organizations seulement.
Le piège, c’est le moteur. LZA est une volumineuse application CDK qu’AWS écrit et que vous exécutez : un pipeline d’installation et un pipeline principal qui synthétisent et déploient du CloudFormation dans vos comptes. Votre YAML vous appartient, mais quand une étape échoue, vous déboguez des modèles générés par du code que vous n’avez pas écrit. Une mise à niveau peut changer le sens de votre configuration, pas seulement ajouter des fonctionnalités. La version 1.16.0 (juillet 2026) s’est mise à réconcilier les associations et les propagations des tables de routage Transit Gateway pour qu’elles correspondent exactement à network-config.yaml, en supprimant celles créées à la main ; ses propres notes de version recommandent d’ailleurs de passer plutôt à la 1.16.1. L’empreinte n’est pas légère non plus : l’estimation de coûts d’AWS pour la configuration d’exemple, au repos et sans charge de travail, est d’environ 430 $ US par mois, principalement pour CloudTrail et la réseautique VPC.
Quand un socle sur mesure vaut son coût
Écrivez le vôtre quand les options gérées vous résistent : plusieurs fournisseurs infonuagiques à gérer selon une seule approche, une structure d’organisation ou un ensemble de contrôles qui ne cadre pas avec elles, ou une équipe de plateforme qui revoit déjà chaque changement sous forme de plan Terraform. Les briques de base sont là : les politiques de contrôle des services, les politiques de contrôle des ressources et les politiques déclaratives d’AWS Organizations pour des services comme EC2, S3 et Security Hub, toutes gérées par le même fournisseur Terraform.
Le prix à payer : tout ce que Control Tower mettrait en place s’ajoute à votre carnet de tâches — le journal de suivi CloudTrail de l’organisation, l’enregistrement Config, la configuration d’IAM Identity Center, l’archive des journaux et les rôles d’audit, le provisionnement des comptes et la détection de la dérive. Personne ne vous impose de mise à niveau, donc aucune ne vient rien casser ; mais personne n’ajoute non plus le prochain contrôle utile à votre place.
Une voie médiane que nous apprécions : gérez vous-même la structure, le provisionnement et le réseau dans Terraform, et activez les contrôles gérés de Control Tower, en mode contrôles seulement, sur les OU que votre module remplit.
Comment choisir
- AWS seulement, structure classique, petite équipe de plateforme : Control Tower, configuré sous forme de code avec le fournisseur Terraform ou AFT.
- Charges de travail réglementées, GovCloud, ou socle de conformité à démontrer rapidement : LZA, habituellement par-dessus Control Tower — si votre équipe accepte d’exploiter CodePipeline et de lire du CDK.
- Plusieurs fournisseurs infonuagiques, une plateforme Terraform existante, ou une structure que Control Tower ne peut pas exprimer : un socle sur mesure, éventuellement jumelé à Control Tower en mode contrôles seulement.
- Quel que soit votre choix : consignez la décision dans un dossier de décision d’architecture (ADR) qui nomme le responsable des mises à niveau.
Une Construction du socle infonuagique commence par cette décision, mise par écrit, et livre la réponse sous forme de Terraform dans votre dépôt — Control Tower piloté par son API, ou un socle AWS Organizations que nous écrivons. Dans les deux cas, le résultat est le même : votre équipe provisionne le prochain compte sans nous.