# Como sair da VPS e migrar para a AWS com alta disponibilidade

> O caso do Ricardo: da VPS com Nginx, MinIO e RabbitMQ para RDS Multi-AZ, S3, SQS e ECS em duas AZs, na ordem em que ele migrou.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-14
- Assuntos: Migração, Containers, Banco de dados
- URL: https://pages.formacaoaws.com.br/blog/como-sair-da-vps-e-migrar-para-a-aws/
- Aula de origem: "Como Ricardo saiu da VPS e migrou sua app para a AWS alcançando a alta disponibilidade" (https://www.youtube.com/watch?v=qwpr-JTADsI)

Com a aplicação numa VPS e um servidor caseiro para cada serviço, basta o fornecedor oscilar para o sistema cair. Aqui está a ordem de uma migração real para a AWS com alta disponibilidade: banco no Amazon RDS Multi-AZ, arquivos e filas no Amazon S3 e no Amazon SQS, e a aplicação em containers no Amazon ECS, em duas zonas de disponibilidade.

Foi o caminho do Ricardo, aluno da Formação, com os erros que ele cometeu no meio.

O Ricardo é sócio da empresa e líder técnico de desenvolvimento e operação. A regra da migração dele: o que era servidor caseiro vira serviço gerenciado, e o que continua com você passa a rodar duplicado.

## O ponto de partida: um servidor para cada problema

A stack da empresa sempre foi .NET com PostgreSQL. Começou numa hospedagem compartilhada, foi para VPS, e em 2022 o servidor mais antigo na VPS tinha seis anos.

Cada necessidade nova virou um servidor novo: um Nginx como proxy reverso com certificado do Let's Encrypt na entrada, a aplicação num servidor, o banco isolado em outra VPS, um MinIO tentando imitar o S3, um RabbitMQ para as filas e o "Severino", o servidor onde ia parar tudo que não cabia em nenhum outro. Nas palavras dele, a cada seis meses aparecia um servidor novo na empresa.

![A arquitetura na VPS: o DNS no Registro.br leva ao servidor Nginx, depois ao servidor de aplicação, que se liga a um servidor para cada serviço (Postgres, MinIO, Linux NFS e RabbitMQ)](https://pages.formacaoaws.com.br/blog/assets/posts/como-sair-da-vps-e-migrar-para-a-aws/arquitetura-vps.svg)

Cada um com sistema, backup e configuração diferentes, tudo pelo terminal, para uma equipe pequena que vinha de desenvolvimento. Eles estavam montando em casa o que a AWS já entrega pronto. E cada solução caseira cobrou seu preço:

- **Entrada sem alta disponibilidade.** O certificado wildcard pago custava, na época, de dois a três mil reais, e eles nem sabiam se aquilo ia funcionar. O Let's Encrypt levou uma ou duas semanas para ficar seguro, e eles não sabiam distribuir o certificado entre várias máquinas. O servidor de entrada ficou mais de dois anos sozinho. Nas poucas vezes em que caiu, a porta do sistema fechou para os clientes.
- **MinIO travado.** Ele não conectou direito com a aplicação ASP.NET Core usando SSL. Foi quase uma semana com os arquivos travados, entre eles os retornos bancários, e cliente reclamando, até voltarem para pastas compartilhadas num servidor Linux, duplicadas para beta e produção.
- **RabbitMQ sem domínio da ferramenta.** Para poder reenviar, salvavam uma cópia de cada mensagem no banco de dados. Essa cópia salvou a equipe algumas vezes.

## O que fez a migração sair do papel

Em 2022 o fornecedor da VPS mudou de data center. Começaram perdas de acesso aos servidores e quedas de uma ou duas horas.

O suporte respondia "instabilidade, a equipe está verificando", sem prazo, e o Ricardo ficava sem resposta para dar ao cliente dele.

Numa mesma semana, o sistema caiu três vezes no horário de pico da manhã. Numa quinta-feira, ficou fora mais da metade do horário comercial.

A equipe se reuniu e decidiu migrar, no meio da implantação de um cliente novo. Ele já estudava na Formação havia mais de um ano e tinha o roteiro esboçado. A lição que eu tiro disso: se você não tira o tempo para fazer a migração, uma hora é obrigado a fazer, no momento de perrengue.

O destino foi este:

**Fluxo:** Amazon Route 53 (DNS do domínio) → Load balancer (HTTPS com certificado do ACM) → Amazon ECS (containers em 2 AZs de São Paulo) → Amazon RDS (PostgreSQL Multi-AZ)

E a ordem em que ele chegou lá:

![A ordem da migração no slide do Ricardo: banco no RDS, depois S3 e SQS, HTTPS com load balancer e ACM, e por fim o ECS](https://pages.formacaoaws.com.br/blog/assets/posts/como-sair-da-vps-e-migrar-para-a-aws/ordem-da-migracao.webp)

## Passo 1: migrar o banco para o Amazon RDS Multi-AZ

O banco vai primeiro. Para o Ricardo, foi de longe a parte mais tranquila, mesmo sendo a mais crítica da empresa: um backup normal do PostgreSQL, restaurado no Amazon RDS, e a aplicação reapontada para o endereço novo. Esse passo ele já tinha dado no fim do ano anterior, antes das quedas.

Duas coisas ajudaram:

- **Uma máquina de apoio** para mover os backups de um servidor para outro, bem mais rápido do que baixar o backup no computador e subir de novo. A empresa já levava o backup de produção para o beta para validar atualizações.
- **Os scripts da Formação**, que deram o roteiro de migração do banco.

Como já tinha feito o curso de alta disponibilidade, ele subiu o RDS já em **Multi-AZ**: o banco tem uma réplica em outra zona de disponibilidade (um data center separado dentro da mesma região), com failover automático. Segundo ele, desde então o banco nunca caiu.

## Passo 2: trocar arquivos, filas e certificado por serviço gerenciado

Com o banco resolvido, cada servidor caseiro deu lugar a um serviço gerenciado:

- **Amazon S3** no lugar do MinIO.
- **Amazon SQS** no lugar do RabbitMQ.
- **AWS Certificate Manager (ACM)** no lugar do Let's Encrypt no Nginx.

O SDK no .NET foi simples, e acabou a preocupação com backup e administração desses servidores.

O HTTPS, que na VPS custou uma ou duas semanas, ele chamou de "ridiculamente fácil": o certificado é gerado no ACM e anexado na porta HTTPS do load balancer. A escala e a distribuição do certificado entre várias máquinas, que ele nunca conseguiu fazer na VPS, já vêm prontas.

## Passo 3: subir a aplicação em containers no Amazon ECS

Por último, o servidor de aplicação. Ele saiu da VPS com a aplicação já em Docker e subiu no Amazon ECS. Escolheu o ECS por ser gerenciado e porque o material que já tinha supria a necessidade.

O curso de Docker que ele tinha feito, de uma hora e meia a duas horas, virou o manual: ele montou o roteiro e foi seguindo, tirando dúvidas no grupo do Telegram da Formação.

Na configuração do ECS ele usou subnets em mais de uma AZ e **pelo menos duas tasks** rodando sempre. O resultado:

![O centro da arquitetura na AWS: dentro da VPC, o load balancer distribui para uma EC2 em cada zona de disponibilidade (A e B); as duas gravam no RDS da zona A, que replica para o RDS da zona B](https://pages.formacaoaws.com.br/blog/assets/posts/como-sair-da-vps-e-migrar-para-a-aws/arquitetura-aws.svg)

1. O Amazon Route 53 resolve o domínio.
2. O load balancer recebe o HTTPS com o certificado do ACM.
3. Atrás dele, pelo menos duas instâncias EC2 em duas AZs de São Paulo rodam as tasks do ECS.
4. Todas apontam para o mesmo RDS Multi-AZ.
5. A aplicação usa S3 e SQS, também gerenciados.
6. O conteúdo estático sai do S3 pelo Amazon CloudFront, com custo que ele chamou de irrisório.

O que não está duplicado é gerenciado.

## Passo 4: rodar em paralelo e testar o deploy sob carga

As duas plataformas rodaram em paralelo durante a migração. Na semana seguinte, um usuário disse que o sistema tinha caído: estava na plataforma antiga. Ela foi desligada depois, num fim de semana.

> **Importante:** enquanto a VPS antiga estiver no ar, tem usuário usando ela. Reclamação de queda nessa fase pode vir de lá, não da AWS.

O deploy também mudou. Na VPS, atualização crítica ia para o almoço ou a madrugada, com aviso aos clientes de que o sistema ficaria fora alguns minutos.

Agora o conteúdo estático é publicado no S3 em vez de ir para o Nginx, e a aplicação vai como imagem nova para o ECS. Na troca, o ECS sobe tasks novas, redireciona o tráfego para elas e só então tira as antigas do load balancer.

Para confiar nisso, ele rodou um teste de carga de 10 minutos e mandou atualizar o sistema no meio. Não caiu.

## Passo 5: medir antes de reservar

A conclusão dele é que a AWS ia sair mais barata que a VPS. Pela estimativa dele, a camada de aplicação, que custava em torno de R$ 1.200 a R$ 1.500 na VPS, devia cair para no máximo R$ 200 a R$ 250. São números da realidade dele em 2022, não tabela de preço: confira os valores atuais na página oficial da AWS.

> **Importante:** não reserve instância antes de medir o uso. O Ricardo reservou para o banco uma instância muito maior do que precisava.

Na aplicação ele fez diferente. Subiu com a capacidade que sabia que atendia, olhou o Amazon CloudWatch no primeiro dia, viu que o processamento não chegava perto de 40% e rodou instâncias sob demanda menores para medir antes de reservar. A regra que ficou:

- **Reserva** para o que roda o tempo todo e é previsível. Ele fez reservas conversíveis de um ano, por ser o primeiro ano dele em produção na AWS.
- **Sob demanda** para o que roda um ou dois dias e fica desligado o resto do mês, como o serviço que importa dados que os clientes trazem de concorrentes.

## Checklist

- Liste cada servidor da VPS e o que ele faz. Cada solução caseira é candidata a serviço gerenciado.
- Migre o banco primeiro: backup do PostgreSQL, restauração no Amazon RDS Multi-AZ, aplicação reapontada.
- Troque arquivos por S3, filas por SQS e o certificado caseiro pelo ACM no load balancer.
- Coloque a aplicação em Docker e suba no Amazon ECS, com pelo menos duas tasks em duas AZs.
- Rode a plataforma antiga em paralelo durante a migração e só depois desligue.
- Teste o deploy debaixo de carga antes de confiar nele.
- Meça no CloudWatch antes de reservar instância.

O Ricardo migrou porque o fornecedor tirou o sistema do ar, e deu certo porque o roteiro já estava pronto. Monte o seu antes de precisar dele.