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: https://learn.microsoft.com/pt-br/azure/architecture/aws-professional/ — O Que é o Azure RBAC: https://learn.microsoft.com/pt-br/azure/role-based-access-control/overview — Terraform AzureRM Provider: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs — Visão Geral do Log Analytics: https://learn.microsoft.com/pt-br/azure/azure-monitor/logs/log-analytics-overview — Network Security Groups: https://learn.microsoft.com/pt-br/azure/virtual-network/network-security-groups-overview — Managed Identities para Recursos Azure: https://learn.microsoft.com/pt-br/entra/identity/managed-identities-azure-resources/overview