O artigo anterior estabeleceu a visão geral: como o Azure se organiza, como a identidade funciona, como o Terraform autentica e as equivalências entre os principais serviços. Com esse mapa em mãos, é possível ir mais fundo nos serviços que formam a infraestrutura de qualquer aplicação: compute, storage e rede.
Este artigo cobre Azure Virtual Machines, Blob Storage, Virtual Network e Azure Functions com a profundidade necessária para colocá-los em produção — não apenas criar recursos, mas configurá-los com boas práticas de segurança, performance e custo.
Azure Virtual Machines em Produção
As Azure Virtual Machines são o equivalente direto das instâncias EC2. A seleção do tipo correto de VM segue a mesma lógica da AWS: para cada carga de trabalho existe uma família otimizada.
A nomenclatura do Azure usa letras para indicar a família e números para o tamanho. O padrão é Standard_[Família][vCPUs][Sufixo]. As principais famílias são a B-series (burstable, equivalente ao T3/T4g da AWS), a D-series (propósito geral, equivalente ao M5/M6i), a E-series (memória otimizada, equivalente ao R5/R6i), a F-series (compute otimizado, equivalente ao C5/C6i), a L-series (storage otimizado com NVMe, equivalente ao I3/I4i) e a N-series (GPU, equivalente ao P3/G4).
O sufixo no nome carrega informações importantes: s indica suporte a Premium Storage (SSD gerenciado de alta performance), d indica disco NVMe local temporário, _v5 é a geração do hardware. Para workloads de produção, sempre preferir as versões mais recentes pois oferecem melhor desempenho por custo.
Uma VM de produção no Azure é provisionada com Terraform declarando o resource group, a VNet e subnet, a network interface (ponte entre VM e subnet), opcionalmente um managed disk separado para dados (boa prática: separar disco de SO de disco de dados), e a VM em si com disable_password_authentication = true para usar apenas chave SSH. A Managed Identity do tipo SystemAssigned elimina qualquer necessidade de credenciais hardcoded para acessar outros serviços Azure. O campo custom_data com base64 é o equivalente ao User Data da AWS para scripts de inicialização.
Spot VMs
O equivalente ao EC2 Spot no Azure são as Azure Spot VMs — compute com desconto de 60–90% usando capacidade ociosa, que pode ser desalocada com 30 segundos de aviso. A configuração usa priority = "Spot" e eviction_policy. A diferença importante: na AWS, instâncias Spot sempre são terminadas quando interrompidas. No Azure, é possível escolher entre Deallocate (VM para mas o disco persiste, cobrança pelo disco continua) ou Delete (tudo é deletado, equivalente ao comportamento AWS). Para workers de processamento em batch, Delete é a escolha mais limpa.
Azure Blob Storage em Profundidade
O Azure Blob Storage é o equivalente do S3, mas com uma hierarquia de três níveis: Storage Account → Container → Blob. A Storage Account é a entidade de cobrança e o namespace — ela tem um nome único globalmente, assim como os buckets S3, mas esse nome define o endpoint DNS do serviço (nomeconta.blob.core.windows.net).
Tipos de Redundância
Diferente do S3 onde há um único tipo de serviço com múltiplas classes de armazenamento, no Azure a redundância é configurada no nível da Storage Account. O LRS (Locally Redundant Storage) mantém 3 cópias dentro de um único data center — o mais barato, não protege contra falha do data center. O ZRS (Zone-Redundant Storage) mantém 3 cópias em 3 availability zones — recomendado para produção. O GRS (Geo-Redundant Storage) mantém 6 cópias: 3 na região primária e 3 na região secundária — protege contra desastre regional. O GZRS combina ZRS na região primária com replicação geográfica — máxima durabilidade.
Access Tiers
O Azure Blob Storage tem quatro tiers de acesso. O Hot é para dados acessados com frequência — maior custo de armazenamento, menor custo de acesso, equivalente ao S3 Standard. O Cool é para dados acessados raramente, mínimo 30 dias de retenção — equivalente ao S3 Standard-IA. O Cold é para dados acessados muito raramente, mínimo 90 dias. O Archive é armazenamento offline — reidratação leva horas, equivalente ao S3 Glacier, mínimo 180 dias.
Uma diferença importante do S3: no Azure, o tier Archive opera no nível do blob individual, não do container. Para acessar um blob em Archive, é necessário "reidratá-lo" explicitamente, o que pode levar de 1 a 15 horas dependendo da prioridade escolhida.
A política de lifecycle no Azure é equivalente ao S3 Lifecycle Rules: é possível mover automaticamente blobs para Cool após N dias, para Archive após N dias, e deletar após N dias — tudo baseado em filtros por prefixo e tipo de blob.
Segurança no Blob Storage
Em produção, a Storage Account deve ter https_traffic_only_enabled = true, min_tls_version = "TLS1_2" e allow_nested_items_to_be_public = false. O soft delete (equivalente ao S3 Versioning com proteção contra deleção) mantém blobs deletados por N dias antes de removê-los permanentemente. O versionamento de blobs é habilitado com versioning_enabled = true nas blob properties.
Networking Avançado: Application Gateway
Na AWS, o ALB distribui tráfego HTTP/HTTPS baseado em regras de roteamento. No Azure, esse papel é do Application Gateway, que adiciona WAF integrado e terminação SSL.
O Application Gateway requer uma subnet dedicada (não pode compartilhar com outros recursos) e um IP público do SKU Standard. A configuração declara um backend address pool (onde vivem os servidores), backend HTTP settings (porta, protocolo, health probe), um frontend listener (porta, protocolo, certificado SSL) e routing rules que ligam listeners a backend pools. O WAF é configurado em modo Detection (apenas registra) ou Prevention (bloqueia) com os rule sets OWASP. O certificado SSL pode ser referenciado diretamente do Key Vault via key_vault_secret_id, sem precisar gerenciar o arquivo do certificado no Terraform.
Azure Functions em Profundidade
As Azure Functions têm três planos de hospedagem. O Consumption Plan é o equivalente direto ao Lambda: paga-se apenas pelo tempo de execução, escala automaticamente para zero quando não há invocações, e há cold start a considerar. O Premium Plan mantém instâncias pré-aquecidas eliminando cold starts, oferece conectividade com VNet e permite instâncias de maior capacidade — ideal para funções com resposta consistente exigida. O Dedicated (App Service) Plan roda as funções em VMs dedicadas, fazendo sentido quando já existe um App Service Plan compartilhado.
Uma Function App Linux requer uma Storage Account para armazenamento interno do runtime, um Service Plan (Y1 = Consumption), e o Application Insights para telemetria automática — um item que o AWS Lambda requer configuração manual para equivalente. A referência a secrets do Key Vault nas variáveis de ambiente usa a sintaxe @Microsoft.KeyVault(SecretUri=...), o que significa que o valor nunca aparece no Terraform ou nas configurações da função.
Os triggers das Azure Functions cobrem os mesmos casos de uso do Lambda: HTTP, Blob Storage (equivalente a S3 Event), Service Bus/Queue Storage (equivalente a SQS), Timer (equivalente ao EventBridge Scheduler) e muitos outros. O formato de CRON do Azure usa 6 campos com segundos no início (segundos minutos horas dias mês dia-semana), diferente dos 5 campos padrão do Linux — 0 0 2 * * * no Azure equivale a 0 2 * * ? * no EventBridge.
Azure Key Vault
O Azure Key Vault concentra em um único serviço o que na AWS é dividido entre Secrets Manager, KMS e ACM. Ele gerencia secrets, chaves de criptografia e certificados com uma API unificada e integração nativa com outros serviços Azure.
Em produção, o Key Vault deve ter soft_delete_retention_days = 90, purge_protection_enabled = true (proteção contra deleção permanente acidental) e enable_rbac_authorization = true (modelo mais moderno que Access Policies). As network ACLs devem restringir o acesso apenas a subnets autorizadas, com default_action = "Deny".
A permissão de uma Managed Identity para ler secrets usa o role Key Vault Secrets User via azurerm_role_assignment com escopo no Key Vault — sem precisar criar Access Policies manualmente.
Referências para Aprofundamento
— Tamanhos de VMs no Azure: https://learn.microsoft.com/pt-br/azure/virtual-machines/sizes/overview — Introdução ao Azure Blob Storage: https://learn.microsoft.com/pt-br/azure/storage/blobs/storage-blobs-introduction — Escala e Hospedagem do Azure Functions: https://learn.microsoft.com/pt-br/azure/azure-functions/functions-scale — O Que É o Azure Application Gateway: https://learn.microsoft.com/pt-br/azure/application-gateway/overview — Visão Geral do Azure Key Vault: https://learn.microsoft.com/pt-br/azure/key-vault/general/overview