Aurora Serverless: banco relacional sem servidor, o que testei

Banco relacional costuma ficar ligado e cobrando o tempo todo. Aqui estão a conta que o Aurora Serverless me apresentou num teste real e as limitações que decidem se ele serve para o seu ambiente. O teste é de 2021, com a primeira geração do serviço.

O que é um banco relacional sem servidor

O Aurora é o banco relacional que a AWS desenhou para a nuvem, com motores compatíveis com MySQL e PostgreSQL. A versão serverless entrega esse banco sem você alocar infraestrutura para ele.

Isso mexe com um ponto doloroso. Banco relacional costuma ser o gargalo de escala de uma aplicação, e escalar na horizontal é complexo. Aplicação sem servidor já é comum, mas banco relacional sem servidor não é uma prática corrente. O Aurora tem vários recursos para vencer esse gargalo, no modelo tradicional e agora neste.

Como a cobrança funciona: a unidade é o ACU

O Aurora Serverless cobra por uma unidade própria, o ACU (Aurora Capacity Unit). Um ACU é uma fatia de poder computacional, e na época eu o traduzi assim: um ACU corresponde a 2 GB de memória, com CPU proporcional.

A lógica lembra o Lambda: você escolhe memória e o poder computacional vem embutido. O ACU custava US$ 0,06 por hora, e a cobrança é fracionada: você paga pelo tempo que a capacidade ficou ligada, não pela hora cheia. A documentação da AWS não deixava isso claro, e eu só tive certeza olhando a minha fatura.

O que o teste mostrou na prática

Usei o banco do evento Imersão AWS, de julho de 2021, que tinha poucos dados. Era um cluster Aurora PostgreSQL serverless na região de N. Virginia. Com nada conectado a ele, o console mostrava 0 capacity units e status disponível. O único custo que aparecia era o de armazenamento, praticamente nulo para um banco pequeno.

Na fatura de agosto de 2021, o consumo apareceu separado em armazenamento e em horas de Aurora: 3,495 ACU-hora a US$ 0,06, o que deu US$ 0,21. Na aula estimei que eram 2 ACUs, mas isso é palpite meu, não dado da fatura. Na fatura de setembro, com o banco de novo em zero ACU, a cobrança de computação foi zero e o armazenamento ficou em 0,001 GB-mês, a US$ 0,00.

1Entenda como ele decide ligar

O Aurora Serverless aloca capacidade com base em pedido de conexão. Parado em zero ACU, ele espera uma conexão chegar. Havendo pedido, ele aloca ACUs proporcionais e passa a responder.

Isso é o que torna a cobrança justa: sem conexão, sem computação cobrada. É também a origem da primeira limitação, que vem agora.

2Avalie a retomada antes de usar em produção

Esse foi o motivo principal pelo qual eu não recomendei o v1 para produção. Quando o banco está em zero ACU e chega a primeira requisição, ele leva um tempo para sair de zero e subir para um ACU. O aquecimento leva em torno de 30 segundos, e nos meus testes levou 35 a 36.

Pense numa aplicação que passou a madrugada com o banco em zero. De manhã, alguém acessa e a primeira resposta leva esses 30 segundos por causa da retomada. Para um ambiente de usuário real, isso é inaceitável. Para homologação e desenvolvimento, serve bem.

Eu soube na época de uma nova versão, ainda em preview, cuja proposta era responder em tempo real. Eu não a tinha testado e, por isso, não afirmo nada sobre ela. Só aceitava MySQL naquela fase.

3Conte com o banco só dentro da VPC

O Aurora Serverless v1 é inacessível de fora da VPC. Ferramentas administrativas, como o DBeaver, o Workbench do MySQL ou uma ferramenta administrativa do PostgreSQL, instaladas na sua máquina, não conectam.

Duas saídas que usei ou considerei:

• Editor de consultas dentro da AWS. O console do RDS tinha o Query Editor, então dava para rodar consultas sem sair da AWS.
• A aplicação dentro da VPC. Se a aplicação e o processo de deploy rodam dentro da VPC, o banco funciona bem para ela, numa EC2 por exemplo.

Há um teste que ficou por fazer e que vale a pena: subir uma instância Windows dentro da mesma VPC, instalar um cliente como o DBeaver e tentar conectar por lá. Como a instância está dentro da VPC, a conexão provavelmente funciona, mas não testei.

4Leia as limitações antes de criar

Além das duas anteriores, a AWS documenta outras limitações do Aurora Serverless v1. Leia essa lista antes de usar, pois ela decide se o serviço serve para o seu caso. É melhor descobrir lendo do que descobrir com a aplicação fora do ar.

Onde eu usaria

Pelo que testei: homologação e desenvolvimento, onde o banco pode ficar parado e a espera da primeira conexão não machuca ninguém. Para quem está começando com Aurora, também é uma forma barata de aprender. Produção, não, pelo menos na versão que testei.

Checklist

• Conferi na documentação oficial se o Aurora Serverless v1 ainda é opção na minha região e versão de motor
• Entendi que a unidade de cobrança é o ACU e que a cobrança é fracionada
• Medi a demora da primeira conexão depois de o banco ficar em zero ACU (35 a 36 segundos no meu teste)
• Confirmei que aplicação e ferramenta de consulta ficam dentro da VPC
• Li a lista de limitações do serviço antes de criar o cluster
• Deixei o uso em homologação e desenvolvimento, não em produção

Banco que cobra só quando é usado é uma boa ideia, desde que você saiba qual é a conta da primeira conexão. Se você quer decidir isso para a sua aplicação com alguém que já passou por isso, agende uma conversa.