Cloud FinOps en la práctica: Reduciendo gastos en AWS y GCP sin reducir la velocidad de entrega

En los centros de datos tradicionales, la compra de un servidor exigía la aprobación de gastos de capital por parte del director financiero, un ciclo de compras y un plazo de entrega de hardware de seis semanas. En la nube pública, un desarrollador junior puede alterar una única línea en un archivo de Terraform o en un manifiesto de implementación de Kubernetes a las 16:45, crear un clúster de instancias de GPU o de base de datos con mucha memoria y añadir silenciosamente US$ 15.000 al mes a los gastos operativos de la empresa antes de que cualquier persona del sector financiero vea una factura.

La computación en nube descentralizó la adquisición de infraestructura hacia la punta de la ingeniería, lo que resultó fenomenal para la velocidad de implementación y desastroso para la gobernanza de costos cuando se dejó sin control.

De acuerdo con las referencias anuales de la industria del Flexera State of the Cloud Report y de la FinOps Foundation, las empresas desperdician cerca de 27% a 32% de sus gastos totales en la nube en computación sobredimensionada, entornos ociosos, capas de almacenamiento no optimizadas y tasas de transferencia de red evitables.

Sin embargo, cuando la directiva entra en pánico debido a la reducción de los márgenes brutos y exige un corte inmediato del 25% en los gastos con AWS, Google Cloud (GCP) o Azure, lo peor que puede hacer un director de tecnología es imponer un congelamiento general en las hojas de ruta de productos. El verdadero FinOps no consiste en sofocar la ingeniería, sino en la eliminación quirúrgica de desperdicios arquitectónicos. Este es el plan de ejecución de 90 días que reduce consistentemente los gastos en la nube del 25% al 45% sin desacelerar una sola liberación de producto.

1. Días 1 y 15: Visibilidad, Etiquetado y Eliminación de Infraestructura Zombi

No puedes optimizar lo que no puedes atribuir. Las primeras dos semanas de cualquier reestructuración de FinOps se concentran en el establecimiento de etiquetas de asignación de costos (environment, service, squad, cost-center) y en la eliminación de desperdicios de riesgo cero que no exigen ninguna refactorización de código:

• Almacenamiento de Bloques no Asociado e Instantáneas Huérfanas: Cuando las instancias de EC2 o Compute Engine se cierran, sus volúmenes de Elastic Block Store (EBS) y años de instantáneas diarias automatizadas frecuentemente permanecen, generando cobros mes tras mes.
• Balanceadores de Carga Ociosos e IPs Elásticas: Los microservicios descontinuados hace seis meses generalmente dejan atrás Application Load Balancers (ALB) huérfanos y direcciones IPv4 públicas no utilizadas.
• Cronogramas de Apagado fuera de Producción: ¿Por qué los clústeres de dev, qa y staging funcionan 168 horas a la semana si los ingenieros trabajan solo entre 45 y 50 horas a semana? Automatizar el dimensionamiento de instancias fuera de producción a cero entre las 20:00 y las 7:00 en los días hábiles y durante todo el fin de semana reduce inmediatamente 65% de los costos de computación fuera de producción.
• Políticas de Ciclo de Vida de S3 / Almacenamiento en la Nube: La aplicación de transiciones automáticas (como S3 Intelligent-Tiering o la transferencia de registros de aplicaciones con más de 30 días a Glacier) reduce rutinariamente las facturas de almacenamiento en 40% a 60% de la noche a la mañana.

2. Días 16 y 45: Redimensionamiento de Computación, Solicitudes de Kubernetes y Migración a ARM

Tan pronto como los recursos zombis son eliminados, el siguiente objetivo es la utilización de la computación. En clústeres típicos de Kubernetes corporativos (EKS, GKE, AKS), la utilización real promedio de CPU se encuentra por debajo de 18%, mientras que la utilización de memoria se acerca a 30%.

¿Por qué? Porque los desarrolladores copian y pegan requests y limits de plantillas YAML antiguas, solicitando 2 vCPUs y 8 GB de RAM para un microservicio que alcanza picos de 0,15 vCPUs y 600 MB. Como el programador de Kubernetes asigna nodos con base en la capacidad solicitada y no en el uso real, el escalador automático del clúster crea decenas de nodos caros que permanecen 80% vacíos.

Simultáneamente, la recompilación de servicios contenedorizados (Node.js, Python, Go, Java, .NET 8+) y bases de datos administradas (RDS, Aurora, ElastiCache) para ejecutarse en procesadores basados en ARM (como AWS Graviton o GCP Tau T2A) ofrece una mejora inmediata de 20% a 35% en la relación precio-rendimiento con el mínimo esfuerzo de ingeniería.

3. Días 46 y 75: Eliminación de Impuestos Ocultos (Gateways NAT, Cross-AZ y Observabilidad)

Algunas de las líneas más dolorosas en una factura de la nube no tienen nada que ver con CPU o almacenamiento:

1. La Trampa del Gateway NAT: En AWS y en GCP, los Gateways NAT administrados cobran tanto por hora como por gigabyte de datos procesados. Auditamos rutinariamente a empresas que gastan más de US$ 8.000 al mes en Gateways NAT simplemente porque las subredes privadas están extrayendo terabytes de imágenes Docker de ECR o leyendo archivos de S3 a través de un Gateway NAT en lugar de usar un Gateway VPC Endpoint gratuito. Añadir cinco líneas de Terraform para aprovisionar un VPC Endpoint de S3/DynamoDB reduce esa tasa de transferencia a US$ 0.
2. Tráfico de Comunicación entre Zonas de Disponibilidad (Cross-AZ): Los proveedores de nube cobran de US$ 0,01 a US$ 0,02 por GB cada vez que un microservicio en us-east-1a se comunica con un agente de Kafka, una caché de Redis o una base de datos en us-east-1b. Habilitar el enrutamiento sensible a la topología en Kubernetes y comprimir cargas útiles elimina miles de dólares en fugas silenciosas de red.
3. Carga Excesiva de Observabilidad: Enviar registros detallados de DEBUG e INFO desde servicios de alto rendimiento hacia Datadog, New Relic o CloudWatch sin muestreo generalmente resulta en una factura de observabilidad que supera 20% de todo el presupuesto de infraestructura. Filtra el ruido de comprobación de integridad en el borde del colector y separa los registros fríos para un almacenamiento de objetos económico.

4. Dias 76, 90: Compromisos y Economía Unitaria

Observe que los compromisos financieros (Reserved Instances y Compute Savings Plans) vienen al final, nunca al principio. Si usted firma un Savings Plan de tres años en la Semana 1 en una arquitectura abultada y sobredimensionada, acaba de bloquear su desperdicio durante 36 meses. Solo después de la eliminación de los activos zombis, el redimensionamiento de los pods de Kubernetes y la conclusión de las migraciones a ARM es cuando debe cerrar Savings Plans de 1 a 3 años para cubrir del 70% al 80% de su carga base constante limpia, mientras usa instancias Spot/Preemptibles (por medio de Karpenter) para cargas de trabajo en lote y de CI/CD tolerantes a fallos.

Por último, el FinOps maduro cambia la conversación del gasto mensual total a la Economía Unitaria: midiendo el costo de nube por 1.000 transacciones de API, costo por inquilino activo o costo como porcentaje de los ingresos brutos (COGS). Cuando cada equipo ve el impacto del costo unitario de sus solicitudes pull directamente al lado de la latencia y de las tasas de error, la eficiencia de costos se convierte en un hábito permanente de ingeniería en lugar de una emergencia anual.

Continúe leyendo: explore FinOps 2030: Zero Cost Is Not the Goal y ROI Is King: Why Software Engineering Must Answer to Unit Economics.

---

Referencias verificables y lectura adicional

• FinOps Foundation (2025). FinOps Framework & State of FinOps Report. Linux Foundation.
• FinOps Foundation (2025). Cloud Unit Economics Playbook.
• Storment, J. R., & Fuller, M. (2023). Cloud FinOps: Collaborative, Real-Time Cloud Value Decision Making (2nd Edition). O'Reilly Media.