Arquitecturas multi-cuenta en AWS

Esta vez hablaremos sobre los casos donde no es suficiente contar con una sola cuenta en un proveedor Cloud como AWS, explicaremos las razones o requisitos de una arquitectura multi-cuenta, veremos ejemplos de cómo se administran y finalmente describiremos un par de arquitecturas listadas como "best practices" por AWS.

Cuando una sola cuenta es suficiente

Es común encontrar casos de administradores de sistemas que nunca tuvieron que administrar más de una cuenta cloud. Si este es tu caso y cumple a cabalidad tus objetivos entonces este blog puede no ser muy útil, pero te ayudará a identificar el momento de dar el paso a una arquitectura multi-cuentas cuando sea necesario.

En fintech.works siempre recomendaremos cuentas únicas a startups, empresas pequeñas e individuos por su simplicidad, bajo costo de mantenimiento en horas hombres y versatilidad.

Síntomas que pueden requerir multi-cuentas

Si ya estas administrando una arquitectura en la nube puede ser poco claro el momento en el que deberías considerar multi-cuentas, entre los síntomas que puedes experimentar hay que prestarle atención a estos:

1. Tienes proyectos que se deben facturar por separado.
2. Tienes usuarios en tu cuenta que están pidiendo permisos de acceso constantemente y tienen permisos muy granulares ya que no se les puede dar acceso a toda la cuenta.
3. Tienes que ajustar constantemente direcciones IPs para que quepan servicios nuevos.
4. Tienes muchas reglas de firewall (security-groups para AWS o NSGs para Azure) y son muy granulares para evitar que servicios de proyectos/clientes/usuarios se vean entre sí.
5. En el caso de que parte de tu infraestructura requiera una auditoría el proceso de aplicar cambios regulatorios puede ser extremadamente tediosa.

Cada uno de estos síntomas se relacionan 1:1 a estos factores diferenciadores de las arquitecturas multi-account:

1. Facturación
2. Control de acceso
3. Escalabilidad
4. Seguridad
5. Compliance

1. Facturación

Mantener un tracking detallado de recursos y los costos de estos para distintos departamentos, proyectos o clientes en una arquitectura mono-cuenta requiere al menos una persona dedicada full-time a esta tarea, y aún así es posible cometer errores.

Esta dificultad desaparece si se asignan cuentas dedicadas a estos departamentos, proyectos y clientes haciendo que el inventario y control de gastos a fin de mes sea trivial y sin perder la vista global ya que todos los proveedores de cloud tienen capacidad de mostrar una vista agregada de todas las cuentas administradas.

2. Control de acceso

Así como en el caso de facturación el control de acceso en mono-cuenta se vuelve una tarea full-time si se tiene que aislar usuarios en base a sus proyectos o servicios, lo cual mejora en ambientes multi-account, donde cada proyecto tiene su propia cuenta y los usuarios terminan teniendo roles y políticas de acceso más sencillas ya que no se mezclan con los dominios de acceso de los demás proyectos.

Veremos casos más específicos en la sección de ejemplos de arquitecturas multi-account.

3. Escalabilidad

Un arma de doble filo de los servicios en la nube que siempre termina causando problemas es el límite de uso de servicios, normalmente estos límites se aplican a nivel de la cuenta lo que significa que una arquitectura mono-cuenta con proyectos independientes entre sí puede llegar a sufrir downtime de todos sus proyectos al mismo tiempo en caso de que uno solo de estos proyectos alcance un límite. En arquitecturas multi-cuenta cada proyecto está aislado y puede escalar sin afectar a otras cuentas.

Otra ventaja de multi-cuentas se encuentra en la facilidad para poner límites de uso y quotas lo cual es muy difícil cuando los servicios son compartidos por sistemas con requisitos diferentes.

4. Seguridad

Si bien parece obvio, no está demás mencionar que la seguridad en mono-cuentas no es la ideal en caso de incidentes de seguridad, algunos de los escenarios posibles son:

1. Un proyecto es vulnerado por lo cual todos los proyectos de la cuenta son víctimas en potencia.
2. Un usuario no malicioso puede tener acceso y afectar sin querer servicios que no debería poder ver.
3. Credenciales para procesos no humanos, por ejemplo tokens, pueden no tener el mismo nivel de aislamiento que otros tipos de autenticación, exponiendo innecesariamente endpoints ocultos.
4. Errores involuntarios a la hora de configurar políticas de seguridad pueden tener consecuencias muy graves, por ejemplo, al configurar un firewall para una base de datos, se puede dar acceso sin querer a redes públicas o peor, de otros clientes.

Todos los puntos anteriores se pueden mitigar con multi-cuentas, donde cada incidente sea malicioso o no queda aislado a nivel de cuenta sin afectar a terceros.

5. Compliance

Para el área de compliance el ejemplo más común es el de las auditorías, estas pueden tener requisitos muy variados y rígidos dependiendo del área de negocio del cliente/proyecto lo que hace imposible cumplirlas en una cuenta sin afectar solo al área que recibe la auditoría. Separando las áreas en cuentas diferentes hace posible aislar y aplicar las políticas que sean necesarias pudiendo incluso separar a nivel de ambientes, workloads y dominios de datos en caso de requerir políticas más granulares y disruptivas.

Patrones multi-cuenta

A continuación veremos los patrones multi-cuenta recomendados por AWS para 2 casos comunes:

1. Multi-tenant: Este es el caso donde se tienen servicios y usuarios de clientes/proyectos que no deben interactuar entre sí, por ejemplo, puede ser el caso de una empresa de servicios informáticos que administra proyectos de clientes diferentes o proyectos de equipos diferentes.
2. Single-tenant: Aquí vemos el caso típico de una empresa con una gran cantidad de servicios y usuarios que deben interactuar entre sí, que es el caso típico de bancos y multinacionales entre otros.

Para los patrones multi-cuentas de AWS, tenemos los siguientes conceptos:

1. Cuenta de administración: Es una cuenta normal de AWS que tiene permisos para modificar la organización y los componentes de menor jerarquía mediante el servicio AWS Organizations, aparte de esto puede ser utilizada para la facturación global de toda la organización, como buena práctica se recomienda que esta cuenta no se utilice para nada más.
2. Organización: Representa el nivel administrativo más alto, contiene las unidades organizacionales y cuentas administrativas, para ambos modelos solo existe una organización.
3. Unidad organizacional: Son agrupaciones de cuentas, que permiten aplicar políticas a todas las cuentas que controlan, puede haber más de una.
4. Cuenta: Contiene el conjunto todos los servicios y herramientas proveídos por AWS.
5. Servicio: Son los servicios individuales como RDS, EC2 y S3 que pueden ser usados en la cuenta.

1. Patrón Multi-tenant

Si nuestra empresa administra cuentas AWS de proyectos o módulos independientes una arquitectura válida puede ser la siguiente:

1. Tenemos una organización madre, la cual que contiene una cuenta de administración y una unidad organizacional para cada proyecto.
2. La cuenta de administración es utilizada para operaciones sobre la organización y temas globales como por ejemplo la facturación.
3. Cada proyecto tiene una unidad organizacional, dentro de esta cada departamento o área dentro del proyecto tiene su propia cuenta.
4. En la imagen, para el caso del proyecto/modulo 1, tenemos una cuenta por ambiente.
5. Para el proyecto/módulo 2, tenemos cuentas por proyectos en curso, para backups de sistemas y una para CI/CD.

Como se ve en el ejemplo, las estrategias de asignar cuentas dentro de un proyecto son muy diferentes dependiendo de la naturaleza del propio proyecto, pudiendo ser por ambientes, módulos, departamentos, productos o funcionalidades como CI/CD.

2. Patrón Single-Tenant

En el caso de empresas grandes se utiliza un esquema parecido al siguiente:

1. Se vuelve a tener una sola organización y una cuenta de administración para temas transversales.
2. Las unidades organizacionales se utilizan para separar áreas dentro de la propia organización.
3. Tenemos una unidad organizacional de "Seguridad", donde existe una cuenta dedicada a capturar y almacenar logs y otra para los servicios de seguridad de AWS, por ejemplo AWS Security Hub.
4. La unidad de "Infraestructura" tiene la cuenta de Network, donde están configuradas las conexiones internas entre cuentas/servicios y para terceros por VPN.
5. También se tienen cuentas dedicadas a backups y otros servicios como IAM y Cloudformation.
6. En la unidad de "Workloads" se ubican los sistemas desplegados, donde se dividen por ambientes.
7. Una cuenta dedicada a CI/CD provee un nivel extra de aislamiento teniendo en cuenta que los procesos CI/CD suelen tener requisitos de seguridad muy diferentes a los de QA y producción.

Conclusión

Elegir una arquitectura multi-cloud es una jugada inteligente cuando los proyectos empiezan a crecer y se vuelven más complejos. Aunque manejar todo en una sola cuenta puede funcionar al principio, dividir los recursos en varias cuentas facilita la gestión, mejora la seguridad y te da más flexibilidad para escalar. En resumen, si ves que tu infraestructura empieza a necesitar más orden y control, una arquitectura multi-cloud es una gran opción para mantener todo en su lugar sin complicaciones innecesarias.

Sources

1. https://www.linkedin.com/pulse/account-structure-comparison-between-aws-azure-richard-lenan-zhao
2. https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html
3. https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenancy-models
4. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/operating-model/compare