EC2, RDS ou Aurora: como decidir onde rodar seu banco na AWS em 2026

A escolha não é sobre qual banco é

Toda vez que um projeto novo precisa de um banco relacional na AWS, a mesma pergunta volta: sobe um EC2 e instala o PostgreSQL na mão, usa o Amazon RDS, ou vai direto de Aurora? A resposta não está em qual tecnologia é "melhor", mas em quanto de responsabilidade operacional o time quer carregar e em que padrão de acesso o banco vai sustentar. A documentação oficial do Aurora (que também é a porta de entrada para entender o RDS, já que o Aurora é um motor dentro do próprio serviço) dá pistas concretas pra essa decisão, mesmo sem citar preço.

Quem decide isso no dia a dia é o DBA que sustenta a operação, o arquiteto de soluções que desenha o ambiente e o engenheiro de SRE que vai ser acordado se o banco cair às 3h da manhã. Para esse público, a escolha é menos sobre feature e mais sobre quem assume o quê quando algo quebra.

Três camadas, três fatias de responsabilidade

As três opções não competem no mesmo nível de abstração; elas empilham responsabilidade de forma diferente.

• EC2 com banco instalado na mão: você controla o sistema operacional, a versão exata do postgres ou do mysqld, extensões customizadas, parâmetros de kernel e a topologia de replicação. Em troca, você também é quem aplica patch de segurança, faz failover, dimensiona disco e escreve o runbook de desastre.
• Amazon RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server): a AWS assume provisionamento, patch, backup, recuperação, detecção de falha e reparo da instância, via console, AWS CLI ou API. Você ainda escolhe a classe de instância (db.r6g.large, por exemplo) e o volume de armazenamento, mas não lida com o sistema operacional por baixo.
• Amazon Aurora: também fica dentro do guarda-chuva do RDS, compatível com MySQL e PostgreSQL, mas troca o motor de armazenamento padrão por um subsistema distribuído próprio, com clustering e replicação automatizados em nível de cluster inteiro, não de instância isolada.

Em todas as três camadas, uma responsabilidade nunca sai da sua mesa: o query tuning. A documentação do Aurora é direta nisso: a AWS cuida da infraestrutura e do software do DB instance, mas o ajuste de consulta (SQL mal escrito, índice ausente, plano de execução ruim) depende do desenho do banco, do volume de dados e do padrão de carga de cada aplicação, algo que só quem conhece o workload consegue tunar. Ferramentas como o RDS Performance Insights ajudam a achar a query problemática, mas não a corrigem sozinhas.

Onde o Aurora ganha de verdade: armazenamento e throughput

A diferença técnica central entre Aurora e um RDS "comum" está no armazenamento. Segundo a documentação, o Aurora entrega até seis vezes o throughput do PostgreSQL de prateleira e até seis vezes o do MySQL de prateleira em hardware comparável, porque o motor foi customizado para explorar esse subsistema de storage distribuído.

O volume de um cluster Aurora cresce sozinho conforme os dados aumentam, sem o DBA precisar provisionar disco antecipadamente, e pode chegar a 256 tebibytes (TiB) por cluster. Isso muda o cálculo de capacity planning: em vez de estimar pico de armazenamento com meses de antecedência e pagar por espaço ocioso, o time paga pelo que o banco efetivamente usa, mês a mês, enquanto o subsistema se expande sob demanda.

Esse ganho de throughput e de elasticidade de storage é o argumento mais forte para migrar uma carga de RDS MySQL ou RDS PostgreSQL para Aurora: o mesmo código de aplicação, o mesmo driver, a mesma query, rodando sobre um motor mais rápido no mesmo tipo de hardware.

Clustering e replicação deixam de ser trabalho manual

Fora do Aurora, montar um cluster de banco com replicação, failover automático e distribuição de leitura entre réplicas é, historicamente, uma das partes mais trabalhosas de operar um RDBMS em produção, seja em EC2, seja em RDS tradicional, onde isso ainda exige configurar réplicas de leitura manualmente.

A documentação descreve que operações de gerenciamento no Aurora normalmente envolvem o cluster inteiro, sincronizado por replicação, em vez de instâncias de banco isoladas. Na prática, isso tira do DBA a tarefa de orquestrar manualmente a promoção de uma réplica em caso de falha do primário, porque a camada de storage compartilhada entre as instâncias do cluster já resolve boa parte da coordenação que, em um banco autogerenciado, cairia sobre o runbook de incidentes.

Migrar sem parar a operação

Para quem já está em RDS MySQL ou RDS PostgreSQL, a documentação aponta dois caminhos de migração para Aurora sem reescrever a aplicação:

1. Criar um snapshot do banco atual e restaurá-lo como um cluster Aurora.
2. Configurar replicação unidirecional (one-way replication) da instância RDS de origem para o novo cluster Aurora, trocando a conexão da aplicação só depois que a réplica estiver sincronizada.

Existem também ferramentas de migração "push-button" citadas na documentação, pensadas para converter aplicações que já rodam em RDS for MySQL ou RDS for PostgreSQL para Aurora. Para quem vem de um banco autogerenciado em EC2, o caminho normalmente passa primeiro por uma migração para RDS (ou direto para Aurora) usando ferramentas como o AWS Database Migration Service, fora do escopo desta documentação específica, mas é o passo que costuma preceder essa decisão.

Quando essa troca não vale a pena

Nem todo workload se beneficia de subir a régua de EC2 para Aurora. Vale ficar em EC2 autogerenciado quando a aplicação depende de uma extensão de banco, de uma versão específica do motor ou de um ajuste de sistema operacional que o RDS e o Aurora não expõem por serem gerenciados. Vale ficar em RDS tradicional, sem subir para Aurora, quando o engine necessário é Oracle, SQL Server ou MariaDB (o Aurora só fala MySQL e PostgreSQL) ou quando o volume de dados e o throughput exigido são pequenos o suficiente para que o ganho de performance do Aurora não justifique a arquitetura extra.

Em resumo: a pergunta certa não é "qual banco é mais moderno", é "qual camada de responsabilidade eu quero operar e qual padrão de acesso meu workload realmente tem". Quem decide isso com o padrão de acesso em mãos, e não pela moda do momento, erra muito menos.

Fonte

Documentação oficial do Amazon Aurora: What is Amazon Aurora?, Amazon RDS User Guide for Aurora.

Fonte: Documentação do Amazon Aurora