Azure: o mapa essencial

Quem vem da AWS estranha o Azure por causa da hierarquia: aqui existe uma camada a mais entre a organização e o recurso, e ela é a base de tudo — cobrança, limites, permissão e política penduram nessa árvore. Entenda a hierarquia primeiro; o resto é tradução de nomes.

Hierarquia: tenant, grupos de gerenciamento, assinaturas e resource groups

Tenant (Entra ID)                         ← a identidade da empresa
└── Grupo de gerenciamento "empresa"      ← onde as políticas ficam
    ├── Grupo "producao"
    │   └── Assinatura "loja-prod"        ← limite de cota e de cobrança
    │       ├── RG "loja-prod-rede"       ← ciclo de vida: apagar o RG apaga tudo dentro
    │       └── RG "loja-prod-app"
    └── Grupo "nao-producao"
        └── Assinatura "loja-dev"

• Assinatura é o equivalente mais próximo da conta AWS: limite de cota, fronteira de cobrança e de isolamento. Separe produção de não produção em assinaturas diferentes.
• Resource group agrupa recursos com o mesmo ciclo de vida. Não é pasta organizacional: az group delete remove tudo que está dentro.
• Grupos de gerenciamento carregam as Azure Policies que valem para tudo abaixo.

az account show                          # em qual assinatura você está — confira sempre
az account set --subscription "loja-prod"
az group create -n loja-prod-app -l brazilsouth

Computação

Serviço	Use quando
Azure Functions	Evento, tarefa curta, integração
Container Apps	Container sem operar Kubernetes; escala a zero; bom padrão
AKS	Precisa de Kubernetes e do ecossistema; você opera upgrades
App Service	Aplicação web tradicional, com deploy simples
VM / VMSS	Legado, licença, controle de sistema operacional

Container Apps é a resposta certa com mais frequência do que se imagina — AKS custa tempo de time, e a maioria dos serviços não usa o que só o Kubernetes oferece.

No AKS, três decisões que doem depois se erradas: modo de rede (Azure CNI consome IP da VNet por Pod — planeje a sub-rede), identidade (use Workload Identity, não a identidade do nó) e canal de upgrade (upgrade automático de patch é o padrão saudável).

Rede

VNet com sub-redes, NSG como firewall (com estado), Application Gateway para HTTP com WAF, Load Balancer para camada 4 e Front Door para CDN e entrada global. brazilsouth (São Paulo) é a região padrão para atender o Brasil, com brazilsoutheast como par para cenários de recuperação.

Private Link / Private Endpoint é ainda mais central aqui do que na AWS: por padrão, PaaS como Storage e SQL responde em endpoint público. Colocar endpoint privado e negar acesso público é o passo de segurança mais importante do ambiente Azure.

Identidade: Entra ID e managed identities

Entra ID (antigo Azure AD) é o diretório: pessoas, grupos, aplicações e MFA. Para recursos, use Managed Identity — a credencial é gerenciada pela plataforma e nunca aparece no seu código.

# a aplicação lê o segredo do Key Vault com identidade gerenciada, sem senha no código
az identity create -g loja-prod-app -n loja-identidade
az role assignment create --assignee <principal-id> \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/<sub>/resourceGroups/loja-prod-app/providers/Microsoft.KeyVault/vaults/loja-kv

Atribua papéis (RBAC) no menor escopo possível — recurso, depois RG, e só então assinatura. E prefira papéis embutidos; papel customizado só quando nenhum embutido servir, porque ele vira manutenção sua.

PIM (elevação temporária) para acesso administrativo é o equivalente do acesso just-in-time: ninguém fica com Owner permanente.

Governança: Azure Policy

É o guardrail mais forte da plataforma, e nativo: aplique no grupo de gerenciamento e vale para tudo abaixo. Comece pelas quatro que evitam mais problema:

• Regiões permitidas (brazilsouth e o par de DR).
• Exigir tag de centro de custo e de dono em todo recurso.
• Negar recurso de armazenamento com acesso público.
• Exigir criptografia e desabilitar autenticação por chave onde houver alternativa.

Rode em modo auditoria primeiro, meça o que já viola e só depois passe para Deny.

Monitor, Log Analytics e custo

Azure Monitor coleta métricas e logs; o destino é um workspace do Log Analytics, consultado em KQL. Alarmes, dashboards e Application Insights (APM) partem daí.

// erros por operação na última hora
AppRequests
| where TimeGenerated > ago(1h) and Success == false
| summarize contagem = count() by OperationName
| order by contagem desc

Como no CloudWatch, o custo é por ingestão e retenção: separe workspaces por ambiente, defina retenção por tabela e mande o histórico longo para armazenamento barato.

Para custo, ative Cost Management com orçamento e alerta, e use as tags obrigatórias que a política acima garante. Nas VMs, avalie reservations e savings plans para carga estável — o desconto é grande e a decisão é reversível dentro de certos limites.

Próximo passo: complete a comparação com GCP: o mapa essencial, ou organize os ambientes em Landing zone.