Prepárese para escalar en la nube. Estrategia de múltiples cuentas

Por Rene Martínez Bravet, Arquitecto de Soluciones AWS y
Angel Goñi Oramas, Arquitecto de Soluciones AWS

¿Te interesa saber cómo multiplicar los límites de servicio y la capa gratuita para diferentes aplicaciones en AWS? ¿Quieres mantener un mayor nivel de soporte para ambientes productivos sin pagar un porcentaje del consumo total? ¿Buscas una forma sencilla y efectiva de aislar costos y accesos para diferentes aplicaciones o unidades de negocio?

Si la respuesta a alguna de las preguntas anteriores es sí, probablemente necesites una estrategia de múltiples cuentas. En la siguiente publicación abordaremos cuando es buena idea hacerlo, cuando no y las consideraciones más relevantes al respecto.

Multi-cuentas versus cuenta única.

Cada vez son más los clientes que se nos acercan, preguntando por indicaciones prescriptivas para la implementación de ambiente de múltiples cuentas, particularmente con AWS Control Tower. Las motivaciones detrás de este interés son varias:

• Recomendación de un partner, típicamente con competencia de seguridad.
• Parte de un proceso de diseño fundacional dentro de una iniciativa de Servicios Profesionales de AWS.
• Crecimiento en la adopción de la nube y con ello la necesidad de ejercer mayor control y gobierno.

Aún cuando las causas han sido distintas, lo interesante para nosotros es que las preguntas son recurrentes:

• ¿Realmente es necesaria una estrategia multi-cuentas y una Landing Zone?
• ¿Debería implementarse con AWS Control Tower?
• ¿Qué impacto tiene en la operación vigente del cliente?
• ¿Cuántas cuentas se deben crear, que patrón seguir?

Esta situación nos lanzó la señal de que faltaba proveer una guía que facilitara la decisión más allá de las buenas prácticas e instrucciones descritas en la documentación del servicio.

Para facilitar estas decisiones y la comprensión de la presente publicación, comencemos por revisar algunas definiciones.

Multi-cuentas:

Es un concepto que se introduce aproximadamente 5 o 6 años, una de las primeras conferencias donde se trata el tema fue en re:Invent 2016. La idea detrás de la estrategia posiciona la entidad Cuenta de AWS cómo la unidad perimetral básica a la hora de aislar los recursos desplegados en AWS; tanto desde el punto de vista técnico como de facturación.

Landing Zone:

Implementación lógica de una estrategia multi-cuentas por medio de la solución Amazon Landing Zone (ALZ), o más recientemente con Control Tower. Un despliegue de Landing Zone realiza una serie de configuraciones de forma automática que puede incluir:

• Configuración de una Account Vending Machine/Account Factory para automatizar la creación de nuevas cuentas en la Landing Zone.
• Creación de Amazon VPC y otros componentes de redes dentro de cada cuenta.
• Implementación de AWS Single Sign-On o federación contra un directorio activo existente.
• Configuración de almacenamiento de los logs de Amazon CloudTrail en una cuenta centralizada.
• Aplicación de protecciones (Guardrails) a cada una de las cuentas creadas.
• Estructura de servicios comunes compartidos, como un directorio, servicios de DNS y herramienta de DevOps.

Aún cuando una Landing Zone puede ser configurada manualmente, es un proceso difícil y que consume un tiempo que puede ser empleado en generar innovación y agregar valor al negocio.

Account Vending Machine / Account Factory:

Mecanismo de auto-servicio que automatiza el proceso de creación de cuentas de AWS. Es un producto del AWS Service Catalog que es parte de los componentes de una Landing Zone para el cual AWS Control Tower provee una capa de abstracción superior llamada Account Factory. Su propósito es crear cuentas de AWS con determinado proceso de línea base que cumpla con las buenas prácticas propuestas por la solución y las configuraciones adicionales definidas por el cliente.

Unidad organizacional (OU):

Constituye un agrupamiento lógico de cuentas de AWS dentro de AWS Organization. Las OUs permiten organizar las cuentas en una jerarquía en forma de árbol facilitando la aplicación de mecanismos de control.

¿Son muchos conceptos nuevos, como decido cual es la mejor opción?

Para responder de forma mas simple esta pregunta hemos creado el siguiente diagrama:

Si deseas entender el razonamiento detrás de cada una de estas alternativas sigue leyendo, a continuación, profundizamos el análisis.

¿Realmente es necesaria una estrategia multi-cuentas y una Landing Zone?

La respuesta corta es que en el 90% de los casos sí se necesita. Por lo general, nuestros clientes tienen desplegadas varias aplicaciones o necesitan más de un ambiente (Dev, QA, Prod), lo que ya constituye una razón para utilizar más de una cuenta. Con múltiples cuentas también se consigue mayor aislamiento en termino de accesos, permisos y costos, se disfruta de una capa gratuita y límites de servicio más amplios de forma general y se pueden conseguir diferentes niveles de soporte en dependencia de la criticidad de las aplicaciones desplegadas.

Una vez clara la decisión de múltiples cuentas hay que ver cómo se implementa. En tecnología las decisiones no suelen ser binarias, así que exploremos un poco más las razones detrás de cada alternativa.

Si solo es necesario:

• Un número reducido de cuentas AWS.
• Separar ambientes por unidad de negocio o por propósito (ambientes bajos y productivos).
• Obtener facturación consolidada en una cuenta pagadora.
• Configurar algunas restricciones básicas sobre las cuentas.

Entonces seria suficiente con solo implementar una estrategia multi-cuentas basada en AWS Organizations, sin necesidad de utilizar ALZ o Control Tower, para emular los Guardrails puedes emplear AWS Config o Service Control Policies (SCP).

¿Debería implementarse con AWS Control Tower?

Esta decisión es más compleja y se deben considerar factores humanos, técnicos, de seguridad y normativos. Sin embargo, hay algunas formas de determinar cuándo AWS Control Tower no es el camino. ¿Se prevé la creación de múltiples cuentas de forma frecuente? ¿La compañía pertenece un rubro regulado con altos estándares de seguridad y cumplimiento? ¿Tienes un equipo de TI dedicado al gobierno y arquitectura de nube?

Si tu respuesta fue “No“ en cada caso, la mejor alternativa es realizar una implementación de una estrategia multi-cuentas manual. En pocas palabras, el propósito fundamental de Control Tower es facilitar un proceso de creación y gobierno de cuentas, políticas de cumplimiento y gestión de accesos centralizados. Si no explotarás esas fortalezas, lo más probable es que los beneficios que se obtengan no justifiquen la operación del servicio.

Otros factores respecto a Control Tower que se deben considerar son:

• Tamaño de la organización y su forma de operar.
  • ¿Operas en múltiples países con requerimientos de costos o regulatorios distintos?
  • ¿Cuál es el crecimiento de adopción de la nube prevista?
  • ¿Las unidades de negocio trabajan de forma independiente y manejan sus propios equipos y presupuesto?
• Capacidad del equipo
  • ¿El cliente cuenta con equipos cloud o partners para operar la infraestructura y desarrollar nuevos proyectos en AWS?
• Requerimientos normativos o de seguridad
  • ¿Existen requerimientos normativos que se deben cumplir?
  • ¿Existe un área dedicada a Seguridad y Riesgos que sería responsable de los procesos y aplicaciones a desplegar en la nueva Landing Zone?

Las grandes compañías poseen áreas que sustentan procesos de gobierno y seguridad que no necesariamente están involucrados en los proyectos de adopción de AWS. Debido a esta desconexión inicial, es común que no se tenga en cuenta o se subestime la capacidad de crecimiento de la infraestructura hasta que no hay varias cargas de trabajo productivas brindando servicio y cuya migración a un framework de multi-cuentas robusto podría ser un riesgo para el negocio. En estos casos, aún cuando no se pretenda utilizar las ventajas de AWS Control Tower a corto plazo, es una buena practica realizar una implementación por defecto del servicio. El diseño de la arquitectura inicial obligará a pensar en detalles como rangos CIDR, cantidad de ambientes, gestión de credenciales etc, que suelen pasar desapercibidos inicialmente y por ende a involucrar a los equipos que a futuro administraran la Landing Zone.

Entonces, si recomendamos una implementación por defecto; ¿Qué impacto tiene en la operación vigente del cliente?

AWS Control Tower es un producto que combina varios servicios de AWS para automatizar el despliegue y administración de la Landing Zone. No todos estos servicios son los utilizados inicialmente por nuestros clientes en los inicios de su viaje de adopción de AWS. Hemos observado que en la etapa donde la arquitectura fundacional tiene sentido, los equipos internos estén realmente completamente enfocados en aprender servicios relacionados directamente sus aplicaciones; como: Amazon Relational Database Service (RDS), Elastic Cloud Compute (Ec2), Elastic Container Service (ECS), AWS Lambda, Amazon Api Gateway, Amazon DynamoDB, u otro servicio que les permita generar valor al negocio y a sus clientes finales lo mas pronto posible.

Teniendo en cuenta la sobreexposición a nuevas tecnologías, es contraproducente adicionar la operación de AWS Control Tower sobre las mismas personas, que, además de los productos mencionados anteriormente, deberán familiarizarse con un grupo de tecnologías que solo aplicarían para Landing Zone, ejemplos: AWS CloudFormation StackSets, AWS Single Sign-On, AWS Service Catalog, Guardrails, AWS Control Tower, etc.

Esta situación tiene dos posibles soluciones:

1. Crear un equipo (similar a la imagen a continuación) cuya responsabilidad incluirá la administración de la infraestructura, o en su defecto, involucrar los equipos de operaciones, virtualización y redes que existan en la compañía en ese momento.
2. Utilizar una implementación por defecto de Control Tower hasta que el equipo “cloud” crezca lo suficiente como para comenzar a utilizar la herramienta y sacarle el mayor provecho.

Otros elementos adicionales a la administración de AWS Control Tower que se deben tener en cuenta antes de comenzar a operarla:

• Estrategia de cuentas, que profundizaremos a continuación.
• Proceso de costo y facturación. Definición del equipo a cargo de los costos, de los presupuestos, de los reportes de utilización, de la estrategia de etiquetado (parte de las responsabilidades fundacionales de la imagen anterior), etc.
• Operación de la Landing Zone y las aplicaciones desplegadas en ellas. División de responsabilidades entre los equipos de operaciones, de seguridad y de los productos.

¿Cuántas unidades organizacionales o cuentas se deben crear, que patrón seguir?

Hay varias publicaciones dedicadas exclusivamente a este tema, la más reciente la encontrarán en este vínculo.

De forma general todas coinciden en un enfoque similar que se puede resumir de la siguiente forma.

– OU de Aplicaciones (Workloads). Que a su vez pueden estar subdivididas por ambientes (Dev, QA y PROD), por unidad de negocio (Banca, Seguro, Corredora) o por país operación (Chile, Argentina, Colombia). Dentro de cada unidad organizacional van a ubicarse las cuentas de las aplicaciones. ¿Cómo distribuirlas? En pocas palabras, si el equipo de la aplicación A no puede colaborar con el equipo de la aplicación B, cuando los notifican por un incidente a las 2AM, probablemente las aplicaciones deberían vivir en cuentas separadas.

– OU de Experimentación (Sandbox). Como su nombre indica, el objetivo de esta unidad es netamente de experimentación e innovación. Las cuentas dentro de esta OU deben estar aisladas del resto del ecosistema pues se requieren permisos menos restrictivos. Adicionalmente se debe tener un buen control sobre los presupuestos. En esta publicación encontrarán una forma automatizada con buenas prácticas incorporadas para operar dicha OU.

– OU de infraestructura. Aquí se despliegan cuentas de uso común, ejemplo: cuenta de redes, donde se cierran túneles de VPN, los enlaces dedicados, se despliegan los AWS Transit Gateway y se centraliza la entrada y salida de internet público. Otros ejemplos son cuentas donde se implementan y comparten servicios de directorio (AD), resolución de nombre de dominio (DNS) y cuentas de herramientas de desarrollo y ciclo de vida del software: repositorio de código fuente, repositorio de artefactos, pipelines de CI/CD, servicios de infraestructura cómo código, etc.

– OU de excepciones. A medida que nuestros clientes aumentan el uso de la nube y despliegan más cargas de trabajo y aplicaciones en AWS, empiezan a aparecer casos especiales que no están alineados con las políticas de seguridad y cumplimiento generales de la organización.  La unidad de excepciones es para estas cuentas que por un motivo u otro requieren un tratamiento especial, por ejemplo: despliegue de aplicaciones que tiene que cumplir con el estándar PCI DSS.

Conclusiones

Mas allá de la tecnología, es el ejercicio de diseño el que convierte una Landing Zone con AWS Control Tower en una herramienta valiosa para la organización. La evaluación del estado actual de los equipos y los objetivos de la compañía determinarán la profundidad del uso de las funcionalidades de gobierno que entrega el servicio.

La implementación de dicha arquitectura funciona como la pista donde aterrizarán las nuevas aplicaciones y proyectos. Como toda pista de aterrizaje, que requiere mantenimiento al asfalto, limpieza y pintura para que no ocurran accidentes durante la llegada; la de AWS necesita que se aseguren los equipos y procesos necesarios para que sea soportada adecuadamente y no se convierta en una carga para la organización.

Próximos pasos

Si necesitas ayuda, puede comunicarse con nuestro equipo a través del chat en línea.

Sobre los autores

Rene Martínez Bravet es Arquitecto de Soluciones senior en AWS con foco en clientes del segmento enterprise e industria financiera.

Angel Goñi Oramas es Arquitecto de Soluciones enterprise en AWS con foco en SAP y la industria CPG.

Sobre los revisores

Bruno Laurenti es Arquitecto de Soluciones senior en AWS.

Carlos Tagle es Senior Manager en AWS.