Landing zone Azure

Ce que nous construisons

Nous déployons des landing zones enterprise-scale alignées sur le cadre d’adoption du nuage de Microsoft, écrites en code. Rien n’est cliqué dans le portail : l’ensemble peut être reconstruit, relu en pull request et expliqué à un auditeur.

Groupes d’administration et politiques. Une hiérarchie qui correspond à votre organisation réelle : unité d’affaires, environnement ou frontière réglementaire. Azure Policy impose région, étiquetage, chiffrement, SKU autorisés et paramètres de diagnostic au niveau où un propriétaire d’abonnement pressé ne peut pas les contourner.

Identité. Locataire Microsoft Entra ID, accès conditionnel, gestion des accès privilégiés, comptes de secours, et un modèle de rôles qui accorde l’accès que le travail exige plutôt que Propriétaire sur tout. C’est le socle de la cybersécurité et Entra ID.

Réseau. Topologie hub and spoke, Azure Firewall ou boîtier tiers, points de terminaison privés pour les services PaaS, zones DNS privées, connectivité hybride vers ce qui reste sur site. L’exposition publique est l’exception, et elle est documentée.

Observabilité et coûts. Log Analytics centralisé, diagnostics appliqués par politique, Microsoft Defender for Cloud au bon palier, budgets et alertes d’anomalie par abonnement.

Pipelines de déploiement. GitHub Actions ou Azure DevOps, plan à l’ouverture de la pull request et application à la fusion, sur identifiants fédérés OIDC plutôt que sur des secrets permanents. Le détail est dans DevOps et infrastructure en code.

Une landing zone telle qu’elle est réellement déployée Quatre niveaux, dans cet ordre : groupe de gestion, abonnement, groupe de ressources, puis les ressources elles-mêmes. La politique est affectée en haut et héritée jusqu’en bas, si bien qu’un propriétaire d’abonnement pressé ne peut pas la désactiver. La charge de travail tourne dans des Container Apps du rayon, et rejoint sa base de données par un point de terminaison privé plutôt que par l’internet public.

Racine du locataire Groupe de gestion mg-root Tout ce qui est en dessous en hérite, y compris la convention de nommage et d’étiquetage que suivent ces noms.

Azure Policy, affectée ici, héritée par tout abonnement créé ensuite

Régions autorisées : canadacentral et canadaeast, et rien d’autre
Étiquettes obligatoires : propriétaire, centre de coût, environnement, classification des données
Chiffrement au repos imposé, accès réseau public refusé sauf exception déposée
Paramètres de diagnostic dirigés automatiquement vers l’espace de travail Log Analytics

Groupes de gestion

Groupe de gestion Plateforme mg-platform Connectivité, identité et gestion. Propriété de l’équipe plateforme, pas d’un projet.
Groupe de gestion Landing zones mg-landing-zones Là où vivent les charges de travail. Un abonnement par application et par environnement, pour que le coût ait une frontière.

Abonnements

Abonnement Connectivité sub-connectivity Le concentrateur, et rien d’autre. Aucune charge de travail n’y est jamais déployée.
Abonnement Gestion sub-management Journalisation, plans Microsoft Defender for Cloud, budgets et alertes d’anomalie.
Abonnement Charge de production sub-lz-prod-01 Une application, un environnement, sa propre frontière de coût et son propre rayon d’impact.

Groupes de ressources, et ce qu’il y a dedans

Groupe de ressources Concentrateur rg-hub-canadaeast-01 Les services réseau partagés. Déployés une fois, utilisés par tous les rayons qui suivent.

Réseau Réseau du concentrateur vnet-hub-canadaeast-01 Plan d’adressage réservé pour la région dès le départ, plutôt qu’improvisé projet après projet.
Contrôle de sortie Azure Firewall afw-hub-canadaeast-01 Tout le trafic sortant y passe. Le jeu de règles est du code, relu en demande de tirage.
Résolution de noms Zones DNS privées privatelink.database.windows.net Rattachées au concentrateur, pour qu’un point de terminaison privé se résolve pareil depuis chaque rayon.
Hybride ExpressRoute ou VPN vgw-hub-canadaeast-01 La liaison vers ce qui reste sur site. L’un des deux, choisi sur la bande passante et la latence, pas par habitude.

Appairage en étoile Le rayon rejoint le concentrateur, et seul le concentrateur rejoint l’extérieur.

Groupe de ressources Charge de production rg-prod-canadaeast-01 Le groupe de ressources que le client voulait voir. Voici à quoi ressemble une application déployée dedans.

Réseau Réseau du rayon vnet-prod-canadaeast-01 Appairé au concentrateur. Aucune adresse publique sur aucun sous-réseau, et la table de routage envoie la sortie au pare-feu.
Entrée publique Application Gateway et WAF agw-prod-canadaeast-01 Le seul point d’entrée public de la charge. Toute autre exposition est une exception qui porte un nom.
Exécution Environnement Container Apps cae-prod-canadaeast-01 Injecté dans le réseau du rayon, entrée interne uniquement, si bien que les conteneurs ne sont jamais joignables directement.
Container Apps API ca-api-prod-01 Descend à zéro instance hors des heures ouvrées, d’où vient l’essentiel de l’économie sur cette charge.
Container Apps Traitement de fond ca-worker-prod-01 Même image, révision différente, aucune entrée. Il lit sa file, et rien ne le lit.
Données Azure SQL sql-prod-canadaeast-01 Accès réseau public refusé par la politique. La base n’a aucune adresse sur internet à attaquer.
Private Link Point de terminaison privé pe-sql-prod-01 Ce par quoi les conteneurs rejoignent la base : une adresse interne au rayon, résolue par la zone DNS privée du concentrateur.

Ce vers quoi tout abonnement remonte

Groupe de ressources Gestion rg-mgmt-canadaeast-01 Un seul endroit vers lequel tout le parc remonte, ce qui rend un audit répondable en un après-midi.

Journalisation Espace de travail Log Analytics log-platform-canadaeast-01 Les paramètres de diagnostic y sont dirigés par la politique : un nouvel abonnement est instrumenté le jour de sa création.

Portée d’abonnement Microsoft Defender for Cloud Activé au plan dont le parc a besoin, avec la vue de conformité réglementaire alignée sur le référentiel qui vous est opposé. Il se pose sur l’abonnement, pas dans un groupe de ressources.
Portée de locataire Microsoft Entra ID Le modèle de rôles et les règles d’accès privilégié dont hérite chaque abonnement de la hiérarchie. Rien de tout cela ne vit dans un groupe de ressources.

Les éléments foncés sont ce qui garde le trafic privé, et la politique héritée du haut de la hiérarchie.
Les noms de ressources suivent la convention déployée sur le parc : type, environnement, région, indice.

Comment se déroulent les quatre semaines

Semaine 1, les décisions. Les choix coûteux à défaire : forme de la hiérarchie, stratégie de régions, modèle d’identité, topologie réseau, nomenclature et étiquetage. Le livrable est un registre de décisions, pas une présentation. Chaque choix est consigné avec sa raison, pour que la personne qui demandera « pourquoi c’est comme ça ? » dans deux ans ait une réponse.

Semaine 2, la plateforme. Groupes d’administration, politiques, réseau du hub, journalisation et base d’identité déployés hors production, puis revus avec votre équipe.

Semaine 3, la production et les pipelines. Le même code est promu en production. Pipelines, protection des branches et processus de revue entrent en service. Vos ingénieurs ouvrent leur première pull request contre l’infrastructure, et ce moment-là dit si le transfert tiendra.

Semaine 4, le transfert. Documentation, procédures d’exploitation, session de parcours avec votre équipe, et un backlog de ce que nous avons laissé de côté, avec le moment de le reprendre.

Ce que vous gardez

Un dépôt Terraform ou Bicep dans votre organisation Git, avec la documentation des modules.
Des pipelines d’intégration continue et de déploiement continu, et les identifiants fédérés derrière.
Le registre de décisions de la première semaine, avec la raison de chaque choix.
Un jeu de politiques relié aux contrôles que votre auditeur examine.
Un backlog de remédiation priorisé, avec notre estimation du coût de chaque élément.

Pour qui c’est

Des organisations de 50 à 5 000 personnes qui démarrent sur Azure, ou dont le parc a grossi sans gouvernance et les ralentit. Le mandat fonctionne bien juste avant une migration infonuagique, un projet d’ingénierie IA ou un audit : ces trois-là révèlent un parc non gouverné en quelques jours.

Pour qui ce n’est pas

Si vous avez trois machines virtuelles et aucun projet de croissance, une landing zone enterprise-scale est du surdimensionnement, et nous le dirons plutôt que de vous la vendre.

Si votre organisation n’arrive pas à s’entendre sur une hiérarchie d’abonnements parce que la question de fond est politique, réglez ça d’abord. Nous ne pouvons pas déployer autour d’un désaccord de gouvernance.

Et si l’attente est qu’une firme exploite tout indéfiniment sans transfert, regardez plutôt l’Azure infogéré.

Pages liées

Ingénierie IA sur Azure AI Foundry, ce pour quoi la landing zone est souvent construite.
Migration infonuagique, les charges qui viennent y atterrir.
Architecture de conformité, le jeu de politiques relié à SOC 2, HIPAA et la Loi 25.
Tous les services Azure, le catalogue.

Questions fréquentes

Combien de temps prend une landing zone ?

Quatre semaines pour un déploiement enterprise-scale standard, du lancement jusqu’à un abonnement gouverné dans lequel votre équipe peut déployer. Une migration d’identité complexe ou une exigence multirégion porte ça à six ou huit semaines, et nous le disons avant la signature plutôt qu’après.

Nous avons déjà des abonnements Azure. Est-ce trop tard ?

Non, et c’est même le point de départ le plus courant. Nous évaluons l’existant, gardons ce qui tient la route, et ramenons le reste sous des groupes d’administration et des politiques. Les charges déjà en place sont déplacées dans la nouvelle structure sans redéploiement chaque fois que c’est possible.

Est-ce que nous obtenons le code Terraform ?

Oui, dans votre propre dépôt, dès le premier commit. Nous travaillons dans votre organisation Git, pas dans la nôtre. Si vous arrêtez le mandat à la deuxième semaine, vous détenez tout ce qui a été produit jusque-là, y compris le registre de décisions.

Et si personne chez nous ne peut la maintenir ?

Dites-le au départ et nous cadrons autrement : soit une entente d’infogérance, soit une architecture plus simple que votre équipe peut réellement exploiter. Remettre un parc sophistiqué à une équipe incapable de le maintenir est un échec, pas une livraison.

Peut-on la déployer uniquement dans les régions canadiennes ?

Oui. La restriction de région est imposée par Azure Policy au niveau du groupe d’administration, donc elle s’applique automatiquement à tout abonnement futur au lieu de dépendre de la mémoire de quelqu’un. Une tentative hors région est refusée et le refus est journalisé, ce qui vous donne la preuve, pas seulement la règle.

Une question sur ce mandat ?

Trois champs. Un architecte le lit et répond en un jour ouvrable.