Amazon RDS for SQL Server passa a suportar instâncias M8id e R8id, com até 384 vCPUs

A AWS anunciou em 12 de novembro de 2026 que o Amazon RDS for SQL Server passa a suportar as instâncias M8id e R8id. São famílias construídas sobre processadores Intel Xeon 6 customizados, disponíveis só na AWS, com armazenamento local em NVMe SSD embutido na própria instância, além do EBS que o RDS já usa para dados e logs.

Os números dão a dimensão do salto: até 384 vCPUs, 3 TiB de memória e 22,8 TB de armazenamento NVMe local por instância. Segundo a AWS, isso é 4 vezes mais vCPU e memória, e mais de 6 vezes mais armazenamento local, do que as famílias M5d e R5d que essas instâncias substituem no topo de linha para quem roda SQL Server no RDS.

O que muda de verdade: tempdb sai do EBS

O ganho de specs é a parte óbvia do anúncio. A mudança que interessa a quem desenha a arquitetura do banco está em outro lugar: ao criar ou modificar uma instância de banco de dados para usar M8id ou R8id, o RDS for SQL Server passa a colocar automaticamente os arquivos de dados e log do tempdb no armazenamento de instância NVMe local, em vez de deixá-los no EBS.

Na prática, isso reduz a latência de leitura e escrita do tempdb em relação ao EBS, porque o NVMe fica fisicamente acoplado ao host da instância. Os arquivos de dados e log do banco de dados em si continuam no Amazon EBS, exatamente como antes. A separação é deliberada: o tempdb é recriado a cada reinicialização da engine, então ele é o único componente seguro o suficiente para viver num storage efêmero.

Esse detalhe importa para quem avalia o trade-off sob a ótica do Well-Architected Framework. Armazenamento de instância local NÃO sobrevive a um stop/start ou a uma substituição de hardware subjacente, então ele nunca deveria guardar dados persistentes de produção. Como o tempdb já é descartável por natureza, colocar ele no NVMe local resolve o gargalo de I/O sem introduzir um risco novo de durabilidade para os dados reais do banco.

Há ainda um efeito colateral no processo de backup: como os snapshots do RDS não incluem os arquivos do tempdb que estão no instance store, os snapshots ficam menores e consomem menos do armazenamento de backup gratuito. Para bancos SQL Server com tempdb pesado (sorts grandes, hash joins, tabelas temporárias intensas em ETL), isso também encurta a janela de snapshot.

Quem sente esse ganho na prática

M8id e R8id seguem a convenção de nomenclatura já conhecida da AWS: a família M é de propósito geral, com proporção equilibrada entre vCPU e memória; a família R é otimizada para memória, com mais RAM por vCPU. O sufixo "id" indica instância com NVMe SSD local de alta performance.

Os workloads que mais se beneficiam da migração para essas famílias são os que já sofrem com gargalo de I/O no tempdb:

• Consultas analíticas com sorts e hash joins grandes, que estouram a memória e derramam para o tempdb
• Cargas de ETL/batch com uso intenso de tabelas temporárias
• Sistemas com muitas transações concorrentes que disputam contenção no tempdb (um clássico problema de latch em SQL Server sob carga)
• Bancos que já rodam em M5d/R5d e estão no limite de vCPU ou memória disponível

Para quem administra um ambiente desses, o caminho não muda o padrão operacional do RDS: dá para modificar uma instância existente ou criar uma nova a partir do console, da AWS CLI ou do SDK. Trocar a classe de instância de um banco em produção, como de costume no RDS, implica reboot — então o planejamento de janela de manutenção continua sendo parte do trabalho, mesmo com o ganho de performance do destino.

Onde já dá para usar, e onde ainda não dá

As instâncias M8id e R8id estão disponíveis nas regiões US East (N. Virginia e Ohio), US West (Oregon), Canada (Central), Europe (Ireland, London, Frankfurt, Stockholm e Spain), e Ásia-Pacífico (Tokyo, Mumbai, Sydney e Malaysia).

São Paulo (sa-east-1) não está na lista. Para quem opera RDS for SQL Server no Brasil, isso significa que a migração para M8id/R8id por enquanto só é viável fora da região local, o que introduz latência extra entre a aplicação e o banco caso a ideia seja só aproveitar o hardware novo mantendo o resto da stack aqui. Times que dependem de baixa latência regional e de dados em sa-east-1 por questão de residência de dados seguem, por ora, limitados às famílias M5d e R5d (ou outras já suportadas na região) até a AWS expandir a disponibilidade.

Vale registrar esse recorte porque ele muda a decisão de arquitetura: antes de desenhar uma migração para M8id/R8id achando que é só trocar a classe da instância, o primeiro passo é confirmar se a região onde o banco roda hoje já suporta a nova família. Quem está em us-east-1 ou eu-west-1, por exemplo, já pode testar; quem está em sa-east-1, ainda não.

Custo e próximos passos

A AWS não divulgou no anúncio valores específicos de preço para M8id e R8id no RDS for SQL Server, remetendo à página oficial de preços do Amazon RDS for SQL Server para os números atualizados por região. Como é padrão em troca de classe de instância, o cálculo de custo-benefício passa por comparar o ganho de throughput do tempdb e a folga de vCPU/memória contra o preço por hora da instância maior, considerando o padrão real de uso (reserved instance, savings plan ou on-demand).

Para quem já opera M5d ou R5d perto do limite de capacidade, M8id e R8id dão margem de crescimento sem precisar escalar horizontalmente nem recorrer a sharding. Para quem está nas regiões ainda não cobertas, a recomendação prática é monitorar a disponibilidade regional antes de desenhar qualquer plano de migração em cima dessas famílias.

Fonte: AWS What's New