Amazon Aurora vs RDS: Quando Migrar para o Banco de Dados Nativo da Nuvem

A AWS afirma que o Amazon Aurora entrega até seis vezes o throughput de uma instalação padrão de MySQL ou PostgreSQL — um número que a própria AWS repete na página oficial do produto. É um dado e tanto para um serviço que, por baixo do capô, ainda fala o mesmo protocolo MySQL ou PostgreSQL que qualquer instância RDS. A pergunta que todo time de infraestrutura acaba enfrentando não é "o Aurora é melhor", porque em boa parte dos casos é: é se a diferença justifica trocar de plataforma, reescrever nada na aplicação (a promessa é justamente essa) e assumir um modelo de cobrança diferente. Este guia explica como o Amazon Aurora funciona por dentro, onde ele realmente supera o RDS tradicional, quanto custa na prática e em que situações a migração compensa — ou não.

O Que É o Amazon Aurora e Como Ele Se Diferencia do RDS Tradicional

O Amazon Aurora é um motor de banco de dados relacional da AWS, compatível com MySQL e com PostgreSQL, construído sobre uma arquitetura de storage distribuído que separa completamente a camada de computação da camada de armazenamento. É essa separação — não uma versão "turbinada" do MySQL — que explica a maior parte da diferença de performance e disponibilidade em relação ao RDS.

No RDS tradicional para MySQL, PostgreSQL, MariaDB, Oracle ou SQL Server, cada instância tem seu próprio volume de armazenamento em Amazon EBS. Alta disponibilidade significa manter uma segunda instância completa em standby (Multi-AZ), com os dados replicados de uma cópia para a outra. No Aurora, todas as instâncias de um cluster — a instância de escrita e as réplicas de leitura — compartilham o mesmo volume de dados, que a própria documentação da AWS descreve como replicado automaticamente em seis cópias distribuídas em três Zonas de Disponibilidade. Isso muda a lógica de disponibilidade: uma réplica de leitura não precisa copiar os dados do zero para virar a nova instância de escrita, porque ela já enxerga o mesmo volume.

Vale reforçar: o Aurora fala o protocolo do MySQL e do PostgreSQL com o que a AWS chama de compatibilidade "drop-in" — drivers, ORMs, ferramentas de BI e código de aplicação continuam funcionando sem alteração. A migração muda a infraestrutura por baixo, não o contrato que a aplicação tem com o banco.

Os Benefícios Reais do Aurora Sobre o RDS Tradicional

Três frentes concentram a diferença prática entre os dois modelos:

Storage que cresce sozinho, sem downtime. No RDS para MySQL ou PostgreSQL, o limite de armazenamento provisionado é de até 64 TiB, e é preciso alocar e pagar por esse espaço com antecedência, mesmo que ele fique parcialmente vazio. No Aurora, o volume do cluster escala automaticamente até 256 TiB, em incrementos que acontecem em segundo plano, e a cobrança é pelo espaço realmente usado — dropar uma tabela grande reduz a fatura no mês seguinte.

Mais réplicas de leitura, com lag muito menor. Um cluster Aurora suporta até 15 réplicas de leitura, contra um número tipicamente menor no RDS tradicional (que também depende de replicação assíncrona convencional, com lag que pode chegar a segundos sob carga pesada). Como as réplicas Aurora compartilham o mesmo volume da instância de escrita, a documentação da AWS registra um lag de replicação usualmente abaixo de 100 milissegundos — e qualquer uma dessas réplicas pode ser promovida a instância de escrita em caso de failover, sem precisar reconstruir dados.

Failover mais rápido e sem perda de dados. Como a promoção de uma réplica para o papel de escrita não depende de copiar um volume inteiro, a troca é significativamente mais rápida que a promoção de um standby Multi-AZ tradicional — e como o volume é compartilhado, não há risco de perda de transações não replicadas no momento da falha.

Aurora vs RDS: Comparação Direta

Repare que a tabela não aponta um vencedor absoluto. Uma carga estável, com motor não suportado pelo Aurora (Oracle e SQL Server, por exemplo) ou com orçamento apertado, continua bem atendida pelo RDS tradicional — trocar de plataforma sem necessidade real é custo de migração sem retorno.

Aurora Serverless v2: Quando a Capacidade Elástica Compensa

O Aurora Serverless v2 resolve um problema específico: cargas de trabalho com picos difíceis de prever, onde dimensionar uma instância provisionada fixa significa pagar por capacidade ociosa na maior parte do tempo ou correr risco de gargalo no pico. A unidade de medida é a ACU (Aurora Capacity Unit), equivalente a aproximadamente 2 GiB de memória com a CPU e a rede correspondentes.

A documentação oficial detalha como a escala funciona na prática: cada escritor ou leitor escala dentro de uma faixa mínima e máxima definida por você, em incrementos de até 0,5 ACU, sem esperar um "ponto quieto" — a escala acontece com conexões abertas, transações em andamento e tabelas travadas, sem derrubar nada. Dependendo da versão do engine, a faixa vai de 0,5 a 128 ACUs, de 0,5 a 256 ACUs, ou — nas versões mais recentes de Aurora MySQL e PostgreSQL — de 0 a 256 ACUs, com a opção de pausa automática quando não há carga nenhuma.

Um ponto que costuma passar despercebido no dimensionamento: você pode montar um cluster misto, com um escritor provisionado (tamanho fixo, para a carga de escrita previsível) e réplicas Serverless v2 (para absorver picos de leitura, como relatórios trimestrais que rodam ao lado do tráfego normal). Não é tudo ou nada.

Onde o Serverless v2 faz sentido: ambientes de desenvolvimento e teste que ficam ociosos boa parte do dia, aplicações novas cuja demanda ainda é uma incógnita, e cargas sazonais como e-commerce em datas promocionais. Onde não faz sentido: cargas de escrita constante e previsível, em que uma instância provisionada de tamanho fixo sai mais barata por hora.

Como Migrar do RDS para o Aurora Sem Reescrever a Aplicação

A AWS documenta três caminhos principais, e a escolha depende do tamanho do banco e da tolerância a downtime:

Migração por réplica (menor downtime). Você cria uma réplica Aurora de leitura a partir da instância RDS de origem. A AWS mantém a replicação até o lag chegar a zero; nesse momento, você promove a réplica Aurora a um cluster independente e redireciona a aplicação. É o caminho recomendado para produção, porque o corte acontece só depois que os dados já estão 100% sincronizados.

Migração por snapshot. Mais simples operacionalmente: você tira (ou já tem) um snapshot do RDS de origem e restaura direto num cluster Aurora. É mais rápido de configurar, mas qualquer escrita feita entre o snapshot e o corte final fica de fora — funciona melhor para bancos com janela de manutenção disponível.

AWS DMS (Database Migration Service). Necessário quando a origem não é MySQL nem PostgreSQL — outro motor, um banco on-premises, ou uma migração heterogênea que exige transformação de esquema. Para migrações de RDS MySQL/PostgreSQL para Aurora do mesmo motor, os dois caminhos acima costumam ser mais diretos que o DMS.

Um detalhe técnico que vale registrar: nem toda versão de origem migra direto. A documentação de migração para Aurora MySQL cita explicitamente que não é possível migrar para Aurora MySQL 3.05 ou superior a partir de algumas versões antigas do MySQL 8.0 (incluindo 8.0.11, 8.0.13 e 8.0.15) — a recomendação da própria AWS é atualizar para o MySQL 8.0.28 antes de migrar. É o tipo de trava que só aparece na hora da migração se ninguém checou a versão de origem antes.

Quanto Custa o Aurora na Prática

O modelo de cobrança do Aurora tem uma diferença estrutural em relação ao RDS: como o storage escala sozinho, você paga pelo espaço usado, não pelo espaço provisionado. Isso muda a lógica de dimensionamento — não existe mais a decisão de "quanto storage reservar com folga para os próximos dois anos".

A AWS oferece dois modelos de cobrança de storage e I/O:

• Aurora Standard: cobra o storage por GB-mês e cobra também por I/O, em incrementos de 1 milhão de requisições.
• Aurora I/O-Optimized: cobra um valor de storage por GB-mês mais alto, mas não cobra nada por I/O. Segundo a AWS, essa opção compensa quando o gasto com I/O já representa 25% ou mais do gasto total com o banco — nesse cenário, a economia pode chegar a 40%.

Para instâncias provisionadas, a cobrança é por instância-hora, no mesmo modelo do RDS. Para o Serverless v2, a cobrança é por ACU-hora — a AWS publica como referência (região US East, não válida para o cálculo no Brasil) valores de US$ 0,12 por ACU-hora no modelo Standard e US$ 0,156 por ACU-hora no I/O-Optimized. A tabela de preços correta para o cálculo real está sempre na página de preços do Aurora, já que a região de São Paulo tem valores próprios.

Vale registrar que essa comparação de custo não pode ignorar o outro lado da conta: no RDS, storage provisionado é pago mesmo ocioso, e picos de I/O em instâncias com Provisioned IOPS têm custo fixo, provisionado com folga, independente do uso real. É o tipo de gasto por inércia que a prática de FinOps na AWS existe para capturar antes que ele vire hábito na fatura.

Quando Migrar — e Quando Não Migrar — por Porte de Empresa

Não existe uma resposta única, e a decisão muda conforme o tamanho da operação:

Empresas menores (30–100 funcionários), carga previsível. Se o banco atual no RDS atende bem, sem gargalo de leitura nem janela de indisponibilidade que doa no negócio, a migração provavelmente não se paga no curto prazo. O ganho de performance do Aurora custa dinheiro e um projeto de migração — vale mais investir esse esforço em outro lugar. Exceção: cargas com picos muito variáveis (sazonalidade forte), onde o Aurora Serverless v2 pode custar menos que uma instância RDS dimensionada para o pico.

Empresas médias (100–400 funcionários), aplicações com SLA mais apertado. Aqui o cálculo já pesa mais a favor do Aurora: mais réplicas de leitura para separar relatórios de transações, failover mais rápido para reduzir indisponibilidade percebida, e storage que escala sem exigir replanejamento de capacidade a cada trimestre. Se a equipe de TI já é enxuta (ou terceirizada), o modelo gerenciado do Aurora reduz ainda mais a carga operacional de dimensionar e monitorar storage manualmente — o mesmo racional por trás de contratar administração de banco de dados terceirizada.

Empresas maiores (400–700 funcionários) ou com operação multirregional. É o cenário onde o Aurora Global Database entra em jogo: um cluster primário em uma região, com até 10 clusters secundários somente leitura em outras regiões, replicando com latência tipicamente abaixo de um segundo. Isso viabiliza leitura de baixa latência para usuários distantes geograficamente e recuperação de desastre regional com RPO e RTO menores que uma estratégia de replicação tradicional. Empresas que já discutem disaster recovery multi-região encontram no Aurora Global Database uma peça pronta, em vez de montar essa replicação na mão.

Para Onde o Aurora Está Indo

Duas tendências valem acompanhar. A primeira é o avanço do modelo serverless como padrão, não como exceção — cada nova versão de plataforma do Aurora Serverless v2 chega com ganho de performance sobre a anterior, e a faixa de escala de 0 a 256 ACUs (com pausa automática) já elimina o argumento de que serverless só serve para ambiente de teste. A segunda é a integração cada vez mais próxima entre Aurora e as ferramentas de dados e IA da AWS — zero-ETL para análise em tempo real, e ampliação da compatibilidade de extensões no Aurora PostgreSQL. Para o CTO que está decidindo hoje, a mensagem prática é: o Aurora não é uma aposta de nicho, é para onde a AWS está direcionando o investimento em banco de dados relacional gerenciado.

Perguntas Frequentes sobre Amazon Aurora

O Amazon Aurora é mais caro que o RDS?

Depende do padrão de uso. A instância em si costuma custar mais por hora que o RDS equivalente, mas o modelo de storage (paga pelo usado, não pelo provisionado) e a ausência de necessidade de superdimensionar para picos podem compensar essa diferença — especialmente com o Aurora I/O-Optimized em cargas com I/O intenso. A resposta correta exige simular os dois cenários com o volume de dados e o padrão de tráfego reais.

Migrar para o Aurora exige reescrever a aplicação?

Não, na grande maioria dos casos. O Aurora é compatível "drop-in" com MySQL e PostgreSQL: drivers, ORMs e ferramentas continuam funcionando sem alteração de código. A exceção é código que depende de comportamento muito específico do motor de origem ou de extensões não suportadas pelo Aurora.

Qual é a diferença entre Aurora Standard e Aurora I/O-Optimized?

O Aurora Standard cobra o storage por GB-mês e cobra também por I/O (por milhão de requisições). O Aurora I/O-Optimized cobra um valor de storage mais alto, mas zera a cobrança de I/O. Segundo a AWS, compensa migrar para o I/O-Optimized quando o gasto com I/O já representa 25% ou mais do gasto total do banco.

O Aurora Serverless v2 serve para produção?

Sim. Diferente da primeira versão do Aurora Serverless, a v2 suporta réplicas de leitura, alta disponibilidade Multi-AZ e escala com conexões abertas e transações em andamento, sem interromper operações. É usado em produção sempre que a carga tem picos variáveis — não é mais restrito a ambientes de desenvolvimento e teste.

Quantas réplicas de leitura o Aurora suporta?

Até 15 réplicas por cluster, distribuídas entre as Zonas de Disponibilidade da região. Com o Aurora Global Database, os clusters secundários somente leitura em outras regiões podem somar até 16 instâncias de leitura cada, por não competirem com o limite do cluster primário.

O ciclo de vida de versões do Aurora é diferente do RDS?

Não. O Aurora compatível com MySQL e com PostgreSQL também tem versões que saem de suporte padrão e entram em Extended Support, com a mesma lógica de cobrança automática do RDS. Migrar para o Aurora resolve o problema de performance e disponibilidade, mas não elimina a necessidade de acompanhar o calendário de fim de suporte de cada versão.

Dá para migrar de volta do Aurora para o RDS, se não funcionar?

Sim, tecnicamente — usando os mesmos mecanismos de dump lógico (mysqldump, pg_dump) ou snapshot, na direção contrária. Mas vale entender isso como plano B, não como plano principal: a decisão de migrar já deveria ter sido tomada com um teste de carga representativo antes do corte em produção, não depois.

O Aurora Compensa Quando a Arquitetura do RDS Já Virou o Gargalo

O Amazon Aurora não é uma versão premium do RDS que toda empresa deveria adotar por padrão — é uma arquitetura diferente, que resolve problemas específicos de performance, disponibilidade e escala de leitura melhor do que um banco com storage e computação acoplados consegue resolver. Quem tem um RDS estável, com carga previsível e sem gargalo real, não ganha nada trocando de plataforma só porque o nome é mais novo. Quem já sente o RDS travando em pico de leitura, esperando minutos por um failover, ou provisionando storage com folga demais "por segurança", está exatamente no perfil que o Aurora foi desenhado para atender.

O caminho mais seguro é medir antes de migrar: identificar o gargalo real — leitura, disponibilidade ou previsibilidade de custo — e simular o Aurora contra esse gargalo específico, não contra a promessa genérica de "seis vezes mais rápido". Para times sem capacidade interna de rodar esse diagnóstico, uma consultoria AWS especializada consegue estruturar esse teste antes de qualquer compromisso de migração em produção.

Artigos Relacionados

• RDS Extended Support: o Guia Completo do Ciclo de Vida de Versões do Amazon RDS — migrar para o Aurora não elimina o problema de ciclo de vida de versões; ele continua existindo, com a mesma mecânica de cobrança automática.
• EC2, S3 e RDS para PMEs: o Guia Completo de Nuvem AWS — para quem ainda está decidindo entre RDS e alternativas mais simples, este é o ponto de partida antes de considerar o Aurora.
• Administração de Banco de Dados Terceirizada: o Guia Definitivo — uma migração de motor de banco é exatamente o tipo de projeto em que ter um time especializado de DBA reduz o risco de downtime e retrabalho.
• Disaster Recovery na AWS: Estratégias Multi-Região — o Aurora Global Database é uma peça pronta de recuperação de desastre; este guia mostra como ela se encaixa numa estratégia multirregional mais ampla.