Bienvenidos a la era del cloud, ¿Qué desean? … entiendo: una cuenta para probar, 2 entornos de preproducción y una cuenta de producción. Serán 30 minutos y pagarán lo que vayan consumiendo.

Actualmente nos encontramos en un punto en el que las empresas se decantan cada vez más por la nube como lugar en el cual alojar sus soluciones y en consecuencia cada vez es mayor su necesidad de proveer un espacio donde desplegar las mismas. En el caso de AWS y cuando estamos hablando de cargas de trabajo diferentes (ya sea por el tipo de entorno o la funcionalidad del mismo), este espacio lo representa la entidad “cuenta”. Podrían alojarse múltiples proyectos en una misma cuenta, sin embargo, de acuerdo a una de las buenas prácticas de los pilares de arquitectura de AWS, la seguridad, lo ideal es aplicar el aislamiento por defecto, separando los recursos de los diferentes flujos de trabajo.

Vamos a partir del hecho de que nos hemos decantado por una estructura multi cuenta, lo siguiente que nos tenemos que plantear es: ¿Cuántas cuentas?. Realmente no hay una respuesta absoluta sobre el número de cuentas que debemos tener, sino más bien una serie de recomendaciones a tener en cuenta para realizar un correcto dimensionamiento. Lo que es indudable es que vamos a tener que crear cuentas de AWS, configurarlas y operarlas y todo esto sin perder de vista la agilidad. Un reto divertido, ¿No?. 

Vale, ya tenemos claro que vamos a tener que proporcionar un montón de cuentas y tenemos que asegurarnos de que estas cuentas estén configuradas correctamente y cumplan con las prácticas recomendadas por el WAF pero es que además todo esto luego tendremos que operarlo, y claro si gestionar, por ejemplo la autorización y autenticación de una de las cuentas ya es costoso imagínate escalar a 200 cuentas; pues extrapola esto a otros ámbitos de la cuenta, seguridad, redes, auditorías….

¿Ya estás agobiad@?, tranquil@ y vamos por partes, que esto tiene solución. 

Muchos de estos servicios que se han de configurar son susceptibles a configurarse y operarse de manera centralizada. A esta estructura de servicios y cuentas se le llama formalmente Landing Zone. 

Una Landing Zone es un ecosistema de cuentas y servicios que funcionan conjuntamente como punto de partida para desplegar de forma segura y escalable múltiples cargas de trabajo y aplicaciones con la seguridad de que las mismas cumplirán los patrones de diseño, prácticas y estándares definidos específicamente para nuestro negocio. Es importante tener en cuenta que, pese a que existen una serie de directrices que nos pueden guiar en cómo diseñar nuestras soluciones, no existe una respuesta holística, pues ni todos los casos de uso son iguales, ni todas las empresas tienen los mismos requisitos. En consecuencia, crear una Landing Zone es algo que implica analizar las necesidades de nuestro negocio y trasladar las mismas a decisiones técnicas sobre redes, seguridad, accesos, etc.

Es cierto que, independientemente de que tengamos que realizar un análisis para garantizar que este ecosistema puede suplir las necesidades de nuestros casos de uso, generalmente las Landing Zones suelen tener una estructura similar en cuanto a cuentas y servicios que proporcionan. Habitualmente las mismas cuentan con la siguiente arquitectura.

Como podemos observar en el diagrama el ecosistema está compuesto por diferentes cuentas, denominadas cuentas core o fundacionales, ¿Para qué sirven?.

Cuenta de Organización:

Esta es la cuenta maestra, desde donde, utilizando AWS Organizations, crearemos, organizaremos y aplicaremos políticas de control de servicios al resto de cuentas. Utilizar AWS Organizations también nos brinda la posibilidad de, en base a la clasificación que hagamos, mediante el uso de OUs, podamos identificar y administrar los costes de las cuentas que pertenezcan a este ecosistema. Otra de las funcionalidades que se ofrece desde esta cuenta es la gestión centralizada de la autenticación y autorización usando AWS SSO.

Servicios Asociados: AWS Organizations, AWS SSO, AWS Control Tower, AWS Billing

Cuenta de servicios compartidos:

La cuenta de servicios compartidos tiene como objetivo alojar aquellos servicios y aplicaciones centralizadas que los equipos de datos e ingeniería consumen para el funcionamiento de su producto. Por ejemplo, servicios de mensajería, bases de datos globales, servicios de integración continua transversales, etc.

Servicios Asociados: AWS AD, C.I./C.D.

Cuenta de auditoría:

El objetivo de la cuenta de auditoría es almacenar de forma segura, centralizada y aislada los registros (logs) creados por los diferentes servicios del ecosistema. 

Servicios Asociados: AWS CloudTrail, AWS Config, AWS S3 Object Logging

Cuenta de seguridad:

La cuenta de seguridad será la responsable de alojar los servicios para gestionar, auditar y operar la seguridad de las cuentas de producto de forma centralizada. A mayores es también la cuenta encargada de alojar los roles utilizados para realizar operaciones de seguridad y auditoría. Estos roles, denominados “breaking-glass”,

serán utilizados en caso de emergencia para actuar ante un incidente.

Servicios Asociados: AWS Guard Duty, AWS Security Hub

Cuenta de redes:

El propósito de esta cuenta es servir como punto único de operación de los servicios de conectividad transversales que, dependiendo de las necesidades y políticas de nuestra empresa, se encargará desde la resolución de DNS hasta la centralización de la operación y monitorización del tráfico este/oeste y norte/sur.

Servicios Asociados: AWS Transit Gateway, AWS Direct Connect, AWS VPC, AWS Route 53

Utilizando este ecosistema y configurando correctamente los servicios asociados podremos garantizar que las cuentas creadas bajo esta organización cuenten de base con las funcionalidades mencionadas anteriormente. ¿Es esto suficiente?

Como recordaréis antes hice hincapié en el hecho de que hay que no hay una solución holística y que tendremos que diseñar en base a las necesidades de nuestro negocio y generalmente esto implica también realizar otras configuraciones específicas que van más allá de las ya centralizadas por AWS. Llegados a este punto es importante definir estas configuraciones e implementarlas de base en todas aquellas cuentas que creemos, ¡un tema que trataremos en el siguiente capítulo!

Imagen: Freepik

Author

  • Cloud Architect en Keepler. "I am specialized in Cloud environments and DevOps culture. I have worked designing and implementing public and hybrid cloud ecosystems for several Ibex 35 companies."