Como Migrar um Servidor Local para a AWS (Runbook Simples)

Introdução

Migrações de on-premises para AWS falham menos por causa da computação e mais por causa de lacunas no planejamento: objetivos de transição pouco claros, dependências negligenciadas e testes apressados. Este guia mantém o processo fácil de seguir enquanto permanece operacional. Você definirá como é o sucesso, preparará uma zona de aterrissagem mínima, executará lançamentos de teste do AWS MGN, fará a transição com confiança e, em seguida, otimizará a carga de trabalho após ela estar ativa.

O que você deve decidir antes de migrar qualquer coisa?

Qual estratégia de migração se encaixa neste servidor (os "7 Rs" da AWS)?

A maneira mais rápida de perder tempo é migrar a coisa errada. Antes de instalar qualquer agente, decida qual estratégia de migração o servidor merece para que você não faça lift-and-shift de algo que deveria ser aposentado ou substituído. Na prática, muitas equipes começam com rehosting para ganhar velocidade e, em seguida, otimizam mais tarde, uma vez que a carga de trabalho esteja estável na AWS.

No entanto, isso só funciona quando o servidor é um bom candidato "como está" e não criará uma dívida técnica cara imediatamente após a transição. Atalhos práticos de decisão:

• Rehosting: mova-se rapidamente com mudanças mínimas quando o tempo estiver apertado.
• Replataforma: mantenha o aplicativo, mas faça pequenos ajustes para se adequar à AWS.
• Refatorar: reserve esforço para diferenciais críticos para os negócios.
• Recompra: substituir por SaaS em vez de migrar o servidor.
• Retire/Retenha: remover sistemas não utilizados ou manter cargas de trabalho restritas localmente.

Um ponto de verificação interno útil é perguntar se a carga de trabalho tem um “futuro em nuvem.” Se o servidor for posteriormente decomposto em serviços gerenciados ou containerizados, documente isso agora e trate o rehosting como uma etapa temporária em vez de um design permanente.

Quais são os RTO/RPO, a janela de inatividade e os gatilhos de reversão?

Cortes são bem-sucedidos quando o sucesso é mensurável. Defina o tempo de inatividade aceitável e a tolerância à perda de dados, e então escreva as condições que forçam o retrocesso. Isso mantém o objetivo da migração e impede que as equipes improvisem durante a janela de corte. Também ajuda as partes interessadas a aprovarem, pois podem ver exatamente qual risco está sendo aceito.

Defina e documente:

• RTO: tempo máximo de inatividade aceitável.
• RPO: perda de dados máxima aceitável.
• Janela de inatividade: quando você pode alternar o tráfego de produção.
• Gatilhos de rollback: condições específicas de falha (interrupção de autenticação, transações falhadas, incompatibilidade de dados).
• Mecanismo de transição: DNS flip, troca de balanceador de carga, alterações de roteamento/firewall.

Para manter o plano de reversão realista, especifique quem é responsável por cada ação durante a transição. Por exemplo, uma pessoa é responsável pelas alterações de DNS, uma é responsável pela validação da aplicação e uma é responsável pela "decisão de reversão" com base nos gatilhos acima.

O que você precisa ter pronto no AWS e no local primeiro?

Conectividade e noções básicas de firewall para replicação

A replicação só funciona se o ambiente de origem puder acessar a AWS de forma consistente. Os bloqueadores mais comuns são controles de saída rigorosos, proxies e inspeção de TLS que interferem no tráfego HTTPS de saída. Valide a conectividade cedo e mantenha o caminho da rede estável durante a replicação inicial e os lançamentos de teste. Em muitos ambientes, a replicação não é "bloqueada" completamente; em vez disso, quedas intermitentes ou inspeção de pacotes causam um comportamento instável que é difícil de diagnosticar mais tarde.

Padrões comuns de conectividade:

• Egresso de internet pública (mais simples quando permitido)
• VPN de site a site (comum para conectividade privada)
• Conexão Direta (mais previsível para ambientes maiores)

Verificações pré-voo:

• O HTTPS de saída funciona de forma confiável a partir da rede de origem.
• O comportamento do proxy é compreendido e testado com o fluxo de migração.
• As equipes de segurança aprovam a saída necessária para a janela de migração

Se o seu ambiente estiver altamente restrito, adicione uma breve etapa de "prova de rede" ao seu plano de onda: valide os endpoints a partir de um servidor piloto e, em seguida, replique esse conjunto de regras exato para o restante da onda.

Checklist mínima de zona de aterrissagem AWS

Você não precisa de uma zona de pouso perfeita para começar, mas precisa de um alvo consistente que não mudará no meio da onda. Mantenha a construção mínima, mas deliberada, para que os testes reflitam como será a transição. Muitos problemas de migração vêm de atalhos de rede "temporários" que se tornam permanentes porque ninguém tem tempo para reconstruí-los após o lançamento.

Elementos mínimos da zona de pouso:

• A VPC e sub-redes onde as instâncias serão iniciadas (geralmente teste separado vs produção)
• Grupos de segurança alinhado aos fluxos de aplicação reais (evitar “abrir agora, corrigir depois”)
• IAM pronto para operações de migração e acesso e ferramentas de dia dois
• Básico marcação assim a propriedade e o rastreamento de custos ficam claros após a transição

Também ajuda a decidir cedo como os administradores acessarão as instâncias (bastion, VPN SSM) e como o acesso à internet de saída será fornecido (gateway NAT, proxy). Essas escolhas afetam a aplicação de patches, agentes de monitoramento e solução de problemas no primeiro dia.

Checklist de prontidão do servidor de origem

Uma migração limpa depende de uma fonte limpa. Confirme se a carga de trabalho é compatível com o método que você escolheu, depois identifique qualquer coisa que dependa de suposições locais que mudarão na AWS. Este também é o momento em que você sinaliza servidores de "caso especial" que podem exigir uma sequência diferente. Por exemplo, um servidor de arquivos com atividade de gravação intensa pode precisar de uma janela de transição mais restrita e validação mais rigorosa para arquivos e compartilhamentos abertos.

Verificações de prontidão que evitam surpresas:

• Compatibilidade de SO/carga de trabalho com a abordagem de migração
• Disco suficiente e I/O estável para sobrecarga de replicação
• Dependências mapeadas: DNS , AD/LDAP , interno PKI/certificados , bancos de dados, compartilhamentos
• Fragilidade oculta: IPs codificados, TLS legado, tarefas agendadas incomuns
• Casos especiais sinalizados precocemente: controladores de domínio, clusters, dispositivos, licenciamento por dongle

Antes de sair desta etapa, capture itens que "devem permanecer os mesmos", como nome do host, requisitos de endereço IP ou vinculações de certificado, pois estes afetam diretamente suas configurações de lançamento da AWS e sua sequência de transição.

Como você migra um servidor para a AWS com o AWS MGN?

Inicializar MGN e definir padrões de replicação

Inicialize o AWS MGN na região onde o servidor será executado, em seguida, defina as configurações padrão de replicação para que a execução da onda permaneça consistente. Um modelo estável reduz a variação por servidor e torna a solução de problemas repetível. Pense nisso como seu procedimento operacional padrão para replicação, semelhante a uma imagem de ouro em um ambiente virtualizado.

Defina os padrões de replicação antecipadamente:

• Estratégia de sub-rede alvo e posicionamento de rede
• Grupo de segurança padrão para instâncias lançadas
• Comportamento de armazenamento (mapeamento de volume, criptografia expectativas)
• Limitação de replicação para proteger o tráfego de produção

Se você já sabe que a produção exigirá configurações diferentes das de teste, defina essas diferenças explicitamente. Dessa forma, os lançamentos de teste permanecem representativos sem expor as redes de produção prematuramente.

Instale o agente e complete a sincronização inicial

Instale o agente de replicação no servidor de origem e confirme que ele registra com sucesso. A sincronização inicial é onde a instabilidade mais custa, então evite mudanças desnecessárias e monitore a saúde da replicação de perto. É também onde as equipes se beneficiam ao documentar o fluxo de instalação "conhecido como bom" para que não precisem solucionar os mesmos problemas em cada onda.

Orientações operacionais:

• Mantenha o servidor estável durante a replicação inicial (evite reinicializações se possível)
• Monitore o status de replicação e resolva os erros imediatamente
• Documente o método de instalação para que as futuras ondas sejam consistentes.

Durante a sincronização inicial, monitore não apenas o console de migração, mas também o desempenho do servidor. A sobrecarga de replicação pode revelar gargalos de armazenamento ou erros de disco que estavam anteriormente ocultos no ambiente local.

Lance uma instância de teste e valide

Um lançamento de teste transforma suposições em evidências. Inicie a instância de teste e, em seguida, valide a saúde do aplicativo de ponta a ponta, não apenas o sucesso da inicialização. Use uma lista de verificação para que os testes sejam repetíveis em servidores e ondas. Se os usuários finais se conectarem através de TSplus Acesso Remoto inclua uma verificação de caminho de acesso na validação. A consistência é importante porque permite que você compare resultados entre cargas de trabalho e identifique padrões, como problemas de resolução de DNS que afetam vários servidores.

Lista mínima de verificação de validação:

• Inicialização concluída e serviços iniciados corretamente
• Os testes de fumaça de aplicação passam para fluxos de trabalho chave
• A autenticação funciona (AD/LDAP/local)
• Caminhos de dados funcionam (conexões de DB, compartilhamentos de arquivos, integrações)
• Tarefas agendadas e serviços em segundo plano são executados conforme o esperado
• Logs e sinais de monitoramento aparecer onde sua equipe de operações espera encontrá-los

Adicione mais um passo que as equipes costumam pular: valide como os usuários realmente acessarão o aplicativo, incluindo roteamento interno, regras de firewall e quaisquer sistemas a montante. Um servidor pode estar "saudável", mas inacessível na prática.

Lançar a transição e finalizar

Cutover é uma troca controlada, não um salto de fé. Congele as mudanças, quando possível, execute a movimentação de tráfego usando o mecanismo planejado e, em seguida, valide usando a mesma lista de verificação que o teste. Mantenha a propriedade de reversão explícita para que as decisões sejam rápidas. Trate isso como um manual repetível: quanto menos você improvisar, menor será o risco.

Essenciais para a execução da transição:

• Confirmar o plano de congelamento de mudanças e comunicações
• Iniciar a instância de corte e mudar o tráfego (DNS/LB/roteamento)
• Reexecutar a lista de verificação de validação com foco extra na integridade dos dados
• Aplique gatilhos de reversão se necessário e reverta o tráfego de forma limpa.
• Finalize a transição e remova ou encerre os recursos de teste

Imediatamente após a transição, capture o que mudou na produção (novos IPs, novas rotas, novas regras de grupo de segurança) e documente. Esta é a informação que a equipe de operações precisa quando algo falha semanas depois.

O que geralmente quebra e o que você deve fazer logo após a transição?

Egress de rede, dependências de DNS/AD e "lift-and-shift não está feito"

A maioria das falhas são falhas de dependência. A replicação tende a falhar em restrições de saída e proxy, enquanto o comportamento da aplicação tende a falhar em identidade, resolução de nomes e certificados. Mesmo quando a transição é bem-sucedida, o rehosting é apenas o primeiro marco, não o estado final. Sem uma segunda fase, você frequentemente acaba com "legado hospedado na nuvem" que custa mais e é mais difícil de operar.

Pontos de interrupção mais comuns:

• Outbound HTTPS bloqueado ou alterado pelo proxy inspeção TLS
• Mudanças na resolução de DNS (problemas de horizonte dividido, regras de resolvedor ausentes)
• Gaps de acessibilidade AD/LDAP da VPC
• Cadeias PKI internas ausentes ou não confiáveis no novo ambiente
• Endpoints codificados e suposições legadas sobre caminhos de rede local

Uma mitigação simples é testar a identidade e o DNS cedo com um lançamento piloto. Se esses fundamentos funcionarem, o restante da validação da aplicação se torna muito mais previsível.

Estabilização pós-migração: segurança, backups, monitoramento, custo

As primeiras 48 horas após a transição devem priorizar a estabilidade e o controle. Certifique-se de que a carga de trabalho seja observável, recuperável e gerenciada de forma segura antes de dedicar tempo a uma otimização mais profunda. É também aqui que sua migração terá sucesso a longo prazo, pois boas operações no segundo dia evitam resultados do tipo "nós movemos, mas ninguém quer assumir".

Ações imediatas após a transição:

• Confirme que o monitoramento/alerta está ativo e sob responsabilidade
• Certifique-se de que os backups estão habilitados e complete uma validação de restauração.
• Aperte os grupos de segurança e aplique o princípio do menor privilégio IAM
• Padronizar a abordagem de correção e acesso administrativo (caminhos auditáveis)
• Comece a redimensionar após coletar dados reais de utilização.
• Imponha a marcação para evitar a deriva de custo de "proprietário desconhecido"

Uma vez que a estabilidade seja comprovada, agende uma breve revisão de otimização para cada servidor migrado. Mesmo uma leve análise sobre tipos de armazenamento, escolha da família de instâncias e estratégia de capacidade reservada pode reduzir significativamente os custos.

Onde o TSplus se encaixa após você mover servidores para a AWS?

Após as cargas de trabalho do Windows serem executadas na AWS, muitas equipes ainda precisam de uma maneira simples de publicar aplicativos e desktops do Windows para os usuários sem construir uma pilha de VDI pesada. TSplus Acesso Remoto entrega publicação de aplicativos e acesso remoto a desktop para servidores Windows na AWS, em local ou em ambientes híbridos, com administração simples e licenciamento previsível que se adapta a operações de PME e mercado médio.

Conclusão

Migrar um servidor local para a AWS é mais bem-sucedido quando segue um runbook repetível: escolha a estratégia de migração certa, valide as dependências, replique com segurança, teste de forma realista e faça a transição com gatilhos de reversão claros. Uma vez que a produção esteja estável, mude o foco para as operações do dia dois: fortalecimento da segurança, validação de backup, monitoramento e dimensionamento adequado. Isso transforma um "movimento" em uma plataforma confiável e com controle de custos.