¿Qué es AWS Control Tower? Control sobre tu entorno AWS

¿Qué gana una empresa al pasar de cuentas AWS desperdigadas a una landing zone con AWS Control Tower? Principalmente, una seguridad homogénea, una gestión automatizada de cuentas, un sistema común de etiquetado y un mayor control financiero gracias a FinOps y la facturación consolidada.

Casi todas las organizaciones llegan a la nube de la misma forma. Primero crean una cuenta para un proyecto, después otra para un proveedor y, más adelante, una adicional para unas pruebas que nunca llegaron a cerrarse. Cada cuenta AWS es, por diseño, una frontera de aislamiento que permite separar permisos, límites de servicio, riesgos y costes. Por eso, la estrategia multicuenta es una buena práctica en sí misma. El problema surge cuando ese aislamiento se convierte en un conjunto de silos, donde cada entorno funciona con sus propias reglas de seguridad, usuarios y criterios de facturación.

La verdadera cuestión es si todas esas cuentas forman parte de una organización gobernada o funcionan como un conjunto de islas independientes. Esta diferencia apenas se percibe cuando se gestionan cinco cuentas, pero se vuelve evidente al llegar a cincuenta. Es entonces cuando aparecen los desafíos, especialmente ante una auditoría, al cerrar el presupuesto trimestral o cuando un incidente de seguridad exige identificar rápidamente qué recursos están expuestos y quién es responsable de ellos.

¿Cuáles son los problemas de tener cuentas desperdigadas?

La dispersión no suele doler el primer día. Su coste se acumula de forma silenciosa, en cinco frentes:

• Cada cuenta es un mundo. Sin una base común, la configuración depende de quién creó la cuenta y cuándo: unas tienen trazabilidad y auditoría, otras no; unas limitan regiones, otras permiten todo.
• La seguridad se revisa a mano, cuenta por cuenta. Responder a «¿cumplimos esta norma en toda la empresa?» exige días de trabajo, capturas de pantalla y, aun así, siempre deja dudas.
• Los accesos se multiplican. Usuarios y claves creados en cada cuenta, permisos heredados de proyectos antiguos y bajas que nunca llegan a todas partes.
• Dar de alta un entorno es un proyecto. Tickets, configuraciones copiadas de otra cuenta y, meses después, divergencias que nadie sabe explicar.
• El coste no tiene dueño. Facturas separadas, etiquetas inventadas por cada equipo (env, Entorno, ENV) y compromisos de ahorro que solo aprovecha la cuenta que los compró.

Ninguno de estos problemas es estrictamente técnico: todos nacen de la falta de un modelo común. Por eso no se resuelven con más herramientas en cada cuenta, sino con una estructura que las abarque a todas.

¿Qué cambia con un entorno gobernado con AWS Control Tower?

AWS Control Tower convierte esa colección de cuentas en una landing zone: una organización con estructura, cuentas compartidas dedicadas a seguridad y registro, y guardarraíles que se heredan automáticamente. Por debajo orquesta servicios que ya existen (AWS Organizations, IAM Identity Center, AWS Config, CloudTrail), pero el cambio importante no es tecnológico, sino de modelo: la gobernanza deja de depender de la disciplina de cada equipo y pasa a estar incorporada en el propio entorno. Y no exige empezar de cero: las OU y las cuentas que ya existen pueden registrarse en Control Tower y pasar a estar gobernadas.

La clave está en la herencia. Las cuentas se agrupan en unidades organizativas (OU) según su función y su nivel de riesgo, no según el organigrama: seguridad, infraestructura compartida, cargas de trabajo de producción y de desarrollo, innovación y una OU de cuentas suspendidas. Lo que se aplica en la raíz alcanza a toda la organización; lo que se aplica a una OU, a todas sus cuentas, presentes y futuras. Una decisión bien tomada una vez protege a cientos de cuentas, y una cuenta nueva nace ya gobernada.

Los beneficios de AWS Control Tower que de verdad se notan

• Velocidad con garantías. En un entorno disperso, rapidez y control compiten: o se crea la cuenta rápido, o se crea bien. En una landing zone dejan de ser incompatibles. Con Account Factory for Terraform (AFT), pedir una cuenta es un git push de un fichero que la describe: llega a su OU con los guardarraíles aplicados, sus etiquetas de cuenta y las personalizaciones comunes, y cada petición queda trazada. CloudFormation StackSets, desplegados sobre las OU, añade automáticamente la línea base (roles, red, monitorización) a cada cuenta que entra y, si así se configura, la retira cuando sale. Los equipos ganan autonomía sin que la organización pierda control.

• Seguridad que no se negocia por equipo. Control Tower ofrece controles de tres tipos que se complementan. Los preventivos (SCP y RCP) marcan el perímetro de lo permitido (regiones, servicios, acciones críticas) y ni siquiera un administrador de la cuenta puede saltárselo. Los detectivos (reglas de AWS Config) avisan de lo que se desvía. Los proactivos (hooks de CloudFormation) impiden desplegar recursos que no cumplen, antes de que existan. Unos son obligatorios, otros muy recomendados y otros opcionales, de modo que cada OU puede tener el nivel de exigencia que le corresponde: más estricto en producción, más flexible en innovación.
• Una identidad, todas las cuentas. La landing zone centraliza el acceso con IAM Identity Center, propio o federado con el proveedor de identidad corporativo: cada persona tiene una sola identidad, los permisos se asignan por grupos y conjuntos de permisos, y dar de baja a alguien es un único cambio, no una búsqueda de usuarios IAM repartidos por decenas de cuentas.
• Visibilidad y auditoría sin perseguir a nadie. La actividad de todas las cuentas se registra de forma centralizada en una cuenta de archivo de registros, protegida frente a cambios, y el equipo de seguridad dispone de una cuenta de auditoría con visión transversal. El estado de cumplimiento de controles y cuentas se consulta en un único panel, y Control Tower detecta cuándo algo se ha desviado de la línea base (drift) para poder corregirlo.

Gobierno por etiquetas: el lenguaje común

Si la estructura de OU responde a «¿qué reglas aplican aquí?», las etiquetas responden a «¿de quién es esto y para qué sirve?». La verdadera palanca de gobierno es acordar una taxonomía corporativa (centro de coste, entorno, propietario, proyecto) y hacerla cumplir de forma sistemática, no por buena voluntad. Un entorno gobernado lo consigue en tres niveles:

• Etiquetas de cuenta. AFT etiqueta cada cuenta al crearla, y esas etiquetas se heredan en todo su consumo, incluidos costes que no admiten etiqueta a nivel de recurso, como créditos o reembolsos.
• Etiquetas de recurso normalizadas. Las tag policies de AWS Organizations fijan qué claves existen, cómo se escriben y qué valores son válidos, y pueden validarse en el propio despliegue de infraestructura como código (CloudFormation o Terraform), bloqueando o avisando antes de crear un recurso sin las etiquetas obligatorias.
• Barreras finales. Una SCP puede denegar la creación de recursos críticos si la petición no incluye las etiquetas requeridas. Conviene aplicarlo de forma gradual: primero medir el cumplimiento, después exigirlo.

El resultado es que cada recurso y cada euro tienen nombre y apellidos. Y esa misma información sirve después para automatizar: políticas de acceso basadas en atributos, apagados programados de entornos no productivos o inventarios por aplicación.

FinOps sobre facturación unificada

Con AWS Organizations, la cuenta de gestión actúa como cuenta pagadora de toda la organización. Esto, que parece un detalle administrativo, es la base de un modelo FinOps maduro, que puede leerse como un embudo: cada capa transforma la factura en algo más útil para el negocio.

• Una sola factura para toda la organización, con el uso agregado para alcanzar antes los descuentos por volumen y con la posibilidad de compartir créditos entre cuentas.
• Los Reserved Instances y Savings Plans dejan de beneficiar solo a quien los compró: pueden compartirse en toda la organización o, si el negocio lo exige, priorizar o restringir ese reparto a grupos definidos (por ejemplo, por unidad de negocio), simulando antes el impacto en la factura.
• Sobre las etiquetas activadas como etiquetas de asignación de costes, las Cost Categories traducen cuentas y etiquetas a la estructura del negocio, y las reglas de reparto distribuyen los costes compartidos (red, seguridad, plataforma) de forma proporcional, fija o equitativa.
• Budgets y Cost Anomaly Detection por unidad de negocio, proyecto o entorno, para que las desviaciones se detecten en días y no al cierre del mes.
• Las billing views dan a cada equipo visibilidad de su propio gasto sin acceder a la cuenta pagadora, y las exportaciones CUR 2.0 o FOCUS alimentan los modelos de showback y chargeback.

El servicio Control Tower no tiene coste adicional; solo se pagan los servicios que utiliza, como AWS Config, CloudTrail o S3.

Utilidades concretas de un entorno gobernado

• Integrar una filial o una adquisición en días: sus cuentas entran en una OU y heredan seguridad, registro y reglas de etiquetado; su gasto aparece desde el primer día en su unidad de negocio.
• Superar una auditoría con evidencias centralizadas en lugar de capturas cuenta por cuenta.
• Dar a innovación un sandbox real: cuentas con presupuesto y alertas, aisladas de producción, que se crean y se cierran sin riesgo.
• Responder a un incidente sabiendo en minutos qué cuentas y recursos están afectados y quién es su responsable.
• Cerrar el mes con el coste repartido: cada centro de coste recibe su consumo, con la parte proporcional de los ahorros y de los servicios compartidos, sin hojas de cálculo manuales.
• Preparar la base para lo que viene: los mismos mecanismos son los que permiten, después, gobernar servicios como los agentes de IA a escala de toda la organización.

¿Cuándo conviene dar el paso? Cuando hay varias unidades de negocio o equipos con cuentas propias, cuando hay que separar desarrollo y producción con reglas distintas, cuando existen requisitos regulatorios o cuando se crean cuentas nuevas con frecuencia. Si se da más de una de estas situaciones, el coste de no gobernar ya se está pagando.

¿Cómo medir que funciona?

La gobernanza también se mide. Estos son los indicadores que reflejan el cambio de modelo:

Una estrategia multicuenta solo aporta valor si las cuentas comparten estructura, reglas y un modelo de costes. AWS Control Tower proporciona esa base: organiza las cuentas en OU, aplica controles que se heredan y automatiza el alta de cuentas. Junto con una taxonomía de etiquetas y la facturación unificada, permite además atribuir cada coste a su responsable. El resultado es un entorno más fácil de auditar, de operar y de hacer crecer.

Conviene subrayar que estos beneficios no proceden de un único servicio, sino de la combinación de varios mecanismos que se refuerzan entre sí. La estructura de OU define dónde aplica cada regla; los controles garantizan que esas reglas se cumplan sin depender de revisiones manuales; la fábrica de cuentas asegura que cada entorno nuevo nazca con la misma base; las etiquetas dan contexto de negocio a cada recurso, y la facturación unificada convierte ese contexto en información económica útil. Si falta alguna de estas piezas, el modelo pierde buena parte de su valor.

Tampoco es necesario abordarlo todo a la vez. Un enfoque razonable es empezar por el diseño de la estructura de OU y de la taxonomía de etiquetas, desplegar la landing zone con los controles básicos e incorporar de forma progresiva las cuentas existentes, priorizando las de producción. A partir de ahí, la fábrica de cuentas, los controles adicionales y el modelo FinOps pueden madurar por fases, apoyándose en los indicadores descritos para medir el avance.

En hiberus acompañamos a las organizaciones en ese recorrido completo: el diseño de la landing zone y de su estructura de OU, la fábrica de cuentas como código, la taxonomía de etiquetas y el modelo FinOps que convierte la factura en información de negocio.

Fuentes: documentación de AWS Control Tower, AWS Organizations, AWS Billing y AWS CloudFormation StackSets.