Aurora não é um RDS mais rápido, e a diferença aparece sob carga e failover

Aurora não é um RDS mais rápido, e a diferença aparece sob carga e failover

Aurora e RDS compartilham a mesma API, mas o armazenamento distribuído do Aurora muda failover, custo e comportamento sob carga. Entenda quando cada um compensa de verdade.

Nota da redação: as descrições específicas de uso de Aurora Global Database (DR cross-region), Aurora I/O-Optimized (custo por requisição de storage) e Aurora DSQL (SQL distribuído) vão além do que a fonte, um artigo de opinião publicado no AWS Builder Center, efetivamente detalha. Essas caracterizações não puderam ser confirmadas em documentação oficial da AWS e devem ser lidas como contexto geral de mercado, não como afirmação verificada de comportamento de produto.

A decisão

A AWS vende o Amazon Aurora como um substituto direto do Amazon RDS: mesmo protocolo, mesmo driver, compatibilidade com MySQL e PostgreSQL. No papel, a migração parece trivial. Na prática, segundo artigo publicado por Fabiano da Silva Santos no AWS Builder Center em 8 de novembro de 2026, compatibilidade de API não é equivalência de comportamento.

O Aurora usa uma camada de armazenamento distribuída, replicada em seis cópias espalhadas em três zonas de disponibilidade, desacoplada do compute. O RDS, por outro lado, mapeia para o modelo mental de rodar um banco em um servidor: storage provisionado, snapshot, maintenance window, instance class previsível. Essa diferença de arquitetura é o ponto central do artigo, e é ela que muda failover, acúmulo de custo de storage e comportamento sob carga sustentada.

A compatibilidade com MySQL e PostgreSQL é real, mas compatibilidade não é equivalência.

The MySQL and PostgreSQL compatibility is real, but compatibility is not equivalence.Fabiano da Silva Santos, autor no AWS Builder Center

Vale o contexto: é um artigo de opinião de um builder da comunidade, não documentação oficial da AWS, e a própria página traz o aviso de que as opiniões são do autor. Mas o padrão que ele descreve, times migrando esperando comportamento idêntico e descobrindo diferenças na marra, é reconhecível para quem opera os dois serviços em produção. Para quem administra RDS e Aurora no dia a dia, esse é o tipo de decisão que normalmente só vira problema depois do primeiro failover real.

Lado a lado

Os dois serviços expõem a mesma interface SQL, mas o que está por baixo diverge em pontos que afetam diretamente operação e fatura.

A separação entre compute e storage é o que explica por que o failover se comporta de forma diferente entre os dois serviços. Segundo o artigo, é essa camada de armazenamento distribuída, replicada em três zonas de disponibilidade e desacoplada do compute, que muda como o failover funciona no Aurora, em contraste com o modelo de instância única do RDS. A fonte não detalha os mecanismos internos de promoção em cada caso nem afirma qual dos dois é mais rápido, apenas que a arquitetura muda o comportamento.

Quando escolher cada um

RDS continua sendo a escolha certa quando a carga é previsível e a equipe já opera bancos tradicionais com conforto. Um serviço interno de back-office, com tráfego estável, rodando numa instância de tamanho fixo, dificilmente ganha algo migrando para Aurora: só adiciona uma camada de comportamento distribuído que o time precisa aprender a diagnosticar. Previsibilidade de fatura e maintenance window conhecida também pesam a favor do RDS.

Aurora compensa quando o padrão de carga não é estável. Um e-commerce com pico sazonal de escrita, que hoje sofre com throttling de IOPS provisionado no RDS, é candidato natural ao Aurora, porque o armazenamento escala sem reprovisionamento manual. Dentro da família Aurora, a escolha certa ainda depende da variante:

• Aurora padrão: cargas de leitura/escrita constantes que já se beneficiam do armazenamento distribuído, sem precisar de recursos extras.
• Aurora Serverless: workloads intermitentes ou esporádicas, onde pausar e retomar capacidade reduz custo, mas com a ressalva de que o cold start do retomar pode aparecer como latência em produção.
• Aurora Global Database: aplicações que precisam de replicação cross-region de baixa latência para disaster recovery.
• Aurora I/O-Optimized: cargas intensivas em I/O, onde o custo de requisições de storage domina a fatura.
• Aurora DSQL: cenários que pedem SQL distribuído além do que a arquitetura padrão do Aurora oferece.

O artigo do AWS Builder Center resume isso numa frase que vale repetir: a decisão real não é RDS contra Aurora, é entender que Aurora não é um produto único, e sim uma família com comportamentos diferentes entre si.

Custo

A diferença de billing de storage é onde times costumam ser surpreendidos. No RDS, o custo de storage é previsível porque é atrelado ao que foi provisionado: você escolhe o tamanho do volume, redimensiona quando precisa, e a fatura reflete essa escolha. No Aurora, o modelo é pagar pelo que de fato se usa, o que parece mais eficiente, mas depende do padrão de escrita da aplicação.

Segundo o artigo, esse modelo de storage sob demanda pode ser mais barato ou muito mais caro, dependendo de como a aplicação escreve dados. Workloads com muita escrita volátil, tabelas temporárias grandes, ou padrões de update intensivo podem gerar acúmulo de storage que não aparece no RDS da mesma forma, porque lá o volume é fixo até ser redimensionado manualmente. É um ponto que só fica visível depois de meses de operação, quando a fatura já acumulou o padrão real de uso.

O Aurora Serverless adiciona outra variável de custo que não é só financeira: o cold start. Pausar instância ociosa economiza, mas o retomar sob demanda pode introduzir latência justamente no momento em que uma requisição chega depois do período ocioso. Para workloads com SLA de latência apertado, esse comportamento precisa ser testado antes de ir para produção, não descoberto durante um incidente.

Veredito

Se o seu time já opera RDS com conforto, a carga é previsível e a prioridade é previsibilidade de fatura e de maintenance window, não há motivo forte para migrar: o Aurora adiciona uma camada de comportamento distribuído que só paga dividendo quando a carga realmente varia.

Se o workload tem picos de escrita, precisa de disaster recovery cross-region de baixa latência, ou sofre com throttling de IOPS no RDS, o Aurora compensa a complexidade adicional, mas a escolha certa está dentro da própria família: Aurora padrão para carga constante, I/O-Optimized para workloads intensivos em I/O, Global Database para DR, Serverless só depois de validar o impacto do cold start, e DSQL apenas quando o problema é de fato SQL distribuído. A pergunta que vale fazer antes de migrar não é "RDS ou Aurora", é qual variante do Aurora corresponde ao padrão de carga que a aplicação realmente tem.

Fonte: AWS Builder Center