Fundamentação Teórica: Manage Resource Groups

1. Intuição Inicial

Pense em um escritório físico. Você não joga todos os documentos de todos os projetos em uma única sala. Você organiza: pastas separadas por projeto, gavetas por departamento, armários por tipo de documento. Quando um projeto termina, você pega a pasta inteira e descarta tudo de uma vez.

No Azure, um Resource Group (RG) é exatamente esse contêiner organizacional. É uma pasta lógica que agrupa recursos relacionados entre si, permitindo gerenciá-los, monitorá-los, controlá-los e deletá-los como uma unidade.

Todo recurso Azure, sem exceção, precisa pertencer a um Resource Group. Não existe VM, Storage Account, Key Vault ou qualquer outro recurso "solto" no Azure: todos têm um RG como contêiner obrigatório.

O valor prático é imediato: quando um projeto termina, você deleta o Resource Group e todos os recursos dentro dele somem simultaneamente, sem precisar lembrar e deletar cada um individualmente.

2. Contexto

Onde Resource Groups se encaixam na hierarquia Azure

100%

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

O Resource Group vive dentro de uma Subscription e contém recursos. Ele é o escopo mais usado para aplicar RBAC, Azure Policy, Resource Locks e tags, conforme visto nos módulos anteriores. Tudo que aprendemos sobre escopos tem o RG como caso de uso central.

Por que Resource Groups existem

Antes dos Resource Groups, o Azure tinha o modelo de deployment clássico onde recursos eram gerenciados individualmente sem agrupamento lógico. Era como tentar gerenciar uma empresa sem pastas, departamentos ou hierarquias. O Azure Resource Manager (ARM) e os Resource Groups foram introduzidos para resolver esse problema de organização e gerenciamento em escala.

O que depende de Resource Groups

Praticamente tudo no Azure opera em relação ao Resource Group como unidade:

Cobrança: custo agregado por RG visível no Cost Management
RBAC: escopo mais comum para atribuições de acesso
Azure Policy: escopo recomendado para a maioria das atribuições
Resource Locks: proteção por RG é a abordagem mais comum
Tags: RG tem suas próprias tags independentes dos recursos internos
ARM Templates: deployments são feitos em um RG alvo
Azure Monitor: alertas e logs podem ser filtrados por RG

3. Construção dos Conceitos

3.1 Propriedades fundamentais de um Resource Group

Um Resource Group tem as seguintes características técnicas:

Propriedade	Detalhes
Nome	Único dentro da subscription, 1-90 caracteres, alfanumérico + hifens + underscores + parênteses + ponto
Localização (região)	Define onde os metadados do RG são armazenados
Subscription	Todo RG pertence a exatamente uma subscription
Tags	Até 50 pares chave:valor, independentes dos recursos internos
ID	`/subscriptions/{subId}/resourceGroups/{rgName}`

3.2 A localização do Resource Group não limita os recursos dentro

Este é o ponto mais contraintuitivo sobre Resource Groups:

A localização do RG define apenas onde os metadados do próprio RG são armazenados. Os recursos dentro do RG podem estar em qualquer região do mundo, independente da região do RG.

Exemplo: um RG criado em brazilsouth pode conter uma VM em eastus, um storage em westeurope e um banco de dados em southeastasia. Tecnicamente válido, embora não seja uma boa prática para a maioria dos casos.

Por que isso importa? Porque ao criar o RG, você escolhe a região sem se preocupar que isso "força" recursos para aquela região. A região do RG é apenas um detalhe administrativo de onde os metadados vivem.

3.3 Recursos podem pertencer a apenas um Resource Group

Um recurso não pode estar em dois RGs simultaneamente. Ele tem exatamente um RG como "dono" durante toda sua existência. Porém, recursos em RGs diferentes podem interagir livremente: uma VM em rg-compute pode usar uma VNet em rg-networking sem nenhuma restrição técnica.

3.4 Deletar um Resource Group deleta tudo dentro

Quando você deleta um RG, o ARM deleta todos os recursos dentro dele de forma cascateada. Não há confirmação individual por recurso. Essa operação é irreversível para a maioria dos recursos, exceto aqueles com soft delete habilitado (como Key Vault e Storage com proteção).

Isso é uma faca de dois gumes: é extremamente conveniente para limpeza de ambientes temporários, e extremamente perigoso se feito acidentalmente em produção. É por isso que Resource Locks CanNotDelete em RGs de produção são tão importantes.

3.5 Mover recursos entre Resource Groups

Recursos podem ser movidos de um RG para outro, dentro da mesma subscription ou entre subscriptions diferentes. Porém, nem todos os tipos de recursos suportam movimentação.

100%

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

O que acontece durante um move:

O Resource ID do recurso muda (o path no ARM inclui o RG)
O recurso fica indisponível brevemente durante a operação (alguns serviços têm downtime, outros não)
Locks no RG de origem não se movem; precisam ser recriados no destino
Role assignments no RG de origem não acompanham o recurso
Tags do recurso individual são preservadas
A operação pode levar de segundos a horas dependendo do tipo e tamanho

Tipos de recursos que NÃO suportam move (exemplos comuns):

Azure Active Directory Domain Services
Alguns recursos de rede (VPN Gateway tem restrições)
Recursos em availability sets se o AS não for movido junto
Recursos com delete locks CanNotDelete podem exigir remoção do lock antes do move

Para verificar se um tipo suporta move antes de tentar:

az resource invoke-action \
  --action "moveResources" \
  --ids "/subscriptions/<sub-id>/resourceGroups/rg-origem" \
  --request-body '{"resources": ["<resource-id>"], "targetResourceGroup": "<target-rg-id>"}'

Ou verificar na documentação: https://learn.microsoft.com/azure/azure-resource-manager/management/move-support-resources

4. Visão Estrutural

Resource Groups como unidade de ciclo de vida

100%

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

Estratégias de organização de Resource Groups

Existem quatro estratégias principais, e a escolha depende do contexto:

100%

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

Na prática, a maioria das organizações usa uma combinação dessas estratégias. Um padrão comum é:

100%

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

Recursos compartilhados (rede, identidade, monitoramento) ficam em RGs próprios. Aplicações têm seus RGs separados por projeto.

5. Funcionamento na Prática

Ciclo de vida de um Resource Group

100%

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

Comportamentos não óbvios importantes

Deleção de RG é assíncrona e pode demorar. Deletar um RG com muitos recursos não é instantâneo. O ARM enfileira a deleção de cada recurso individualmente. Para um RG com 50 recursos, pode levar 10 a 30 minutos. Durante esse tempo, o RG aparece como "Deleting" no portal.

Recursos podem falhar ao ser deletados por dependências. Se recursos dentro do RG têm dependências circulares ou se outro recurso fora do RG faz referência a um recurso dentro (ex: uma VM em outro RG usando uma NIC do RG que está sendo deletado), a deleção pode falhar parcialmente. O ARM tentará deletar na ordem correta baseado em dependências conhecidas, mas nem sempre consegue.

Um RG vazio ainda ocupa espaço no ARM e pode ter custos de metadata. Após remover todos os recursos de um RG, o próprio RG permanece e deve ser deletado separadamente se não for mais necessário. Muitos RGs vazios proliferam em organizações sem processo de limpeza.

Tags e locks no RG não se propagam automaticamente aos recursos. Conforme visto nos módulos anteriores, um lock no RG impede a deleção do RG e herda proteção para os recursos dentro (você não pode deletar o RG, portanto não pode deletar seus recursos via remoção do RG). Mas tags são independentes.

Mover recurso muda seu Resource ID. O Resource ID de qualquer recurso inclui o path do RG: /subscriptions/{sub}/resourceGroups/{rg}/providers/{provider}/{type}/{name}. Se o recurso se move para outro RG, seu ID muda. Qualquer referência codificada ao ID antigo (em scripts, alertas, RBAC, etc.) quebra.

6. Formas de Implementação

Portal do Azure

Quando usar: criação inicial, exploração, operações únicas, verificação visual

Criar um Resource Group:

Portal > Resource groups > + Create
Selecionar Subscription
Definir nome (seguindo naming convention)
Selecionar região
Adicionar tags
Review + Create

Deletar um Resource Group:

Portal > Resource groups > selecionar o RG
Delete resource group
Digitar o nome do RG para confirmar (proteção contra deleção acidental)
Clicar em Delete

Mover recursos:

Navegar até o recurso a ser movido
Clicar em Move > Move to another resource group ou Move to another subscription
Selecionar o destino
Confirmar que entende as implicações (IDs mudam, referências podem quebrar)

Limitação: não reproduzível, sem controle de versão, lento para múltiplos RGs.

Azure CLI

# Criar Resource Group
az group create \
  --name "rg-ecommerce-prod" \
  --location "brazilsouth" \
  --tags Environment=Production Project=ecommerce Owner=time-backend

# Listar Resource Groups
az group list --output table

# Listar RGs com filtro por tag
az group list \
  --query "[?tags.Environment=='Production']" \
  --output table

# Ver detalhes de um RG específico
az group show --name "rg-ecommerce-prod"

# Atualizar tags de um RG (substitui todas as tags)
az group update \
  --name "rg-ecommerce-prod" \
  --tags Environment=Production Project=ecommerce Owner=time-backend CostCenter=CC-2045

# Deletar Resource Group (assíncrono, não aguarda conclusão por padrão)
az group delete --name "rg-ecommerce-prod" --yes

# Deletar e aguardar conclusão
az group delete --name "rg-ecommerce-prod" --yes --no-wait false

# Verificar se um RG existe
az group exists --name "rg-ecommerce-prod"

# Mover recurso para outro Resource Group (mesma subscription)
az resource move \
  --destination-group "rg-ecommerce-prod-v2" \
  --ids "/subscriptions/<sub-id>/resourceGroups/rg-ecommerce-prod/providers/Microsoft.Compute/virtualMachines/vm-web-01"

# Mover múltiplos recursos de uma vez
az resource move \
  --destination-group "rg-destino" \
  --ids \
    "/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-01" \
    "/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Network/networkInterfaces/nic-vm-01"

# Mover recurso para outra subscription
az resource move \
  --destination-group "rg-destino" \
  --destination-subscription-id "<sub-id-destino>" \
  --ids "<resource-id>"

# Listar recursos dentro de um RG
az resource list \
  --resource-group "rg-ecommerce-prod" \
  --output table

# Verificar se tipo de recurso suporta move
az provider show \
  --namespace "Microsoft.Compute" \
  --query "resourceTypes[?resourceType=='virtualMachines'].capabilities" \
  --output json

# Exportar template ARM do RG (para backup ou replicação)
az group export \
  --name "rg-ecommerce-prod" \
  --output-folder "./exports/"

Azure PowerShell

# Criar Resource Group
New-AzResourceGroup `
  -Name "rg-ecommerce-prod" `
  -Location "brazilsouth" `
  -Tag @{
    Environment = "Production"
    Project     = "ecommerce"
    Owner       = "time-backend"
    CostCenter  = "CC-2045"
  }

# Listar Resource Groups
Get-AzResourceGroup | Select-Object ResourceGroupName, Location, ProvisioningState

# Listar RGs com filtro
Get-AzResourceGroup -Tag @{Environment = "Production"}

# Verificar se RG existe
Get-AzResourceGroup -Name "rg-ecommerce-prod" -ErrorAction SilentlyContinue

# Deletar Resource Group (aguarda conclusão)
Remove-AzResourceGroup -Name "rg-ecommerce-prod" -Force

# Deletar de forma assíncrona
Remove-AzResourceGroup -Name "rg-ecommerce-prod" -Force -AsJob

# Mover recursos para outro RG
Move-AzResource `
  -DestinationResourceGroupName "rg-ecommerce-prod-v2" `
  -ResourceId "/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-01"

# Mover para outra subscription
Move-AzResource `
  -DestinationResourceGroupName "rg-destino" `
  -DestinationSubscriptionId "<sub-id-destino>" `
  -ResourceId "<resource-id>"

# Listar recursos em um RG
Get-AzResource -ResourceGroupName "rg-ecommerce-prod" |
  Select-Object Name, ResourceType, Location

# Exportar template ARM do RG
Export-AzResourceGroup `
  -ResourceGroupName "rg-ecommerce-prod" `
  -Path "./exports/rg-ecommerce-prod-template.json"

# Criar RG a partir de um template existente
New-AzResourceGroupDeployment `
  -ResourceGroupName "rg-destino" `
  -TemplateFile "./exports/rg-ecommerce-prod-template.json"

Bicep e ARM Templates

Em IaC, Resource Groups são criados com targetScope = 'subscription' porque RGs pertencem a subscriptions, não a outros RGs:

// arquivo: create-rgs.bicep
targetScope = 'subscription'

param location string = 'brazilsouth'
param environment string = 'prod'

// Resource Group da aplicação principal
resource rgApp 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-ecommerce-${environment}'
  location: location
  tags: {
    Environment: environment
    Project: 'ecommerce'
    Owner: 'time-backend'
    CostCenter: 'CC-2045'
    ManagedBy: 'bicep'
  }
}

// Resource Group de rede compartilhada
resource rgNetwork 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-networking-${environment}'
  location: location
  tags: {
    Environment: environment
    Project: 'shared-infrastructure'
    Owner: 'time-cloud'
    ManagedBy: 'bicep'
  }
}

// Usar módulo para criar recursos DENTRO do RG
module appResources './app-resources.bicep' = {
  name: 'deploy-app-resources'
  scope: rgApp  // escopo é o RG criado acima
  params: {
    location: location
    environment: environment
  }
}

Para deploy de um template que cria RGs:

az deployment sub create \
  --location "brazilsouth" \
  --template-file "create-rgs.bicep" \
  --parameters environment=prod

Note que o deployment é no nível de subscription (az deployment sub create), não no nível de RG, porque estamos criando RGs.

Terraform

# Variáveis comuns
locals {
  environment = "prod"
  location    = "brazilsouth"
  
  common_tags = {
    Environment = "Production"
    ManagedBy   = "terraform"
    Owner       = "time-cloud"
  }
}

# Resource Group da aplicação
resource "azurerm_resource_group" "app" {
  name     = "rg-ecommerce-${local.environment}"
  location = local.location
  tags     = merge(local.common_tags, {
    Project    = "ecommerce"
    CostCenter = "CC-2045"
  })
}

# Resource Group de rede
resource "azurerm_resource_group" "network" {
  name     = "rg-networking-${local.environment}"
  location = local.location
  tags     = merge(local.common_tags, {
    Project = "shared-infrastructure"
  })
}

# Resource Group de monitoramento
resource "azurerm_resource_group" "monitoring" {
  name     = "rg-monitoring"
  location = local.location
  tags     = merge(local.common_tags, {
    Project = "shared-infrastructure"
  })
}

# Recursos criados dentro dos RGs referenciando os RGs acima
resource "azurerm_virtual_network" "main" {
  name                = "vnet-main"
  resource_group_name = azurerm_resource_group.network.name  # referencia o RG de rede
  location            = azurerm_resource_group.network.location
  address_space       = ["10.0.0.0/16"]
  tags                = local.common_tags
}

7. Controle e Segurança

RBAC em Resource Groups

O Resource Group é o escopo de RBAC mais comum para equipes de trabalho. A abordagem padrão é:

100%

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

Resource Locks em Resource Groups de produção

Todo RG de produção deve ter, no mínimo, um lock CanNotDelete. Isso previne deleções acidentais de todo o ambiente com um único comando.

# Aplicar lock obrigatório em RG de produção
az lock create \
  --name "rg-prod-nodelete" \
  --resource-group "rg-ecommerce-prod" \
  --lock-type CanNotDelete \
  --notes "Producao - Remover apenas com aprovacao via ticket de change"

Azure Policy no escopo de Resource Group

Policies podem ser atribuídas diretamente ao RG para regras específicas daquele ambiente. Por exemplo, uma policy de região permitida na Subscription mas com exceção de RGs de laboratório específicos.

8. Tomada de Decisão

Estratégia de organização de Resource Groups

Situação	Estratégia de RG	Motivo
Startup pequena, poucos projetos	Por ambiente (dev, prod)	Simplicidade operacional
Empresa média com múltiplos projetos	Por aplicação + ambiente	Isolamento por projeto, controle de custo por app
Grande empresa com times distintos	Por aplicação + ambiente + RG de infra compartilhada	Times independentes, infraestrutura centralizada
Projeto temporário (POC, hackathon)	Um único RG para tudo	Fácil deleção ao final do projeto
Infraestrutura compartilhada (VNet, DNS)	RG dedicado separado	Ciclo de vida diferente das aplicações

Quando mover recursos vs. recriar

Situação	Decisão	Motivo
Recurso recém-criado em RG errado	Mover	Sem dados, sem impacto significativo
VM de produção em RG errado, com dados críticos	Avaliar downtime do move	Move pode ter downtime breve
Recurso que não suporta move	Recriar	Não há alternativa técnica
Move cross-subscription com muitas dependências	Recriar com blue/green	Menos risco de referências quebradas
Resource Group inteiro para outra subscription	Mover recurso a recurso ou recriar via IaC	Não existe "mover RG inteiro" nativamente

Importante: não existe operação nativa de mover um Resource Group inteiro. Você move os recursos individuais dentro dele. Se precisa "mover" um RG para outra subscription, a abordagem mais segura é exportar o ARM template do RG, criar o RG na subscription destino, e fazer o deployment do template.

Região do Resource Group

Cenário	Região do RG	Motivo
RG de produção com recursos no Brasil	brazilsouth	Metadados próximos dos recursos para latência mínima de gerenciamento
RG de disaster recovery	região secundária (eastus2)	Metadados sobrevivem a falha da região primária
RG de recursos globais (CDN, Traffic Manager)	eastus ou westeurope	Convencional para recursos globais

9. Boas Práticas

Defina uma naming convention e siga rigorosamente. Resource Groups são o ponto de entrada visual do seu ambiente Azure. Nomes como rg-ecommerce-prod, rg-erp-dev, rg-networking-shared comunicam imediatamente o propósito. Nomes como ResourceGroup1 ou Test criam caos operacional.

Um Resource Group por ambiente por aplicação. Misturar recursos de dev e produção no mesmo RG é arriscado (deleção acidental de prod junto com dev) e complica relatórios de custo. A separação por ambiente em RGs distintos é a prática padrão.

Recursos com o mesmo ciclo de vida ficam no mesmo RG. A regra de ouro do Resource Group: se os recursos são criados juntos, gerenciados juntos e deletados juntos, eles pertencem ao mesmo RG. Infraestrutura compartilhada que sobrevive a projetos individuais fica em RGs próprios.

Sempre aplique tags ao criar o RG, antes de criar recursos dentro. Tags aplicadas no RG servem de referência e podem ser herdadas por Policy. Se você cria o RG sem tags e depois quer aplicar, vai precisar fazer remediation em todos os recursos dentro.

Nunca deixe RGs de produção sem locks. Um az group delete --name rg-producao --yes destrói meses de trabalho em segundos. Lock CanNotDelete é a proteção mínima obrigatória.

Documente a estratégia de RGs como código. Use Bicep ou Terraform para criar e gerenciar RGs. Assim, a criação de novos ambientes segue sempre o mesmo padrão, com as mesmas tags, locks e configurações.

Crie um RG dedicado para monitoramento e operações. Log Analytics Workspace, Application Insights, alertas e dashboards devem estar em um RG separado dos recursos que monitoram. Isso evita que a deleção de um RG de aplicação destrua os dados históricos de monitoramento.

Limite o número de Resource Groups por subscription. Embora o limite técnico seja 980 RGs por subscription, organizações com centenas de RGs se tornam difíceis de gerenciar. Se você está chegando a dezenas de RGs, provavelmente é hora de avaliar a separação em múltiplas subscriptions.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Colocar recursos de ambientes diferentes no mesmo RG	Praticidade inicial sem visão de longo prazo	Definir convenção de RGs antes de começar
Deletar RG de produção acidentalmente	Sem lock, comando CLI errado	Resource Lock CanNotDelete obrigatório em prod
Assumir que região do RG limita recursos internos	Confusão conceitual comum	Lembrar: região do RG é só dos metadados do RG
Não aplicar tags ao criar o RG	Pressa, considerado detalhe menor	Incluir tags na definição IaC do RG
Mover recurso sem verificar suporte	Tentar economizar tempo	Verificar documentação de move support antes
Acreditar que mover recurso preserva IDs	Desconhecimento técnico	O Resource ID muda; atualizar todas as referências
RGs vazios proliferando após projetos encerrados	Sem processo de limpeza	Processo de offboarding que deleta RGs vazios
Criar um único RG para todos os recursos de uma subscription	Simplicidade inicial excessiva	Impossibilita controle de acesso granular e chargeback
Recursos de ciclo de vida diferente no mesmo RG	Organização por tipo técnico em vez de por ciclo de vida	Agrupar por quando os recursos vivem e morrem juntos

O erro mais catastrófico

Executar az group delete sem lock em um RG de produção é um dos acidentes mais comuns e devastadores em ambientes Azure. A confirmação que o CLI pede (--yes) é facilmente passada em scripts automatizados. A única proteção real é o Resource Lock.

11. Operação e Manutenção

Inventário e auditoria de Resource Groups

# Listar todos os RGs com tags, localização e estado
az group list \
  --query "[].{Name:name, Location:location, State:properties.provisioningState, Tags:tags}" \
  --output table

# Identificar RGs sem tags obrigatórias (via Resource Graph)
az graph query -q "
ResourceContainers
| where type == 'microsoft.resources/subscriptions/resourcegroups'
| where isnull(tags['Environment']) or isnull(tags['CostCenter'])
| project name, location, tags, subscriptionId"

# Identificar RGs vazios (sem recursos)
az graph query -q "
ResourceContainers
| where type == 'microsoft.resources/subscriptions/resourcegroups'
| join kind=leftouter (
    Resources
    | summarize resourceCount = count() by resourceGroup
  ) on \$left.name == \$right.resourceGroup
| where isnull(resourceCount) or resourceCount == 0
| project name, location, subscriptionId"

# Verificar locks em todos os RGs de produção
az lock list \
  --query "[?contains(id, 'prod')]" \
  --output table

# Contar recursos por tipo em um RG
az resource list \
  --resource-group "rg-ecommerce-prod" \
  --query "[].type" \
  --output tsv | sort | uniq -c | sort -rn

Monitorar mudanças em Resource Groups

# Verificar operações recentes em um RG (Activity Log)
az monitor activity-log list \
  --resource-group "rg-ecommerce-prod" \
  --max-events 50 \
  --output table

# Alertar sobre criação ou deleção de RGs
az monitor activity-log alert create \
  --name "Alerta-RG-Criado-Deletado" \
  --resource-group "rg-monitoramento" \
  --condition \
    category=Administrative \
    operationName=Microsoft.Resources/subscriptions/resourceGroups/write \
  --scope "/subscriptions/<sub-id>"

Limites técnicos de Resource Groups

Limite	Valor
RGs por subscription	980
Recursos por Resource Group	Sem limite documentado, mas prático ~800 por tipo
Tags por Resource Group	50
Comprimento do nome	1 a 90 caracteres
Deployments simultâneos por RG	800 (histórico de deployments; mais antigos são deletados automaticamente)

O limite de 800 deployments por RG é importante em cenários de CI/CD com muitos deployments. O ARM mantém o histórico de até 800 deployments por RG; quando atingido, começa a deletar os mais antigos. Em pipelines muito ativos, isso pode ser um problema de rastreabilidade se o histórico de deployments for necessário.

12. Integração e Automação

Automação de criação de ambientes via pipeline

100%

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

Processo de offboarding de projetos

100%

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

Replicação de ambientes via template export

Um padrão útil para criar ambientes idênticos (ex: replicar prod para staging):

# Exportar configuração atual do RG de produção
az group export \
  --name "rg-ecommerce-prod" \
  --skip-resource-name-params \
  --output-folder "./templates/"

# Parametrizar o template exportado para o ambiente staging
# (editar manualmente ou via script para trocar nomes de recursos)

# Criar RG de staging
az group create \
  --name "rg-ecommerce-staging" \
  --location "brazilsouth" \
  --tags Environment=Staging Project=ecommerce

# Fazer deploy do template no RG de staging
az deployment group create \
  --resource-group "rg-ecommerce-staging" \
  --template-file "./templates/template.json" \
  --parameters environment=staging

Integração com Azure Cost Management

Resource Groups aparecem como dimensão nativa no Cost Management. Sem precisar de tags ou configuração extra, você consegue ver:

Custo por Resource Group no período
Tendência de custo por RG ao longo do tempo
Alertas de orçamento por RG

# Criar alerta de orçamento para um RG específico
az consumption budget create \
  --budget-name "budget-ecommerce-prod" \
  --amount 5000 \
  --time-grain Monthly \
  --resource-group "rg-ecommerce-prod" \
  --notifications '{"actual_GreaterThan_80_Percent": {"enabled": true, "operator": "GreaterThan", "threshold": 80, "contactEmails": ["cloud-team@empresa.com"]}}'

13. Resumo Final

Pontos essenciais:

Todo recurso Azure deve pertencer a exatamente um Resource Group; não existem recursos sem RG
A região do RG define onde os metadados do RG são armazenados, não onde os recursos dentro podem ser criados
Deletar um RG deleta todos os recursos dentro de forma cascateada e irreversível (exceto recursos com soft delete)
RGs são o escopo mais comum para RBAC, Policy, Locks e tags no dia a dia operacional
Tags do RG não propagam automaticamente para recursos dentro dele
Recursos podem ser movidos entre RGs ou subscriptions, mas o Resource ID muda no processo

Diferenças críticas:

RG vs. Subscription: Subscription é unidade de cobrança e limite administrativo; RG é contêiner lógico dentro da subscription
Região do RG vs. Região dos recursos: A região do RG é independente da região de seus recursos
Mover recurso vs. recriar: Mover preserva dados mas muda o Resource ID e pode ter downtime; recriar é mais seguro mas perde o estado
Lock no RG vs. Lock no recurso: Lock no RG protege o RG e herda proteção contra deleção do RG inteiro; não impede deleção de recursos individuais dentro do RG via delete direto no recurso

O que precisa ser lembrado para o AZ-104:

O limite de RGs por subscription é 980
O limite de histórico de deployments por RG é 800
A operação de mover recurso muda o Resource ID
Não existe operação de mover um RG inteiro; recursos são movidos individualmente
Ao fazer deploy de templates que criam RGs, o deployment deve ser no nível de subscription (az deployment sub create), não no nível de RG
Resource Group não é uma unidade de isolamento de rede; recursos em RGs diferentes podem se comunicar livremente
A exportação de ARM template de um RG via portal ou CLI é uma forma prática de backup e replicação de ambientes

1. Intuição Inicial​

2. Contexto​

Onde Resource Groups se encaixam na hierarquia Azure​

Por que Resource Groups existem​

O que depende de Resource Groups​

3. Construção dos Conceitos​

3.1 Propriedades fundamentais de um Resource Group​

3.2 A localização do Resource Group não limita os recursos dentro​

3.3 Recursos podem pertencer a apenas um Resource Group​

3.4 Deletar um Resource Group deleta tudo dentro​

3.5 Mover recursos entre Resource Groups​

4. Visão Estrutural​

Resource Groups como unidade de ciclo de vida​

Estratégias de organização de Resource Groups​

5. Funcionamento na Prática​

Ciclo de vida de um Resource Group​

Comportamentos não óbvios importantes​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep e ARM Templates​

Terraform​

7. Controle e Segurança​

RBAC em Resource Groups​

Resource Locks em Resource Groups de produção​

Azure Policy no escopo de Resource Group​

8. Tomada de Decisão​

Estratégia de organização de Resource Groups​

Quando mover recursos vs. recriar​

Região do Resource Group​

9. Boas Práticas​

10. Erros Comuns​

O erro mais catastrófico​

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

Inventário e auditoria de Resource Groups​

Monitorar mudanças em Resource Groups​

Limites técnicos de Resource Groups​

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

Automação de criação de ambientes via pipeline​

Processo de offboarding de projetos​

Replicação de ambientes via template export​

Integração com Azure Cost Management​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde Resource Groups se encaixam na hierarquia Azure

Por que Resource Groups existem

O que depende de Resource Groups

3. Construção dos Conceitos

3.1 Propriedades fundamentais de um Resource Group

3.2 A localização do Resource Group não limita os recursos dentro

3.3 Recursos podem pertencer a apenas um Resource Group

3.4 Deletar um Resource Group deleta tudo dentro

3.5 Mover recursos entre Resource Groups

4. Visão Estrutural

Resource Groups como unidade de ciclo de vida

Estratégias de organização de Resource Groups

5. Funcionamento na Prática

Ciclo de vida de um Resource Group

Comportamentos não óbvios importantes

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep e ARM Templates

Terraform

7. Controle e Segurança

RBAC em Resource Groups

Resource Locks em Resource Groups de produção

Azure Policy no escopo de Resource Group

8. Tomada de Decisão

Estratégia de organização de Resource Groups

Quando mover recursos vs. recriar

Região do Resource Group

9. Boas Práticas

10. Erros Comuns

O erro mais catastrófico

11. Operação e Manutenção

Inventário e auditoria de Resource Groups

Monitorar mudanças em Resource Groups

Limites técnicos de Resource Groups

12. Integração e Automação

Automação de criação de ambientes via pipeline

Processo de offboarding de projetos

Replicação de ambientes via template export

Integração com Azure Cost Management

13. Resumo Final