Reducir costes cloud un 40%: framework FinOps para empresas medianas

La factura cloud que nadie entiende

Revisamos la factura de AWS de un cliente en octubre pasado. Facturaban 14.200 euros mensuales. Cuando les preguntamos qué porcentaje de esa factura podían explicar línea por línea, la respuesta fue “quizá un 60%”. El 40% restante era un misterio distribuido entre instancias que alguien levantó para una prueba hace ocho meses, snapshots de EBS acumulados desde 2022, y transferencia de datos entre regiones que nadie había cuestionado.

Esa es la realidad de la mayoría de empresas medianas en cloud. No es que gasten demasiado a propósito. Es que no tienen visibilidad sobre lo que gastan, y sin visibilidad no hay optimización posible.

Según la FinOps Foundation, FinOps no es una herramienta. Es una práctica operativa que convierte el gasto cloud en una decisión de negocio consciente. Y para una empresa que gasta entre 5.000 y 50.000 euros mensuales en cloud, implementar FinOps básico puede generar ahorros del 30-45% en los primeros 90 días.

Las tres fases del framework

Fase 1: Visibilidad (semanas 1-2)

No se puede optimizar lo que no se mide. Antes de tocar una sola instancia, necesitas un mapa completo de tu gasto cloud.

Tagging obligatorio. Cada recurso cloud debe tener al menos tres tags: equipo (quién lo creó), proyecto (para qué sirve), y entorno (producción, staging, desarrollo). Sin tags, tu factura es un muro de líneas anónimas. AWS Cost Explorer y GCP Billing distinguen por tags. Sin ellos, esas herramientas son inútiles.

Implementamos una política de tag-or-terminate: cualquier recurso sin tags después de 72 horas recibe una alerta. Después de una semana, se apaga. Suena agresivo. Funciona. En tres semanas, pasamos de un 23% de recursos taggeados a un 94%.

Dashboard de costes en tiempo real. No un informe mensual que nadie lee. Un dashboard que muestre el gasto acumulado del día, la semana y el mes, con comparativas contra el periodo anterior. Usamos Grafana Cloud con datos de la API de billing. Que el dashboard este visible en un monitor del equipo de ingeniería no es opcional.

Anomaly detection. AWS Cost Anomaly Detection (gratuito) o equivalente. Si tu gasto diario se desvía más de un 20% de la media, quieres saberlo antes de que pase una semana. Hemos detectado instancias GPU dejadas encendidas un viernes que habrían costado 800 euros de haber pasado el fin de semana.

Fase 2: Optimización (semanas 3-6)

Con visibilidad establecida, pasamos a las tres palancas de optimización que generan el 80% de los ahorros.

Right-sizing. La mayoría de instancias están sobredimensionadas. Es natural: nadie quiere que producción se caiga porque le faltan recursos, así que se pide un t3.xlarge “por si acaso” cuando un t3.medium sería suficiente.

AWS Compute Optimizer y GCP Recommender analizan el uso real de CPU, memoria y red de tus instancias y recomiendan el tamaño correcto. En nuestra experiencia, entre el 40% y el 60% de las instancias pueden reducirse al menos un tamaño sin impacto en rendimiento.

El truco está en no hacerlo todo a la vez. Empezamos por instancias de desarrollo y staging (bajo riesgo). Después pasamos a producción, una instancia cada vez, con monitorización de rendimiento durante 48 horas antes de confirmar. El right-sizing típico ahorra entre un 15% y un 25% del gasto en cómputo.

Reserved Instances / Committed Use. Si una instancia va a estar encendida 24/7 durante el próximo año (bases de datos, APIs core, caches), pagar on-demand es tirar dinero. Los Reserved Instances de AWS ofrecen descuentos del 30-40% (1 año, sin pago adelantado) o del 55-65% (3 años, pago completo adelantado).

La regla que usamos: cualquier instancia que haya tenido una utilización superior al 70% durante los últimos 3 meses es candidata a reserva. No reservamos el 100% de la flota. Reservamos el 60-70% (la carga base) y el resto lo dejamos on-demand para absorber picos.

Un error común: comprar Savings Plans demasiado grandes. Si tu uso real baja (porque has hecho right-sizing o porque un proyecto ha terminado), el compromiso te obliga a pagar por capacidad que no usas. Mejor empezar conservador y ampliar que sobrecomprar.

Spot Instances para cargas tolerantes. Pipelines de datos, tests de integración, batch processing, entornos de desarrollo efímeros. Todo esto puede ejecutarse en instancias spot con descuentos del 60-90% sobre on-demand. Sí, la instancia puede desaparecer con 2 minutos de aviso. Pero si tu pipeline está diseñado para checkpointing y reintento automático, la interrupción es un inconveniente menor, no un desastre.

Usamos AWS Spot Fleet con diversificación de instancias: en lugar de pedir 10 instancias m5.xlarge, pedimos un fleet de m5.xlarge, m5a.xlarge, m5d.xlarge y m4.xlarge. Esto reduce drásticamente la probabilidad de interrupción porque no dependemos de un único pool de capacidad.

Fase 3: Gobierno (semana 7 en adelante)

La optimización sin gobierno es un sprint, no una maratón. Los ahorros se pierden en semanas cuando alguien levanta una instancia “temporal” que se queda para siempre.

Presupuestos por equipo. Cada equipo tiene un presupuesto cloud mensual. No es un límite duro (no cortamos servicios si se excede), pero es un número visible. Cuando un equipo supera su presupuesto, tiene que explicar por qué. Solo eso cambia comportamientos.

Revisión mensual de costes. 30 minutos, una vez al mes. Se revisan los tres mayores incrementos de coste respecto al mes anterior, se identifican recursos zombies (encendidos pero sin tráfico), y se actualizan las reservas. Esta reunión es la pieza más importante del framework porque crea responsabilidad continua.

Automatización de limpieza. Scripts que apagan entornos de desarrollo fuera de horario laboral (lunes a viernes, 8-20h). Scripts que eliminan snapshots de EBS más antiguos de 30 días (salvo los taggeados como críticos). Scripts que detectan load balancers sin targets, elastic IPs sin asociar, y volúmenes EBS sin montar.

Solo esta automatización de limpieza ahorra entre un 8% y un 12% del gasto total, y una vez implementada no requiere esfuerzo humano.

Resultados reales

El cliente del inicio de este artículo bajó de 14.200 a 8.400 euros mensuales en 90 días. Un 41% de reducción.

Desglose: right-sizing ahorró 2.100 euros/mes (redujimos 12 instancias). Reserved Instances ahorró 1.800 euros/mes (6 instancias de base de datos y 4 de API). Limpieza de recursos zombies ahorró 1.300 euros/mes (snapshots, instancias de prueba, un NAT Gateway que nadie usaba). Programación de apagado de entornos de desarrollo ahorró 600 euros/mes.

El esfuerzo total fue de 40 horas de un ingeniero cloud durante 6 semanas. El ROI se alcanzó en el segundo mes.

No es magia. Es visibilidad, disciplina y un proceso repetible. Y para empresas medianas, la diferencia entre tener FinOps y no tenerlo no es un refinamiento marginal. Es la diferencia entre quemar 170.000 euros al año y quemar 100.000. Esos 70.000 euros son un ingeniero senior, o tres proyectos de innovación, o un colchón financiero que un día te salva.

Si tu factura cloud es un misterio, el primer paso es un diagnóstico tecnológico que identifique dónde está el dinero. Porque está en algún sitio. Solo hay que mirarlo. Para empresas con entornos multi-cloud, la optimización FinOps es aún más crítica al multiplicarse las fuentes de gasto. Nuestro equipo de cloud y DevOps implementa frameworks FinOps completos.