Azure perguntas frequentes sobre a zona de destino

Este artigo responde a perguntas frequentes sobre a arquitetura de zonas de aterrissagem do Azure.

Para perguntas frequentes sobre a implementação da arquitetura de zona de aterrissagem do Azure, consulte as Perguntas Frequentes sobre Implementação em Escala Empresarial.

O que é o acelerador de portal do Azure landing zone?

O acelerador do portal da zona de aterrissagem do Azure é uma experiência de implantação baseada no portal do Azure. Ele implanta uma implementação padronizada com base na arquitetura de referência do Azure landing zone.

Quais são os aceleradores e implementações recomendados para Azure zonas de destino?

Microsoft desenvolve e mantém ativamente os aceleradores de plataforma, aplicativos e implementações em alinhamento com as diretrizes de design da zona de aterrissagem do Azure e orientação da área de design.

Examine as diretrizes de Deploy de zonas de aterrissagem do Azure para saber mais sobre as zonas de aterrissagem recomendadas da plataforma e do aplicativo.

Para saber como personalizar sua implantação de zonas de destino Azure para atender às suas necessidades, consulte Escreva a arquitetura da zona de destino Azure para atender aos requisitos

Qual é a arquitetura de referência da zona de destino Azure?

A arquitetura de referência da zona de destino Azure representa decisões de escala e maturidade. É baseado em lições aprendidas e comentários de clientes que adotaram Azure como parte de sua propriedade digital. Essa arquitetura conceitual pode ajudar sua organização a definir uma direção para projetar e implementar uma zona de destino.

A que uma zona de aterrissagem corresponde em Azure no contexto da arquitetura de zona de aterrissagem da Azure?

Do ponto de vista das zonas de destino do Azure, as zonas de destino são assinaturas individuais do Azure.

O que significa a governança orientada por políticas e como ela funciona?

A governança orientada por políticas é um dos principais princípios de design da arquitetura de escala empresarial.

Governança controlada por políticas significa usar Azure Policy para reduzir o tempo necessário para tarefas operacionais comuns e repetidas em seu locatário Azure. Use muitos dos efeitos Azure Policy, como Append, Deny, DeployIfNotExists e Modify, para evitar que recursos não compatíveis (conforme definido pela definição de política) sejam criados ou atualizados, ou para implantar recursos e modificar configurações de uma solicitação de criação ou atualização de recursos a fim de torná-los compatíveis. Alguns efeitos, como Audit, Disablede AuditIfNotExists, não impedem ou tomam medidas; eles apenas auditam e relatam não conformidade.

Alguns exemplos de governança orientada por políticas são:

• Deny efeito: impede que as sub-redes sejam criadas ou atualizadas para não ter nenhum Grupo de Segurança de Rede associado a elas.

• DeployIfNotExists efeito: uma nova assinatura (zona de aterrissagem) é criada e colocada em um grupo de gerenciamento dentro da implantação da sua zona de aterrissagem do Azure. Azure Policy garante que o Microsoft Defender para Nuvem esteja habilitado na assinatura. Isso também configura as configurações de diagnóstico do Log de Atividades para enviar logs para o espaço de trabalho do Log Analytics na assinatura de gerenciamento.

  Em vez de repetir o código ou atividades manuais quando uma nova assinatura é criada, a definição da política DeployIfNotExists implanta e as configura automaticamente para você.

E se não pudermos ou ainda não estivermos prontos para utilizar políticas DINE (DeployIfNotExists)?

Temos uma página dedicada que percorre as várias fases e opções que você precisa para "desabilitar" as políticas DINE ou usar nossa abordagem de três fases para adotá-las ao longo do tempo em seu ambiente.

Confira as diretrizes Adotar os verificadores de integridade orientados por políticas

Devemos usar Azure Policy para implantar cargas de trabalho?

Resumindo, não. Use o Azure Policy para controlar, gerenciar e manter suas cargas de trabalho e zonas de aterrissagem em conformidade. Ele não foi projetado para implantar cargas de trabalho inteiras e outras ferramentas. Use o portal do Azure ou as ofertas de infraestrutura como código (Modelos ARM, Bicep, Terraform) para implantar e gerenciar sua carga de trabalho e alcançar a autonomia necessária.

O que são as Zonas de Destino do Cloud Adoption Framework para Terraform (aztfmod)?

As zonas de aterrissagem do Cloud Adoption Framework código aberto project (OSS) (também conhecido como aztfmod) é um projeto gerido pela comunidade e mantido fora da equipe central de zona de aterrissagem do Azure e da organização Azure GitHub. Se sua organização optar por usar esse projeto do OSS, considere o suporte disponível, pois isso é impulsionado pelo esforço da comunidade por meio de GitHub.

E se já tivermos recursos em nossas zonas de destino e, posteriormente, atribuirmos uma definição de Azure Policy que os inclua em seu escopo?

Examine as seguintes seções de documentação:

• Transitionar ambientes existentes do Azure para a arquitetura de referência da Azure landing zone - seção "Política"
• Início Rápido: Criar uma atribuição de política para identificar recursos não compatíveis – seção "Identificar recursos não compatíveis"

Preciso de uma zona de destino de IA dedicada ou separada?

Não, você não precisa de uma zona de destino de IA separada. Em vez disso, você pode usar a arquitetura de zona de destino Azure existente para implantar cargas de trabalho de IA. Consulte as diretrizes e explicações em AI em zonas de destino Azure.

Como lidamos com as zonas de aterrissagem de carga de trabalho de "desenvolvimento/teste/produção" na arquitetura de zona de aterrissagem do Azure?

Para obter mais informações, consulte Gerenciar ambientes de desenvolvimento de aplicações em zonas de aterrissagem do Azure.

Por que é solicitado que especifique as regiões do Azure durante a implantação da arquitetura de referência da zona de aterrissagem do Azure e para que elas são utilizadas?

Ao implantar a arquitetura de zona de destino do Azure usando a experiência no portal da arquitetura de referência da zona de destino do Azure, selecione uma região do Azure para a implantação. A primeira guia, local da implantação, determina onde os dados de implantação são armazenados. Para obter mais informações, confira Implantações de locatário com modelos do ARM. Algumas partes de uma zona de destino são implantadas globalmente, mas seus metadados de implantação são acompanhados em um repositório de metadados regional. Os metadados referentes à implantação são armazenados na região selecionada na guia Local de implantação .

O seletor de região na guia local de implantação também é usado para selecionar em qual região do Azure quaisquer recursos específicos da região devem ser armazenados, como um workspace do Log Analytics, se necessário.

Se você implantar uma topologia de rede na guia Topologia e conectividade de rede, será necessário selecionar uma região do Azure para implantar os recursos de rede. Essa região pode ser diferente da região selecionada na guia Local de implantação .

Para obter mais informações sobre as regiões que os recursos da zona de destino usam, consulte regiões da zona de destino.

Como podemos habilitar mais regiões do Azure quando usamos a arquitetura de zona de aterrissagem do Azure?

Para entender como adicionar novas regiões a uma zona de destino ou como mover recursos da zona de destino para uma região diferente, consulte regiões da zona de destino.

Devemos criar uma nova assinatura de Azure sempre ou devemos reutilizar Azure Assinaturas?

O que é reutilização de assinatura?

A reutilização de assinatura é o processo de reemitir uma assinatura existente a um novo proprietário. Deve haver um processo para redefinir a assinatura para um estado limpo conhecido e depois reatribuir a um novo proprietário.

Por que devo considerar reutilizar assinaturas?

Em geral, recomendamos que os clientes adotem o princípio de design de Democratização da Assinatura. No entanto, há circunstâncias específicas em que a reutilização da assinatura não é possível ou recomendada.

Você deve considerar a reutilização da assinatura se atender a uma das seguintes circunstâncias:

• Você tem um EA (Contrato Enterprise Agreement) e planeja criar mais de 5.000 assinaturas em uma única Conta de Proprietário da EA (conta de faturamento), incluindo assinaturas excluídas.
• Você tem um MCA (Contrato de Cliente da Microsoft) ou Contrato de Parceiro da Microsoft MPA e planeja ter mais de 5.000 assinaturas ativas. Para saber mais sobre os limites de assinatura, consulte Contas de cobrança e escopos no portal do Azure.
• Você é um cliente de pagamento conforme o uso.
• Você usa um Patrocínio do Microsoft Azure.
• Normalmente, você cria:
  1. Ambientes de laboratório efêmero ou sandbox
  2. Ambientes de demonstração para POCs (prova de conceito) ou MVP (produtos mínimos viáveis), incluindo ISV (fornecedores de software independentes) para acesso de demonstração/avaliação do cliente
  3. Ambientes de treinamento, como os ambientes de aprendizado dos MSPs/treinadores

Como reutilizar assinaturas?

Se você corresponder a um dos cenários ou considerações acima, talvez seja necessário considerar a reutilização de assinaturas desativadas ou não utilizados existentes e reatribuí-las a um novo proprietário e finalidade.

Limpar assinatura antiga

Primeiro, você precisa limpar a assinatura antiga para reutilização. Você precisa executar as seguintes ações em uma assinatura antes que ela esteja pronta para reutilização:

• Remover grupos de recursos e recursos contidos.
• Remova as atribuições de função no escopo da assinatura, incluindo aquelas do Privileged Identity Management (PIM).
• Remova Definição Personalizada de Controle de Acesso baseadas em função (RBAC) no escopo da assinatura.
• Remova definições de política, iniciativas, atribuições e isenções no escopo da assinatura.
• Remova as implantações no escopo da assinatura.
• Remova as tags no escopo da assinatura.
• Remova todos os Bloqueios de Recursos no escopo da assinatura.
• Remova qualquer orçamento do Gerenciamento de Custos da Microsoft no escopo da assinatura.
• Redefina os planos do Microsoft Defender para Nuvem para níveis gratuitos, exceto se requerimentos organizacionais exigirem que esses registros sejam configurados para as camadas pagas. Normalmente, você impõe esses requisitos por meio de Azure Policy.
• Remova os logs de atividade de assinatura (configurações de diagnóstico) de encaminhamento para Log Analytics Workspaces, Hubs de Eventos, Conta de Armazenamento ou outros destinos com suporte, a menos que os requisitos organizacionais exiram o encaminhamento desses logs enquanto uma assinatura estiver ativa.
• Remova as delegações do Azure Lighthouse no escopo de assinatura.
• Remova todos os recursos ocultos da assinatura.

Reatribuir a assinatura

Você pode reatribuir a assinatura após limpar a assinatura. Aqui estão algumas atividades comuns que talvez você queira executar como parte do processo de reatribuição:

• Adicione novas tags e defina valores para elas na assinatura.
• Adicione novas atribuições de função ou atribuições de função de gerenciamento de identidade privilegiada (PIM) para os novos proprietários no escopo da assinatura. Normalmente, essas atribuições seriam para grupos do Microsoft Entra em vez de indivíduos.
• Coloque a assinatura no Grupo de Gerenciamento desejado, conforme os seus requisitos de governança.
• Crie novos orçamentos de Gerenciamento de Custos da Microsoft e defina alertas para novos proprietários quando os limites forem atingidos.
• Defina os planos do Microsoft Defender para Nuvem para as camadas desejadas. Você deve impor essa configuração por meio de Azure Policy uma vez colocada no Grupo de Gerenciamento correto.
• Configure os logs de atividade de assinatura (configurações de diagnóstico) encaminhando para Log Analytics Workspaces, Hubs de Eventos, Conta de Armazenamento ou outros destinos com suporte. Você deve impor essa configuração por meio de Azure Policy uma vez colocada no Grupo de Gerenciamento correto.

O que é uma zona de destino soberana e como ela está relacionada à arquitetura da zona de destino Azure?

A zona de destino soberana é um componente do Microsoft Sovereign Cloud destinado a clientes do setor público que precisam de controles avançados de soberania. Como uma versão personalizada da arquitetura de referência da zona de destino Azure, a zona de destino soberana alinha recursos Azure, como residência de serviço, chaves gerenciadas pelo cliente, Link Privado do Azure e computação confidencial. Por meio desse alinhamento, a zona de destino soberana cria uma arquitetura de nuvem em que dados e cargas de trabalho oferecem criptografia e proteção contra ameaças por padrão.

Para obter mais informações sobre a zona de destino soberana, consulte SLZ (Zona de Destino Soberana).