Come migrare un server on-premises su AWS (Runbook semplice)

Introduzione

Le migrazioni da on-prem a AWS falliscono meno a causa del calcolo e più a causa di lacune nella pianificazione: obiettivi di passaggio poco chiari, dipendenze trascurate e test affrettati. Questa guida mantiene il processo facile da seguire pur rimanendo operativo. Definirete come appare il successo, preparerete una zona di atterraggio minima, eseguirete lanci di test AWS MGN, passerete con fiducia e poi ottimizzerete il carico di lavoro dopo che sarà attivo.

Cosa dovresti decidere prima di migrare qualsiasi cosa?

Quale strategia di migrazione si adatta a questo server (le "7 R" di AWS)?

Il modo più veloce per perdere tempo è migrare la cosa sbagliata. Prima di installare qualsiasi agente, decidi quale strategia di migrazione il server merita, in modo da non sollevare e spostare qualcosa che dovrebbe essere ritirato o sostituito. In pratica, molti team iniziano con il rehosting per velocità, poi ottimizzano in seguito una volta che il carico di lavoro è stabile in AWS.

Tuttavia, ciò funziona solo quando il server è un buon candidato "così com'è" e non creerà debito tecnico costoso immediatamente dopo il passaggio. Scorciatoie decisionali pratiche:

• Rehosting: muovi rapidamente con il minimo cambiamento quando il tempo è limitato.
• Replatforming: mantieni l'app ma apporta piccole modifiche per adattarla ad AWS.
• Rifattorizzare: riservare sforzi per differenziali critici per il business.
• Riacquisto: sostituire con SaaS invece di migrare il server.
• Ritirare/Mantenere: rimuovere i sistemi non utilizzati o mantenere carichi di lavoro limitati in loco.

Un utile punto di controllo interno è chiedere se il carico di lavoro ha un "futuro nel cloud". Se il server sarà successivamente scomposto in servizi gestiti o containerizzati, documentalo ora e tratta il rehosting come un passo temporaneo piuttosto che come un design permanente.

Quali sono i RTO/RPO, la finestra di inattività e i trigger di rollback?

I tagli hanno successo quando il successo è misurabile. Definire il tempo di inattività e la tolleranza alla perdita di dati accettabili, quindi annotare le condizioni che costringono al ripristino. Questo mantiene l'obiettivo della migrazione e impedisce ai team di improvvisare durante la finestra di taglio. Aiuta anche le parti interessate aziendali a firmare perché possono vedere esattamente quale rischio viene accettato.

Definire e documentare:

• RTO: massimo tempo di inattività accettabile.
• RPO: perdita massima di dati accettabile.
• Finestra di inattività: quando sei autorizzato a commutare il traffico di produzione.
• Rollback triggers: condizioni di errore specifiche (interruzione dell'autenticazione, transazioni non riuscite, incongruenza dei dati).
• Meccanismo di transizione: DNS flip, switch del bilanciatore di carico, modifiche al routing/firewall.

Per mantenere il piano di rollback realistico, specifica chi possiede ciascuna azione durante il passaggio. Ad esempio, una persona si occupa delle modifiche DNS, una si occupa della validazione dell'applicazione e una si occupa della "decisione di rollback" basata sui trigger sopra.

Cosa ti serve pronto in AWS e in locale per primo?

Connettività e nozioni di base del firewall per la replica

La replicazione funziona solo se l'ambiente sorgente può raggiungere AWS in modo coerente. I blocchi più comuni sono controlli di uscita rigorosi, proxy e ispezione TLS che interferiscono con il traffico HTTPS in uscita. Convalida la connettività in anticipo e mantieni stabile il percorso di rete durante la replicazione iniziale e i lanci di test. In molti ambienti, la replicazione non è "bloccata" completamente; invece, interruzioni intermittenti o ispezione dei pacchetti causano un comportamento instabile che è difficile da diagnosticare in seguito.

Modelli di connettività comuni:

• Uscita su internet pubblico (più semplice quando consentito)
• VPN site-to-site (comune per connettività privata)
• Connessione Diretta (più prevedibile per ambienti più grandi)

Controlli pre-volo:

• L'HTTPS in uscita funziona in modo affidabile dalla rete sorgente.
• Il comportamento del proxy è compreso e testato con il flusso di migrazione.
• I team di sicurezza approvano l'uscita richiesta per la finestra di migrazione

Se il tuo ambiente è altamente bloccato, aggiungi un breve passaggio di "prova della rete" al tuo piano di onda: convalida i punti finali da un server pilota, quindi replica esattamente quel set di regole per il resto dell'onda.

Checklist minima per la landing zone AWS

Non è necessario avere una zona di atterraggio perfetta per iniziare, ma è necessario avere un obiettivo coerente che non cambierà a metà onda. Mantieni la costruzione minimale, ma deliberata, in modo che i test riflettano come sarà il passaggio. Molti problemi di migrazione derivano da collegamenti di rete "temporanei" che diventano permanenti perché nessuno ha tempo di ricostruirli dopo il lancio.

Elementi minimi della zona di atterraggio:

• A VPC e sottoreti dove le istanze verranno avviate (spesso test separati rispetto alla produzione)
• Gruppi di sicurezza allineato ai flussi di applicazione reali (evitare "apri ora, risolvi dopo")
• IAM pronto per le operazioni di migrazione e l'accesso e gli strumenti del giorno due
• Base etichettatura quindi la proprietà e il monitoraggio dei costi sono chiari dopo il passaggio

Aiuta anche a decidere precocemente come gli amministratori accederanno alle istanze (bastione, VPN , SSM) e come sarà fornito l'accesso a Internet in uscita (gateway NAT, proxy). Queste scelte influenzano la gestione delle patch, gli agenti di monitoraggio e la risoluzione dei problemi fin dal primo giorno.

Checklist di prontezza del server sorgente

Una migrazione pulita dipende da una sorgente pulita. Conferma che il carico di lavoro sia compatibile con il metodo scelto, quindi identifica qualsiasi cosa che dipenda da assunzioni locali che cambieranno in AWS. Questo è anche il momento in cui segnali i server "casi speciali" che potrebbero richiedere una sequenza diversa. Ad esempio, un server di file con un'attività di scrittura intensa potrebbe necessitare di una finestra di transizione più ristretta e di una validazione più rigorosa per i file e le condivisioni aperte.

Controlli di prontezza che prevengono sorprese:

• Compatibilità del sistema operativo/carico di lavoro con l'approccio di migrazione
• Spazio su disco sufficiente e I/O costante per l'overhead di replicazione
• Dipendenze mappate: DNS , AD/LDAP interno PKI/certificati , database, condivisioni
• Fragilità nascosta: IP hard-coded, TLS obsoleto, attività programmate non comuni
• Casi speciali segnalati in anticipo: controller di dominio, cluster, dispositivi, licenza dongle

Prima di lasciare questo passaggio, cattura gli elementi "devono rimanere gli stessi" come hostname, requisiti dell'indirizzo IP o binding dei certificati, poiché questi influenzano direttamente le impostazioni di avvio di AWS e la tua sequenza di passaggio.

Come si migra un server su AWS con AWS MGN?

Inizializza MGN e imposta i valori predefiniti di replica

Inizializza AWS MGN nella regione in cui il server verrà eseguito, quindi definisci le impostazioni predefinite di replica in modo che l'esecuzione dell'onda rimanga coerente. Un modello stabile riduce la variazione per server e rende la risoluzione dei problemi ripetibile. Considera questo come la tua procedura operativa standard per la replica, simile a un'immagine gold in un ambiente virtualizzato.

Imposta i valori predefiniti di replica in anticipo:

• Strategia della subnet target e posizionamento della rete
• Baseline di sicurezza per le istanze avviate
• Comportamento di archiviazione (mappatura del volume, crittografia aspettative)
• Limitazione della replicazione per proteggere il traffico di produzione

Se sai già che la produzione richiederà impostazioni diverse rispetto ai test, definisci esplicitamente quelle differenze. In questo modo, i lanci di test rimangono rappresentativi senza esporre prematuramente le reti di produzione.

Installa l'agente e completa la sincronizzazione iniziale

Installa l'agente di replica sul server sorgente e conferma che si registri con successo. La sincronizzazione iniziale è il momento in cui l'instabilità ti costa di più, quindi evita modifiche non necessarie e monitora attentamente la salute della replica. È anche qui che i team traggono vantaggio dalla documentazione del flusso di installazione "conosciuto come buono" in modo da non dover risolvere gli stessi problemi in ogni ondata.

Guida operativa:

• Mantieni il server stabile durante la replica iniziale (evita riavvii se possibile)
• Monitora lo stato della replica e affronta gli errori immediatamente
• Documentare il metodo di installazione in modo che le future ondate siano coerenti

Durante la sincronizzazione iniziale, monitora non solo la console di migrazione ma anche le prestazioni del server. L'overhead di replicazione può rivelare colli di bottiglia nello storage o errori del disco che erano precedentemente mascherati nell'ambiente on-prem.

Avvia un'istanza di test e convalida

Un lancio di test trasforma le assunzioni in prove. Avvia l'istanza di test, quindi convalida la salute dell'applicazione end-to-end, non solo il successo dell'avvio. Utilizza un elenco di controllo in modo che i test siano ripetibili su server e ondate. Se gli utenti finali si connetteranno tramite TSplus Remote Access includere un controllo del percorso di accesso nella convalida. La coerenza è importante perché consente di confrontare i risultati tra i carichi di lavoro e individuare schemi, come problemi di risoluzione DNS che influenzano più server.

Elenco di controllo minimo di convalida:

• Il boot si completa e i servizi partono correttamente.
• I test di fumo dell'applicazione superano per i flussi di lavoro chiave
• L'autenticazione funziona (AD/LDAP/locale)
• I percorsi dei dati funzionano (connessioni DB, condivisioni di file, integrazioni)
• I lavori pianificati e i servizi in background funzionano come previsto
• Registri e segnali di monitoraggio appaiono dove il tuo team operativo si aspetta di trovarli

Aggiungi un ulteriore passaggio che i team spesso saltano: convalida come gli utenti accederanno effettivamente all'applicazione, inclusi il routing interno, le regole del firewall e eventuali sistemi a monte. Un server può essere "sano" ma irraggiungibile nella pratica.

Lanciare il passaggio e finalizzare

Il cutover è uno switch controllato, non un salto nel vuoto. Congela le modifiche, quando possibile, esegui il trasferimento del traffico utilizzando il meccanismo pianificato, quindi valida utilizzando la stessa lista di controllo dei test. Mantieni esplicita la proprietà del rollback in modo che le decisioni siano rapide. Tratta questo come un playbook ripetibile: meno improvvisi, minore è il rischio.

Essenziali per l'esecuzione del cutover:

• Conferma il piano di congelamento delle modifiche e delle comunicazioni
• Avvia l'istanza di cutover e commuta il traffico (DNS/LB/routing)
• Rieseguire la checklist di validazione con particolare attenzione all'integrità dei dati
• Applica i trigger di rollback se necessario e ripristina il traffico in modo pulito
• Finalizzare il passaggio e rimuovere o terminare le risorse di test

Subito dopo il passaggio, cattura ciò che è cambiato in produzione (nuovi IP, nuove rotte, nuove regole del gruppo di sicurezza) e documentalo. Queste sono le informazioni di cui il team operativo ha bisogno quando qualcosa si rompe settimane dopo.

Cosa si rompe di solito e cosa dovresti fare subito dopo il passaggio?

Egress di rete, dipendenze DNS/AD e "il lift-and-shift non è completato"

La maggior parte dei fallimenti sono fallimenti di dipendenza. La replicazione tende a rompersi a causa di vincoli di uscita e proxy, mentre il comportamento dell'applicazione tende a rompersi a causa di identità, risoluzione dei nomi e certificati. Anche quando il passaggio riesce, il rehosting è solo il primo traguardo, non lo stato finale. Senza una seconda fase, spesso ci si ritrova con "legacy ospitato nel cloud" che costa di più ed è più difficile da gestire.

I punti di interruzione più comuni:

• Outbound HTTPS bloccato o alterato dal proxy ispezione TLS
• Modifiche alla risoluzione DNS (problemi di orizzonte diviso, regole del risolutore mancanti)
• lacune di raggiungibilità AD/LDAP dal VPC
• Catene PKI interne mancanti o non affidabili nel nuovo ambiente
• Endpoint hard-coded e assunzioni legacy sui percorsi di rete locali

Una semplice mitigazione è testare l'identità e il DNS in anticipo con un lancio pilota. Se quei fondamenti funzionano, il resto della validazione dell'applicazione diventa molto più prevedibile.

Stabilizzazione post-trasferimento: sicurezza, backup, monitoraggio, costo

Le prime 48 ore dopo il passaggio dovrebbero dare priorità alla stabilità e al controllo. Assicurati che il carico di lavoro sia osservabile, recuperabile e gestito in modo sicuro prima di dedicare tempo a un'ottimizzazione più profonda. È anche qui che la tua migrazione ha successo a lungo termine, perché buone operazioni del secondo giorno prevengono risultati del tipo "l'abbiamo spostato, ma nessuno vuole prendersene la responsabilità".

Azioni immediate dopo il passaggio:

• Conferma che il monitoraggio/alerting sia attivo e di proprietà
• Assicurati che i backup siano abilitati e completa una convalida del ripristino
• Rafforzare i gruppi di sicurezza e applicare il principio del minimo privilegio IAM
• Standardizzare l'approccio alla patching e l'accesso amministrativo (percorsi auditabili)
• Inizia a ottimizzare dopo aver raccolto dati reali di utilizzo.
• Imporre il tagging per prevenire la deriva dei costi "proprietario sconosciuto"

Una volta dimostrata la stabilità, pianifica una breve revisione dell'ottimizzazione per ciascun server migrato. Anche un intervento leggero sui tipi di archiviazione, sulla scelta della famiglia di istanze e sulla strategia di capacità riservata può ridurre materialmente i costi.

Dove si inserisce TSplus dopo aver spostato i server su AWS?

Dopo che i carichi di lavoro Windows sono in esecuzione su AWS, molti team hanno ancora bisogno di un modo semplice per pubblicare applicazioni e desktop Windows agli utenti senza costruire un pesante stack VDI. TSplus Remote Access fornisce pubblicazione di applicazioni e accesso desktop remoto per server Windows in AWS, on-prem, o ambienti ibridi, con amministrazione semplice e licenze prevedibili che si adattano alle operazioni delle PMI e del mercato medio.

Conclusione

La migrazione di un server on-premises su AWS ha maggior successo quando segue un runbook ripetibile: scegliere la giusta strategia di migrazione, convalidare le dipendenze, replicare in modo sicuro, testare in modo realistico e passare con chiari trigger di rollback. Una volta che la produzione è stabile, spostare l'attenzione sulle operazioni del secondo giorno: indurimento della sicurezza, convalida del backup, monitoraggio e dimensionamento appropriato. Questo trasforma un "trasloco" in una piattaforma affidabile e controllata nei costi.