Uma aplicação usa AWS Lambda e ECS no Fargate e armazena dados em um banco de dados Aurora MySQL. A carga de trabalho tem uso intenso de escrita e o tráfego é altamente variável, com longos períodos de inatividade e aumentos repentinos. A instância de banco de dados otimizada para memória atual não consegue lidar com a carga variável. Qual é o design MAIS econômico para escalar para esses padrões de tráfego?

A migração para o Aurora Serverless v1 é a solução mais econômica para cargas de trabalho com tráfego variável e picos repentinos. Ele escala automaticamente a capacidade do banco de dados para cima e para baixo, pagando apenas pela capacidade consumida, eliminando a necessidade de provisionar e gerenciar instâncias. A compra de Compute Savings Plans pode otimizar ainda mais os custos para a parte de computação da solução, incluindo o Aurora Serverless. As outras opções são menos adequadas: Adicionar réplicas de leitura ajuda na leitura, mas não na escrita intensa, e Savings Plans/Instâncias Reservadas não resolvem a variabilidade da carga. Múltiplas instâncias de gravação no Aurora (Aurora Multi-Master) é uma opção de alta disponibilidade e escalabilidade de escrita, mas não é a mais econômica para picos intermitentes, pois as instâncias provisionadas geram custos mesmo em inatividade. Aurora Global Database é para recuperação de desastres e latência global, não para escalabilidade econômica de picos de tráfego em uma única região.