Migração para AWS

Ponto único de falha: o que muda ao sair de uma VPS para a AWS

Por Audizio Nunes · 13 de outubro de 2026

Se a sua aplicação depende de uma máquina só, você tem um ponto único de falha: quando esse servidor para, param juntos o sistema, o banco de dados e os arquivos. Levar a VPS para a AWS não elimina esse risco por si só. O que muda são os recursos disponíveis para desenhar alta disponibilidade.

O que é ponto único de falha em um servidor único

Fala-se em ponto único de falha quando vários componentes dependem do mesmo recurso. Numa VPS típica, a aplicação, o banco de dados e os arquivos enviados pelos usuários ficam na mesma máquina, e um problema nela atinge os três de uma vez.

O pilar de confiabilidade do Well-Architected recomenda evitar pontos únicos de falha e operar cargas de produção em pelo menos duas Zonas de Disponibilidade, que são conjuntos de datacenters separados dentro de uma mesma Região.

Uma instância EC2 sozinha continua sendo um servidor único

Segundo a AWS, uma carga que roda em uma única instância (o servidor virtual) do Amazon EC2, em uma única Zona de Disponibilidade, não tem alta disponibilidade. No Amazon Lightsail a orientação é a mesma: instâncias em zonas diferentes, atrás de um balanceador.

Mesmo sozinha, a instância conta com dois recursos:

• Os dados de um volume do Amazon EBS, o disco da instância, são replicados entre vários servidores da mesma zona.
• A recuperação automática vem ativada por padrão nas instâncias compatíveis. Se a verificação do hardware e da rede do hospedeiro falha, a AWS tenta mover a instância para outro equipamento, mantendo identificador, endereços IP e volumes EBS.

A recuperação acontece na mesma zona, perde o que estava em memória, não age quando o problema é do sistema operacional ou da aplicação, não opera durante um evento de serviço da AWS e pode falhar se faltar capacidade. Segundo a AWS, ela serve a instâncias individuais; um sistema resiliente pede balanceador e Auto Scaling. E a AWS não faz backup automático dos volumes EBS: criar snapshots, as cópias do disco em um ponto no tempo, é responsabilidade de quem opera.

Alta disponibilidade na AWS: o que cada bloco resolve

• Regiões e Zonas de Disponibilidade. Cada Região tem zonas fisicamente separadas, com energia e rede independentes, para que a falha de uma não derrube as outras. É preciso distribuir os recursos entre elas.
• Elastic Load Balancing. Envia tráfego só aos destinos saudáveis, em uma ou mais zonas. Com uma única instância, não há para onde desviar.
• Amazon EC2 Auto Scaling. Substitui a instância com falha por uma nova. Em grupos pequenos a troca pode causar algum tempo de parada.
• Amazon RDS Multi-AZ. No banco gerenciado da AWS, a opção Multi-AZ (várias zonas) mantém uma cópia em espera, sincronizada, em outra zona, e troca para ela automaticamente (failover). No SQL Server a AWS faz isso com espelhamento, Always On ou replicação em bloco, conforme a versão e a edição. A documentação informa de 60 a 120 segundos como tempo típico da troca, que pode aumentar e varia com o banco e a classe da instância; a AWS recomenda testar. A opção precisa ser ativada, e a aplicação ainda precisa refazer as conexões.
• Amazon S3. Na classe S3 Standard, a usada por padrão, guarda os objetos em vários dispositivos de pelo menos três zonas. Há classes de zona única, como a S3 One Zone-IA, que não têm essa proteção. A aplicação que grava arquivos no disco local precisa ser adaptada.
• Snapshots e backups. Os snapshots do EBS são incrementais e replicados entre as zonas da Região. O RDS ativa backups automáticos por padrão, com retenção de até 35 dias, e a restauração para um ponto no tempo cria uma instância nova, com endereço novo.

Como deixar de ter tudo em uma VPS só, em etapas

1. Separar o banco. No Amazon RDS, o Multi-AZ fica disponível como opção. No SQL Server ela depende da edição e da versão (a lista da AWS não inclui a Express). Para esse banco, veja como migrar SQL Server para o Amazon RDS.
2. Separar os arquivos. Mover uploads e documentos para o S3.
3. Tirar o estado da aplicação. A AWS orienta que, entre uma requisição e outra, o serviço não dependa de dados guardados localmente em disco ou em memória, o que inclui a sessão do usuário. Tarefas agendadas também precisam de dono: um cron configurado em todas as instâncias roda em todas ao mesmo tempo.
4. Duplicar a aplicação. Duas ou mais instâncias, em zonas diferentes, atrás de um balanceador e com Auto Scaling.

Nenhuma etapa é obrigatória, e a AWS lembra que objetivos de recuperação mais apertados custam mais em recursos e em complexidade de operação. Depois das duas primeiras, a falha da máquina da aplicação já não leva junto os dados do banco nem os arquivos. Mas, se essa máquina falhar, o sistema ainda sai do ar, e o banco sem Multi-AZ continua sendo um ponto único de falha. O efeito na conta está em quanto custa migrar para a AWS.

O que avalio antes de recomendar uma arquitetura na AWS

Com exceção do backup, nenhum dos blocos descritos antes entra por padrão. Cada um muda a conta do mês, então a recomendação sai de uma análise feita com o cliente, antes de qualquer alteração na infraestrutura:

• Multi-AZ no banco. Nem sempre entra. Segundo a AWS, a implantação Multi-AZ pode custar aproximadamente o dobro da de zona única. A decisão depende de quanto tempo o negócio aceita ficar sem o banco e do orçamento.
• Região. A AWS orienta comparar conformidade, serviços disponíveis, custo e latência. Na prática, a pergunta é se a aplicação precisa ficar na Região de São Paulo, por causa da distância até os usuários ou de alguma exigência de manter os dados no Brasil, ou se pode rodar em outra Região.
• Servidores da aplicação. Quando a aplicação permite, proponho rodar em duas Zonas de Disponibilidade, atrás de um balanceador.
• Filas. Se o sistema guarda as tarefas pendentes em uma tabela do banco, usada como fila, avalio se ela continua assim ou se vale passar para o Amazon SQS, o serviço gerenciado de filas da AWS.
• O que o cliente já tem. Se a empresa já contrata envio de e-mail ou outro serviço que funciona, ele não é trocado só porque a infraestrutura mudou.
• Backup automatizado. Entra desde o início, com retenção combinada com o cliente e teste de restauração.
• Itens cobrados por hora. Balanceador de carga e endereço IPv4 público são cobrados por hora, mesmo sem tráfego, e o próprio balanceador ocupa endereços públicos. Por isso conto quantas máquinas precisam mesmo de IP público.

O resultado é uma proposta com as opções lado a lado e o efeito de cada uma na conta, para o cliente decidir. Veja como escolher a estratégia de migração de cada aplicação.

Backup não é alta disponibilidade

O Well-Architected define dois objetivos de recuperação, ambos escolhidos pela empresa. O RTO é o atraso máximo aceitável entre a interrupção e a volta do serviço. O RPO é o tempo máximo aceitável desde o último ponto de recuperação dos dados.

Backup serve para restaurar depois. A frequência do backup define o ponto de recuperação que se consegue alcançar, e os dados ainda precisam ser restaurados. Alta disponibilidade busca manter o serviço no ar quando um componente falha.

O inverso também vale. Segundo a AWS, se um arquivo é apagado ou corrompido, a replicação contínua pode levar essa alteração para a cópia, e por isso um backup de ponto no tempo continua necessário. A estratégia de backup, diz a AWS, precisa incluir o teste dos backups.

O que o SLA da AWS diz sobre instância única e Multi-AZ

O SLA de computação da AWS traz dois compromissos para o EC2. Para cada instância individual, 99,5% de disponibilidade no mês. Com todas as instâncias em execução distribuídas em duas ou mais zonas da mesma Região, 99,99% no nível da Região, e só conta como indisponibilidade o período em que todas ficam sem conectividade externa ao mesmo tempo. O SLA do Amazon RDS segue a mesma lógica: 99,95% para instância Multi-AZ e 99,5% para instância única, e exclui as classes micro.

O texto fala em esforços comercialmente razoáveis, e o que o cliente recebe quando o percentual não é atingido é crédito de serviço, pedido por chamado no suporte. O que se mede é a conexão com a instância, não o funcionamento da sua aplicação. O SLA não é promessa de que o sistema não para. Leia o documento vigente antes de usar esses números.

Quando manter um servidor único é uma escolha razoável

• O sistema tolera horas parado. Se o RTO definido pelo negócio é de horas, backup testado e um roteiro de restauração podem bastar. A AWS recomenda ajustar a meta de disponibilidade à necessidade de cada parte do sistema.
• Custo e complexidade. No Multi-AZ do RDS, a instância em espera e o armazenamento dela também são cobrados, e a operação fica mais complexa.
• A necessidade é só ter uma cópia. Provedores de VPS também oferecem backups e snapshots do servidor, em geral como recurso a ativar.

Esta página não calcula custo nem trata de arquitetura em mais de uma Região. Para o caminho da mudança em si, veja como migrar de VPS para AWS. Se quiser ajuda para avaliar o risco do seu servidor, conheça o serviço de migração para a AWS.