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:
- 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.
- 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).
- 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.
- 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
- 1.1 El modelo cliente-servidor tradicional
- 1.2 Problemas que venía a resolver la nube
- 1.3 On-premise vs cloud vs híbrido
- 1.4 Los tres modelos de servicio: IaaS, PaaS, SaaS
- 1.5 Los cinco pilares del cloud (según NIST)
- 1.6 Ventajas reales: elasticidad, pago por uso, disponibilidad global
Capítulo 2 · El mercado cloud y los grandes proveedores
- 2.1 AWS, Azure y GCP: diferencias y cuotas de mercado
- 2.2 Por qué aprender AWS primero
- 2.3 Conceptos que son universales entre proveedores
Capítulo 3 · Regiones, zonas de disponibilidad y edge
- 3.1 Qué es una región AWS y cómo elegirla
- 3.2 Availability Zones: alta disponibilidad desde el diseño
- 3.3 Edge locations y CloudFront
- 3.4 Latencia, resiliencia y soberanía de datos
Capítulo 4 · Cómputo: EC2
- 4.1 Instancias: tipos, familias y cuándo elegir cada una
- 4.2 AMIs, key pairs y Security Groups
- 4.3 Ciclo de vida de una instancia
- 4.4 Elastic IPs y Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítulo 5 · Almacenamiento: S3
- 5.1 Buckets, objetos y claves
- 5.2 Clases de almacenamiento (Standard, IA, Glacier…)
- 5.3 Versionado y ciclo de vida de objetos
- 5.4 Políticas de bucket y ACLs
- 5.5 Hosting de sitios web estáticos
Capítulo 6 · Redes: VPC
- 6.1 Qué es una VPC y por qué la necesitas
- 6.2 Subredes públicas y privadas
- 6.3 Internet Gateway y NAT Gateway
- 6.4 Route Tables y Network ACLs
- 6.5 VPC Peering y endpoints
Capítulo 7 · Identidad y acceso: IAM
- 7.1 Usuarios, grupos, roles y políticas
- 7.2 El principio de mínimo privilegio
- 7.3 Políticas basadas en identidad vs en recurso
- 7.4 MFA y credenciales temporales (STS)
- 7.5 Buenas prácticas de seguridad IAM
Capítulo 8 · Bases de datos gestionadas
- 8.1 RDS: motores, Multi-AZ y réplicas de lectura
- 8.2 Aurora y sus ventajas sobre RDS vanilla
- 8.3 DynamoDB: modelo clave-valor / documentos
- 8.4 ElastiCache para caché en memoria
- 8.5 Cuándo usar cada tipo de base de datos
Capítulo 9 · Por qué Infraestructura como Código
- 9.1 Problemas del aprovisionamiento manual
- 9.2 IaC declarativo vs imperativo
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El ciclo plan → apply → destroy
Capítulo 10 · HCL: el lenguaje de Terraform
- 10.1 Bloques resource, variable, output, locals
- 10.2 Tipos de datos: string, number, bool, list, map, object
- 10.3 Expresiones, referencias y funciones built-in
- 10.4 Condicionales y bucles (count, for_each, for)
Capítulo 11 · Providers y estado
- 11.1 Cómo funciona el provider de AWS
- 11.2 El fichero terraform.tfstate y su importancia
- 11.3 State local vs state remoto (S3 + DynamoDB)
- 11.4 Comandos esenciales: init, plan, apply, destroy, fmt, validate
Capítulo 12 · Tu primera infraestructura real en Terraform
- 12.1 Crear una VPC con subredes desde cero
- 12.2 Levantar una instancia EC2 pública
- 12.3 Asociar un Security Group y una Elastic IP
- 12.4 Outputs y referencias entre recursos
- 12.5 Flujo de trabajo en equipo: PR review de planes
Capítulo 13 · Balanceo de carga y autoescalado
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners y reglas
- 13.3 Auto Scaling Groups: políticas y métricas
- 13.4 Warm pools y lifecycle hooks
Capítulo 14 · Serverless con Lambda
- 14.1 El modelo de ejecución de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestión de dependencias y capas (Layers)
- 14.4 Cold starts y estrategias para reducirlos
- 14.5 Límites y antipatrones
Capítulo 15 · Mensajería y eventos
- 15.1 SQS: colas estándar vs FIFO, DLQ
- 15.2 SNS: topics, suscripciones, fan-out
- 15.3 EventBridge: event buses y reglas
- 15.4 Patrones: pub/sub, desacoplamiento, saga
Capítulo 16 · Entrega de contenido y DNS
- 16.1 Route 53: tipos de registros y routing policies
- 16.2 CloudFront: distribuciones, cachés y origins
- 16.3 ACM: certificados SSL/TLS gratuitos
- 16.4 WAF integrado con CloudFront
Capítulo 17 · Contenedores en AWS
- 17.1 Docker: repaso exprés de conceptos clave
- 17.2 ECR: registro privado de imágenes
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: cuándo Kubernetes y cuándo no
Capítulo 18 · Módulos: reutilización y composición
- 18.1 Anatomía de un módulo Terraform
- 18.2 Variables de entrada, outputs y dependencias
- 18.3 Módulos locales vs módulos del Terraform Registry
- 18.4 Versionado de módulos con Git tags
- 18.5 Diseño de módulos genéricos vs específicos de dominio
Capítulo 19 · Workspaces y gestión de entornos
- 19.1 Workspaces de Terraform: casos de uso y limitaciones
- 19.2 Estrategia de directorios por entorno (dev/stg/prod)
- 19.3 Terragrunt: DRY para configuraciones de entorno
- 19.4 Variables de entorno y archivos .tfvars
Capítulo 20 · Backends remotos y locking
- 20.1 Configurar S3 + DynamoDB como backend
- 20.2 State locking: evitar corrupción en equipo
- 20.3 Migración de estado entre backends
- 20.4 terraform import: traer recursos existentes al estado
Capítulo 21 · Testing de infraestructura
- 21.1 Terraform validate y fmt en CI
- 21.2 Checkov y tfsec: análisis de seguridad estático
- 21.3 Terratest: tests de integración en Go
- 21.4 Contract testing entre módulos
Capítulo 22 · Terraform en CI/CD
- 22.1 Pipeline básico: lint → plan → apply en GitHub Actions
- 22.2 Atlantis: GitOps para Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection y reconciliación automática
Capítulo 23 · Seguridad en profundidad
- 23.1 AWS Organizations y Service Control Policies
- 23.2 AWS Config: compliance continuo
- 23.3 GuardDuty: detección de amenazas
- 23.4 Security Hub: visión centralizada
- 23.5 KMS: gestión de claves y rotación
- 23.6 Secrets Manager vs Parameter Store
Capítulo 24 · Observabilidad: logs, métricas y trazas
- 24.1 CloudWatch Logs, métricas y alarmas
- 24.2 CloudWatch Dashboards y Contributor Insights
- 24.3 X-Ray: trazado distribuido
- 24.4 OpenTelemetry en AWS
- 24.5 Managed Grafana y Managed Prometheus
Capítulo 25 · Optimización de costes
- 25.1 AWS Cost Explorer y presupuestos con alertas
- 25.2 Trusted Advisor y Compute Optimizer
- 25.3 Rightsizing: cómo detectar sobredimensionamiento
- 25.4 Savings Plans vs Reserved Instances: decisión estratégica
- 25.5 FinOps: cultura y procesos para controlar el gasto
Capítulo 26 · Alta disponibilidad y disaster recovery
- 26.1 RTO y RPO: definir los objetivos
- 26.2 Estrategias: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks y failover automático
- 26.4 AWS Backup: política centralizada de copias
Capítulo 27 · Well-Architected Framework de AWS
- 27.1 Los seis pilares: excelencia operacional, seguridad, fiabilidad, eficiencia de rendimiento, optimización de costes, sostenibilidad
- 27.2 Well-Architected Tool: revisiones formales
- 27.3 Cómo aplicar el framework en decisiones de diseño
Capítulo 28 · Arquitecturas serverless a escala
- 28.1 Event-driven architecture con Lambda + EventBridge
- 28.2 Saga pattern para transacciones distribuidas
- 28.3 Step Functions: orquestación de workflows complejos
- 28.4 Lambda@Edge y CloudFront Functions
Capítulo 29 · Plataformas de datos en AWS
- 29.1 Data Lake con S3, Glue y Athena
- 29.2 Kinesis Data Streams y Firehose para streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: gobierno del dato
Capítulo 30 · Multi-cuenta y landing zones
- 30.1 Por qué separar workloads en cuentas distintas
- 30.2 AWS Control Tower y Account Factory
- 30.3 Gestión centralizada de logs y seguridad
- 30.4 Terraform a escala multi-cuenta con módulos compartidos
Capítulo 31 · Platform Engineering e Internal Developer Platform
- 31.1 Golden paths y abstracciones sobre Terraform
- 31.2 Service Catalog de AWS
- 31.3 Backstage como portal de desarrolladores
- 31.4 Módulos Terraform como producto interno
Capítulo 32 · Certificaciones AWS relevantes
- 32.1 Cloud Practitioner: ¿vale la pena?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Capítulo 33 · Proyectos para consolidar lo aprendido
- 33.1 Proyecto 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Proyecto 2: API REST con ECS Fargate + RDS + ALB
- 33.3 Proyecto 3: plataforma de datos con Glue + Athena + Redshift
- 33.4 Proyecto 4: landing zone multi-cuenta con Terraform y Control Tower
