O artigo Azure para Quem Já Conhece AWS 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
- Introdução ao Azure Blob Storage
- Escala e Hospedagem do Azure Functions
- O Que É o Azure Application Gateway
- Visão Geral do Azure Key Vault
Exercícios
Exercício 1
Aplicando o padrão Standard_[Família][vCPUs][Sufixo] descrito no artigo, decodifique Standard_E16ds_v5: o que cada parte informa, e qual seria o equivalente aproximado na AWS?
Ver resposta
✓ Resposta: Cada elemento carrega uma decisão de arquitetura:
| parte | significado |
|---|---|
E | família memória otimizada — cerca de 8 GiB de RAM por vCPU |
16 | 16 vCPUs — e, pela proporção da série, ~128 GiB de memória |
d | disco NVMe local temporário anexado à VM |
s | suporte a Premium Storage (discos gerenciados SSD de alta performance) |
v5 | 5ª geração de hardware |
O equivalente na AWS é a r6i.4xlarge: mesma família de memória otimizada, 16 vCPUs e 128 GiB. A correspondência não é exata — as gerações de hardware e os processadores diferem —, mas serve para dimensionar e comparar preços.
Duas dessas letras merecem atenção porque são fonte frequente de erro. O d indica um disco efêmero: rapidíssimo, fisicamente ligado ao host, e apagado sempre que a VM é desalocada ou migrada. É excelente para /tmp, arquivos de swap, cache local e diretórios de scratch de build; é uma armadilha para qualquer dado que precise sobreviver. Ele não custa à parte — vem incluído no preço da VM —, o que aumenta a tentação de usá-lo indevidamente.
O s importa por ausência: uma VM sem essa letra não pode anexar discos Premium SSD. Um dimensionamento feito olhando apenas vCPU e memória pode escolher um tamanho que, na hora de montar o volume de banco de dados, só aceita Standard HDD — e o problema aparece no terraform apply, ou pior, como latência inexplicável em produção.
Por isso a orientação do artigo de preferir sempre a geração mais recente é prática, e não estética: as gerações novas costumam entregar mais desempenho pelo mesmo preço ou menos. Migrar de v4 para v5 é das otimizações de custo com melhor relação entre esforço e retorno — muitas vezes basta alterar uma string e reiniciar.
Exercício 2
Um time roda workers de processamento em Spot VMs e escolhe eviction_policy = "Deallocate", com o argumento de "não perder o disco quando a VM for interrompida". Ao fim do mês, a economia esperada não aparece na fatura, e vários workers estão parados. Explique os dois problemas.
Ver resposta
✓ Resposta: O primeiro problema é de custo: Deallocate para a VM mas preserva o disco gerenciado, que continua sendo cobrado integralmente. Um worker com disco de 128 GiB Premium SSD desalocado por três semanas gera a fatura completa do armazenamento sem executar trabalho algum. Como o desconto do Spot incide sobre o compute, e o compute é exatamente o que parou, o que sobra na fatura é justamente a parte sem desconto.
O segundo é operacional, e explica os workers parados: uma VM desalocada não volta sozinha. O Azure libera a capacidade e não reinicia a instância quando ela fica disponível de novo. Sem uma automação que monitore o estado e execute az vm start, cada interrupção retira permanentemente um worker do pool. A frota encolhe silenciosamente ao longo do mês, e a fila de processamento cresce sem que nenhum alerta de falha dispare — nada está com erro, apenas parado.
Para workers de processamento em lote, Delete é a escolha correta, como o artigo indica. O trabalho não vive no disco: ele vem de uma fila e o resultado vai para o armazenamento. A instância é descartável por natureza, e a reposição é responsabilidade do scale set, que cria uma nova quando há capacidade — exatamente o comportamento das instâncias Spot na AWS, onde a terminação é a única política existente.
O Deallocate tem seu lugar, mas é estreito: uma estação de desenvolvimento com ambiente configurado à mão, ou uma máquina de treinamento cujo checkpoint está no disco local e cuja retomada é mais barata que recomeçar. Nesses casos, preservar o disco compensa — desde que exista a automação de religar, e que o custo do disco ocioso tenha sido considerado.
Vale notar a diferença de janela em relação à AWS: o Azure avisa com 30 segundos de antecedência, contra os 2 minutos do EC2 Spot. É pouco tempo para drenar trabalho em andamento, o que reforça o desenho de tarefas curtas e idempotentes — a mensagem volta para a fila e outro worker a reprocessa.
Exercício 3
O artigo destaca que o CRON do Azure usa 6 campos, com segundos no início, e que 0 0 2 * * * equivale a 0 2 * * ? * no EventBridge. Uma rotina de fechamento diário é agendada com essa expressão, mas o time no Brasil observa a execução acontecendo no dia anterior, às 23h. O que está acontecendo?
Ver resposta
✓ Resposta: A expressão está certa — o problema é o fuso horário. As Azure Functions avaliam expressões de timer em UTC por padrão, e Brasília está em UTC−3. As 02:00 UTC correspondem às 23:00 do dia anterior no horário local.
Para uma rotina de "fechamento diário", isso não é um detalhe cosmético: ela processa o dia errado. O job roda às 23h de segunda pensando estar fechando a segunda, quando ainda faltam uma hora de transações — e essas transações acabam contabilizadas no fechamento seguinte. O relatório fecha, os números batem entre si, e a atribuição por data está sistematicamente deslocada.
A correção é declarar o fuso na configuração da Function App:
app_settings = {
WEBSITE_TIME_ZONE = "E. South America Standard Time" # Windows
# em Linux: WEBSITE_TIME_ZONE = "America/Sao_Paulo"
}Repare que o nome do fuso depende do sistema operacional do plano: Windows usa a nomenclatura da Microsoft, Linux usa a base IANA. Copiar o valor errado resulta em silêncio — a variável é ignorada e a função continua em UTC.
Uma vez configurado o fuso local, aparece a questão seguinte, que costuma ser esquecida: o horário de verão. Fusos com DST fazem um agendamento diário saltar ou repetir uma execução nas noites de transição. Para rotinas financeiras, a prática mais segura é manter o agendamento em UTC e ajustar a expressão (0 0 5 * * * para as 2h de Brasília), porque UTC não tem descontinuidades. O custo é a expressão não ser autoexplicativa — o que se resolve com um comentário.
Sobre o campo extra: é ele que permite ao Azure agendar por segundo, algo que o cron clássico não faz. E é também a origem de erros de deslocamento quando se copia uma expressão de cinco campos de outro sistema — cada valor cai um campo à esquerda do pretendido, transformando "às 2h" em algo completamente diferente. Ao trazer uma expressão de fora, o primeiro passo é contar os campos.
Exercício 4
O artigo recomenda, para produção, purge_protection_enabled = true no Key Vault. Um time aplica essa configuração no módulo Terraform usado por todos os ambientes. Duas semanas depois, o pipeline de ambientes efêmeros — que cria e destrói infraestrutura a cada PR — começa a falhar na criação. O que aconteceu?
Ver resposta
✓ Resposta: O terraform destroy não apaga o Key Vault de verdade: ele o deixa em estado soft-deleted, e com purge protection ativa ninguém pode expurgá-lo antes do fim da retenção — 90 dias, no valor recomendado. Como o nome do Key Vault permanece reservado durante esse período, a recriação com o mesmo nome falha com VaultAlreadyExists. O ambiente efêmero deixa de ser efêmero.
O que agrava é a irreversibilidade da flag: uma vez habilitada, a purge protection não pode ser desabilitada. Não há como corrigir o vault existente — só esperar os 90 dias. E como o soft delete também não pode ser desligado, cada PR mergeado nesse período deixa mais um vault fantasma ocupando um nome.
A proteção é correta em produção, e é exatamente para isso que existe: impede que alguém com permissão de Owner destrua permanentemente as chaves que criptografam os dados da empresa — inclusive num ataque, em que apagar as chaves equivale a apagar tudo. O erro foi aplicar a mesma política a ambientes com ciclo de vida oposto.
A correção é condicionar ao ambiente, como o módulo do capstone faz com deletion_protection e recovery_window_in_days:
resource "azurerm_key_vault" "principal" {
soft_delete_retention_days = var.ambiente == "production" ? 90 : 7
purge_protection_enabled = var.ambiente == "production"
# …
}E, para os ambientes efêmeros, incluir nomes únicos por PR (com o número do PR ou um sufixo aleatório), de modo que a colisão não aconteça mesmo com vaults em soft delete. Se o problema já ocorreu e a proteção não está ativa, o expurgo manual libera o nome:
az keyvault purge --name kv-loja-pr-1234 --location brazilsouthA lição vale para toda configuração de proteção: o que torna um recurso seguro em produção o torna inutilizável em ambientes descartáveis. Vale a mesma pergunta em cada uma delas — esta flag pode ser desfeita? —, porque as irreversíveis precisam ser decididas uma única vez e para sempre.
Exercício 5
Uma política de lifecycle move os logs de auditoria para o tier Archive após 90 dias. Uma auditoria solicita os logs de seis meses atrás, com prazo de resposta de 24 horas. O time consegue atender? O que precisa ser considerado?
Ver resposta
✓ Resposta: Consegue, mas o prazo é apertado e exige decisão imediata — não é uma operação de leitura, é um processo.
Blobs em Archive estão offline: não podem ser lidos, copiados ou listados em seu conteúdo. É preciso reidratá-los primeiro, e a reidratação tem duas prioridades com prazos bem diferentes:
- Standard — até 15 horas, mais barata. Dentro das 24h, mas sem margem para erro: se o pedido for feito com atraso, ou se for necessário reidratar um segundo lote depois de descobrir que faltou arquivo, o prazo estoura.
- High — normalmente menos de 1 hora para blobs de até algumas centenas de MB, com custo bem maior por operação e por GB.
A primeira coisa a fazer, portanto, é escolher a prioridade alta e disparar a reidratação imediatamente — antes mesmo de saber exatamente quais arquivos serão necessários. O tempo de reidratação corre em paralelo ao trabalho de identificar o escopo do pedido.
Três pontos que costumam surpreender:
- A reidratação é por blob, não por container — o artigo destaca que no Azure o Archive opera no nível do blob individual. Milhares de arquivos de log diários significam milhares de operações, e vale usar
azcopyou um script em lote em vez do portal. - O mínimo de 180 dias do Archive é faturável: um blob movido para lá e reidratado no dia 90 é cobrado como se tivesse ficado os 180 — a mesma armadilha de duração mínima do S3.
- Reidratar não devolve o blob ao tier anterior automaticamente. Ele volta como Hot ou Cool conforme solicitado, e passa a custar como tal até que a política de lifecycle o mova de novo.
A conclusão de desenho é que o tier precisa ser escolhido a partir do prazo de recuperação exigido, não apenas do custo de armazenamento. Para dados de compliance sujeitos a solicitação com prazo curto, o Cold — acesso imediato, mínimo de 90 dias, bem mais barato que o Hot — costuma ser a escolha certa, deixando o Archive para o que só precisa existir, como retenção legal de longo prazo que ninguém espera consultar.