Ao longo dos doze meses do currículo principal desta série, a AWS funcionou como plataforma de referência. A escolha não foi arbitrária: a AWS detém a maior parcela do mercado global de nuvem e seu ecossistema de ferramentas, documentação e comunidade é o mais maduro disponível. Dominar a AWS primeiro é a decisão pedagógica correta.
Mas o mercado de trabalho não é monolítico. Grandes organizações frequentemente operam em múltiplas nuvens — seja por aquisições corporativas, requisitos regulatórios, estratégias de evitar dependência de fornecedor único ou porque determinados times já construíram expertise em uma plataforma específica. O Azure, nuvem da Microsoft, é o segundo maior provedor global e tem presença especialmente forte em empresas que já utilizam o ecossistema Microsoft: Active Directory, Office 365, SQL Server e Windows Server.
Este artigo é um mapa de tradução. Ele não recomeça do zero — parte do conhecimento já construído sobre AWS e mostra como os conceitos equivalem no Azure, onde as implementações são idênticas na prática, onde são semelhantes mas com nuances importantes, e onde o Azure segue caminhos fundamentalmente diferentes.
A Estrutura Organizacional: Contas vs. Subscrições
A primeira diferença que um engenheiro familiarizado com AWS encontra no Azure é a hierarquia organizacional. Na AWS, a unidade de isolamento de cobrança e segurança é a conta (account). Múltiplas contas são agrupadas em Organizations, com unidades organizacionais (OUs) para estruturar a hierarquia.
No Azure, a estrutura é ligeiramente diferente. O ponto de entrada é o Tenant do Azure Active Directory (agora chamado Microsoft Entra ID) — equivalente aproximado à organização como um todo. Dentro do tenant, existem Subscriptions (subscrições), que são a unidade de cobrança e limite de recursos, e funcionam de maneira análoga às contas AWS. As subscrições podem ser agrupadas em Management Groups, equivalentes às OUs no AWS Organizations.
O Resource Group merece atenção especial porque não tem equivalente direto na AWS. No Azure, todo recurso precisa pertencer a um Resource Group. Isso permite que uma aplicação completa — VMs, banco de dados, rede, storage — seja agrupada logicamente, e operações como aplicar tags, delegar permissões, monitorar custos ou deletar todos os recursos de uma vez operem sobre o grupo inteiro. É uma abstração útil que o Terraform implementa naturalmente ao provisionar recursos no Azure.
Mapa de Equivalências: AWS → Azure
A tabela a seguir cobre os serviços que aparecem em 90% dos projetos reais.
Compute: EC2 equivale a Azure Virtual Machines. A nomenclatura de tipos é diferente (B-series, D-series, E-series). Pricing por minuto em ambos. Azure Spot = EC2 Spot.
Object Storage: S3 equivale a Azure Blob Storage. A hierarquia é Storage Account → Container → Blob. Os tiers Hot/Cool/Cold/Archive equivalem aproximadamente a S3 Standard/IA/Glacier.
Containers gerenciados: ECS/Fargate equivale a Azure Container Instances (ACI). O ACI é mais simples para containers avulsos. Para orquestração, o caminho direto no Azure é o AKS.
Kubernetes gerenciado: EKS equivale ao AKS (Azure Kubernetes Service). O AKS integra-se nativamente com Entra ID para RBAC. Upgrade de versão do cluster é mais simples via CLI.
Serverless: Lambda equivale a Azure Functions. O Azure Functions suporta mais linguagens por padrão e tem modelo de hospedagem flexível (Consumption/Premium/Dedicated).
Banco relacional: RDS equivale a Azure Database for PostgreSQL/MySQL/Azure SQL. O Azure SQL é o serviço gerenciado do SQL Server — sem equivalente direto na AWS.
Cache gerenciado: ElastiCache equivale a Azure Cache for Redis. Ambos são Redis gerenciado. Configuração e tiers diferentes mas comportamento idêntico para a aplicação.
Filas de mensagens: SQS equivale a Azure Service Bus / Azure Queue Storage. O Azure Queue Storage é simples como SQS Standard. Service Bus é mais rico: tópicos, sessões, DLQ nativa — mais próximo do SQS + SNS juntos.
Event streaming: MSK/Kinesis equivale a Azure Event Hubs. O Event Hubs é compatível com protocolo Kafka — produtores/consumidores Kafka funcionam sem alteração de código.
CDN: CloudFront equivale a Azure Front Door / Azure CDN. O Front Door combina CDN + WAF + load balancing global em um produto.
DNS: Route 53 equivale a Azure DNS. O Azure DNS não tem registro de domínios nativamente.
Identidade e permissões: IAM equivale a Entra ID + Azure RBAC. Esta é a maior diferença conceitual — veja seção dedicada abaixo.
Segredos: Secrets Manager / Parameter Store equivale a Azure Key Vault. O Key Vault gerencia secrets, chaves de criptografia e certificados em um único serviço.
CI/CD: CodePipeline + CodeBuild equivale a Azure DevOps Pipelines. GitHub Actions (usado nesta série) funciona igualmente bem com Azure.
Observabilidade: CloudWatch equivale a Azure Monitor + Log Analytics. O Log Analytics Workspace tem uma linguagem de query muito mais poderosa chamada KQL.
Infraestrutura como código: CloudFormation equivale a ARM Templates / Bicep. Terraform funciona igualmente em ambas as nuvens.
Rede virtual: VPC equivale a Virtual Network (VNet). A VNet não tem subnets públicas/privadas por padrão como na AWS — o roteamento é mais flexível mas requer configuração explícita de NSGs e route tables.
Load Balancer: ALB/NLB equivale a Azure Load Balancer / Application Gateway. O Azure Load Balancer é L4 (equivalente ao NLB). O Application Gateway é L7 (equivalente ao ALB) com WAF integrado opcional.
Identidade: A Maior Diferença Conceitual
Em todas as equivalências anteriores, há uma que exige mais atenção do que as outras: identidade e permissões. Na AWS, o IAM é um serviço dentro da conta que gerencia tanto usuários humanos quanto identidades de serviços (roles). Políticas são documentos JSON que listam permissões explicitamente.
No Azure, a identidade é separada da autorização em dois sistemas distintos que trabalham juntos.
O Microsoft Entra ID (anteriormente Azure Active Directory) é o sistema de identidade — onde vivem usuários, grupos, service principals e managed identities. É um serviço de diretório completo, integrável com Active Directory on-premises via Azure AD Connect. Isso é fundamentalmente diferente do IAM da AWS, que é específico de nuvem.
O Azure RBAC (Role-Based Access Control) é o sistema de autorização — define quem pode fazer o quê em qual recurso. Em vez das políticas IAM da AWS (que listam permissões granulares), o Azure RBAC usa roles predefinidas e customizáveis que são atribuídas a identidades em um escopo específico (subscription, resource group ou recurso individual).
No Azure, uma role assignment é a combinação de: quem (identidade do Entra ID) + o que pode fazer (role com permissões) + onde (escopo: subscription, resource group ou recurso). Esse modelo é mais rígido mas mais fácil de auditar do que as políticas JSON do IAM.
Managed Identity: O Equivalente ao IAM Role para Serviços
Na AWS, quando um serviço precisa acessar outro, usa-se um IAM Role. O serviço assume o role automaticamente — sem credenciais hardcoded.
No Azure, o equivalente é a Managed Identity. A System-assigned Managed Identity é criada junto com o recurso e deletada quando o recurso é deletado — equivale a criar um IAM Role exclusivo para um recurso específico. A User-assigned Managed Identity é criada independentemente e pode ser atribuída a múltiplos recursos — equivale a um IAM Role compartilhado entre múltiplas instâncias.
Redes Virtuais: VPC vs. VNet
A Virtual Network (VNet) do Azure cumpre o mesmo papel da VPC da AWS: isola recursos em uma rede privada, controla o tráfego entre subnets e define conectividade com a internet e com redes on-premises.
A diferença mais importante é o conceito de subnets públicas e privadas. Na AWS, uma subnet é "pública" quando tem uma route table com rota para um Internet Gateway. No Azure, todas as subnets dentro de uma VNet podem ter acesso à internet por padrão — o que as torna "privadas" ou "públicas" é a combinação de Network Security Groups (NSGs), route tables e se os recursos têm Public IP Addresses associados.
O NSG do Azure equivale aos Security Groups da AWS, mas com uma diferença: ele pode ser associado tanto a subnets quanto a interfaces de rede individuais, e as regras têm prioridade numérica explícita em vez de serem permissivas por adição como nos Security Groups da AWS.
Uma nota de segurança importante: diferente da AWS onde uma subnet privada sem Internet Gateway é isolada por padrão, no Azure um recurso sem IP público ainda pode ter acesso de saída à internet via NAT implícito. Para isolar completamente, é necessário uma route table que force o tráfego de saída por um Azure Firewall.
Estado do Terraform no Azure
No currículo principal, o estado remoto do Terraform foi armazenado no S3 com lock no DynamoDB. No Azure, o backend equivalente usa Azure Blob Storage para o arquivo de estado e bloqueia via Azure Blob Storage leases — sem necessidade de um serviço separado como o DynamoDB. O backend é declarado no Terraform como backend "azurerm", apontando para a storage account, container e chave do arquivo de estado.
Regiões e Disponibilidade
Na AWS, as Regiões são localizações geográficas amplas e dentro delas existem Availability Zones — data centers fisicamente separados. No Azure, as Regions cumprem o mesmo papel. Dentro das regiões existem Availability Zones com a mesma função. O Azure adiciona um conceito intermediário relevante: Region Pairs. Cada região Azure tem um par designado geograficamente próximo para onde o Azure replica automaticamente alguns dados e prioriza recuperação em caso de interrupção regional.
A região Azure mais próxima do Brasil é a Brazil South, localizada em São Paulo — equivalente à região sa-east-1 da AWS. A região secundária para disaster recovery é a South Central US (Texas) — geograficamente mais distante que o par de AZs de São Paulo na AWS, ponto importante para arquiteturas com RTO/RPO muito baixos.
Próximos Passos na Trilha Azure
Este artigo estabeleceu o mapa de tradução entre AWS e Azure. Com os conceitos fundamentais alinhados — hierarquia organizacional, identidade, redes e estado do Terraform —, os próximos artigos aprofundam os serviços de compute, storage e rede (E2), o Kubernetes gerenciado com AKS (E3) e as pipelines de CI/CD com Azure DevOps (E4).
O investimento em aprender Azure sobre uma base sólida de AWS é menor do que aprender Azure do zero. Os princípios são os mesmos; a sintaxe, a nomenclatura e alguns padrões específicos da plataforma são o que muda.
Referências para Aprofundamento
- Azure para Profissionais AWS — Microsoft Learn
- O Que é o Azure RBAC
- Terraform AzureRM Provider
- Visão Geral do Log Analytics
- Network Security Groups
- Managed Identities para Recursos Azure
Exercícios
Exercício 1
O artigo aponta que as regras de NSG têm "prioridade numérica explícita em vez de serem permissivas por adição como nos Security Groups da AWS". Um time precisa liberar HTTPS para toda a internet, mas bloquear um bloco específico de IPs abusivos. Como isso se resolve na AWS e como se resolve no Azure?
Ver resposta
✓ Resposta: Na AWS, não se resolve com Security Group — é preciso outro recurso. No Azure, resolve-se com um único NSG.
Security Groups da AWS só admitem regras de permissão. Não existe "deny" ali, e a avaliação é aditiva: o tráfego passa se casar com qualquer regra, e tudo o que não casa é implicitamente negado. Como 0.0.0.0/0 na porta 443 já permite o bloco abusivo, nenhuma regra adicional pode retirá-lo — não há como subtrair de uma união. A negação depende de uma NACL, que atua no nível da subnet, é stateless (exige regra de retorno) e tem numeração de regras própria; ou de um WAF acima.
No Azure, o NSG admite regras Allow e Deny, cada uma com uma prioridade de 100 a 4096, e a avaliação para na primeira regra que casa — menor número vence. A ordem passa a ser o mecanismo:
prioridade 100 · Deny · origem 203.0.113.0/24 · porta 443
prioridade 200 · Allow · origem Internet · porta 443O bloqueio é avaliado antes e vence; todo o restante da internet cai na regra 200. Inverter os números inverteria o resultado — o bloqueio nunca seria alcançado.
A consequência prática para quem migra é que a ordem passa a importar. Em Security Groups, acrescentar uma regra é sempre seguro: no máximo ela amplia o acesso. Em NSGs, uma regra nova com prioridade baixa pode anular silenciosamente regras existentes, e a leitura da lista precisa ser feita de cima para baixo. Convém deixar espaço entre os números (100, 200, 300…) para permitir inserções futuras sem renumerar tudo.
Vale registrar duas outras diferenças que o artigo menciona: o NSG pode ser associado à subnet e à interface de rede, e quando ambos existem o tráfego precisa ser permitido pelos dois — o que gera boa parte dos casos de "a regra está lá e não funciona". E o NSG, como o Security Group, é stateful: a resposta de uma conexão permitida volta sem regra explícita, ao contrário da NACL.
Exercício 2
Um engenheiro com experiência em AWS provisiona uma VM no Azure em uma subnet sem IP público e sem NAT Gateway, e conclui que ela está isolada da internet, como estaria em uma subnet privada da AWS sem Internet Gateway. Por que essa conclusão é perigosa, e o que de fato isola a VM?
Ver resposta
✓ Resposta: Porque, historicamente, o Azure concede acesso de saída à internet por padrão — o chamado default outbound access. A VM não recebe conexões de entrada, mas inicia conexões livremente, através de um endereço público gerenciado pela plataforma que o engenheiro nunca declarou.
A diferença de modelo é a raiz do erro. Na AWS, o roteamento é explícito: sem rota para um Internet Gateway ou NAT Gateway na route table, o pacote não tem para onde ir e a subnet é isolada por construção. No Azure, a saída é o comportamento padrão, e o isolamento precisa ser construído ativamente — invertendo o ônus.
Isso importa porque o tráfego de saída é o que interessa a um invasor. Um container comprometido com saída livre pode baixar ferramentas, estabelecer canal de comando e controle e exfiltrar dados — tudo sem nenhuma conexão de entrada. A defesa que o engenheiro julga ter é justamente a que não existe.
O isolamento real exige uma dessas medidas, e o correto é combiná-las:
- Regra de NSG negando saída — uma regra
Denypara o service tagInternetna direção outbound, liberando apenas os destinos necessários por tags comoSql,StorageouAzureActiveDirectory. - Route table forçando o tráfego por um Azure Firewall, como o artigo indica — uma rota
0.0.0.0/0com next hop na aplicação virtual, o que permite inspeção e registro do que sai. - Private Endpoints para os serviços gerenciados, de modo que Storage, Key Vault e banco sejam alcançados por IP privado dentro da VNet, sem passar pela internet.
Uma atualização importante que muda o cenário sem invalidar o cuidado: a Microsoft está descontinuando o default outbound access para VNets criadas a partir de setembro de 2025, que passam a exigir método de saída explícito. Na prática isso significa conviver com dois comportamentos diferentes — ambientes antigos com saída implícita e novos sem ela —, e a única postura segura é verificar em vez de presumir, em qualquer um dos dois.
Exercício 3
O artigo distingue System-assigned e User-assigned Managed Identity. Um scale set de VMs que varia entre 3 e 30 instâncias precisa ler segredos do Key Vault. Qual dos dois tipos usar, e o que acontece se a escolha for a outra?
Ver resposta
✓ Resposta: User-assigned. Com System-assigned, o autoscaling quebra.
A System-assigned nasce e morre junto com o recurso, e é única para ele. Em um scale set com instâncias sendo criadas e destruídas continuamente, cada nova VM ganharia uma identidade nova, com um object ID que nunca existiu antes — e portanto sem nenhuma atribuição de acesso ao Key Vault. A VM sobe, tenta ler o segredo e recebe Forbidden. Alguém precisaria criar a role assignment manualmente para cada instância, o que é impossível em escala e inútil, já que a identidade some quando a instância é removida.
A User-assigned é um recurso independente do ciclo de vida das VMs: criada uma vez, recebe a permissão no Key Vault uma vez, e é atribuída ao scale set. Toda instância — a terceira ou a trigésima, criada agora ou daqui a seis meses — já nasce com o acesso, porque compartilha a mesma identidade. O paralelo com AWS é direto: é o IAM Role associado ao launch template do Auto Scaling Group, não um role por instância.
A regra de escolha decorre disso: System-assigned para recursos singulares e de vida longa (uma VM específica, uma instância de Azure SQL), onde a identidade morrer junto é uma vantagem — não sobra identidade órfã com permissões vivas. User-assigned quando a identidade precisa sobreviver ao recurso ou ser compartilhada por vários: scale sets, múltiplos App Services do mesmo sistema, ou quando é preciso conceder a permissão antes de o recurso existir — situação comum no Terraform, em que a ordem de criação importa.
O contraponto honesto da User-assigned é o mesmo do IAM Role compartilhado: a granularidade se perde. Todos os recursos que a usam têm exatamente as mesmas permissões, e o log de auditoria mostra a identidade, não qual instância agiu. Quando o rastreamento por instância importa, o custo operacional da System-assigned pode valer a pena.
Exercício 4
O artigo registra que o Region Pair da Brazil South é a South Central US, no Texas, e aponta a distância como "ponto importante para arquiteturas com RTO/RPO muito baixos". Além da latência, que outra consequência essa geografia traz para uma empresa brasileira?
Ver resposta
✓ Resposta: Transferência internacional de dados pessoais, regulada pelo Capítulo V da LGPD — uma questão jurídica, não técnica, e que a escolha de um par de regiões pode acionar sem que ninguém tenha decidido nada.
Replicar dados de Brazil South para o Texas significa que dados pessoais de titulares brasileiros passam a residir nos Estados Unidos. A LGPD permite isso, mas sob condições: o país precisa oferecer grau de proteção adequado reconhecido pela ANPD, ou a transferência precisa se apoiar em garantias específicas — cláusulas contratuais padrão, normas corporativas globais, consentimento específico do titular. Nada disso é automático, e tudo isso precisa estar documentado no ROPA, no campo de compartilhamento que registra receptor, país e garantia aplicada.
O que torna a situação traiçoeira é que a replicação para o par pode ser o comportamento padrão de certas configurações de armazenamento — o GRS (Geo-Redundant Storage) replica para a região par sem que se escolha o destino explicitamente. Um engenheiro seleciona "armazenamento georredundante" pensando em durabilidade e cria uma transferência internacional. Em uma auditoria, a pergunta "onde estão os dados dos seus clientes?" tem uma resposta que ninguém no time técnico esperava dar.
Sobre a parte técnica, a distância também não é detalhe: são cerca de 7.500 km, com latência de ida e volta na casa dos 130 a 160 ms — inviável para replicação síncrona, o que impõe RPO maior que zero e a possibilidade de perder as últimas transações em um desastre regional. É diferente da AWS em sa-east-1, onde as três AZs em São Paulo permitem multi-AZ síncrono dentro do país.
As saídas: usar ZRS (redundância entre zonas dentro de Brazil South) quando o requisito é alta disponibilidade sem sair do território; reservar a replicação para o par apenas ao que realmente exige sobrevivência a desastre regional; e, quando ela for necessária, anonimizar ou pseudonimizar antes de replicar, de modo que o que atravessa a fronteira não seja dado pessoal.
Exercício 5
O Resource Group é apresentado como abstração "sem equivalente direto na AWS", com a propriedade de que operações se aplicam ao grupo inteiro — inclusive "deletar todos os recursos de uma vez". Que vantagem operacional isso traz e que risco introduz? Como estruturar os grupos para aproveitar um sem sofrer o outro?
Ver resposta
✓ Resposta: A vantagem é ter uma fronteira explícita de ciclo de vida; o risco é que essa fronteira também é um botão de exclusão em massa.
Do lado bom, o Resource Group resolve com naturalidade problemas que na AWS exigem disciplina de tagging. Custos por aplicação saem prontos, sem depender de todo recurso ter sido etiquetado corretamente. Permissões podem ser delegadas ao grupo — um time recebe Contributor no seu grupo e não alcança os demais. E derrubar um ambiente efêmero é uma operação, não uma varredura em busca de recursos esquecidos: nada fica órfão, porque todo recurso pertence obrigatoriamente a um grupo.
Do lado ruim, az group delete remove tudo o que está dentro — bancos, discos, storage accounts — sem que seja preciso enumerar nada. É a mesma propriedade vista de outro ângulo, e não existe "lixeira" de Resource Group.
A estruturação que preserva a vantagem separa os recursos por ciclo de vida, não por aplicação. Recursos efêmeros e recursos duradouros não devem dividir o mesmo grupo:
rg-loja-prod-app → AKS, App Services, IPs públicos (recriável)
rg-loja-prod-dados → PostgreSQL, storage de uploads (insubstituível)
rg-loja-prod-rede → VNet, NSGs, Private DNS (estável, compartilhado)Assim, derrubar e recriar a camada de aplicação é uma operação segura e rotineira, enquanto os dados vivem atrás de uma fronteira que ninguém cruza por engano. Três proteções complementam o desenho: Resource Locks do tipo CanNotDelete nos grupos de dados — que bloqueiam a exclusão mesmo para quem tem permissão de Owner e precisam ser removidos deliberadamente antes; Azure Policy exigindo tags e restringindo tipos de recurso por grupo; e permissões desenhadas de modo que quem opera a aplicação não tenha direito de exclusão no grupo de dados.
Repare que a decisão espelha a lição das foreign keys do capstone: a estrutura deve tornar a operação destrutiva difícil exatamente onde ela é irreversível, e fácil onde o recurso é descartável por natureza.