Entendendo o erro DeploymentQuotaExceeded (800) em implantações Bicep e ARM

Entendendo o erro DeploymentQuotaExceeded (800) em implantações Bicep e ARM

TL;DR: O erro 'DeploymentQuotaExceeded' no Azure ocorre quando um único Resource Group atinge o limite histórico de 800 implantações. Este é um limite de metadados, não de recursos físicos. A falha interrompe pipelines CI/CD que realizam múltiplos deploys diários. A conclusão é que o histórico de implantação deve ser tratado como um componente de governança: implementar políticas de retenção e limpeza automatizada é essencial para evitar o bloqueio de esteiras de automação em escala.

Introdução

Ao trabalhar com Infrastructure as Code (IaC) via Azure Bicep ou templates ARM, falhas de deploy são uma realidade operacional comum. No entanto, em ambientes corporativos de alta cadência, o erro DeploymentQuotaExceeded frequentemente surge como um bloqueador silencioso que para pipelines de CI/CD sem uma causa óbvia no template.

Figura: Exemplo de falha de deployment Bicep após atingir o limite de 800 registros.

Copiar{
  "code": "DeploymentFailed",
  "details": [
    {
      "code": "DeploymentQuotaExceeded",
      "message": "Creating the deployment ... would exceed the quota of '800'."
    }
  ]
}

O que significa a cota 800?

O Azure impõe um limite rígido de 800 registros de histórico de implantação por Resource Group. É importante reforçar: isso não é um limite de recursos provisionados (VMs, VNets, ou Web Apps). É uma limitação de metadados mantida pelo ARM (Azure Resource Manager) para fins de auditoria, rastreabilidade e debug.

Por que isso afeta suas esteiras de CI/CD?

Em cenários de maturidade DevOps, onde pipelines disparados por GitOps ou integrações contínuas rodam dezenas de vezes ao dia — seja por validações de linting, mudanças incrementais ou deploys de prs — o limite de 800 registros é atingido surpreendentemente rápido. Se você utiliza o mesmo Resource Group para toda a persistência de deploy, sua automação irá quebrar assim que o limite for batido, bloqueando novas alterações.

Estratégias de Resolução e Governança

Não adianta apenas deletar o erro; é preciso implementar governança. Abaixo, as abordagens recomendadas:

1. Limpeza Automatizada (Obrigatória em escala): Crie um job de limpeza (via PowerShell ou GitHub Actions/Azure DevOps task) que monitore a quantidade de implantações por Resource Group e remova automaticamente os registros mais antigos se o total exceder uma margem de segurança (recomenda-se manter cerca de 100-200).

   Copiar$deployments = Get-AzResourceGroupDeployment -ResourceGroupName "seu-rg"
   if ($deployments.Count -gt 700) {
       $deployments | Sort-Object Timestamp | Select-Object -First 100 | Remove-AzResourceGroupDeployment
   }
   

2. Arquitetura por Escopo: Segmente ambientes (Dev, Staging, Prod) em diferentes Resource Groups. Isso não é apenas uma boa prática de segurança RBAC, mas também isola os limites de cota.
3. Naming Predictable: Utilize strings de data ou IDs únicos de commit nos nomes das implantações para facilitar a identificação e limpeza programática.

Resumo para Tomadores de Decisão

Área	Diagnóstico
Tipo de Erro	Limitação na cota de histórico (Metadata)
Limite	800 registros por Resource Group
Causa Primária	Alta frequência de CI/CD em um único agrupamento
Prevenção	Automação de limpeza e boa segmentação (IaC)

O histórico de implantação do Azure deve ser tratado como um recurso a ser monitorado. Deixar a cota atingir o teto de 800 por falta de governança é um erro operacional que, embora simples, impacta diretamente a disponibilidade de suas entregas contínuas.

Perguntas Frequentes

• O erro 'DeploymentQuotaExceeded' significa que estou sem capacidade de infraestrutura?
  Não. Este erro é uma limitação de metadados, especificamente no histórico de registros de implantação do Azure Resource Manager (ARM), e não afeta a capacidade ou o provisionamento de recursos de computação, rede ou storage.

• Como posso limpar o histórico de implantações para liberar espaço?
  Você pode excluir registros manualmente via Portal do Azure (na aba 'Deployments' do Resource Group) ou automatizar a exclusão usando Azure CLI ou scripts PowerShell, removendo as implantações mais antigas quando o contador se aproximar do limite de 800.

• A melhor prática é segmentar por Resource Group?
  Sim. Distribuir recursos em múltiplos Resource Groups — por ambiente (Dev, Test, Prod) ou por propósito — ajuda a evitar que uma única cota de 800 registros se torne um gargalo em seus processos de CI/CD.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.