Introducción
A medida que tu gasto en la nube crece y se vuelve más complejo, desglosar la factura solo por servicio o proyecto/cuenta se queda corto si quieres entender de verdad cómo se reparten los costos en tu organización.
Lo ideal es organizar los costos de una forma que refleje cómo opera tu negocio. Por ejemplo, podrías tener varios equipos, entornos u otras categorías a las que quieras asignar costos. Pero estas categorías pueden tener definiciones complejas. Por ejemplo, lo que tu empresa entiende por "Staging Environment" podría incluir todos los proyectos o cuentas que empiezan con la palabra "staging", repartidos en varios equipos o servicios.
Con Allocations en DoiT Cloud Intelligence, puedes mapear los costos de nube a categorías de negocio personalizadas, agrupando por múltiples dimensiones de costo: Labels/Tags, proyectos, cuentas, tipos de servicio, regiones e incluso metadatos de facturación. Allocations admite estrategias de costos directos y compartidos, con reglas automatizadas para distribuir proporcionalmente servicios compartidos como soporte o redes.
Veamos qué son las Allocations y cómo funcionan. Si lo prefieres, salta directamente al tour interactivo.
¿Qué son las Allocations?
Una Allocation es una agrupación lógica de recursos de nube que define una categoría de costo única para tu organización.
Las empresas usan Allocations en la DoiT Platform para entender el consumo de nube en el contexto de su negocio.
También son un paso clave para dar trazabilidad y responsabilidad sobre los costos entre equipos y áreas funcionales.
Veamos algunos ejemplos de Allocations y cómo funcionan en la práctica:
Definir los costos de los equipos de Engineering con Allocations
En DoiT usamos Allocations internamente para definir la huella de nube de cada equipo de Engineering. En este ejemplo, creamos una Allocation para el equipo Bruteforce agrupando los recursos donde un label a nivel de recurso o un label a nivel de proyecto sea igual a "bruteforce".
Aplicamos una lógica "A OR B" para que la Allocation capture los recursos que estén:
- Etiquetados solo con el label de recurso team:bruteforce
- Etiquetados solo con el label de proyecto team:bruteforce
- Etiquetados con ambos
Así logramos una cobertura completa de los costos de Bruteforce, sin importar dónde se haya aplicado el label.
Screenshot
Muchos clientes usan Allocations así para alimentar dashboards y reportes específicos por equipo, que muestran los principales generadores de costo.
En el ejemplo de abajo, desglosamos los costos de Bruteforce por servicio, lo que nos da visibilidad inmediata de qué está moviendo el gasto de ese equipo de Engineering.
Screenshot
Definir los costos por entorno con Allocations
En este ejemplo, definimos los costos de nuestro Staging Environment agrupando todos los proyectos de Google Cloud que incluyan la palabra "staging" mediante coincidencia con regex.
Es una buena muestra de cómo se pueden construir Allocations sin depender de labels o tags.
Screenshot
Como los proyectos de staging suelen crearse o eliminarse con frecuencia, usar regex hace que la Allocation se mantenga al día de forma automática, sin que tengas que actualizarla manualmente cada vez que se agregue un proyecto nuevo.
Screenshot
En el ejemplo siguiente, creamos un reporte de Costo por Entorno que compara tres Allocations: Development, Staging y Production. Así podemos hacer seguimiento del uso por entorno y comparar tendencias en el tiempo.
Screenshot
También podemos desglosar los costos de cada entorno por servicio, cuenta o región para entender qué marca las diferencias.
Screenshot
Por último, puedes programar cualquiera de estos reportes para que se actualicen automáticamente y se envíen a las personas clave con la frecuencia que definas, para que todos estén al tanto.
Screenshot
Estimar ahorros en almacenamiento EBS con Allocations
Las Allocations no se limitan a categorías organizacionales o por equipo: también puedes usarlas para agrupar componentes de infraestructura y modelar escenarios.
Por ejemplo, supongamos que estás usando volúmenes GP2 para AWS EBS y quieres estimar los ahorros potenciales al migrar a GP3.
Empezarías creando una Allocation que capture todos los costos relacionados con EBS asociados a volúmenes GP2. Esto se logra filtrando por metadatos relevantes del servicio de AWS (tipo de volumen, tipo de uso o SKU) que identifiquen el uso de GP2:
Screenshot
Una vez definida la Allocation, puedes combinarla con Metrics en la DoiT Platform para correr tu modelo de ahorros.
Según AWS, los volúmenes GP3 ofrecen hasta un 20% menos de precio por GB frente a GP2. Para estimar tus ahorros potenciales, crea una métrica personalizada que multiplique el costo de la Allocation de GP2 por 0,2.
Screenshot
O bien, para estimar el costo ajustado como si ya estuvieras en GP3, multiplica la misma Allocation por 0,8.
Esto te da una forma ligera y self-serve de:
- Cuantificar los ahorros diarios potenciales
- Priorizar los esfuerzos de migración de almacenamiento
- Validar decisiones de arquitectura con datos reales de costo
Otras formas de usar Allocations
Una vez que defines tus Allocations, se vuelven inputs poderosos en toda la DoiT Platform y desbloquean insights más precisos, accionables y relevantes para el negocio.
Ya vimos cómo las Allocations te ayudan a construir reportes de costo más significativos. Pero su utilidad va mucho más allá. Los clientes de DoiT también usan Allocations para:
- Asignar el gasto con precisión
- Mapear cada dólar de costo de nube a una unidad de negocio, producto o iniciativa específica, cubriendo los huecos que dejan las prácticas de tagging inconsistentes o las estructuras de facturación fragmentadas.
- Mejorar la precisión del pronóstico y el control con Budgets
- Define presupuestos asociados a Allocations para detectar si un equipo, entorno o aplicación está superando el pronóstico y avisar de forma proactiva a los responsables.
- Crear alertas granulares y específicas
- Detecta anomalías, picos de costo o cambios de uso a nivel de Allocation, no solo a nivel de cuenta o servicio, para que los equipos correctos puedan actuar.
- Empoderar a los equipos para tener mejores conversaciones
- Como las allocations reflejan la estructura de tu negocio, funcionan como un lenguaje común entre Finance, Engineering y Leadership para evaluar el comportamiento de los costos y tomar decisiones.
- ¡Y mucho más!
Puedes explorar el resto en este post.
¿Y qué pasa con los Tags y Labels?
Quizá estés pensando: "¿Pero no puedo lograr esto con tags y labels?". ¿Las Allocations reemplazan a los tags y labels?
Son dos conceptos distintos, aunque con cierto solapamiento. Las Allocations te ayudan a organizar tu gasto de nube sin que necesites un tagging perfecto. Por supuesto que puedes usar tags y labels como inputs para construir tus Allocations, pero no estás limitado a ellos.
Sí, puedes lograr agrupaciones similares solo con tags y labels si tu organización mantiene una buena higiene de tagging. Eso significa:
- Una clave de tag consistente para cada categoría (por ejemplo, environment, product, team)
- Un conjunto definido de valores por clave (por ejemplo, prod, dev, staging)
- Cobertura de tags del 100% en todos los recursos
Así se vería un reporte en AWS Cost Explorer con tags AWS aplicados de forma correcta y consistente:
Claves o valores de Tag duplicados
Sin embargo, muchas organizaciones se enfrentan a una realidad de tagging mucho más fragmentada. Puedes tener claves de tag inconsistentes como Environment, Env o environment, y valores como prod, production o Production.
Esa inconsistencia complica el reporte de costos, ya que no puedes agrupar de forma nativa esos valores en una sola unidad lógica.
Con Allocations, puedes definir una única agrupación alineada al negocio (por ejemplo, "Production Environment") que incluya todas estas variantes de tag en una sola regla.
Abajo agrupamos recursos con valores de tag Environment como prod, Production y production en una única Allocation:
Screenshot
Multi-cloud
Supongamos que tu aplicación corre en AWS y Google Cloud. ¿Cómo medirías el costo total de esa app?
No puedes hacerlo de forma nativa dentro de la consola de ningún proveedor de nube; cada uno solo ve sus propios datos.
Con Allocations en la DoiT Platform, puedes agrupar recursos de ambas nubes usando metadatos compartidos como tags, labels, IDs de cuenta, nombres de proyecto y más. Así obtienes una vista de costo unificada de cualquier servicio o producto multi-cloud.
Cuando los Tags no son apropiados para la agrupación de costos que quieres definir
A veces los tags simplemente no encajan con la agrupación que quieres crear.
Por ejemplo, podrías querer definir los costos de "Staging Environment" agregando cuentas de AWS o proyectos de GCP cuyos nombres contengan "staging", sin importar si esos recursos están etiquetados.
Con Allocations, puedes usar nombres de proyecto/cuenta, coincidencias con regex y otras dimensiones para construir esas agrupaciones de costo.
Screenshot
Sistemas legacy que no funcionan con Tags
Algunos clientes tienen sistemas legacy que no soportan tags o no permiten hacer cumplir estándares de tagging.
En estos casos, no hay una buena solución alternativa en las consolas nativas. Pero con Allocations, puedes agrupar esos recursos sin etiquetar usando otros metadatos, como ID de cuenta, región, nombre de servicio o lógica personalizada.
Conclusión
Ya sea que quieras entender el gasto de nube en el contexto de tu negocio o llevar la trazabilidad de costos entre equipos, todo empieza con Allocations.
¿Listo para tener una visión más clara de tus costos de nube? Haz el tour interactivo de abajo, o contacta a DoiT para agendar una demo personalizada y ver cómo Allocations y el resto de la DoiT Platform pueden trabajar para tu equipo.
Haz un tour interactivo de Allocations