FAQ sur la zone d’atterrissage Azure

Cet article répond aux questions fréquemment posées sur Azure’architecture de zone d’atterrissage.

Pour plus d'informations sur la mise en œuvre de l’architecture de zone d’atterrissage Azure, consultez la FAQ sur l’implémentation à l’échelle de l’entreprise.

Qu’est-ce que l’accélérateur du portail de zone d’atterrissage Azure ?

L’accélérateur de portail de zone d’atterrissage Azure est une expérience de déploiement basée sur le portail Azure. Il déploie une implémentation avisée basée sur l’architecture de référence de zone d’atterrissage Azure.

Quels sont les accélérateurs et les implémentations recommandés pour Azure zones d’atterrissage ?

Microsoft développe et gère activement les accélérateurs et les implémentations de plateforme et d’application en conformité avec les principes de conception des zones d'atterrissage Azure et les orientations par domaine de conception.

Consultez les instructions sur les Zones d’atterrissage Azure pour en savoir plus sur les zones d’atterrissage recommandées pour les plateformes et applications.

Pour savoir comment adapter votre déploiement de zones d’atterrissage Azure pour répondre à vos besoins, consultez Tailor l’architecture de zone d’atterrissage Azure pour répondre aux exigences

Quelle est l’architecture de référence de zone d’atterrissage Azure ?

L’architecture de référence de zone d’atterrissage Azure représente les décisions d’échelle et de maturité. Elle est basée sur les leçons apprises et les commentaires des clients qui ont adopté Azure dans le cadre de leur patrimoine numérique. Cette architecture conceptuelle peut aider votre organisation à définir une direction pour concevoir et implémenter une zone d’atterrissage.

À quoi correspond une "landing zone" dans Azure dans le contexte de l'architecture des zones de destination Azure ?

D’un point de vue de zone d’atterrissage Azure, les zones d’atterrissage sont des abonnements Azure individuels.

Que signifie la gouvernance pilotée par les stratégies et comment fonctionne-t-elle ?

La gouvernance basée sur des stratégies est l’un des principes de conception clés de l’architecture à l’échelle de l’entreprise.

La gouvernance basée sur des stratégies consiste à utiliser Azure Policy pour réduire le temps nécessaire pour effectuer des tâches opérationnelles courantes et répétées sur votre locataire Azure. Utilisez de nombreux effets Azure Policy, tels que Append, Deny, DeployIfNotExists et Modify, pour empêcher la non-conformité en limitant les ressources non conformes (telles que définies par la définition de stratégie) à être créées ou mises à jour, ou en déployant des ressources ou en modifiant les paramètres d’une demande de création ou de mise à jour de ressources pour les rendre conformes. Certains effets, tels que Audit, Disabledet AuditIfNotExists, n’empêchent pas ou ne prennent pas d’action ; ils auditent et signalent uniquement la non-conformité.

Voici quelques exemples de gouvernance pilotée par des stratégies :

• Deny effet : empêche les sous-réseaux d’être créés ou mis à jour pour qu’aucun groupe de sécurité réseau ne leur soit associé.

• DeployIfNotExists effet : un nouvel abonnement (zone d’atterrissage) est créé et placé dans un groupe d’administration au sein de votre déploiement de zone d’atterrissage Azure. Azure Policy garantit que Microsoft Defender for Cloud est activé sur l’abonnement. Il configure également les paramètres de diagnostic du journal d’activité pour envoyer des journaux à l’espace de travail Log Analytics dans l’abonnement de gestion.

  Au lieu de répéter du code ou des activités manuelles lorsqu’un nouvel abonnement est créé, la DeployIfNotExists définition de stratégie déploie et les configure automatiquement pour vous.

Que se passe-t-il si nous ne pouvons pas ou ne sommes pas encore prêts à utiliser des stratégies DeployIfNotExists (DINE) ?

Nous avons une page dédiée qui décrit les différentes phases et options que vous devez soit « désactiver » les stratégies DINE, soit utiliser notre approche en trois phases pour les adopter au fil du temps dans votre environnement.

Consultez les conseils d’adoption des garde-fous pilotés par la stratégie

Devons-nous utiliser Azure Policy pour déployer des charges de travail ?

Bref, non. Utilisez Azure Policy pour contrôler, régir et maintenir vos charges de travail et zones d’atterrissage conformes. Il n’est pas conçu pour déployer des charges de travail entières et d’autres outils. Utilisez le portail Azure ou les offres d’infrastructure en tant que code (modèles ARM, Bicep, Terraform) pour déployer et gérer votre charge de travail et obtenir l’autonomie dont vous avez besoin.

Qu’est-ce que les espaces d’atterrissage du Framework d’Adoption du Cloud pour Terraform (aztfmod) ?

Les zones d’atterrissage du Framework d'Adoption du Cloud projet open source (OSS) (également appelé aztfmod) sont un projet communautaire possédé et géré en dehors de l’équipe centrale de la zone d’atterrissage Azure et de l’organisation Azure GitHub. Si votre organisation choisit d’utiliser ce projet OSS, il convient de prendre en compte le soutien disponible, car cela est piloté par l’effort de la communauté par le biais de GitHub.

Que se passe-t-il si nous avons déjà des ressources dans nos zones de destination, puis attribuons une définition d'Azure Policy englobant ces ressources dans sa portée ?

Passez en revue les sections de documentation suivantes :

• Transition des environnements Azure existants vers l’architecture de référence de zone d’atterrissage Azure - section « Stratégie »
• Démarrage rapide : Créer une attribution de stratégie pour identifier les ressources non conformes - Section « Identifier les ressources non conformes »

Ai-je besoin d’une zone d’atterrissage IA dédiée ou distincte ?

Non, vous n’avez pas besoin d’une zone d’atterrissage IA distincte. Au lieu de cela, vous pouvez utiliser l’architecture de zone d’atterrissage Azure existante pour y déployer des charges de travail en IA. Consultez les instructions et explications dans les zones d'atterrissage Azure AI.

Comment gérer les zones d’atterrissage pour les charges de travail « dev/test/production » dans l'architecture de zone d’atterrissage Azure ?

Pour plus d’informations, consultez la gestion des environnements de développement d’applications dans les zones d’atterrissage Azure.

Pourquoi nous demande-t-on de spécifier les régions Azure lors du déploiement de l’architecture de référence de la zone d'accueil Azure et à quoi elles sont utilisées ?

Lorsque vous déployez une architecture de zone d’atterrissage Azure à l’aide de l’expérience basée sur le portail de l’architecture de référence de zone d’atterrissage Azure, sélectionnez une région Azure dans laquelle déployer. Le premier onglet, Emplacement du déploiement, détermine l’emplacement où les données de déploiement sont stockées. Pour plus d’informations, consultez Déploiements de clients avec des Modèles ARM. Certaines parties d’une zone d’atterrissage sont déployées globalement, mais leurs métadonnées de déploiement sont suivies dans un magasin de métadonnées régional. Les métadonnées relatives à leur déploiement sont stockées dans la région sélectionnée sous l’onglet Emplacement du déploiement .

Le sélecteur de région dans l’onglet emplacement de déploiement est également utilisé pour sélectionner dans quelle région Azure les ressources spécifiques à une région doivent être stockées, telles que, si nécessaire, un espace de travail Log Analytics.

Si vous déployez une topologie de mise en réseau sous l’onglet Network et connectivité, vous devez sélectionner une région Azure dans laquelle déployer les ressources réseau. Cette région peut être différente de la région sélectionnée sous l’onglet Emplacement de déploiement .

Pour plus d’informations sur les régions utilisées par les ressources de zone d’atterrissage, consultez les régions de zone d’atterrissage.

Comment activer davantage de régions Azure lorsque nous utilisons l’architecture de zone d’atterrissage Azure ?

Pour comprendre comment ajouter de nouvelles régions à une zone d’atterrissage ou comment déplacer des ressources de zone d’atterrissage vers une autre région, consultez les régions de zone d’atterrissage.

Devons-nous créer un abonnement Azure chaque fois ou devons-nous réutiliser Azure abonnements ?

Qu’est-ce que la réutilisation de l’abonnement ?

La réutilisation de l’abonnement est le processus de réédition d’un abonnement existant à un nouveau propriétaire. Il doit y avoir un processus de réinitialisation de l’abonnement à un état propre connu, puis sa réattribution à un nouveau propriétaire.

Pourquoi dois-je envisager de réutiliser des abonnements ?

En général, nous recommandons aux clients d’adopter le principe de conception de la démocratisation des abonnements. Toutefois, il existe des circonstances spécifiques dans lesquelles la réutilisation de l’abonnement n’est pas possible ou recommandée.

Vous devez envisager la réutilisation de l’abonnement si vous rencontrez l’une des circonstances suivantes :

• Vous disposez d’un contrat Entreprise (EA) et prévoyez de créer plus de 5 000 abonnements sur un compte propriétaire de compte EA unique (compte de facturation), y compris les abonnements supprimés.
• Vous disposez d’un Contrat client Microsoft (MCA) ou Contrat Partenaire Microsoft MPA et prévoyez d’avoir plus de 5 000 abonnements actifs. Pour en savoir plus sur les limites d’abonnement, consultez Comptes de facturation et périmètres dans le portail Azure.
• Vous êtes un client du paiement à l’utilisation.
• Vous utilisez un parrainage Microsoft Azure.
• Vous créez généralement :
  1. Environnements de laboratoire ou de bac à sable éphémères
  2. Environnements de démonstration pour les preuves de concept (POCs) ou les produits minimum viables (MVP), y compris les éditeurs de logiciels indépendants (ISV) pour l’accès aux démonstrations/versions d’évaluation des clients
  3. Environnements de formation, tels que les environnements d'apprentissage des MSP/Fournisseurs de services managés et des formateurs

Comment réutiliser des abonnements ?

Si vous correspondez à l’un des scénarios ou considérations ci-dessus, vous devrez peut-être envisager de réutiliser les abonnements désaffectés ou inutilisés existants et de les réaffecter à un nouveau propriétaire et à un nouvel objectif.

Nettoyer l’ancien abonnement

Vous devez d’abord nettoyer l’ancien abonnement afin de pouvoir le réutiliser. Vous devez effectuer les actions suivantes sur un abonnement avant de pouvoir être réutilisé :

• Supprimez les groupes de ressources et les ressources contenues.
• Supprimez les attributions de rôles, y compris les attributions de rôles Privileged Identity Management (PIM), dans l’étendue de l’abonnement.
• Supprimez les définitions personnalisées de contrôle d'accès basé sur les rôles (RBAC) à l’échelle de l'abonnement.
• Supprimez les définitions de stratégie, les initiatives, les affectations et les exemptions dans l’étendue de l’abonnement.
• Supprimer les déploiements dans l’étendue de l’abonnement.
• Supprimer les étiquettes dans l’étendue de l’abonnement.
• Supprimer les verrous de ressource dans l’étendue de l’abonnement.
• Supprimez les budgets Microsoft Cost Management dans l’étendue de l’abonnement.
• Réinitialisez Microsoft Defender pour les plans Cloud vers les niveaux gratuits, sauf si les exigences organisationnelles imposent que ces plans ou journaux doivent être définis sur les niveaux payants. Vous appliquez normalement ces exigences via Azure Policy.
• Supprimez le transfert des journaux d'activité d'abonnement (paramètres de diagnostic) vers les espaces de travail Log Analytics, Event Hubs, comptes de stockage ou autres destinations prises en charge, sauf si les exigences de l’organisation imposent de transférer ces journaux pendant qu’un abonnement est actif.
• Supprimez les Azure Lighthouse Délégations au niveau de l’étendue de l’abonnement.
• Supprimez les ressources masquées de l’abonnement.

Réattribuer l’abonnement

Vous pouvez réattribuer l’abonnement après l’avoir nettoyé. Voici quelques activités courantes que vous pouvez effectuer dans le cadre du processus de réaffectation :

• Ajoutez de nouvelles balises et définissez des valeurs pour celles-ci sur l’abonnement.
• Ajoutez de nouvelles attributions de rôles ou des attributions de rôles de la gestion des identités privilégiées (PIM) à l'étendue de l'abonnement pour les nouveaux propriétaires. En règle générale, ces affectations seraient à des groupes Microsoft Entra plutôt qu'à des individus.
• Placez l’abonnement dans le groupe d’administration souhaité en fonction de ses exigences de gouvernance.
• Créez de nouveaux budgets Microsoft Cost Management et définissez des alertes aux nouveaux propriétaires lorsque les seuils sont atteints.
• Définissez les plans Microsoft Defender pour le cloud aux niveaux désirés. Vous devez appliquer ce paramètre via Azure Policy une fois placé dans le groupe d’administration approprié.
• Configurez le transfert des journaux d’activités d’abonnement (paramètres de diagnostic) vers des espaces de travail Log Analytics, des Event Hubs, des Comptes de stockage ou d’autres destinations prises en charge. Vous devez appliquer ce paramètre via Azure Policy une fois placé dans le groupe d’administration approprié.

Qu’est-ce qu’une zone d’atterrissage souveraine et comment est-elle liée à l’architecture de la zone d’atterrissage Azure ?

La zone d'atterrissage souveraine est un composant de Microsoft Cloud souverain destiné aux clients du secteur public qui ont besoin de contrôles de souveraineté avancés. En tant que version personnalisée de l’architecture de référence de zone d’atterrissage Azure, la zone d’atterrissage souveraine aligne les fonctionnalités de Azure telles que la résidence des services, les clés gérées par le client, les Azure Private Link et l’informatique confidentielle. Grâce à cet alignement, la zone d’atterrissage souveraine crée une architecture cloud où les données et charges de travail offrent le chiffrement et la protection contre les menaces par défaut.

Pour plus d’informations sur la zone d’atterrissage souveraine, consultez La zone d’atterrissage souverain (SLZ) .