Diseño de separación de entornos en AWS

Desarrollo, staging y producción no deberían diferir solo porque sus recursos contienen -dev o -prod en el nombre. La separación de entornos se trata principalmente de limitar el radio de impacto (blast radius), controlar el acceso y dificultar que la actividad de no producción afecte a producción.

Un diseño práctico en AWS usa las cuentas como límite principal de aislamiento, y luego agrega controles consistentes de infraestructura, identidad, redes y despliegue alrededor de ellas.

Empieza por cuentas, no solo por VPCs

Una arquitectura común en etapas tempranas coloca todo en una sola cuenta de AWS:

Cuenta de AWS
├── dev-vpc
├── staging-vpc
└── prod-vpc

Esto es simple, pero la cuenta sigue siendo un límite administrativo y de seguridad compartido.

Un permiso IAM demasiado amplio, un despliegue incorrecto de infraestructura, un problema de cuota de servicio o un error del operador pueden potencialmente cruzar los límites entre entornos.

Un modelo más sólido es:

Organización de AWS
├── Security
│   ├── Log Archive
│   └── Audit
│
├── Non-Production
│   ├── Cuenta de Desarrollo
│   └── Cuenta de Staging
│
└── Production
    └── Cuenta de Producción

AWS recomienda la separación a nivel de cuenta como un límite de aislamiento sólido para cargas de trabajo y entornos. Las cargas de trabajo de producción y de no producción normalmente deberían separarse en lugar de colocarse juntas en una sola cuenta.

El límite de cuenta también facilita razonar sobre políticas de acceso, atribución de facturación, cuotas de servicio y contención de incidentes.

Un patrón práctico de separación de entornos

Para muchos equipos, el siguiente enfoque es suficiente sin necesidad de crear decenas de cuentas.

1. Coloca las cuentas bajo AWS Organizations

Usa AWS Organizations para gestionar las cuentas de forma centralizada.

Agrúpalas en Unidades Organizativas (OUs) según los controles que requieran. Una OU es un grupo lógico de cuentas de AWS al que se le pueden aplicar políticas organizativas.

Un buen punto de partida es:

Security OU
NonProduction OU
Production OU

AWS Control Tower puede ofrecer un modelo de landing zone gestionado sobre AWS Organizations, incluyendo aprovisionamiento estandarizado de cuentas y controles de gobernanza.

2. Centraliza el acceso humano

Evita crear usuarios IAM de larga duración separados dentro de cada entorno.

En su lugar, usa federación centralizada, comúnmente a través de AWS IAM Identity Center, y asigna conjuntos de permisos según el entorno.

Por ejemplo:

Rol	Desarrollo	Staging	Producción
Desarrollador	Tipo admin	Lectura/escritura	Solo lectura
QA	Lectura	Lectura/escritura	Solo lectura
Ingeniero de plataforma	Admin	Admin	Admin controlado
CI/CD	Deploy	Deploy	Deploy a través de pipeline

El acceso a producción debería ser deliberadamente más difícil que el acceso a desarrollo.

Esa fricción es útil.

3. Despliega la misma definición de infraestructura

La separación de entornos no debería significar mantener tres arquitecturas sin relación entre sí.

Define la infraestructura con AWS CDK, CloudFormation, Terraform u otra herramienta de Infrastructure as Code, y parametriza las diferencias:

ApplicationStack
   ↓
configuración dev
configuración staging
configuración prod

Mantén las diferencias arquitectónicas intencionales.

Los tamaños de instancia, límites de escalado, períodos de retención o la capacidad de la base de datos pueden diferir. La topología central debería mantenerse lo suficientemente comparable como para que staging brinde una validación significativa.

4. Separa los datos por completo

No permitas que las aplicaciones de desarrollo se conecten casualmente a bases de datos de producción.

Cada entorno debería tener sus propios:

• bases de datos;
• buckets de S3;
• colas y tópicos;
• secretos;
• configuración de cifrado;
• credenciales de aplicación.

Si los datos de producción deben copiarse a un entorno inferior, define un proceso de sanitización explícito en lugar de tratar la clonación de bases de datos como algo rutinario.

5. Promueve artefactos en lugar de reconstruirlos

Un flujo de entrega útil es:

Commit
  ↓
Build
  ↓
Test
  ↓
Deploy Dev
  ↓
Deploy Staging
  ↓
Aprobación
  ↓
Deploy Producción

Idealmente, el artefacto de la aplicación validado en staging es el mismo artefacto promovido a producción.

Evita construir un nuevo binario de producción a partir del mismo código fuente después de la validación en staging. Eso introduce otra variable entre lo que se probó y lo que se lanzó.

Ejemplo: una aplicación SaaS serverless

Considera una plataforma SaaS que usa API Gateway, Lambda, DynamoDB, SQS y S3.

En lugar de crear recursos como:

orders-dev
orders-staging
orders-prod

dentro de una sola cuenta de AWS, crea tres cuentas de carga de trabajo.

El equipo de desarrollo puede experimentar libremente en la cuenta de desarrollo. Staging recibe despliegues controlados usando infraestructura similar a la de producción. Producción permite cambios de aplicación principalmente a través de CI/CD.

Las cuentas centralizadas de logging y seguridad pueden recibir información de auditoría y seguridad de todos los entornos. AWS recomienda específicamente el logging centralizado entre cuentas, y AWS Control Tower ofrece patrones dedicados de cuentas de log archive y audit para este propósito.

Un despliegue defectuoso en desarrollo es, por lo tanto, mucho menos probable que afecte a los recursos de producción.

Trade-offs y errores comunes

Una arquitectura multi-cuenta agrega trabajo operativo.

Necesitas roles de despliegue entre cuentas, autenticación centralizada, aprovisionamiento de cuentas, logging, decisiones de DNS, redes y gestión de costos.

Eso no significa que cada desarrollador necesite una cuenta de AWS individual.

El objetivo es un aislamiento significativo, no la cantidad máxima de cuentas.

Otro error es permitir conectividad permanente en todas partes:

Dev ↔ Staging ↔ Producción

Una vez que cada VPC puede alcanzar a todas las demás y los ingenieros tienen permisos equivalentes en todas partes, gran parte del beneficio del aislamiento desaparece.

Finalmente, no hagas que staging sea fundamentalmente distinto de producción. Un entorno de staging que usa mecanismos de despliegue, patrones de red, autenticación o tecnologías de persistencia diferentes brinda evidencia limitada de que un release de producción se comportará correctamente.

Un marco de decisión simple

Para cada entorno, pregunta:

1. ¿Un error aquí podría afectar a producción?
2. ¿Este entorno necesita permisos de acceso distintos?
3. ¿Sus cuotas de servicio y costos deberían estar aislados?
4. ¿Contiene datos con requisitos de seguridad distintos?
5. ¿Los despliegues deberían requerir controles distintos?

Si varias respuestas son sí, el entorno probablemente pertenece a una cuenta de AWS separada.

Conclusión

Para la mayoría de las cargas de trabajo serias en AWS, la separación de entornos debería comenzar por los límites de cuenta, no por convenciones de nomenclatura de recursos. Usa AWS Organizations para la gobernanza, identidad centralizada para el acceso, Infrastructure as Code para la consistencia y pipelines controlados para la promoción.

Un siguiente paso útil es dibujar tu camino actual de desarrollo a producción e identificar cada lugar donde credenciales, redes, datos o permisos de despliegue actualmente cruzan los límites entre entornos.