Arquitectura Multi-Account en AWS: ¿Por dónde empezar y por qué es importante?
Diseñar una arquitectura en AWS va más allá de desplegar servicios. Descubre por qué separar las cargas de trabajo en múltiples cuentas mejora la seguridad, la gobernanza y la escalabilidad, y cómo AWS Organizations y Control Tower ayudan a construir una base sólida para entornos empresariales.
Arquitectura Multi-Account en AWS: ¿Por dónde empezar y por qué es importante?
Cuando comenzamos a trabajar con Amazon Web Services (AWS), es común utilizar una sola cuenta para desplegar nuestros primeros recursos.
Creamos una VPC, lanzamos algunas instancias EC2, configuramos bases de datos y comenzamos a desplegar nuestras aplicaciones.
Durante las primeras etapas, este enfoque suele ser suficiente.
Sin embargo, conforme la infraestructura crece y nuestros sistemas comienzan a atender diferentes necesidades de negocio, aparecen nuevos desafíos.
¿Cómo separamos los ambientes de desarrollo, pruebas y producción?
¿Cómo garantizamos que un cambio en desarrollo no afecte a producción?
¿Cómo administramos los permisos de diferentes equipos?
¿Cómo centralizamos la seguridad sin perder flexibilidad?
Aquí es donde una arquitectura Multi-Account en AWS comienza a tener sentido.
1. ¿Qué es una arquitectura Multi-Account?
Una arquitectura Multi-Account consiste en distribuir nuestras cargas de trabajo entre diferentes cuentas de AWS, en lugar de concentrar todos los recursos en una sola.
Cada cuenta funciona como un límite de aislamiento para recursos, permisos, cuotas y determinados controles de seguridad.
Por ejemplo, podemos utilizar cuentas independientes para:
- Desarrollo (DEV).
- Pruebas (QA).
- Demostraciones (DEMO).
- Producción (PROD).
- Servicios de red (NETWORK).
- Herramientas DevOps.
- Seguridad y auditoría.
Esto nos permite organizar la infraestructura de forma más clara y establecer controles específicos según las necesidades de cada ambiente.
2. ¿Por qué no utilizar una sola cuenta AWS?
Imaginemos una organización que administra desarrollo, pruebas y producción dentro de una misma cuenta.
Aunque podemos separar recursos utilizando VPC, etiquetas y políticas IAM, continuamos compartiendo ciertos límites administrativos.
Esto puede generar desafíos importantes.
Seguridad
Una configuración incorrecta de permisos podría permitir que un usuario o servicio tenga acceso a recursos que no debería administrar.
Separar ambientes en cuentas independientes permite establecer límites más sólidos.
Aislamiento de recursos
Una modificación accidental sobre un recurso compartido podría afectar diferentes ambientes.
Con múltiples cuentas podemos reducir el alcance de determinados errores operativos.
Administración de costos
Cuando todos los recursos están dentro de una cuenta, necesitamos estrategias adicionales para identificar qué ambiente o equipo genera determinados gastos.
Las cuentas independientes permiten analizar los costos por cuenta, aunque sigue siendo recomendable utilizar etiquetas y herramientas de administración financiera.
Gobernanza
Conforme aumenta el número de equipos y aplicaciones, mantener configuraciones consistentes se vuelve más complejo.
Una arquitectura multicuenta permite establecer políticas y controles organizacionales.
3. AWS Organizations: la base de nuestra arquitectura
AWS Organizations permite administrar múltiples cuentas AWS desde una estructura organizacional centralizada.
Uno de sus principales componentes son las Organizational Units (OU).
Una OU permite agrupar cuentas para organizar su administración y aplicar políticas.
Por ejemplo, podríamos utilizar una estructura como la siguiente:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
AWS Organization
│
├── Management Account
│
├── Security OU
│ ├── Log Archive
│ └── Audit
│
├── Infrastructure OU
│ ├── Network
│ └── DevOps
│
├── Workloads-NonProd OU
│ ├── Development
│ ├── QA
│ └── Demo
│
└── Workloads-Prod OU
└── ProductionEsta estructura es ilustrativa y puede adaptarse a los requerimientos de cada organización.
Lo importante es comprender que no existe una única estructura de cuentas válida para todas las empresas.
Debemos considerar factores como seguridad, operación, conectividad, cumplimiento y crecimiento futuro.
4. AWS Control Tower: estableciendo nuestra Landing Zone
Una vez definida nuestra estrategia de cuentas, necesitamos establecer una base que nos permita administrarlas.
Aquí entra AWS Control Tower.
Este servicio facilita la configuración y gobernanza de un entorno multicuenta mediante una Landing Zone.
Una Landing Zone es un entorno AWS preparado para alojar diferentes cargas de trabajo bajo una estructura organizacional y controles definidos.
AWS Control Tower permite apoyarnos en servicios como:
AWS Organizations: administración de cuentas y unidades organizacionales.
AWS IAM Identity Center: acceso centralizado a cuentas y asignación de permisos.
AWS CloudTrail: registro de actividades y llamadas a las API de AWS.
AWS Config: seguimiento de configuraciones de recursos y evaluación de determinadas reglas de cumplimiento.
AWS Control Tower Controls: controles preventivos, detectivos y proactivos, según su disponibilidad y compatibilidad.
La composición concreta de la Landing Zone depende de las integraciones seleccionadas y de la versión de AWS Control Tower utilizada.
En versiones recientes, como Landing Zone 4.0, existe mayor flexibilidad para definir la estructura organizacional y las cuentas utilizadas por distintas integraciones. AWS Documentation
5. Separar cuentas no significa perder conectividad
Una de las preguntas más comunes cuando comenzamos a diseñar una arquitectura multicuenta es:
¿Cómo se comunicarán nuestras aplicaciones si están en cuentas diferentes?
Es importante entender que el aislamiento administrativo no significa que nuestras aplicaciones deban permanecer completamente desconectadas.
AWS ofrece diferentes alternativas para establecer comunicación entre redes.
Por ejemplo:
- AWS Transit Gateway.
- VPC Peering.
- AWS PrivateLink.
- Conectividad híbrida mediante VPN.
- AWS Direct Connect.
La elección dependerá de los requerimientos de conectividad, seguridad, escalabilidad y costos.
En arquitecturas empresariales con múltiples redes, AWS Transit Gateway puede ayudarnos a construir un modelo de conectividad centralizada.
Sin embargo, adoptar una arquitectura multicuenta no implica que siempre necesitemos implementar un Transit Gateway.
6. Buenas prácticas al comenzar
Antes de implementar una arquitectura multicuenta, recomiendo considerar algunos aspectos.
Diseñar antes de desplegar.
Definir las cuentas necesarias, las unidades organizacionales y las responsabilidades de cada equipo.
Separar producción de ambientes no productivos.
Esto permite establecer controles de acceso y operación diferenciados.
Centralizar identidad y accesos.
Evitar la administración innecesaria de usuarios individuales en cada cuenta y favorecer el uso de identidades federadas y permisos temporales.
Establecer una estrategia de registros y auditoría.
Definir qué eventos necesitamos registrar, dónde se almacenarán y quién podrá consultarlos.
Diseñar la conectividad desde el inicio.
Planificar direccionamiento IP, conectividad entre redes, resolución DNS y necesidades de acceso a Internet.
Considerar los costos operativos.
Una arquitectura multicuenta mejora la organización, pero los servicios adicionales de seguridad, conectividad y monitoreo también generan costos que debemos evaluar.
7. Una reflexión desde DevOps y SRE
Cuando trabajamos en operaciones, automatización o confiabilidad, muchas veces nos concentramos en resolver necesidades inmediatas.
Necesitamos desplegar una aplicación, habilitar una conexión, configurar permisos o implementar un nuevo servicio.
Sin embargo, conforme nuestras plataformas crecen, resulta cada vez más importante pensar en la arquitectura que sostiene estas operaciones.
Una buena estrategia multicuenta no elimina los incidentes ni los errores humanos.
Pero sí puede ayudarnos a reducir su alcance, establecer responsabilidades y construir una infraestructura más fácil de administrar.
Desde mi perspectiva, una arquitectura Cloud debe diseñarse pensando no solamente en cómo desplegar los recursos, sino también en cómo operarlos, protegerlos y escalarlos a largo plazo.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article