Amazon Aurora Serverless v2 guia detalhado de arquitetura, escala, custo e operação

O Amazon Aurora Serverless v2 é uma configuração do Aurora em que a capacidade de computação do banco acompanha a demanda em tempo real, em vez de ser fixada na criação da instância. Você define uma faixa (mínimo e máximo) e o Aurora ajusta a capacidade dentro dela, sem reiniciar o banco e sem derrubar conexões.

Ele não é um produto separado, e sim um tipo de instância dentro de um cluster Aurora comum (db.serverless). Por isso herda o armazenamento distribuído, o Multi-AZ, as réplicas de leitura e o restante do ecossistema do Aurora.

Os valores de preço, limites de ACU e disponibilidade por versão de motor mudam com o tempo. Os números deste artigo são referências para raciocínio. Confirme sempre na documentação e na página de preços da AWS.

2. Um pouco de contexto: v1 vs. v2

	Serverless v1	Serverless v2
Modelo	Cluster inteiro escala	Instâncias escalam individualmente
Escala	Em degraus, com pausa para encontrar "ponto seguro"	Contínua, em incrementos pequenos
Interrompe conexões ao escalar	Pode interromper	Não
Multi-AZ, réplicas, Global DB	Limitado	Suportado
Granularidade	Capacidade dobra	0,5 ACU
Status	Legado	Modelo atual

A v2 foi desenhada para eliminar as limitações da v1 e é o modelo recomendado para novas cargas.

3. Como funciona por dentro

3.1 O ACU (Aurora Capacity Unit)

Cada ACU equivale a aproximadamente 2 GiB de memória, com CPU e rede proporcionais. A capacidade vai de frações de ACU até centenas de ACUs, e o incremento é de 0,5 ACU.

Pense no ACU como uma "fatia" de instância: um banco a 16 ACU tem algo na ordem de 32 GiB de memória disponíveis.

3.2 Escala em linha (in-place)

Diferentemente da troca de classe de instância, a v2 ajusta CPU e memória dentro do próprio processo do banco. As consequências práticas:

• Sem failover para escalar.
• Conexões e transações em andamento são preservadas.
• A escala responde a CPU, memória e rede, não só ao número de conexões.

A velocidade da escala depende da capacidade atual: quanto maior a instância já está, mais rápido ela cresce. Um banco parado em 0,5 ACU sobe mais devagar que um que já opera em 16 ACU. Isso é relevante para quem usa mínimo muito baixo e espera picos bruscos.

3.3 Faixa mínima e máxima

Você configura:

• min_capacity: piso de capacidade (pode ser 0 ACU com auto-pause, em versões de motor compatíveis).
• max_capacity: teto de capacidade e teto de custo.

O ACU em uso nunca sai dessa faixa. Além de controlar custo, o piso e o teto influenciam parâmetros do banco, como o tamanho do buffer pool e o número máximo de conexões, que são derivados da configuração de capacidade.

3.4 Auto-pause (scale-to-zero)

Com min_capacity = 0, o banco pode pausar após um período de inatividade que você configura, e a computação deixa de ser cobrada. Ao chegar uma nova conexão, o banco retoma, o que leva algum tempo (na casa de segundos).

Pontos de atenção:

• O armazenamento continua sendo cobrado.
• A primeira requisição após a pausa sofre a latência de retomada.
• É ideal para dev, teste e ferramentas internas, e arriscado para produção com usuários esperando.
• Conexões em pool e health checks frequentes podem impedir a pausa, mantendo o banco acordado sem você perceber.

3.5 Armazenamento

O armazenamento é o mesmo do Aurora convencional: volume distribuído em 3 AZs, com 6 cópias, crescendo automaticamente. Você não provisiona disco. A cobrança de storage e I/O é independente do tipo de instância, e existem as opções de configuração Standard e I/O-Optimized.

3.6 Tiers de promoção em clusters com readers

Em clusters com mais de uma instância, os tiers de failover (0 a 15) influenciam como os readers escalam:

• Tiers 0 e 1: o reader acompanha a capacidade do writer, para estar pronto para assumir em caso de failover.
• Tiers 2 a 15: o reader escala de forma independente, de acordo com a própria carga.

Essa escolha afeta diretamente custo e prontidão para failover.

4. Recursos suportados

Em geral, a v2 funciona com o ecossistema do Aurora:

• Multi-AZ e failover automático
• Até 15 réplicas de leitura
• Aurora Global Database
• RDS Proxy
• Performance Insights e Enhanced Monitoring
• Backups, snapshots e Point-in-Time Recovery
• Criptografia com KMS e autenticação IAM
• Integração com Secrets Manager (manage_master_user_password)
• Blue/Green Deployments
• Data API (conforme versão e região)

Compatível com Aurora MySQL e Aurora PostgreSQL, em versões de motor específicas. Vale checar a matriz de versões antes de criar o cluster.

5. Modelo de custo

5.1 Como é cobrado

• Computação: ACU-hora consumido, medido por segundo, com mínimo de cobrança por período de capacidade.
• Armazenamento: por GB-mês.
• I/O: por requisição no modo Standard. No modo I/O-Optimized não há cobrança de I/O, mas o preço de computação e storage é maior.
• Backups além da retenção gratuita, transferência de dados, Performance Insights além do tier gratuito, etc.

5.2 Raciocínio de break-even

O ACU-hora é, por unidade de memória, mais caro que uma instância provisionada equivalente. Ilustrando com valores aproximados de us-east-1:

• 1 ACU ≈ US$ 0,12/h → rodando 24x7 ≈ US$ 87/mês por ACU.
• Uma instância db.r6g.large (16 GiB) custa em torno de US$ 0,26/h ≈ US$ 190/mês.
• 16 GiB equivalem a ~8 ACUs, que custariam ≈ US$ 0,96/h ≈ US$ 700/mês se ficassem sempre ligados.

A conclusão é que, sob carga constante e alta, o provisionado é bem mais barato. Já se o banco usa em média menos de ~25–30% da capacidade equivalente, o serverless costuma sair na frente, e com auto-pause em dev pode custar uma fração.

O raciocínio correto é: custo = média de ACUs consumidos ao longo do tempo × preço do ACU-hora. Por isso o monitoramento de ACU médio importa mais que o pico.

5.3 O que não esquecer

• Reserved Instances não se aplicam ao ACU da mesma forma. Savings Plans para banco de dados podem se aplicar, conforme as regras vigentes.
• O max_capacity é seu limite de gasto de computação, então defina-o conscientemente.
• Readers com tier 0/1 acompanham o writer, e isso multiplica o custo.

6. Quando usar (e quando evitar)

Bons casos de uso

• Cargas variáveis ou imprevisíveis: e-commerce com campanhas, apps com picos em horário comercial.
• Aplicações novas sem histórico de consumo.
• Dev, teste e homologação: principalmente com auto-pause.
• SaaS multi-tenant com muitos bancos de perfis diferentes.
• Workloads com picos curtos: relatórios noturnos, processamento em lote.
• Arquiteturas serverless (Lambda + RDS Proxy) em que o tráfego é irregular.

Quando reconsiderar

• Carga alta e constante 24x7: provisionado com Reserved Instance tende a custar menos.
• Latência ultra-previsível exigida: variações de cache durante escalas podem incomodar.
• Produção com auto-pause: a latência de retomada geralmente é inaceitável.
• Falta de limite de custo definido: um max_capacity alto sem alarmes pode gerar conta alta com uma query mal escrita.

7. Arquitetura de referência

Um padrão comum para uma aplicação web em produção:

Usuários
   │
CloudFront ── ALB ── ECS/EKS (aplicação)
                         │
                    RDS Proxy
                         │
        ┌────────────────┴───────────────┐
   Writer (Serverless v2)        Reader(s) (Serverless v2)
        └────────────────┬───────────────┘
              Volume Aurora (3 AZs, 6 cópias)

Pontos de design:

1. Writer em Serverless v2 com mínimo que mantenha o cache aquecido.
2. Readers em tier 2+ se você quer que escalem de forma independente e mais barata.
3. RDS Proxy na frente, para absorver conexões e reduzir o impacto de connection storms.
4. Secrets Manager para credenciais, com rotação.
5. Subnets privadas, com Security Groups restritos à camada de aplicação.
6. Alarmes de ACU, CPU, conexões e latência.

Variação: cluster misto

Como o storage é compartilhado, é possível ter um writer provisionado (carga estável, com desconto) e readers Serverless v2 para absorver picos de leitura. É um bom caminho para quem quer previsibilidade na escrita e elasticidade na leitura.

8. Implementação com Terraform

resource "aws_db_subnet_group" "this" {
  name       = "app-aurora-subnets"
  subnet_ids = var.private_subnet_ids
}

resource "aws_security_group" "db" {
  name   = "app-aurora-sg"
  vpc_id = var.vpc_id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [var.app_security_group_id]
  }
}

resource "aws_rds_cluster" "this" {
  cluster_identifier = "app-aurora-sv2"
  engine             = "aurora-postgresql"
  engine_mode        = "provisioned"   # Serverless v2 usa o modo provisioned
  engine_version     = "16.4"

  database_name               = "appdb"
  master_username             = "dbadmin"
  manage_master_user_password = true

  db_subnet_group_name   = aws_db_subnet_group.this.name
  vpc_security_group_ids = [aws_security_group.db.id]

  storage_encrypted       = true
  backup_retention_period = 7
  deletion_protection     = true
  copy_tags_to_snapshot   = true

  serverlessv2_scaling_configuration {
    min_capacity = 1
    max_capacity = 16
    # seconds_until_auto_pause = 600   # só com min_capacity = 0
  }
}

resource "aws_rds_cluster_instance" "writer" {
  identifier           = "app-aurora-sv2-writer"
  cluster_identifier   = aws_rds_cluster.this.id
  engine               = aws_rds_cluster.this.engine
  engine_version       = aws_rds_cluster.this.engine_version
  instance_class       = "db.serverless"
  promotion_tier       = 0
  performance_insights_enabled = true
}

resource "aws_rds_cluster_instance" "reader" {
  identifier           = "app-aurora-sv2-reader"
  cluster_identifier   = aws_rds_cluster.this.id
  engine               = aws_rds_cluster.this.engine
  engine_version       = aws_rds_cluster.this.engine_version
  instance_class       = "db.serverless"
  promotion_tier       = 2   # escala de forma independente do writer
  performance_insights_enabled = true
}

Observações:

• O engine_mode continua provisioned. O que torna a instância serverless é o instance_class = "db.serverless" junto com o bloco serverlessv2_scaling_configuration.
• A capacidade é configurada no cluster, e vale para todas as instâncias serverless dele.
• Verifique a versão do provider AWS para suporte a recursos mais novos, como o auto-pause.

9. Observabilidade

Métricas essenciais (CloudWatch)

Métrica	O que mostra
ServerlessDatabaseCapacity	ACUs em uso no momento
ACUUtilization	% do max_capacity em uso
CPUUtilization	CPU, no contexto da capacidade atual
FreeableMemory	Memória livre
DatabaseConnections	Conexões abertas
BufferCacheHitRatio	Eficiência do cache
AuroraReplicaLag	Atraso dos readers

Alarmes recomendados

• ACUUtilization alto por tempo prolongado, o que indica max_capacity apertado.
• ServerlessDatabaseCapacity encostando no máximo, o que sinaliza risco de saturação e de custo.
• BufferCacheHitRatio caindo após escalas para baixo.
• Conexões se aproximando do limite.

Um padrão útil: acompanhar a média de ACU por dia e cruzar com a fatura, para validar se o serverless está compensando em relação ao provisionado.

10. Boas práticas

1. Dimensione o mínimo pelo cache, não só pelo custo. Um piso muito baixo faz o working set sair da memória, e a latência piora quando a carga volta.
2. Dimensione o máximo pelo teto de custo aceitável e pelo pior pico real.
3. Use RDS Proxy com Lambda ou aplicações com muitas conexões curtas.
4. Não use auto-pause em produção com usuários finais, a menos que a latência de retomada seja aceitável.
5. Escolha o tier de promoção dos readers de acordo com a necessidade de failover rápido versus economia.
6. Defina alarmes de custo (AWS Budgets) e de ACU. Uma query descontrolada pode manter o banco no máximo por horas.
7. Otimize queries antes de aumentar o máximo. Escalar infraestrutura para esconder SQL ruim é caro.
8. Teste carga com perfil realista, incluindo picos súbitos, para validar a velocidade de escala partindo do mínimo escolhido.
9. Mantenha IaC e proteção contra deleção ligadas em produção.
10. Reavalie a cada trimestre: se a carga estabilizou, talvez o writer deva migrar para uma instância fixa.

11. Migração

• De Aurora provisionado para Serverless v2: como o storage é o mesmo, adicione uma instância db.serverless ao cluster, promova-a via failover e remova a instância antiga. É necessário que a versão do motor seja compatível.
• De Serverless v1 para v2: o caminho é por snapshot/restauração ou por upgrade de versão com recriação, conforme a documentação vigente. Planeje uma janela de manutenção e teste no ambiente de homologação.
• De RDS comum para Aurora Serverless v2: use réplica de leitura Aurora ou o AWS DMS, dependendo do motor e da tolerância a downtime.

12. Armadilhas comuns

• Achar que serverless é sempre mais barato. Em carga constante e alta, é o contrário.
• Mínimo em 0,5 ACU em produção e depois estranhar a lentidão no primeiro pico.
• Esquecer que readers de tier 0/1 acompanham o writer e dobram o custo.
• Deixar o max_capacity muito alto sem alarmes.
• Pools de conexão que impedem o auto-pause em ambientes de dev.
• Ignorar limites de conexão derivados da capacidade configurada.

13. Conclusão

O Aurora Serverless v2 resolve um problema clássico: pagar por capacidade que você só usa em parte do tempo. Ele entrega elasticidade fina, sem downtime ao escalar, e mantém todos os recursos do Aurora. Em troca, cobra mais caro por unidade de capacidade e exige disciplina com limites, monitoramento e dimensionamento de mínimo e máximo.

A decisão certa não é "serverless ou fixo" de forma absoluta, e sim medir a utilização real, calcular o custo nos dois modelos e, quando fizer sentido, combiná-los no mesmo cluster.