Transition d'un environnement Azure existant vers l'architecture conceptuelle de la zone d'atterrissage Azure

De nombreuses organisations disposent d’une empreinte Azure existante, d’un ou plusieurs abonnements et potentiellement d’une structure de groupe de gestion existante. En fonction de leurs exigences commerciales et de leurs scénarios, ils peuvent déployer des ressources Azure, telles que Azure passerelle VPN ou Azure ExpressRoute pour la connectivité hybride.

Cet article fournit des suggestions pour aider votre organisation à gérer les changements en fonction de votre environnement Azure existant en cours de transition vers l’architecture conceptuelle de la zone d’atterrissage Azure. Cet article décrit également les considérations relatives au déplacement de ressources dans Azure, par exemple le déplacement d'un abonnement d'un groupe d'administration existant vers un autre groupe d'administration. Tenez compte de ces suggestions pour vous aider à évaluer et planifier la transition de votre environnement Azure existant.

Déplacer des ressources dans Azure

Vous pouvez déplacer certaines ressources dans Azure après la création. Il existe différentes approches qui sont soumises aux autorisations de contrôle d'accès en fonction du rôle (RBAC) Azure d'un utilisateur au niveau et entre les étendues. Le tableau suivant présente les ressources que vous pouvez déplacer, dans quelle étendue, ainsi que les avantages et les inconvénients associés à chaque ressource.

Étendue	Destination	Pro	Con
Ressources dans les groupes de ressources.	Vous pouvez passer à un nouveau groupe de ressources dans le même abonnement ou dans un autre abonnement.	Vous pouvez modifier la composition des ressources dans un groupe de ressources après le déploiement.	Non pris en charge par tous les types de ressources. Certains types de ressources ont des limitations ou des exigences spécifiques. Les ResourceIds sont mis à jour. Cette mise à jour affecte la surveillance, les alertes et les opérations existantes du plan de contrôle. Les groupes de ressources sont verrouillés pendant la période de déplacement. Nécessite une évaluation des politiques et des opérations RBAC avant et après le déplacement.
Souscriptions chez un locataire.	Vous pouvez passer à différents groupes de gestion.	Aucun effet sur les ressources existantes au sein de l'abonnement, car les valeurs ResourceId ne changent pas.	Nécessite une évaluation des politiques et des opérations RBAC avant et après le déplacement.

Pour déterminer quelle stratégie de déplacement vous devez utiliser, considérez les exemples suivants.

Déplacer des abonnements

En règle générale, vous déplacez les abonnements pour les organiser en groupes de gestion ou pour transférer les abonnements vers un nouveau locataire Microsoft Entra ID. Le déplacement d’un abonnement vers un nouveau locataire sert principalement à transférer la propriété de facturation. Pour plus d'informations sur la façon de déplacer des abonnements entre des groupes d'administration dans le même locataire, consultez Déplacement de groupes d'administration et d'abonnements.

Conditions requises de RBAC Azure

Pour évaluer un abonnement avant un déplacement, il est important que l’utilisateur dispose du RBAC Azure approprié. L'utilisateur peut être propriétaire de l'abonnement (attribution de rôle directe) et disposer d'une autorisation en écriture sur le groupe d'administration cible. Les rôles intégrés qui prennent en charge l'autorisation d'écriture sur le groupe d'administration cible sont le rôle de propriétaire, le rôle de contributeur et le rôle de contributeur du groupe d'administration.

Si l'utilisateur dispose d'une autorisation de rôle de propriétaire héritée sur l'abonnement d'un groupe d'administration existant, vous pouvez uniquement déplacer l'abonnement vers le groupe d'administration dans lequel l'utilisateur se voit attribuer le rôle de propriétaire.

Stratégies

Les souscriptions existantes peuvent être soumises à des stratégies Azure attribuées directement ou attribuées au niveau du groupe d'administration où ils se trouvent actuellement. Il est important d’évaluer les politiques actuelles et les politiques qui pourraient exister dans le nouveau groupe d’administration ou dans la hiérarchie du groupe d’administration.

Vous pouvez utiliser Azure Resource Graph pour effectuer un inventaire des ressources existantes et comparer leur configuration avec les stratégies qui existent à la destination.

Après avoir déplacé les abonnements vers un groupe d’administration avec Azure RBAC et des stratégies existantes, tenez compte des facteurs suivants :

• Pour tout Azure RBAC hérité des abonnements déplacés, l’actualisation des jetons utilisateur dans le cache du groupe d’administration peut prendre jusqu’à 30 minutes. Pour accélérer ce processus, vous pouvez actualiser le jeton en vous déconnectant et en vous reconnectant, ou en demandant un nouveau jeton.

• Une stratégie dans laquelle la portée de l'affectation inclut les abonnements déplacés effectue un audit uniquement sur les ressources existantes. Une ressource existante dans l'abonnement qui est soumise à :

  • L’effet de stratégie DeployIfNotExists apparaît comme non conforme et n’est pas automatiquement corrigé. Un utilisateur doit effectuer manuellement la correction.

  • l'effet de stratégie Deny apparaît comme non conforme et n'est pas rejeté. Un utilisateur doit atténuer manuellement ce résultat, le cas échéant.

  • l'effet de la politique Append et Modify apparaît comme non conforme et nécessite qu'un utilisateur l'atténue.

  • l'effet de la politique Audit et AuditIfNotExist apparaît comme non conforme et nécessite qu'un utilisateur l'atténue.

• Toutes les nouvelles écritures sur les ressources de l'abonnement déplacé sont soumises aux stratégies attribuées en temps réel, comme d'habitude.

Déplacer des ressources

En règle générale, vous déplacez des ressources lorsque vous souhaitez consolider des ressources dans le même groupe de ressources si elles partagent le même cycle de vie. Ou si vous souhaitez déplacer des ressources vers un autre abonnement en raison du coût, de la propriété ou des exigences Azure RBAC.

Lorsque vous déplacez des ressources, le groupe de ressources source et le groupe de ressources cible sont verrouillés pendant l'opération de déplacement. Vous ne pouvez pas ajouter, mettre à jour ou supprimer des ressources dans les groupes de ressources. Une opération de déplacement de ressources ne modifie pas l’emplacement des ressources.

Pour plus d'informations sur la façon de déplacer des ressources entre des groupes de ressources et des abonnements dans le même locataire, consultez Déplacer des ressources vers un nouveau groupe de ressources ou un nouvel abonnement.

Conseil

Pour réduire l’effet des pannes régionales, nous vous recommandons de placer les ressources dans la même région que le groupe de ressources. Pour plus d’informations, consultez Alignement de l’emplacement du groupe de ressources.

Si vous avez des ressources dans différentes régions au sein du même groupe de ressources, envisagez de les déplacer vers un nouveau groupe de ressources ou un nouvel abonnement.

Pour déterminer si votre ressource prend en charge le déplacement vers un autre groupe de ressources, inventoriez vos ressources à l’aide d’un référencement croisé. Assurez-vous que les conditions préalables appropriées sont réunies.

Avant de déplacer des ressources

Avant une opération de déplacement, vous devez vérifier que les ressources sont prises en charge et évaluer leurs exigences et dépendances. Par exemple, lorsque vous déplacez un réseau virtuel appairé, vous devez d'abord désactiver le peering de réseau virtuel, puis réactiver le peering une fois l'opération de déplacement terminée. Planifiez à l'avance la désactivation et la réactivation de la dépendance afin de comprendre l'effet sur les charges de travail existantes qui pourraient être connectées à vos réseaux virtuels.

Après avoir déplacé des ressources

Lorsque vous déplacez les ressources vers un nouveau groupe de ressources dans le même abonnement, les stratégies Azure RBAC héritées du groupe d’administration ou de l’abonnement s’appliquent toujours. Cela s’applique également si vous passez à un groupe de ressources dans un nouvel abonnement où l’abonnement peut être soumis à d’autres affectations de stratégie et RBAC Azure. Vous devez valider la conformité des ressources et les contrôles d’accès.

Scénarios

Les scénarios suivants décrivent comment migrer et faire la transition d’un environnement existant vers l’architecture conceptuelle de la zone d’atterrissage Azure.

• Scénarios d'alignement

  • Transition d'un abonnement unique sans groupe d'administration vers l'architecture conceptuelle de la zone d'atterrissage Azure
  • Transition des groupes de gestion vers l’architecture conceptuelle de la zone d’atterrissage Azure
  • Transition d’une organisation régionale vers l’architecture conceptuelle de la zone d’atterrissage Azure

• Approches d’alignement

  • Transition d'un environnement en dupliquant un groupe de gestion de zone d'atterrissage

Voyage vers l’architecture cible