Migrar um banco de dados para a nuvem costuma ser vendido como algo simples: “é só mover o banco para a AWS”. Na prática, qualquer pessoa que já passou por isso sabe que a história é bem diferente. Principalmente quando estamos falando de uma aplicação financeira, com transações em tempo real, requisitos regulatórios e tolerância praticamente zero a indisponibilidade.
Neste artigo, quero compartilhar os aprendizados que tive ao trabalhar na migração e modernização de um banco SQL on-premises para o Amazon Aurora PostgreSQL. Mais do que explicar ferramentas, a ideia aqui é dividir o raciocínio por trás das decisões, os erros iniciais, os ajustes no caminho e, principalmente, quando faz sentido escolher Aurora provisionado em vez de Serverless.
Este texto é especialmente para quem está começando na AWS ou está vivendo a transição de um ambiente tradicional para a nuvem e ainda tenta entender onde cada serviço realmente se encaixa.
O problema nunca é só o banco
Antes de falar de Aurora, vale voltar um passo. O banco original rodava on-premises e já carregava alguns problemas clássicos: crescimento dependente de hardware, backups manuais, janelas de manutenção difíceis de negociar e uma arquitetura que exigia intervenção humana em momentos críticos.
Em sistemas financeiros, esse tipo de dependência é perigosa. Downtime não é apenas um inconveniente técnico; ele afeta confiança do cliente, contratos e conformidade regulatória. O que precisávamos não era apenas “mais performance”, mas previsibilidade, alta disponibilidade e menos risco operacional.
Foi nesse contexto que a nuvem deixou de ser uma discussão conceitual e passou a ser uma necessidade prática.
Por que Amazon Aurora?
Amazon Aurora é frequentemente apresentado como “PostgreSQL compatível, só que melhor”. E, embora isso seja verdade até certo ponto, o diferencial real do Aurora está na arquitetura.
Diferente de bancos tradicionais, o armazenamento do Aurora é distribuído e replicado automaticamente entre múltiplas zonas de disponibilidade. Isso significa que falhas de disco, ou até de uma AZ inteira, não exigem o tipo de recuperação manual que muitos DBAs aprenderam a fazer ao longo da carreira.
Para quem vem do on-premises, isso muda completamente a forma de pensar backup, réplica e failover. Você deixa de gerenciar peças individuais e passa a confiar em um serviço que já nasce assumindo que falhas vão acontecer.
Mas escolher Aurora não encerra a decisão. A grande pergunta vem logo depois: Serverless ou provisionado?
A promessa do Aurora Serverless
Aurora Serverless costuma ser muito atraente para quem está começando. Ele promete escalar automaticamente, cobrar pelo uso e eliminar a necessidade de escolher tamanho de instância. Em workloads com carga imprevisível ou intermitente, isso pode ser uma grande vantagem.
Durante o projeto, avaliamos seriamente essa opção. Em teoria, ela resolveria boa parte do esforço de capacity planning. Na prática, no entanto, aplicações financeiras raramente se comportam como workloads “elásticos”. A carga é relativamente constante, a latência precisa ser previsível e qualquer pausa inesperada pode virar incidente.
Foi nesse ponto que um aprendizado importante ficou claro: Serverless não é uma escolha técnica melhor ou pior, mas uma escolha baseada em contexto. Para este caso específico, previsibilidade era mais importante do que elasticidade automática.
A decisão pelo Aurora provisionado
Optamos por um cluster Aurora PostgreSQL provisionado, com arquitetura Multi-AZ. Isso nos deu controle explícito sobre capacidade, latência e comportamento em cenários de falha.
Alta disponibilidade, aqui, não é apenas ter réplicas. É garantir que o failover seja rápido, gerenciado e previsível. Em ambientes críticos, saber exatamente como o sistema se comporta em uma falha é tão importante quanto evitar a falha em si.
Outro ponto fundamental foi a governança. Toda a infraestrutura foi criada usando Terraform. Banco, rede, regras de segurança, parâmetros, tudo versionado como código. Isso trouxe consistência, reprodutibilidade e facilitou muito revisões, auditorias e mudanças futuras.
Para quem está começando, esse é um aprendizado valioso: infraestrutura como código não é um “extra”, mas parte da arquitetura.
Migrar sem parar o sistema
Um dos maiores receios em qualquer migração de banco é o downtime. Parar uma aplicação financeira para trocar banco simplesmente não é uma opção.
Para isso, utilizamos o AWS Database Migration Service com Change Data Capture. O conceito é simples, mas poderoso: enquanto a aplicação ainda escreve no banco legado, o banco novo recebe continuamente as mesmas alterações. Quando chega o momento do corte, a diferença entre os bancos é mínima.
Na prática, isso exige acompanhamento constante. Replicação tem latência, e latência varia conforme carga, volume de escrita e até detalhes do schema. Aprendi muito observando como pequenas mudanças no padrão de escrita impactavam o atraso do CDC e como isso precisava ser comunicado claramente ao time.
Observabilidade não é opcional
Se tem algo que mudou radicalmente a forma como tomamos decisões nesse projeto, foi observabilidade. Não no sentido de “olhar gráficos”, mas de usar métricas para decidir.
No início, o cluster foi superdimensionado. Isso é comum, especialmente quando o medo de subdimensionar fala mais alto. Mas, com Performance Insights, ficou claro onde estavam os gargalos reais e ajudou a identificar também onde eles não estavam.
Com base em dados reais, conseguimos reduzir o tamanho do cluster e cortar cerca de 20% do custo, sem impacto perceptível na aplicação. Esse aprendizado é simples, mas poderoso: cloud não é sobre escolher ambientes grandes, mas sobre escolher ambientes certos para sua necessidade.
O CloudWatch também teve um papel importante, pois monitorar IOPS e latência de forma consistente nos deu confiança para validar que os SLAs estavam sendo cumpridos com evidências.
Segurança sem senha no código
Outro ganho importante foi eliminar credenciais hardcoded. Com AWS Secrets Manager, as aplicações passaram a buscar credenciais dinamicamente, com rotação e controle centralizado.
Para quem vem de ambientes legados, isso pode parecer detalhe. Mas em produção, especialmente em times grandes, isso reduz riscos reais e evita uma classe inteira de incidentes difíceis de rastrear.
O maior aprendizado como DBA
Talvez o aprendizado mais importante desse projeto não tenha sido técnico, mas conceitual. Migrar para a nuvem não é apenas mover dados. É mudar a forma como pensamos o papel de quem cuida do banco.
O administrador de banco de dados deixa de ser alguém focado apenas em manutenção e passa a atuar como alguém que entende arquitetura, custo, confiabilidade e impacto no negócio. Performance deixa de ser apenas tuning e passa a ser observabilidade, decisão e contexto.
Para quem está começando
Se você está iniciando na AWS, meu conselho é simples: não comece pelo serviço, comece pelo problema. Alta disponibilidade, previsibilidade, custo, latência e governança são perguntas muito mais importantes do que “qual banco usar”.
Aurora Serverless é uma excelente solução, quando o contexto pede isso. Aurora provisionado também é, quando o sistema exige controle e previsibilidade. A maturidade vem quando você consegue explicar sua escolha com base no cenário, não na tendência.
No fim, tecnologia boa é aquela que resolve o problema certo, no contexto certo, com o menor risco possível.
Deixe um comentário