Aprovechando AWS Compute Optimizer para el Ajuste Continuo y la Reducción de Costos

El ajuste de tamaño en AWS suena como un ejercicio financiero hasta que el primer cambio incorrecto derriba una carga de trabajo de producción. La versión útil es más cuidadosa: encontrar recursos que son claramente demasiado grandes, claramente demasiado pequeños, o que se ejecutan en una generación incómoda de infraestructura, luego hacer cambios de una manera que respete los patrones de tráfico, el estado, la reversión y el comportamiento de la aplicación.

AWS Compute Optimizer ayuda con ese trabajo analizando la configuración de los recursos y las métricas de utilización, luego produce recomendaciones para servicios como instancias EC2, grupos de Auto Scaling, volúmenes EBS, servicios ECS en Fargate y funciones Lambda. Las recomendaciones son útiles, pero deben tratarse como apoyo a la decisión, no como verdad automática. Compute Optimizer puede ver métricas. No siempre puede ver los calendarios de lanzamiento, los compromisos con los clientes, las peculiaridades de las licencias o el extraño trabajo por lotes que solo se ejecuta al final del mes.

---

Entendiendo AWS Compute Optimizer

AWS Compute Optimizer proporciona recomendaciones analizando las métricas de utilización históricas de los recursos compatibles. La retrospectiva predeterminada se basa comúnmente en la historia reciente, y las métricas de infraestructura mejoradas pueden extender la ventana de análisis para algunos tipos de recursos. La disponibilidad y retención exactas pueden variar según el tipo de recurso, la región, la configuración de la cuenta y los cambios de funciones de AWS, así que verifica la página de servicio actual antes de construir un proceso rígido en torno a un número.

ACO evalúa varios factores, incluida la utilización de la CPU, el uso de la memoria (si el agente de CloudWatch apropiado está instalado), el rendimiento de la red y la E/S del disco, generando recomendaciones que priorizan tanto la eficiencia de costos como el rendimiento.

Métricas Clave Proporcionadas por ACO

1. Hallazgos de Optimización: Categorización del recurso (por ejemplo, Sobreaprovisionado, Subaprovisionado, Optimizado).
2. Ahorro Mensual Estimado: Reducción de costos proyectada si se implementa la recomendación.
3. Riesgo de Rendimiento: Una evaluación baja, media o alta que indica la probabilidad de que implementar la recomendación impacte negativamente el rendimiento de la carga de trabajo.
4. Opciones Recomendadas: Configuraciones alternativas específicas de recursos (por ejemplo, tipos de instancia, configuraciones de memoria, especificaciones de volumen EBS).

Nota: Las recomendaciones de Compute Optimizer están disponibles sin un cargo de servicio separado en muchos usos comunes, pero las métricas mejoradas opcionales y los recursos que se analizan aún pueden afectar tu factura. Verifica los precios en tu cuenta antes de habilitar funciones opcionales de manera generalizada.

Ajuste de Tamaño de Instancias Amazon EC2

Las instancias EC2 suelen ser el mayor impulsor individual de los costos de cómputo en la nube. ACO proporciona recomendaciones personalizadas para instancias independientes e instancias dentro de Grupos de Auto Scaling (ASG).

Identificando Instancias Sobreaprovisionadas y Subaprovisionadas

ACO categoriza las instancias EC2 según su análisis:

• Sobreaprovisionadas: Instancias que muestran una utilización consistentemente baja para las métricas que Compute Optimizer puede ver. Puede sugerir pasar a un tipo de instancia más pequeño o diferente.
• Subaprovisionadas: Instancias que muestran una alta utilización o presión sobre los recursos. Puede sugerir una instancia más grande, una familia diferente o una configuración con mejores características de CPU, memoria, red o almacenamiento.

Implementando Recomendaciones de Ajuste de Tamaño de EC2

Implementar un cambio requiere una planificación cuidadosa, especialmente para cargas de trabajo de producción. El proceso para cambiar un tipo de instancia generalmente implica detener, modificar y reiniciar la instancia.

Ejemplo: Modificando una Instancia Sobreaprovisionada a través de CLI

Si Compute Optimizer recomienda cambiar una instancia de m5.large a t3.large, los pasos mecánicos para una instancia respaldada por EBS son:

1. Detener la Instancia:

   aws ec2 stop-instances --instance-ids i-1234567890abcdef0
   

2. Modificar el Tipo de Instancia:

   aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}"
   

3. Iniciar la Instancia:

   aws ec2 start-instances --instance-ids i-1234567890abcdef0
   

Mejor Práctica: Siempre realiza estos cambios durante períodos de bajo tráfico y monitorea de cerca las métricas de la instancia (CPU, latencia, registros de aplicación) durante 24-48 horas después de la implementación para asegurarte de que el nuevo tamaño pueda manejar la carga máxima sin degradación del rendimiento.

Antes de cambiar el tipo, verifica si la instancia es parte de un grupo de Auto Scaling, utiliza volúmenes de almacenamiento de instancia, tiene requisitos de grupo de colocación, utiliza suposiciones de nomenclatura ENA o NVMe, o está vinculada a un modelo de licencia. Para servicios de producción, a menudo es más seguro integrar el nuevo tamaño en una plantilla de lanzamiento, reemplazar las instancias gradualmente y dejar que los balanceadores de carga drenen las conexiones.

Optimizando Volúmenes Amazon EBS

Compute Optimizer extiende sus recomendaciones a los volúmenes de Elastic Block Store (EBS) adjuntos a instancias EC2. La optimización aquí se centra en maximizar el rendimiento por dólar sugiriendo tipos de volumen modernos y ajustando la configuración de IOPS/rendimiento.

Recomendaciones de Migración

Una optimización común es migrar volúmenes de propósito general más antiguos, especialmente gp2, a gp3 donde se ajuste a la carga de trabajo.

Tipo de Volumen	Ventaja
gp2	El rendimiento escala con el tamaño del volumen y los créditos de ráfaga.
gp3	El rendimiento se puede configurar por separado del tamaño dentro de los límites del servicio.

Compute Optimizer puede recomendar valores específicos de IOPS y rendimiento basados en los patrones de uso observados. Trata esas recomendaciones como un punto de partida. Un volumen de base de datos con bajo volumen de escritura reciente aún puede necesitar margen para ventanas de mantenimiento, compactación, construcción de índices, copias de seguridad o recuperación tras failover.

Paso Accionable: Modificando un Volumen

Las modificaciones de volumen EBS generalmente se pueden realizar mientras el volumen está en uso (a diferencia de cambiar un tipo de instancia EC2), aunque se debe considerar el impacto en el rendimiento.

# Ejemplo: Migrando volumen a gp3 y estableciendo IOPS/rendimiento específicos
aws ec2 modify-volume \
    --volume-id vol-fedcba9876543210 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

Observa el estado de la modificación después del comando:

aws ec2 describe-volumes-modifications \
  --volume-ids vol-fedcba9876543210

Para bases de datos críticas, prueba el cambio primero en una réplica o copia de staging. Un cambio de tipo de volumen puede ser en línea, pero la carga de trabajo aún puede sentir cambios en el comportamiento de E/S si la nueva configuración de IOPS o rendimiento es demasiado baja.

Ajuste de Tamaño de Funciones AWS Lambda

Para cargas de trabajo serverless, Compute Optimizer proporciona información crítica sobre las funciones AWS Lambda. En Lambda, la configuración de memoria determina la cantidad de vCPU asignada a la función. El ajuste de tamaño de Lambda se trata principalmente de encontrar la configuración de memoria más baja que aún cumpla con los objetivos de rendimiento.

El Compromiso Memoria/CPU

Compute Optimizer analiza los patrones de utilización y duración de Lambda para recomendar configuraciones de memoria. Una función podría tener asignados 1024 MB pero funcionar aceptablemente con 512 MB. Otra función podría resultar más barata cuando se aumenta la memoria porque la CPU adicional reduce la duración lo suficiente como para compensar la asignación de memoria más grande.

Ese segundo caso sorprende a la gente. El costo de Lambda está vinculado a la memoria asignada y la duración, por lo que la configuración más barata no siempre es el valor de memoria más pequeño. Prueba eventos representativos antes de aplicar las recomendaciones de manera generalizada.

Implementando la Optimización de Funciones Lambda

La optimización de Lambda es sencilla, generalmente requiere una simple actualización de la configuración de la función.

Ejemplo: Actualizando la Configuración de Memoria de Lambda

Si ACO recomienda mover una función de 2048MB a 1024MB:

aws lambda update-function-configuration \
    --function-name MyOptimizedFunction \
    --memory-size 1024

Integrando la Optimización Continua en tu Flujo de Trabajo

El ajuste de tamaño no debe ser una auditoría única, sino una disciplina continua. Compute Optimizer facilita esto a través de su API e integración con AWS Organizations.

1. Gestión Centralizada

Si usas AWS Organizations, designa una cuenta de administrador delegado para Compute Optimizer. Esto permite que ACO proporcione recomendaciones consolidadas en todas las cuentas, ofreciendo una visión holística de los posibles ahorros a nivel empresarial.

2. Automatización y Notificación

Usa la API de Compute Optimizer e intégrala con AWS CloudWatch Events o Lambda para crear flujos de trabajo automatizados:

• Informes Programados: Configura un disparador diario o semanal que extraiga las últimas recomendaciones de alta prioridad (por ejemplo, aquellas con el mayor ahorro estimado).
• Alertas: Activa alertas a través de SNS cuando ACO identifique recursos con hallazgos específicos (por ejemplo, instancias subaprovisionadas con alto riesgo de rendimiento).
• Implementación Semiautomatizada: Para recomendaciones de bajo riesgo y alto ahorro (como la migración a gp3 de EBS), usa funciones Lambda para generar automáticamente solicitudes de cambio o incluso aplicar el cambio directamente después de pasar un umbral de gobierno necesario.

# Fragmento conceptual de Python usando boto3 para recuperar recomendaciones
import boto3

aco_client = boto3.client('compute-optimizer')

response = aco_client.get_ec2_instance_recommendations(
    filters=[
        {'name': 'finding', 'values': ['Overprovisioned']}
    ]
)
# Procesa y actúa sobre las opciones recomendadas...

Mantén la implementación separada de la recopilación de recomendaciones. Un informe semanal puede enumerar candidatos de manera segura. Un bot que detiene instancias o cambia la memoria de Lambda sin contexto de la carga de trabajo puede crear incidentes. Un buen punto intermedio es abrir tickets o solicitudes de extracción con la recomendación, las métricas actuales, el cambio propuesto, el ahorro estimado y el plan de reversión.

Cómo Revisar una Recomendación Antes de Actuar

Para cada recomendación, haz algunas preguntas prácticas:

1. ¿El recurso todavía está en uso, o la eliminación es una mejor respuesta que el redimensionamiento?
2. ¿El período de retrospectiva incluye el tráfico pico normal, las ventanas de lotes y los lanzamientos recientes?
3. ¿Están disponibles los datos de memoria para EC2, o la recomendación se basa principalmente en CPU y red?
4. ¿La instancia tiene estado, tiene licencia, está vinculada a hardware o configurada manualmente?
5. ¿Se puede implementar el cambio detrás de un grupo de Auto Scaling, una implementación azul/verde o una réplica?
6. ¿Qué métrica probaría que el cambio funcionó o falló?

Por ejemplo, una instancia EC2 que ejecuta un informe nocturno puede parecer inactiva durante el horario comercial y extremadamente ocupada durante 40 minutos después de la medianoche. Una recomendación basada en promedios amplios podría sugerir reducir el tamaño, pero la pregunta real es si el informe aún termina antes de la fecha límite del negocio. Los ahorros de costos que rompen la ventana del lote no son ahorros.

Patrones de Implementación que Reducen el Riesgo

El camino de implementación más seguro depende del recurso.

Para servicios EC2 sin estado detrás de un balanceador de carga, prefiere reemplazar instancias a través de un grupo de Auto Scaling o un pipeline de implementación en lugar de detener una instancia en vivo manualmente. Actualiza la plantilla de lanzamiento, agrega una instancia con el nuevo tipo, observa las comprobaciones de salud y las métricas de la aplicación, luego implementa el resto gradualmente. Esto te da una reversión natural: vuelve a poner la versión anterior de la plantilla de lanzamiento y reemplaza las nuevas instancias.

Para hosts EC2 con estado, toma un camino más lento. Confirma las copias de seguridad, comprende los volúmenes adjuntos, verifica las ventanas de mantenimiento y asegúrate de que la aplicación pueda tolerar un ciclo de detener/iniciar. Algunas familias de instancias más antiguas y familias más nuevas exponen discos o dispositivos de red de manera diferente, por lo que los scripts de inicio que asumen un nombre de dispositivo pueden romperse después de un cambio de tipo.

Para EBS, observa tanto las métricas de costos como de rendimiento después de cambiar el tipo de volumen o el rendimiento aprovisionado. Una estimación mensual más baja no es suficiente. Verifica la longitud de la cola, la latencia, el rendimiento y los síntomas a nivel de aplicación. Si el volumen respalda una base de datos, la latencia de la aplicación puede decirte más que el gráfico del volumen por sí solo.

Para Lambda, publica una nueva versión o una implementación basada en alias cuando la función sea importante. Envía una pequeña parte del tráfico a la nueva configuración de memoria, compara la duración, los errores, los arranques en frío y la presión descendente, luego cambia más tráfico. Una función que se vuelve más rápida con más memoria puede ejercer más presión sobre una base de datos o API a la que llama, así que observa toda la ruta.

Reportando Recomendaciones Claramente

Un informe de ajuste de tamaño útil no debe ser una hoja de cálculo llena de IDs de instancia sin contexto. Incluye la configuración actual, la configuración recomendada, la ventana de utilización observada, el ahorro mensual estimado, el riesgo de rendimiento, el propietario, el método de implementación propuesto y el plan de reversión. Agrega una nota corta explicando por qué se acepta, aplaza o rechaza la recomendación.

Las recomendaciones rechazadas siguen siendo útiles. Un servidor de base de datos puede parecer sobreaprovisionado porque está dimensionado para failover, no para tráfico promedio. Un servidor de licencias puede necesitar una familia de instancias fija. Un host de baja utilización puede estar esperando una migración planificada. Capturar esas razones evita que la misma recomendación se discuta nuevamente cada mes.

Mejores Prácticas para Usar Compute Optimizer

Área	Mejor Práctica
Período de Monitoreo	Asegúrate de que los recursos hayan estado funcionando bajo carga típica durante al menos 14 días antes de confiar en las recomendaciones.
Pruebas de Rendimiento	Después de implementar una recomendación de reducción de tamaño, siempre ejecuta pruebas de carga para asegurarte de que la aplicación mantenga los SLO (Objetivos de Nivel de Servicio) requeridos.
Cargas de Trabajo Especializadas	Ten cuidado con las aplicaciones con estado, bases de datos o servidores de licencias de terceros que puedan requerir tipos de instancia específicos o recursos mínimos, incluso si ACO recomienda un tamaño más pequeño.
Métrica de Memoria	Para EC2, instala el agente de CloudWatch para recopilar datos detallados de uso de memoria. Sin esto, las recomendaciones de ajuste de tamaño de ACO se basan principalmente en CPU y red, lo que puede ser incompleto.
Revisión Continua	Trata el panel de ACO como un documento vivo. Las cargas de trabajo cambian constantemente, lo que requiere una reevaluación regular del dimensionamiento de los recursos.

---

Verificación Final

AWS Compute Optimizer es más valioso cuando se convierte en parte de un hábito de revisión. Úsalo para encontrar desperdicios, detectar recursos subaprovisionados y desafiar suposiciones antiguas. Luego trae el contexto que AWS no puede inferir: tiempos de lanzamiento, eventos pico, promesas a los clientes, dominios de falla y rutas de reversión. El mejor programa de ajuste de tamaño no es el que acepta la mayoría de las recomendaciones. Es el que ahorra dinero sin hacer que la producción sea más frágil.