Right-sizing de EC2 y Compute Optimizer

Heredas una cuenta con 40 servidores web en m5.2xlarge. Todas las instancias están sanas. No se disparó una alarma en ocho meses. CloudWatch muestra CPUUtilization promediando 8% con picos cerca de 22%. La factura mensual de cómputo ronda los 11.000 dólares, y unos 8.000 de esos están comprando capacidad que nadie usa.

Acá no hay nada roto, y por eso mismo nadie lo mira. El right-sizing es la parte del trabajo de CloudOps que no tiene ningún incidente asociado, y el examen lo evalúa porque usa exactamente las mismas habilidades que necesitas cuando algo sí está roto: leer bien las métricas de utilización, saber cuál es la métrica que falta y saber qué herramienta responde qué pregunta.

El uso de CPU es una dimensión de cuatro

CPUUtilization es la métrica a la que todo el mundo va primero, y por sí sola es casi inútil para decidir un tamaño.

Una instancia tiene al menos cuatro dimensiones de capacidad que se pueden agotar de forma independiente: CPU, memoria, red y I/O de almacenamiento. CloudWatch publica métricas de instancia para tres de ellas sin que hagas nada. No publica memoria, porque el hipervisor no puede ver adentro del huésped. Para AWS, la memoria de tu sistema operativo es opaca; solo un agente corriendo dentro de la instancia puede reportar cuánta está en uso.

Esto produce una forma de falla muy específica y muy común: una aplicación lenta mientras CPUUtilization se queda en 12%. La instancia está hambrienta de memoria, el sistema operativo está haciendo swap, y todos los gráficos de la consola se ven tranquilos. Si un escenario describe CPU baja con mal rendimiento, la memoria es lo primero que hay que sospechar, y la acción que destraba el diagnóstico es instalar el agente unificado de CloudWatch para que la memoria se vuelva una métrica que puedas ver.

El mismo punto ciego afecta a las herramientas construidas encima de estas métricas. Compute Optimizer analiza la utilización de memoria solo en recursos con el agente de CloudWatch instalado. Sin él, obtienes findings basados en CPU, red e I/O, y el servicio va a recomendarte con toda tranquilidad una instancia más chica para una carga que en realidad está limitada por memoria.

Qué hace Compute Optimizer

AWS Compute Optimizer lee la configuración y las métricas de utilización de CloudWatch de tus recursos y devuelve una configuración recomendada, junto con la utilización proyectada si la adoptaras.

Cuatro hechos sobre cómo funciona explican la mayoría de las preguntas de examen:

Tienes que hacer opt-in. No hace nada hasta que lo activas para una cuenta independiente, una cuenta miembro o la cuenta de administración de una organización. Un escenario donde "Compute Optimizer no muestra recomendaciones" muchas veces termina acá.

La ventana predeterminada son 14 días. Analiza los últimos 14 días de métricas y refresca las recomendaciones a diario. Activar enhanced infrastructure metrics, una preferencia de recomendación paga, extiende la ventana a 93 días. Esa es la respuesta cada vez que una carga tiene un cierre mensual, un batch trimestral o cualquier pico que una ventana de 2 semanas no llegaría a ver.

Necesita datos suficientes. Las recomendaciones pueden tardar hasta 24 horas en aparecer después del opt-in, y un recurso con poco historial de métricas no recibe ningún finding.

Cubre mucho más que EC2. Instancias EC2 y grupos de Auto Scaling, volúmenes EBS, funciones Lambda, servicios de ECS sobre Fargate, bases RDS y Aurora, DynamoDB, ElastiCache, MemoryDB, DocumentDB, NAT gateways, WorkSpaces, SageMaker y licencias de software comercial. Si una pregunta busca un único servicio que dé recomendaciones de right-sizing sobre cómputo y almacenamiento y bases de datos, es este.

Leer un finding

Cada instancia analizada cae en una de tres clasificaciones:

La clasificación te dice que algo está mal. El finding reason te dice qué, y es específico: CPU over-provisioned, Memory under-provisioned, EBS throughput under-provisioned, EBS IOPS over-provisioned, Network bandwidth under-provisioned, Network PPS under-provisioned, Disk IOPS, Disk throughput y sus equivalentes de GPU. Cada uno nombra la métrica de la que salió, así que puedes ir a verificarlo por tu cuenta: los reasons de EBS IOPS vienen de VolumeReadOps y VolumeWriteOps, los de ancho de banda de red de NetworkIn y NetworkOut, los de PPS de NetworkPacketsIn y NetworkPacketsOut.

Fíjate en la división que confunde a mucha gente: los reasons de Disk se refieren a volúmenes de instance store (DiskReadOps, DiskWriteBytes), mientras que los de EBS se refieren a volúmenes EBS conectados. Hardware distinto, arreglo distinto. Un finding de disco se resuelve cambiando el tipo de instancia; uno de EBS muchas veces se resuelve modificando el volumen, que es de lo que trata la tercera lección de este tema.

Cada recomendación también trae un performance risk de very low a very high (0 a 4 en la API). Es el puntaje máximo entre todas las especificaciones analizadas, y responde "¿qué tan probable es que este tipo más chico me decepcione?". Very low significa que se predice que el tipo siempre tendrá capacidad de sobra. Cualquier cosa por encima es una invitación a probar bajo carga real primero.

Las instancias burstable juegan con otras reglas

Todo lo anterior asume que una instancia puede usar el 100% de su CPU cuando quiere. Las instancias T no pueden, y este es el pedazo de conocimiento sobre tamaño de EC2 que más se evalúa.

Una instancia burstable se vende con un nivel baseline de CPU que puede sostener para siempre, más un balde de créditos de CPU que le permiten correr arriba del baseline durante un rato. Un crédito de CPU equivale a un vCPU al 100% durante un minuto. Abajo del baseline, la instancia gana más de lo que gasta y el balde se llena. Arriba del baseline, gasta más de lo que gana y el balde se vacía.

Acá tienes una t3.large, que tiene 2 vCPU, gana 36 créditos por hora, tiene un baseline de 30% y puede acumular hasta 864 créditos (un día entero de ganancia):

• La demanda sube a un 55% de CPU estable.
• Créditos gastados por minuto = vCPU x utilización = 2 x 0,55 = 1,1, o sea 66 por hora.
• Créditos ganados por hora = 36.
• Drenaje neto = 30 créditos por hora. Partiendo de 864 llenos, el balance llega a cero en unas 29 horas.

Qué pasa al llegar a cero depende del modo de configuración de créditos:

• Modo standard: la instancia baja a su baseline. La CPU queda fijada en 30% y la aplicación se pone lenta, sin error, sin alarma y sin una causa evidente. Es el predeterminado para T2 y para T3 sobre un Dedicated Host.
• Modo unlimited: la instancia sigue corriendo arriba del baseline gastando créditos excedentes. Si su CPU promedio en una ventana móvil de 24 horas se queda en el baseline o por debajo, el excedente queda cubierto por el precio horario normal. Si no, pagas una tarifa plana adicional por vCPU-hora. Es el predeterminado para T3, T3a y T4g.

La confusión que conviene nombrar en voz alta: la gente lee "burstable" como un bonus y asume que la instancia puede sostener CPU alta de forma indefinida. No puede, en ninguno de los dos modos, sin una consecuencia. En modo standard la consecuencia es un precipicio de rendimiento más o menos un día después de que subió la carga. En modo unlimited la consecuencia es una línea de factura que nadie esperaba. La métrica que predice las dos es CPUCreditBalance, no CPUUtilization, así que una flota de instancias T necesita una alarma sobre el balance de créditos yendo hacia cero. Para el lado de la factura, la métrica a mirar es CPUSurplusCreditsCharged.

Algunos hechos más sobre créditos que vale la pena sostener:

• El límite de acumulación siempre equivale a 24 horas de ganancia. Una t3.micro gana 12 por hora y acumula 288; una t3.2xlarge gana 192 por hora y acumula 4.608.
• Los porcentajes de baseline son por vCPU y coinciden con lo que muestra CloudWatch. Una t3.large en su baseline se lee como 30% en la consola.
• En T3, T3a y T4g los créditos acumulados sobreviven un stop durante 7 días. En T2 se pierden en el momento en que detienes la instancia.
• Los launch credits existen solo en T2 en modo standard. T3 y posteriores se lanzan en unlimited, así que pueden hacer burst de inmediato sin necesitarlos.

Si una instancia T vive de forma sostenida arriba de su baseline, es la instancia equivocada para esa carga. Eso es un finding de right-sizing, no un problema de tuning, y Compute Optimizer dibuja la línea del baseline burstable sobre su gráfico de CPU justamente para que lo veas.

Cambiar el tamaño de una instancia viva

Una vez que tienes el finding, el cambio en sí es mecánico, y al examen le importan el orden y los efectos colaterales.

En una instancia EBS-backed, cambiar el tipo exige que esté detenida:

aws ec2 stop-instances --instance-ids i-0abc123def4567890
aws ec2 wait instance-stopped --instance-ids i-0abc123def4567890

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123def4567890 \
  --instance-type "{\"Value\": \"m5.xlarge\"}"

aws ec2 start-instances --instance-ids i-0abc123def4567890

La instancia conserva su ID, sus volúmenes EBS, sus security groups y su rol de IAM. Tres cosas no sobreviven al stop y start:

• Los datos en volúmenes de instance store, porque la instancia se mueve a otro hardware.
• La dirección IPv4 pública, salvo que tenga asociada una Elastic IP.
• El balance de créditos de CPU en una instancia T2.

Los tags hacen la mitad organizativa de este trabajo. Hacer right-sizing a escala de flota significa poder responder "quién es dueño de esta instancia y en qué entorno está" antes de tocarla, y por eso la Skill 1.3.1 de la guía del examen nombra los resource tags al lado de las métricas de rendimiento. Un juego consistente de tags Environment, Owner y Application es lo que convierte una lista de 400 findings en 12 conversaciones.

Para instancias dentro de un Auto Scaling group, no cambies el tamaño una por una. Actualiza el launch template con el tipo nuevo y arranca un instance refresh, así el cambio queda durable y el grupo reemplaza instancias de forma controlada.

Qué herramienta responde qué pregunta

Tres servicios producen consejos que suenan parecidos, y las preguntas están escritas para separarlos.

La pista: "recomendar un tipo de instancia según la utilización medida" es Compute Optimizer. "Muéstrame oportunidades de ahorro junto a mi factura" es Cost Explorer. "Revisa mi cuenta contra una lista de buenas prácticas" es Trusted Advisor.

Consejos para el examen

• CPU baja más aplicación lenta significa memoria. La acción que destraba es instalar el agente de CloudWatch, porque la memoria no es una métrica predeterminada de CloudWatch y Compute Optimizer no puede analizarla sin el agente.
• "Job mensual", "pico trimestral" o "carga estacional" junto con Compute Optimizer apuntan a enhanced infrastructure metrics y su ventana de 93 días. Los 14 días por defecto nunca verían el pico.
• Una instancia T que se pone lenta después de más o menos un día de carga elevada es una pregunta de agotamiento de créditos. La métrica es CPUCreditBalance; el arreglo es o modo unlimited (aceptando el cargo por excedente) o una familia no burstable.
• Presta atención a qué predeterminado implica la pregunta. T2 arranca en modo standard y hace throttling; T3, T3a y T4g arrancan en unlimited y facturan en vez de frenar.
• No confundas los finding reasons de Disk (instance store) con los de EBS (volúmenes conectados). Llevan a remediaciones distintas.
• Cambiar el tipo de instancia exige detenerla, y detenerla destruye los datos de instance store y libera una IP pública que no sea Elastic.

El hábito que te llevas: antes de cambiar el tamaño de cualquier instancia, sabe cuál de sus cuatro dimensiones de capacidad está realmente restringida. La CPU es la que ves por defecto, la memoria es la que tienes que ir a buscar, y en las instancias T la restricción no es una dimensión sino un balance de créditos. La lección que sigue toma la tercera dimensión, la red, y muestra por qué una instancia puede estar lejísimos de su ancho de banda declarado y aun así estar limitada.