Hemos visto herramientas (Cost Explorer, Budgets, Trusted Advisor) y técnicas (rightsizing, Savings Plans) para ahorrar. Pero gestionar costes en la nube no es solo cuestión de herramientas: es una forma de trabajar en equipo, una cultura. Esa disciplina tiene nombre propio: FinOps. Cerramos el capítulo de costes entendiendo qué es y por qué se ha vuelto tan importante en las empresas que operan en la nube.

El problema: en la nube, cualquiera puede gastar

En el modelo tradicional (servidores físicos), gastar dinero en infraestructura era un proceso lento y centralizado: alguien tenía que aprobar la compra de un servidor, pasaba por el departamento de compras, tardaba semanas. El gasto estaba controlado por pocas personas.

En la nube, esto cambia radicalmente: cualquier desarrollador puede, con unas líneas de Terraform o unos clics, crear recursos que cuestan dinero al instante. Esto es maravilloso para la agilidad (recuerda el self-service del subcapítulo 1.2), pero crea un problema nuevo:

Modelo tradicional:  gastar = proceso lento, centralizado, controlado
Modelo nube:         gastar = instantáneo, descentralizado, cualquiera puede
   → enorme agilidad, PERO el coste se puede descontrolar fácilmente

Si nadie se responsabiliza de los costes, cada equipo crea recursos sin pensar en el gasto, y la factura crece sin control. Hace falta una nueva forma de gestionar el dinero en la nube: FinOps.

Qué es FinOps

FinOps (de Financial Operations) es una disciplina y cultura para gestionar los costes de la nube de forma colaborativa, juntando a los equipos técnicos, financieros y de negocio para que tomen decisiones de gasto informadas y responsables. La idea central: el coste de la nube es responsabilidad de todos, no solo del departamento de finanzas.

   FinOps une a tres mundos que antes iban por separado:
   
   👩‍💻 Equipos técnicos  ──┐
   💰 Finanzas           ──┼──►  decisiones de gasto INFORMADAS,
   📊 Negocio            ──┘     responsables y colaborativas

Analogía: FinOps es como gestionar bien el presupuesto de una familia en la que todos colaboran. No es que solo uno controle el dinero mientras los demás gastan sin pensar; es que toda la familia entiende cuánto se gana, en qué se gasta, y cada uno es consciente y responsable de sus gastos. Si todos colaboran y tienen visibilidad, el presupuesto se gestiona sano. Si solo uno vigila y los demás ignoran el coste, el descontrol está garantizado.

Los principios de FinOps

FinOps se basa en algunas ideas clave:

  1. Visibilidad: todos ven lo que cuesta

Para que la gente sea responsable del coste, primero tiene que verlo. FinOps promueve que cada equipo conozca cuánto cuesta lo que ellos usan (gracias a las etiquetas y a Cost Explorer, subcapítulo 25.1). No puedes responsabilizarte de algo que no ves.

  1. Responsabilidad: cada equipo es dueño de su coste

Cada equipo se hace responsable del gasto de sus propios recursos. El coste deja de ser «un problema de finanzas» y pasa a ser parte del trabajo de cada equipo técnico, que considera el coste al diseñar y operar (igual que considera el rendimiento o la seguridad).

  1. Optimización continua: mejorar siempre

FinOps no es algo que se hace una vez, sino un proceso continuo de revisar y mejorar: aplicar rightsizing (25.3), comprar Savings Plans cuando convenga (25.4), eliminar lo que no se usa, etc., de forma habitual.

  1. Colaboración: técnicos, finanzas y negocio juntos

La decisión de gasto se toma entre todos, con cada parte aportando su visión: los técnicos saben qué se puede optimizar, finanzas entiende el presupuesto, y negocio sabe qué valor aporta cada gasto.

Principios FinOps:
   👁️  Visibilidad           → todos ven los costes
   🙋  Responsabilidad       → cada equipo es dueño de su gasto
   🔄  Optimización continua → revisar y mejorar siempre
   🤝  Colaboración          → técnicos + finanzas + negocio juntos

El equilibrio: no se trata solo de gastar menos

Un matiz importante: FinOps no consiste en gastar lo mínimo a toda costa. Consiste en gastar de forma inteligente, obteniendo el máximo valor por cada euro. A veces lo correcto es gastar más (en un recurso que genera mucho valor de negocio), y a veces es recortar. FinOps busca que cada decisión de gasto esté justificada por el valor que aporta.

Recortar costes a ciegas puede ser tan malo como derrochar: si recortas algo que sostiene un servicio que genera ingresos, pierdes más de lo que ahorras. FinOps busca el equilibrio entre coste y valor.

Ejemplo del mundo real: una empresa con la factura de la nube creciendo sin control implanta una cultura FinOps. Empiezan etiquetando todos los recursos por equipo y dando a cada equipo un dashboard con su gasto (visibilidad). Cada equipo asume la responsabilidad de su factura. Se reúnen mensualmente técnicos, finanzas y un responsable de negocio para revisar costes (colaboración) y deciden optimizaciones (rightsizing, Savings Plans). En seis meses, no solo reducen la factura un 30 %, sino que además entienden por qué gastan lo que gastan y cada euro está justificado. Lo más valioso no es el ahorro puntual, sino la cultura: ahora el coste se piensa desde el principio, no como un susto a fin de mes.

Cómo cierra el capítulo de costes

Todo lo visto en el Capítulo 25 forma parte de FinOps:

FinOps (la cultura y disciplina, este subcapítulo)
   ├── Visibilidad y control → Cost Explorer, Budgets (25.1)
   ├── Recomendaciones       → Trusted Advisor, Compute Optimizer (25.2)
   ├── Ajuste de tamaño      → Rightsizing (25.3)
   └── Descuentos            → Savings Plans, Reserved Instances (25.4)

Las herramientas y técnicas son el «cómo»; FinOps es el «cómo trabajamos juntos» para usarlas bien de forma continua.

Lo que debes recordar

  • En la nube, cualquiera puede gastar al instante (gran agilidad, pero el coste se puede descontrolar). Hace falta una nueva forma de gestionarlo: FinOps.
  • FinOps es una disciplina y cultura para gestionar los costes de la nube de forma colaborativa, uniendo equipos técnicos, financieros y de negocio para tomar decisiones de gasto informadas y responsables. Como gestionar bien el presupuesto familiar entre todos.
  • Principios: visibilidad (todos ven los costes), responsabilidad (cada equipo es dueño de su gasto), optimización continua (mejorar siempre) y colaboración (técnicos + finanzas + negocio).
  • No se trata de gastar lo mínimo, sino de gastar de forma inteligente, con el máximo valor por euro; a veces lo correcto es gastar más. Es equilibrio entre coste y valor.
  • Las herramientas y técnicas del capítulo (Cost Explorer, Budgets, rightsizing, Savings Plans) son el «cómo»; FinOps es «cómo trabajamos juntos» para aplicarlas de forma continua.

¡Has completado el Capítulo 25 y dominas la optimización de costes en la nube! En el Capítulo 26, que cierra la Parte VI, abordaremos cómo asegurar que tus sistemas resistan fallos y desastres: la alta disponibilidad y la recuperación ante desastres.

Cloud, AWS & Terraform — De cero a experto

Capítulo 1 · Qué es el cloud computing

Capítulo 2 · El mercado cloud y los grandes proveedores

Capítulo 3 · Regiones, zonas de disponibilidad y edge

Capítulo 4 · Cómputo: EC2

Capítulo 5 · Almacenamiento: S3

Capítulo 6 · Redes: VPC

Capítulo 7 · Identidad y acceso: IAM

Capítulo 8 · Bases de datos gestionadas

Capítulo 9 · Por qué Infraestructura como Código

Capítulo 10 · HCL: el lenguaje de Terraform

Capítulo 11 · Providers y estado

Capítulo 12 · Tu primera infraestructura real en Terraform

Capítulo 13 · Balanceo de carga y autoescalado

Capítulo 14 · Serverless con Lambda

Capítulo 15 · Mensajería y eventos

Capítulo 16 · Entrega de contenido y DNS

Capítulo 17 · Contenedores en AWS

Capítulo 18 · Módulos: reutilización y composición

Capítulo 19 · Workspaces y gestión de entornos

Capítulo 20 · Backends remotos y locking

Capítulo 21 · Testing de infraestructura

Capítulo 22 · Terraform en CI/CD

Capítulo 23 · Seguridad en profundidad

Capítulo 24 · Observabilidad: logs, métricas y trazas

Capítulo 25 · Optimización de costes

Capítulo 26 · Alta disponibilidad y disaster recovery

Capítulo 27 · Well-Architected Framework de AWS

Capítulo 28 · Arquitecturas serverless a escala

Capítulo 29 · Plataformas de datos en AWS

Capítulo 30 · Multi-cuenta y landing zones

Capítulo 31 · Platform Engineering e Internal Developer Platform

Capítulo 32 · Certificaciones AWS relevantes

Capítulo 33 · Proyectos para consolidar lo aprendido

Capítulo 34 · Recursos y comunidad

© Copyright 2024. Todos los derechos reservados