Fundamentação Teórica: Manage Subscriptions

1. Intuição Inicial

Pense em uma grande empresa com filiais em vários países. Cada filial tem seu próprio orçamento, suas próprias contas bancárias, seus próprios limites de gasto. A matriz pode ver tudo, mas cada filial é uma unidade financeira e administrativa independente.

No Azure, uma Subscription é exatamente essa unidade: um contrato com a Microsoft que define limites de cobrança, limites de recursos e um perímetro administrativo. Tudo que você cria no Azure existe dentro de uma subscription. Ela é o nível onde a fatura é gerada, onde cotas de recursos são definidas e onde limites administrativos são estabelecidos.

Organizações pequenas geralmente começam com uma única subscription e gerenciam tudo dentro dela. Organizações maiores frequentemente têm dezenas ou centenas de subscriptions, cada uma representando um departamento, projeto, ambiente ou região geográfica.

2. Contexto

Onde Subscriptions se encaixam na hierarquia Azure

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A Subscription é o segundo nível da hierarquia Azure (abaixo do Tenant e Management Groups, acima dos Resource Groups). Ela é o limite fundamental de cobrança e o container principal de recursos.

Por que Subscriptions existem como unidade separada

Subscriptions existem por três razões fundamentais:

1. Limite de cobrança: cada subscription gera uma fatura separada. Isso permite chargeback preciso por departamento ou projeto.

2. Limite de escala: cada subscription tem cotas independentes de recursos (número de VMs, CPUs, IPs públicos, etc.). Separar em subscriptions evita que um projeto esgote os recursos de toda a organização.

3. Limite de controle de acesso: permite que times tenham autonomia total dentro de sua subscription sem afetar outras subscriptions.

O que depende de Subscriptions

Todo Resource Group pertence a uma subscription
Cotas de recursos são por subscription
Faturamento é por subscription
RBAC, Policy e Locks aplicados em subscription herdam para todos os RGs e recursos dentro
Service Limits (cotas) são definidos por subscription

3. Construção dos Conceitos

3.1 Tipos de Subscription

Subscriptions não são todas iguais. O tipo determina o modelo de preço, os limites e os recursos disponíveis:

Tipo	Descrição	Caso de uso
Pay-As-You-Go	Paga pelo que usa, sem compromisso	Startups, projetos variáveis
Enterprise Agreement (EA)	Contrato plurianual com descontos por volume	Grandes empresas com gasto previsível
Microsoft Customer Agreement (MCA)	Sucessor moderno do EA, mais flexível	Empresas de médio a grande porte
Cloud Solution Provider (CSP)	Gerenciada por parceiro Microsoft	Clientes que compram via revendedor
Visual Studio / Dev/Test	Créditos mensais para desenvolvimento	Desenvolvedores individuais, times de dev
Azure Free	Crédito inicial + serviços gratuitos por 12 meses	Experimentação inicial
Azure for Students	Créditos para estudantes	Educação
Sponsored	Créditos fornecidos pela Microsoft	Startups via programas específicos

3.2 Relacionamento Subscription e Azure AD Tenant

Esta é uma das distinções mais importantes e frequentemente mal compreendida:

Tenant é a instância do Azure Active Directory. É a identidade da organização: onde usuários, grupos e aplicações vivem.

Subscription confia em um Tenant para autenticação. Uma subscription está associada a exatamente um Tenant por vez, mas um Tenant pode ter múltiplas subscriptions.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Implicação crítica: quando você move uma subscription para um Tenant diferente (processo chamado de transfer), todos os role assignments (RBAC) são perdidos, porque os usuários do Tenant antigo não existem no novo Tenant. Os recursos em si são preservados, mas o acesso precisa ser reconfigurado completamente.

3.3 Subscription ID e nome

Cada subscription tem:

ID: GUID único e imutável (ex: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
Nome: string legível, editável, não única globalmente
Estado: Enabled, Disabled, Deleted, Warned, Past Due

O ID é o identificador permanente. O nome pode ser alterado sem impacto nos recursos. Em scripts e automação, sempre use o ID, nunca o nome.

3.4 Estados de uma Subscription

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Estado Disabled é crítico: quando uma subscription fica Disabled, os recursos dentro dela ficam inacessíveis (não são deletados imediatamente). Você tem um período de 90 dias para reabilitar antes que os recursos sejam permanentemente deletados. Durante esse período, os dados estão preservados mas sem acesso.

3.5 Service Limits e Quotas

Cada subscription tem limites (cotas) por tipo de recurso e por região. Esses limites existem para proteger a infraestrutura compartilhada da Microsoft e podem ser aumentados via request.

Exemplos de limites padrão importantes:

Recurso	Limite padrão	Limite máximo
VMs por região	25.000	Depende do tipo de VM
vCPUs totais por subscription	20 (pay-as-you-go)	Solicitável
Resource Groups por subscription	980	980 (fixo)
Role assignments por subscription	4.000	4.000 (fixo)
Virtual Networks por subscription	50	1.000
Public IP addresses	20	Solicitável
Storage Accounts por subscription	250	250 por região

Os limites de vCPUs são os mais frequentemente atingidos e os mais importantes para solicitar aumento antes de precisar.

3.6 Management Groups

Management Groups são contêineres que organizam múltiplas subscriptions em uma hierarquia. Eles permitem aplicar governance (RBAC, Policy, Locks) em escala sobre um conjunto de subscriptions.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O padrão acima é o Azure Landing Zone da Microsoft, a arquitetura de referência para organização de subscriptions em escala empresarial.

Cada subscription pode pertencer a apenas um Management Group por vez, mas pode ser movida entre Management Groups.

3.7 Transferência de Subscription

Uma subscription pode ser transferida para outro Tenant ou outra conta de cobrança. Este é um processo administrativo distinto da gestão técnica de recursos:

Transfer de cobrança: muda quem paga a fatura. Os recursos e role assignments são preservados se o Tenant não mudar.

Transfer de Tenant (Change Directory): muda para qual Azure AD a subscription confia. Todos os role assignments são perdidos. Managed Identities são resetadas. O Service Principal de aplicações precisa ser recriado no novo Tenant.

4. Visão Estrutural

Como Subscriptions interagem com os demais conceitos de governança

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A Subscription é o ponto de convergência de todos os conceitos de governança estudados nos módulos anteriores: ela é o escopo onde RBAC, Policy, Locks e Tags podem ser aplicados para cobrir todos os RGs e recursos dentro.

5. Funcionamento na Prática

Ciclo de vida de uma Subscription

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos não óbvios importantes

A subscription tem seu próprio Activity Log. Todo evento de criação, modificação e deleção de recursos em uma subscription é registrado no Activity Log da subscription. Esse log é retido por 90 dias por padrão. Para retenção maior, configure export para Log Analytics ou Storage Account.

Mover subscription entre Management Groups não afeta os recursos. Quando você move uma subscription de um Management Group para outro, as policies e role assignments do MG de origem deixam de se aplicar e as do novo MG passam a vigorar. Os recursos em si não são afetados, mas a governança muda imediatamente.

Subscriptions não se comunicam entre si por padrão. Recursos em subscriptions diferentes não têm conectividade de rede automática. Para conectar redes entre subscriptions, é necessário VNet Peering cross-subscription ou VPN Gateway.

Limites de quota são por subscription por região. O limite de vCPUs não é global: é separado por família de VM (D-series, E-series, etc.) e por região. Você pode ter 100 vCPUs de D-series em East US mas apenas 10 em Brazil South. Planejar capacidade requer verificar quotas na região específica onde os recursos serão criados.

Faturamento da subscription tem atraso. Os dados de custo no Cost Management têm atraso de até 72 horas para alguns serviços. Não tome decisões de scaling baseado nos números em tempo real sem considerar esse atraso.

6. Formas de Implementação

Portal do Azure

Para visualizar e gerenciar subscriptions:

Portal > Subscriptions (buscar no search bar ou no menu)
Lista de todas as subscriptions às quais você tem acesso
Clicar em uma subscription para ver: visão geral, IAM, políticas, custo, recursos

Para verificar e solicitar aumento de quotas:

Portal > Subscriptions > selecionar subscription
Usage + quotas no menu lateral
Filtrar por provider, região e tipo de recurso
Clicar em Request increase para tipos com limite insuficiente

Para mover subscription entre Management Groups:

Portal > Management Groups
Localizar a subscription
Selecionar Move e escolher o Management Group destino

Limitação do portal: criação de subscriptions via portal é limitada dependendo do tipo de enrollment. EA e MCA têm processos específicos.

Azure CLI

# Listar todas as subscriptions acessíveis
az account list --output table

# Ver subscription ativa no contexto atual
az account show

# Mudar a subscription ativa no contexto do CLI
az account set --subscription "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# ou pelo nome:
az account set --subscription "Empresa-Prod"

# Ver detalhes completos de uma subscription
az account show --subscription "<sub-id>" --output json

# Listar todas as localizações disponíveis em uma subscription
az account list-locations --output table

# Verificar quotas de vCPUs em uma região
az vm list-usage \
  --location "brazilsouth" \
  --output table

# Verificar quota de um recurso específico
az vm list-usage \
  --location "brazilsouth" \
  --query "[?name.value=='cores']" \
  --output table

# Listar resource providers registrados na subscription
az provider list \
  --query "[?registrationState=='Registered'].namespace" \
  --output tsv

# Registrar um resource provider
az provider register --namespace "Microsoft.Compute"

# Verificar status de registro
az provider show --namespace "Microsoft.Compute" --query "registrationState"

# Mover subscription para Management Group diferente
az management-groups subscription add \
  --name "mg-landing-zones" \
  --subscription "<sub-id>"

# Listar subscriptions em um Management Group
az management-groups entities list \
  --name "mg-landing-zones" \
  --query "[?type=='Microsoft.Management/managementGroups/subscriptions'].{Name:displayName, ID:name}" \
  --output table

# Criar alerta de custo em uma subscription
az consumption budget create \
  --budget-name "budget-sub-prod-mensal" \
  --amount 10000 \
  --time-grain Monthly \
  --start-date "2026-04-01" \
  --end-date "2027-03-31" \
  --notifications '{
    "actual_GreaterThan_80_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 80,
      "contactEmails": ["cloud-team@empresa.com", "finance@empresa.com"]
    },
    "actual_GreaterThan_100_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 100,
      "contactEmails": ["cto@empresa.com"]
    }
  }'

# Ver o custo atual da subscription
az consumption usage list \
  --start-date "2026-03-01" \
  --end-date "2026-03-24" \
  --output table

# Verificar activity log da subscription (últimas operações)
az monitor activity-log list \
  --max-events 20 \
  --output table

Azure PowerShell

# Listar subscriptions acessíveis
Get-AzSubscription | Select-Object Name, Id, State, TenantId

# Mudar contexto para uma subscription
Set-AzContext -SubscriptionId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Ou pelo nome
Set-AzContext -Subscription "Empresa-Prod"

# Ver contexto atual
Get-AzContext | Select-Object Name, Subscription, Tenant

# Verificar usage e quotas de VM em uma região
Get-AzVMUsage -Location "brazilsouth" |
  Select-Object @{N="Name"; E={$_.Name.LocalizedValue}}, CurrentValue, Limit |
  Sort-Object -Property CurrentValue -Descending

# Verificar quotas próximas do limite (acima de 80%)
Get-AzVMUsage -Location "brazilsouth" |
  Where-Object { $_.Limit -gt 0 -and ($_.CurrentValue / $_.Limit) -gt 0.8 } |
  Select-Object @{N="Resource"; E={$_.Name.LocalizedValue}}, CurrentValue, Limit

# Registrar resource provider
Register-AzResourceProvider -ProviderNamespace "Microsoft.ContainerService"

# Listar todos os resource providers e seu estado
Get-AzResourceProvider -ListAvailable |
  Select-Object ProviderNamespace, RegistrationState |
  Sort-Object RegistrationState

# Mover subscription entre Management Groups
New-AzManagementGroupSubscription `
  -GroupId "mg-landing-zones" `
  -SubscriptionId "<sub-id>"

# Criar budget de subscription
New-AzConsumptionBudget `
  -Name "budget-sub-prod-mensal" `
  -Amount 10000 `
  -Category Cost `
  -TimeGrain Monthly `
  -StartDate "2026-04-01" `
  -EndDate "2027-03-31"

Criação de Subscriptions via API (EA/MCA)

Para organizações com Enterprise Agreement ou Microsoft Customer Agreement, subscriptions podem ser criadas programaticamente:

# Criar subscription programaticamente (requer billing scope adequado)
az rest \
  --method POST \
  --url "https://management.azure.com/providers/Microsoft.Subscription/aliases/<alias-name>?api-version=2021-10-01" \
  --body '{
    "properties": {
      "displayName": "Empresa-App-Prod",
      "workload": "Production",
      "billingScope": "/providers/Microsoft.Billing/billingAccounts/<accountId>/enrollmentAccounts/<enrollmentAccountId>"
    }
  }'

Quando usar criação via API: automação de vending machine de subscriptions, onde novas subscriptions são criadas automaticamente como parte de um processo de onboarding de projetos ou times.

7. Controle e Segurança

Modelo de acesso a Subscriptions

O acesso a uma subscription segue exatamente o modelo RBAC estudado nos módulos anteriores, mas com implicações específicas:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Quem deve ser Owner da Subscription? Owner de subscription é um papel muito poderoso e deve ser restrito. As melhores práticas recomendam:

No máximo 2 a 3 pessoas com Owner (para continuidade operacional)
Usar grupos do Azure AD em vez de usuários individuais
Usar Privileged Identity Management (PIM) para Owner just-in-time

Resource Providers: o que são e por que importam

Antes de criar qualquer recurso em uma subscription, o Resource Provider correspondente precisa estar registrado. Um Resource Provider é o serviço ARM responsável por gerenciar aquele tipo de recurso.

Por exemplo:

Microsoft.Compute para VMs e discos
Microsoft.Network para VNets, NSGs, Load Balancers
Microsoft.Storage para Storage Accounts
Microsoft.KeyVault para Key Vaults
Microsoft.ContainerService para AKS

Muitos providers são registrados automaticamente quando você cria o primeiro recurso do tipo. Mas em automação via scripts, pode ser necessário registrar explicitamente antes de criar recursos.

# Verificar se um provider está registrado
az provider show --namespace "Microsoft.ContainerService" \
  --query "registrationState" --output tsv

# Registrar se não estiver
az provider register --namespace "Microsoft.ContainerService"

# Aguardar registro completar
az provider show --namespace "Microsoft.ContainerService" \
  --query "registrationState" --output tsv
# Repita até retornar "Registered"

Diagnóstico de custo e anomalias

Configure alertas de anomalia de custo no Cost Management para detectar gastos inesperados:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

8. Tomada de Decisão

Quantas subscriptions usar

Situação	Recomendação	Motivo
Startup ou projeto pequeno	1 subscription	Simplicidade operacional, custo de gerenciamento baixo
Empresa com prod e dev	Mínimo 2 subscriptions (prod, dev)	Isolamento de risco, billing separado
Enterprise com múltiplas aplicações	1 sub por aplicação por ambiente	Isolamento completo, chargebacks precisos, quotas independentes
Limite de quota atingido	Nova subscription	Cotas são por subscription; nova sub = novas cotas
Compliance requer isolamento completo	Subscription dedicada	Nenhum recurso de outro contexto no mesmo perímetro
Time com autonomia total	Subscription própria	Times podem gerenciar sem impactar outros

Quando criar nova Subscription vs. novo Resource Group

Necessidade	Escolha	Motivo
Separar dev de prod logicamente	Subscription separada	Billing independente, cotas independentes, isolamento real
Separar dois projetos com o mesmo ambiente	Resource Group separado	Mesmo ambiente, billing na mesma sub, mais simples
Atingiu limite de quota em uma sub	Nova subscription	Cotas são por subscription, não por RG
Compliance que exige isolamento de rede total	Subscription separada	VNets em subs diferentes são isoladas por padrão
Time precisa de autonomia sem afetar outros	Subscription separada	RBAC e Policy independentes
Apenas separação visual/organizacional	Resource Group separado	Overhead de gerenciar sub não se justifica

Escolha do tipo de Subscription

Situação	Tipo recomendado	Motivo
Empresa com gasto previsível e alto	Enterprise Agreement	Descontos por volume, billing centralizado
Empresa de médio porte	Microsoft Customer Agreement	Flexibilidade similar ao EA, sem compromisso mínimo tão alto
Dev/test da equipe	Visual Studio Dev/Test	Preços reduzidos para ambientes não-produtivos
Experimentação sem compromisso	Pay-As-You-Go	Sem contrato, paga só o que usa
Projeto novo que precisa testar	Free Trial ou Sandbox	Créditos iniciais sem custo

9. Boas Práticas

Defina um modelo de subscription antes de começar a criar recursos. A organização de subscriptions é difícil de refatorar depois. Decidir o modelo (por ambiente, por aplicação, por time) antes de provisionar os primeiros recursos economiza trabalho enorme no futuro.

Use Management Groups para governança em escala. Com mais de 2 subscriptions, Management Groups são essenciais. Policies e RBAC aplicados no Management Group se propagam para todas as subscriptions abaixo, eliminando a necessidade de repetir configurações.

Implante o padrão Azure Landing Zone para organizações. A Microsoft disponibiliza o Azure Landing Zone como código (Terraform/Bicep) que cria a hierarquia de Management Groups, subscriptions de plataforma (rede, identidade) e subscriptions de aplicação com toda a governança baseline configurada. É o ponto de partida recomendado para qualquer organização que vai usar Azure em escala.

Monitore quotas proativamente. Configure alertas quando o uso de vCPUs atingir 70% do limite. Solicitar aumento de quota leva de horas a dias, e esperar até atingir 100% causa indisponibilidade em deployments.

Mantenha o número de Owners mínimo e use PIM. Owner de subscription é extremamente poderoso. Com Privileged Identity Management, owners recebem o papel apenas quando precisam, por tempo limitado, com aprovação e auditoria.

Separe subscriptions de produção de desenvolvimento. Jamais coloque recursos de produção e desenvolvimento na mesma subscription. O risco de impacto cruzado (quotas compartilhadas, billing misturado, risco de deleção acidental) não se justifica pela simplificação.

Configure orçamentos e alertas de custo em toda subscription nova. Toda subscription criada deve ter imediatamente um budget configurado com alertas em 80% e 100%. Descobrir gastos excessivos apenas na fatura do mês é tarde demais.

Use naming convention consistente para subscriptions. Nomes como empresa-producao, empresa-desenvolvimento, empresa-sandbox comunicam imediatamente o propósito. Subscriptions com nomes como "Azure subscription 1" ou "Test" causam confusão operacional.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Colocar prod e dev na mesma subscription	Simplicidade inicial, sem visão de longo prazo	Separar desde o início; recriar depois é custoso
Não monitorar quotas até atingi-las	Falta de visibilidade proativa	Alertas de quota em 70% para solicitar aumento antes da necessidade
Dar Owner a muitas pessoas	Facilidade de acesso, falta de processo	Máximo 2-3 owners, PIM para acesso elevado
Transferir subscription de Tenant sem planejar RBAC	Não saber que role assignments são perdidos	Documentar todos os acessos antes do transfer, reconfigurar no novo Tenant
Não registrar resource providers em automação	Script funciona no portal (registro automático) mas falha em pipeline	Incluir etapa de registro de providers em pipelines
Confundir Tenant com Subscription	Terminologia similar, conceitos distintos	Tenant = identidade (AD); Subscription = cobrança e recursos
Criar subscriptions sem Management Group	Governança individual por subscription não escala	Definir hierarquia de MGs antes de criar subscriptions
Não configurar budget ao criar subscription	Custo não é uma prioridade no início	Incluir criação de budget como parte obrigatória do processo de criação de subscription
Usar nome da subscription em scripts em vez do ID	Nome pode mudar; ID é permanente	Sempre referenciar subscription por ID em scripts

O erro mais custoso

Criar todos os recursos de todos os projetos em uma única subscription sem separação por ambiente. Quando a quota de vCPUs é atingida por um job de processamento em desenvolvimento, os deployments de produção falham. Quando um desenvolvedor acidentalmente deleta um Resource Group com nome errado, leva recursos de produção junto. A separação em subscriptions é proteção fundamental, não burocracia.

11. Operação e Manutenção

Auditoria e inventário de Subscriptions

# Listar todas as subscriptions com estado e Tenant
az account list \
  --query "[].{Name:name, ID:id, State:state, Tenant:tenantId}" \
  --output table

# Verificar subscription com mais recursos (para planejamento de migração)
az graph query -q "
Resources
| summarize count() by subscriptionId
| order by count_ desc" \
--subscriptions "<sub-id1>" "<sub-id2>"

# Listar todos os owners de uma subscription
az role assignment list \
  --role "Owner" \
  --scope "/subscriptions/<sub-id>" \
  --include-inherited \
  --output table

# Ver quotas críticas em todas as regiões
for region in brazilsouth eastus westeurope; do
  echo "=== $region ==="
  az vm list-usage \
    --location "$region" \
    --query "[?currentValue > 0].{Resource:name.localizedValue, Current:currentValue, Limit:limit}" \
    --output table
done

Monitoramento de custo e anomalias

# Ver custo total da subscription no mês atual
az consumption usage list \
  --start-date "$(date -d 'first day of this month' +%Y-%m-%d)" \
  --end-date "$(date +%Y-%m-%d)" \
  --query "sum([].pretaxCost)" \
  --output tsv

# Ver os 10 recursos mais caros do mês
az consumption usage list \
  --start-date "2026-03-01" \
  --end-date "2026-03-24" \
  --query "sort_by([].{Resource:instanceName, Cost:pretaxCost, Currency:currency}, &Cost) | reverse(@) | [:10]" \
  --output table

# Verificar todos os budgets configurados
az consumption budget list --output table

Configurar export de Activity Log para retenção longa

Por padrão, o Activity Log da subscription retém apenas 90 dias. Para conformidade e auditoria de longo prazo:

# Criar configuração de diagnóstico para exportar Activity Log ao Log Analytics
az monitor diagnostic-settings create \
  --name "sub-activity-log-export" \
  --resource "/subscriptions/<sub-id>" \
  --workspace "<log-analytics-workspace-id>" \
  --logs '[
    {"category": "Administrative", "enabled": true},
    {"category": "Security", "enabled": true},
    {"category": "ServiceHealth", "enabled": true},
    {"category": "Alert", "enabled": true},
    {"category": "Policy", "enabled": true}
  ]'

Limites da Subscription importantes para o dia a dia

Limite	Valor	Impacto operacional
Resource Groups por subscription	980	Raramente atingido; indica necessidade de nova subscription se próximo
Role assignments por subscription	4.000	Importante monitorar em orgs grandes; usar grupos
vCPUs padrão por região	20 (PAYG) / maior em EA	Solicitar aumento antes de precisar
Public IP por subscription	20	Solicitar aumento para ambientes com muitos serviços expostos
Storage Accounts por região	250	Relevante para arquiteturas com muitos storage accounts
Deployments no Activity Log	Sem limite de criação, mas UI mostra até 800 por RG	Exportar para Log Analytics para histórico completo

12. Integração e Automação

Subscription Vending Machine

Em organizações enterprise, o processo de criar novas subscriptions é automatizado como um "vending machine": um desenvolvedor ou time solicita uma nova subscription via formulário ou pipeline, e o processo automaticamente cria a subscription, coloca no Management Group correto, configura RBAC baseline, aplica tags e cria os budgets.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Terraform para gestão de subscriptions em escala

# Criar subscription (requer billing scope de EA ou MCA)
resource "azurerm_subscription" "app_prod" {
  subscription_name = "empresa-app-producao"
  billing_scope_id  = "/providers/Microsoft.Billing/billingAccounts/<account>/enrollmentAccounts/<enrollment>"
  workload          = "Production"
  
  tags = {
    Environment = "Production"
    Project     = "app"
    Owner       = "time-cloud"
    CreatedBy   = "terraform"
  }
}

# Mover para Management Group
resource "azurerm_management_group_subscription_association" "app_prod" {
  management_group_id = "/providers/Microsoft.Management/managementGroups/mg-corp-prod"
  subscription_id     = azurerm_subscription.app_prod.id
}

# Criar budget na subscription
resource "azurerm_consumption_budget_subscription" "app_prod_budget" {
  name            = "budget-app-prod-mensal"
  subscription_id = azurerm_subscription.app_prod.id
  amount          = 15000
  time_grain      = "Monthly"

  time_period {
    start_date = "2026-04-01T00:00:00Z"
    end_date   = "2027-03-31T00:00:00Z"
  }

  notification {
    enabled        = true
    threshold      = 80
    operator       = "GreaterThan"
    threshold_type = "Actual"
    contact_emails = ["cloud-team@empresa.com"]
  }

  notification {
    enabled        = true
    threshold      = 100
    operator       = "GreaterThan"
    threshold_type = "Actual"
    contact_emails = ["cto@empresa.com", "finance@empresa.com"]
  }
}

Integração com Microsoft Cost Management APIs

Para relatórios de custo automatizados por subscription:

# Exportar relatório de custo da subscription para Storage Account (automático mensal)
az consumption export create \
  --name "export-mensal-sub-prod" \
  --type ActualCost \
  --billing-period-start "2026-04-01" \
  --billing-period-end "2027-03-31" \
  --recurrence Monthly \
  --recurrence-period from="2026-04-01" to="2027-03-31" \
  --storage-account-id "/subscriptions/<sub-id>/resourceGroups/rg-billing/providers/Microsoft.Storage/storageAccounts/stgbillingexport" \
  --storage-container "cost-exports" \
  --storage-directory "sub-producao"

13. Resumo Final

Pontos essenciais:

Uma Subscription é a unidade de cobrança e o perímetro administrativo fundamental do Azure
Toda subscription está associada a exatamente um Azure AD Tenant, que provê autenticação
Subscriptions contêm Resource Groups, que contêm recursos; a hierarquia é Tenant > Management Group > Subscription > Resource Group > Resource
Service Limits (Quotas) são definidos por subscription e por região, independentemente entre subscriptions
Subscriptions podem ficar Disabled por falta de pagamento, com período de 90 dias antes da deleção permanente dos recursos
Resource Providers devem estar registrados em uma subscription antes de criar recursos do tipo correspondente

Diferenças críticas:

Tenant vs. Subscription: Tenant é a identidade (Azure AD); Subscription é cobrança e recursos. Um Tenant pode ter muitas subscriptions
Transfer de cobrança vs. Transfer de Tenant: mudar quem paga preserva RBAC; mudar o Tenant destrói todos os role assignments
Nova Subscription vs. Novo Resource Group: nova subscription = novas cotas, billing separado, isolamento real; novo RG = apenas organização lógica dentro da mesma subscription
Management Group vs. Subscription: MG é contêiner de governança; Subscription é unidade de cobrança e recursos

O que precisa ser lembrado para o AZ-104:

O estado Disabled preserva recursos por 90 dias antes da deleção permanente
Limites críticos: 980 RGs por subscription, 4.000 role assignments por subscription
Transferir subscription para outro Tenant destrói todos os role assignments
Resource Providers precisam estar registrados antes de criar recursos do tipo correspondente
Management Groups permitem aplicar RBAC e Policy em escala sobre múltiplas subscriptions com herança
Quotas de vCPUs são por subscription por região por família de VM, não globais
Em scripts e automação, sempre referenciar subscription pelo ID (GUID), não pelo nome
O Activity Log da subscription retém eventos por 90 dias por padrão; exportar para Log Analytics para retenção maior

1. Intuição Inicial​

2. Contexto​

Onde Subscriptions se encaixam na hierarquia Azure​

Por que Subscriptions existem como unidade separada​

O que depende de Subscriptions​

3. Construção dos Conceitos​

3.1 Tipos de Subscription​

3.2 Relacionamento Subscription e Azure AD Tenant​

3.3 Subscription ID e nome​

3.4 Estados de uma Subscription​

3.5 Service Limits e Quotas​

3.6 Management Groups​

3.7 Transferência de Subscription​

4. Visão Estrutural​

Como Subscriptions interagem com os demais conceitos de governança​

5. Funcionamento na Prática​

Ciclo de vida de uma Subscription​

Comportamentos não óbvios importantes​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Criação de Subscriptions via API (EA/MCA)​

7. Controle e Segurança​

Modelo de acesso a Subscriptions​

Resource Providers: o que são e por que importam​

Diagnóstico de custo e anomalias​

8. Tomada de Decisão​

Quantas subscriptions usar​

Quando criar nova Subscription vs. novo Resource Group​

Escolha do tipo de Subscription​

9. Boas Práticas​

10. Erros Comuns​

O erro mais custoso​

11. Operação e Manutenção​

Auditoria e inventário de Subscriptions​

Monitoramento de custo e anomalias​

Configurar export de Activity Log para retenção longa​

Limites da Subscription importantes para o dia a dia​

12. Integração e Automação​

Subscription Vending Machine​

Terraform para gestão de subscriptions em escala​

Integração com Microsoft Cost Management APIs​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde Subscriptions se encaixam na hierarquia Azure

Por que Subscriptions existem como unidade separada

O que depende de Subscriptions

3. Construção dos Conceitos

3.1 Tipos de Subscription

3.2 Relacionamento Subscription e Azure AD Tenant

3.3 Subscription ID e nome

3.4 Estados de uma Subscription

3.5 Service Limits e Quotas

3.6 Management Groups

3.7 Transferência de Subscription

4. Visão Estrutural

Como Subscriptions interagem com os demais conceitos de governança

5. Funcionamento na Prática

Ciclo de vida de uma Subscription

Comportamentos não óbvios importantes

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Criação de Subscriptions via API (EA/MCA)

7. Controle e Segurança

Modelo de acesso a Subscriptions

Resource Providers: o que são e por que importam

Diagnóstico de custo e anomalias

8. Tomada de Decisão

Quantas subscriptions usar

Quando criar nova Subscription vs. novo Resource Group

Escolha do tipo de Subscription

9. Boas Práticas

10. Erros Comuns

O erro mais custoso

11. Operação e Manutenção

Auditoria e inventário de Subscriptions

Monitoramento de custo e anomalias

Configurar export de Activity Log para retenção longa

Limites da Subscription importantes para o dia a dia

12. Integração e Automação

Subscription Vending Machine

Terraform para gestão de subscriptions em escala

Integração com Microsoft Cost Management APIs

13. Resumo Final