Azure (Serviços equivalentes)

O Microsoft Azure é a segunda maior nuvem pública do mercado e a opção mais natural em ambientes corporativos que já dependem do ecossistema Microsoft, como Active Directory, Office 365 e licenciamento Windows e SQL Server. Sua arquitetura de serviços cobre as mesmas categorias da AWS, com nomes, modelos de organização e nuances de governança próprios. Para quem já conhece AWS, o caminho mais rápido de aprendizado é mapear as equivalências e depois estudar onde os modelos divergem, porque as diferenças estruturais ficam na organização hierárquica e nas ferramentas de gestão, e não na capacidade técnica. Em produção, a escolha do Azure frequentemente nasce de integração corporativa, contratos de empresa e incentivos de licenciamento, e não apenas de mérito técnico isolado. Este arquivo apresenta o panorama por categoria com as equivalências principais e as diferenças de governança que surpreendem quem vem da AWS.

Hierarquia de organização: subscriptions e resource groups

O Azure organiza recursos em uma hierarquia que não existe na AWS na mesma forma. A unidade fundamental de gestão e cobrança é a subscription; dentro dela, os resource groups agrupam recursos que compartilham o mesmo ciclo de vida, e os recursos individuais ficam dentro dos grupos. Management groups empilham subscriptions e aplicam políticas e RBAC em cascata, formando uma árvore de governança corporativa.

Essa hierarquia traz consequências práticas: um resource group inteiro pode ser excluído com um único comando, o que acelera ambientes efêmeros mas aumenta o raio de acidente; quotas e limites são por subscription, e atingir o limite em uma subscription exige redistribuição de cargas; políticas aplicadas em management group garantem que nenhuma subscription filha possa criar recursos fora do padrão. A AWS isola contas por completo e o Azure permite governança unificada com isolamento mais fino por camada, e essa é a principal mudança de mentalidade para quem migra.

Compute: App Service, AKS e Functions

A oferta de computação do Azure cobre o mesmo espectro da AWS, de plataforma PaaS a Kubernetes gerenciado.

O App Service é o diferencial competitivo do Azure no segmento PaaS: deployment slots permitem staging integrado e troca a quente entre versões, integração nativa com GitHub Actions e Application Insights, e suporte amplo a stacks corporativas. O AKS simplifica o control plane do Kubernetes e integra identidade gerenciada, monitoramento e rede do Azure. As Azure Functions oferecem consumo baseado em execução, com planos dedicados e premium para cold start reduzido e VNet integrada.

Para times que administram contêineres sem querer operar Kubernetes, o Azure Container Apps oferece a terceira via: contêineres com escala até zero, KEDA para escala baseada em eventos e o mesmo agente de ambiente do AKS por baixo, sem expor o control plane. A decisão entre App Service, Container Apps e AKS segue o mesmo raciocínio do comparativo AWS: comece pelo modelo mais gerenciado que atende o caso e só suba de complexidade quando limites concretos forem atingidos.

# App Service com deployment slot de staging e troca a quente
az webapp create --resource-group rg-producao --plan asp-producao \
  --name api-pedidos --runtime "DOTNET:8"

az webapp deployment slot create --name api-pedidos \
  --resource-group rg-producao --slot staging

# Publica no slot, valida e promove para produção sem downtime
az webapp deployment slot swap --name api-pedidos \
  --resource-group rg-producao --slot staging --target-slot production

Esse fluxo de slots é o equivalente nativo do blue-green no Azure e resolve a maioria dos deploys de aplicações web sem infraestrutura adicional, sendo uma das razões pelas quais times .NET raramente saem do App Service.

Storage: Blob Storage, discos e Files

O Blob Storage é a resposta do Azure ao S3: armazenamento de objetos com contas de armazenamento, containers e blobs, camadas Hot, Cool, Cold e Archive por frequência de acesso, e lifecycle policies para transição automática. Blob recebe todos os casos clássicos de objeto: arquivos de usuário, backups, data lake e artefatos de build.

Para blocos, os Managed Disks anexam discos a máquinas virtuais, com tiers de desempenho que vão de HDD padrão a SSD Premium e Ultra para cargas de IOPS intensivo. O Azure Files entrega compartilhamentos SMB e NFS gerenciados, o equivalente do EFS, usado em lifted-and-shifted e cenários de arquivo compartilhado entre VMs e contêineres. Diferença relevante para quem vem da AWS: no Azure, conta de armazenamento é o agrupador de Blob, Files, filas e tabelas, e nomes de contas são globalmente únicos, o que exige planejamento de nomenclatura desde o início.

As opções de redundância do Blob também exigem decisão explícita, pois cada nível tem preço e alcance de durabilidade diferentes.

Em produção, ZRS é o piso razoável para dados de aplicação, e GZRS fica para backups e dados de continuidade, com a decisão de ativar failover para a região secundária documentada no plano de desastre.

Database: Azure SQL e Cosmos DB

O Azure SQL Database é o banco relacional gerenciado construído sobre SQL Server, com camadas de compra por vCore ou DTU, Hyperscale para tamanhos de até centenas de GB a múltiplos TB com réplicas de leitura, e elastic pools para milhares de bancos pequenos compartilhando capacidade. Para quem já opera SQL Server on-premises, a migração é a mais suave entre nuvens, pois engine, ferramentas e compatibilidade T-SQL são preservadas.

O Cosmos DB é o banco distribuído globalmente multimodelo, com APIs compatíveis com SQL, MongoDB, Cassandra, Gremlin e Table, cobrança por RU (Request Unit) e latência de leitura de milissegundos de um dígito. Cinco níveis de consistência ajustáveis, de strong a eventual, permitem calibrar o trade-off por coleção, algo que o DynamoDB não expõe com a mesma granularidade. O custo é o alerta clássico: RUs provisionadas sem acompanhamento geram contas surpreendentes, e a modelagem deve seguir os padrões de acesso desde o desenho, como no DynamoDB.

-- Criando banco e container no Cosmos DB com API NoSQL e consistência session
CREATE DATABASE pedidos WITH partition_key = "/clienteId";

CREATE CONTAINER pedidos_itens WITH
  partition_key = "/clienteId",
  offer_throughput = 400;  -- RUs provisionadas por segundo

Networking: VNet, Load Balancer e Front Door

A VNet (Virtual Network) é o equivalente da VPC: rede privada subdividida em sub-redes, com NSGs (Network Security Groups) para filtragem e tabelas de rotas para encaminhamento. Peering entre VNets e VPN/ExpressRoute conectam redes próprias e outros ambientes, e Private Endpoints expõem serviços PaaS dentro da rede privada, análogo aos endpoints privados da AWS.

O conceito de availability zones também diverge em detalhe: na AWS toda região tem no mínimo três AZs explícitas nomeadas; no Azure, regiões têm contagem variável de zonas, e nem todo serviço ou SKU tem presença em todas as zonas. Em produção, isso exige verificar a disponibilidade zonal do SKU escolhido antes de prometer SLA zonal, pois uma VM em região sem zona suportada não recebe o mesmo nível de resiliência do desenho que presume distribuição zonal.

O balanceamento se divide em dois produtos que confundem iniciantes: o Azure Load Balancer atua em camada 4, equivalente do NLB, com balanceamento regional por IP e porta; o Application Gateway atua em camada 7, com WAF integrado e roteamento por URL, equivalente do ALB. O Front Door fecha o conjunto como serviço global de entrada HTTP com CDN embutida, health checks e failover entre regiões, na posição do CloudFront combinado ao Global Accelerator. Em arquiteturas globais de produção, o padrão comum é Front Door na entrada mundial e Application Gateway por região para inspeção e roteamento local.

Tabela de equivalências AWS, Azure e GCP

Memorizar a tabela não substitui entender os modelos: cada equivalência esconde diferenças de cota, preço, integração e maturidade regional que importam no desenho final. Ao comparar propostas técnicas entre nuvens, compare unidades de cobrança, SLA e limites de serviço, e não apenas o nome do produto, pois é aí que as equivalências falham silenciosamente.

Aplicação prática: topologia de referência

Uma topologia de produção no Azure segue o mesmo esqueleto lógico da AWS, com peças equivalentes. Front Door recebe o tráfego global e encaminha para um Application Gateway com WAF por região; VM Scale Sets ou AKS servem a aplicação em sub-redes privadas de múltiplas zonas; Azure SQL com redundância zonal guarda a fonte da verdade; Blob Storage com ZRS recebe arquivos via SAS de leitura restrita; Key Vault entrega segredos via managed identity.

A diferença operacional aparece nas ferramentas: Application Insights e Log Analytics centralizam telemetria com menos montagem que a combinação equivalente na AWS, e o Benefício Híbrido pode reduzir de forma decisiva o custo de cargas Windows e SQL Server. O desenho deve explicitar a subscription de destino, o resource group de cada peça e as policies aplicáveis antes da criação de qualquer recurso.

Diferenças de governança para quem vem da AWS

• Subscription no lugar de conta: a fronteira de quota e cobrança é mais permeável, e multi-account exige disciplina com management groups e Azure Policy, não apenas isolamento físico.
• Resource group como ciclo de vida: a exclusão de um grupo derruba todos os recursos de uma vez; desenhe grupos por deploy unitário, não por tipo de recurso.
• Entra ID (antigo Azure AD) como identidade: RBAC do portal é separado da identidade corporativa, e a federação com o AD on-premises costuma ser o primeiro projeto real de quem migra.
• Bicep e ARM templates no lugar de CloudFormation; em times multi-cloud, Terraform costuma vencer como linguagem comum para reduzir atrito.
• Preços e incentivos de licenciamento: Benefício Híbrido do Azure reutiliza licenças Windows e SQL Server, mudando radicalmente o comparativo de custo contra EC2 para cargas Microsoft.

Erros comuns e boas práticas

• Criar todos os recursos soltos na subscription, sem resource groups coesos; a exclusão, a aplicação de policy e a gestão de custo ficam impraticáveis.
• Confundir Azure Load Balancer com Application Gateway e colocar tráfego HTTP no produto errado, perdendo WAF e roteamento por path.
• Provisionar Cosmos DB com RUs altas demais "para garantir", gerando custo desperdiçado; comece com autoscale e ajuste por métrica de consumo real.
• Esquecer o Benefício Híbrido ao migrar cargas Windows e SQL Server, pagando licença que a empresa já possuía.
• Ignorar deployment slots do App Service e implementar deploy manual com downtime; slots com swap cobrem o caso com configuração mínima.
• Usar access keys de conta de armazenamento em código de aplicação; prefira managed identity e RBAC por data plane.
• Deixar subscriptions fora de management groups, perdendo policies e agregação de custo; toda subscription nova deve nascer sob governança.
• Assumir que região A tem os mesmos SKUs e zonas que região B; valide disponibilidade por região antes de fechar o desenho.
• Mapear serviços apenas pelo nome parecido e ignorar diferenças de cota e de data plane entre equivalentes aparentes.

Como prática consolidada, trate a hierarquia management group, subscription e resource group como decisão arquitetural de primeiro dia, aplique Azure Policy desde a primeira subscription, e documente o mapeamento de equivalências para acelerar a conversa entre times AWS e Azure dentro da mesma empresa.