O que é o Amazon Aurora PostgreSQL
O Amazon Aurora PostgreSQL é um banco de dados relacional gerenciado pela AWS, totalmente compatível com o PostgreSQL padrão. A diferença fundamental em relação ao RDS PostgreSQL convencional está na arquitetura: o Aurora foi projetado como um serviço nativo de nuvem, com armazenamento distribuído e replicação integrada desde o início.
Na prática, isso significa que ele não é simplesmente um PostgreSQL rodando em uma instância EC2 gerenciada. A AWS redesenhou a camada de armazenamento para tirar proveito da infraestrutura distribuída, o que resulta em até 3x mais throughput que uma instalação PostgreSQL padrão em hardware equivalente.
O Aurora aceita o mesmo driver, as mesmas extensões e os mesmos comandos SQL que você já usa com PostgreSQL. A migração de código é, na maioria dos casos, transparente. A diferença está em como os dados são armazenados, replicados e recuperados.
Arquitetura Interna do Aurora
Separação de computação e armazenamento
No RDS PostgreSQL tradicional, computação e armazenamento estão acoplados na mesma instância. O Aurora separa essas duas camadas: as instâncias de banco processam queries, enquanto o armazenamento vive em um cluster distribuído independente.
Essa separação traz consequências importantes:
- Escalar leitura não exige duplicar armazenamento. Réplicas de leitura compartilham o mesmo volume de dados.
- O armazenamento cresce automaticamente de 10 GiB até 128 TiB, sem necessidade de provisionar disco manualmente.
- Failover é mais rápido porque a nova instância não precisa reconstruir dados locais.
Armazenamento distribuído e tolerância a falhas
O Aurora mantém 6 cópias dos dados distribuídas em 3 Availability Zones. Esse modelo tolera:
- Perda de até 2 cópias sem impacto na capacidade de escrita
- Perda de até 3 cópias sem impacto na capacidade de leitura
Cada operação de escrita é confirmada quando 4 das 6 cópias respondem (quorum de escrita). Para leitura, bastam 3 cópias. Isso elimina a necessidade de configurações complexas de replicação síncrona que seriam necessárias para atingir nível similar de durabilidade no RDS.
Log-Based Storage
Uma diferença arquitetural significativa: o Aurora envia apenas os registros WAL (Write-Ahead Log) para a camada de armazenamento. As páginas de dados são materializadas diretamente no storage distribuído, eliminando checkpoints tradicionais.
No PostgreSQL padrão, checkpoints são operações pesadas que pausam a escrita para sincronizar páginas sujas do buffer pool com o disco. Sem essa necessidade, o Aurora consegue manter throughput mais estável, especialmente sob carga intensa de escrita.
O resultado direto: recuperações de crash são quase instantâneas e o lag de replicação entre a instância primária e as réplicas de leitura fica tipicamente abaixo de 100ms, já que as réplicas consomem diretamente do mesmo volume de armazenamento. Todas as transações mantêm propriedades ACID completas.
Comparação: Aurora PostgreSQL vs RDS PostgreSQL
| Aspecto | Aurora PostgreSQL | RDS PostgreSQL |
|---|---|---|
| Armazenamento | Distribuído, 6 cópias em 3 AZs, até 128 TiB | EBS por instância, até 64 TiB |
| Replicação | Mesmo volume, lag < 100ms | Baseada em WAL, lag de segundos a minutos |
| Failover | Multi-AZ nativo, ~30 segundos | Multi-AZ opcional, 1-2 minutos |
| Réplicas de leitura | Até 15 réplicas | Até 5 réplicas |
| Performance | Sem checkpoints locais, até 3x mais throughput | PostgreSQL padrão, dependente de tuning |
| Global Database | Suporte nativo, replicação cross-region | Não disponível |
| Backups | Contínuos e incrementais no S3 | Snapshots diários |
| Custo base | ~20% mais caro (instância + I/O) | Mais econômico para cargas previsíveis |
O ponto central da comparação não é que o Aurora é universalmente superior. É que ele resolve problemas específicos — alta disponibilidade, replicação de leitura massiva, failover rápido — que no RDS exigiriam configuração manual significativa e ainda assim não atingiriam o mesmo nível de confiabilidade.
Aurora Serverless v2
O Aurora Serverless v2 elimina a necessidade de escolher e gerenciar classes de instâncias. O banco escala automaticamente a capacidade de computação com base na demanda real.
Como funciona
A unidade de medida é o ACU (Aurora Capacity Unit). Cada ACU equivale a aproximadamente 2 GiB de RAM com CPU proporcional. O cluster escala continuamente entre os limites configurados:
- Mínimo: 0.5 ACU
- Máximo: 128 ACUs
A escala acontece de forma granular, em incrementos de 0.5 ACU, com ajustes em sub-segundos e sem interrupção de conexões ou queries em andamento.
Pricing
A cobrança é por ACU-hora consumida. Na região de São Paulo (sa-east-1), o custo fica em torno de $0.16 a $0.18 por ACU-hora.
Para referência:
| Cenário | ACUs estimados | Custo mensal aproximado |
|---|---|---|
| Aplicação leve, horário comercial | 2-4 ACUs (8h/dia) | ~$80-150 |
| API com picos noturnos | 4-16 ACUs (variável) | ~$300-700 |
| Workload constante e pesado | 16-32 ACUs (24/7) | ~$1.900-4.200 |
O Serverless v2 é particularmente vantajoso para cargas imprevisíveis. Se o banco fica ocioso à noite, ele reduz para o mínimo configurado. Se um pico de tráfego chega às 3h da manhã, ele escala em segundos sem intervenção manual.
Serverless v2 vs instâncias provisionadas
Para workloads com carga constante e previsível, instâncias provisionadas ainda são mais econômicas. O Serverless v2 compensa quando a variabilidade da carga é alta o suficiente para justificar pagar um prêmio por ACU em troca de não manter capacidade ociosa.
Escalabilidade
Escalabilidade vertical
Como no RDS, você pode alterar a classe da instância (db.r6g.large, db.r6g.xlarge, etc.) para aumentar CPU e memória. Essa operação causa um breve downtime, geralmente de poucos minutos.
Escalabilidade horizontal
O Aurora suporta até 15 réplicas de leitura no mesmo cluster. Todas compartilham o mesmo volume de armazenamento, então adicionar uma réplica não duplica os dados.
O Aurora Auto Scaling ajusta automaticamente o número de réplicas de leitura com base em métricas como uso de CPU ou número de conexões. Você define a capacidade mínima e máxima, e o Aurora cria ou remove réplicas conforme a demanda.
aws application-autoscaling register-scalable-target \
--service-namespace rds \
--resource-id cluster:meu-cluster-aurora \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8Aurora Global Database
Para aplicações com usuários em múltiplas regiões, o Aurora Global Database replica os dados entre regiões AWS com latência inferior a 1 segundo. A região primária processa escritas, enquanto regiões secundárias servem leituras locais com baixa latência.
Em caso de desastre regional, a promoção de uma região secundária a primária leva menos de 1 minuto — sem necessidade de restaurar backups.
Quando Migrar para Aurora
Escolha Aurora quando
- Alta disponibilidade é crítica: failover em ~30 segundos e replicação com lag mínimo são requisitos de negócio, não apenas desejados.
- Leitura pesada: a aplicação tem muito mais leituras que escritas e precisa de mais de 5 réplicas de leitura.
- Cargas variáveis: o tráfego oscila significativamente (Serverless v2) ou a base de dados cresce rapidamente (autoexpansão de armazenamento).
- Multi-região: usuários em diferentes regiões precisam de leituras com baixa latência (Global Database).
RDS PostgreSQL é suficiente quando
- Workload pequeno e previsível: uma aplicação com poucos usuários e carga constante não se beneficia da arquitetura distribuída do Aurora.
- Orçamento restrito: o RDS é 10-20% mais barato para a mesma classe de instância. Se o custo mensal faz diferença, o RDS pode ser suficiente.
- Failover não é crítico: se a aplicação tolera 1-2 minutos de indisponibilidade durante failover, o Multi-AZ do RDS atende.
- Compatibilidade estrita: em casos raros, extensões ou versões específicas do PostgreSQL podem estar disponíveis no RDS antes do Aurora.
Caminho de migração
A AWS oferece migração nativa com downtime mínimo:
- Crie um snapshot do RDS PostgreSQL
- Restaure o snapshot como um cluster Aurora PostgreSQL
- Use o AWS DMS (Database Migration Service) para replicação contínua durante a transição
- Redirecione a aplicação para o endpoint do Aurora
- Valide e desative o RDS original
Para bancos menores, o processo inteiro pode levar menos de 1 hora. Para bancos de centenas de GiB, planeje uma janela de manutenção adequada.
Conclusão
O Aurora PostgreSQL não é um substituto automático para o RDS. É uma opção arquitetural que faz sentido quando os requisitos de disponibilidade, replicação e escalabilidade justificam o custo adicional. Para a maioria das aplicações em estágio inicial ou com carga moderada, o RDS PostgreSQL continua sendo a escolha mais pragmática e econômica.
A recomendação prática: comece com RDS PostgreSQL. Monitore as métricas de replicação, failover e throughput. Quando esses indicadores mostrarem que o RDS está atingindo seus limites — ou quando a criticidade do negócio exigir garantias mais fortes — migre para o Aurora com dados concretos justificando a decisão.