Fundamentos do Azure: hierarquia de recursos, Entra ID, computação, armazenamento e rede

A maioria dos engenheiros chega ao Azure depois de conhecer outra nuvem, e o atrito raramente é conceitual. Regiões, máquinas virtuais, armazenamento de objetos e bancos de dados gerenciados funcionam como você espera. O que atrasa é que o Azure tem um nível extra de agrupamento que outros provedores não têm, um serviço de diretório com modelo de permissões próprio ao lado do modelo de permissões dos recursos, e uma convenção de nomes em que a mesma palavra significa coisas diferentes conforme o contexto. A proposta deste guia é resolver tudo isso de uma sentada.

Partimos do princípio de que você sabe o que são uma região, uma zona de disponibilidade e o modelo de responsabilidade compartilhada; se não, comece pelos fundamentos de cloud. Tudo a seguir usa os nomes atuais dos serviços; quando um serviço foi renomeado recentemente, o nome antigo aparece uma vez para que a documentação mais antiga continue fazendo sentido.

A hierarquia de recursos

O Azure organiza tudo em quatro níveis aninhados, e saber a que nível cada configuração pertence poupa muita busca.

Microsoft Entra tenant           fronteira de identidade — usuários, grupos, registros de aplicativos
└── Management group             políticas e acesso herdados por tudo que está abaixo
    └── Management group (…)     até seis níveis de profundidade
        └── Subscription         fronteira de cobrança + fronteira de cotas
            └── Resource group   fronteira de ciclo de vida — implantado e excluído junto
                └── Resource     uma VM, uma conta de armazenamento, um banco de dados

Um tenant é o diretório. Uma organização normalmente tem um, e é nele que ficam as identidades; não é nele que ficam os recursos.

Uma assinatura (subscription) é o contêiner de cobrança e o contêiner de cotas. Todo recurso pertence a exatamente uma. As organizações dividem as assinaturas conforme o que querem cobrar, isolar ou limitar separadamente: produção versus não produção, uma por unidade de negócio, uma por plataforma principal. As cotas (quantos núcleos de uma família de VM você pode executar em uma região) valem por assinatura, e esse é o motivo prático para não rodar tudo em uma só.

Um grupo de gerenciamento (management group) fica acima das assinaturas e existe para que a governança não precise ser repetida. As atribuições de Azure Policy e de funções aplicadas a um grupo de gerenciamento são herdadas por todas as assinaturas abaixo dele. Um layout típico tem um grupo raiz, depois grupos para a plataforma e para as landing zones, e abaixo deles produção e não produção.

Um grupo de recursos (resource group) é uma pasta com poder de fogo. Os recursos dentro dele podem ser implantados juntos, marcados juntos, receber acesso juntos e, o mais importante, excluídos juntos. Agrupe por ciclo de vida, não por tipo de recurso: tudo que é criado e destruído como uma unidade vai no mesmo grupo.

Identidade: Microsoft Entra ID e atribuições de função

O acesso no Azure tem duas metades que os iniciantes costumam confundir.

O Microsoft Entra ID (antigo Azure Active Directory) autentica. Ele guarda usuários, grupos, entidades de serviço e registros de aplicativos, e emite tokens. As funções do Entra ID (Global Administrator, User Administrator, Application Administrator) governam o próprio diretório: quem pode criar usuários, dar consentimento a aplicativos ou redefinir senhas.

O Azure RBAC autoriza ações sobre os recursos. Uma atribuição de função liga três coisas: uma entidade de segurança (usuário, grupo, entidade de serviço ou identidade gerenciada), uma definição de função (um conjunto de operações permitidas, como Contributor, Reader ou Storage Blob Data Reader) e um escopo (grupo de gerenciamento, assinatura, grupo de recursos ou um único recurso). As permissões são herdadas para baixo, então uma atribuição Reader no escopo de uma assinatura torna a entidade leitora de tudo que há nela.

Ser Global Administrator no Entra ID não dá, por padrão, nenhuma permissão sobre os recursos, uma separação que pega muita gente de surpresa no primeiro incidente. E, no sentido inverso, um Owner de uma assinatura não consegue criar usuários.

A identidade gerenciada é o recurso que você deve usar o tempo todo. Ela dá a um recurso do Azure uma identidade no diretório gerenciada pela plataforma: sem segredo de cliente, sem certificado, sem rotação. Um aplicativo web com identidade gerenciada consegue ler um segredo do Key Vault ou gravar em uma conta de armazenamento sem nada na configuração além do nome de um recurso.

# Conceder à identidade gerenciada de um aplicativo web acesso de leitura a uma conta de armazenamento
appId=$(az webapp identity assign -g rg-orders-prod -n app-orders --query principalId -o tsv)
scope=$(az storage account show -g rg-orders-prod -n storders --query id -o tsv)

az role assignment create \
  --assignee-object-id "$appId" --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" --scope "$scope"

Para qualquer acesso privilegiado, adicione o Privileged Identity Management, para que as funções sejam ativadas por algumas horas mediante justificativa em vez de ficarem atribuídas permanentemente, e exija autenticação multifator por meio do Acesso Condicional. Os princípios de design mais amplos estão em gestão de identidades e acessos.

Computação: quatro opções e como escolher

O Azure tem muitos serviços de computação; na prática, a maioria das decisões se resume a quatro.

As Virtual Machines vêm em famílias nomeadas pela finalidade: B para burstable, D para uso geral, E otimizada para memória, F otimizada para computação, L para cargas intensivas em armazenamento. Os conjuntos de dimensionamento (scale sets) agrupam VMs idênticas atrás de regras de autoscale e são a forma de rodar uma camada baseada em VMs em produção.

O App Service é o caminho mais rápido para produção para uma aplicação web típica. Ele roda sobre um App Service Plan, que é a unidade que você de fato paga e o motivo de muitos sustos na fatura: o plano é cobrado com ou sem tráfego nos aplicativos, e vários aplicativos podem compartilhar o mesmo plano. Os slots de implantação permitem publicar em um slot de staging, aquecê-lo e trocá-lo com a produção, o que dá releases sem downtime e sem nenhum trabalho de infraestrutura.

O Azure Kubernetes Service oferece um control plane gerenciado sem custo; você paga pelos nós. É a resposta certa quando você já roda Kubernetes ou quando a quantidade de serviços justifica um scheduler, e a errada para três microsserviços sem time de plataforma. Leia os fundamentos de Kubernetes antes de se comprometer.

O Azure Functions cobra por execução no plano Consumption e escala até zero, ao custo de cold starts. O plano Premium mantém instâncias aquecidas e oferece integração com rede virtual; o plano dedicado roda as funções em um App Service Plan que você já paga.

Contas de armazenamento, camadas e discos

Uma conta de armazenamento é um namespace com até quatro serviços: Blob (objetos), Files (compartilhamentos SMB/NFS), Queue (mensagens simples) e Table (linhas chave-valor). Quase todo trabalho novo usa o Blob Storage, de preferência com o namespace hierárquico habilitado se ele for lido por ferramentas de analytics.

Duas configurações dominam a fatura e o comportamento.

Redundância. O LRS mantém três cópias dentro de um único datacenter. O ZRS espalha as cópias pelas zonas de disponibilidade da região e é o padrão sensato para qualquer coisa em produção. GRS e GZRS replicam de forma assíncrona para uma região secundária emparelhada; as variantes com acesso de leitura (RA-GRS, RA-GZRS) permitem ler a cópia secundária durante uma queda regional.

Camada de acesso. A camada Hot custa mais por gigabyte-mês e menos por leitura; Cool, Cold e Archive invertem essa proporção progressivamente, sendo que o Archive exige uma reidratação explícita que leva horas. Configure uma política de gerenciamento de ciclo de vida em vez de mover blobs à mão.

{
  "rules": [{
    "name": "invoices-lifecycle",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["invoices/"] },
      "actions": { "baseBlob": {
        "tierToCool": { "daysAfterModificationGreaterThan": 30 },
        "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
        "delete": { "daysAfterModificationGreaterThan": 2555 }
      }}
    }
  }]
}

Os discos gerenciados são separados das contas de armazenamento e servem às máquinas virtuais. As camadas vão do Standard HDD, passando por Standard SSD e Premium SSD, até o Ultra Disk, no qual você provisiona IOPS e throughput independentemente da capacidade. O Premium SSD v2 costuma ter o melhor custo-benefício para bancos de dados em VMs.

Bancos de dados

O Azure SQL Database é o padrão relacional gerenciado: backups automáticos com restauração point-in-time, patches automáticos e, à escolha, um modelo de compra baseado em DTU (uma abstração empacotada) ou o modelo vCore (núcleos e memória explícitos, e o único compatível com o Azure Hybrid Benefit para licenças existentes). A camada serverless pausa automaticamente um banco ocioso, o que é excelente para ambientes de desenvolvimento. O Azure Database for PostgreSQL e o for MySQL oferecem o mesmo tratamento gerenciado para engines open source.

O Azure Cosmos DB é o serviço NoSQL distribuído globalmente. Seus diferenciais são gravações multirregião prontas para uso e cinco níveis de consistência explícitos entre forte e eventual, que permitem equilibrar de forma deliberada latência e defasagem dos dados. A capacidade é provisionada em unidades de solicitação por segundo, fixas ou com autoscale, ou cobrada por solicitação no modo serverless. O Cosmos DB recompensa um modelo de dados desenhado em torno de padrões de acesso conhecidos e pune consultas entre partições; escolha-o para esse perfil de carga, não como substituto de uso geral do SQL.

O Azure Cache for Redis cobre cache e estado de sessão, e o Azure Service Bus cobre mensageria durável com filas e tópicos quando você precisa de ordenação, sessões ou transações em vez da simples Storage Queue.

Rede

Uma rede virtual (VNet) é um espaço de endereçamento privado em uma região, dividido em sub-redes. Duas VNets podem ser conectadas por peering, que não é transitivo: conectar A a B e B a C não conecta A a C, e isso pega de surpresa quem monta uma topologia hub-and-spoke esperando que o hub roteie automaticamente. Em hub-and-spoke, você coloca um firewall ou um appliance virtual de rede no hub e adiciona rotas definidas pelo usuário para forçar o tráfego a passar por ele.

Um grupo de segurança de rede (NSG) é uma lista stateful de regras de permissão e negação avaliadas por prioridade, que pode ser associada a uma sub-rede ou a uma interface de rede. As regras podem referenciar marcas de serviço como Storage ou AzureMonitor em vez de faixas de IP, e os grupos de segurança de aplicativo permitem escrever regras sobre grupos lógicos de VMs em vez de endereços.

Os endpoints privados (private endpoints) são o padrão importante para os serviços de plataforma. Por padrão, uma conta de armazenamento ou um banco Azure SQL tem um endpoint público protegido por chaves e regras de firewall; um endpoint privado dá a ele um IP privado dentro da sua VNet, de modo que o tráfego nunca passa pela internet. Combine-o com uma zona DNS privada para que o nome de host usual resolva para esse endereço privado.

A conexão com o ambiente on-premises é feita com um VPN Gateway pela internet ou com o ExpressRoute por um circuito privado, e o tráfego é distribuído com o Load Balancer (camada 4), o Application Gateway (camada 7, com web application firewall) ou o Front Door (global, com cache na borda).

Infraestrutura como código com Bicep

Os templates ARM são o formato de implantação JSON subjacente; o Bicep é uma linguagem legível que compila para eles, e é o que você deve escrever. Ele não tem arquivo de estado (o grafo de recursos no Azure é o estado) e as implantações são declarativas e idempotentes.

param location string = resourceGroup().location
param appName string

resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: '${appName}-plan'
  location: location
  sku: { name: 'P1v3', tier: 'PremiumV3' }
}

resource site 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  identity: { type: 'SystemAssigned' }
  properties: {
    serverFarmId: plan.id
    httpsOnly: true
    siteConfig: {
      linuxFxVersion: 'JAVA|21-java21'
      minTlsVersion: '1.2'
      ftpsState: 'Disabled'
    }
  }
}

output principalId string = site.identity.principalId

az deployment group create \
  --resource-group rg-orders-prod \
  --template-file main.bicep \
  --parameters appName=app-orders \
  --what-if      # visualizar as mudanças antes de aplicá-las

O Terraform é igualmente viável no Azure e é a melhor escolha se você também gerencia outros provedores; o raciocínio está em infraestrutura como código.

Vocabulário da AWS para o Azure

O mapeamento é aproximado (os equivalentes diferem em capacidade, não só no nome), mas encurta a tradução.

Onde os iniciantes erram

Colocar tudo em uma única assinatura. Cotas, escopo de políticas e atribuição de custos funcionam no nível da assinatura. Separar produção de não produção logo no início não custa nada e evita uma migração depois.

Achar que Global Administrator dá acesso aos recursos. Não dá, e isso é proposital. Eleve o acesso de forma explícita e temporária quando realmente precisar.

Pagar App Service Plans que ninguém usa. O plano é cobrado continuamente. Planos de desenvolvimento deixados ligados são, de longe, a causa mais comum de uma fatura do Azure sem explicação.

Esquecer que o peering não é transitivo. Os spokes não conseguem se comunicar por um hub sem rotas e sem um appliance no meio.

Deixar serviços de plataforma no endpoint público. Regras de firewall ajudam, mas endpoints privados com DNS privado são o padrão que os revisores esperam para qualquer coisa que guarde dados regulados.

Principais conclusões

• O Azure aninha os recursos em tenant, grupo de gerenciamento, assinatura e grupo de recursos; políticas e atribuições de função são herdadas para baixo, e o grupo de recursos é a unidade de implantação e exclusão.
• O Entra ID autentica e suas funções de diretório governam o diretório; o Azure RBAC autoriza ações sobre recursos por meio de atribuições de função com escopo em qualquer ponto da hierarquia.
• As identidades gerenciadas eliminam totalmente as credenciais armazenadas e devem ser a forma padrão de as cargas de trabalho acessarem armazenamento, bancos de dados e Key Vault.
• As opções de computação se resumem a VMs, App Service, AKS e Functions; no armazenamento, redundância e camada de acesso dominam as decisões, e políticas de ciclo de vida devem mover os dados automaticamente.
• VNets, NSGs, peering não transitivo e endpoints privados definem a postura de rede; Bicep ou Terraform devem descrever tudo isso como código.