EBS gp2 vs gp3: Qual escolher para escalar IOPS sem aumentar o disco?

Você está provisionando um volume EBS e vê duas opções de SSD de uso geral: gp2 e gp3. A diferença não é apenas de geração — o modelo de performance e custo entre eles é fundamentalmente diferente, e escolher errado significa pagar mais por menos controle. Em workloads de banco de dados ou aplicações com picos de I/O previsíveis, essa decisão impacta diretamente o comportamento da instância em produção.

TL;DR: gp2 vs gp3 — Comparação Direta

Característica gp2 gp3
IOPS base 3 IOPS/GB (mín. 100, máx. 16.000) 3.000 IOPS fixos incluídos
IOPS independente do tamanho Não — acoplado ao tamanho do volume Sim — configurável até 16.000 IOPS
Throughput máximo 250 MiB/s 1.000 MiB/s
Throughput base incluído Acoplado ao modelo de burst 125 MiB/s incluídos
Custo por GB Maior (varia por região) Menor (varia por região)
Burst de IOPS Sim (até 3.000 IOPS via créditos) Não necessário — baseline já é 3.000
Caso de uso ideal Workloads legados ou migração direta Novos volumes, otimização de custo/performance

Como o gp2 e o gp3 Funcionam por Dentro

Antes de decidir, é necessário entender o mecanismo de performance de cada tipo — porque o comportamento em produção é bem diferente do que os números de marketing sugerem.

Modelo de performance do gp2

O gp2 acopla IOPS ao tamanho do volume: você recebe 3 IOPS por GB provisionado. Um volume de 100 GB entrega 300 IOPS de base. O máximo atingível é 16.000 IOPS, o que exige um volume de pelo menos 5.334 GB. Para volumes menores que 33,34 GB, a AWS garante um mínimo de 100 IOPS — o volume não cai abaixo desse piso, independentemente do tamanho.

Para compensar a baixa performance base em volumes pequenos, o gp2 usa um sistema de burst baseado em créditos de I/O. Volumes com menos de 1.000 GB podem fazer burst até 3.000 IOPS enquanto o bucket de créditos não esgota. Quando os créditos acabam, a performance cai para o baseline calculado por tamanho. Esse comportamento é o principal ponto de falha silenciosa em produção.

O sistema de créditos do gp2 funciona como uma bateria: enquanto o volume está ocioso, ela carrega. Quando a aplicação exige I/O intenso por tempo prolongado, a bateria descarrega — e a performance despenca sem aviso explícito no console.

Modelo de performance do gp3

O gp3 desacopla completamente IOPS e throughput do tamanho do volume. Todo volume gp3 começa com 3.000 IOPS e 125 MiB/s incluídos no preço base, independentemente de quantos GB foram provisionados. Você pode provisionar IOPS adicionais — até 16.000 — e throughput adicional — até 1.000 MiB/s — pagando separadamente por essas dimensões. Não existe sistema de burst nem bucket de créditos.

graph TD A["Volume gp2
200 GB"] --> B["IOPS Base: 600
(3 IOPS/GB)"] B --> C{"Créditos
disponíveis?"} C -- Sim --> D["Burst até 3.000 IOPS
(temporário)"] C -- Não --> E["Opera a 600 IOPS
(degradação silenciosa)"] F["Volume gp3
200 GB"] --> G["3.000 IOPS incluídos
(sem créditos)"] G --> H["Performance sustentada
sem degradação"] G --> I["IOPS adicionais
configuráveis até 16.000"]
  1. gp2 — acoplamento IOPS/tamanho: aumentar IOPS exige aumentar o volume. O burst mascara o problema temporariamente, mas esgota créditos sob carga sustentada.
  2. gp3 — dimensões independentes: tamanho, IOPS e throughput são configurados separadamente. Um volume de 20 GB pode ter 10.000 IOPS sem precisar de 3.333 GB de disco.
  3. Ponto de inflexão gp2: volumes acima de 1.000 GB no gp2 atingem 3.000 IOPS de base sem burst — exatamente o mesmo que o gp3 entrega por padrão em qualquer tamanho.

Quando o gp2 Falha em Produção: Um Padrão Comum

O cenário mais frequente: uma instância RDS ou EC2 com volume gp2 de 200 GB funciona bem durante semanas. O time observa latência de I/O aceitável nos dashboards. Então, durante uma janela de carga alta — backup noturno, reindex, migration — a latência de disco explode. O primeiro diagnóstico é quase sempre errado.

A suposição inicial é problema de instância: CPU, memória, conexões. O volume parece saudável no console — não há alarme de IOPS estourado. O que aconteceu foi o esgotamento silencioso do bucket de créditos de burst do gp2. Um volume de 200 GB tem baseline de 600 IOPS. Quando os créditos acabam após minutos de I/O intenso, o volume opera a 600 IOPS — e a aplicação, que esperava 3.000, trava.

A métrica que confirma o diagnóstico é BurstBalance no CloudWatch, disponível para volumes gp2. Quando esse valor cai para zero e a latência sobe simultaneamente, o esgotamento de créditos é a causa.

# Verificar BurstBalance de um volume gp2 nos últimos 60 minutos
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time $(date -u -d '60 minutes ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Average \
  --region us-east-1

No gp3, essa métrica não existe — porque não há créditos para esgotar. Os 3.000 IOPS base são sustentados indefinidamente.

Escalando IOPS Independentemente do Tamanho: Apenas o gp3 Permite

Essa é a diferença operacional mais importante. Se você precisa de alta performance de I/O em um volume pequeno — um banco de dados OLTP com dataset de 50 GB que exige 8.000 IOPS, por exemplo — o gp2 força você a provisionar cerca de 2.667 GB de armazenamento que você não precisa, só para atingir o IOPS desejado.

Com gp3, você provisiona 50 GB e configura 8.000 IOPS diretamente. O custo adicional é cobrado pelos IOPS provisionados acima de 3.000, não pelo armazenamento desnecessário.

# Criar volume gp3 com IOPS e throughput customizados
aws ec2 create-volume \
  --volume-type gp3 \
  --size 50 \
  --iops 8000 \
  --throughput 500 \
  --availability-zone us-east-1a \
  --region us-east-1
# Modificar volume gp2 existente para gp3 com IOPS customizados
aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 8000 \
  --throughput 500 \
  --region us-east-1

A modificação de gp2 para gp3 pode ser feita sem downtime — o volume continua disponível durante a transição. O estado da modificação pode ser acompanhado com o comando abaixo.

# Verificar status da modificação do volume
aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --region us-east-1
graph LR subgraph gp2["gp2 — IOPS acoplado ao tamanho"] A1["Meta: 8.000 IOPS"] --> B1["Exige ~2.667 GB
provisionados"] B1 --> C1["Paga por 2.617 GB
desnecessários"] end subgraph gp3["gp3 — IOPS independente"] A2["Meta: 8.000 IOPS"] --> B2["Provisiona 50 GB
(tamanho real)"] B2 --> C2["Configura 8.000 IOPS
separadamente"] C2 --> D2["Paga apenas pelo
que usa"] end
  1. gp2 — caminho forçado: para obter 8.000 IOPS, o único caminho é aumentar o volume para ~2.667 GB, pagando por armazenamento desnecessário.
  2. gp3 — caminho direto: provisione o tamanho real necessário e configure IOPS separadamente. Sem desperdício de armazenamento.
  3. Modificação sem downtime: a transição de gp2 para gp3 é feita via modify-volume e não requer desanexar o volume ou reiniciar a instância.

Comparação de Custo: gp3 é Geralmente Mais Barato

O gp3 tem preço por GB menor que o gp2 na maioria das regiões AWS. Para volumes que não precisam de IOPS ou throughput acima dos valores base incluídos no gp3, a migração resulta em redução de custo imediata sem nenhuma mudança de configuração adicional.

O cenário onde o gp3 pode custar mais é quando você provisiona IOPS muito acima de 3.000 — porque esses IOPS adicionais têm custo separado. No gp2, IOPS altos são obtidos aumentando o volume, e o custo é embutido no preço por GB. Dependendo do ponto de equilíbrio, volumes gp2 muito grandes com alta demanda de IOPS podem ter custo total comparável ao gp3 com IOPS provisionados.

Preços e limites variam — sempre verifique a página oficial de preços do EBS para sua região antes de tomar decisões baseadas em custo.

IAM: Permissões Necessárias para Gerenciar Volumes EBS

Para executar os comandos de criação e modificação de volumes mostrados neste post, a principal ou role precisa das seguintes permissões mínimas.

🔽 Clique para expandir — Política IAM mínima para gerenciar volumes EBS 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeVolumes",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CreateAndModifyVolumes",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVolume",
        "ec2:ModifyVolume"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CloudWatchEBSMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

As ações ec2:DescribeVolumes e ec2:DescribeVolumesModifications exigem Resource: * — restrição por ARN de recurso específico não é suportada para essas ações de leitura/listagem conforme a Service Authorization Reference da AWS.

Guia de Decisão: gp2 ou gp3?

graph TD START(["Preciso de um volume EBS"]) --> Q1{"É um volume novo?"} Q1 -- Sim --> REC1["Use gp3
(padrão recomendado)"] Q1 -- Não --> Q2{"Volume gp2 com
BurstBalance esgotando?"} Q2 -- Sim --> REC2["Migre para gp3
via modify-volume"] Q2 -- Não --> Q3{"Precisa de IOPS alto
em volume pequeno?"} Q3 -- Sim --> REC3["gp3 — configure IOPS
independentemente"] Q3 -- Não --> Q4{"Volume gp2 estável
sem problemas?"} Q4 -- Sim --> REC4["Avalie custo:
gp3 tende a ser mais barato por GB"] Q4 -- Não --> REC2
  1. Novo volume: o ponto de partida padrão hoje é gp3. A AWS recomenda gp3 como substituto do gp2 para a maioria dos casos de uso.
  2. Volume gp2 existente com burst esgotando: migre para gp3. O problema de créditos desaparece e você ganha controle explícito sobre IOPS.
  3. IOPS alto em volume pequeno: gp3 é o único caminho sem desperdiçar armazenamento.
  4. Volume gp2 grande e estável: avalie o custo antes de migrar. Se o volume já tem IOPS base suficiente pelo tamanho e não há problemas de burst, a migração ainda é recomendada pelo custo menor por GB do gp3, mas o impacto operacional é menor.

Conclusão: gp3 como Padrão para Novos Volumes EBS

O gp3 resolve os dois problemas centrais do gp2: o acoplamento entre IOPS e tamanho de volume, e o comportamento imprevisível do sistema de burst sob carga sustentada. Para a maioria dos workloads, o gp3 entrega mais controle, performance previsível e custo menor por GB.

A única razão para manter gp2 hoje é inércia operacional — volumes existentes que funcionam e onde o custo de validar a migração não se justifica no curto prazo. Para novos volumes, não há argumento técnico para escolher gp2.

Próximos passos recomendados:

  • Audite volumes gp2 existentes verificando a métrica BurstBalance no CloudWatch
  • Identifique volumes onde o BurstBalance cai frequentemente — esses são candidatos imediatos para migração
  • Use aws ec2 modify-volume para migrar sem downtime
  • Consulte a documentação oficial de tipos de volume EBS para detalhes atualizados de limites e preços por região

Glossário

Termo Definição
IOPS Input/Output Operations Per Second — medida de throughput de operações de leitura e escrita em disco.
Burst de I/O Capacidade temporária de exceder o IOPS base usando créditos acumulados durante períodos de baixa atividade. Exclusivo do gp2.
BurstBalance Métrica CloudWatch que indica o percentual de créditos de burst restantes em um volume gp2. Quando atinge zero, o volume opera apenas no IOPS base.
Throughput Volume de dados transferidos por segundo (MiB/s). No gp3, configurável independentemente dos IOPS.
modify-volume API da AWS que permite alterar tipo, tamanho, IOPS e throughput de um volume EBS sem desanexá-lo ou reiniciar a instância.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

EC2 SSH Connection Timeout: Quais Regras do Security Group Verificar

Você acabou de lançar uma instância EC2, tenta conectar via SSH e recebe ssh: connect to host X.X.X.X port 22: Connection timed out . Esse erro específico — timeout, não recusa — quase sempre aponta para bloqueio de rede antes mesmo do pacote chegar ao sistema operacional. O culpado mais comum é o Security Group, mas não é o único. TL;DR — EC2 SSH Connection Timeout: O Que Verificar Camada O Que Verificar Impacto se Errado Security Group Regra inbound TCP/22 com source correto Pacote descartado silenciosamente Network ACL Regra allow na porta 22 e portas efêmeras no outbound Timeout sem log de erro Rota da Subnet Internet Gateway associado à route table Pacote sem caminho de retorno IP Público / EIP Instância tem endereço IP público atribuído Destino inalcançável Firewall do SO iptables / firewalld bloqueando porta 22 Conexão recusada ou timeout Como o Tráfego SSH Chega à Instância EC2 Antes d...
Leia mais

EC2 Sem Acesso à Internet em VPC Customizada: Como Configurar Internet Gateway e Route Table

Você criou uma VPC do zero, subiu uma instância EC2 em uma subnet pública e tentou um simples ping google.com — sem resposta. Esse é um dos problemas mais comuns ao trabalhar com VPCs customizadas no AWS, e a causa quase sempre está na ausência de um Internet Gateway associado ou em uma Route Table que não sabe para onde mandar o tráfego de saída. TL;DR — EC2 Sem Acesso à Internet em VPC Customizada Componente O que precisa estar configurado Internet Gateway (IGW) Criado e anexado à VPC Route Table Rota 0.0.0.0/0 apontando para o IGW Subnet Associada à Route Table com a rota para o IGW IP Público Instância com Elastic IP ou auto-assign de IP público habilitado Security Group Regra de saída permitindo o tráfego desejado Network ACL Regras de entrada e saída permitindo o tráfego (stateless) Como o Roteamento de Internet Funciona em uma VPC Customizada Quando a AWS cria a VPC padrão da su...
Leia mais

S3 Access Denied: Por que 'Bloquear Acesso Público' impede seu objeto mesmo após torná-lo público

Você fez upload de uma imagem no S3, marcou o objeto como público, copiou a URL e abriu no navegador — e recebeu um 403 Access Denied . A configuração de ACL do objeto está correta, mas o acesso público continua bloqueado. O culpado quase sempre é o Block Public Access no nível do bucket, uma camada de controle que opera acima das ACLs e políticas de objeto e que muita gente ignora até levar o primeiro 403 em produção. TL;DR — S3 Access Denied com objeto público Camada O que controla O que verificar Block Public Access (bucket) Bloqueia ACLs e políticas públicas no bucket inteiro aws s3api get-public-access-block --bucket NOME ACL do objeto Permissão pública no objeto individual aws s3api get-object-acl --bucket NOME --key CHAVE Bucket Policy Permissões baseadas em política no bucket aws s3api get-bucket-policy --bucket NOME Object Ownership Controla se ACLs são respeitadas ou ignoradas aws s3api get-buc...
Leia mais