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