Building an AWS landing zone

Año nuevo vida nueva. Si tanto los artículos del 2020 como los del 2021 estuvieron principalmente centrados en analizar las capacidades de las bases de datos distribuidas más populares del mercado, ha llegado el momento de dar un brusco giro de 180 grados y ceder el testigo a AWS y su landing zone.

La premisa es sencilla, un primer artículo a modo de introducción al tema que nos atañe, seguido de una serie de entregas con las que desgranar las claves para diseñar una landing zone corporativa que cumpla con todas las best practises recomendadas por el gigante de Seattle.

Landing Zone

Cuando uno piensa en los motivos que empujan a una organización a iniciar un Journey To Cloud con el que migrar sus aplicativos a la nube, lo primero que le viene a la cabeza es la accesibilidad/disponibilidad instantánea de los recursos, la escalabilidad ilimitada, el ahorro de costes, una mayor seguridad, la reducción del time to market, o la capacidad de innovación, entre muchos otros. Todo ellos beneficios prácticamente irrechazables.

Ahora bien, independientemente del tamaño e índole de la empresa, este viaje puede convertirse en un autentico infierno si no se lleva a cabo desde un inicio de una forma ordenada, segura y escalable. Por ello, antes de lanzaros a desplegar recursos como si no hubiera un mañana, os animo a plantearos las siguientes cuestiones de lo mas concretas y variopintas:

¿Como se va a garantizar que las acciones de los distintos usuarios, unidades de negocio y equipos de productos no interfieren negativamente entre sí?
¿Como se pretende asegurar que los costos se presupuestan y asignan a los centros de costos apropiados?
¿Que mecanismos se van a emplear para permitir que las medidas de seguridad se implementen de forma personalizada en función de la sensibilidad de cada aplicativo?
¿De que forma se pretende certificar el aislamiento total de los entornos de AWS de forma segura y repetible?

La respuesta a todas esas preguntas son las cuentas. Una cuenta de AWS no es más que un contenedor de recursos totalmente aislado, que proporciona capacidades administrativas para el acceso y la facturación.

Una definición algo farragosa, que analizada en detenimiento, saca a relucir muchos de los beneficios que proporcionan y que resuelve las problemáticas previamente planteadas:

Aislamiento: Una cuenta es una unidad de protección de seguridad, ya que su su aislamiento permite que los riesgos potenciales derivados de las amenazas de seguridad se puedan contener dentro de la misma sin afectar a las demás. En otras palabras, un recurso de una cuenta no puede acceder a otro recurso de otra cuenta sin una autorización previa.
Segregación de responsabilidades: En toda organización cada equipo y/o proyecto puede tener sus propias responsabilidades y necesidades. El hecho de poder gestionar el acceso de los usuarios a nivel de cuentas, garantiza que los equipos no vayan interferir entre sí, como podrían hacerlo cuando se emplea una única cuenta.
Controles de seguridad personalizados: Al desplegar los aplicativos en cuentas independientes, es posible aplicar políticas y mecanismos de control personalizadas para cada una de ellas.
Facturación individualizada: Una cuenta es la única forma de separar elementos a nivel de facturación. Una estrategia multi-cuenta ayuda a crear elementos facturables por unidad de negocio, equipos funcionales o usuarios individuales.
Seguridad del dato: Aislar los almacenes de datos en una cuenta ayuda a limitar la cantidad de personas que tienen acceso, previniendo la exposición no autorizada de información sensible.
Cuotas independientes: Las cuotas de AWS se configuran por cuenta. El despliegue de los aplicativos en cuentas aisladas permite que sea mas difícil alcanzar dichos limites.

Ahora que está claro que la solución pasa por emplear una modelo multi-cuenta, la siguiente pregunta obligatoria es, como deben organizarse estas cuentas, y aquí es precisamente donde entra la landing zone. (No confundir con AWS Landing Zone, el servicio gestionado detallado mas adelante que permite desplegar una landing zone preconfigurada)

Amazon describe la landing zone como un entorno multi-cuenta de AWS escalable y seguro, que sigue al pie de la letra el marco de referencia definido por el AWS Well-Architected Tool, y se encarga de administrar la gestión de identidad y acceso, la gobernanza, la seguridad, el diseño de redes y el logging. Casi nada… mejor analizarlo por partes.

Por un lado, la landing zone se encarga de establecer un modelo de accounting que permita a la organización migrar sus aplicativos a nube de forma ordenada, segura y horizontalmente escalable, a la par que satisface las necesidades previamente planteadas.

Por otro lado, también se encarga de proporcionar una infraestructura base o fundacional, centralizada, que da servicio al resto de cargas de trabajo:

Networking: Infraestructura encargada del enrutamiento del tráfico de entrada, el tráfico entre las distintas cuentas de la landing zone/on-premise y el tráfico de salida a Internet, previo paso por los firewalls correspondientes. También centraliza la resolución de los DNS.
Logging: Infraestructura encargada de consolidar todos los logs generados en AWS, tanto de infraestructura como de aplicación, para que puedan ser utilizados por los equipos de seguridad, operaciones, auditoría o legal.
Shared services: Infraestructura que da un servicio compartido para las distintas cuentas de la landing zone, como los directory services (Active Directory) o el AWS System Manager, entre todos.
Security: Infraestructura orientada a la detección de brechas de seguridad, respuesta ante incidentes, protección del datos y protección de la infraestructura.

Por todo esto, el diseño de la landing zone debe ser uno de los puntos de partida en el journey to cloud de cualquier organización, y un proceso en el que deben estar involucrados tanto los equipos técnicos como el negocio, ya que establece las bases que posteriormente permiten desplegar los aplicativos de forma segura y ordenada.

Building a Landing Zone

Si bien hasta ahora se ha descrito que es una landing zone y cual es la problemática que resuelve, no se ha detallado que es exactamente lo que hay que construir y mucho menos el cómo.

La respuesta a la primera pregunta es que estéis atentos a los próximos artículos del blog en los que se detallarán los diseños técnicos asociados los modelos de accounting, networking, logging centralizado o single sign-on, entre otros.

Para dar respuesta a la segunda pregunta planteada, existen hasta 3 opciones:

AWS Landing Zone

La documentación oficial de Amazon describe AWS Landing Zone como una solución que ayuda a los clientes a configurar un entorno de AWS multi cuenta seguro, basado en las prácticas recomendadas de AWS, permitiendo ahorrar tiempo mediante la automatización de la configuración, ejecutar las cargas de trabajo de forma segura y escalable, al tiempo que implementa una línea de referencia de seguridad inicial mediante la creación de cuentas y recursos principales.

Si bien la traducción al español por parte de AWS es algo farragosa, deja entrever que se trata de un acelerador para construir una landing zone prefabricada por Amazon, que despliega mediante CloudFormation la infraestructura fundacional asociada a la gestión de identidad y acceso, la gobernanza, la seguridad, el diseño de redes y el logging centralizado, que teóricamente cumple con sus best practises.

Adicionalmente, se integra con el AWS Account Vending Machine (AVM) para aprovisionar y configurar de forma automática cuentas nuevas y aprovecha AWS Single Sign-On para administrar el acceso a las cuentas del usuario.

La parte negativa es que esta solución se encuentra deprecada en favor de AWS Control Tower y que tampoco genera la estructura de cuentas recomendada por Amazon en la actualidad, por lo que esta opción queda totalmente descartada.

AWS Control Tower

La documentación oficial de Amazon describe AWS Control Tower como un servicio gestionado que ofrece una forma sencilla de configurar y gobernar un entorno de multicuenta de AWS, siguiendo las mejores prácticas prescriptivas de AWS. Para ello, se integra con otros servicios como, AWS Organizations, AWS Service Catalog y AWS Single Sign-On, logrando desplegar la Landing Zone en menos de una hora.

A priori la propuesta es muy similar a la previamente descrita de AWS Landing Zone, incluyendo un Account Factory para aprovisionar y configurar de forma automática nuevas cuentas, con los correspondientes guardrails que implementan una línea de referencia de seguridad inicial.

Las grandes diferencias residen en su integración con AWS Organizations así como el hecho de disponer de un dashboard con el que llevar a cabo las tareas administrativas. Por contra, su estructura de accounting inicial es mucho más rígida.

Aquí es precisamente donde se presenta el problema, ya que despliega de caja una unidad organizativa “Core” con una cuenta de log-archive y otra de audit, que si bien pueden ser renombradas, no es posible añadir nuevas cuentas a dicha OU. Esto se da de bruces con la estructura de cuentas recomendada por Amazon en la actualidad, como bien se detallará en el post centrado en el accounting.

Y no, Customizations for AWS Control Tower, no solventa esta problemática, ya que está diseñado para personalizar aquellas cuentas creadas mediante el Account Factory de Control Tower, pero no para modificar la unidad organizativa “Core” desplegada inicialmente. De hecho, este servicio de customizacion no es más que una plantilla de CloudFormation que despliega un pipeline de CI/CD que se ejecuta cada vez que se crea una cuenta vía Account Factory, aplicando las personalizaciones configuradas.

No me malinterpretéis, es un añadido muy valioso, especialmente si la compañía apuesta por CloudFormation como herramienta de IaC, pero en esta serie de artículos acerca de la landing zone se busca dar una solución próxima al diseño de referencia Enterprise recomendado por Amazon, y eso no lo puede proveer.

A modo de curiosidad, comentar que desde el pasado mes de noviembre, es posible emplear Terraform para el aprovisionamiento y personalización de dichas cuentas mediante un pipelines de de despliegue de dichas cuentas. Anteriormente esto solo se podía llevar a cabo vía CloudFormation.

Custom Built Solution

Como su propio nombre indica, esta aproximación pasa por construir una solución personalizada que permita construir una organización de cuentas flexibles, a la par que despliega la infraestructura fundacional asociada. Las palabras IaC y automatización deberían ser los pilares centrales de este proceso.

Es sin duda la opción mas costosa, pero a su vez las más flexible y personalizable.

Conclusiones

En conclusión, se ha descrito una landing zone como un entorno multi-cuenta de AWS escalable y seguro, que sigue al pie de la letra el marco de referencia definido por el AWS Well-Architected Tool, y se encarga de administrar la gestión de identidad y acceso, la gobernanza, la seguridad, el diseño de redes y el logging centralizado.

También se han analizado las distintas opciones disponibles para su despliegue, siendo la solución personalizada la mas adecuada para plasmar el diseño de referencia recomendado por Amazon, pero también la mas costosa. Ahora bien, ¿es siempre la más adecuada? No, de ninguna manera.

Esta serie de escritos busca plasmar un escenario de máximos purista, con una segregación de cuentas y responsabilidades que requieren un volumen de negocio que justifique un equipo detrás que lo mantenga. Si no es vuestro caso, una estructura de cuentas mas comedida y Control Tower pueden ser la solución mas adecuada.

Finalmente, estad atentos a futuros artículos en los que se detallarán en profundidad los diseños técnicos asociados los modelos de accounting, networking, logging centralizado o single sign-on, entre otros.

Referencias

Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:

Building an AWS landing zone

Landing Zone