Organización de cuentas, proyectos y suscripciones
La unidad de aislamiento más fuerte que ofrece una nube no es un permiso ni una red: es la cuenta. Cómo se reparten las cargas entre cuentas define el radio de un error, la claridad de la factura y cuánto cuesta dar acceso a alguien nuevo.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
Todo empieza con una cuenta y todo adentro. Funciona bien un año. Después alguien prueba algo en “la cuenta” y afecta a producción, la factura no dice qué gastó cada equipo, y dar acceso a un proveedor externo obliga a inventar permisos finísimos que nadie está seguro de que alcancen.
Las tres cosas son el mismo problema, y tienen la misma solución: más cuentas. En la nube las cuentas son gratis y son el límite más fuerte que existe.
La jerarquía de cada proveedor
| AWS | Google Cloud | Azure | |
|---|---|---|---|
| Contenedor de recursos | Cuenta | Proyecto | Suscripción, y adentro grupos de recursos |
| Agrupación intermedia | Unidad organizativa | Carpeta | Grupo de administración |
| Raíz | Organización | Organización | Directorio del inquilino |
| Barandas | Políticas de control de servicio | Políticas de la organización | Azure Policy |
| Factura | Consolidada, desglosada por cuenta | Consolidada, desglosada por proyecto | Consolidada, desglosada por suscripción |
La estructura tiene dos ejes y conviene no mezclarlos: entorno —producción, preproducción, desarrollo— y dominio o equipo. La regla que funciona casi siempre es separar primero por entorno, porque es donde el aislamiento importa más, y después por equipo o sistema.
Las cuentas que casi toda organización termina teniendo
El conjunto que se repite
- Gestión: la raíz de la organización. No corre cargas, casi nadie entra. Su compromiso es el peor escenario posible.
- Seguridad y auditoría: recibe una copia de los registros de auditoría de todas las demás, y es la única donde no se pueden borrar.
- Red compartida: la conectividad central, el enlace híbrido, la inspección.
- Producción, una por sistema o por dominio si el volumen lo justifica.
- Preproducción y desarrollo, con las mismas formas pero sin los datos reales.
- Caja de arena, con presupuesto acotado y borrado periódico, para que probar no requiera pedir permiso.
Antes de seguir, predecí
Barandas: lo que nadie puede hacer, ni con permisos
Las políticas de organización son un techo. No otorgan permisos: limitan lo que los permisos de adentro pueden lograr, incluso para un administrador de esa cuenta.
Barandas que valen para casi cualquier organización
- Regiones permitidas: crear recursos sólo donde corresponde. Es también la defensa más simple contra la minería de criptomonedas en una cuenta comprometida.
- Prohibido apagar la auditoría o borrar sus destinos.
- Prohibido salirse de la organización o cambiar los roles que la administran.
- Prohibido crear recursos públicos —buckets, bases— donde no tenga sentido.
- Etiquetas obligatorias de dueño y centro de costo, sin las cuales no se puede crear.
La estructura también es la factura
Separar por cuenta resuelve gratis un problema que de otro modo cuesta mucho trabajo: saber quién gasta qué. La factura viene desglosada por cuenta o proyecto sin que nadie etiquete nada.
Lo que hace falta igual
- Etiquetas obligatorias para el detalle fino dentro de una cuenta: sistema, entorno, dueño.
- Un presupuesto con alertas por cuenta, que es la forma más temprana de enterarse de un error de configuración o de un abuso.
- Los costos compartidos repartidos con una regla explícita —la red central, la observabilidad, el enlace híbrido—, aunque la regla sea imperfecta: sin regla, nadie se siente dueño de bajarlos.
Más a fondo · nivel seniorCómo se ordena algo que ya creció desordenado
Casi nadie diseña esto antes; se llega con una cuenta gigante y todo adentro. La migración ordenada tiene una secuencia conocida:
- Crear la organización y meter la cuenta existente adentro, sin mover nada todavía. Ya con eso se ganan la factura consolidada y las barandas.
- Sacar primero lo nuevo: todo sistema nuevo nace en su propia cuenta. La cuenta vieja deja de crecer.
- Mover lo que sea fácil de mover: lo que no tiene estado y está definido como código.
- Dejar para el final lo que tiene datos, que se mueve con una migración planificada, no con un traslado de recursos.
- Aceptar que la cuenta original queda como legado durante años. Es un resultado normal y mucho mejor que el punto de partida.
Lo que no conviene es el proyecto de “reorganización total” de seis meses: compite con el trabajo de producto, no muestra valor hasta el final y se cancela a mitad de camino.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica