Muchas empresas utilizan varias cuentas de AWS para proporcionar aislamiento de recursos a nivel de cuenta y una atribución de gastos más sencilla por centro de costos. Las razones mas comunes para ejecutar esta estrategia son:

• Algunos departamentos tienen su propia Cuenta AWS por razones de seguridad, por ejemplo el Área de Recursos Humanos pues maneja información muy sensible de los empleados.
• Cada entorno tiene su propia cuenta, por ejemplo DEV, TEST, PROD.
• Han adquirido otros negocios o comprado empresas, y éstas ya tienen su propia Cuenta AWS.
• Operan a nivel global y cada ubicación geográfica tiene sus propios requerimientos legales, por eso desean tener aisladas las cuentas para mejor cumplimiento.

Si bien es muy ‘interesante’ tener varias cuentas por razones de seguridad, gestión y optimización de costos es necesario respondernos algunas preguntas para estar seguros si esta estrategia es la mejor forma de lograr nuestros objetivos:

• El negocio requiere aislamiento administrativo entre las cargas de trabajo?
• El negocio requiere de visibilidad limitada y capacidad para detectar cargas de trabajo en particular?
• El negocio requiere aislamiento para minimizar el potencial impacto de eventos perjudiciales críticos?
• El negocio requiere alto nivel de aislamiento para la recuperación o auditoria de datos?

Si la respuesta a cualquiera de éstas preguntas es SI, es probable que el negocio requiera una estrategia de múltiples cuentas AWS.

Además del aislamiento de recursos y una mejor atribución de gastos, una ventaja de usar varias cuentas de AWS es que los límites de servicio se aplican a nivel de cuenta individual. Entonces, en lugar de un límite de servicio (como 20 reservas de instancias EC2 por AZ por mes) para toda la organización, cada cuenta puede usar un servicio hasta sus límites.

Un costo adicional asociado con el uso de varias cuentas es que, con la excepción del soporte de nivel empresarial, cada cuenta individual debe pagar su propio soporte. Sin embargo, esto también puede ser un beneficio, ya que puede limitar el nivel de soporte pagado por lo que es apropiado para esa cuenta.

Existen algunos patrones de diseño que nos pueden ayudar a tener un mejor gobierno entre cuentas. A continuación explico sobre estos patrones.

Independent Multi-Account Pattern:

Una solución para administrar diferentes equipos usando múltiples cuentas es usar cuentas independientes completamente separadas entre sí. Estas cuentas pueden operar de forma autónoma con sus propios equipos, y también sin la necesidad de que ningún equipo esté involucrado con otro equipo. En lugar de que todos estos equipos compartan una cuenta, arriesgándose a complicaciones potenciales debido a una autorización incorrecta de acceso o problemas de seguimiento, facturación o seguridad complicados, cada región, departamento, proyecto, carga de trabajo, etc., podría tener su propia cuenta.

Pros:

• Acceso más simple, controlado y separado que con una sola cuenta compartida.
• Reportes de facturación simplificados

Cons:

• Alta posibilidad de duplicar esfuerzos operativos.
• Por lo menos dos grupos de Instancias Reservadas.
• Es requerido un Gobierno Centralizada para garantizar la consistencia.

Centrally-Controlled Multi-Account Pattern:

Si bien el uso de múltiples cuentas independientes grandes es teóricamente la forma más sencilla de usar y administrar múltiples cuentas, garantizar estándares uniformes de gobierno, administración y auditoría es difícil con equipos separados. Además, sus equipos de producción y de no producción no tendrán separación a nivel de cuenta, es decir, sin controles de IAM estrictos y específicos, corre el riesgo de violar el principio de acceso con privilegios mínimos. Para organizaciones más grandes, se puede utilizar un patrón de cuentas múltiples con controles centralizados para proporcionar estos beneficios, con el inconveniente de una mayor complejidad administrativa.

Pros:

• Gobierno Centralizado
• Reporte de Facturación único
• Una compra de Instancias Reservadas por el Payer Account se comparte con las demás cuentas
• Aislamiento de entorno y recursos a nivel de cuenta

Cons:

• Es requerido mayor complejidad administrativa
• Reportes de Facturación extensos y se requiere mayor tiempo para el análisis

Una forma de aprovechar una estructura de cuentas múltiples de control centralizado es dividir sus cuentas por unidad de negocio.

• Las cuentas son separadas por equipo, organización o centro de costos.
• Ideal para organizaciones que quieren alinear sus operaciones y control de facturación con unidades de negocio individuales.
• Es lo mejor para organizaciones con entornos de TI descentralizados.
• Es más fácil lanzar alertas de costos basados en el consumo de cada unidad de negocio.

Otra forma de dividir cuentas de esta manera es por su etapa en el ciclo de vida de la aplicación:

• Cuentas son separadas por la etapa en el ciclo de vida de la aplicación.
• Es lo mejor para organizaciones con un modelo de TI tradicional, incluyendo estricta separación de permisos entre cada entorno de la aplicación.
• Es más fácil lanzar alertas de costos basados en el consumo de recursos de cada entorno de la aplicación.

También puedes dividir las cuentas por proyecto, como por aplicación:

• Cuentas son separadas por proyecto o carga de trabajo.
• Es lo mejor para organizaciones con sólidos entornos DevOps.
• Es más fácil lanzar alertas de costos basados en el consumo de cada proyecto, carga de trabajo o aplicación.

Multiple Payer Multi-Account Pattern:

Este patrón ofrece todos los beneficios del patrón anterior (Centrally-Controlled Multi-Account) más la habilidad de asignas costos a cuentas pagadoras por separado.

Pros:

• Gobierno centralizado por cada división.
• Gobierno es naturalmente aislado por división.
• Costos son divididos por cuenta pagadora haciéndolos más fácil de asignar a lo largo de la organización.
• Mecanismo de pago puede ser personalizado por división.

Cons:

• Requiere una administración más compleja.
• Reportes de facturación todo incluido son mas largos y puede requerir más tiempo en analizarlos.
• Requiere compra de Instancias Reservadas por cada cuenta pagadora.

Este es un ejemplo de una estructura de cuenta híbrida, donde cada aplicación tiene su propia cuenta pagadora vinculada a cuentas separadas para cada etapa del ciclo de vida de la aplicación.

• Diseñado para proveer visibilidad incrementada del consumo de recursos así como un aislamiento administrativo sobre múltiples dimensiones.
• Es lo mejor para organizaciones con entornos bien grandes, complejos y con un entorno DevOps maduro.

Este ejemplo muestra cómo cada cuenta pagadora debe tener cuentas vinculadas organizadas de la manera que tenga más sentido según las necesidades de esa división.

• Diseñado para proveer visibilidad incrementada del consumo de recursos así como un aislamiento administrativo sobre múltiples dimensiones.
• Es lo mejor para organizaciones con entornos bien grandes, complejos y con un entorno DevOps maduro.
• Permite una mitigación aún más fuerte de los daños causados por fallas críticas.

Mejores prácticas para el uso de Múltiples Cuentas:

• Usar grupo de alias para las cuentas de correo electrónico. Las personas dejan las organizaciones pero los alias de correo aseguran la continuidad del acceso. Es mas simple atribuir la propiedad de la cuenta y permite una mejor gestión de las alertas de seguridad, operativas y de costos.
• Crear y reforzar el uso de etiquetas de los recursos.
• Aprovechar el uso de las APIs de AWS y scripts para aplicar automáticamente y consistentemente la configuración base a todas las cuentas.