Bicep vs Terraform no Azure: quando cada um vence — e como coexistir com governança

A decisão certa não é escolher uma ferramenta. É escolher o padrão certo sem quebrar governança.

Se você trabalha com Azure em ambiente enterprise, provavelmente já participou dessa discussão:

“Bicep ou Terraform?”

Mas essa pergunta está errada.

A pergunta certa é:

Qual ferramenta aumenta minha velocidade sem gerar dívida operacional, conflito de ownership e falhas de governança?

🧠 O erro mais comum

Muita gente trata Infrastructure as Code (IaC) como se fosse governança.

Não é.

No Azure, governança continua sendo responsabilidade de:

• Management Groups
• Azure Policy (Initiatives, Assignments, Exemptions)
• RBAC
• Landing Zones

👉 Bicep e Terraform provisionam; a governança é implementada por mecanismos de plataforma do Azure, como Azure Policy, Management Groups e RBAC, enquanto landing zones estruturam essa base em escala.

Legenda:
A decisão não é sobre ferramenta. É sobre equilibrar velocidade, governança e operação.

🌍 Domínio de mercado: generalista vs especialista

Esse é o ponto mais mal interpretado.

Terraform e Bicep não competem exatamente no mesmo espaço.

Terraform é generalista.
Bicep é especializado em Azure.

Comparação simples

👉 Tradução prática:

• Quer padronizar múltiplas clouds → Terraform
• Quer profundidade no Azure → Bicep

📈 Curva de aprendizado (vida real)

Esse ponto define adoção.

Bicep

• Mais rápido para times Azure
• Sintaxe simples
• Sem state
• Integração nativa

Terraform

• Curva inicial maior
• Precisa entender: provider, backend, state
• Mais robusto depois

Resumo direto

💻 Comparação prática com código

Os exemplos abaixo são intencionalmente simplificados para destacar o estilo de cada linguagem, não representando um deployment completo em ambiente enterprise.

🔷 Bicep

param storageAccountName string = 'stcontosoprod001'resource storage 'Microsoft.Storage/storageAccounts@2024-01-01' = {
  name: storageAccountName
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false
    minimumTlsVersion: 'TLS1_2'
  }
}

O que esse código faz:
Cria uma Storage Account no Azure usando o modelo nativo do ARM, definindo nome, tipo, redundância e configurações básicas de segurança.

✔ Simples
✔ Azure-native
✔ Sem state

🟪 Terraform

resource "azurerm_storage_account" "storage" {
  name                     = "stcontosoprod001"
  resource_group_name      = "rg-contoso-prod"
  location                 = "Brazil South"
  account_tier             = "Standard"
  account_replication_type = "LRS"

  min_tls_version = "TLS1_2"

  lifecycle {
    prevent_destroy = true
  }
}

O que esse código faz:
Cria a mesma Storage Account usando Terraform, incluindo controle operacional com lifecycle para evitar exclusão acidental.

✔ Mais controle
✔ State + lifecycle
✔ Multi-provider

Legenda:
Bicep simplifica o Azure. Terraform padroniza a operação.

⚠️ Recursos novos do Azure (sem mito)

✔ Bicep tem menor atrito com novidades
❗Terraform reduz bastante esse gap com o provedor AzAPI, que permite gerenciar qualquer tipo de recurso do Azure utilizando qualquer versão de API, mesmo antes do suporte oficial no provider azurerm.

👉 Tradução:

• Velocidade no Azure → Bicep
• Padronização multi-cloud → Terraform

🔄 Export e brownfield: um fator decisivo

Pouca gente começa do zero.

Bicep (vantagem de entrada)

No Azure, o portal permite exportar recursos diretamente em Bicep, além de ARM JSON que pode ser decompilado.

No lado Terraform, o caminho oficial é o Azure Export for Terraform, que gera código a partir de recursos existentes e permite iniciar o controle via state.

Na prática, ambos resolvem o problema — a diferença está na maturidade do fluxo e na estratégia de adoção.

• Export direto pelo portal
• Decompile de ARM para Bicep

az bicep decompile --file main.json

O que faz:
Converte ARM JSON para Bicep, facilitando começar em ambiente existente.

Terraform

• Azure Export for Terraform
• Gera HCL + state

Leitura prática

• Entrada rápida → Bicep
• Operação contínua → Terraform

🏗️ Coexistência: o modelo mais maduro

A melhor resposta em enterprise não é escolher uma só ferramenta.

É definir fronteiras claras.

Legenda:
Governança no topo. Ferramentas abaixo. Cada uma com seu papel.

Modelo recomendado

• Governança → Azure (Policy, MG, RBAC)
• Foundation → Bicep
• Workloads multi-cloud → Terraform
• Módulos → padrão comum (AVM)

Cenários reais (onde essa decisão aparece de verdade)

1. Plataforma corporativa Azure (banco, grande empresa)

Ambiente altamente padronizado, com forte uso de Azure Policy, landing zones e governança centralizada.
Bicep tende a vencer pela integração nativa, velocidade de suporte a novos recursos e simplicidade operacional.

2. Times de produto com estratégia multi-cloud

Times que precisam padronizar deploy entre Azure, AWS e GCP.
→ Terraform tende a vencer pela abstração e consistência entre clouds.

3. Ambiente brownfield com muitos recursos já existentes

Infra criada fora de IaC, necessidade de trazer para código.
→ Empate técnico, com vantagem prática dependendo da estratégia:
– Bicep: export nativo + decompile
– Terraform: Azure Export for Terraform + import

📦 O que são AVM (Azure Verified Modules)

AVM são módulos reutilizáveis oficiais/alinhados ao ecossistema Microsoft, disponíveis para:

• Bicep
• Terraform

👉 Por que isso importa?

Mesmo usando duas ferramentas diferentes, você mantém:

• padrão de naming
• segurança
• arquitetura consistente

👉 Ou seja: padroniza sem forçar uma única linguagem

Esse modelo se conecta diretamente com Azure Landing Zones, que recomendam o uso de módulos padronizados (AVM) como base para escala e governança, independentemente da ferramenta escolhida (Bicep ou Terraform).

🔒 Regra de ouro

Um recurso = uma única ferramenta gerenciando

Quebrou isso → conflito, drift e caos.

🚫 Anti-patterns

Evite:

• escolher ferramenta por hype
• misturar Bicep e Terraform no mesmo recurso
• ignorar governança
• usar Terraform sem necessidade
• usar Bicep em multi-cloud

🎯 Critérios finais de decisão

🧠 Conclusão

Bicep e Terraform não são concorrentes diretos.

Eles resolvem problemas diferentes.

A decisão correta não é técnica apenas. É organizacional.

💡 Pergunta final

Qual ferramenta acelera sua entrega sem reduzir sua governança?

Se você responder isso, já está à frente da maioria das decisões erradas em cloud.

E no seu cenário?

No seu contexto, o que pesa mais:
– velocidade Azure-native?
– padronização multi-cloud?
– ou governança centralizada?

Vale a pena refletir antes de escolher — porque a decisão errada aqui vira dívida operacional por anos.

📚 Referências

https://developer.hashicorp.com/terraform/language/backend/azurerm

https://learn.microsoft.com/pt-br/azure/developer/terraform/comparing-terraform-and-bicep

https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview

https://learn.microsoft.com/pt-br/azure/governance/policy/

https://learn.microsoft.com/en-us/community/content/azure-verified-modules