Nota revisada y reescrita el 18 de octubre de 2026: la versión original tenía errores y datos sin fuente.
"La web va lenta a ciertas horas, ¿subimos de instancia?" Puede ser, o puede que estés pagando más por un problema que un tamaño mayor no arregla. CloudWatch tiene casi todos los datos para decidirlo, con un par de trampas.
1. CPU... y créditos, si es una instancia T
CPUUtilization es la métrica obvia: si pasa mucho tiempo por encima del 80-90 % en las horas de carga, falta CPU.
Pero las familias T (t3, t3a, t4g) son burstable: tienen un rendimiento base (un porcentaje de la CPU, según el tamaño) y acumulan créditos cuando están por debajo, que gastan cuando suben por encima. Mira dos métricas más:
CPUCreditBalance: si baja a cero en las horas punta, la instancia se queda limitada a su rendimiento base. Esto ocurre en modo standard.CPUSurplusCreditBalance: en modo unlimited (el predeterminado de T3 y T4g), la instancia sigue por encima de la base aunque se quede sin créditos, y lo cobra aparte. Si esta cifra crece, estás pagando CPU extra cada día.
Una T que vive sin créditos o en surplus constante es una instancia que debería ser de otra familia (m7g, c7g, m7i...), no una T más grande.
2. Memoria: AWS no la ve sin ayuda
EC2 no publica la memoria en CloudWatch por defecto: el hipervisor no sabe cuánta usa tu sistema operativo. Hace falta instalar el CloudWatch agent, que publica mem_used_percent (y swap_used_percent) en el espacio de nombres CWAgent.
Síntomas de que falta memoria: swap en uso constante, el OOM killer matando procesos (dmesg | grep -i oom, o MySQL/PHP-FPM reiniciándose solos) y una CPU alta en iowait por el swap. Si es esto, más CPU no ayuda: hace falta una instancia con más RAM, o ajustar lo que consume (procesos de PHP-FPM, innodb_buffer_pool_size).
3. Disco: IOPS y BurstBalance
En el volumen EBS mira VolumeReadOps, VolumeWriteOps y VolumeQueueLength. Una cola de E/S alta y sostenida significa que el disco no da abasto.
Los volúmenes gp2 también funcionan con créditos: su rendimiento base depende del tamaño (3 IOPS por GiB) y pueden ir más allá con ráfagas mientras les quede BurstBalance. Un gp2 pequeño que se queda a 0 % de BurstBalance va lentísimo. Los gp3 tienen un rendimiento base fijo (3.000 IOPS y 125 MiB/s) sea cual sea el tamaño, y se puede aumentar por separado. Pasar de gp2 a gp3 se hace en caliente, sin parar la instancia, y suele salir más barato.
4. Red
NetworkIn y NetworkOut contra el ancho de banda del tipo de instancia. Las instancias pequeñas tienen un rendimiento de red up to (de ráfaga), y lo que pueden sostener de forma continua es bastante menor. Es raro que sea el cuello de botella en una tienda, salvo que sirva imágenes o descargas grandes desde la propia instancia (para eso, mejor S3 y CloudFront).
Cómo decidir
- Mira estas métricas en las mismas horas en que la web va lenta, con una resolución de 1 minuto. La media diaria lo esconde todo.
- Si nada de esto está al límite y la web sigue lenta, el problema está en la aplicación (consultas, caché, código), y una instancia mayor solo lo disimula un tiempo.
- Si algo está al límite, cambia en esa dimensión: más créditos o CPU fija, más RAM o un disco gp3. Cambiar el tipo de instancia exige pararla y arrancarla, así que hazlo en una ventana tranquila (o con un balanceador y dos instancias).