State do Terraform é o banco de dados de produção que poucas equipes tratam como tal

Um post recente na DEV Community reacende um ponto que arquitetos AWS conhecem bem: o state do Terraform guarda o mapa exato da infraestrutura e, sem remote backend, lock e verificação de drift, vira o ponto cego que detona o próximo incidente.

Um post da desenvolvedora Frida Hansen na DEV Community, no canal #aws, resume em poucas linhas um problema que todo time que opera infraestrutura como código na AWS já sentiu na pele: o state do Terraform é tratado como um arquivo de apoio, quando na prática é o banco de dados que descreve o estado real da sua conta. Ela lista um baseline mínimo que recusa abrir mão: remote state com lock, um state por ambiente, caminho de import sem edição manual e verificação de drift em agenda fixa, não quando alguém percebe.

Para quem desenha e opera contas AWS em produção, o recorte importa mais do que parece. O terraform.tfstate guarda o ID de cada recurso, atributos completos e, em muitos casos, segredos em texto puro. Perder esse arquivo, corrompê-lo ou deixar dois processos escreverem nele ao mesmo tempo não é um bug cosmético: é a diferença entre um terraform apply previsível e um apply que decide recriar um banco RDS de produção porque achou que ele não existe mais.

Remote state com lock não é opcional em produção

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

A recomendação da fonte, S3 para armazenar o state e DynamoDB para o lock, é o padrão mais usado em ambientes AWS há anos, e por um motivo simples: sem lock, dois terraform apply concorrentes correm em cima do mesmo arquivo e corrompem o plano de execução. O DynamoDB resolve isso coordenando o lock entre os processos, garantindo que apenas um apply rode por vez contra o mesmo state.

Em região sa-east-1, o bucket de state deve ter versionamento e criptografia ligados por padrão, e o acesso restrito por política de bucket e IAM, não por convenção de equipe:

terraform {
  backend "s3" {
    bucket         = "minha-empresa-tfstate-prod-sa-east-1"
    key            = "env/prod/terraform.tfstate"
    region         = "sa-east-1"
    dynamodb_table = "minha-empresa-tfstate-lock-prod"
    encrypt        = true
    kms_key_id     = "arn:aws:kms:sa-east-1:111122223333:key/abcd-1234"
  }
}

Um state por ambiente, não workspaces fingindo isolamento

O segundo ponto do baseline é incômodo para quem cresceu usando terraform workspace para separar dev, staging e produção. Workspaces não entregam o isolamento real que a separação de ambientes exige: na prática, um erro de terraform workspace select pode acabar aplicando o plano do ambiente errado contra o state do ambiente certo.

A alternativa mais segura, e mais verbosa, é um diretório (ou um módulo raiz) por ambiente, cada um com seu próprio bloco backend apontando para uma key distinta no S3. Fica mais código para manter, mas o erro humano mais comum, aplicar staging em cima de produção, deixa de ser possível por desenho: o Terraform simplesmente não enxerga o outro state a partir do contexto errado.

O incidente que se repete: import na state errada

A parte mais dura do relato é o cenário de falha descrito por quem escreveu o post: alguém importa um recurso para o state errado, e o próximo terraform plan detecta ausência daquele recurso onde deveria estar, propondo recriação. Em produção, recriar significa destruir e recriar: um banco de dados, uma fila SQS, um load balancer.

Não é glamoroso, mas o state é o sistema. Trate-o como um banco de dados: faça backup, bloqueie, revise as mudanças nele.

It's not glamorous, but the state is the system. Treat it like a database: back it up, lock it, review changes to it.Frida Hansen, autora do post no DEV Community

O ponto prático para quem opera a conta: locking protege contra escrita concorrente no mesmo arquivo, mas não protege contra importar o recurso certo no state errado. Esse erro só se evita com processo: terraform import sempre revisado em pull request, com terraform plan rodado antes e depois para comparar o diff, e preferência por terraform state mv dentro do mesmo backend em vez de reimportar manualmente quando o recurso já existe em outro state.

Segredos em texto puro dentro do state

O Terraform guarda no state o valor de todo atributo que o provider retorna, incluindo senhas geradas, chaves de API e tokens. Como a própria fonte alerta, o state pode conter segredos em texto puro, independentemente de boas práticas aplicadas no código que o gerou.

Isso torna o bucket S3 que guarda o state um alvo tão sensível quanto um cofre de segredos. O mínimo aceitável para esse bucket:

• Criptografia em repouso com KMS, chave gerenciada pelo cliente, não a chave padrão do S3
• Bloqueio de acesso público (block_public_access) habilitado na conta inteira, não só no bucket
• Política de bucket restrita por role ou usuário, sem Principal: "*"
• Versionamento ligado, para permitir rollback de um state corrompido

Drift detection em agenda, não por acaso

O último item do baseline é o que mais costuma faltar: rodar verificações de plano em um pipeline agendado, não só quando alguém decide investigar. Diferenças entre o state e a infraestrutura real normalmente aparecem quando alguém muda um recurso pelo console ou pela CLI, fora do fluxo de IaC.

Um job noturno em CodeBuild, GitHub Actions ou GitLab CI, rodando o plan contra cada ambiente e publicando o resultado num canal (SNS, Slack, o que o time já usa), transforma drift de "descoberta por acidente durante um incidente" em "alerta de rotina". Para contas com múltiplas equipes mexendo nos mesmos recursos via console, essa checagem agendada é a diferença entre corrigir o drift em dez minutos ou descobri-lo no meio de um post-mortem.

Onde esse rigor não compensa

Nem todo ambiente pede o baseline inteiro. Um protótipo de fim de semana, uma stack de sandbox que qualquer um destrói ao fim do dia, não justifica DynamoDB, bucket com KMS dedicado e pipeline de drift detection: o custo operacional de manter isso supera o risco de perder um state que não importa. O critério que decide é simples: se o recurso por trás do state afeta algum usuário real, o state merece o mesmo tratamento que o banco de dados de produção que ele descreve.

Fonte: DEV Community — #aws