Instancias T3 Burstables en AWS: Créditos de CPU y Por Qué Tu Servidor Se Ralentiza

Estás monitoreando una instancia EC2 T3 en producción y todo va bien — hasta que de repente la CPU cae a un rendimiento mínimo sin ninguna razón aparente en los logs de aplicación. No hay errores, no hay picos de memoria, pero las peticiones empiezan a acumularse. Si esto te suena familiar, el problema casi siempre está en el sistema de créditos de CPU que define cómo funcionan las instancias burstables T3.

TL;DR: Créditos de CPU en Instancias T3

Concepto Descripción
Crédito de CPU Unidad que permite usar el 100% de un vCPU durante 1 minuto
Tasa de acumulación Varía por tipo de instancia; se acumula cuando el uso está por debajo del baseline
Baseline Porcentaje de CPU garantizado sin consumir créditos (ej. 20% para t3.small)
Modo Standard Al agotar créditos, la CPU cae al baseline — comportamiento por defecto en T3
Modo Unlimited Permite bursts sostenidos; genera cargos adicionales si se excede el baseline
Síntoma típico CPU throttling silencioso — sin errores en logs, pero latencia alta

Cómo Funcionan las Instancias Burstables T3: El Modelo de Créditos

Las instancias T3 no son instancias de propósito general con CPU dedicada al 100%. Son instancias burstables: tienen un rendimiento de CPU base (baseline) garantizado, y pueden superar ese baseline temporalmente consumiendo créditos de CPU acumulados.

El mecanismo funciona así: mientras el uso de CPU de la instancia está por debajo del baseline, la instancia acumula créditos a una tasa fija. Cuando el uso supera el baseline, los créditos se consumen. Si los créditos se agotan y la instancia está en modo Standard, la CPU queda limitada al baseline hasta que se acumulen suficientes créditos nuevamente.

Cada crédito de CPU equivale a usar el 100% de un vCPU durante 1 minuto. Una instancia con 6 créditos acumulados puede usar un vCPU al 100% durante 6 minutos, o al 50% durante 12 minutos.

graph TD A["Instancia T3 en ejecución"] --> B{"¿Uso CPU < Baseline?"} B -- Sí --> C["Acumular créditos
hasta el límite máximo"] B -- No --> D{"¿Hay créditos disponibles?"} C --> A D -- Sí --> E["Consumir créditos
para sostener el burst"] D -- No --> F{"¿Modo Unlimited?"} E --> A F -- Sí --> G["Usar créditos surplus
— cargo adicional"] F -- No --> H["CPU limitada al baseline
— throttling silencioso"] G --> A H --> A
  1. Acumulación: Cuando el uso de CPU está por debajo del baseline, los créditos se acumulan continuamente hasta el límite máximo de la instancia.
  2. Burst: Cuando la carga supera el baseline, los créditos acumulados se consumen para sostener el rendimiento elevado.
  3. Agotamiento (modo Standard): Al llegar a cero créditos, la CPU queda limitada al porcentaje baseline — esto es el throttling silencioso.
  4. Recuperación: Con carga baja, los créditos vuelven a acumularse y el burst se restaura gradualmente.

Baseline y Tasa de Acumulación por Tipo de Instancia

Cada tipo de instancia T3 tiene un baseline diferente y una tasa de acumulación de créditos distinta. AWS documenta estos valores en la guía de instancias burstables. Como referencia conceptual: una instancia más pequeña tiene un baseline más bajo y acumula créditos más lentamente, lo que la hace más susceptible al agotamiento bajo cargas sostenidas. Consulta siempre la documentación oficial de AWS sobre instancias burstables para los valores exactos de tu tipo de instancia.

Piensa en los créditos de CPU como una batería de rendimiento: se carga lentamente cuando la instancia está ociosa y se descarga rápido bajo carga intensa. Una instancia que trabaja duro toda la noche llega al día siguiente sin batería.

Modos de Operación: Standard vs. Unlimited

Este es el punto donde la mayoría de los equipos comete el error de diagnóstico. T3 tiene dos modos de operación que determinan qué pasa cuando los créditos se agotan.

graph LR A["Instancia T3"] --> B{"Modo de crédito"} B -- Standard --> C["Créditos agotados"] B -- Unlimited --> D["Créditos agotados"] C --> E["CPU limitada al baseline
sin cargo adicional"] D --> F["CPU continúa en burst
créditos surplus con cargo"] E --> G["Rendimiento degradado
hasta recuperar créditos"] F --> H["Rendimiento sostenido
costo variable"] style E fill:#ff9999 style G fill:#ff9999 style F fill:#99ccff style H fill:#99ccff
  1. Modo Standard: Cuando los créditos llegan a cero, AWS aplica throttling de CPU al baseline. La instancia sigue funcionando, pero con rendimiento reducido. No hay ningún error explícito — la aplicación simplemente se vuelve lenta.
  2. Modo Unlimited: La instancia puede hacer burst más allá de sus créditos acumulados. Si el uso promedio supera el baseline durante un período de 24 horas, AWS cobra por los créditos adicionales consumidos. Este modo tiene implicaciones de costo que deben monitorearse.

Un detalle importante: a diferencia de T2, las instancias T3 tienen el modo Unlimited habilitado por defecto. Esto significa que una instancia T3 recién lanzada puede hacer burst sin límite — y generar cargos adicionales — si no se configura explícitamente el modo Standard.

Verificar y Cambiar el Modo de Crédito

# Verificar el modo de crédito actual de una instancia
aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1
# Cambiar a modo Standard (limita CPU al baseline cuando se agotan créditos)
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications '[{"InstanceId":"i-1234567890abcdef0","CpuCredits":"standard"}]' \
  --region us-east-1
# Cambiar a modo Unlimited (permite burst sostenido con posible cargo adicional)
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications '[{"InstanceId":"i-1234567890abcdef0","CpuCredits":"unlimited"}]' \
  --region us-east-1

Diagnóstico: Por Qué Tu Servidor Se Ralentiza Sin Errores Aparentes

El patrón clásico de agotamiento de créditos es engañoso: la CPU en CloudWatch muestra un porcentaje que parece razonable, la aplicación no lanza excepciones, pero la latencia se dispara y el throughput cae. El equipo revisa logs de aplicación, base de datos, red — y no encuentra nada.

Lo que está pasando: la CPU está siendo throttled al baseline, pero CloudWatch reporta el uso relativo al baseline, no al 100% del vCPU. La instancia está trabajando al máximo de lo que se le permite, no al máximo de lo que podría hacer.

Paso 1: Verificar el Saldo de Créditos Actual

Antes de revisar logs de aplicación o configuración de red, confirma si la instancia tiene créditos disponibles. Esta métrica es el primer indicador que diferencia un problema de créditos de cualquier otro problema de rendimiento.

# Obtener el saldo de créditos de CPU en los últimos 60 minutos
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T10:00:00Z \
  --end-time 2024-01-15T11:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Paso 2: Correlacionar CPUCreditBalance con CPUSurplusCreditsCharged

Si la instancia está en modo Unlimited y el balance llegó a cero, AWS empieza a usar créditos surplus. La métrica CPUSurplusCreditsCharged confirma que se están generando cargos adicionales y que el burst está siendo sostenido artificialmente. Esto cierra el diagnóstico: no es un problema de la aplicación, es un problema de dimensionamiento de instancia.

# Verificar créditos surplus consumidos (solo relevante en modo Unlimited)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T10:00:00Z \
  --end-time 2024-01-15T11:00:00Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

Paso 3: Revisar CPUCreditUsage para Entender el Patrón de Consumo

El balance te dice dónde estás; el uso te dice cómo llegaste ahí. Un consumo de créditos alto y sostenido durante horas indica que la carga de trabajo no es adecuada para una instancia burstable — no es un pico temporal sino una carga base que supera el baseline.

# Ver tasa de consumo de créditos en las últimas 3 horas
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T08:00:00Z \
  --end-time 2024-01-15T11:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Paso 4: Configurar Alarma de CloudWatch para CPUCreditBalance

Una vez confirmado el patrón, la alarma preventiva evita que el próximo incidente sea una sorpresa. El umbral exacto depende de tu tasa de acumulación y los patrones de carga — un valor de 20 créditos da tiempo de reacción para la mayoría de instancias pequeñas, pero ajústalo según tu baseline documentado.

# Crear alarma cuando el balance de créditos cae por debajo de 20
aws cloudwatch put-metric-alarm \
  --alarm-name 'T3-CPUCreditBalance-Low' \
  --alarm-description 'Creditos de CPU por debajo del umbral critico' \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1
graph TD START(["Servidor lento sin errores en logs"]) --> S1["Paso 1: Verificar CPUCreditBalance"] S1 --> Q1{"¿Balance cercano a cero?"} Q1 -- No --> S_OTHER["Investigar otras causas
red, DB, aplicación"] Q1 -- Sí --> S2["Paso 2: Verificar CPUSurplusCreditsCharged"] S2 --> Q2{"¿Hay créditos surplus?"} Q2 -- Sí --> DIAG1["Modo Unlimited activo
carga supera baseline"] Q2 -- No --> S3["Paso 3: Revisar CPUCreditUsage"] S3 --> Q3{"¿Consumo sostenido?"} Q3 -- Sí --> DIAG2["Carga no adecuada
para instancia burstable"] Q3 -- No --> DIAG3["Pico temporal agotó créditos
esperar recuperación"] DIAG1 --> FIX1["Evaluar migración a M5/C5"] DIAG2 --> FIX1 DIAG3 --> FIX2["Configurar alarma
CPUCreditBalance"] FIX1 --> END(["Problema resuelto"]) FIX2 --> END

El Error de Diagnóstico Más Común con Instancias T3

El escenario real: una instancia t3.small ejecutando un servidor web con tráfico moderado. Durante semanas funciona perfectamente. Un lunes por la mañana, con el tráfico habitual, la latencia se triplica. El equipo revisa RDS — sin problemas. Revisa la red — sin pérdida de paquetes. Revisa los logs de Nginx — sin errores 5xx.

El diagnóstico inicial apunta a un problema de base de datos o de configuración de la aplicación después de un deploy del viernes. Se revierte el deploy — el problema persiste.

La causa real: el fin de semana hubo un proceso batch que consumió CPU intensivamente durante horas. La instancia agotó todos sus créditos acumulados. El lunes, con el balance en cero y en modo Standard, la CPU estaba limitada al baseline. El tráfico del lunes era idéntico al de siempre, pero la instancia ya no tenía capacidad de burst para manejarlo.

La solución no fue revertir el deploy. Fue cambiar temporalmente a modo Unlimited mientras se evaluaba migrar a una instancia de propósito general (M5 o C5) para esa carga de trabajo.

Los créditos de CPU son un recurso compartido en el tiempo — lo que gastas hoy lo pagas mañana.

Cuándo NO Usar Instancias T3

Las instancias T3 son apropiadas para cargas de trabajo con uso de CPU variable o intermitente: servidores web con tráfico irregular, entornos de desarrollo, microservicios con picos cortos. No son adecuadas cuando:

  • El uso de CPU supera el baseline de forma sostenida (más de unas pocas horas al día).
  • La carga de trabajo requiere rendimiento de CPU predecible y consistente.
  • Los picos de CPU son frecuentes y prolongados — el balance de créditos nunca se recupera.

En esos casos, una instancia M5 o C5 tiene un costo más predecible y elimina la variable de créditos del diagnóstico operativo.

Política IAM Mínima para Diagnóstico de Créditos

🔽 Ver política IAM mínima requerida 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeInstanceCredits",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CloudWatchMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    }
  ]
}

Nota: ec2:DescribeInstanceCreditSpecifications y cloudwatch:GetMetricStatistics requieren "Resource": "*" ya que no admiten restricción a nivel de recurso específico según la Service Authorization Reference de AWS.

Conclusión y Próximos Pasos con Instancias T3 Burstables

El sistema de créditos de CPU de las instancias T3 burstables es potente para cargas variables, pero introduce una dimensión de rendimiento que no existe en instancias de propósito general. El throttling silencioso — sin errores en logs, con métricas de CPU aparentemente normales — es el síntoma más engañoso en operaciones con estas instancias.

Pasos concretos para operar instancias T3 de forma segura:

  1. Verifica el modo de crédito actual de todas tus instancias T3 con describe-instance-credit-specifications.
  2. Configura alarmas de CloudWatch sobre CPUCreditBalance para cada instancia T3 en producción.
  3. Revisa el historial de CPUCreditUsage para identificar instancias con patrones de consumo sostenido.
  4. Evalúa migrar a instancias M5 o C5 si el uso de CPU supera el baseline de forma consistente.

Documentación de referencia: AWS — Instancias de rendimiento burstable.

Glosario de Términos Clave

Término Definición
CPU Credit Unidad de rendimiento de CPU. Un crédito = 100% de un vCPU durante 1 minuto.
Baseline Porcentaje de CPU garantizado para una instancia T3 sin consumir créditos.
CPU Throttling Limitación del rendimiento de CPU al baseline cuando los créditos se agotan en modo Standard.
Modo Unlimited Modo de operación T3 que permite burst sostenido con posible cargo adicional por créditos surplus.
CPUSurplusCreditsCharged Métrica de CloudWatch que indica créditos consumidos más allá del balance acumulado en modo Unlimited.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más