Capacidade base do Redshift Serverless ligada 24 horas pode inflar a fatura da AWS

Capacidade base do Redshift Serverless ligada 24 horas pode inflar a fatura da AWS

Um relato no DEV Community mostra como as 128 RPUs padrão do console, rodando o dia inteiro, geraram sobra de US$ 2.700 por mês até alguém medir o uso real.

Nota da redação: os detalhes do incidente relatado (valor da fatura, RPUs, prazo e citação do autor) foram confirmados no post original do DEV Community. Porém, as explicações técnicas sobre o funcionamento do Redshift Serverless citadas ao longo do texto (degraus de capacidade base, teto de storage por degrau, mecanismo de cobrança por RPU hora, restrição da API update-workgroup a um parâmetro por chamada, comportamento padrão do AI-driven scaling e a recomendação de piso de 32 RPU) têm como única fonte esse mesmo post de terceiro, sem confirmação na documentação oficial da AWS. Recomendamos checar esses pontos na documentação e na página de preços da AWS antes de usá-los para decisões de orçamento.

Um relato publicado no DEV Community mostra como a capacidade base de 128 RPUs, o valor que o console da AWS sugere por padrão, ficou rodando o dia inteiro e gerou uma sobra de US$ 2.700 por mês na fatura. O caso expõe um ponto cego comum em quem fecha orçamento de dados na nuvem.

O workgroup que custou US$ 2.700 a mais todo mês

Um consultor relatou em post no DEV Community (assinado por Arvind Toorpu) o caso de um cliente que criou um workgroup novo no Amazon Redshift Serverless, apontou o ELT noturno para ele e seguiu em frente. Três semanas depois, a fatura da AWS chegou quase quatro vezes acima do modelado. Ninguém tinha mexido em nenhum parâmetro: o workgroup continuava na capacidade base que o console preencheu sozinho na criação, 128 RPUs, ligados o dia inteiro, com ou sem consulta rodando.

Esse é o ponto cego do modelo serverless. Ele tira a pergunta "de que tamanho eu provisiono este cluster" da tela de criação, mas não elimina a necessidade de responder essa pergunta: só a empurra para a primeira fatura.

O que é um RPU e quem decide o mínimo

Um RPU (Redshift Processing Unit) é um pacote de computação e memória, 16 GB de memória por unidade. A capacidade base é o patamar em que o workgroup roda mesmo ocioso (mas "quente"), e o Redshift Serverless escala para cima automaticamente sob carga, a partir desse piso.

A cobrança é por segundo, com mínimo de 60 segundos, a US$ 0,375 por RPU-hora na região us-east-1, segundo o post original. O storage gerenciado (Redshift Managed Storage) é cobrado à parte, a US$ 0,024 por GB-mês na mesma região. Para quem opera em sa-east-1 (São Paulo), vale conferir a página oficial de preços da AWS: o valor por RPU-hora costuma variar entre regiões, e a fonte não traz o número específico para o Brasil.

A régua de capacidade que o console não explica

A capacidade base não é um número livre: ela segue degraus fixos, e cada degrau carrega um teto de armazenamento junto.

Isso significa que reduzir a capacidade base para economizar tem um efeito colateral: se o dataset crescer além do teto de storage daquele degrau, a única saída é subir a capacidade de novo, não apenas comprar mais armazenamento.

Quanto custa deixar ligado o tempo todo

Fazendo a conta com a tarifa que a fonte cita: 128 RPU a US$ 0,375 por RPU-hora dá US$ 48 por hora. Multiplicado pelas cerca de 730 horas de um mês, isso chega a um teto teórico de aproximadamente US$ 35 mil só de computação, caso o workgroup nunca escalasse para baixo. Esse número é uma conta de cima, feita a partir da fórmula de preço, não o valor exato que o cliente do relato pagou.

O ponto mais incômodo do caso real é outro: a fatura surpresa foi de US$ 2.700 por mês, não o teto teórico inteiro. Ou seja, mesmo com uso real bem abaixo da capacidade máxima, o workgroup ficou pago como se estivesse perto do piso de 128 RPU boa parte do tempo, porque escalar para cima é automático, mas escalar para baixo não é instantâneo nem garantido em todos os casos, especialmente nos níveis mais baixos.

Como medir o que você realmente usa

Antes de tocar em qualquer parâmetro, o post recomenda medir com duas views de sistema do próprio Redshift Serverless, rodando por uma semana representativa:

-- Tempo total de execução de queries por hora
SELECT
 date_trunc('hour', start_time) AS hour,
 count(*) AS query_count,
 sum(datediff(millisecond, start_time, end_time)) AS total_elapsed_ms
FROM sys_query_history
WHERE start_time >= dateadd(day, -7, current_date)
GROUP BY 1
ORDER BY 1;

-- RPU-horas efetivamente cobradas
SELECT
 date_trunc('day', start_time) AS day,
 sum(charged_seconds) / 3600.0 AS rpu_hours,
 sum(charged_seconds) / 3600.0 * 0.375 AS approx_cost_usd
FROM sys_serverless_usage;

Se o workgroup está travado em 128 RPU mas a sys_serverless_usage mostra que ele raramente passa do que uma base de 8 ou 16 RPU cobriria, a resposta já está na tela.

Ajustando a capacidade pelo CLI

Com o número em mãos, o ajuste é um comando:

aws redshift-serverless update-workgroup \
 --workgroup-name my-analytics-wg \
 --base-capacity 32

Uma restrição importante: update-workgroup aceita só um parâmetro alterável por chamada. Não dá para mudar --base-capacity e --port na mesma requisição, o que obriga a planejar a sequência das mudanças em vez de empacotar tudo num único deploy.

Escala automática por IA: vale a pena?

Para workloads com picos irregulares em vez de carga estável, a alternativa à capacidade fixa é o AI-driven scaling, que hoje já é o padrão para workgroups novos. Ele ajusta a capacidade dinamicamente dentro de uma faixa de 8 a 512 RPU, controlada por um indicador de custo versus performance:

--price-performance-target Level=25,Status=ENABLED

O nível 1 otimiza ao máximo para custo, o 100 otimiza ao máximo para velocidade, e 50 é o padrão balanceado. Segundo o post, o benchmark TPC-DS feito pela própria AWS mostrou que a configuração Balanced entrega cerca do dobro da performance da configuração Optimized-for-Cost por apenas cerca de 3% a mais de gasto, uma troca que compensa sempre que o workload tem alguma concorrência real de consultas.

A ressalva: a própria AWS recomenda não usar o AI-driven scaling abaixo de aproximadamente 32 RPU de base, embora o piso mínimo para habilitar o recurso tenha caído ao longo do tempo; para cargas genuinamente pequenas, uma base fixa continua mais simples de prever.

O que muda pra quem fecha a fatura

No modelo serverless, os controles de custo disponíveis se resumem a dois: o dimensionamento correto da capacidade base e um limite de uso (usage limit) configurado em RPU-horas, com alerta ou corte automático quando o teto é atingido.

A cobrança do modelo serverless exige a mesma disciplina que sempre exigiu de clusters provisionados, só esconde esse fato atrás de um assistente de criação mais amigável.

Serverless billing rewards the same discipline provisioned clusters always demanded, it just hides that fact behind a friendlier setup wizard.Arvind Toorpu, autor do relato publicado no DEV Community

Para quem responde pela fatura e pelo orçamento de dados, isso significa que o risco não está num pico de uso isolado, mas em um workgroup esquecido rodando no padrão do console, mês após mês, sem ninguém revisitar o número. Um usage limit não substitui o right-sizing: ele é a rede de segurança que impede uma query solta de virar fatura de choque, enquanto a capacidade base ajustada é a prevenção.

Checklist antes de fechar o trimestre

• Rodar sys_serverless_usage por uma semana representativa antes de mexer em qualquer parâmetro
• Comparar a capacidade base atual com o p50 real de uso, não com o pico
• Ajustar --base-capacity pelo CLI, lembrando da restrição de um parâmetro por chamada
• Avaliar o AI-driven scaling para cargas com picos, a partir de uma base de cerca de 32 RPU
• Configurar um usage limit em RPU-horas com alerta ou corte automático, independente do modo escolhido
• Revisar o teto de storage gerenciado antes de reduzir a base, para não travar o crescimento do dataset

São cerca de vinte minutos de trabalho, segundo o próprio relato, contra uma fatura que, sem essa revisão, continua compondo silenciosamente mês após mês.

Fonte: DEV Community — #aws