Como separar ambientes (dev, staging e produção) na AWS

Por que separar ambientes#

Um ambiente é um espaço isolado onde você faz o deploy de uma versão do seu sistema com um propósito específico: desenvolvimento, testes, staging ou produção. Separá-los permite testar mudanças sem colocar os usuários em risco, dar permissões diferentes para cada etapa e saber quanto custa cada uma.

Muitas plataformas de deploy modelam o ambiente como a soma de três decisões: uma conta ou credenciais de nuvem, uma região e um domínio, e ao criá-lo provisionam uma rede própria (uma VPC com várias sub-redes). A mesma ideia vale se você montar tudo diretamente na AWS.

A pergunta importante não é se separar, e sim onde colocar o limite: em contas diferentes, em VPCs diferentes dentro de uma conta ou só em nomes e tags. Este guia explica o que cada opção isola e como organizar nomes, configuração, segredos e promoção entre ambientes.

Contas separadas ou VPCs separadas#

A AWS recomenda fortemente separar ambientes no nível da conta. O pilar de segurança do Well-Architected Framework descreve isso como um limite de isolamento forte para segurança, faturamento e acesso. Uma VPC, por outro lado, isola a rede, mas dentro da mesma conta IAM, as cotas de serviço e a fatura são compartilhados.

Para um protótipo, uma única conta com VPCs separadas pode bastar. A partir do momento em que existem dados reais de clientes, o sensato é produção ficar em uma conta própria.

Documentação: AWS Well-Architected · SEC01-BP01 ↗ · AWS · Benefícios de usar várias contas ↗ · AWS · O que é Amazon VPC ↗

Organizar contas com OUs e guardrails#

O AWS Organizations agrupa contas em unidades organizacionais (OUs). O whitepaper da AWS sobre ambientes multiconta propõe, entre outras, uma OU Workloads que reúne as contas das cargas de trabalho do negócio, tanto de produção quanto de não produção, e uma OU Sandbox para experimentação com acesso limitado à produção.

Sobre as OUs você aplica service control policies (SCPs): limites máximos de permissão que nenhuma identidade dessas contas pode ultrapassar, por exemplo proibir a desativação do log de auditoria ou restringir as regiões permitidas. Se não quiser montar isso na mão, o AWS Control Tower configura uma landing zone multiconta com esses controles.

• Workloads / Prod: contas de produção, com acesso humano mínimo.
• Workloads / Não produção: dev e staging, com mais liberdade, mas com os mesmos guardrails básicos.
• Sandbox: experimentos pessoais ou do time, sem conexão com dados de produção.

Para se aprofundar: Qual é a melhor estrutura organizacional para sua conta AWS?

Documentação: AWS · OUs e contas recomendadas ↗ · AWS Organizations · SCPs ↗ · AWS Control Tower ↗

Um só código, um state por ambiente#

Os ambientes só são comparáveis se forem criados com o mesmo código. A prática comum com Terraform ou OpenTofu é ter uma configuração compartilhada, um arquivo de variáveis por ambiente e um backend de state diferente para cada um, com credenciais próprias.

# providers.tf: a mesma configuração serve para todos os ambientes
variable "environment" { type = string }   # dev | staging | prod
variable "account_id"  { type = string }   # uma conta AWS por ambiente
variable "region"      { type = string }

provider "aws" {
  region = var.region

  # O Terraform entra na conta do ambiente assumindo uma role de deploy
  assume_role {
    role_arn = "arn:aws:iam::${var.account_id}:role/deploy"
  }

  # Todos os resources ficam com a tag do seu ambiente
  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
    }
  }
}

# Uso: um arquivo de variáveis e um backend (state) por ambiente
#   terraform init  -backend-config=envs/prod.backend.hcl
#   terraform apply -var-file=envs/prod.tfvars

A HashiCorp alerta que os workspaces da CLI compartilham o mesmo backend e não são um isolamento adequado quando cada deploy precisa de credenciais e controles de acesso diferentes. Para dev e produção em contas separadas, use backends separados.

Para se aprofundar: OpenTofu vs Terraform: quando migrar sem quebrar a infraestrutura

Documentação: Terraform · Workspaces ↗ · Terraform · Configuração de backend ↗ · Terraform · Provider da AWS ↗

Rede, nomes e domínios#

• Dê a cada ambiente a sua própria VPC e reserve faixas CIDR que não se sobreponham: se um dia você precisar conectá-las com VPC peering, a AWS não permite peering entre VPCs com faixas iguais ou sobrepostas.
• Use um domínio ou subdomínio por ambiente, por exemplo dev.seudominio.com, staging.seudominio.com e app.seudominio.com. Assim nenhum ambiente compartilha certificados nem registros DNS com outro.
• Defina uma convenção de nomes curta e estável (dev, stg, prd) e use-a em contas, recursos e aliases.
• Coloque tags em tudo com pelo menos Environment e Owner; as tags permitem filtrar custos e aplicar políticas.

Documentação: AWS · VPC peering e CIDRs sobrepostos ↗ · AWS · Boas práticas de tagging ↗

Configuração e segredos por ambiente#

O código e o artefato devem ser idênticos em todos os ambientes; o que muda é a configuração. Guarde os parâmetros em uma hierarquia por ambiente no AWS Systems Manager Parameter Store e as credenciais no AWS Secrets Manager, que também permite fazer a rotação delas.

# Mesma hierarquia, prefixo diferente por ambiente
#   /miapp/dev/DATABASE_URL      /miapp/prod/DATABASE_URL
#   /miapp/dev/FEATURE_FLAGS     /miapp/prod/FEATURE_FLAGS
aws ssm get-parameters-by-path \
  --path /miapp/prod/ \
  --with-decryption \
  --query 'Parameters[].Name'

Nunca copie segredos de produção para dev para depurar. Se precisar de dados realistas, gere dados sintéticos ou anonimizados.

Para se aprofundar: Variáveis de ambiente e DATABASE_URL em produção: guia completo

Documentação: Parameter Store · Hierarquias ↗ · AWS CLI · get-parameters-by-path ↗ · AWS Secrets Manager ↗

Promover mudanças entre ambientes#

Faça o build uma vez e promova o mesmo artefato: a mesma imagem de contêiner (de preferência referenciada por digest) ou o mesmo pacote passa de dev para staging e de staging para produção. Se você recompilar a cada etapa, o que foi testado não é exatamente o que vai para o ar.

No GitHub Actions, os environments permitem associar segredos e regras de proteção a cada ambiente, como revisores obrigatórios ou branches permitidas. Lembre que, nos planos Free, Pro e Team, essas regras (revisores, timers) só estão disponíveis em repositórios públicos. Combinado com OIDC, a role AWS de produção pode aceitar apenas tokens emitidos para o environment prod.

Documentação: GitHub · Environments para deploys ↗ · GitHub · OIDC com AWS ↗

Checklist#

• Produção em uma conta AWS própria, dentro de uma OU com guardrails.
• Mesmo código de infraestrutura; um arquivo de variáveis e um state por ambiente.
• CIDRs sem sobreposição e um domínio ou subdomínio por ambiente.
• Parâmetros e segredos separados por ambiente, nunca copiados de produção.
• Um único artefato promovido entre ambientes, com aprovação antes de produção.