Aurora e RDS passam a suportar instâncias R9g com Graviton5

Em números

• Até 30% de ganho de performance sobre instâncias Graviton4 equivalentes, variando por engine, versão e workload
• Até 22% de melhora no custo-benefício (price-performance) no modelo on-demand, na mesma comparação
• 192 vCPUs no maior tamanho da família, o db.r9g.48xlarge, com proporção de 8:1 entre memória e vCPU
• 100 Gbps de rede e 72 Gbps de banda para o Amazon EBS no topo da linha

O que mudou

A AWS anunciou em 12 de novembro de 2026 a disponibilidade geral das instâncias R9g, baseadas no processador Graviton5, para Amazon Aurora com compatibilidade PostgreSQL e MySQL, e para Amazon RDS for PostgreSQL, MySQL e MariaDB. São nove tamanhos, de large a 48xlarge, construídos sobre o AWS Nitro System.

Segundo a AWS, o ganho é de até 30% de performance e até 22% de price-performance sobre instâncias R8g (Graviton4) de tamanho equivalente, a depender do engine, da versão e da carga de trabalho. Não há detalhamento de benchmark na fonte: nenhum número de latência, TPS ou throughput específico foi publicado, só o percentual agregado.

Onde está disponível

As instâncias R9g estão disponíveis, por ora, em quatro regiões: US East (N. Virginia e Ohio), US West (Oregon) e Europe (Frankfurt). A região América do Sul (São Paulo), sa-east-1, não está na lista, e o anúncio da AWS não dá previsão de expansão.

Para quem opera produção no Brasil, isso significa que não dá para trocar instâncias hoje sem sair da região. Quem quiser testar o Graviton5 antes da chegada ao sa-east-1 precisa provisionar um cluster de avaliação numa das quatro regiões disponíveis, o que traz latência extra se o teste envolver tráfego real do Brasil.

Quanto custa

A fonte não publica tabela de preço por hora ou por vCPU para o R9g: ela remete às páginas de Amazon Aurora pricing e Amazon RDS pricing para os valores por região e engine. O único dado de custo divulgado é relativo, o ganho de até 22% em price-performance sobre o Graviton4 no modelo on-demand, sem conversão em dólar ou real.

Isso é relevante para quem faz sizing: o ganho percentual de price-performance normalmente só se confirma depois de rodar o workload real na nova instância, porque varia por engine (Aurora PostgreSQL, Aurora MySQL, RDS MySQL, RDS MariaDB), versão e padrão de acesso.

Como começar

A AWS lista dois caminhos para provisionar as instâncias R9g:

• Pelo Amazon RDS Management Console, ao escolher a classe de instância na criação ou na modificação de um banco já existente
• Pela AWS Command Line Interface (CLI), usando os comandos de criação ou modificação de instância do RDS/Aurora com a classe db.r9g.*

Antes de trocar, vale checar a documentação de versões suportadas do Aurora e do RDS: nem toda versão de engine aceita a nova classe de instância, e a fonte remete a essa checagem sem listar as versões específicas.

O que muda para quem já usa

Quem já roda Aurora ou RDS em R8g (Graviton4) ganha um motivo concreto para reabrir a planilha de sizing, mas só nas quatro regiões onde o R9g já existe. O caminho recomendado para validar o ganho antes de migrar produção é:

1. Subir uma réplica de leitura ou um ambiente de blue/green deployment na classe R9g
2. Rodar o workload real (ou um replay dele) por tempo suficiente para capturar picos
3. Comparar métricas do Amazon RDS Performance Insights entre a instância atual e a nova
4. Só então promover a réplica ou cortar o tráfego de produção

Para arquitetos e times de SRE com operação concentrada no Brasil, a lição prática é dupla: o ganho de performance e custo é real e documentado pela AWS, mas a ausência do sa-east-1 na lista de regiões adia a adoção direta em produção local. Quem tem workload multi-região já pode começar a medir o Graviton5 fora do Brasil; quem só opera em São Paulo fica, por enquanto, de olho na próxima atualização do What's New.

Fonte: AWS What's New