Optimización de costos de AWS: una guía de FinOps para equipos SaaS

La mayoría de las empresas SaaS no tienen un problema con la factura de AWS. Tienen un problema de propiedad que se manifiesta en la factura de AWS. Instancias lanzadas para una prueba en marzo siguen corriendo en octubre, una base de datos de staging tiene el tamaño de la de producción y nadie sabe decir qué cliente o funcionalidad genera la partida más grande. La optimización de costos de AWS tiene menos que ver con trucos ingeniosos que con ver adónde va el dinero, eliminar el desperdicio evidente y crear un hábito para que el desperdicio no regrese. Esta guía recorre los tres pasos, en ese orden, con las herramientas de AWS que hacen el trabajo.

Qué significa FinOps para un equipo SaaS pequeño

FinOps es el nombre de ese hábito. La FinOps Foundation lo define como “un marco operativo y una práctica cultural que maximiza el valor de negocio de la tecnología, permite tomar decisiones oportunas basadas en datos y crea responsabilidad financiera mediante la colaboración entre los equipos de ingeniería, finanzas y negocio.”

En una gran empresa, eso significa un equipo de FinOps dedicado. En una empresa SaaS de 20 personas, normalmente significa que un ingeniero, el CTO y quien paga las facturas se ponen de acuerdo en tres cosas: cómo debería verse la factura, quién es dueño de cada parte y cuándo alguien la revisa. La optimización de costos en la nube funciona igual con cualquier proveedor, pero las herramientas que siguen son específicas de AWS.

AWS plantea la misma idea en el pilar de optimización de costos de su Well-Architected Framework. Los tres pasos de abajo son una versión de ese pilar a la medida de un equipo sin departamento de FinOps.

Paso 1: obtén visibilidad antes de recortar nada

No puedes optimizar lo que no puedes atribuir. Empieza por aquí, aunque ya sospeches dónde está el desperdicio.

Activa Cost Explorer y úsalo cada semana. AWS Cost Explorer muestra el gasto por servicio, cuenta, región y tipo de uso, y es donde la mayoría de las demás herramientas de costos muestran sus datos. Agrupa por tipo de uso, no solo por servicio. “EC2-Other” esconde volúmenes EBS, snapshots, cargos de NAT gateway y transferencia de datos, que suelen ser las sorpresas.

Etiqueta los recursos y luego activa las etiquetas. Etiquetas como team, service, environment y customer te permiten dividir la factura según lo que importa a tu negocio. Hay un detalle que atrapa a muchos equipos: una etiqueta en un recurso no sirve para la facturación hasta que la activas como etiqueta de asignación de costos en la consola de Billing and Cost Management, y las etiquetas activadas pueden tardar hasta 24 horas en aparecer. Haz cumplir las etiquetas en tus módulos de Terraform o CloudFormation en lugar de pedirle a la gente que se acuerde.

Exporta los datos detallados. Cuando Cost Explorer no tiene suficiente granularidad, AWS Data Exports entrega el Cost and Usage Report 2.0 (CUR 2.0) a un bucket de S3 con detalle por partida. AWS llama a CUR 2.0 la forma recomendada de recibir datos detallados de costos y uso. Es lo que necesitas para calcular el costo por cliente o el costo por solicitud, que es el número que un negocio SaaS realmente debería vigilar.

Separa los entornos en cuentas. Si producción, staging y desarrollo comparten una sola cuenta de AWS, toda conversación sobre costos empieza con una discusión sobre qué recursos pertenecen a qué entorno. Cuentas separadas bajo AWS Organizations hacen esa división automática.

Paso 2: aprovecha las victorias rápidas

Con la visibilidad lista, la primera ronda de ahorros suele salir de los mismos pocos lugares.

Empieza con AWS Cost Optimization Hub

AWS te señalará muchos de ellos: Cost Optimization Hub consolida las recomendaciones de ajuste de tamaño (rightsizing), recursos inactivos, Savings Plans e Instancias Reservadas de todas tus cuentas y regiones, y los hallazgos de rightsizing y recursos inactivos provienen de AWS Compute Optimizer. Tómalas como una lista de partida, no como una lista de pendientes. Una recomendación de reducir una instancia no sabe que esa instancia ejecuta un proceso por lotes de fin de mes. Tras activarlo, tarda cerca de 24 horas en poblarse, así que enciéndelo pronto.

Recursos inactivos o sobredimensionados

Busca instancias con un uso de CPU y memoria constantemente bajo, balanceadores de carga sin destinos, volúmenes EBS sin conectar y bases de datos que corren las 24 horas en entornos que no son de producción. Los entornos de desarrollo y staging que nadie usa de noche ni los fines de semana se pueden programar para apagarse. Vale la pena hacer el rightsizing con cuidado: cambia una cosa, observa la latencia y las tasas de error durante unos días y sigue con la siguiente.

Almacenamiento

• Pasa los volúmenes gp2 a gp3. AWS indica que los volúmenes gp3 ofrecen un precio por GiB 20 por ciento menor que gp2, con una base de 3,000 IOPS y 125 MiB/s incluidos. El cambio se puede hacer en caliente con Elastic Volumes, sin detener la instancia.
• Elige la clase de almacenamiento de S3 adecuada. Para datos con acceso impredecible, S3 Intelligent-Tiering mueve los objetos a niveles más baratos tras 30 y 90 días sin acceso, por un pequeño cargo de monitoreo. Los objetos de menos de 128 KB no se mueven de nivel, así que ayuda menos en buckets llenos de archivos diminutos. Para datos con acceso predecible, como logs que guardas un año, es más simple usar reglas de ciclo de vida hacia una clase específica.
• Limpia los snapshots. Los snapshots antiguos de EBS y los snapshots manuales de RDS se acumulan en silencio. Elimina lo que no necesites, y para los snapshots que debes conservar 90 días o más, EBS Snapshots Archive ofrece hasta un 75 por ciento menos de costo de almacenamiento, a cambio de una restauración más lenta.

Datos que pasan por NAT gateway

Los NAT gateways cobran por hora y por gigabyte de datos procesado, además de la transferencia de datos normal. Las subredes privadas que descargan imágenes de contenedores, envían logs o leen de S3 a través de un NAT gateway pueden generar una partida grande y fácil de pasar por alto. Los gateway VPC endpoints para S3 y DynamoDB no tienen cargo por hora ni por procesamiento de datos, así que enrutar ese tráfico por ellos suele ser el cambio de red más barato que harás en tu vida. Los interface endpoints de otros servicios sí cuestan, así que compáralos con el tráfico de NAT que reemplazarían.

Savings Plans vs. Instancias Reservadas

Cuando tu uso ya está bien dimensionado, comprométete con la base que sabes que vas a ejecutar. Si te comprometes antes del rightsizing, dejas fijo el desperdicio.

Los Savings Plans intercambian un compromiso de uno o tres años con un gasto por hora por tarifas más bajas. AWS ofrece cuatro tipos:

• Compute Savings Plans, hasta 66% menos que On-Demand, se aplican a todas las familias, tamaños y regiones de instancias EC2, y también a Fargate y Lambda.
• EC2 Instance Savings Plans, hasta 72% menos, requieren una familia de instancias específica en una región específica.
• Database Savings Plans, hasta 35% menos, cubren Aurora, RDS, DynamoDB, ElastiCache y varios otros servicios de bases de datos.
• SageMaker AI Savings Plans cubren el uso de instancias de SageMaker.

Las Instancias Reservadas siguen existiendo para servicios como RDS, ElastiCache, OpenSearch y Redshift, y te atan a una configuración más específica. Para un equipo SaaS en crecimiento cuya arquitectura va a cambiar, la flexibilidad suele importar más que los últimos puntos de descuento, lo que apunta a empezar por los Compute Savings Plans. Cost Explorer genera recomendaciones de Savings Plans a partir de tu uso real, y AWS Budgets puede avisarte cuando baja la utilización o la cobertura, que es como te das cuenta de un compromiso que ya no necesitas.

Paso 3: conviértelo en un proceso, no en un proyecto

Una limpieza de costos sin proceso dura más o menos un trimestre. Estas mejores prácticas de optimización de costos de AWS hacen que los ahorros se mantengan.

Dale un dueño a cada dólar. Cada cuenta, servicio o valor de etiqueta debe corresponder a una persona o equipo que responda por él. Cuando la factura del servicio de búsqueda se duplica, alguien concreto recibe la pregunta.

Define presupuestos y alertas de pronóstico. AWS Budgets puede avisarte sobre el gasto real y sobre el gasto pronosticado, antes de que el dinero se haya ido, y puede activar acciones como aplicar una política de IAM que bloquea nuevos recursos en una cuenta. Define un presupuesto por cuenta y por servicio importante, y envíalo al dueño, no a una bandeja compartida que nadie lee.

Activa la detección de anomalías. AWS Cost Anomaly Detection usa aprendizaje automático para señalar gastos inusuales por servicio, cuenta, etiqueta de asignación de costos o categoría de costos, y puede alertar por correo, SNS o Slack. AWS señala en su FAQ que la detección se apoya en datos de Cost Explorer con hasta 24 horas de latencia, así que detecta un proceso fuera de control al segundo día, no al segundo minuto. Aun así, es mucho mejor que enterarte en la factura.

Revisa cada mes. Treinta minutos al mes con los dueños de los costos bastan para la mayoría de los equipos pequeños: qué cambió, por qué y qué sigue. Haz seguimiento de una métrica unitaria, como el costo de infraestructura por cliente activo, para que el crecimiento no esconda la ineficiencia.

Herramientas de optimización de costos de AWS: qué usar y cuándo

Necesidad	Herramienta de AWS
Ver adónde va el dinero	Cost Explorer
Atribuir el gasto a equipos, servicios, clientes	Etiquetas de asignación de costos, AWS Organizations
Detalle por partida y costos unitarios	Data Exports (CUR 2.0)
Encontrar rightsizing y recursos inactivos	Compute Optimizer, Cost Optimization Hub
Comprometerse con el uso base	Savings Plans, Instancias Reservadas
Detectar el sobregasto a tiempo	AWS Budgets, Cost Anomaly Detection

Ninguna herramienta de optimización de costos de AWS cubre todo esto, y por eso la tabla empareja necesidades con herramientas. Las plataformas de costos de terceros añaden vistas multi-nube, asignación de costos de Kubernetes e informes más cuidados. Vale la pena evaluarlas cuando las herramientas nativas dejen de responder tus preguntas, no antes.

Dónde encaja un agente

La mayor parte de este trabajo no es difícil. Simplemente es fácil de posponer, porque ninguna tarea es urgente por sí sola y las personas que podrían hacerla están ocupadas lanzando producto. Ahí es donde la automatización se gana su lugar: algo tiene que leer los datos de costos todos los días, notar el volumen sin conectar y la flota de gp2, y poner una recomendación clara frente a una persona que pueda decidir.

En Webera, ese es el trabajo de Optimizer, uno de nuestros nueve agentes de IA. Analiza el gasto en la nube, identifica el desperdicio, recomienda rightsizing y capacidad reservada, construye dashboards de costos y alertas de presupuesto, y da seguimiento a los ahorros con el tiempo. Navigator, el agente de redes, revisa los costos de red y la transferencia de datos, incluido el tráfico por NAT gateway. Los agentes proponen; los ingenieros deciden. Dar de baja una instancia o comprar un compromiso de tres años es una decisión que una persona toma junto con tu equipo, no algo que un agente haga por su cuenta.

El trabajo de costos también se cruza con la confiabilidad. Un rightsizing demasiado agresivo causa incidentes, y esa es una razón por la que debe estar en manos del equipo que carga con la guardia. Nuestros artículos sobre site reliability engineering vs. DevOps y gestión de incidentes para SaaS cubren ese lado. Para una visión más amplia de lo que asume un equipo externo, mira lo que reemplaza una suscripción de DevOps administrada.

Preguntas frecuentes

¿Cuáles son los cinco pilares de la optimización de costos en AWS?

En rigor, la optimización de costos es uno de los seis pilares del AWS Well-Architected Framework. Dentro de ese pilar, AWS agrupa su guía en cinco áreas: practicar la gestión financiera de la nube (Cloud Financial Management), conocer el gasto y el uso, usar recursos rentables, administrar la oferta y la demanda de recursos, y optimizar con el tiempo. A esas cinco se refiere la gente cuando habla de los cinco pilares de la optimización de costos de AWS.

¿La optimización de costos de AWS es gratis?

En parte. Cost Optimization Hub no tiene cargo adicional, y Cost Explorer, Budgets y Cost Anomaly Detection están en la consola de Billing and Cost Management, aunque revisa el precio de cada uno antes de depender de él a gran escala. Lo que cuesta dinero es el tiempo para actuar sobre los hallazgos, y los compromisos como los Savings Plans, que bajan las tarifas a cambio de un compromiso de gasto de uno o tres años.

¿Por qué AWS cuesta tanto?

Para la mayoría de los equipos SaaS, la factura es alta por un desperdicio que nadie tiene a su cargo, más que por las tarifas de AWS: instancias de prueba olvidadas, staging del tamaño de producción, volúmenes sin conectar, snapshots viejos y cargos por datos de NAT gateway. Sin etiquetas y sin un dueño para cada parte de la factura, esos costos crecen en silencio.

¿Cómo optimizar el costo de EC2?

Empieza por hacer rightsizing de las instancias con un uso de CPU y memoria constantemente bajo, tomando los hallazgos de Compute Optimizer como lista de partida, y programa el apagado de las instancias que no son de producción por las noches y los fines de semana. Pasa los volúmenes gp2 a gp3 y limpia los snapshots viejos. Cuando el uso ya esté bien dimensionado, cubre la base estable con Compute Savings Plans o EC2 Instance Savings Plans.

Pon FinOps en el plato de alguien

Webera es una suscripción de DevOps para equipos SaaS en AWS: ingenieros senior más nueve agentes de IA, con monitoreo 24/7 y respuesta a incidentes y solicitudes ilimitadas en todos los planes. Pro cuesta US$4,999 al mes, Elite US$9,999 y Platform US$14,999, cada uno con un mínimo de tres meses y, después, mes a mes. Todo el código y la configuración son tuyos.

Si tu factura de AWS no deja de crecer y nadie se hace cargo, compara los planes y mira qué haría falta para que revisar los costos sea un hábito semanal y no una carrera anual.