Separar ambientes (dev, staging, producción) en AWS

Por qué separar ambientes#

Un ambiente es un espacio aislado donde despliegas una versión de tu sistema para un propósito concreto: desarrollo, pruebas, staging o producción. Separarlos permite probar cambios sin arriesgar a los usuarios, dar permisos distintos a cada etapa y saber cuánto cuesta cada una.

Muchas plataformas de despliegue modelan el ambiente como la unión de tres decisiones: una cuenta o credenciales de nube, una región y un dominio, y al crearlo aprovisionan una red propia (una VPC con varias subredes). Esa misma idea sirve si lo construyes tú directamente en AWS.

La pregunta importante no es si separar, sino dónde poner el límite: en cuentas distintas, en VPCs distintas dentro de una cuenta, o solo en nombres y etiquetas. Esta guía explica qué aísla cada opción y cómo organizar nombres, configuración, secretos y promoción entre ambientes.

Cuentas separadas o VPCs separadas#

AWS recomienda con fuerza separar ambientes a nivel de cuenta. El pilar de seguridad del Well-Architected Framework lo describe como un límite de aislamiento fuerte para seguridad, facturación y acceso. Una VPC, en cambio, aísla la red, pero dentro de la misma cuenta se comparten IAM, las cuotas de servicio y la factura.

Para un prototipo, una sola cuenta con VPCs separadas puede bastar. En cuanto hay datos reales de clientes, lo sensato es que producción viva en su propia cuenta.

Documentación: AWS Well-Architected · SEC01-BP01 ↗ · AWS · Beneficios de usar varias cuentas ↗ · AWS · Qué es Amazon VPC ↗

Organizar cuentas con OUs y guardrails#

AWS Organizations agrupa cuentas en unidades organizativas (OUs). El whitepaper de AWS sobre entornos multicuenta propone, entre otras, una OU Workloads que agrupa las cuentas de las cargas del negocio, tanto de producción como de no producción, y una OU Sandbox para experimentación con acceso limitado a producción.

Sobre las OUs aplicas service control policies (SCPs): límites máximos de permisos que ninguna identidad de esas cuentas puede superar, por ejemplo prohibir desactivar el registro de auditoría o restringir las regiones permitidas. Si no quieres montarlo a mano, AWS Control Tower configura una landing zone multicuenta con estos controles.

• Workloads / Prod: cuentas de producción, con acceso humano mínimo.
• Workloads / No producción: dev y staging, con más libertad pero los mismos guardrails básicos.
• Sandbox: experimentos personales o de equipo, sin conexión con datos de producción.

Documentación: AWS · OUs y cuentas recomendadas ↗ · AWS Organizations · SCPs ↗ · AWS Control Tower ↗

Un solo código, un estado por ambiente#

Los ambientes solo son comparables si se crean con el mismo código. La práctica habitual con Terraform u OpenTofu es una configuración compartida, un archivo de variables por ambiente y un backend de estado distinto para cada uno, con credenciales propias.

# providers.tf: la misma configuración sirve para todos los ambientes
variable "environment" { type = string }   # dev | staging | prod
variable "account_id"  { type = string }   # una cuenta de AWS por ambiente
variable "region"      { type = string }

provider "aws" {
  region = var.region

  # Terraform entra en la cuenta del ambiente asumiendo un rol de despliegue
  assume_role {
    role_arn = "arn:aws:iam::${var.account_id}:role/deploy"
  }

  # Todas las resources quedan etiquetadas con su ambiente
  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
    }
  }
}

# Uso: un archivo de variables y un backend (estado) por ambiente
#   terraform init  -backend-config=envs/prod.backend.hcl
#   terraform apply -var-file=envs/prod.tfvars

HashiCorp advierte que los workspaces de la CLI comparten el mismo backend y no son un aislamiento adecuado cuando cada despliegue necesita credenciales y controles de acceso distintos. Para dev y producción en cuentas separadas, usa backends separados.

Documentación: Terraform · Workspaces ↗ · Terraform · Configuración de backend ↗ · Terraform · Provider de AWS ↗

Red, nombres y dominios#

• Da a cada ambiente su propia VPC y reserva rangos CIDR que no se solapen: si algún día necesitas conectarlas con VPC peering, AWS no permite peering entre VPCs con rangos coincidentes o solapados.
• Usa un dominio o subdominio por ambiente, por ejemplo dev.tudominio.com, staging.tudominio.com y app.tudominio.com. Así ningún ambiente comparte certificados ni registros DNS con otro.
• Define una convención de nombres corta y estable (dev, stg, prd) y úsala en cuentas, recursos y alias.
• Etiqueta todo con al menos Environment y Owner; las etiquetas permiten filtrar costos y aplicar políticas.

Documentación: AWS · VPC peering y CIDR solapados ↗ · AWS · Buenas prácticas de etiquetado ↗

Configuración y secretos por ambiente#

El código y el artefacto deben ser idénticos en todos los ambientes; lo que cambia es la configuración. Guarda los parámetros en una jerarquía por ambiente en AWS Systems Manager Parameter Store y las credenciales en AWS Secrets Manager, que además permite rotarlas.

# Misma jerarquía, distinto prefijo 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 copies secretos de producción a dev para depurar. Si necesitas datos realistas, genera datos sintéticos o anonimizados.

Documentación: Parameter Store · Jerarquías ↗ · AWS CLI · get-parameters-by-path ↗ · AWS Secrets Manager ↗

Promover cambios entre ambientes#

Construye una vez y promueve el mismo artefacto: la misma imagen de contenedor (idealmente referenciada por digest) o el mismo paquete pasa de dev a staging y de staging a producción. Si recompilas en cada paso, lo que probaste no es exactamente lo que publicas.

En GitHub Actions, los environments permiten asociar secretos y reglas de protección a cada ambiente, como revisores obligatorios o ramas permitidas. Ten en cuenta que en planes Free, Pro y Team esas reglas (revisores, temporizadores) solo están disponibles en repositorios públicos. Combinados con OIDC, el rol de AWS de producción puede aceptar únicamente tokens emitidos para el environment prod.

Documentación: GitHub · Environments para despliegues ↗ · GitHub · OIDC con AWS ↗

Checklist#

• Producción en su propia cuenta de AWS, dentro de una OU con guardrails.
• Mismo código de infraestructura; un archivo de variables y un estado por ambiente.
• CIDRs sin solapamiento y un dominio o subdominio por ambiente.
• Parámetros y secretos separados por ambiente, nunca copiados desde producción.
• Un solo artefacto promovido entre ambientes, con aprobación antes de producción.