La factura cloud llegó un 60% por encima del presupuesto. El CFO quería explicaciones. El equipo de IT culpaba a los entornos de desarrollo que nadie apagaba. Los equipos de desarrollo culpaban a la falta de visibilidad sobre los costes. Y nadie sabía con exactitud qué aplicación consumía qué recursos en Azure ni en AWS.
Este era el punto de partida de un proyecto FinOps multicloud que terminó con una reducción del 35% en la factura cloud en seis meses y 180.000 euros anuales recuperados solo en reservas mal dimensionadas. Lo que funcionó no fue una herramienta ni un producto. Fue una secuencia de decisiones en un orden específico, y esa secuencia importa más de lo que sugieren la mayoría de guías sobre FinOps.
El error más costoso: empezar por las herramientas en lugar de por el tagging
Cuando una empresa llega a un proyecto FinOps con la factura fuera de control, el instinto inicial es contratar una plataforma de optimización cloud — CloudHealth, Apptio Cloudability, o las herramientas nativas de Azure Cost Management y AWS Cost Explorer configuradas con más detalle. Es el movimiento equivocado si el tagging está roto, y en el 90% de los proyectos que reviso, el tagging está roto.
Sin tagging sistemático, cualquier herramienta de optimización cloud produce dashboards con datos incorrectos o incompletos, y las recomendaciones de optimización que genera no se pueden validar ni atribuir a responsables concretos. El resultado es un informe que nadie ejecuta porque nadie confía en los números.
La primera acción en cualquier proyecto FinOps debe ser imponer el tagging como requisito no negociable mediante políticas de infraestructura. En Azure, esto se implementa con Azure Policy en modo Deny que impide el despliegue de cualquier recurso sin los tags obligatorios. En AWS, con Service Control Policies (SCPs) a nivel de organización.
El modelo de tags mínimo que funciona en entornos multicloud:
environment: prod / pre / dev / sandboxcost-center: código del centro de coste del área propietariaapplication: identificador del sistema o aplicaciónowner: alias del equipo o persona responsableproject: código del proyecto para recursos temporales
En el proyecto que describimos, el tagging pasó del 23% al 98% de cobertura en las primeras seis semanas. Solo con eso, el equipo finance pudo, por primera vez, ver qué unidad de negocio consumía qué en la factura cloud. Ese dato, por sí solo, cambió la conversación con el CFO.
Definir los KPIs FinOps antes de empezar a optimizar
El segundo error frecuente es lanzarse a optimizar sin definir cómo se va a medir el éxito. FinOps sin métricas es un proyecto de reducción de costes sin capacidad de demostrar resultados, lo que lo hace políticamente frágil en cuanto aparece la primera resistencia del negocio.
Los KPIs FinOps que tienen sentido para la dirección de una empresa mediana o grande no son los KPIs técnicos (cobertura de tagging, número de recursos rightsized) sino los KPIs financieros vinculados a decisiones de negocio:
- Unit economics: coste cloud por transacción procesada, por usuario activo o por unidad de negocio relevante para el modelo de la empresa. Este es el KPI que convierte FinOps de "reducción de costes IT" en "eficiencia operativa del negocio".
- Budget variance: desviación real vs. presupuestado por unidad de negocio. El objetivo no es gastar menos en cloud — es gastar exactamente lo que se presupuestó y poder predecir con precisión.
- Cobertura de compromiso: porcentaje del gasto comprometible (cargas estables y predecibles) cubierto por reservas o Savings Plans. El benchmark del sector está entre el 60% y el 80% para entornos maduros.
Definir estos KPIs antes de empezar permite justificar las inversiones en el proyecto — que las hay, aunque sean menores que el ahorro — y proteger el proyecto cuando algún equipo de desarrollo argumenta que las restricciones de tagging o las políticas de apagado automático "ralentizan la innovación".
Reservas y Savings Plans: la palanca de mayor impacto, con el análisis correcto
En el proyecto mencionado, 180.000 euros anuales vinieron de reservas mal dimensionadas. No de reservas inexistentes — la empresa tenía reservas tanto en Azure como en AWS — sino de reservas compradas sin analizar correctamente el patrón de uso previo.
El error más común con las reservas cloud es comprarlas basándose en el consumo puntual del último mes en lugar de analizar el patrón de los doce meses anteriores. Las cargas de trabajo cloud raramente tienen un consumo completamente estable: hay picos estacionales, proyectos que arrancan y terminan, aplicaciones que crecen o se retiuran. Una reserva comprada en diciembre sobre el consumo de noviembre puede estar sobredimensionada el 40% del año.
La regla que usamos: no comprar ninguna reserva sin un análisis de al menos 12 meses de histórico de consumo. En Azure, el Right-size recommendations de Azure Advisor más Azure Cost Management + análisis de utilization de las reservas existentes dan los datos necesarios. En AWS, el Cost Explorer con el análisis de Reserved Instance coverage y los Compute Optimizer recommendations.
El segundo error con las reservas es comprarlas con un alcance demasiado específico (una instancia concreta, una región, un tamaño de VM exacto) en lugar de reservas con mayor flexibilidad. Azure ofrece reservas con instance flexibility que aplican a toda una familia de instancias. AWS ofrece Convertible Reserved Instances y Savings Plans con cobertura de instancia flexible. El descuento es ligeramente menor, pero la probabilidad de utilización completa durante toda la vigencia de la reserva es significativamente mayor.
Rightsizing: el período de observación que nadie quiere esperar
Rightsizing — ajustar el tamaño de los recursos cloud a la demanda real — es donde muchos proyectos FinOps pierden el momentum. El equipo técnico identifica cientos de VMs sobredimensionadas, presenta el análisis al negocio, y el proceso de aprobación se eterniza porque nadie quiere ser el responsable de haber reducido una VM que luego se queda sin recursos en producción.
El mecanismo que funciona en la práctica tiene dos componentes: datos de 30 días de utilización real y un proceso de aprobación ligero.
30 días de observación es el mínimo para rightsizing en cargas productivas. Menos de eso captura variabilidad puntual, no el patrón real de uso. Azure Advisor y AWS Compute Optimizer ya calculan recomendaciones basadas en 7, 14 o 30 días de métricas — usar siempre el período máximo disponible antes de ejecutar cualquier cambio.
El proceso de aprobación que funciona es uno en el que el propietario de la aplicación recibe la recomendación con los datos de utilización en un formato que pueda entender — no el dashobard técnico del portal Azure, sino un email con tres números: tamaño actual, tamaño recomendado, ahorro mensual estimado — y tiene que aprobar o rechazar en 5 días hábiles. Sin respuesta en 5 días, se ejecuta el cambio. Esta política funciona porque convierte el silencio en aprobación implícita, lo que elimina el principal cuello de botella de los proyectos FinOps: la inacción por miedo al riesgo.
Apagado automático con lógica de excepciones: el truco que salva el proyecto
Apagar automáticamente los recursos de desarrollo y pruebas fuera del horario laboral es uno de los ahorros más inmediatos en cualquier proyecto FinOps. Un entorno de desarrollo activo 24/7 que solo se usa 10 horas al día de lunes a viernes consume el 71% de su presupuesto sin generar valor. Apagarlo fuera del horario de uso, con encendido automático por la mañana, puede reducir su coste entre un 65% y un 70%.
El problema que destruye estos proyectos es la política de excepciones. Si implementas el apagado automático sin un proceso claro para las excepciones legítimas — cargas de CI/CD que corren por la noche, entornos con jobs programados fuera de horario, sistemas de pruebas de carga que necesitan correr en ventanas específicas — los equipos de desarrollo encuentran formas de eludir el sistema: desactivan el mecanismo de apagado, crean recursos fuera del scope de la política, o simplemente se quejan hasta que el proyecto se abandona.
La solución es un proceso de excepción documentado y autogestionado: cualquier equipo puede solicitar una excepción para un recurso o grupo de recursos, con una justificación de negocio y una fecha de revisión. Las excepciones aprobadas se auditan trimestralmente y se eliminan si la justificación original ya no aplica. Este proceso convierte las excepciones en algo visible y gestionable en lugar de un agujero negro que vacía el ahorro de la iniciativa.
FinOps es cultura, no una herramienta ni un proyecto de seis meses
Este es el punto que los proyectos FinOps que fracasan comparten: se trataron como un proyecto de optimización puntual en lugar de como un cambio permanente en cómo la organización gestiona el consumo cloud.
Un proyecto FinOps con un gran resultado en el primer semestre puede revertirse completamente en el segundo semestre si no se institucionaliza el proceso. Los equipos de desarrollo vuelven a desplegar sin tags. Las reservas vencen y no se renuevan. Los entornos de desarrollo sobredimensionados vuelven a crecer. Y en doce meses, la factura vuelve a estar donde estaba.
Lo que hace que FinOps sea sostenible es un proceso mensual con tres elementos:
- Review mensual de costes con los propietarios de las aplicaciones principales, no solo con el equipo de IT. Cuando el responsable de un departamento ve que su aplicación gastó X euros el mes pasado y cómo eso compara con el presupuesto, el comportamiento cambia.
- Actualización automática de recomendaciones: el rightsizing de enero no es válido en julio si la aplicación ha crecido. Las recomendaciones deben regenerarse mensualmente y el proceso de aprobación debe mantenerse activo.
- Gobernanza de nuevos despliegues: cualquier recurso nuevo que supere un umbral de coste mensual requiere revisión previa de arquitectura con el ángulo FinOps. Esto evita que los problemas de optimización acumulen deuda técnica de costes.
Los números que importan al final del año
En el caso de estudio 006, la factura que llegó un 60% sobre presupuesto se redujo un 35% en seis meses. El tagging pasó del 23% al 98% de cobertura. Las reservas se ajustaron recuperando 180.000 euros anuales de compromisos sobredimensionados. El rightsizing liberó otro 15% de gasto en entornos no productivos.
Pero el resultado que más valoró el CFO en la presentación de cierre no fue el porcentaje de ahorro. Fue que, por primera vez en tres años, el equipo de IT podía responder en tiempo real a "¿cuánto cuesta nuestra aplicación de pagos por mes?" sin necesitar una semana de análisis de factura. Esa visibilidad, que parece trivial desde fuera, cambió fundamentalmente cómo el comité de dirección evalúa las inversiones en tecnología.
¿Tu factura cloud crece sin control?
Si la factura cloud de tu organización lleva creciendo más de un 20% interanual o si el equipo finance no puede atribuir el gasto a unidades de negocio concretas, hay un proyecto FinOps que tiene sentido. Puedo ayudarte a identificar el potencial de ahorro real antes de comprometer presupuesto en herramientas.
Hablemos