Entendendo Instâncias T3 Burstáveis: CPU Credits e Por Que Seu Servidor Fica Lento

Você sobe uma instância T3 para um ambiente de staging, tudo funciona bem por horas — até que, do nada, a CPU trava em 5% e a aplicação começa a responder com latência absurda. Sem erro no log, sem alarme disparado, sem explicação óbvia. Esse é o comportamento clássico de esgotamento de créditos de CPU em instâncias T3, e entender o mecanismo por trás disso é o que separa um diagnóstico de 5 minutos de horas de investigação inútil.

TL;DR: Instâncias T3 e CPU Credits

Conceito	Comportamento
CPU Credit	Unidade que permite uso de CPU acima da baseline por 1 minuto
Baseline de CPU	Percentual garantido de CPU por tipo de instância (ex: t3.micro = 10%)
Acúmulo de créditos	Créditos acumulam quando CPU fica abaixo da baseline
Esgotamento	CPU é limitada à baseline quando créditos acabam (modo Standard)
Modo Unlimited	Permite burst além dos créditos acumulados, com custo adicional
Diagnóstico principal	Métrica CPUCreditBalance no CloudWatch

Como o Mecanismo de CPU Credits Funciona

Instâncias T3 não são instâncias de propósito geral com CPU dedicada. Elas são projetadas para cargas de trabalho com uso de CPU variável — picos ocasionais intercalados com períodos de baixa utilização. O modelo de créditos é o mecanismo que viabiliza isso.

Cada instância T3 tem uma baseline de CPU — um percentual de vCPU que ela pode usar indefinidamente sem consumir créditos. Quando a utilização fica abaixo dessa baseline, a instância acumula créditos. Quando ultrapassa, ela gasta créditos. A relação é direta: 1 crédito de CPU = 1 vCPU rodando a 100% por 1 minuto.

graph TD A["CPU abaixo da baseline"] -->|"acumula créditos"| B["CPUCreditBalance aumenta"] B --> C{"Bucket cheio?"} C -->|"Não"| A C -->|"Sim — limite máximo atingido"| D["Créditos não acumulam mais"] E["CPU acima da baseline"] -->|"consome créditos"| F["CPUCreditBalance diminui"] F --> G{"Saldo zerou?"} G -->|"Não"| E G -->|"Sim — modo Standard"| H["CPU limitada à baseline
throttling silencioso"] G -->|"Sim — modo Unlimited"| I["Burst continua
CPUSurplusCreditBalance aumenta"]

1. Acúmulo: CPU abaixo da baseline gera créditos no bucket. O bucket tem um limite máximo por tipo de instância.
2. Burst: CPU acima da baseline consome créditos acumulados. A instância pode usar até 100% da vCPU enquanto houver créditos.
3. Esgotamento (modo Standard): Quando o saldo de créditos chega a zero, a CPU é limitada à baseline. Isso acontece silenciosamente — sem erro, sem reinicialização.
4. Modo Unlimited: A instância pode continuar em burst além dos créditos acumulados. O excesso é cobrado por vCPU-hora adicional.

Pense nos créditos como um cartão pré-pago de CPU. Você pode gastar mais do que ganha por um tempo, mas quando o saldo zera (no modo Standard), a operadora simplesmente corta o serviço no teto da franquia — sem aviso prévio.

A partir do lançamento das instâncias T3, o modo padrão é Unlimited — diferente das instâncias T2, que nasceram com o modo Standard como padrão. Isso significa que uma instância T3 nova pode acumular cobranças de burst sem que você perceba, especialmente em ambientes de desenvolvimento onde ninguém monitora custo de CPU.

Baseline por Tipo de Instância T3

A baseline define o comportamento em regime permanente. Conhecer esse valor é essencial para dimensionar corretamente a instância para a carga esperada.

Tipo	vCPUs	Baseline por vCPU	Créditos ganhos/hora	Máximo de créditos acumulados
t3.nano	2	5%	6	144
t3.micro	2	10%	12	288
t3.small	2	20%	24	576
t3.medium	2	20%	24	576
t3.large	2	30%	36	864
t3.xlarge	4	40%	96	2304
t3.2xlarge	8	40%	192	4608

Verifique sempre os valores atualizados na documentação oficial da AWS, pois esses números podem ser revisados.

Diagnóstico: Por Que Meu Servidor Ficou Lento?

O padrão de falha é sempre o mesmo: a instância funciona normalmente, passa por um período de alta utilização de CPU, e depois fica inexplicavelmente lenta — mesmo com CPU aparentemente baixa no console. O que o console mostra é a utilização atual, não o saldo de créditos.

graph LR A["Instância T3 inicia"] --> B["CPU baixa — acumulando créditos"] B --> C["Pico de carga — burst ativo"] C --> D["CPUCreditBalance cai"] D --> E{"Modo configurado?"} E -->|"Standard"| F{"Saldo zerou?"} E -->|"Unlimited"| G["Burst continua
surplus acumula"] F -->|"Não"| C F -->|"Sim"| H["CPU throttled na baseline"] H --> I["Lentidão — sem erro no log"] I --> J["CPUCreditBalance = 0
diagnóstico confirmado"]

Passo 1 — Verificar o saldo de créditos no CloudWatch

Esse é o primeiro lugar a olhar. A métrica CPUCreditBalance mostra quantos créditos estão disponíveis. Se o valor está próximo de zero ou chegou a zero no momento em que a lentidão começou, o diagnóstico está feito.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Correlacione o timestamp em que CPUCreditBalance chegou a zero com o início da lentidão reportada. Na maioria dos casos, a correlação é exata.

Passo 2 — Verificar o consumo de créditos

O saldo zerado confirma o esgotamento, mas a métrica CPUCreditUsage mostra o ritmo de consumo — útil para entender se foi um pico pontual ou carga sustentada acima da baseline. Isso define se a solução é trocar de instância ou ajustar a aplicação.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Passo 3 — Verificar o modo de crédito configurado

Antes de decidir entre trocar de instância ou habilitar Unlimited, confirme qual modo está ativo. Uma instância T3 em modo Unlimited não vai travar na baseline — ela vai continuar em burst e gerar cobrança adicional. Se a instância está em modo Standard e o saldo zerou, o throttling é o comportamento esperado.

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1

A resposta retorna o campo CpuCredits com valor standard ou unlimited.

Passo 4 — Verificar o surplus de créditos (modo Unlimited)

Se a instância está em modo Unlimited e você suspeita de cobrança inesperada, a métrica CPUSurplusCreditBalance mostra quantos créditos foram usados além do acumulado. Créditos surplus são cobrados quando não são compensados por acúmulo subsequente dentro do ciclo de 24 horas.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Experiência de Campo: O Diagnóstico Errado Que Todo Mundo Faz

A instância de staging estava respondendo com 8-10 segundos de latência em requisições que normalmente levavam menos de 200ms. O time abriu o console EC2, viu CPU em 8%, memória normal, sem erros de disco. Conclusão imediata: problema na aplicação, provavelmente um query lento no banco.

Duas horas de análise de query plan, índices e slow log depois — nada. O banco estava saudável. A aplicação estava saudável. A instância é que estava throttled na baseline de 10% de CPU, processando cada requisição na fração da capacidade normal.

O erro foi olhar para a utilização de CPU como indicador de capacidade disponível. Quando uma instância T3 está throttled, ela mostra baixa utilização porque está sendo artificialmente limitada — não porque a carga diminuiu. A métrica que importava era CPUCreditBalance, que estava em zero há mais de uma hora.

CPU baixa no console não significa CPU disponível. Em instâncias T3 com créditos esgotados, CPU baixa pode significar exatamente o oposto: a instância está no teto da sua capacidade atual.

A correção imediata foi mudar para modo Unlimited para restaurar o serviço. A correção definitiva foi avaliar se a carga média real justificava uma instância T3 ou se um tipo M5 seria mais adequado para aquele workload.

Alterando o Modo de Crédito

Habilitando modo Unlimited

Pode ser feito com a instância rodando, sem necessidade de parada.

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=unlimited \
  --region us-east-1

Revertendo para modo Standard

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1

Alterando múltiplas instâncias

🔽 Clique para expandir — modificar múltiplas instâncias

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications \
    InstanceId=i-1234567890abcdef0,CpuCredits=unlimited \
    InstanceId=i-0987654321fedcba0,CpuCredits=unlimited \
    InstanceId=i-abcdef1234567890a,CpuCredits=standard \
  --region us-east-1

Configurando Alarmes para CPU Credits no CloudWatch

Monitorar CPUCreditBalance reativamente — só quando a lentidão já aconteceu — não resolve o problema operacionalmente. O alarme deve disparar antes do esgotamento, com margem suficiente para agir.

aws cloudwatch put-metric-alarm \
  --alarm-name t3-cpu-credit-low-i-1234567890abcdef0 \
  --alarm-description 'CPUCreditBalance abaixo de 30 - risco de throttling' \
  --metric-name CPUCreditBalance \
  --namespace AWS/EC2 \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1

O threshold de 30 créditos é um ponto de partida — ajuste conforme o ritmo de consumo da sua instância. Para uma t3.micro que ganha 12 créditos por hora, 30 créditos representam 2,5 horas de buffer se a CPU ficar na baseline.

Quando T3 Não é a Escolha Certa

O modelo de créditos funciona bem para workloads genuinamente intermitentes: servidores de desenvolvimento, aplicações com tráfego irregular, workers de background com picos ocasionais. Quando a carga média de CPU sustentada fica consistentemente acima da baseline, a instância T3 em modo Unlimited começa a gerar custo de surplus que pode superar o custo de uma instância M5 equivalente.

graph TD A["Qual é o padrão de carga?"] --> B{"CPU média sustentada
vs baseline"} B -->|"Consistentemente abaixo"| C["T3 Standard melhor custo"] B -->|"Picos ocasionais
média abaixo"| D["T3 Unlimited custo controlado"] B -->|"Consistentemente acima"| E{"Comparar custo total"} E -->|"T3 Unlimited + surplus
menor que M5"| F["T3 Unlimited monitorar surplus"] E -->|"M5 mais barato
no total"| G["Migrar para M5 ou instância equivalente"]

A decisão não é binária. Em muitos casos, o padrão de carga real justifica T3 Unlimited com custo total menor que M5. O problema é tomar essa decisão sem dados — baseando-se apenas no custo base da instância, ignorando o custo de surplus.

IAM: Permissões Necessárias para Diagnóstico e Modificação

🔽 Clique para expandir — política IAM mínima

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchReadCPUCredits",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2ReadCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2ModifyCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
    }
  ]
}

As ações Describe* do EC2 e GetMetricStatistics do CloudWatch não suportam restrição por ARN de recurso específico — por isso Resource: * é necessário nessas ações. A ação de modificação (ModifyInstanceCreditSpecification) pode ser restrita por ARN de instância ou por tags.

Próximos Passos e Entendendo Instâncias T3 em Produção

O mecanismo de CPU credits em instâncias T3 é simples quando você entende o modelo — mas invisível quando você não entende. A maioria dos problemas de performance em T3 é diagnosticada como problema de aplicação porque ninguém pensa em verificar CPUCreditBalance primeiro.

Checklist operacional para instâncias T3 em produção:

• Defina alarme em CPUCreditBalance com threshold que dê tempo de reação
• Decida conscientemente entre modo Standard e Unlimited — não aceite o padrão sem avaliar
• Monitore CPUSurplusCreditBalance em instâncias Unlimited para detectar custo inesperado
• Reavalie o tipo de instância se a CPU média sustentada ficar consistentemente acima da baseline

Referências oficiais:

• AWS EC2 — Burstable Performance Instances
• CPU Credits and Baseline Utilization
• Unlimited Mode for Burstable Instances

Glossário

Termo	Definição
CPU Credit	Unidade de capacidade de CPU que permite uso acima da baseline. 1 crédito = 1 vCPU a 100% por 1 minuto.
Baseline de CPU	Percentual de vCPU que a instância pode usar indefinidamente sem consumir créditos.
CPU Throttling	Limitação forçada da CPU à baseline quando o saldo de créditos se esgota no modo Standard.
Modo Unlimited	Configuração que permite burst além dos créditos acumulados, com cobrança adicional pelo excesso.
CPUSurplusCreditBalance	Créditos usados além do saldo acumulado em modo Unlimited. Geram cobrança se não compensados em 24 horas.