Compartilhar via

Fazer a transição de um ambiente existente do Azure para a arquitetura de referência da zona de destino do Azure

Muitas organizações têm uma presença existente no Azure, uma ou mais assinaturas e, potencialmente, uma estrutura de grupo de gerenciamento existente. Dependendo de seus requisitos e cenários de negócios, eles podem ter recursos do Azure implantados, como o Gateway de VPN do Azure ou o Azure ExpressRoute para conectividade híbrida.

Este artigo fornece recomendações para ajudar sua organização a navegar por alterações com base no ambiente existente do Azure que está fazendo a transição para a arquitetura de referência da zona de destino do Azure. Este artigo também descreve considerações sobre como mover recursos no Azure, por exemplo, mover uma assinatura de um grupo de gerenciamento existente para outro grupo de gerenciamento. Considere essas recomendações para ajudá-lo a avaliar e planejar a transição do ambiente existente do Azure.

Mover recursos no Azure

Você pode mover alguns recursos no Azure após a criação. Há diferentes abordagens que estão sujeitas às permissões de RBAC (controle de acesso baseado em função) de um usuário do Azure dentro e entre escopos. A tabela a seguir descreve quais recursos você pode mover, em qual escopo, e os prós e contras associados a cada recurso.

Scope Destino Pro Con
Recursos em grupos de recursos. Você pode migrar para um novo grupo de recursos na mesma assinatura ou em uma assinatura diferente. Você pode modificar a composição de recursos em um grupo de recursos após a implantação. Não há suporte para todos os resourceTypes.

Alguns resourceTypes têm limitações ou requisitos específicos.

Os ResourceIds são atualizados e afetam as operações existentes de monitoramento, alertas e plano de controle.

Os grupos de recursos são bloqueados durante o período de movimentação.

Requer uma avaliação das políticas e das operações do RBAC antes e depois da movimentação.
Assinaturas em um locatário. Você pode migrar para diferentes grupos de gerenciamento. Nenhum efeito sobre os recursos existentes na assinatura porque os valores resourceId não são alterados. Requer uma avaliação das políticas e das operações do RBAC antes e depois da movimentação.

Para determinar qual estratégia de movimentação você deve usar, considere os exemplos a seguir.

Mover assinaturas

Normalmente, você move assinaturas para organizá-las em grupos de gerenciamento ou transferir assinaturas para um novo locatário do Microsoft Entra ID. Mover uma assinatura para um novo cliente é, principalmente, para transferir a propriedade de cobrança. Para obter mais informações sobre como mover assinaturas entre grupos de gerenciamento no mesmo locatário, consulte Movendo grupos de gerenciamento e assinaturas.

Requisitos do RBAC do Azure

Para avaliar uma assinatura antes de uma mudança, é importante que o usuário tenha o RBAC do Azure apropriado. O usuário pode ser um proprietário da assinatura (atribuição de função direta) e ter permissão de gravação no grupo de gerenciamento alvo. As funções internas que dão suporte à permissão de gravação no grupo de gerenciamento de destino são a função de proprietário, a função de colaborador e a função de colaborador do grupo de gerenciamento.

Se o usuário tiver uma permissão de função de proprietário herdada na assinatura de um grupo de gerenciamento existente, você só poderá mover a assinatura para o grupo de gerenciamento no qual o usuário recebe a função de proprietário.

Policies

As assinaturas existentes podem estar sujeitas às políticas do Azure que são atribuídas diretamente ou atribuídas ao grupo de gerenciamento em que estão localizadas no momento. É importante avaliar as políticas atuais e as políticas que podem existir no novo grupo de gerenciamento ou na hierarquia do grupo de gerenciamento.

Você pode usar o Azure Resource Graph para executar um inventário de recursos existentes e comparar sua configuração com as políticas existentes no destino.

Depois de mover assinaturas para um grupo de gerenciamento com RBAC do Azure existente e políticas em vigor, considere os seguintes fatores:

  • Para qualquer RBAC do Azure herdado para as assinaturas movidas, os tokens de usuário no cache do grupo de gerenciamento podem levar até 30 minutos para serem atualizados. Para agilizar esse processo, você pode atualizar o token saindo e entrando novamente, ou solicitar um novo token.

  • Uma política na qual o escopo de atribuição inclui as assinaturas movidas executa uma auditoria somente nos recursos existentes. Um recurso existente na assinatura que está sujeito a um:

    • DeployIfNotExists O efeito de política aparece como não compatível e não é corrigido automaticamente. Um usuário deve executar manualmente a correção.

    • Deny O efeito de política aparece como não compatível e não é rejeitado. Um usuário deve atenuar manualmente esse resultado conforme apropriado.

    • Append e Modify o efeito de política aparece como não compatível e requer que um usuário atenue.

    • Audit e AuditIfNotExist o efeito de política aparece como não compatível e requer que um usuário atenue.

  • Todas as novas gravações em recursos na assinatura movida estão sujeitas às políticas atribuídas em tempo real, como normal.

Mover recursos

Normalmente, você move recursos quando deseja consolidar recursos no mesmo grupo de recursos se eles compartilham o mesmo ciclo de vida. Ou se você quiser mover recursos para uma assinatura diferente devido aos requisitos de custo, propriedade ou RBAC do Azure.

Quando você move recursos, o grupo de recursos de origem e o grupo de recursos de destino são bloqueados durante a operação de movimentação. Você não pode adicionar, atualizar ou excluir recursos nos grupos de recursos. Uma operação de movimentação de recurso não altera o local dos recursos.

Para obter mais informações sobre como mover recursos entre grupos de recursos e assinaturas no mesmo locatário, consulte Mover recursos para um novo grupo de recursos ou assinatura.

Dica

Para minimizar o efeito de interrupções regionais, recomendamos que você coloque os recursos na mesma região que o grupo de recursos. Para obter mais informações, consulte Alinhamento de localização do grupo de recursos.

Se você tiver recursos em regiões diferentes dentro do mesmo grupo de recursos, considere mover seus recursos para um novo grupo de recursos ou assinatura.

Para determinar se o recurso suporta a movimentação para outro grupo de recursos, faça um inventário dos seus recursos referenciando-os cruzadamente. Verifique se você atende aos pré-requisitos apropriados.

Antes de mover recursos

Antes de uma operação de movimentação, você deve verificar se os recursos têm suporte e avaliar seus requisitos e dependências. Por exemplo, ao mover uma rede virtual emparelhada, você precisa desabilitar o emparelhamento de rede virtual primeiro e habilitar novamente o emparelhamento após a conclusão da operação de movimentação. Planeje antecipadamente para desabilitar e reabilitar a dependência, garantindo que você compreende o efeito disso nas cargas de trabalho existentes que podem estar conectadas às suas redes virtuais.

Depois de mover recursos

Quando você move os recursos para um novo grupo de recursos na mesma assinatura, qualquer Controle de Acesso Baseado em Funções (RBAC) herdado do Azure, bem como as políticas do grupo de gerenciamento ou da assinatura, ainda se aplicam. Isso também se aplica se você migrar para um grupo de recursos em uma nova assinatura, em que a assinatura pode estar sujeita a outros RBAC e atribuições de política do Azure. Você precisa validar a conformidade do recurso e os controles de acesso.

Cenários

Os cenários a seguir descrevem como migrar e fazer a transição de um ambiente existente para a arquitetura de referência da zona de destino do Azure.

Percurso em direção à arquitetura de destino

  • Last updated on