Landing zone AWS

Une landing zone AWS n'est pas un produit qu'on achète, ni une case à cocher : c'est la fondation sur laquelle reposera tout votre cloud pour les dix prochaines années. Mal posée, elle se paie en incidents de sécurité, en factures incontrôlées et en refontes coûteuses ; bien posée, elle devient invisible, et c'est précisément le signe qu'elle fonctionne. Cette page explique tout : la définition technique, les choix d'architecture, le chiffrage réel en euros, la conformité française, et la méthode pour la construire sans vous enfermer.

Qu'est-ce qu'une landing zone AWS ?

Une landing zone AWS est un environnement cloud multi-comptes pré-configuré, sécurisé et conforme aux bonnes pratiques du AWS Well-Architected Framework, conçu pour accueillir vos charges de travail dès le premier jour dans un cadre maîtrisé. Le terme image bien la chose : c'est la « zone d'atterrissage » où vos applications viennent se poser, sur une piste déjà balisée : identités, réseau, journalisation, garde-fous de sécurité et structure de comptes étant déjà en place.

Concrètement, une landing zone répond à une question simple que se posent toutes les organisations qui prennent AWS au sérieux : comment industrialiser la création d'environnements cloud sûrs, sans réinventer la sécurité et la gouvernance à chaque nouveau projet ? Plutôt que de laisser chaque équipe créer ses propres comptes AWS avec ses propres règles (la recette du chaos), on définit une fois pour toutes un socle commun, puis on distribue des comptes normalisés, déjà câblés aux bons standards.

Une landing zone bien conçue couvre cinq dimensions :

• L'organisation des comptes : une hiérarchie multi-comptes structurée via AWS Organizations.
• Les identités et les accès : une gestion centralisée des connexions humaines via IAM Identity Center.
• La sécurité et la traçabilité : journalisation centralisée, détection des menaces, chiffrement, archivage immuable des logs.
• Le réseau : une topologie de connectivité cohérente (souvent en hub-and-spoke) et, le cas échéant, la liaison à votre système d'information existant.
• La gouvernance : des garde-fous (guardrails) qui empêchent automatiquement les configurations dangereuses, et un modèle d'étiquetage qui rend les coûts lisibles.

À retenir. Une landing zone n'est pas une machine ni un service AWS unique. C'est un assemblage cohérent de services AWS (Organizations, Control Tower, IAM Identity Center, CloudTrail, Config, GuardDuty…) gouverné par du code, qui transforme « un compte AWS » en « une plateforme cloud d'entreprise ». La construire relève de l'architecture, pas du clic.

La landing zone est le premier chantier structurant de toute démarche de gouvernance cloud. Elle matérialise, dans la console AWS, les décisions de gouvernance que beaucoup d'organisations repoussent, et finissent par regretter d'avoir repoussées.

Pourquoi une architecture multi-comptes plutôt qu'un compte unique ?

C'est la décision fondatrice, et la plus contre-intuitive pour qui débute sur AWS. L'instinct pousse à tout mettre dans un seul compte « parce que c'est plus simple ». À l'échelle de l'entreprise, c'est l'inverse : le compte unique est une dette technique et un risque de sécurité qui grossissent avec vous.

Le modèle multi-comptes répond à quatre enjeux concrets.

Isolation et réduction du blast radius

Le blast radius (rayon de souffle) désigne l'étendue des dégâts qu'un incident peut provoquer. Dans un compte unique, une clé d'accès compromise, une erreur de configuration ou un script Terraform malheureux peuvent affecter toutes vos charges de travail : production, données clients, sauvegardes comprises. En isolant chaque environnement (production, recette, développement) et chaque grande charge dans des comptes distincts, on cloisonne le risque : un incident dans le compte de développement ne peut pas, par construction, détruire la production. C'est la même logique que les compartiments étanches d'un navire.

Gouvernance et séparation des responsabilités

Des comptes séparés permettent d'appliquer des politiques différenciées : l'équipe data n'a pas les mêmes droits que l'équipe web, l'environnement de production est verrouillé là où la sandbox reste ouverte à l'expérimentation. La séparation des responsabilités, exigence récurrente des référentiels de sécurité comme ISO 27001 et des audits réglementaires, devient native plutôt que bricolée à coups de politiques IAM complexes et fragiles.

Facturation et FinOps

Chaque compte AWS produit sa propre facture détaillée. Une architecture multi-comptes offre donc une ventilation native des coûts par environnement, par équipe ou par projet, sans dépendre uniquement de l'étiquetage. Combinée à la facturation consolidée (consolidated billing) du compte de gestion, elle permet d'agréger la dépense globale tout en gardant une lisibilité fine. C'est la première brique d'une démarche d'optimisation des coûts cloud sérieuse.

Limites de service et passage à l'échelle

Les quotas AWS (nombre de ressources, limites d'API) s'appliquent au niveau du compte. Répartir les charges sur plusieurs comptes éloigne les plafonds techniques et facilite le passage à l'échelle sans demande de quota permanente.

| Critère | Compte unique | Architecture multi-comptes | |---|---|---| | Blast radius | Maximal : tout est exposé | Cloisonné par compte | | Isolation des environnements | Logique (fragile) | Physique (par construction) | | Gouvernance | Politiques IAM complexes | Garde-fous par OU | | Lisibilité des coûts | Étiquetage uniquement | Facture native par compte | | Limites de service | Atteintes rapidement | Réparties | | Conformité (ISO, DORA…) | Difficile à démontrer | Séparation native des rôles |

Le bon réflexe. La question n'est pas « ai-je besoin de plusieurs comptes ? » mais « combien, et structurés comment ? ». Au-delà de trois ou quatre charges, ou dès qu'une exigence de conformité entre en jeu, le multi-comptes n'est plus une option : c'est le standard.

AWS Organizations et la structure des Organizational Units (OU)

AWS Organizations est le service qui fédère et gouverne vos comptes AWS. Il introduit la notion de compte de gestion (management account), au sommet de la hiérarchie, sous lequel se rattachent tous les autres comptes, regroupés dans des Organizational Units (OU), des unités organisationnelles qui fonctionnent comme des dossiers auxquels on applique des politiques.

La structure d'OU est l'ossature de votre landing zone. AWS recommande, dans son guide Organizing Your AWS Environment Using Multiple Accounts, une organisation par fonction plutôt que par projet. Une structure de référence ressemble à ceci :

Racine de l'organisation
├── Security OU
│   ├── Compte Log Archive (archivage immuable des journaux)
│   └── Compte Audit / Security Tooling (GuardDuty, Security Hub)
├── Infrastructure OU
│   ├── Compte Network (Transit Gateway, connectivité hybride)
│   └── Compte Shared Services (DNS, annuaires, outillage)
├── Workloads OU
│   ├── OU Prod
│   │   ├── Compte App A — Prod
│   │   └── Compte App B — Prod
│   └── OU Non-Prod
│       ├── Compte App A — Dev/Recette
│       └── Compte App B — Dev/Recette
├── Sandbox OU (expérimentation, budget plafonné, isolée du SI)
└── Suspended OU (comptes à désactiver)

Chaque OU a un rôle clair :

• Security OU : héberge les comptes les plus sensibles. Le compte Log Archive centralise tous les journaux de l'organisation en lecture seule ; le compte Audit (ou Security Tooling) concentre les outils de sécurité et donne aux équipes RSSI une vue transverse sans leur ouvrir les comptes de production.
• Infrastructure OU : regroupe ce qui est partagé entre charges : le réseau (Transit Gateway, VPN, Direct Connect) et les services communs (DNS, dépôts d'artefacts, annuaires).
• Workloads OU : accueille les applications métier, séparées Prod / Non-Prod pour appliquer des garde-fous plus stricts en production.
• Sandbox OU : un espace d'expérimentation libre mais cadré : budget plafonné, déconnecté du réseau d'entreprise, garde-fous empêchant l'exposition de données réelles.

Le piège classique. La structure d'OU est facile à dessiner et difficile à corriger une fois peuplée. Une mauvaise arborescence dès le départ (par exemple un découpage par équipe plutôt que par fonction de sécurité) se traduit, deux ans plus tard, par des migrations de comptes pénibles et des politiques incohérentes. C'est l'une des erreurs les plus coûteuses que nous corrigeons en mission.

AWS Control Tower : account factory et guardrails préconfigurés

AWS Control Tower est le service qui automatise la mise en place et la gouvernance d'une landing zone multi-comptes. Là où AWS Organizations fournit les briques (comptes, OU, politiques), Control Tower les assemble selon les bonnes pratiques AWS et maintient le tout dans un état conforme. C'est l'orchestrateur.

Control Tower apporte trois capacités majeures.

1. Une landing zone préconfigurée. À l'activation, il déploie automatiquement une structure de base : une Security OU avec un compte Log Archive et un compte Audit, la centralisation de CloudTrail et d'AWS Config, le chiffrement, et l'intégration d'IAM Identity Center pour l'accès fédéré. En quelques heures, vous disposez d'un socle conforme, là où une construction manuelle prendrait des semaines.

2. L'Account Factory. C'est l'usine à comptes (souvent appelée account vending machine) : un mécanisme de provisionnement qui crée de nouveaux comptes AWS déjà câblés aux bons standards : rattachés à la bonne OU, connectés à l'accès fédéré, soumis aux garde-fous, conformes au modèle réseau. Demander un nouveau compte devient une opération de quelques minutes au lieu d'un projet.

3. Les guardrails. Control Tower fournit une bibliothèque de garde-fous préconfigurés (appelés controls) que l'on active par OU pour empêcher ou détecter automatiquement les configurations à risque.

Control Tower convient particulièrement aux organisations qui veulent un socle robuste rapidement, sans bâtir toute la mécanique elles-mêmes. Sa contrepartie : il impose un cadre. Les organisations aux exigences très spécifiques (réseau atypique, conformité poussée, automatisation 100 % par code) lui préfèrent parfois une approche personnalisée ou le Landing Zone Accelerator, nous y revenons plus bas.

Service Control Policies (SCP) et guardrails

Les garde-fous sont le système immunitaire de la landing zone. Ils se déclinent selon deux axes.

Selon le moment d'action :

• Garde-fous préventifs : ils empêchent une action interdite avant qu'elle ne se produise. Sur AWS, ils s'appuient principalement sur les Service Control Policies (SCP), des politiques attachées aux OU qui définissent le périmètre maximal des permissions de tous les comptes en dessous. Exemple : interdire la désactivation de CloudTrail, ou bloquer la création de ressources hors des régions européennes (un levier précieux pour la souveraineté des données).
• Garde-fous détectifs : ils signalent une non-conformité après coup. Ils reposent sur AWS Config, dont les règles évaluent en continu la configuration des ressources et lèvent une alerte en cas d'écart, par exemple un bucket S3 rendu public ou un volume non chiffré.

Selon le niveau d'exigence, Control Tower classe ses controls en trois catégories : obligatoires (toujours actifs, non désactivables, ils protègent l'intégrité de la landing zone), fortement recommandés (bonnes pratiques que la plupart des organisations activent), et optionnels (à activer selon le contexte réglementaire ou métier).

Une SCP n'octroie jamais de permission : elle ne fait que restreindre. Un compte ne peut donc jamais dépasser le périmètre fixé par les SCP de ses OU parentes, même si un administrateur local lui accorde des droits IAM larges. C'est ce qui rend les SCP si puissantes pour la gouvernance d'entreprise : elles posent des limites infranchissables, au-dessus des administrateurs.

Exemple concret de SCP. Pour une entreprise soumise au RGPD souhaitant garantir que ses données ne quittent pas l'Europe, une SCP attachée à la racine refuse toute action dans les régions AWS hors eu-west-* et eu-central-*. Aucun compte, aucun administrateur ne peut alors déployer une ressource hors d'Europe : la contrainte est structurelle, pas déclarative.

La conception fine des SCP et des règles Config relève d'une expertise de sécurisation de l'infrastructure cloud : mal calibrées, elles bloquent les équipes ; trop laxistes, elles ne protègent rien.

IAM Identity Center : gestion centralisée des identités et des accès

Dans une architecture multi-comptes, la gestion des accès humains devient vite le point de friction majeur : personne ne veut gérer des dizaines d'utilisateurs IAM répliqués dans chaque compte. IAM Identity Center (anciennement AWS Single Sign-On / AWS SSO) résout ce problème en centralisant l'authentification et l'autorisation à l'échelle de toute l'organisation.

Son principe repose sur les permission sets : des modèles de permissions (par exemple « Administrateur réseau », « Lecteur facturation », « Développeur App A ») que l'on affecte à des utilisateurs ou des groupes, sur les comptes de leur choix. Un développeur se connecte à un portail unique et accède, en un clic et sans clé d'accès statique, aux seuls comptes et rôles qui lui sont attribués.

Les bénéfices sont directs :

• Fin des clés d'accès statiques sur les postes, donc une surface d'attaque drastiquement réduite. Les identifiants compromis sont la première cause d'incident sur AWS.
• Fédération avec votre annuaire existant (Active Directory, Entra ID, Okta…) : on gère les accès cloud depuis l'annuaire de l'entreprise, et un départ collaborateur coupe instantanément tous ses accès AWS.
• Authentification multifacteur (MFA) centralisée et imposée.
• Traçabilité : chaque accès est journalisé, ce qui simplifie les audits et la conformité.

IAM Identity Center est intégré nativement à Control Tower, mais s'utilise aussi dans une landing zone personnalisée. Dans les deux cas, c'est la pierre angulaire d'un accès maîtrisé, et l'un des premiers points qu'un audit de sécurité cloud examine.

Account Factory : le provisionnement automatisé des comptes

Le provisionnement de comptes est ce qui distingue une landing zone d'entreprise d'une simple collection de comptes. L'Account Factory (ou account vending machine) industrialise la création : on remplit un formulaire ou on déclenche un pipeline, et un nouveau compte naît déjà conforme : rattaché à la bonne OU, connecté à IAM Identity Center, soumis aux garde-fous, doté du réseau standard et des outils de sécurité.

Deux implémentations dominent :

• L'Account Factory de Control Tower, pilotée depuis la console ou via AWS Service Catalog. Simple, intégrée, idéale pour les équipes qui veulent une expérience guidée.
• Account Factory for Terraform (AFT), un cadre open source d'AWS qui orchestre le provisionnement de comptes Control Tower via des pipelines Terraform. C'est l'option des organisations matures qui veulent que tout, y compris la création de comptes, soit décrit par du code versionné, revu et auditable.

Pourquoi ça compte. Sans usine à comptes, chaque nouveau projet rouvre la même négociation : qui crée le compte, avec quels droits, quel réseau, quelle sécurité ? Avec une Account Factory, ces décisions sont prises une fois, codées, et appliquées identiquement à chaque fois. C'est la différence entre artisanat et industrie, et la condition d'un passage à l'échelle serein.

Sécurité et conformité : journalisation, détection, chiffrement

La sécurité d'une landing zone ne se résume pas à quelques garde-fous : c'est une chaîne complète, du journal à l'archive, en passant par la détection et le chiffrement. Voici les composants essentiels et leur rôle.

AWS CloudTrail (centralisé). CloudTrail enregistre chaque appel d'API dans vos comptes : qui a fait quoi, quand, depuis où. Dans une landing zone, un organization trail agrège ces journaux de tous les comptes vers le compte Log Archive. C'est la mémoire de votre cloud, indispensable aux enquêtes post-incident et aux audits.

AWS Config. Config inventorie en continu la configuration de vos ressources et son historique, puis évalue cette configuration au regard de règles (les garde-fous détectifs). Il répond à la question « ma ressource est-elle conforme, et l'a-t-elle toujours été ? ».

Amazon GuardDuty. Service de détection de menaces qui analyse les journaux (CloudTrail, DNS, flux VPC) par apprentissage automatique pour repérer les comportements suspects : exfiltration de données, instances compromises, accès anormaux. Activé à l'échelle de l'organisation, il couvre tous les comptes depuis le compte Audit.

AWS Security Hub. Il agrège et priorise les alertes de sécurité (GuardDuty, Config, scanners…) et mesure votre posture face à des référentiels standards (CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices). C'est le tableau de bord sécurité de l'organisation.

AWS KMS. Le service de gestion des clés de chiffrement. Dans une landing zone, on chiffre par défaut les données au repos (S3, EBS, RDS…) avec des clés gérées, dont l'usage est journalisé et contrôlé par politique.

Le compte Log Archive. Compte dédié, à accès très restreint, qui reçoit l'ensemble des journaux en écriture seule. Verrouillé contre la suppression (idéalement via S3 Object Lock pour une immuabilité de type WORM), il assure qu'un attaquant, même administrateur d'un compte compromis, ne puisse pas effacer les traces de son passage. C'est une exigence forte des audits réglementaires.

Ensemble, ces services matérialisent la part « cloud » du modèle de responsabilité partagée d'AWS : AWS sécurise l'infrastructure du cloud (datacenters, hyperviseur, réseau physique) ; vous sécurisez ce que vous mettez dans le cloud (configuration, identités, données, chiffrement). La landing zone est précisément l'outil qui vous permet d'assumer votre part de ce modèle, à l'échelle, sans repartir de zéro à chaque compte.

Conception réseau : VPC, Transit Gateway et connectivité hybride

Le réseau est la dimension la plus structurante et la plus difficile à corriger après coup. Une landing zone définit une topologie réseau cohérente, généralement organisée en hub-and-spoke (en étoile).

Les briques :

• Amazon VPC (Virtual Private Cloud) : le réseau privé isolé de chaque compte/charge, segmenté en sous-réseaux publics et privés, sur des plages d'adressage planifiées pour ne jamais se chevaucher (un plan d'adressage IP rigoureux est non négociable).
• AWS Transit Gateway : le concentrateur (le hub) qui interconnecte tous les VPC (les spokes) et les liens vers l'extérieur, via un point central unique. Il remplace l'enchevêtrement ingérable de connexions point à point (VPC peering) qui devient un cauchemar au-delà de quelques VPC.
• La connectivité hybride : pour relier votre cloud à vos datacenters ou bureaux, AWS Direct Connect (lien physique dédié, faible latence, débit garanti par l'opérateur) ou un VPN site-à-site (sur Internet, plus rapide à mettre en place, souvent en secours du Direct Connect).

Dans le modèle hub-and-spoke, le compte Network (dans l'Infrastructure OU) héberge le Transit Gateway et la connectivité hybride. Tous les VPC des comptes applicatifs s'y raccordent, ce qui centralise l'inspection du trafic, les passerelles sortantes et les règles de filtrage. Schématiquement :

        Datacenter / Bureaux
                │  (Direct Connect / VPN)
        ┌───────┴────────┐
        │  Compte Network │
        │ Transit Gateway │  ← le HUB
        └───┬────┬────┬───┘
            │    │    │       (les SPOKES)
        ┌───┘ ┌──┘ └──┐
     VPC App A  VPC App B  VPC Shared Services

Une conception réseau soignée dès la landing zone évite la double peine classique : un adressage mal planifié qui interdit toute interconnexion future, et une topologie point à point qui devient impossible à exploiter. C'est typiquement le genre de fondation dont la qualité ne se voit que des années plus tard, en bien comme en mal.

Les deux approches : Control Tower vs landing zone personnalisée

Il existe deux grandes voies pour construire une landing zone, et le bon choix dépend de votre maturité, de vos contraintes et de votre rapport à l'automatisation.

1. L'approche Control Tower (managée). AWS orchestre la landing zone pour vous, avec une expérience guidée et un socle conforme aux bonnes pratiques. Vous gagnez en rapidité et en simplicité de maintenance, au prix d'un cadre plus contraint. C'est le choix par défaut pour la majorité des organisations.

2. L'approche personnalisée (custom / IaC). Vous décrivez l'intégralité de la landing zone par Infrastructure as Code, généralement Terraform ou CloudFormation, sans Control Tower, ou en l'étendant. Vous obtenez une maîtrise totale (réseau atypique, exigences réglementaires fines, intégrations spécifiques) au prix d'un effort de construction et de maintenance supérieur. C'est la voie des organisations matures, des grands comptes et des contextes très réglementés.

Ces deux approches ne sont pas exclusives : on construit souvent sur Control Tower tout en codant les extensions en Terraform (via AFT). Le vrai sujet n'est pas « managé ou custom » mais « quel curseur entre simplicité et contrôle ». C'est l'une des premières décisions que nous aidons à trancher en mission, car elle conditionne tout le reste.

Infrastructure as Code : Terraform, CloudFormation et AFT

Quelle que soit l'approche, l'Infrastructure as Code (IaC) n'est pas une option : une landing zone se décrit, se versionne et se déploie par du code. Cliquer dans la console pour bâtir une fondation d'entreprise, c'est garantir l'irreproductibilité, le drift (l'écart silencieux entre le code et la réalité) et l'impossibilité d'auditer ce qui a été fait.

Les outils :

• Terraform : l'outil IaC le plus répandu, multi-cloud, avec un écosystème de modules très riche. C'est notre recommandation par défaut pour une landing zone, notamment pour sa portabilité et sa lisibilité. La maîtrise du state, des modules et du cycle plan/apply est ici déterminante, un sujet que nous détaillons côté consultant Terraform.
• AWS CloudFormation : l'IaC natif d'AWS, intégré au plus près des services et utilisé en interne par Control Tower (qui s'appuie sur des StackSets pour propager des ressources sur de multiples comptes).
• Account Factory for Terraform (AFT) : le cadre AWS qui marie Control Tower et Terraform, en provisionnant les comptes Control Tower via des pipelines Terraform. C'est le pont entre la robustesse managée de Control Tower et l'industrialisation par code.

Notre principe, non négociable. Le code IaC de votre landing zone vit dans vos dépôts Git, à votre nom, documenté et transférable. Nous ne pratiquons pas le code captif. Si vous décidez un jour de reprendre la main ou de changer de prestataire, vous emportez tout : c'est ce que nous appelons la réversibilité, et c'est ce qui maintient la fondation la vôtre. Voir notre approche de l'Infrastructure as Code en entreprise.

Landing Zone Accelerator on AWS (LZA) pour les charges réglementées

Pour les organisations soumises à des exigences de conformité lourdes (santé, finance, secteur public, défense), AWS propose le Landing Zone Accelerator on AWS (LZA), une solution open source qui déploie une landing zone bien plus complète et durcie que Control Tower seul. Le LZA est l'héritier et la généralisation de solutions antérieures comme l'AWS Secure Environment Accelerator (ASEA).

Ce qui distingue le LZA :

• Il s'appuie sur Control Tower et l'étend avec des dizaines de services de sécurité préconfigurés (chiffrement renforcé, journalisation exhaustive, segmentation réseau avancée, inspection du trafic).
• Il est piloté par des fichiers de configuration et déployé par pipeline, ce qui le rend reproductible et auditable.
• Il intègre des modèles alignés sur des cadres réglementaires exigeants (par exemple le secteur public ou la finance).

Sa contrepartie est sa richesse : le LZA est plus complexe à appréhender et à maintenir que Control Tower, et son coût de fonctionnement est supérieur. La documentation AWS situe le run d'une configuration de référence (type sandbox) autour de 430 USD par mois rien qu'en services de socle, un ordre de grandeur utile à garder en tête avant de l'adopter. Il se justifie quand la conformité est un enjeu de premier ordre ; pour un besoin standard, Control Tower suffit largement et coûte moins cher à exploiter.

Control Tower, LZA, AFT ou custom : le comparatif décisionnel

Le choix de l'outil de mise en œuvre détermine votre budget, votre délai et votre capacité d'évolution. Voici les critères qui comptent vraiment.

| Critère | Control Tower | LZA (Accelerator) | AFT (Account Factory for Terraform) | Custom Terraform | |---|---|---|---|---| | Maturité requise de l'équipe | Faible à moyenne | Élevée | Élevée | Très élevée | | Rapidité de mise en place | Rapide | Moyenne | Moyenne | Lente | | Niveau de personnalisation | Limité | Élevé | Élevé | Total | | Conformité réglementaire poussée | Correcte | Excellente | Bonne | Selon conception | | Tout en code (IaC) | Partiel | Oui (config) | Oui | Oui | | Coût d'exploitation (run) | Modéré | Plus élevé | Modéré | Variable | | Profil type | PME/ETI standard | Santé, finance, public | Grand compte « tout-code » | Besoin très spécifique |

En pratique, la décision se prend ainsi :

• Control Tower si vous voulez un socle conforme rapidement, sans contrainte réglementaire exceptionnelle. C'est le cas le plus fréquent.
• AFT si vous voulez Control Tower et l'industrialisation complète par Terraform, avec une équipe à l'aise sur l'IaC.
• LZA si la conformité (HDS, DORA, secteur public) est un enjeu de premier ordre et justifie la complexité supplémentaire.
• Custom Terraform seulement si un besoin très spécifique (réseau exotique, intégration tierce profonde) rend les solutions packagées trop rigides. À réserver aux équipes très matures.

Notre conseil indépendant. La sur-ingénierie est l'erreur la plus répandue. Beaucoup d'équipes choisissent le LZA ou le custom « pour être tranquilles » et héritent d'une plateforme qu'elles n'arrivent plus à maintenir. Le bon dimensionnement n'est pas le plus puissant : c'est celui que vos équipes sauront exploiter dans deux ans. Nous recommandons souvent de commencer simple (Control Tower) et de n'ajouter de la complexité que lorsqu'un besoin réel l'exige.

Conformité réglementaire française et européenne

C'est le grand angle mort des contenus existants, et pourtant le point de blocage n°1 des entreprises françaises. Une landing zone bien conçue est un levier de conformité majeur, parce qu'elle inscrit les exigences réglementaires dans la structure même de la plateforme, et non dans des procédures que personne ne suit.

RGPD. Le Règlement général sur la protection des données impose notamment la localisation maîtrisée des données et un encadrement strict de la sous-traitance (article 28). Une landing zone permet de contraindre structurellement le périmètre : SCP interdisant les régions hors UE, chiffrement KMS par défaut, journalisation complète des accès aux données. Côté rôles, la distinction responsable de traitement / sous-traitant se reflète dans la séparation des comptes et des responsabilités.

HDS (Hébergement de Données de Santé). Pour héberger des données de santé en France, l'hébergeur doit être certifié HDS. AWS dispose de régions et de services éligibles, et l'hébergement s'effectue chez un partenaire/hébergeur certifié HDS, la certification visant l'hébergeur, jamais votre configuration ni un intermédiaire de conseil. Une landing zone pour le secteur santé restreint les services et régions à ceux couverts par le périmètre HDS, et durcit la traçabilité. C'est un cas d'usage où le LZA prend tout son sens.

DORA (Digital Operational Resilience Act). Applicable depuis janvier 2025 au secteur financier et assurantiel européen, DORA exige la résilience opérationnelle, la maîtrise du risque lié aux prestataires tiers (dont les fournisseurs cloud) et la réversibilité. Une landing zone documentée, multi-région et dont le code IaC vous appartient répond directement à ces exigences : elle rend la résilience démontrable et la sortie possible.

ISO 27001. La norme de management de la sécurité de l'information valorise la séparation des responsabilités, la traçabilité et la maîtrise des accès, toutes natives dans une landing zone bien conçue. Architecte Cloud conduit ses missions dans une démarche ISO 27001.

Souveraineté. Pour les organisations sensibles à la localisation des données et au cadre juridique, on peut combiner régions européennes, SCP de verrouillage géographique et, selon le niveau d'exigence, des offres souveraines, sujets que nous arbitrons sans parti pris.

Ce que personne ne dit. La conformité ne s'ajoute pas à une landing zone après coup : elle se conçoit dedans. Restreindre les régions a posteriori sur une plateforme déjà peuplée est douloureux ; le faire dès la fondation via une SCP est gratuit. C'est tout l'intérêt de bien poser le socle au départ, un thème que nous approfondissons côté conformité cloud.

FinOps dès la fondation : maîtriser les coûts par construction

Attendre que la facture explose pour s'intéresser aux coûts est l'erreur classique. Une landing zone est l'occasion d'inscrire la maîtrise financière (le FinOps) dans la fondation, là où elle coûte le moins cher à mettre en place.

Les leviers à poser dès le départ :

• Modèle d'étiquetage (tagging) imposé. Une stratégie de tags cohérente (centre de coût, application, environnement, propriétaire) appliquée, et rendue obligatoire via des règles Config ou des SCP, est la condition de toute analyse de coûts ultérieure. Sans tags dès le jour 1, on étiquette à l'aveugle un parc déjà constitué : un chantier pénible et toujours incomplet.
• Budgets et alertes (AWS Budgets) par compte et par OU, pour être averti avant le dépassement, pas après.
• Cost Explorer et facturation consolidée pour analyser la dépense, native par compte grâce au multi-comptes.
• Engagements : poser dès la fondation une stratégie de Savings Plans et de Reserved Instances sur les charges stables, et exploiter les instances Spot sur les charges tolérantes aux interruptions.
• Rightsizing : dimensionner les ressources au plus juste, et éteindre les environnements hors usage (dev/recette la nuit et le week-end).

Une landing zone qui ignore le FinOps produit, à coup sûr, une facture que personne ne sait expliquer dix-huit mois plus tard. À l'inverse, une fondation bien étiquetée transforme la dépense cloud en information de pilotage. C'est le point de départ de toute optimisation des coûts cloud durable.

Erreurs fréquentes : ce que nous corrigeons en mission

De nombreuses missions et projets livrés laissent un catalogue d'erreurs récurrentes. Les connaître, c'est les éviter.

• Mauvaise structure d'OU dès le départ. Un découpage par équipe ou par projet au lieu d'un découpage par fonction de sécurité. La correction, plus tard, implique de déplacer des comptes et de réécrire des politiques, long et risqué.
• Sur-ingénierie. Adopter le LZA ou une landing zone custom pour un besoin que Control Tower couvrirait. Résultat : une plateforme que l'équipe interne ne sait plus exploiter et qui dépend d'un prestataire pour la moindre évolution.
• Drift IaC. Des modifications faites à la main dans la console qui s'écartent du code. Le code ne reflète plus la réalité, les déploiements deviennent imprévisibles, et la confiance dans l'IaC s'effondre. La discipline « tout passe par le code » se décide dès le jour 1.
• Oubli du modèle de tagging. Sans stratégie d'étiquetage imposée dès la fondation, l'analyse des coûts est impossible et le FinOps ne décolle jamais.
• Plan d'adressage IP improvisé. Des plages qui se chevauchent interdisent toute interconnexion future entre VPC ou avec le SI. Irréparable sans renumérotation lourde.
• Logs non immuables. Un compte Log Archive sans verrouillage (Object Lock) laisse un attaquant effacer ses traces. La traçabilité ne vaut que si elle est inviolable.
• Comptes au nom du prestataire. Des comptes AWS et un code IaC qui appartiennent au prestataire, pas au client. C'est le piège du lock-in : nous le combattons par principe.

Retour d'expérience. La majorité de nos reprises de landing zone ne concernent pas des erreurs techniques exotiques, mais ces fondamentaux négligés sous la pression du délai. Une fondation bâclée en deux semaines coûte des mois à reprendre. L'inverse (quelques jours de cadrage rigoureux) épargne des années de friction.

Landing zone AWS vs landing zone Azure : pour les décideurs multi-cloud

Si vous arbitrez entre AWS et Azure, ou pilotez les deux, les concepts se répondent, avec des différences de vocabulaire et de packaging.

| Concept | AWS | Azure | |---|---|---| | Cadre de référence | Well-Architected Framework | Cloud Adoption Framework (CAF) | | Hiérarchie de comptes | Organizations + OU | Management groups + abonnements | | Orchestrateur de landing zone | Control Tower / LZA | Azure Landing Zones (CAF) | | Garde-fous préventifs | Service Control Policies (SCP) | Azure Policy | | Identités centralisées | IAM Identity Center | Microsoft Entra ID | | IaC privilégié | Terraform / CloudFormation | Terraform / Bicep | | Détection de menaces | GuardDuty / Security Hub | Microsoft Defender for Cloud |

La philosophie est commune : multi-comptes (ou multi-abonnements), garde-fous centralisés, identités fédérées, tout en code. Les différences tiennent au modèle d'identité (Entra ID très intégré côté Azure) et au packaging des landing zones. Si votre SI est déjà fortement Microsoft, l'intégration Entra ID pèse dans la balance. Notre conseil reste indépendant : nous accompagnons aussi les projets de landing zones Azure et les décideurs architecte Azure sans pousser une plateforme plutôt qu'une autre.

Combien coûte une landing zone AWS ? Durée et livrables

Voici la transparence que le SERP français n'offre pas. Il faut distinguer deux types de coûts : le build (le projet de construction) et le run (l'exploitation mensuelle).

Le coût de build (projet)

Le budget indicatif d'un projet de landing zone AWS conçu et livré par Architecte Cloud se situe dans une fourchette de 10 000 à 25 000 €, établie sur devis selon le périmètre. Ce budget dépend principalement de :

• l'approche retenue (Control Tower standard vs LZA réglementé vs custom) ;
• le nombre de comptes et la complexité de la structure d'OU ;
• les exigences de conformité (RGPD seul, ou HDS/DORA) ;
• la complexité réseau et l'interconnexion au SI existant ;
• le périmètre de transfert de compétences souhaité.

Cadre de transparence. Cette fourchette est indicative, jamais un prix ferme : seul un cadrage permet d'établir un devis précis. Nos honoraires sont clairs et sans engagement caché, l'une de nos convictions d'indépendant.

Le coût de run (mensuel)

Le run d'une landing zone correspond au coût des services de socle (Config, GuardDuty, CloudTrail, KMS…), distinct du coût de vos charges applicatives. Pour donner un ordre de grandeur public et vérifiable, AWS documente le run d'une configuration LZA de référence (sandbox) autour de 430 USD par mois en services de socle. Une landing zone Control Tower standard se situe en deçà. Le chiffre exact dépend du volume de journaux, du nombre de comptes et des services activés, il se chiffre précisément lors du cadrage.

Durée et planning

La mise en œuvre du socle se déroule typiquement sur 5 à 12 jours ouvrés, selon les jalons suivants :

1. Audit & cadrage (1-2 j) : compréhension du SI, des contraintes de conformité, de la cible. Choix de l'approche (Control Tower / LZA / custom).
2. Design HLD/LLD (1-3 j) : architecture détaillée : structure d'OU, plan réseau et d'adressage, garde-fous, modèle d'identités, stratégie de tagging.
3. Build IaC (2-5 j) : déploiement du socle par code (Terraform/Control Tower), comptes de sécurité, journalisation, réseau, Account Factory.
4. Transfert de compétences (1-2 j) : documentation remise, formation de vos équipes, remise du code dans vos dépôts.
5. Run / infogérance (optionnel) : exploitation et évolution dans la durée.

Livrables remis

• L'environnement AWS multi-comptes opérationnel, à votre nom.
• Le code IaC complet, versionné dans vos dépôts Git.
• La documentation d'architecture (HLD/LLD), le plan d'adressage et le catalogue des garde-fous.
• Le modèle de tagging et la configuration FinOps initiale (budgets, alertes).
• Le transfert de compétences et un point d'entrée pour l'infogérance cloud d'entreprise si vous le souhaitez.

PRA/PCA et résilience : penser la continuité dès la fondation

La résilience ne s'improvise pas après l'incident. Une landing zone bien conçue prépare le terrain de la continuité d'activité.

• Multi-région : la structure multi-comptes et un réseau cohérent facilitent le déploiement de charges critiques sur deux régions AWS, pour résister à la perte d'une région entière.
• RTO / RPO : on définit, par charge, le temps de reprise (RTO) et la perte de données acceptable (RPO) visés, ils orientent l'architecture de sauvegarde et de réplication.
• Sauvegardes centralisées et immuables : pilotées et isolées dans un compte dédié, hors d'atteinte d'un compte de production compromis (une protection clé contre les rançongiciels).
• Tests de bascule : la résilience ne se présume pas, elle se vérifie : DORA l'exige d'ailleurs explicitement pour le secteur financier.

La landing zone ne remplace pas un projet de PRA cloud ou de PCA, mais elle en pose les fondations structurelles : sans isolation des comptes ni réseau multi-région cohérent, toute stratégie de reprise reste fragile.

Cas d'usage sectoriels

La landing zone se décline selon le secteur et ses contraintes :

• Santé : restriction aux services et régions du périmètre HDS, hébergement chez un partenaire certifié HDS, traçabilité renforcée. Voir secteur santé.
• Finance & assurance : conformité DORA, résilience multi-région démontrable, maîtrise du risque tiers et réversibilité documentée. Voir secteur finance.
• Industrie : interconnexion au SI et aux sites de production, connectivité hybride (Direct Connect), cloisonnement OT/IT. Voir secteur industrie.
• Éditeurs SaaS / scale-ups : isolation par client (compte par tenant pour les plus exigeants), Account Factory intensive, FinOps natif pour piloter une croissance rapide. Voir secteur SaaS.

Chaque secteur ajuste le curseur entre Control Tower et LZA, et le périmètre des garde-fous. Découvrez l'ensemble de nos secteurs d'intervention.

Notre méthode d'accompagnement

Architecte Cloud est un intermédiaire indépendant qui met en relation avec des prestataires d'expertise et d'infogérance cloud sur Microsoft Azure et AWS, du conseil à l'exploitation. Notre accompagnement landing zone suit cinq étapes :

1. Audit & cadrage. Nous partons de votre SI, de vos contraintes de conformité et de votre cible. Pas de solution sur étagère : un diagnostic d'abord. C'est l'objet de notre audit d'infrastructure cloud.
2. Design HLD/LLD. Architecture détaillée et arbitrages explicités en langage clair (coûts, risques, délais) pour la DSI comme pour la direction générale.
3. Build IaC. Construction par code versionné, dans vos dépôts, avec les garde-fous, la sécurité et le réseau.
4. Transfert de compétences. Documentation, formation, remise du code. Vous repartez autonome.
5. Run 24/7 (optionnel). Exploitation et évolution continue si vous le souhaitez, sans jamais vous enfermer.

Ce qui nous distingue tient en trois mots : indépendance (conseil sans parti pris Azure/AWS, coûts clairs, aucun engagement caché), autonomie (tout ce qui est construit vous appartient : code IaC, comptes, documentation) et réversibilité (vous pouvez reprendre la main ou changer de prestataire à tout moment). Nos atouts : un réseau de prestataires expérimentés, partenaires Microsoft Azure et AWS (Advanced Tier Services), disposant des certifications requises (AWS DevOps Engineer Pro, Azure Solutions Architect Expert, CISSP, FinOps Certified Practitioner), en démarche ISO 27001, membre de la FinOps Foundation.

Prochaine étape. Une landing zone se décide sur un diagnostic, pas sur une brochure. Lancez votre audit en ligne ou contactez-nous : réponse sous 48 h ouvrées. Et pour situer la landing zone dans la démarche globale de gouvernance cloud, ou bâtir un Cloud Center of Excellence (CCoE) et une culture DevOps cloud en entreprise, nous vous accompagnons de bout en bout.

FAQ

Qu'est-ce qu'une landing zone AWS ?

Une landing zone AWS est un environnement cloud multi-comptes pré-configuré, sécurisé et conforme aux bonnes pratiques du Well-Architected Framework. Elle fournit, dès le départ, une structure de comptes (via AWS Organizations), une gestion centralisée des identités (IAM Identity Center), une journalisation et une détection des menaces, un réseau cohérent et des garde-fous de gouvernance. C'est la fondation sur laquelle déployer vos charges de travail dans un cadre maîtrisé.

Pourquoi mettre en place une landing zone sur AWS ?

Pour industrialiser la création d'environnements cloud sûrs et conformes, sans réinventer la sécurité à chaque projet. Une landing zone réduit le blast radius (en isolant les environnements dans des comptes distincts), centralise la gouvernance, rend les coûts lisibles par compte et inscrit la conformité dans la structure même de la plateforme. Elle vous fait gagner des semaines de mise en place et évite des refontes coûteuses ultérieures.

Quelle est la différence entre AWS Control Tower et une landing zone ?

Une landing zone est le résultat : l'environnement multi-comptes structuré et sécurisé. AWS Control Tower est l'outil qui automatise sa mise en place et sa gouvernance. Control Tower déploie une landing zone préconfigurée, fournit l'Account Factory pour créer des comptes normalisés et applique des garde-fous. On peut aussi construire une landing zone sans Control Tower, par Infrastructure as Code (Terraform).

Quelle est la différence entre Landing Zone Accelerator et Control Tower ?

Control Tower fournit un socle conforme et rapide à activer, adapté à la plupart des organisations. Le Landing Zone Accelerator on AWS (LZA) s'appuie sur Control Tower et l'étend avec une sécurité et une conformité bien plus poussées, destinées aux charges fortement réglementées (santé, finance, secteur public). Le LZA est plus complet mais plus complexe à exploiter et plus coûteux en run ; Control Tower suffit pour un besoin standard.

Combien coûte une landing zone AWS ?

Il faut distinguer le build et le run. Le projet de construction (build) représente un budget indicatif de 10 000 à 25 000 €, sur devis selon le périmètre (approche, nombre de comptes, conformité, réseau). Le run mensuel correspond aux services de socle : AWS documente une configuration LZA de référence autour de 430 USD/mois, une landing zone Control Tower standard se situant en deçà. Le chiffre exact se détermine lors du cadrage.

Combien de temps faut-il pour déployer une landing zone AWS ?

La mise en œuvre du socle se déroule typiquement sur 5 à 12 jours ouvrés : audit et cadrage, design HLD/LLD, build par Infrastructure as Code, puis transfert de compétences. La durée varie selon l'approche (Control Tower est plus rapide qu'une landing zone personnalisée ou LZA), la complexité réseau et les exigences de conformité.

Quels sont les composants d'une landing zone AWS ?

Les principaux composants sont : AWS Organizations et la structure d'OU (Security, Infrastructure, Workloads, Sandbox) ; les comptes Log Archive et Audit ; IAM Identity Center pour les identités ; les garde-fous (SCP préventives, règles AWS Config détectives) ; la journalisation CloudTrail centralisée ; la détection avec GuardDuty et Security Hub ; le chiffrement KMS ; et le réseau (VPC, Transit Gateway, connectivité hybride).

Qu'est-ce qu'AWS Organizations et une Organizational Unit (OU) ?

AWS Organizations est le service qui fédère et gouverne plusieurs comptes AWS sous un compte de gestion. Une Organizational Unit (OU) est un regroupement de comptes, comparable à un dossier, auquel on applique des politiques communes, notamment des Service Control Policies. Les OU structurent la landing zone par fonction (Security, Infrastructure, Workloads, Sandbox), ce qui permet d'appliquer des règles différenciées selon la sensibilité des comptes.

Qu'est-ce qu'une Service Control Policy (SCP) ?

Une Service Control Policy (SCP) est une politique attachée à une OU (ou à la racine) qui définit le périmètre maximal des permissions de tous les comptes situés en dessous. Une SCP ne donne jamais de droits : elle ne fait que les restreindre. C'est un garde-fou préventif puissant (par exemple interdire la désactivation de CloudTrail ou bloquer les régions hors d'Europe) qui s'impose même aux administrateurs des comptes concernés.

Comment sécuriser une landing zone AWS ?

La sécurité repose sur une chaîne complète : isolation des environnements dans des comptes distincts, garde-fous préventifs (SCP) et détectifs (AWS Config), identités centralisées sans clés statiques (IAM Identity Center avec MFA), journalisation CloudTrail centralisée vers un compte Log Archive immuable, détection des menaces (GuardDuty, Security Hub) et chiffrement par défaut (KMS). Cette architecture matérialise votre part du modèle de responsabilité partagée AWS.

Faut-il utiliser Terraform ou CloudFormation pour une landing zone AWS ?

Les deux fonctionnent ; le choix dépend du contexte. Terraform est multi-cloud, très répandu, avec un riche écosystème de modules : c'est notre recommandation par défaut, notamment pour sa portabilité. CloudFormation est l'IaC natif d'AWS, utilisé en interne par Control Tower. Account Factory for Terraform (AFT) combine Control Tower et Terraform pour industrialiser le provisionnement de comptes. L'essentiel est que tout soit décrit par du code versionné.

Quelle est la différence entre une landing zone AWS et une landing zone Azure ?

Les concepts se répondent : la hiérarchie multi-comptes d'AWS (Organizations + OU) correspond aux management groups et abonnements d'Azure ; Control Tower/LZA correspond aux Azure Landing Zones du Cloud Adoption Framework ; les SCP correspondent à Azure Policy ; IAM Identity Center à Microsoft Entra ID. La philosophie est commune. Les différences tiennent au modèle d'identité (Entra ID très intégré) et au packaging des landing zones.

Comment une landing zone AWS gère-t-elle la conformité (RGPD, HDS, ISO 27001) ?

Elle inscrit les exigences dans la structure de la plateforme. Pour le RGPD, des SCP restreignent les régions à l'Europe, le chiffrement KMS est imposé et les accès journalisés (article 28 sur la sous-traitance). Pour la santé, on restreint le périmètre aux services et régions couverts par un hébergeur certifié HDS. La séparation native des responsabilités sert la démarche ISO 27001, et la réversibilité documentée répond à DORA pour la finance.