Hola a todos, Jules Martin aquí, de regreso en agntmax.com. Espero que estén teniendo un gran día. Hoy quiero hablar sobre algo que me ha estado preocupando últimamente, algo que he visto aparecer en más conversaciones y post-mortems de proyectos de lo que me gustaría admitir: el arrastre invisible de costos de infraestructura no optimizados. Todos sabemos que necesitamos construir rápido, escalar rápidamente y entregar características ayer. Pero a menudo, en esa carrera frenética, dejamos una estela de recursos olvidados, instancias sobredimensionadas y servicios funcionando en piloto automático, acumulando facturas a las que apenas echamos un vistazo hasta que la revisión presupuestaria trimestral llega como un tonelada de ladrillos.
Así que, para este artículo, estoy profundizando de lleno en optimización de costos, pero con un ángulo muy específico y oportuno: cómo dejar de perder dinero en recursos que deberían estar “bajo demanda” o “activados por eventos.” Es 2026, gente. Los días de aprovisionamiento de servidores y olvidarse de ello han quedado atrás. Si tu factura de nube aún se parece a un directorio telefónico, es hora de una intervención.
El Asesino Silencioso: Siempre Activo Cuando Debería Ser Bajo Demanda
Seamos realistas. Cuando estamos bajo presión para sacar una nueva herramienta para agentes o una mejora en el servicio al cliente, el costo suele quedar en segundo plano frente a la funcionalidad y la velocidad. Aprovisionamos una instancia de EC2 que es “suficientemente grande”, quizás incluso “un poco más grande por si acaso.” Iniciamos una base de datos con IOPS aprovisionados que podrían manejar toda la internet, solo para que permanezca casi inactiva durante las horas fuera de pico. Olvidamos configurar políticas de escalado adecuadas, o simplemente dejamos las cosas funcionando 24/7 porque, bueno, es más fácil que pensarlo.
Vi esto de primera mano hace unos meses con el nuevo panel de análisis interno de un cliente. El equipo, benditos sean, había construido un sistema fantástico que daba a los agentes información en tiempo real sobre las interacciones con los clientes. Fue una gran victoria en términos de rendimiento. Pero cuando llegó la primera factura completa de la nube, el CFO casi sufre un paro cardíaco. Habían aprovisionado un solido clúster de EKS, un par de instancias de RDS de alta gama y un montón de funciones de Lambda con asignaciones de memoria generosas, todas funcionando sin parar. ¿La sorpresa? El panel se usaba principalmente por los agentes durante el horario laboral, de 9 AM a 5 PM, de lunes a viernes. Fuera de eso, era un pueblo fantasma.
Estaban pagando por capacidad de grado empresarial para un sistema que estaba efectivamente inactivo el 70% de la semana. Eso es como comprar un coche de Fórmula 1 para ir al supermercado una vez a la semana.
Identifica a los Culpables: A Dónde Va Realmente Tu Dinero
Antes de poder solucionar cualquier cosa, necesitas saber qué está roto. La mayoría de los proveedores de nube ofrecen herramientas para ayudarte a visualizar tu gasto, y absolutamente necesitas usarlas. AWS Cost Explorer, Azure Cost Management, informes de Google Cloud Billing: no son solo para finanzas. Son tu primera línea de defensa.
Los Sospechosos Habituales
- Instancias de Cómputo (EC2, VMs): Estas son a menudo las más problemáticas. ¿Son sobredimensionadas? ¿Están funcionando cuando no necesitan estarlo? ¿Estás usando la familia de instancias correcta para tu carga de trabajo?
- Base de Datos (RDS, Azure SQL, Cloud SQL): Similar al cómputo, las bases de datos pueden estar sobredimensionadas en IOPS, CPU o memoria. Muchas ahora ofrecen opciones serverless que escalan hasta cero o cerca de cero costo cuando están inactivas.
- Almacenamiento (volúmenes EBS, discos no adjuntos): ¿Alguna vez lanzaste una instancia, la terminaste, pero dejaste el volumen de almacenamiento asociado por ahí? Sucede más a menudo de lo que piensas.
- Redes (Transferencia de datos, NAT Gateways): Los costos de transferencia de datos pueden acumularse rápidamente, especialmente entre regiones. Los NAT Gateways también tienen un cargo por hora, incluso si no están haciendo nada.
- Servicios Infrautilizados: ¿Estás pagando por un cache de Redis dedicado que solo recibe unos pocos accesos al día? ¿Un clúster de Kafka administrado para un goteo de mensajes?
Mi cliente de la historia del panel de análisis comenzó por mirar su AWS Cost Explorer. Los mayores conceptos en la factura eran, predeciblemente, EC2 y RDS. También encontraron un par de volúmenes EBS conectados a instancias terminadas y un NAT Gateway en una VPC que ya no se usaba activamente para tráfico de producción. Cosas pequeñas, pero que se suman.
Estrategias para Convertir Siempre Activo en Bajo Demanda (o Fuera de Pico)
Bien, has identificado las áreas donde estás gastando de más. Ahora viene la parte divertida: corregirlo. El objetivo no es solo ahorrar dinero, sino construir un sistema más resiliente y eficiente que solo consuma recursos cuando realmente los necesita.
1. Programar Inicio/Parada de Instancias
Este es probablemente el “bajo colgante” para muchas aplicaciones. Si tus herramientas internas o entornos de staging solo se utilizan durante el horario laboral, no hay razón para que estén funcionando 24/7. La mayoría de los proveedores de nube ofrecen maneras nativas de programar ciclos de encendido y apagado de instancias, o puedes implementar tu propia solución con funciones serverless.
Ejemplo Práctico: Programador de AWS EC2 con Lambda
Puedes crear una función Lambda simple activada por Eventos de CloudWatch (expresiones CRON) para detener y encender instancias de EC2 basadas en etiquetas. Aquí hay una versión simplificada del código de la función Lambda (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Definir etiquetas para identificar instancias para detener/empezar
# Por ejemplo, 'Schedule': 'horas-laborales'
# Obtener todas las instancias en ejecución con la etiqueta 'Schedule' configurada en 'horas-laborales'
running_instances = ec2.describe_instances(
Filters=[
{'Name': 'instance-state-name', 'Values': ['running']},
{'Name': 'tag:Schedule', 'Values': ['horas-laborales']}
]
)
stop_instance_ids = []
for reservation in running_instances['Reservations']:
for instance in reservation['Instances']:
stop_instance_ids.append(instance['InstanceId'])
if stop_instance_ids:
print(f"Deteniendo instancias: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("No hay instancias para detener.")
# --- Lógica similar para iniciar instancias en un momento diferente ---
# Tendrías otra Lambda/Event de CloudWatch para iniciar,
# o combinar lógica con una etiqueta de 'inicio'.
return {
'statusCode': 200,
'body': 'Programación de instancias EC2 completa.'
}
Deberías configurar dos reglas de Evento de CloudWatch: una para activar esta Lambda a, digamos, 6 PM UTC para detener instancias, y otra a las 7 AM UTC para iniciarlas. Esto solo puede reducir los costos de cómputo en más del 70% para esos recursos específicos.
2. Adoptar Serverless y Orquestación de Contenedores
Si tu carga de trabajo es verdaderamente esporádica o activada por eventos, serverless es tu mejor amigo. AWS Lambda, Azure Functions, Google Cloud Functions: escalan hasta cero cuando no están en uso, lo que significa que solo pagas por cómputo cuando tu código realmente está en ejecución. Este es un cambio masivo del paradigma de “siempre activo”.
Para aplicaciones más complejas que aún necesitan servicios persistentes pero tienen demanda fluctuante, las plataformas de orquestación de contenedores como Kubernetes (EKS, AKS, GKE) combinadas con escalado automático inteligente son poderosas. Los Autoscaladores de Pods Horizontales (HPA) pueden escalar tus pods de aplicación hacia arriba y hacia abajo según la utilización de CPU o métricas personalizadas. Los Autoscaladores de Clúster pueden agregar o quitar nodos de tu clúster a medida que cambia la demanda.
Mi cliente reformuló partes de su panel de análisis para usar Lambda para generar ciertos informes que solo se solicitaban unas pocas veces al día. En lugar de una instancia de EC2 dedicada ejecutando un trabajo cron, se activaba una función Lambda por un evento de S3 (nuevo dato subido) o una solicitud de API Gateway. Los ahorros en costos fueron inmediatos y significativos.
3. Dimensionar Correctamente Tus Bases de Datos con Serverless o Escalado Automático
Las bases de datos son a menudo un tema delicado porque la persistencia de datos es crítica. Sin embargo, muchas bases de datos modernas ofrecen opciones serverless o de escalado automático que no estaban ampliamente disponibles hace unos años.
- AWS Aurora Serverless v2: Este es un cambio significativo. Escala la capacidad basada en el uso real, desde fracciones de un ACU (Unidad de Capacidad Aurora) hasta cientos, y solo pagas por lo que usas. No más aprovisionamiento para capacidad pico cuando la mayor parte del tiempo estás operando a carga base.
- Azure SQL Database Serverless: Similar a Aurora Serverless, escala automáticamente los cómputos y se pausa cuando está inactivo, ahorrando costos significativos para cargas de trabajo intermitentes.
- DynamoDB On-Demand: Para cargas de trabajo NoSQL, el modo de capacidad bajo demanda de DynamoDB significa que pagas por solicitud, sin tener que aprovisionar unidades de capacidad de lectura/escritura. Perfecto para patrones de tráfico impredecibles.
El panel de análisis originalmente usaba una gran instancia de RDS PostgreSQL con IOPS aprovisionados. Después de migrar a Aurora Serverless v2, sus costos de base de datos cayeron casi un 60%, simplemente porque ya no estaba funcionando a toda capacidad durante las horas fuera de servicio.
4. Limpiar Almacenamiento No Adjuntado y Snapshots
Esto suena básico, pero es una fuente constante de desperdicio de dinero. Cuando terminas una instancia de EC2, su volumen de EBS asociado no siempre se elimina por defecto, especialmente si era un volumen no raíz. Lo mismo ocurre con los snapshots: se acumulan rápidamente y pueden volverse costosos.
Ejemplo Práctico: Encontrar y Eliminar Volúmenes EBS No Adjuntados (AWS CLI)
Puedes usar AWS CLI para encontrar volúmenes no adjuntados y eliminarlos. Esta es una tarea común de limpieza.
# Listar todos los volúmenes no adjuntos
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Para eliminar un volumen específico (TEN CUIDADO, ESTO ES IRREVERSIBLE)
# Reemplaza 'vol-xxxxxxxxxxxxxxxxx' con el ID del volumen real
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx
Automatiza esto con una función Lambda programada si a menudo inicias y desmontas entornos. El cliente encontró varios terabytes de antiguos volúmenes EBS no adjuntos y cientos de instantáneas obsoletas. Eliminarlos redujo unos cientos de dólares de su factura mensual; no es mucho, pero cada centavo cuenta.
5. Optimiza los Costos de Red
Las NAT Gateways son fantásticas para permitir que las instancias en subredes privadas accedan a Internet, pero generan un cargo por hora y un cargo por procesamiento de datos. Si tienes múltiples NAT Gateways en diferentes zonas de disponibilidad, pero solo una se utiliza activamente, estás pagando por las redundantes.
- Consolida las NAT Gateways: Si tu arquitectura lo permite, consolida a menos NAT Gateways.
- Puntos de enlace de VPC: Para acceder a servicios de AWS como S3 o DynamoDB desde dentro de tu VPC, utiliza Puntos de enlace de VPC. El tráfico fluye de forma privada dentro de la red de AWS, evitando los costos de NAT Gateway y ofreciendo mejor seguridad.
Descubrimos que el cliente tenía una NAT Gateway en cada AZ, aunque su aplicación principal solo funcionaba en dos. Pudieron consolidar y ahorrar un poco allí, y luego implementaron Puntos de enlace de VPC para el acceso a S3, lo que redujo los costos de procesamiento de datos a través de la NAT Gateway.
Conclusiones Accionables para Tu Próximo Sprint
Esto no solo se trata de reducir costos; se trata de construir sistemas más inteligentes y eficientes que sean inherentemente conscientes de los costos. Aquí tienes lo que puedes comenzar a hacer hoy:
- Audita Tu Factura de Nube Regularmente: Hazlo un hábito. Usa las herramientas de gestión de costos de tu proveedor de nube. No se lo entregues solo a finanzas. Comprende hacia dónde va cada dólar.
- Etiqueta Todo: Esto es innegociable. Etiqueta los recursos por proyecto, propietario, entorno (dev, staging, prod) y si pueden ser programados para apagado. Esto facilita infinitamente la identificación y la automatización.
- Prioriza la Programación para Entornos No Prod: Los entornos de staging, dev y QA son candidatos ideales para apagados programados fuera del horario laboral. Por lo general, esta es la victoria más fácil y rápida.
- Evalúa Serverless para Nuevas Cargas de Trabajo: Si estás construyendo algo nuevo, especialmente microservicios impulsados por eventos o tareas en segundo plano, siempre considera primero serverless.
- Revisa las Opciones de Base de Datos: Si tienes bases de datos funcionando 24/7 con cargas altamente variables, investiga opciones serverless o de escalado automático para tu tecnología de base de datos específica.
- Automatiza la Limpieza: Implementa scripts automatizados o funciones serverless para identificar y eliminar volúmenes de almacenamiento no adjuntos, instantáneas antiguas y otros recursos huérfanos.
- Educa a Tu Equipo: Fomenta una cultura de conciencia de costos. Asegúrate de que los desarrolladores comprendan las implicaciones de costos de sus decisiones de aprovisionamiento. Ya no es solo un problema de operaciones.
Detener la fuga de recursos “siempre activos” no es una solución única; es una disciplina continua. Pero al hacer estos cambios, no solo ahorrarás una cantidad significativa de dinero a tu empresa, sino que también construirás una infraestructura más ágil, resiliente y a prueba de futuro. Y, francamente, eso simplemente te hace un mejor agente en el juego tecnológico.
Eso es todo de mi parte esta vez. Sigue construyendo de manera inteligente, y te veré en la próxima!
🕒 Published: