Dado seu cenário, eu sugiro que você use Kubernetes, mais espeficicamente o microk8s da Canonical mantenedora do Ubuntu. E o porquê disso? A instalação é bem mais simples e já te dá acesso ao HPA (Horizontal Pod Autoscaling) que é um recurso chave e muito fantástico pra escalar seu ambiente.

Eu, por exemplo, utilizo 3 servidores dedicados (bare metal) em cluster utilizando DRDB pra persistencia de dados e quase todas minhas aplicações com MinIO - que me ajuda muito a manter, migrar ou repatriar dados.

Na minha stack quase sempre utilizo Redis e RabbitMQ, então uma parte da aplicação vai virar fila persistente ou fila em memória, que depois vai ser descarregada pra uma 1 ou N bancos (Por ex: uma parte pode ser escrita no Postgres ou MySQL e outra parte também ser escrita no MongoDB ou ScyllaDB). Num cenário hipotético pra ilustar: tenho um cliente que faz uma live, abertura de carrinho, enfim, ele gera uma concentração muito grande de usuários e direciona pra uma página de vendas, captura de leads etc e geralmente não dá tempo pro servidor escalar no método tradicional - e é ai que vem a sacada.

No meu caso eu rodo um script que monitora o tamanho da fila, e como eu já fiz teste de carga e eu sei exatamente a quantidade de usuários que cada parte vai segurar, então o HPA do Kubernetes basicamente dispara via API a requisição pra subir mais uma instância pra plugar mais um nó de worker ao cluster, só que agora essa isntância não é dedicada e sim VPS (EC2 da AWS, Droplet da Digital Ocean, VM da OCI, Cloud da Hetzner, etc aonde fizer sentido). Eu só imponho um limite pra ele não escalar ao infinito e além por prevenção caso haja algum bug.

Outra detalhe importante que eu ia me esquecendo de mencionar: uma parte da aplicação (Geralmetne a camada estática e uma parte de roteamento entre os serviços) é serverless - que me garante que mesmo que uma quantidade absurda de usuários entrem me dê tempo pra aplicação tratar o erro de too many conections, por exemplo, de forma bonitinha sem o usuário saber que o backend tá morrendo lá atrás. Mesmo que você use um Aurora da AWS com um banco serverless, ele não segura esses estouros de conexão, ele demora pra escalar inclusive (E aqui é a vantagem principal do HPA, pois se eu tenho 50k usuários concorrentes eu já sei o tamanho que a minha infra precisa escalar, e no Aurora e RDS por exemplo, você é meio que forçado a subir o número de instâncias um passo de cada vez. As vezes o simples fato da sua aplicação morrer ou estourar um erro na cara do usuário, faz os usuários a ficarem clicando em refresh sem parar e piorar o cenário gerando um DoS (Denial of Service).

Então o HPA do Kubernetes tb é responsável por gerenciar o warmup e cooldown pra instanciar mais rápido que a forma convencional (eu não espero a máquina chegar em 80% de consumo de recurso ou beirar o esgotamento) e não liberar as máquinas de forma prematura (Por ex: passou a rajada de conexõs iniciais eu sei que o provedor vai me cobrar em blocos de X intervalos de tempo, nesse caso eu crio um script que segura a instancia ao limite do que já será cobrado ou se o tráfego já reduziu ao limite do cooldown e se manteve sem acionar o gatilho de warmup nenhuma vez durante 15 minutos ai sim libera a instância do worker.

Pra reduzir ainda mais o custo, você pode utilizar round robin se for complicado você colocar um load balancer de borda (Nem toda topologia de rede favorece isso, principalmente se seus servidores tiverem geograficamente separados - que é meu caso). Então eu uso via API da CloudFlare um health-check que a cada 5 segundos faz detach do nó com falha, e nesse caso eu só posso ter failover de 1 servidor dedicado.

No caso dos bare metal eu tenho tolerância de 1 falha, pra suporar 2 falhas eu teria que ter 5 dedicados. Na real é um algoritmo de consenso tb pra evitar que fiquem números pares de servidores, mas o limite mínimo é de 2, isso pq os bancos de dados relacionais também tem replicação em um nível que quando o bloco fica par, ele força um a eleger um master, só funcionando master-master em nível impar (Com o objetivo de evitar split brain). Isso é um assunto gigante, mas quase tudo que tem replicação horizontal sofre esse problema. Cada serviço tem seu jeito de trabalhar horizontalmente, Postgres, MySQL, Mongo, Redis. Cada um dos que citei tem várias formas de configurar horizontalmente e trabalhar diferentes. Redis tem sentinela e cluster que é um assunto fantástico também. Enfim, subiu as réplicas em Kubernetes o serviço tem que ter a sua estratégia de replicar os dados dos pods entre si.

Sei que parece complicado, mas acredite é a forma mais simples de você conseguir escalar seu ambiente low-cost. Se tiver dúvidas, manda ai que respondo na medida do possível.