Como escolher entre Terraform, Bicep e ARM para IaC no Azure?

Escolher entre Terraform, Bicep e ARM para IaC no Azure é uma decisão que impacta diretamente a maturidade operacional, a velocidade de entrega e a capacidade de governança da infraestrutura em nuvem. Para equipes de TI em empresas de médio e grande porte, essa escolha raramente é trivial: cada ferramenta carrega trade-offs reais em curva de aprendizado, integração com pipelines de CI/CD, suporte a múltiplos provedores e alinhamento com os padrões já adotados pela organização.

ARM Templates foram durante anos a única opção nativa do Azure, mas sua verbosidade em JSON afastou muitas equipes. O Bicep surgiu como uma linguagem declarativa de domínio específico para simplificar exatamente esse problema, mantendo integração total com o ecossistema Microsoft. O Terraform, por sua vez, consolidou-se como padrão de mercado para infraestrutura multi-cloud, com uma comunidade robusta e um modelo de estado que oferece controle granular sobre o ciclo de vida dos recursos.

Neste artigo, analisamos os critérios técnicos e estratégicos que devem guiar essa decisão — considerando maturidade do time, complexidade do ambiente, requisitos de governança e o contexto de organizações que operam em setores regulados, como o financeiro. O objetivo é ajudar gestores e arquitetos de nuvem a fazer uma escolha fundamentada, não apenas seguir a ferramenta mais popular do momento.

Terraform, Bicep e ARM: Qual Ferramenta de IaC Escolher para o Azure?

A escolha entre Terraform, Bicep e ARM Templates é uma das decisões técnicas mais relevantes para times que gerenciam infraestrutura no Azure. Cada ferramenta tem filosofia, curva de aprendizado e casos de uso distintos — e escolher errado significa dívida técnica, retrabalho e fricção nos pipelines de entrega. Este artigo apresenta uma análise comparativa objetiva para ajudar CTOs, gerentes de infraestrutura e engenheiros de plataforma a tomar essa decisão com base em critérios concretos.

O Que é Infrastructure as Code (IaC) e Por Que Isso Importa no Azure

Infrastructure as Code é a prática de provisionar e gerenciar recursos de infraestrutura por meio de arquivos de configuração versionáveis, em vez de processos manuais via portal ou CLI. No contexto do Azure, isso significa descrever máquinas virtuais, redes, bancos de dados, políticas de segurança e qualquer outro recurso em código — e aplicar esse código de forma repetível, auditável e automatizada.

Benefícios de Adotar IaC em Ambientes Azure

Reprodutibilidade: ambientes de desenvolvimento, homologação e produção são criados a partir da mesma base de código, eliminando o problema do "funciona na minha máquina".
Rastreabilidade: cada mudança na infraestrutura fica registrada no histórico do repositório Git, com autor, data e justificativa — essencial para auditorias e conformidade regulatória.
Velocidade de provisionamento: pipelines de CI/CD aplicam mudanças de infraestrutura em minutos, sem intervenção manual.
Redução de erro humano: configurações críticas como regras de firewall, políticas de acesso e criptografia de storage são definidas em código e aplicadas de forma consistente.
Governança e conformidade: IaC facilita a implementação de guardrails — por exemplo, garantir que nenhum recurso seja criado sem tags de centro de custo ou sem criptografia habilitada.

Para empresas que operam em setores regulados — financeiro, saúde, empresas que processam transações Pix — a rastreabilidade e a consistência que o IaC oferece são especialmente relevantes para atender requisitos do Banco Central e da LGPD. Se você está avaliando como a automação de infraestrutura se encaixa em uma estratégia DevOps mais ampla, o artigo sobre contratar DevOps como serviço e montar um time interno oferece um contexto complementar útil.

Visão Geral das Três Principais Opções: Terraform, Bicep e ARM Templates

ARM Templates são a camada nativa do Azure Resource Manager — o plano de controle que processa toda criação e atualização de recursos no Azure. Bicep é uma linguagem de domínio específico (DSL) desenvolvida pela Microsoft que compila para ARM, oferecendo sintaxe mais limpa e legível. Terraform, da HashiCorp, é uma ferramenta de IaC agnóstica de provedor que suporta Azure por meio do provider AzureRM, além de dezenas de outros provedores de nuvem e serviços SaaS. As três são opções válidas e produção-ready — a diferença está nos trade-offs.

ARM Templates: A Base Nativa do Azure

Como Funcionam os ARM Templates

ARM Templates são arquivos JSON que descrevem os recursos a serem provisionados no Azure. Quando você submete um template, o Azure Resource Manager o valida, resolve dependências entre recursos e executa as operações de criação ou atualização na ordem correta. O ARM é o motor por baixo de toda interação com o Azure — seja via portal, CLI, PowerShell ou qualquer outra ferramenta de IaC. Isso significa que ARM Templates têm acesso imediato a qualquer recurso ou propriedade que o Azure suporte, sem intermediários.

Vantagens dos ARM Templates

Cobertura total e imediata: qualquer novo serviço ou propriedade lançado no Azure está disponível em ARM no mesmo dia — sem depender de atualizações de provider ou DSL.
Sem dependência externa: não há ferramenta de terceiros, binário adicional ou estado externo para gerenciar; tudo roda nativamente na plataforma Azure.
Integração nativa com Azure Policy e Blueprints: templates ARM são o formato de referência para definições de política e blueprints de governança.
Suporte robusto da Microsoft: documentação extensa, exemplos no GitHub (azure-quickstart-templates) e suporte oficial.

Limitações e Desvantagens dos ARM Templates

O principal problema dos ARM Templates é a verbosidade do JSON. Um recurso simples como uma conta de storage pode exigir dezenas de linhas de código com estrutura aninhada profunda, sem suporte nativo a comentários no JSON puro. A reutilização de código é limitada — templates vinculados (linked templates) existem, mas adicionam complexidade de hospedagem e referência. A lógica condicional e loops existem, mas com sintaxe pouco intuitiva usando funções como copyIndex() e expressões de template. Para times que precisam manter grandes bases de código de infraestrutura, ARM puro se torna difícil de escalar e revisar. Não à toa, a própria Microsoft desenvolveu o Bicep como alternativa.

Azure Bicep: A Evolução Moderna dos ARM Templates

Como o Bicep se Relaciona com ARM por Baixo dos Panos

Bicep não é uma abstração sobre ARM — é uma transpilação. O compilador Bicep converte arquivos .bicep em ARM Templates JSON antes de enviá-los ao Azure Resource Manager. Isso significa que Bicep tem a mesma cobertura de recursos que ARM, com a mesma latência zero para novos lançamentos. Não existe runtime do Bicep em execução — o Azure processa ARM JSON puro. Essa relação é análoga à do TypeScript com JavaScript: você escreve em uma linguagem mais expressiva, mas o que executa é a camada de baixo nível.

Sintaxe e Legibilidade: Por Que o Bicep é Mais Fácil de Escrever

Bicep elimina a estrutura JSON repetitiva e substitui por uma DSL declarativa e concisa. Declarar um recurso em Bicep é direto: a palavra-chave resource, seguida do nome simbólico, tipo e versão da API, e um bloco de propriedades sem aninhamento excessivo. Loops usam a sintaxe for nativa. Condicionais usam if de forma legível. Módulos são arquivos .bicep referenciados diretamente — sem necessidade de hospedar templates vinculados em storage. Comentários são suportados. A experiência no VS Code com a extensão oficial inclui IntelliSense, validação em tempo real e navegação de recursos.

Vantagens do Bicep para Times Focados no Azure

Curva de aprendizado significativamente menor do que ARM JSON para quem já conhece Azure.
Cobertura de recursos idêntica ao ARM — sem defasagem para novos serviços.
Módulos reutilizáveis com referência local ou via Bicep Registry (ACR ou registro público).
Integração nativa com Azure CLI (az deployment) e Azure DevOps sem configuração adicional.
Sem gerenciamento de estado externo — o estado é o próprio Azure.
Suporte oficial e roadmap ativo da Microsoft, com investimento crescente na ferramenta.

Limitações do Bicep: Quando Ele Não é Suficiente

Bicep é Azure-only. Se a organização opera em multi-cloud — AWS, GCP, ou provedores SaaS como Datadog, Cloudflare, MongoDB Atlas — Bicep não serve para os recursos fora do Azure. Times que precisam de uma linguagem única para gerenciar toda a infraestrutura heterogênea encontrarão no Bicep uma solução parcial. Além disso, o ecossistema de módulos públicos do Bicep, embora crescente, ainda é menor do que o Terraform Registry. Para empresas com infraestrutura exclusivamente no Azure, essas limitações raramente são bloqueantes.

Terraform: IaC Multi-Cloud e Agnóstico de Provedor

Como o Terraform Funciona com o Azure (Provider AzureRM)

O Terraform interage com o Azure por meio do provider AzureRM, mantido pela HashiCorp em parceria com a Microsoft. O provider expõe recursos do Azure como blocos HCL (HashiCorp Configuration Language) — por exemplo, azurerm_virtual_network, azurerm_storage_account, azurerm_key_vault. O Terraform chama as APIs do Azure Resource Manager por baixo dos panos, da mesma forma que ARM Templates ou Bicep. A diferença está na camada de abstração e no modelo de operação: o Terraform mantém um arquivo de estado (state file) que representa o mapeamento entre o código HCL e os recursos reais provisionados.

HCL vs JSON/Bicep: Comparando a Experiência de Desenvolvimento

HCL é uma linguagem declarativa projetada para ser legível por humanos. A sintaxe é mais limpa do que JSON e comparável ao Bicep em termos de concisão. O Terraform oferece recursos poderosos como locals (variáveis calculadas localmente), data sources (consulta de recursos existentes sem gerenciá-los), count e for_each para loops, e dynamic blocks para gerar blocos de configuração programaticamente. O ecossistema de providers é a maior vantagem: o mesmo arquivo de configuração pode provisionar recursos no Azure, configurar registros DNS no Cloudflare, criar workspaces no Databricks e gerenciar segredos no HashiCorp Vault.

Gerenciamento de Estado no Terraform: O Que é e Por Que Importa

O state file é o coração do Terraform — e também sua maior fonte de complexidade operacional. Esse arquivo JSON mapeia cada recurso no código HCL ao recurso real na nuvem, incluindo IDs, atributos e dependências. Sem ele, o Terraform não sabe o que já existe e o que precisa ser criado, atualizado ou destruído. Em ambientes de time, o state precisa ser armazenado remotamente — no Azure, o backend padrão é um Azure Blob Storage com lock via Azure Blob Lease. Problemas com state corrompido, conflitos de lock ou drift entre o state e a realidade são os principais desafios operacionais do Terraform. Ferramentas como Terragrunt e plataformas como Terraform Cloud ou HCP Terraform ajudam a mitigar esses problemas, mas adicionam camadas de complexidade.

Vantagens do Terraform para Ambientes Multi-Cloud ou Híbridos

Uma única linguagem e fluxo de trabalho para gerenciar infraestrutura em múltiplos provedores.
Ecossistema massivo: mais de 3.000 providers no Terraform Registry, incluindo Azure, AWS, GCP, Kubernetes, GitHub, Datadog e outros.
Módulos públicos maduros e amplamente testados pela comunidade.
Plan explícito (terraform plan) que mostra exatamente o que será criado, modificado ou destruído antes de qualquer ação.
Amplamente adotado no mercado — facilita contratação de engenheiros com experiência prévia.

Limitações do Terraform no Contexto Azure

O provider AzureRM pode ter defasagem em relação ao lançamento de novos recursos ou propriedades do Azure. Quando a Microsoft lança um novo serviço, ele está disponível imediatamente via ARM/Bicep, mas pode levar semanas ou meses para ser suportado no provider Terraform. A gestão do state file exige disciplina e infraestrutura dedicada (storage account, políticas de acesso, estratégias de backup do state). O modelo de licenciamento da HashiCorp mudou em 2023 com a adoção da licença BSL, o que levou ao surgimento do OpenTofu como fork open-source — uma variável adicional de risco para organizações com requisitos rígidos de licenciamento.

Comparação Direta: Terraform vs Bicep vs ARM

Tabela Comparativa: Curva de Aprendizado, Maturidade, Suporte e Ecossistema

ARM Templates: curva alta (JSON verboso), maturidade máxima, suporte oficial Microsoft, ecossistema limitado a Azure.
Bicep: curva baixa a média, maturidade crescente (GA desde 2021), suporte oficial Microsoft com roadmap ativo, ecossistema focado em Azure.
Terraform: curva média (HCL + conceito de state), maturidade alta, suporte da HashiCorp e comunidade global, ecossistema multi-cloud extenso.

Gerenciamento de Estado: Diferenças Fundamentais entre as Ferramentas

ARM e Bicep não têm estado externo — o Azure Resource Manager é stateful por natureza, rastreando todos os recursos e suas propriedades. O Terraform exige um state file gerenciado externamente. Isso significa que ARM/Bicep têm menos overhead operacional para equipes menores, enquanto o Terraform exige investimento em infraestrutura de state (storage account, locks, controle de acesso) e processos para lidar com drift e importação de recursos existentes.

Suporte a Módulos e Reutilização de Código

Terraform tem o ecossistema de módulos mais maduro, com o Terraform Registry oferecendo módulos públicos para praticamente qualquer cenário Azure. Bicep tem módulos locais e o Bicep Registry (via Azure Container Registry), com crescimento acelerado e módulos oficiais da Microsoft. ARM oferece templates vinculados, mas a experiência é significativamente mais complexa. Para reutilização de código em escala, Terraform e Bicep estão à frente do ARM puro.

Integração com Azure DevOps e GitHub Actions

As três ferramentas integram bem com pipelines de CI/CD. Azure DevOps tem tasks nativas para ARM/Bicep (AzureResourceManagerTemplateDeployment) e para Terraform (TerraformTaskV4). GitHub Actions tem actions oficiais para as três ferramentas. Bicep tem vantagem em pipelines Azure DevOps por não exigir configuração de backend de state — basta autenticar com uma service connection e executar az deployment. Terraform exige steps adicionais para inicializar o backend e gerenciar o state.

Cobertura de Recursos Azure: Qual Ferramenta Suporta Mais Serviços?

ARM e Bicep têm cobertura de 100% dos recursos Azure por definição — qualquer recurso que o Azure suporta pode ser provisionado via ARM Template ou Bicep no mesmo dia do lançamento. O provider AzureRM do Terraform cobre a grande maioria dos serviços comuns, mas pode ter lacunas em recursos novos ou muito específicos. Para serviços como Azure Confidential Computing, funcionalidades preview ou propriedades recém-adicionadas, ARM/Bicep sempre estarão à frente.

Velocidade de Adoção de Novos Recursos do Azure

Este é um ponto crítico para times que trabalham com serviços em preview ou que precisam adotar novos recursos rapidamente. ARM e Bicep ganham aqui sem discussão — a disponibilidade é imediata. O Terraform depende do ciclo de release do provider AzureRM, que geralmente acompanha lançamentos importantes, mas com alguma latência. Para ambientes que precisam de acesso imediato a funcionalidades de ponta do Azure, Bicep é a escolha mais segura.

Critérios Decisivos para Escolher a Ferramenta Certa

Critério 1: Estratégia de Nuvem — Azure Only ou Multi-Cloud?

Este é o critério mais determinante. Se a organização opera exclusivamente no Azure e não tem planos de adotar outros provedores de nuvem no médio prazo, Bicep é a recomendação padrão: cobertura total, sintaxe moderna, sem overhead de state, com suporte oficial da Microsoft e roadmap ativo. Se a organização já opera em multi-cloud (Azure + AWS, Azure + GCP) ou gerencia infraestrutura heterogênea que inclui provedores SaaS relevantes, Terraform é a escolha natural — a capacidade de usar uma única linguagem e fluxo de trabalho para toda a infraestrutura supera os custos operacionais do gerenciamento de state. ARM puro raramente é a escolha certa para projetos novos — seu caso de uso principal hoje é automação de políticas, blueprints e cenários onde a integração nativa com o Azure Resource Manager é obrigatória.

Essa decisão também tem impacto em custos. Uma infraestrutura bem codificada em IaC facilita práticas de otimização de custos no Azure, pois permite identificar e eliminar recursos ociosos de forma sistemática — algo difícil de fazer com provisionamento manual.

Critério 2: Tamanho e Experiência do Time de Engenharia

Times pequenos ou com pouca experiência em IaC se beneficiam da menor complexidade operacional do Bicep. Sem state file para gerenciar, sem backend para configurar, sem risco de drift entre state e realidade — a equipe foca em escrever e aplicar código de infraestrutura, não em operar a ferramenta de IaC. Times maiores ou com engenheiros experientes em Terraform conseguem absorver a complexidade adicional e se beneficiam do ecossistema mais maduro de módulos e da padronização que o Terraform oferece em ambientes híbridos. Para organizações que estão começando a jornada de IaC, o artigo sobre primeiros passos para adotar DevOps contextualiza bem onde IaC se encaixa na maturidade geral da engenharia.

A experiência prévia do time também pesa: se os engenheiros já conhecem Terraform de projetos anteriores, a curva de adoção no Azure é baixa — basta aprender o provider AzureRM. Se o time vem de um background Azure-centric (Azure Administrator, Azure DevOps), Bicep é a extensão natural do conhecimento existente.

Critério 3: Complexidade da Infraestrutura e Escala do Projeto

Para projetos de infraestrutura simples a moderada — um ambiente de aplicação com rede virtual, alguns serviços PaaS, Key Vault e banco de dados — Bicep entrega tudo que é necessário com menos fricção. Para infraestruturas complexas com múltiplos ambientes, dezenas de serviços interdependentes, integrações com sistemas externos e requisitos de governança avançados, o ecossistema de módulos e a maturidade do Terraform oferecem vantagens reais em termos de organização e reutilização de código.

Projetos que envolvem FinOps estruturado — onde a infraestrutura precisa ser tagueada, auditada e otimizada continuamente — se beneficiam de qualquer uma das três ferramentas, desde que as tags e políticas sejam codificadas desde o início. Se a organização ainda não tem uma estratégia de FinOps no Azure, adotar IaC é um pré-requisito natural para implementá-la de forma eficaz.

Em síntese: não existe ferramenta universalmente superior. ARM Templates são o fundamento técnico de tudo, mas raramente a escolha para código novo. Bicep é a evolução lógica para times Azure-first, com menor custo operacional e suporte oficial crescente. Terraform é a escolha certa quando a portabilidade multi-cloud ou a padronização em um ecossistema heterogêneo são requisitos reais — não hipotéticos. A decisão deve ser guiada pela estratégia de nuvem da organização, pela maturidade do time e pela complexidade da infraestrutura, não por tendências de mercado ou preferências pessoais.