Partilhar via

Considerações e recomendações de subscrição

  • Artigo

As subscrições são uma unidade de gestão, faturação e dimensionamento no Azure. Eles desempenham um papel crítico quando você projeta para adoção em larga escala do Azure. Este artigo ajuda você a capturar os requisitos de assinatura e projetar assinaturas de destino com base em fatores críticos que variam dependendo de:

  • Tipos de ambientes
  • Modelos de propriedade e governação
  • Estruturas organizacionais
  • Portfólios de aplicativos
  • Regiões

Gorjeta

Para obter mais informações sobre assinaturas, consulte o vídeo do YouTube: Zonas de aterrissagem do Azure - Quantas assinaturas devo usar no Azure?

Nota

Se utilizar Enterprise Agreements, Microsoft Customer Agreements (Enterprise) ou Microsoft Partner Agreements (CSP), reveja os limites de subscrição em Contas de faturação e âmbitos no portal do Azure.

Considerações sobre a subscrição

As seções a seguir contêm considerações para ajudá-lo a planejar e criar assinaturas para o Azure.

Considerações sobre design de organização e governança

  • As assinaturas servem como limites para atribuições de Política do Azure.

    Por exemplo, cargas de trabalho seguras, como cargas de trabalho PCI (Payment Card Industry), normalmente exigem outras políticas para alcançar a conformidade. Em vez de usar um grupo de gerenciamento para agrupar cargas de trabalho que exigem conformidade com PCI, você pode obter o mesmo isolamento com uma assinatura, sem ter muitos grupos de gerenciamento com algumas assinaturas.

    Se você precisar agrupar muitas assinaturas do mesmo arquétipo de carga de trabalho, crie-as em um grupo de gerenciamento.

  • As assinaturas servem como uma unidade de escala para que as cargas de trabalho dos componentes possam ser dimensionadas dentro dos limites de assinatura da plataforma. Certifique-se de considerar os limites de recursos de assinatura ao projetar suas cargas de trabalho.

  • As assinaturas fornecem um limite de gerenciamento para governança e isolamento que separa claramente as preocupações.

  • Crie assinaturas de plataforma separadas para gerenciamento (monitoramento), conectividade e identidade quando forem necessárias.

    • Estabeleça uma assinatura de gerenciamento dedicada em seu grupo de gerenciamento de plataforma para dar suporte a recursos de gerenciamento global, como espaços de trabalho do Azure Monitor Logs e runbooks de Automação do Azure.

    • Estabeleça uma assinatura de identidade dedicada em seu grupo de gerenciamento de plataforma para hospedar controladores de domínio do Ative Directory do Windows Server quando necessário.

    • Estabeleça uma assinatura de conectividade dedicada em seu grupo de gerenciamento de plataforma para hospedar um hub WAN Virtual do Azure, DNS (Sistema de Nomes de Domínio) privado, circuito de Rota Expressa do Azure e outros recursos de rede. Uma assinatura dedicada garante que todos os recursos da sua rede básica sejam cobrados juntos e isolados de outras cargas de trabalho.

    • Utilize as subscrições como uma unidade de gestão democratizada que se alinha com as necessidades e prioridades do seu negócio.

  • Use processos manuais para limitar os locatários do Microsoft Entra apenas a assinaturas de registro do Enterprise Agreement. Quando você usa um processo manual, não pode criar assinaturas do Microsoft Developer Network (MSDN) no escopo do grupo de gerenciamento raiz.

    Para obter suporte, envie um tíquete de suporte do Azure.

    Para obter informações sobre transferências de assinatura entre ofertas de cobrança do Azure, consulte Hub de transferência de assinatura e reserva do Azure.

Considerações sobre várias regiões

Importante

As assinaturas não estão vinculadas a uma região específica e você pode tratá-las como assinaturas globais. Eles são construções lógicas para fornecer controles de cobrança, governança, segurança e identidade para recursos do Azure contidos neles. Portanto, você não precisa de uma assinatura separada para cada região.

  • Você pode adotar uma abordagem multirregional no nível de carga de trabalho única para dimensionamento ou recuperação de desastres geográficos ou em um nível global (cargas de trabalho diferentes em regiões diferentes).

  • Uma única assinatura pode conter recursos de diferentes regiões, dependendo dos requisitos e da arquitetura.

  • Em um contexto de recuperação de desastres geográficos, você pode usar a mesma assinatura para conter recursos de regiões primárias e secundárias, pois eles fazem parte logicamente da mesma carga de trabalho.

  • Você pode implantar ambientes diferentes para a mesma carga de trabalho em regiões diferentes para otimizar os custos e a disponibilidade de recursos.

  • Em uma assinatura que contém recursos de várias regiões, você pode usar grupos de recursos para organizar e conter recursos por região.

Considerações sobre o design da cota e da capacidade

As regiões do Azure podem ter um número finito de recursos. Como resultado, você deve acompanhar a capacidade disponível e as SKUs para adoções do Azure com vários recursos.

  • Considere limites e cotas dentro da plataforma Azure para cada serviço que suas cargas de trabalho exigem.

  • Considere a disponibilidade das SKUs necessárias nas regiões do Azure escolhidas. Por exemplo, podem estar disponíveis novas funcionalidades apenas em determinadas regiões. A disponibilidade de determinadas SKUs para determinados recursos, como máquinas virtuais (VMs), pode variar de uma região para outra.

  • Considere que as cotas de assinatura não são garantias de capacidade e são aplicadas por região.

    Para reservas de capacidade de máquina virtual, consulte Reserva de capacidade sob demanda.

  • Considere a possibilidade de reutilizar subscrições não utilizadas ou desativadas. Para obter mais informações, consulte Criar ou reutilizar assinaturas do Azure.

Considerações de design de restrição de transferência de locatário

Cada assinatura do Azure é vinculada a um único locatário do Microsoft Entra, que atua como um provedor de identidade (IdP) para sua assinatura do Azure. Use o locatário do Microsoft Entra para autenticar usuários, serviços e dispositivos.

Quando qualquer usuário tiver as permissões necessárias, ele poderá alterar o locatário do Microsoft Entra vinculado à sua assinatura do Azure. Para obter mais informações, consulte:

Nota

Não é possível transferir para um locatário diferente do Microsoft Entra para assinaturas do Provedor de Soluções de Nuvem (CSP) do Azure.

Para zonas de aterrissagem do Azure, você pode definir requisitos para impedir que os usuários transfiram assinaturas para o locatário do Microsoft Entra da sua organização. Para obter mais informações, veja Gerir políticas de subscrição do Azure.

Configure sua política de assinatura fornecendo uma lista de usuários isentos. Os usuários isentos têm permissão para ignorar as restrições definidas na política.

Importante

Uma lista de usuários isentos não é uma Política do Azure.

  • Considere se você deve permitir que os usuários que têm assinaturas do Visual Studio ou do MSDN Azure transfiram suas assinaturas de ou para seu locatário do Microsoft Entra.

  • Somente usuários com a função de Administrador Global do Microsoft Entra podem definir as configurações de transferência de locatário. Esses usuários devem ter acesso elevado para alterar a política.

    • Você só pode especificar contas de usuário individuais como usuários isentos, não grupos do Microsoft Entra.

Importante

A Microsoft recomenda que você use funções com o menor número de permissões. Isso ajuda a melhorar a segurança da sua organização. Administrador Global é uma função altamente privilegiada que deve ser limitada a cenários de emergência quando você não pode usar uma função existente.

  • Todos os utilizadores com acesso ao Azure podem ver a política definida para o seu inquilino do Microsoft Entra.

    • Os utilizadores não podem ver a sua lista de utilizadores isentos.

    • Os usuários podem exibir os administradores globais em seu locatário do Microsoft Entra.

  • As assinaturas do Azure que você transfere para um locatário do Microsoft Entra são colocadas no grupo de gerenciamento padrão para esse locatário.

  • Se sua organização aprovar, sua equipe de aplicativos poderá definir um processo para permitir que as assinaturas do Azure sejam transferidas de ou para um locatário do Microsoft Entra.

Considerações sobre o projeto de gerenciamento de custos

Toda grande organização empresarial tem o desafio de gerenciar a transparência de custos. Esta seção explora os principais aspetos para alcançar a transparência de custos em grandes ambientes do Azure.

  • Talvez seja necessário compartilhar modelos de estorno, como o Ambiente do Serviço de Aplicativo e o Serviço Kubernetes do Azure (AKS), para obter maior densidade. Os modelos de estorno podem afetar os recursos de plataforma compartilhada como serviço (PaaS).

  • Utilize uma agenda de encerramento para cargas de trabalho de não produção de forma a otimizar os custos.

  • Use o Azure Advisor para obter recomendações para otimizar custos.

  • Estabeleça um modelo de estorno para uma melhor distribuição de custos em toda a sua organização.

  • Implemente a política para que os usuários não possam implantar recursos não autorizados no ambiente da sua organização.

  • Estabeleça um cronograma e uma cadência regulares para revisar o custo e os recursos de tamanho certo para cargas de trabalho.

Recomendações de subscrição

As seções a seguir contêm recomendações para ajudá-lo a planejar e criar assinaturas para o Azure.

Recomendações de organização e governança

  • Trate as subscrições como uma unidade de gestão alinhada com as necessidades e prioridades do seu negócio.

  • Informe os proprietários de assinaturas sobre suas funções e responsabilidades.

    • Faça uma revisão de acesso trimestral ou anual para o Microsoft Entra Privileged Identity Management (PIM) para garantir que os privilégios não proliferem quando os usuários se movem dentro da sua organização.

    • Aproprie-se plenamente das despesas e dos recursos orçamentais.

    • Garanta a conformidade da política e corrija quando necessário.

  • Ao identificar requisitos para novas assinaturas, faça referência aos seguintes princípios:

    • Limites de escala: as assinaturas servem como uma unidade de escala para cargas de trabalho de componentes serem dimensionadas dentro dos limites de assinatura da plataforma. Grandes cargas de trabalho especializadas, como computação de alto desempenho, IoT e SAP, devem usar assinaturas separadas para evitar esbarrar nesses limites.

    • Limite de gerenciamento: as assinaturas fornecem um limite de gerenciamento para governança e isolamento, o que permite uma separação clara de preocupações. Vários ambientes, como ambientes de desenvolvimento, teste e produção, são frequentemente removidos de uma perspetiva de gerenciamento.

    • Limite de política: as assinaturas servem como um limite para as atribuições da Política do Azure. Por exemplo, cargas de trabalho seguras, como cargas de trabalho PCI, normalmente exigem outras políticas para alcançar a conformidade. A outra sobrecarga não será considerada se você usar uma assinatura separada. Os ambientes de desenvolvimento têm requisitos de política mais relaxados do que os ambientes de produção.

    • Topologia de rede de destino: você não pode compartilhar redes virtuais entre assinaturas, mas pode conectá-las a diferentes tecnologias, como emparelhamento de rede virtual ou Rota Expressa. Ao decidir se precisa de uma nova assinatura, considere quais cargas de trabalho precisam se comunicar entre si.

  • Agrupe subscrições em grupos de gestão, que estão alinhados com a estrutura do grupo de gestão e os requisitos da política. Assinaturas de grupo para garantir que as assinaturas com o mesmo conjunto de políticas e atribuições de função do Azure venham do mesmo grupo de gerenciamento.

  • Estabeleça uma assinatura de gerenciamento dedicada em seu Platform grupo de gerenciamento para dar suporte a recursos de gerenciamento global, como espaços de trabalho de Logs do Azure Monitor e runbooks de automação.

  • Estabeleça uma assinatura de identidade dedicada em seu Platform grupo de gerenciamento para hospedar controladores de domínio do Ative Directory do Windows Server quando necessário.

  • Estabeleça uma assinatura de conectividade dedicada em seu Platform grupo de gerenciamento para hospedar um hub WAN virtual, DNS privado, circuito de Rota Expressa e outros recursos de rede. Uma assinatura dedicada garante que todos os recursos da sua rede básica sejam cobrados juntos e isolados de outras cargas de trabalho.

  • Evite um modelo de subscrição rígido. Em vez disso, use um conjunto de critérios flexíveis para agrupar assinaturas em toda a organização. Esta flexibilidade garante que, à medida que a composição da carga de trabalho e estrutura da organização muda, pode criar novos grupos de subscrição em vez de utilizar um conjunto fixo de subscrições existentes. Um tamanho único não serve para todas as assinaturas, e o que funciona para uma unidade de negócios pode não funcionar para outra. Algumas aplicações podem coexistir na mesma subscrição de zona de destino, enquanto outras podem exigir a sua própria subscrição.

    Para obter mais informações, consulte Manipular zonas de aterrissagem de carga de trabalho de desenvolvimento/teste/produção.

Recomendações para várias regiões

  • Crie assinaturas adicionais para cada região somente se você tiver requisitos de governança e gerenciamento específicos da região, por exemplo, soberania de dados ou para escalar além dos limites de cota.

  • Se o dimensionamento não for uma preocupação para um ambiente de recuperação de desastres geográficos que abrange várias regiões, use a mesma assinatura para os recursos da região primária e secundária. Alguns serviços do Azure, dependendo da estratégia e das ferramentas de continuidade de negócios e recuperação de desastres (BCDR) adotadas, talvez precisem usar a mesma assinatura. Em um cenário ativo-ativo, em que as implantações são gerenciadas independentemente ou têm ciclos de vida diferentes, recomendamos que você use assinaturas diferentes.

  • A região onde você cria um grupo de recursos e a região dos recursos contidos devem corresponder para que não afetem a resiliência e a confiabilidade.

  • Um único grupo de recursos não deve conter recursos de regiões diferentes. Essa abordagem pode levar a problemas com o gerenciamento e a disponibilidade de recursos.

Recomendações em matéria de quotas e capacidades

  • Use assinaturas como unidades de escala e dimensione recursos e assinaturas conforme necessário. Sua carga de trabalho pode usar os recursos necessários para dimensionamento sem atingir os limites de assinatura na plataforma Azure.

  • Use reservas de capacidade para gerenciar a capacidade em algumas regiões. Sua carga de trabalho pode então ter a capacidade necessária para recursos de alta demanda em uma região específica.

  • Estabeleça um painel com exibições personalizadas para monitorar os níveis de capacidade usados e configure alertas se a capacidade se aproximar de níveis críticos, como 90% de uso da CPU.

  • Levante solicitações de suporte para aumentos de cota no provisionamento de assinatura, como para o total de núcleos de VM disponíveis em uma assinatura. Certifique-se de que seus limites de cota sejam definidos antes que suas cargas de trabalho excedam os limites padrão.

  • Certifique-se de que todos os serviços e recursos necessários estejam disponíveis nas regiões de implantação escolhidas.

Recomendações de automação

  • Crie um processo de venda automática de assinaturas para automatizar a criação de assinaturas para equipes de aplicativos por meio de um fluxo de trabalho de solicitação. Para obter mais informações, consulte Subscrição vending.

Recomendações de restrição de transferência de locatário

  • Configure as seguintes configurações para impedir que os usuários transfiram assinaturas do Azure de ou para seu locatário do Microsoft Entra:

    • Defina Subscription deixando o diretório Microsoft Entra como Permit no one.

    • Defina Assinatura inserindo o diretório Microsoft Entra como Permit no one.

  • Configure uma lista limitada de usuários isentos.

    • Inclua membros de uma equipe de operações da plataforma Azure.

    • Inclua contas quebra-vidro na lista de usuários isentos.

Próximo passo

Adote guarda-corpos orientados por políticas