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 que porcentaje de esa factura podian explicar linea por linea, la respuesta fue “quiza un 60%”. El 40% restante era un misterio distribuido entre instancias que alguien levanto para una prueba hace ocho meses, snapshots de EBS acumulados desde 2022, y transferencia de datos entre regiones que nadie habia cuestionado.

Esa es la realidad de la mayoria de empresas medianas en cloud. No es que gasten demasiado a proposito. Es que no tienen visibilidad sobre lo que gastan, y sin visibilidad no hay optimizacion posible.

Segun la FinOps Foundation, FinOps no es una herramienta. Es una practica operativa que convierte el gasto cloud en una decision de negocio consciente. Y para una empresa que gasta entre 5.000 y 50.000 euros mensuales en cloud, implementar FinOps basico puede generar ahorros del 30-45% en los primeros 90 dias.

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 (quien lo creo), proyecto (para que sirve), y entorno (produccion, staging, desarrollo). Sin tags, tu factura es un muro de lineas anonimas. AWS Cost Explorer y GCP Billing distinguen por tags. Sin ellos, esas herramientas son inútiles.

Implementamos una politica de tag-or-terminate: cualquier recurso sin tags despues de 72 horas recibe una alerta. Despues 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 dia, 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 ingenieria no es opcional.

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

Fase 2: Optimizacion (semanas 3-6)

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

Right-sizing. La mayoria de instancias estan sobredimensionadas. Es natural: nadie quiere que produccion se caiga porque le faltan recursos, asi que se pide un t3.xlarge “por si acaso” cuando un t3.medium seria suficiente.

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

El truco esta en no hacerlo todo a la vez. Empezamos por instancias de desarrollo y staging (bajo riesgo). Despues pasamos a produccion, una instancia cada vez, con monitorizacion de rendimiento durante 48 horas antes de confirmar. El right-sizing tipico ahorra entre un 15% y un 25% del gasto en computo.

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

La regla que usamos: cualquier instancia que haya tenido una utilizacion superior al 70% durante los ultimos 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 comun: 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 integracion, batch processing, entornos de desarrollo efimeros. Todo esto puede ejecutarse en instancias spot con descuentos del 60-90% sobre on-demand. Si, la instancia puede desaparecer con 2 minutos de aviso. Pero si tu pipeline esta disenado para checkpointing y reintento automatico, la interrupcion es un inconveniente menor, no un desastre.

Usamos AWS Spot Fleet con diversificacion 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 drasticamente la probabilidad de interrupcion porque no dependemos de un unico pool de capacidad.

Fase 3: Gobierno (semana 7 en adelante)

La optimizacion sin gobierno es un sprint, no una maraton. 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 limite duro (no cortamos servicios si se excede), pero es un numero visible. Cuando un equipo supera su presupuesto, tiene que explicar por que. Solo eso cambia comportamientos.

Revision 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 trafico), y se actualizan las reservas. Esta reunion es la pieza mas importante del framework porque crea responsabilidad continua.

Automatizacion de limpieza. Scripts que apagan entornos de desarrollo fuera de horario laboral (lunes a viernes, 8-20h). Scripts que eliminan snapshots de EBS mas antiguos de 30 dias (salvo los taggeados como criticos). Scripts que detectan load balancers sin targets, elastic IPs sin asociar, y volúmenes EBS sin montar.

Solo esta automatizacion 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 articulo bajo de 14.200 a 8.400 euros mensuales en 90 dias. Un 41% de reduccion.

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

El esfuerzo total fue de 40 horas de un ingeniero cloud durante 6 semanas. El ROI se alcanzo 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 ano y quemar 100.000. Esos 70.000 euros son un ingeniero senior, o tres proyectos de innovacion, o un colchon financiero que un dia te salva.

Si tu factura cloud es un misterio, el primer paso es un diagnostico tecnologico que identifique donde esta el dinero. Porque esta en algun sitio. Solo hay que mirarlo. Para empresas con entornos multi-cloud, la optimizacion FinOps es aun mas critica al multiplicarse las fuentes de gasto. Nuestro equipo de cloud y DevOps implementa frameworks FinOps completos.