EBS gp2 vs gp3: Cuándo migrar y cómo escalar IOPS sin crecer el volumen

Cuando revisas las opciones de almacenamiento para una instancia EC2 y ves gp2 y gp3 en el selector de volúmenes EBS, la diferencia no es obvia hasta que recibes la factura de AWS o intentas escalar rendimiento sin querer pagar por terabytes que no necesitas. Este artículo explica el modelo de rendimiento de cada tipo, cuándo uno supera al otro, y cómo migrar sin downtime.

TL;DR — EBS gp2 vs gp3 en producción

Característica gp2 gp3
IOPS base 3 IOPS/GiB (mínimo 100, máximo 16.000) 3.000 IOPS incluidas, independientes del tamaño
IOPS máximas 16.000 (requiere ≥ 5.334 GiB) 16.000 (configurables sin cambiar el tamaño)
Throughput máximo 250 MiB/s 1.000 MiB/s
Throughput base incluido Vinculado a IOPS 125 MiB/s incluidos, hasta 1.000 MiB/s configurable
Modelo de créditos de burst Sí (bucket de créditos I/O) No — rendimiento consistente
Costo relativo Mayor para volúmenes grandes con IOPS moderadas Generalmente más económico para el mismo rendimiento
Escalado independiente de IOPS No — IOPS acopladas al tamaño Sí — IOPS y throughput configurables por separado

Cómo funciona el rendimiento en EBS gp2 y gp3

Antes de decidir cuál usar, es necesario entender el modelo de rendimiento de cada tipo. No son variantes cosméticas — tienen arquitecturas de rendimiento fundamentalmente distintas.

gp2: IOPS acopladas al tamaño y el sistema de créditos

En gp2, las IOPS base se calculan multiplicando el tamaño del volumen en GiB por 3. Un volumen de 100 GiB tiene 300 IOPS base. El mínimo garantizado es 100 IOPS y el máximo alcanzable es 16.000 IOPS, lo que requiere un volumen de al menos 5.334 GiB.

Para volúmenes de menos de 1.000 GiB, gp2 implementa un mecanismo de burst: cuando el volumen no está usando sus IOPS base, acumula créditos I/O en un bucket con capacidad máxima de 5,4 millones de créditos. Esos créditos permiten operar a hasta 3.000 IOPS durante un período limitado. Cuando el bucket se vacía, el rendimiento cae a las IOPS base. Este comportamiento es la causa más frecuente de degradación de rendimiento intermitente en instancias con volúmenes gp2 pequeños.

El sistema de créditos de gp2 funciona como una batería: útil para picos cortos, pero si tu carga es sostenida, la batería se agota y el rendimiento colapsa sin ninguna alerta visible en la consola.

gp3: rendimiento desacoplado del tamaño

gp3 rompe el acoplamiento entre tamaño e IOPS. Todo volumen gp3, independientemente de su tamaño, incluye 3.000 IOPS y 125 MiB/s de throughput sin costo adicional. Si necesitas más, puedes configurar hasta 16.000 IOPS y hasta 1.000 MiB/s de throughput pagando solo por el incremento, sin necesidad de aumentar el tamaño del volumen.

No hay bucket de créditos. El rendimiento configurado es el rendimiento entregado de forma consistente. Para cargas de trabajo con I/O sostenida — bases de datos, sistemas de logging de alto volumen, pipelines de procesamiento — esto elimina la variabilidad que gp2 introduce.

graph TD A["Volumen EBS gp2"] --> B["Tamaño del volumen (GiB)"] B --> C["IOPS base = GiB × 3
mín 100, máx 16.000"] C --> D{"¿Volumen < 1.000 GiB?"} D -- Sí --> E["Burst disponible
hasta 3.000 IOPS"] D -- No --> F["IOPS base sostenidas"] E --> G{"¿BurstBalance > 0?"} G -- Sí --> H["Rendimiento en burst"] G -- No --> I["Caída a IOPS base"] J["Volumen EBS gp3"] --> K["3.000 IOPS incluidas
125 MiB/s incluidos"] K --> L["Configurar IOPS adicionales
hasta 16.000"] K --> M["Configurar Throughput adicional
hasta 1.000 MiB/s"] L --> N["Rendimiento consistente
sin créditos"] M --> N
  1. gp2 — IOPS acopladas: el tamaño del volumen determina directamente las IOPS disponibles. Para obtener más IOPS, debes crecer el volumen.
  2. gp2 — Burst temporal: volúmenes pequeños pueden superar sus IOPS base consumiendo créditos acumulados, pero solo mientras el bucket no esté vacío.
  3. gp3 — IOPS base garantizadas: 3.000 IOPS incluidas en cualquier volumen, sin importar el tamaño.
  4. gp3 — Escalado independiente: IOPS y throughput se configuran directamente, desacoplados del tamaño del volumen.

¿Cuál es más económico? Comparación de costos EBS gp2 vs gp3

Pricing and limits vary — always check the official AWS documentation. Sin embargo, el patrón general documentado por AWS es que gp3 tiene un precio por GiB-mes menor que gp2, y las IOPS adicionales en gp3 se cobran por encima de las 3.000 incluidas. En gp2, no puedes comprar IOPS adicionales sin comprar almacenamiento adicional.

El escenario donde gp2 puede resultar más económico es prácticamente inexistente para cargas de trabajo nuevas. El caso típico donde gp2 sale más caro: un volumen de 200 GiB que necesita 3.000 IOPS sostenidas. En gp2, necesitas 1.000 GiB para alcanzar esas IOPS de forma garantizada (sin depender del burst). En gp3, un volumen de 200 GiB ya incluye 3.000 IOPS. Pagas por 200 GiB, no por 1.000 GiB.

graph LR A["Necesito 3.000 IOPS sostenidas"] --> B{"¿Qué tipo uso?"} B -- gp2 --> C["Necesito ≥ 1.000 GiB
para 3.000 IOPS base"] B -- gp3 --> D["Cualquier tamaño
3.000 IOPS incluidas"] C --> E["Pago por 1.000 GiB
aunque use 200 GiB"] D --> F["Pago por 200 GiB
+ 0 IOPS extra"] E --> G["Costo mayor"] F --> H["Costo menor"]
  1. Volúmenes pequeños con IOPS moderadas: gp3 es más económico porque no necesitas sobredimensionar el volumen para alcanzar las IOPS requeridas.
  2. Volúmenes grandes con IOPS bajas: gp3 sigue siendo competitivo o más barato por el menor precio por GiB-mes.
  3. IOPS muy altas (> 16.000): ambos tipos alcanzan el mismo máximo de 16.000 IOPS. Si necesitas más, debes considerar io1/io2.

Diagnóstico: cómo saber si tu volumen gp2 está siendo limitado

El síntoma más común es latencia de I/O intermitente que no correlaciona con carga de CPU ni con tráfico de red. La aplicación se ralentiza, los logs muestran timeouts de base de datos o escrituras lentas, pero las métricas de instancia parecen normales. El volumen está agotando sus créditos de burst.

Verifica el estado del bucket de créditos con CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Si BurstBalance cae consistentemente por debajo del 20% o llega a 0 durante ventanas de carga, el volumen está operando en modo degradado. Ese es el momento en que la migración a gp3 deja de ser una optimización de costos y se convierte en una corrección de estabilidad.

También revisa las IOPS reales consumidas versus las provisionadas:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeReadOps \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 60 \
  --statistics Sum \
  --region us-east-1

Cómo migrar de gp2 a gp3 sin downtime

EBS permite modificar el tipo de volumen en caliente usando Elastic Volumes. No se requiere detener la instancia ni desmontar el volumen. La modificación es en línea y el volumen permanece disponible durante el proceso.

Paso 1: Verificar el estado actual del volumen

Antes de modificar, confirma el tipo y tamaño actuales para calcular si necesitas ajustar IOPS o throughput en el destino:

aws ec2 describe-volumes \
  --volume-ids vol-0123456789abcdef0 \
  --query 'Volumes[*].{VolumeId:VolumeId,Type:VolumeType,Size:Size,Iops:Iops,State:State}' \
  --output table \
  --region us-east-1

Paso 2: Iniciar la modificación a gp3

Si tu carga requiere más de 3.000 IOPS o más de 125 MiB/s, especifícalos en el mismo comando. Si las IOPS base de gp3 son suficientes, omite los parámetros --iops y --throughput — los valores incluidos se aplican automáticamente:

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125 \
  --region us-east-1

Para un volumen que actualmente tiene 6.000 IOPS en gp2 (porque tiene 2.000 GiB), necesitas especificar explícitamente --iops 6000 al migrar a gp3. Si no lo haces, el volumen quedará con las 3.000 IOPS base de gp3 — un downgrade silencioso de rendimiento.

Paso 3: Monitorear el progreso de la modificación

La modificación pasa por los estados modifying, optimizing y finalmente completed. El volumen es completamente funcional durante todo el proceso, pero el rendimiento puede variar ligeramente durante la fase de optimización:

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,ModificationState:ModificationState,Progress:Progress,TargetVolumeType:TargetVolumeType}' \
  --output table \
  --region us-east-1

Paso 4: Verificar el resultado

aws ec2 describe-volumes \
  --volume-ids vol-0123456789abcdef0 \
  --query 'Volumes[*].{VolumeId:VolumeId,Type:VolumeType,Iops:Iops,Throughput:Throughput,State:State}' \
  --output table \
  --region us-east-1

El error de diagnóstico más frecuente en producción

El patrón que se repite: un equipo reporta degradación de rendimiento en una instancia de base de datos. Se revisan métricas de CPU, memoria, conexiones activas — todo normal. Se aumenta el tipo de instancia. El problema persiste. Finalmente alguien revisa BurstBalance en CloudWatch y está en 0 desde hace horas.

El volumen era gp2 de 500 GiB. Las IOPS base eran 1.500. La carga sostenida requería 2.800 IOPS. El burst cubría el gap durante minutos, pero con carga continua el bucket se vaciaba en menos de una hora. La solución no era una instancia más grande — era migrar a gp3 con 3.000 IOPS configuradas.

La lección operacional: cuando el rendimiento de I/O se degrada de forma intermitente y no hay correlación con métricas de instancia, BurstBalance es la primera métrica a revisar, no la última.

IAM mínimo necesario para modificar volúmenes EBS

La operación ModifyVolume requiere permisos explícitos. La política mínima para permitir modificaciones de volumen sin acceso de escritura a datos:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEBSVolumeModification",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyVolume",
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    }
  ]
}

Nota: DescribeVolumes y DescribeVolumesModifications son acciones de solo lectura que requieren "Resource": "*" según la Service Authorization Reference de AWS. ModifyVolume puede restringirse a ARNs de volumen específicos si el contexto lo requiere.

Cuándo gp3 no es suficiente: límites del tipo General Purpose

gp3 tiene un techo de 16.000 IOPS y 1.000 MiB/s de throughput. Si tu carga requiere más — bases de datos OLTP de alto volumen, workloads de latencia sub-milisegundo — necesitas evaluar io2 Block Express, que soporta hasta 256.000 IOPS por volumen. Ese es un territorio diferente en términos de costo y arquitectura.

Para la mayoría de las cargas de trabajo de propósito general, bases de datos medianas, servidores de aplicación y entornos de desarrollo/staging, gp3 cubre el rango operacional sin necesidad de provisionar IOPS adicionales.

Conclusión y próximos pasos con EBS gp3

La respuesta directa a la pregunta original: gp3 es el tipo que permite escalar IOPS independientemente del tamaño del volumen, y en la mayoría de los escenarios resulta más económico que gp2 para el mismo nivel de rendimiento. gp2 acopla IOPS al tamaño y depende de un sistema de créditos que introduce variabilidad en cargas sostenidas.

Para volúmenes existentes en gp2, la migración a gp3 es en línea y no requiere downtime. El único riesgo operacional es no especificar las IOPS correctas al migrar desde un volumen gp2 grande que depende de su tamaño para alcanzar IOPS elevadas.

Recursos de referencia:

Glosario de términos clave

Término Definición operacional
IOPS Input/Output Operations Per Second — número de operaciones de lectura/escritura que el volumen puede procesar por segundo.
Throughput Cantidad de datos transferidos por segundo (MiB/s). Distinto de IOPS — relevante para operaciones con bloques grandes.
Burst Balance Créditos I/O acumulados en gp2 que permiten superar las IOPS base temporalmente. Métrica disponible en CloudWatch.
Elastic Volumes Funcionalidad de EBS que permite modificar tipo, tamaño, IOPS y throughput de un volumen sin detener la instancia.
Provisioned IOPS IOPS configuradas explícitamente por el usuario, garantizadas de forma consistente sin depender de créditos ni del tamaño del volumen.

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