Perguntas frequentes sobre zonas de atterragem do Azure

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

Para FAQs sobre implementação da arquitetura da zona de aterragem Azure, consulte FAQ sobre implementação em escala empresarial.

O que é o acelerador de portal da zona de aterragem Azure?

O acelerador de portal para zona de aterragem do Azure é uma experiência de implementação baseada no portal do Azure. Implementa uma solução orientada baseada na arquitetura de referência da zona de aterragem do Azure.

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

Microsoft desenvolve e mantém ativamente os aceleradores de plataforma e aplicação e suas implementações, alinhados com os princípios de design design principles da zona de aterragem do Azure e a orientação área de design.

Consulte as orientações Deploy Azure landing zones para saber mais sobre a plataforma recomendada e as zonas de aterragem da aplicação.

Para aprender a adaptar a implantação das suas zonas de aterragem Azure às suas necessidades, veja Adapte a arquitetura Azure da zona de aterragem para cumprir requisitos

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

A arquitetura de referência da zona de aterragem Azure representa decisões de escala e maturidade. Baseia-se nas lições aprendidas e no feedback de clientes que adotaram o Azure como parte do seu património digital. Essa arquitetura conceitual pode ajudar sua organização a definir uma direção para projetar e implementar uma zona de pouso.

Para que é que uma zona de aterragem corresponde no Azure no contexto da arquitetura da zona de aterragem do Azure?

Do ponto de vista das zonas de aterragem do Azure, as zonas de aterragem são subscrições individuais do Azure.

O que significa governação orientada por políticas e como funciona?

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

Gestão orientada por políticas significa usar o Azure Policy para reduzir o tempo necessário para realizar tarefas operacionais comuns e repetidas em todo o seu locatário Azure. Utilizar muitos dos efeitos Azure Policy, como Append, Deny, DeployIfNotExists e Modify, para evitar a não conformidade, restringindo ou atualizando recursos não conformes (conforme definido pela definição da política) ou implementando recursos ou modificando definições de um pedido de criação ou atualização de recursos para os tornar compatíveis. Alguns efeitos, como Audit, Disabled, e AuditIfNotExists, não impedem ou tomam medidas, apenas auditam e relatam o não cumprimento.

Eis alguns exemplos de governação orientada para as políticas:

• Deny efeito: Impede que sub-redes sejam criadas ou atualizadas para que não haja Grupos de Segurança de Rede associados a elas.

• DeployIfNotExists efeito: Uma nova subscrição (zona de aterragem) é criada e colocada num grupo de gestão na sua implementação da zona de aterragem Azure. O Azure Policy garante que o Microsoft Defender para a Cloud está ativado na subscrição. Também configura as definições de diagnóstico do Registo de Atividade para enviar registos para o espaço de trabalho do Log Analytics na subscrição de Gestão.

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

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

Temos uma página dedicada que percorre as várias fases e opções necessárias para "desativar" as políticas do DINE ou usar nossa abordagem trifásica para adotá-las ao longo do tempo em seu ambiente.

Veja as orientações Adotando guarda-corpos orientados por políticas

Devemos usar o Azure Policy para implementar cargas de trabalho?

Em suma, não. Use o Azure Policy para controlar, governar e manter as suas cargas de trabalho e zonas de aterragem em conformidade. Ele não foi projetado para implantar cargas de trabalho inteiras e outras ferramentas. Use o portal Azure ou as ofertas de infraestrutura como código (ARM Templates, Bicep, Terraform) para implementar e gerir a sua carga de trabalho e obter a autonomia de que precisa.

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

As zonas de aterragem Cloud Adoption Framework open source (OSS) (também conhecidas como aztfmod) são um projeto impulsionado pela comunidade, propriedade e mantido fora da equipa central da zona de aterragem Azure e da organização Azure GitHub. Se a sua organização optar por utilizar este projeto OSS, deve considerar-se o suporte disponível, pois este é impulsionado pelo esforço da comunidade através do GitHub.

E se já tivermos recursos nas nossas zonas de aterragem e mais tarde atribuirmos uma definição do Azure Policy que os inclua no seu âmbito?

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

• Transição dos ambientes de Azure existentes para a arquitetura de referência da zona de aterragem Azure - secção "Política
• Guia de 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 pouso de IA dedicada ou separada?

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

Como gerimos as zonas de destino da carga de trabalho "dev/test/production" na arquitetura de zonas de destino do Azure?

Para mais informações, consulte Gerir ambientes de desenvolvimento de aplicações em zonas de aterragem Azure.

Porque é que nos pedem para especificar regiões do Azure durante a implementação da arquitetura de referência da zona de aterragem do Azure e para que são usadas?

Quando implementa a arquitetura de zonas de aterragem Azure utilizando a experiência baseada em portal de arquitetura de referência de zonas de aterragem Azure, selecione uma região Azure para implementar. A primeira guia, Local de implantação, determina onde os dados de implantação são armazenados. Para obter mais informações, consulte Implementações de inquilinos com modelos ARM. Algumas partes de uma zona de aterrissagem são implantadas globalmente, mas seus metadados de implantação são rastreados em um repositório de metadados regional. Os metadados relativos à sua implementação são armazenados na região selecionada no separador Local de implementação .

O seletor de região no separador local de implementação também é usado para selecionar em que região do Azure qualquer recurso específico da região deve ser armazenado, como um espaço de trabalho do Log Analytics, se necessário.

Se implementares uma topologia de rede no separador Topologia de Rede e conectividade, precisas de selecionar uma região Azure para onde implantares 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 aterrissagem usam, consulte Regiões da zona de desembarque.

Como é que podemos ativar mais regiões do Azure quando usamos a arquitetura de zonas de aterragem do Azure?

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

Devemos criar uma nova Subscrição do Azure sempre ou devemos reutilizar as Subscrições do Azure?

O que é a reutilização de subscrição?

A reutilização da subscrição é o processo de reemissão de uma subscrição existente para um novo proprietário. Deve haver um processo para redefinir a assinatura para um estado limpo e conhecido e, em seguida, reatribuí-la a um novo proprietário.

Por que devo considerar a reutilização de assinaturas?

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

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

• Tem um Enterprise Agreement (EA) e planeia criar mais de 5.000 subscrições numa única Conta de Proprietário EA (conta de faturação), incluindo subscrições eliminadas.
• Tem um Contrato de Cliente Microsoft (MCA) ou Contrato de Parceiro da Microsoft MPA e planeia ter mais de 5.000 subscrições ativas. Para saber mais sobre os limites de subscrição, consulte Contas de faturação e âmbitos no portal Azure.
• Você é um cliente pré-pago.
• Utilizas um patrocínio Microsoft Azure.
• Você normalmente cria:
  1. Ambientes efêmeros de laboratório ou sandbox
  2. Ambientes de demonstração para provas de conceito (POCs) ou produtos mínimos viáveis (MVP), incluindo fornecedores independentes de software (ISV) para demonstração/avaliação aos clientes.
  3. Ambientes de formação, tais como ambientes de aprendizagem de MSPs/Formadores

Como posso reutilizar subscrições?

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

Limpar subscrição 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:

• Remova Grupos de Recursos e recursos contidos.
• Remover as atribuições de funções, incluindo as atribuições de funções de Gestão de Identidade Privilegiada (PIM), no âmbito de subscrição.
• Remover as definições personalizadas de Controlo de Acesso Baseado em Funções (RBAC) no âmbito da subscrição.
• Remova Definições, Iniciativas, Atribuições e Isenções de Política no escopo da assinatura.
• Remova implantações no âmbito da assinatura.
• Remova as tags no escopo da assinatura.
• Remova todos os bloqueios de recursos no escopo da assinatura.
• Remova quaisquer orçamentos do Microsoft Cost Management no âmbito da subscrição.
• Repor os planos do Microsoft Defender para a Cloud para "Free Tiers", a menos que os requisitos organizacionais exijam que estes registos sejam configurados para os níveis pagos. Normalmente aplicas estes requisitos através do Azure Policy.
• Remover registos de atividade de subscrição (definições de diagnóstico) que encaminham para os espaços de trabalho do Log Analytics, Centros de Eventos, Conta de Armazenamento ou outros destinos suportados, a menos que os requisitos organizacionais obriguem a encaminhar estes registos enquanto a subscrição está ativa.
• Remova quaisquer delegações do Azure Lighthouse no âmbito da subscrição.
• Remova todos os recursos ocultos da assinatura.

Reatribuir a subscrição

Você pode reatribuir a assinatura depois de limpar a assinatura. Aqui estão algumas atividades comuns que você pode querer executar como parte do processo de reatribuição:

• Adicione novas tags e defina valores para elas na assinatura.
• Adicione novas Atribuições de Funções, ou Atribuições de Funções do Privileged Identity Management (PIM), no âmbito da subscrição para os novos proprietários. Normalmente, estas atribuições seriam para grupos da Microsoft Entra em vez de indivíduos.
• Coloque a assinatura no Grupo de Gestão desejado com base nos seus requisitos de governança.
• Crie novos orçamentos do Microsoft Cost Management e defina alertas para os novos proprietários quando os limites forem atingidos.
• Defina os planos do Microsoft Defender para a Cloud para os níveis desejados. Deve aplicar esta configuração através do Azure Policy assim que for colocado no Grupo de Gestão correto.
• Configure registos de atividade de subscrição (definições de diagnóstico) que sejam encaminhados para espaços de trabalho do Log Analytics, Centros de Eventos, Conta de Armazenamento ou outros destinos suportados. Deve aplicar esta configuração através do Azure Policy assim que for colocado no Grupo de Gestão correto.

O que é uma zona de aterragem soberana e como está relacionada com a arquitetura da zona de aterragem do Azure?

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

Para mais informações sobre a zona de aterragem soberana, consulte Zona de Desembarque Soberana (SLZ).