Questions fréquentes (FAQ) sur la zone de démarrage Azure

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

Pour plus d’informations sur l’implémentation 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 du 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 la zone d’atterrissage Azure.

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

Microsoft développe et gère activement les accélérateurs de plateforme et les accélérateurs d’application et les implémentations en conformité avec les principes de conception de la zone d’atterrissage Azure et les conseils relatifs à la zone de conception .

Passez en revue les instructions de déploiement des zones d’atterrissage Azure pour en savoir plus sur les zones d’atterrissage recommandées pour la plateforme et l’application.

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

Qu’est-ce que l’architecture de référence de la zone d’atterrissage Azure ?

L’architecture de référence de la zone d’atterrissage Azure représente les décisions de mise à l’é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 zone d'atterrissage dans le cadre de l'architecture de zone d'atterrissage Azure ?

À partir 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 implique l’utilisation d’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 un grand nombre des effets Azure Policy, tels que Append, Deny, DeployIfNotExistset , pour Modifyempêcher la non-conformité en limitant les ressources non conformes (telles que définies par la définition de stratégie) d’être créées ou mises à jour ou en déployant des ressources ou en modifiant les paramètres d’une création ou d’une demande de mise à jour 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 pour Cloud (anciennement Azure Security Center) est activé sur l’abonnement. Il configure également les paramètres de diagnostic du journal d’activité pour envoyer les 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 zones d’atterrissage du Cloud Adoption Framework pour Terraform (aztfmod) ?

Le projet open source des zones d’atterrissage cloud Adoption Framework (OSS) ( également appelé aztfmod) est un projet piloté par la communauté appartenant et géré en dehors de l’équipe principale de la zone d’atterrissage Azure et de l’organisation Azure GitHub. Si votre organisation choisit d’utiliser ce projet OSS, vous devez prendre en compte la prise en charge disponible, car cela est piloté par l’effort de la communauté via GitHub.

Que se passe-t-il si nous avons déjà des ressources dans nos zones d’atterrissage et que vous affectez ultérieurement une définition Azure Policy qui les inclut dans son étendue ?

Passez en revue les sections de documentation suivantes :

• Transition des environnements Azure existants vers l’architecture de référence de la 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 existante de la zone d’atterrissage Azure pour déployer des charges de travail IA. Consultez les instructions et les explications dans l’IA dans les zones d’atterrissage Azure.

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

Pour plus d'informations, consultez la section Gérer les environnements de développement d'applications dans les zones d'atterrissage Azure.

Pourquoi sommes-nous invités à spécifier des régions Azure pendant le déploiement de l’architecture de référence de la zone d’atterrissage Azure et à quoi ils sont utilisés ?

Lorsque vous déployez l’architecture de zone d’atterrissage Azure à l’aide de l’expérience basée sur le portail d’architecture de référence de la zone d’atterrissage Azure, sélectionnez une région Azure à 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 sous l’onglet Emplacement de déploiement est également utilisé pour sélectionner la région Azure dans laquelle les ressources spécifiques à une région doivent être stockées, telles qu’un espace de travail Log Analytics, si nécessaire.

Si vous déployez une topologie de mise en réseau sous l’onglet Topologie réseau 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 quand 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 réutiliser des abonnements Azure ?

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 d’un Contrat partenaire Microsoft 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 étendues 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.
• Supprimer les attributions de rôle, y compris les attributions de rôle Privileged Identity Management (PIM), dans l’étendue de l’abonnement.
• Supprimez les définitions de contrôle d’accès en fonction du rôle (RBAC) personnalisées au niveau de l’étendue 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 à l'échelle de l'abonnement.
• Réinitialiser les plans Microsoft Defender pour le cloud sur les niveaux gratuits, sauf si les exigences de l’organisation imposent que ces journaux soient définis sur les niveaux payants. Vous appliquez normalement ces exigences via Azure Policy.
• Supprimez la redirection des journaux d'activité d'abonnement (paramètres de diagnostic) vers des espaces de travail Log Analytics, des Event Hubs, un compte de stockage ou d'autres destinations prises en charge, sauf si les exigences organisationnelles imposent de les transférer pendant qu'un abonnement est actif.
• Supprimez toutes les délégations Azure Lighthouse au niveau 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.
• Ajouter de nouvelles attributions de rôle, ou attributions de rôle Privileged Identity Management (PIM), dans l’étendue de l’abonnement pour les nouveaux propriétaires. En règle générale, ces affectations seraient aux groupes Microsoft Entra au lieu d’individus.
• Placez l’abonnement dans le groupe d’administration souhaité en fonction de ses exigences de gouvernance.
• Créez des budgets Microsoft Cost Management et définissez des alertes sur les nouveaux propriétaires lorsque des seuils sont atteints.
• Définissez les plans Microsoft Defender pour cloud sur les niveaux souhaité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é d’abonnement (paramètres de diagnostic) vers des espaces de travail Log Analytics, Event Hubs, un compte 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 Sovereign Cloud 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 la zone d’atterrissage Azure, la zone d’atterrissage souveraine aligne les fonctionnalités Azure telles que la résidence des services, les clés gérées par le client, 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) .