Configurazione di AWS DMS
Passiamo alla pratica iniziando dalla configurazione di AWS DMS. In questo tutorial imparerai a migrare un database Oracle su Amazon Aurora (MySQL), includendo conversione dello schema, replica dei dati e best practice per garantire una transizione fluida.
Step 1: Prerequisiti per usare AWS DMS
Prima di migrare i database, devi configurare le risorse AWS essenziali. Usando AWS CloudFormation, puoi automatizzare il provisioning per concentrarti sulle attività di migrazione. Il template che useremo distribuisce:
- Una VPC AWS con subnet pubbliche per il networking.
- Una Replication Instance di AWS DMS per eseguire la migrazione dei dati.
- Un’istanza Amazon RDS come database di destinazione.
- Un’istanza Amazon EC2 per ospitare strumenti di migrazione come AWS Schema Conversion Tool (SCT) o una simulazione del database di origine.
Accedi alla Console AWS
- Accedi alla AWS Management Console usando le tue credenziali.
- Clicca sul menu a tendina in alto a destra e seleziona la tua regione. Per questo tutorial selezionerò la regione N. Virginia.

Figura 1 Selezione della regione AWS nella AWS Management Console.
- Vai alla Console EC2 e apri la sezione Key Pair. Assicurati di essere nella stessa regione AWS dello step precedente.
- Clicca su Create Key Pair e chiamala “DMS”.
Figura 2 Creazione di una key pair per l’accesso sicuro in AWS EC2.
- Clicca su Create e il browser scaricherà
DMS.pem. - Salva questo file in modo sicuro: ti servirà più avanti nel tutorial.
Configura l’ambiente
In questo step userai un template CloudFormation (CFN) per predisporre l’infrastruttura AWS necessaria alla migrazione del database. Questo automatizza il provisioning e ti permette di concentrarti sui task di migrazione.
- Apri la console AWS CloudFormation e clicca Create Stack.
- Seleziona Choose an existing template, poi scegli Upload a template file.

Figura 3 Caricamento di un template CloudFormation per creare un nuovo stack.
- Scarica il file da Github Gist e clicca Choose file.
- Carica il file
DMS.yamle clicca Next. - Compila i parametri richiesti come indicato, quindi clicca Next.

Figura 4 Configurazione dei parametri per uno stack AWS DMS su CloudFormation
Nota: Puoi modificare il tipo di istanza in base alle tue esigenze o lasciarlo com’è.
- Nella pagina Stack Options, mantieni le impostazioni predefinite e clicca Next.
- Rivedi la configurazione e clicca Create stack.
- Verrai reindirizzato alla console CloudFormation, dove lo stato mostrerà “CREATE_IN_PROGRESS”. Attendi finché non passa a “CREATE_COMPLETE”.

Figura 5 Verifica dello stato di creazione delle risorse in AWS CloudFormation
- Una volta completato, vai alla sezione Outputs e annota i valori: ti serviranno per il resto del tutorial.
Prepara i database di origine e destinazione per la migrazione
Inizieremo dalla configurazione del database di origine. Segui questi passaggi per accedere all’istanza EC2 usando il Remote Desktop Protocol (RDP).
Step 1: Configura l’accesso RDP
- Per Mac: scarica Microsoft Remote Desktop dall’App Store.
- Per PC: usa Remote Desktop per connetterti al PC che hai configurato.
Step 2: Modifica le regole del Security Group per l’accesso RDP
- Apri la Console AWS EC2.
- Nel menu a sinistra, clicca su Security Groups (potresti dover scorrere).
- Seleziona il security group che termina con “InstanceSecurityGroup” spuntando la casella.
- Clicca Actions > Edit Inbound Rules.
- Individua la regola RDP (porta 3389), clicca su Source e seleziona My IP per una maggiore sicurezza.
- Se usi una VPN aziendale o una rete complessa, potresti dover cambiarla in “Anywhere (0.0.0.0/0)” in seguito.

Figura 6 Modifica delle regole di sicurezza in ingresso su AWS.
- Clicca Save rules.
Step 3: Recupera le credenziali RDP
- Nella Console AWS EC2, clicca su Instances nel menu a sinistra.
- Seleziona l’istanza denominata “<StackName>-EC2Instance”.
- Clicca Actions > Connect.
- Vai alla sezione RDP Client e clicca Get password.
- Clicca Browse e carica il file Key Pair scaricato in precedenza.
- Clicca Decrypt password.

Figura 7 Recupero della password di Windows per un’istanza AWS EC2.
- Copia la password generata tra gli appunti per usarla più avanti.
Step 4: Connettiti all’istanza EC2
- Clicca Download Remote Desktop File per salvare il file RDP.
- Apri il client RDP (Microsoft Remote Desktop su Mac).
- Usa la password decrittata per accedere.
- Se richiesto, clicca Done per completare la configurazione.
Step 5: Connettiti a Oracle SQL Developer
Una volta connesso all’istanza EC2, segui questi passaggi per stabilire una connessione al database Oracle usando Oracle SQL Developer.
Step 1: Apri Oracle SQL Developer
- Trova Oracle SQL Developer nella barra delle applicazioni e aprilo.
- Nota: Le icone potrebbero apparire in un ordine diverso rispetto alle immagini di riferimento.

Figura 8 Configurazione di una nuova connessione database in Oracle SQL Developer.
Step 2: Crea una nuova connessione database
- Clicca sul segno più (+) nel menu a sinistra per creare una New Database Connection.
- Inserisci i seguenti dettagli:
- Connection Name: Source Oracle
- Username: dbadmin
- Password: Controlla il tab Outputs dello stack CloudFormation alla voce DMSDBSecretP
- Save Password: Spunta questa casella.
- Hostname: Trova il Source Oracle Endpoint nel tab Output di CloudFormation. In alternativa, vai alla console RDS, seleziona la tua istanza Oracle di origine e usa l’endpoint indicato.
- Port: 1521
- SID: ORACLEDB
Step 3: Test e connessione
- Clicca Test per verificare la connessione.
- Quando lo stato del test mostra “Successful”, clicca Connect.
Step 4: Configura Oracle per la migrazione con AWS DMS
Prima di usare Oracle come origine per AWS DMS, assicurati che siano presenti le seguenti configurazioni:
1. Crea un utente DMS con i privilegi richiesti
AWS DMS richiede un account utente (utente DMS) con privilegi di lettura e scrittura sul database Oracle.
2. Abilita l’ARCHIVELOG MODE
- ARCHIVELOG MODE deve essere abilitata per fornire a LogMiner le informazioni dei transaction log.
- AWS DMS si affida a LogMiner per catturare i dati di modifica dai log di archivio.
- Assicurati che i log di archivio siano mantenuti per almeno 24 ore per evitare perdite di dati durante la migrazione.
3. Abilita il supplemental logging
- Supplemental logging a livello di database:
- Garantisce che LogMiner acquisisca tutti i dettagli necessari per varie strutture di tabelle (ad es., tabelle clustered e index-organized).
- Supplemental logging a livello di tabella:
- Deve essere abilitato per ogni tabella che intendi migrare.
4. Concedi i privilegi richiesti all’utente AWS DMS
- In Oracle SQL Developer, clicca sull’icona SQL Worksheet.
- Connettiti al database Oracle di origine.
- Copia, incolla ed esegui le istruzioni dal Github Gist per concedere all’utente AWS DMS i privilegi necessari.

Figura 9 Esecuzione di script SQL in Oracle SQL Developer.
Step 6: Configura la destinazione Amazon Aurora (MySQL)
Dopo aver impostato la configurazione iniziale e il database di origine, puoi migrare un database di esempio. Questa guida descrive come usare AWS Schema Conversion Tool (AWS SCT) e AWS Database Migration Service (AWS DMS) per trasformare la struttura del database e spostare i dati su Amazon Aurora (MySQL).
Inoltre, AWS DMS fungerà da strumento per abilitare la replica continua, il che significa che tutte le modifiche effettuate nel database di origine verranno replicate in tempo reale nel database di destinazione.
- Riconnettiti all’istanza EC2 tramite RDP.
- Apri la cartella DMS Workshop sul Desktop e fai doppio clic su AWS Schema Conversion Tool Download per installare l’ultima versione.
- Decomprimi e installa AWS SCT seguendo la procedura guidata (accetta i default e clicca Finish).
- Avvia AWS SCT dallo Start Menu o dall’icona arancione SCT sul Desktop e accetta i termini.
- Apri MySQL Workbench 8.0 CE e crea una nuova connessione database per la destinazione Aurora MySQL usando:
- Connection Name: Target Aurora RDS (MySQL)
- Host Name:
<TargetAuroraMySQLEndpoint>(trovalo negli Outputs di CloudFormation o nella console RDS) - Port: 3306
- Username: dbadmin
- Password: recuperala dal tab Output di CloudFormation
- Default Schema: lascia vuoto

Figura 10 Configurazione di una connessione MySQL Workbench verso Amazon Aurora.
- Clicca Test Connection, conferma l’esito positivo, quindi connettiti ad Aurora MySQL.
- Esegui in MySQL Workbench le istruzioni SQL di GitHub Gist per i permessi (clicca l’icona a fulmine per avviare).
Ora che hai installato AWS Schema Conversion Tool, il passo successivo è creare un Database Migration Project usando lo strumento.
Step 1: Avvia un nuovo progetto
- Apri AWS Schema Conversion Tool (SCT).
- Se il New Project Wizard non si avvia automaticamente, vai su File > New Project Wizard.
- Inserisci i seguenti dettagli:
- Project Name: AWS Schema Conversion Tool Source DB to Aurora MySQL
- Location:
C:\Users\Administrator\AWS Schema Conversion Tool - Database Type: Select SQL Database
- Source Engine: Oracle
- Migration Type: Select I want to switch engines and optimize for the cloud
- Clicca Next.
Step 2: Connettiti al database di origine
- Compila la Source Database Configuration:
- Connection Name: Oracle Source
- Type: SID
- Server Name:
<SourceOracleEndpoint>(trovalo negli Outputs di CloudFormation o nella RDS Console) - Server Port: 1521
- Oracle SID: ORACLEDB
- User Name: dbadmin
- Password: recuperala dal tab Output di CloudFormation
- Use SSL: non spuntato
- Store Password: spuntato
- Oracle Driver Path:
C:\Users\Administrator\Desktop\DMS Workshop\JDBC\ojdbc11.jar
- Clicca Test Connection. Se va a buon fine, clicca Next.

Figura 11 Test della connettività al database in AWS Schema Conversion Tool.
Step 3: Seleziona il database e rivedi l’assessment report
- Seleziona il database
dms_sample, quindi clicca Next. - Ignora eventuali avvisi sul caricamento dei metadati.
- Rivedi il Database Migration Assessment Report:

Figura 12 Revisione dei risultati dell’assessment della migrazione del database.
- Dopo la revisione, clicca Next.
Nota: SCT converte automaticamente la maggior parte degli oggetti ed evidenzia quelli che richiedono intervento manuale. Presta particolare attenzione a procedure, package e function, che potrebbero necessitare modifiche.
Step 4: Connettiti al database di destinazione
- Compila la Target Database Configuration:
- Target Engine: Amazon Aurora (MySQL compatible) (modifica il valore predefinito)
- Connection Name: Aurora MySQL Target
- Server Name:
<TargetAuroraMySQLEndpoint>(trovalo negli Outputs di CloudFormation o nella RDS Console) - Server Port: 3306
- User Name: dbadmin
- Password: recuperala dal tab Output di CloudFormation
- Use SSL: non spuntato
- Store Password: spuntato
- MySQL Driver Path:
C:\Users\Administrator\Desktop\DMS Workshop\JDBC\mysql-connector-j-8.3.0.jar - Clicca Test Connection. Se va a buon fine, clicca Finish.
Ora che hai creato un Database Migration Project, il prossimo passo è convertire lo schema del database di origine in Amazon Aurora MySQL.
Step 5: Conversione dello schema del database di origine in Amazon Aurora MySQL
- Clicca View nel menu in alto e seleziona Assessment Report View.
- Seleziona
DMS_SAMPLEnel pannello a sinistra per visualizzare la gerarchia del database. - Vai al tab Action Items per vedere gli elementi di schema che non possono essere convertiti automaticamente.
- AWS SCT categorizza gli elementi come:
- Verde – Convertito con successo.
- Blu – Richiede modifiche manuali prima della migrazione.
- Hai due opzioni per gli elementi di schema che non possono essere convertiti automaticamente:
- Modificare lo schema di origine.
- Modificare gli script SQL generati prima di applicarli al database di destinazione. Regoleremo manualmente una stored procedure in AWS SCT per renderla compatibile con Aurora MySQL.
Step 6: Modifica il codice SQL
- Clic destro sul database
DMS_SAMPLEnel pannello a sinistra. - Seleziona Convert Schema per generare le istruzioni DDL del database di destinazione.
- Quando richiesto sugli oggetti esistenti, clicca Yes.

Figura 13 Conversione di uno schema Oracle con AWS Schema Conversion Tool.
- Clic destro sullo schema
dms_sample_dbo(origine SQL Server) odms_sample(altre origini) nel pannello di destra. - Seleziona Apply to database.
- Quando richiesto, clicca Yes per confermare.
- Espandi lo schema
dms_sample_dboodms_samplenel pannello di destra. - Ora dovresti vedere tabelle, viste, stored procedure e altri oggetti creati correttamente in Aurora MySQL.
Hai convertito con successo lo schema e gli oggetti del database in un formato compatibile con Amazon Aurora MySQL!
Step 2: Creazione di una replication instance
Segui questi passaggi per creare una DMS Replication Instance:
- Apri la console AWS Database Migration Service (DMS) o cerca DMS nella barra di ricerca AWS.
- Nel menu a sinistra, clicca su Replication Instances per accedere alla schermata di gestione delle istanze di replica.
- È disponibile un’istanza di replica preconfigurata: puoi saltare questo step. Tuttavia, se vuoi fare pratica, procedi creando una nuova istanza:
- Clicca Create replication instance in alto a destra. Poi compila i seguenti dettagli:
- Name: DMSReplication-dms
- Descriptive Amazon Resource Name (ARN): lascia vuoto
- Description: (Opzionale) Inserisci "Replication server for Database Migration"
- Instance Class: dms.c5.xlarge
- Engine Version: lascia il valore predefinito.
- High Availability / Multi-AZ: seleziona Dev or Test workload (Single-AZ)
- Allocated Storage (GB): 50
- VPC: seleziona l’ID della VPC che include DMSVpc nel nome (adatta il menu a tendina se necessario)
- Publicly Accessible: imposta su No (non spuntato)
- Advanced -> VPC Security Group(s): seleziona il security group predefinito

Figura 14 Creazione di una replication instance.
- Inserisci i dettagli richiesti per la replication instance, quindi clicca Create.
Step 3: Configurazione degli endpoint di origine e destinazione
Ora che abbiamo l’istanza di replica, il prossimo passo è creare gli endpoint di origine e destinazione per la migrazione del database. Segui questi passaggi per configurare entrambi gli endpoint.
Crea l’endpoint di origine
- Apri la Console AWS DMS.
- Nel menu a sinistra, clicca su Endpoints.
- Clicca Create endpoint (in alto a destra).
- Inserisci i dettagli richiesti per l’endpoint del database di origine:
- Endpoint Type: Source endpoint
- Select RDS DB Instance: seleziona solo per Oracle (lascia vuoto per gli altri)
- RDS Instance: seleziona
<StackName>-SourceOracleDB - Endpoint Identifier: oracle-source (o mantieni il valore precompilato)
- Descriptive ARN: lascia vuoto
- Source Engine: Oracle
- Access to Endpoint Database: seleziona “Provide access information manually”
- Server Name:
<SourceOracleEndpoint>(dovrebbe autocompilarsi). - Port: 1521
- SSL Mode: None
- User Name: dbadmin
- Password: controlla il tab Outputs dello stack CloudFormation alla voce 2DMSDBSecretP
- SID/Service Name: ORACLEDB
- VPC: seleziona l’ID VPC con DMSVpc dalla configurazione dell’ambiente
- Replication Instance: scegli
cfn-DMSReplication,DMSReplicationo l’istanza di replica che hai creato (se pronta) - Clicca Run Test per verificare la connettività.

Figura 15 verifica della connettività.
- Quando lo stato del test passa a “Successful”, clicca Create endpoint.
Crea l’endpoint di destinazione
Segui lo stesso processo per creare il Target Endpoint per il database Aurora RDS:
- Clicca di nuovo su Create endpoint.
- Inserisci i seguenti dettagli:
- Endpoint Type: Target endpoint
- Select RDS DB Instance: spunta la casella per tutte le destinazioni RDS
- RDS Instance: scegli
<StackName>-AuroraMySQLInstance - Endpoint Identifier:
aurora-mysql-target - Descriptive ARN: lascia vuoto
- Target Engine: Amazon Aurora MySQL
- Access to Endpoint Database: seleziona “Provide access information manually”
- Server Name:
TargetAuroraMySQLEndpoint(o dovrebbe autocompilarsi). - Port: 3306
- SSL Mode: None
- User Name:
dbadmin - Password: controlla il tab Outputs dello stack CloudFormation alla voce 2DMSDBSecretP
- VPC: seleziona l’ID VPC con DMSVpc dalla configurazione dell’ambiente
- Replication Instance: scegli
cfn-DMSReplication,DMSReplicationo l’istanza di replica che hai creato (se pronta) - Clicca Run Test per verificare la connettività.
- Quando lo stato del test passa a “Successful”, clicca Create endpoint.
Step 4: Configurare l’attività di migrazione
Gestire i vincoli di chiave esterna nella migrazione con AWS DMS
AWS DMS non impone un ordine di caricamento delle tabelle durante il full load, il che può causare violazioni di chiave esterna se i vincoli sono abilitati. Inoltre, i trigger sul database di destinazione possono determinare modifiche inattese ai dati. Abbiamo anche rimosso i vincoli di chiave esterna dal database di destinazione Aurora MySQL.
- Avvia MySQL Workbench 8.0 CE (usato in precedenza per la configurazione dei permessi).
- Apri una nuova finestra di query.
- Elimina gli indici dei vincoli: AWS SCT non crea automaticamente i vincoli quando si migra da Oracle; crea solo gli indici. Esegui il seguente script SQL per eliminare gli indici:
DROP INDEX set_seat_idx ON dms_sample.sporting_event_ticket;
DROP INDEX set_ticketholder_idx ON dms_sample.sporting_event_ticket;
DROP INDEX set_sporting_event_idx ON dms_sample.sporting_event_ticket;
- Clicca sull’icona Esegui (fulmine) per lanciare lo script.

Figura 16 Interfaccia di MySQL Workbench che mostra query SQL.
Con i vincoli rimossi, il database Aurora MySQL di destinazione è pronto per la migrazione dei dati con AWS DMS!
Crea un’attività di migrazione DMS
AWS DMS usa le Database Migration Task per spostare i dati dal database di origine a quello di destinazione. Segui questi passaggi per creare e monitorare l’attività di migrazione.
Step 1: Crea un’attività di migrazione
- Apri la console AWS DMS.
- Clicca su Database migration tasks nel menu a sinistra.
- Clicca Create task (angolo in alto a destra).
Step 2: Configura le impostazioni dell’attività
- Task Identifier:
source-to-AuroraMySQL-target - Replication Instance:
cfn-dmsreplication - Source Database Endpoint: Seleziona il tuo database di origine
- Target Database Endpoint:
cfn-auroramysqlinstance - Migration Type: Migra i dati esistenti e replica le modifiche in corso
- CDC Stop Mode: Don’t use custom CDC stop mode
- Create Recovery Table on Target DB: Non selezionato
- Target Table Preparation Mode: Do nothing (non predefinito)
- Stop Task After Full Load Completes: Don’t stop
- LOB Column Settings / Include LOB Columns in Replication: Limited LOB mode
- Max LOB Size (KB): 32
- Data Validation: Non selezionato
- Enable CloudWatch Logs: Selezionato
- Log Context: Default levels
- Batch-Optimized Apply: Non selezionato
Step 3: Configura il mapping delle tabelle
- Espandi la sezione Table mappings.
- Seleziona Wizard come modalità di modifica.
- Clicca Add new selection rule, quindi inserisci quanto segue:
- Schema:
DMS_SAMPLE% - Table Name:
% - Action: Include

Figura 17 Configure Table Mapping.
Step 4: Configura le regole di trasformazione
- Espandi la sezione Transformation rules.
- Clicca Add new transformation rule e inserisci le seguenti regole:
- Rule 1:
- Target: Schema
- Schema Name:
DMS_SAMPLE - Action: Make lowercase
- Rule 2:
- Target: Table
- Schema Name:
DMS_SAMPLE - Table Name:
% - Action: Make lowercase
- Rule 3:
- Target: Column
- Schema Name:
DMS_SAMPLE - Table Name:
% - Action: Make lowercase
Step 5: Finalizza e avvia l’attività di migrazione
- Deseleziona Turn on premigration assessment (non richiesto per questo tutorial).
- Assicurati che la Migration task startup configuration sia impostata su Start automatically on create.
- Clicca Create task.
Eseguire la migrazione
È finalmente il momento di eseguire la nostra migrazione!
Step 1: Avviare la migrazione
L’attività passerà attraverso i seguenti stati:
- Creating → Ready → Starting → Running.
- Clicca il pulsante di aggiornamento circolare per aggiornare lo stato.

Figura 18 Interfaccia attività di migrazione AWS DMS che mostra la replica in corso.
Step 2: Monitorare la migrazione
AWS DMS fornisce metriche CloudWatch per monitorare le prestazioni della tua istanza di replica e delle attività di migrazione.
Visualizzare le metriche CloudWatch per le istanze di replica:
- Apri la console AWS DMS.
- Clicca su Replication Instances nel menu a sinistra.
- Seleziona la tua istanza di replica.
- Vai alla scheda CloudWatch Metrics per visualizzare i dati sulle prestazioni.

Figura 19 Grafici di utilizzo risorse dell’istanza AWS DMS.
Visualizzare le metriche CloudWatch per le attività di migrazione:
- Apri la console AWS DMS.
- Clicca su Database Migration Tasks nel menu a sinistra.
- Seleziona la tua attività DMS dall’elenco.
- Vai alla scheda Monitor per analizzare le prestazioni dell’attività.

Figura 20 Metriche di throughput del full load di AWS DMS.
Con CloudWatch puoi monitorare metriche chiave come latenza, replication lag e stato dell’attività.
Step 3: Gestire errori e avvisi di migrazione
Durante la migrazione con AWS DMS, possono verificarsi errori e avvisi dovuti a problemi di connessione, integrità dei dati o configurazioni errate. Di seguito trovi i problemi più comuni e i passaggi per la risoluzione.
1. Errori di connessione
- Problema: DMS non riesce a connettersi al database di origine o di destinazione.
- Soluzione:
- Verifica le impostazioni di VPC, i Security Group e la disponibilità delle Subnet.
- Assicurati di usare hostname, porta e credenziali del database corretti.
- Verifica la connettività cliccando Test Endpoint Connection nella console DMS.
2. Problemi di integrità dei dati
- Problema: Dati mancanti o incoerenti tra origine e destinazione.
- Soluzione:
- Abilita la validazione CDC per controllare eventuali transazioni mancanti.
- Confronta il conteggio righe usando le metriche CloudWatch.
- Esegui query di checksum su entrambi i database per garantire la coerenza dei dati.
3. Colli di bottiglia nelle prestazioni
- Problema: Migrazione lenta o in ritardo.
- Soluzione:
- Abilita il Parallel Load per accelerare i trasferimenti massivi.
- Regola la modalità LOB (usa Full LOB mode se gestisci oggetti di grandi dimensioni).
- Monitora le metriche CloudWatch per CPU, memoria e replication lag.
4. Vincoli e trigger nel database di destinazione
- Problema: Violazioni di chiave esterna o modifiche inattese ai dati.
- Soluzione:
- Disabilita i vincoli di chiave esterna prima della migrazione.
- Rimuovi temporaneamente i trigger sul database di destinazione per evitare conflitti.
5. Replica CDC interrotta inaspettatamente
- Problema: L’attività si interrompe prima di applicare le modifiche in corso.
- Soluzione:
- Controlla nei log la posizione di avvio della CDC.
- Assicurati che il periodo di retention dei log sia sufficiente (ad es. 24 ore per Oracle LogMiner).
- Riavvia l’attività CDC dall’ultima transazione applicata.
6. Disallineamento dello schema tra origine e destinazione
- Problema: Alcuni oggetti non vengono migrati a causa di differenze di schema.
- Soluzione:
- Usa AWS SCT (Schema Conversion Tool) per valutare le incompatibilità.
- Applica modifiche manuali allo schema se necessario.
7. Verifica dei log e debug degli errori
- Usa i log di AWS CloudWatch:
- Vai a AWS DMS Console > Migration Tasks > View Logs.
- Filtra i log per parole chiave di errore come failure, timeout o constraint violation.
- Abilita il Verbose Logging se servono approfondimenti maggiori.
Passi post-migrazione
Ora vediamo alcuni passaggi che puoi eseguire dopo una migrazione con DMS.
Step 1: Validare l’integrità dei dati
Una volta che AWS DMS ha completato la migrazione, è fondamentale validare l’integrità dei dati e assicurarsi che il database di destinazione rispecchi correttamente la sorgente. Di seguito alcune tecniche chiave di validazione:
Usare la funzione di data validation di AWS DMS
- Se la validazione dei dati era abilitata in AWS DMS, vai a:
- AWS DMS Console > Migration Tasks > Table Statistics
- Controlla eventuali errori di validazione e riesegui la migrazione per le tabelle interessate.

Figura 21 Riepilogo di validazione AWS DMS.
Step 2: Eseguire il cutover al database di destinazione
Quando AWS DMS ha migrato correttamente tutti i dati e completato la replica continua (CDC), il passo finale è passare al database di destinazione come sistema primario. Segui questi passaggi per garantire una transizione fluida:
Step 1: Verifica la coerenza dei dati
Prima di effettuare lo switch, conferma che tutti i dati siano stati replicati completamente:
- Confronta il conteggio righe tra origine e destinazione.
- Esegui la validazione con checksum sulle tabelle chiave.
- Controlla le metriche CloudWatch per il replication lag (dovrebbe essere zero prima del cutover).
Step 2: Interrompi nuove modifiche sul database di origine
Per evitare incoerenze nei dati:
- Disabilita le scritture sul database di origine impostandolo in modalità sola lettura.
- Assicurati che tutte le applicazioni che scrivono sul database puntino invece alla nuova destinazione.
Step 3: Interrompi la replica AWS DMS
- Nella console AWS DMS, vai a Database Migration Tasks.
- Seleziona la tua attività di migrazione attiva.
- Clicca Stop Task per interrompere la replica in corso.

Figura 22 Arresto dell’attività di migrazione AWS DMS.
Step 4: Promuovi il database di destinazione a primario
- Rimuovi le restrizioni di sola lettura sul database di destinazione
- Aggiorna le stringhe di connessione delle applicazioni per puntare al nuovo database.
Step 5: Esegui la validazione e i test finali
- Prova le query critiche dell’applicazione per confermare la funzionalità.
- Verifica che le nuove transazioni vengano elaborate correttamente nel sistema di destinazione.
- Esegui test end-to-end per assicurarti che i processi di business restino integri.
Step 6: Disattiva il vecchio database di origine (se necessario)
- Il database di origine può essere archiviato o dismesso se non è più richiesto.
- Conserva i backup prima di rimuovere completamente il sistema di origine.
Step 3: Pulizia e finalizzazione
Step 1: Arresta ed elimina l’attività di migrazione
- Apri la console AWS DMS.
- Nel menu a sinistra, clicca su Database Migration Tasks.
- Seleziona le attività di migrazione che hai creato.
- Clicca Actions > Stop e conferma.
- Quando lo stato dell’attività passa a “Stopped”, clicca Actions > Delete e conferma.
Step 2: Elimina gli endpoint DMS
- Nella console AWS DMS, clicca su Endpoints nel menu a sinistra.
- Seleziona gli endpoint creati durante il tutorial.
- Clicca Actions > Delete e conferma.

Figura 23 Eliminazione degli endpoint AWS DMS.
Step 3: Elimina lo stack CloudFormation
- Apri la AWS CloudFormation Console.
- Seleziona lo stack CloudFormation creato durante il tutorial.
- Clicca Delete (angolo in alto a destra).

Figura 24 Conferma dell’eliminazione dello stack in AWS.
- Conferma l’eliminazione: CloudFormation rimuoverà automaticamente tutte le risorse associate (potrebbe richiedere fino a 15 minuti).
- Monitora la console CloudFormation per assicurarti che lo stack sia completamente eliminato.
Funzionalità avanzate di AWS DMS
Ora vediamo alcuni degli scenari più complessi che puoi risolvere con AWS DMS.
Trasformazione dei dati durante la migrazione
AWS DMS consente la trasformazione dei dati durante la migrazione permettendo modifiche come il cambio dei tipi di dato delle colonne, la rinomina di tabelle e colonne e il filtraggio dei dati. Queste trasformazioni aiutano ad allineare lo schema di origine con la struttura del database di destinazione. Usando le regole di trasformazione nella sezione Table Mappings, puoi applicare queste modifiche in modo dinamico senza alterare il database di origine.
Per i passaggi dettagliati, consulta questo blog post su trasformazione del contenuto delle colonne.
Usare AWS DMS con S3 come destinazione
AWS DMS può migrare i dati su Amazon S3, abilitando uno storage conveniente per analisi, machine learning o ulteriori elaborazioni usando servizi come AWS Glue, Athena o Redshift.
Segui questi passaggi per configurare Amazon S3 come destinazione per la migrazione AWS DMS.
Step 1: Crea un bucket S3
- Apri la console Amazon S3.
- Clicca su Create bucket.
- Imposta il Bucket Name a:
dmstargetbucket-<random 4-digit number> - Assicurati che la regione corrisponda alle risorse AWS DMS.
- Lascia tutte le altre impostazioni predefinite e clicca Create bucket.
Step 2: Crea una cartella nel bucket S3
- Apri il bucket appena creato.
- Clicca su Create folder.
- Assegna alla cartella il nome
dmstargetfolder. - Lascia tutte le impostazioni predefinite e clicca Create folder.
Step 3: Crea una policy AWS IAM per l’accesso a S3
- Apri la Console IAM e vai su Policies.
- Clicca su Create policy, poi scegli la scheda JSON.
- Copia e incolla la seguente policy, sostituendo
"REPLACE-WITH-YOUR-BUCKET-NAME"con il nome effettivo del tuo bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::REPLACE-WITH-YOUR-BUCKET-NAME*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::REPLACE-WITH-YOUR-BUCKET-NAME*"
]
}
]
}
- Clicca su Review policy.
- Imposta il nome della policy su
DMS-tutorial-S3-Access-Policy, poi clicca su Create policy.
Step 4: Associa la policy al ruolo IAM
- Nella Console IAM, vai su Roles.
- Cerca “dms-vpc” e seleziona
dms-vpc-role. - Clicca Add permissions > Attach policies.

Figura 25 Gestione delle policy AWS IAM.
- Seleziona
DMS-LAB-S3-Access-Policye clicca Add permissions.
Step 5: Salva l'ARN del ruolo IAM
- Nella pagina di riepilogo di
dms-vpc-role, copia il Role ARN. - Salvalo per usarlo più avanti nella configurazione di AWS DMS.
Creazione degli endpoint di destinazione S3
Ora che il bucket S3 è configurato con le policy e i ruoli appropriati, il passo successivo è creare gli endpoint di destinazione in AWS DMS.
- Apri la Console AWS DMS.
- Clicca su Endpoints nel menu a sinistra.
- Clicca su Create endpoint (angolo in alto a destra).
- Configura l'endpoint di destinazione S3.
- Inserisci i seguenti valori:
- Endpoint Type: Target endpoint
- Endpoint Identifier: S3-target
- Descriptive ARN: Lascia vuoto
- Target Engine: Amazon S3
- Server Name:
<ARN of the dms-vpc-role> - Bucket Name:
<Your S3 Bucket Name> - Bucket Folder:
dmstargetfolder - Clicca Run Test per verificare la connessione.
- Quando il test risulta “Successful”, clicca Create endpoint.
Creazione di un task di migrazione DMS
Step 1: Crea un task di migrazione
- Apri la Console AWS DMS.
- Clicca su Database migration tasks nel menu a sinistra.
- Clicca su Create task (angolo in alto a destra).
Step 2: Configura le impostazioni del task
- Task Identifier:
source-to-AuroraMySQL-target - Replication Instance:
cfn-dmsreplication - Source Database Endpoint: Seleziona il tuo database sorgente
- Target Database Endpoint:
cfn-auroramysqlinstance - Migration Type: Migrate existing data and replicate ongoing changes
- CDC Stop Mode: Don’t use custom CDC stop mode
- Create Recovery Table on Target DB: Non selezionato
- Target Table Preparation Mode: Do nothing (not the default)
- Stop Task After Full Load Completes: Don’t stop
- LOB Column Settings / Include LOB Columns in Replication: Limited LOB mode
- Max LOB Size (KB): 32
- Data Validation: Non selezionato
- Enable CloudWatch Logs: Selezionato
- Log Context: Default levels
- Batch-Optimized Apply: Non selezionato
Step 3: Configura le mappature delle tabelle
- Espandi la sezione Table mappings.
- Seleziona Wizard come modalità di modifica.
- Clicca su Add new selection rule, quindi inserisci quanto segue:
- Schema:
DMS_SAMPLE% - Table Name:
% - Action: Include

Figura 26 Configurazione della mappatura delle tabelle
Step 4: Configura le regole di trasformazione
- Espandi la sezione Transformation rules.
- Clicca su Add new transformation rule e inserisci le seguenti regole:
- Rule 1:
- Target: Schema
- Schema Name:
DMS_SAMPLE - Action: Make lowercase
- Rule 2:
- Target: Table
- Schema Name:
DMS_SAMPLE - Table Name:
% - Action: Make lowercase
- Rule 3:
- Target: Column
- Schema Name:
DMS_SAMPLE - Table Name:
% - Action: Make lowercase
Step 5: Finalizza e avvia il task di migrazione
- Deseleziona Turn on premigration assessment (non richiesto per questo workshop).
- Assicurati che la Migration task startup configuration sia impostata su Start automatically on create.
- Clicca su Create task.
Step 6: Monitora l'avanzamento della migrazione
- Clicca sul task di migrazione (
source-to-s3-target). - Scorri fino a Table Statistics per visualizzare il numero di righe spostate.
- Se lo stato diventa rosso (errore), clicca su View Logs per eseguire il troubleshooting usando i log di CloudWatch.
Best practice per AWS DMS
Ora vediamo alcune best practice da applicare quando migri i dati con AWS DMS.
Ottimizza le prestazioni
Per garantire una migrazione del database efficiente e veloce con AWS DMS, considera le seguenti ottimizzazioni:
- Scegli la dimensione giusta dell'istanza di replica
- Usa un tipo di istanza più grande (ad es.,
dms.r5.largeo superiore) per migrazioni ad alto throughput. - Monitora CPU, memoria e IOPS con CloudWatch e ridimensiona l'istanza se necessario.
- Usa più task di migrazione per l'elaborazione in parallelo
- Dividi migrazioni di grandi dimensioni in più task per gruppi di tabelle per ridurre i tempi di caricamento.
- Migra le tabelle grandi separatamente da quelle piccole per bilanciare le prestazioni.
- Ottimizza le connessioni di rete
- Posiziona l'istanza di replica DMS nella stessa VPC e Availability Zone dei database sorgente e di destinazione.
- Usa endpoint VPC o Direct Connect per una migliore stabilità di rete e minore latenza.
- Ottimizza le impostazioni LOB
- Per i Large Object (LOB), usa il Limited LOB Mode con una dimensione LOB adeguata per ridurre l'impatto sulle prestazioni.
- Abilita il caricamento parallelo e l'applicazione in batch
- Attiva Batch Optimized Apply per inserimenti più rapidi nel database di destinazione.
- Usa Parallel Load per migrazioni su larga scala e processare più tabelle contemporaneamente.
Pianifica il downtime
Ridurre al minimo il downtime durante la migrazione del database è fondamentale per mantenere la continuità operativa. Ecco le strategie chiave per garantire un cutover senza intoppi:
- Migra nei periodi di basso traffico
- Pianifica il cutover nelle ore non di punta per ridurre l'impatto sugli utenti.
- Avvisa in anticipo gli stakeholder per prepararli a eventuali interruzioni temporanee.
- Usa la replica continua (CDC)
- Abilita il Change Data Capture (CDC) per mantenere il database di destinazione sincronizzato con la sorgente.
- Questo permette alle applicazioni di passare al nuovo target con perdita di dati minima.
- Esegui un test di cutover
- Esegui una migrazione di prova in un ambiente di staging prima del cutover finale.
- Valida le prestazioni e risolvi eventuali inconsistenze di schema o dati.
- Riduci l'impatto del cambio DNS
- Prepara una connessione al database basata su DNS in modo che il passaggio al nuovo target sia senza interruzioni.
- Aggiorna le stringhe di connessione dell'applicazione solo quando la migrazione è verificata.
- Mantieni la sorgente in sola lettura prima del cutover finale
- Impedisci nuove transazioni sulla sorgente impostandola in modalità di sola lettura.
- Assicurati che tutte le modifiche in sospeso siano replicate prima di puntare le applicazioni al target.
Metti al sicuro i tuoi dati
La sicurezza dei dati durante la migrazione è fondamentale per proteggere le informazioni sensibili e rispettare i requisiti di conformità.
- Cifra i dati in transito con SSL/TLS
- Abilita SSL/TLS per le connessioni ai database sorgente e di destinazione per prevenire intercettazioni.
- Usa l'autenticazione basata su certificati per una sicurezza aggiuntiva.
- Limita l'accesso con ruoli e policy AWS IAM
- Assegna all'istanza di replica DMS e agli endpoint ruoli IAM con il minimo privilegio necessario.
- Usa policy IAM per limitare l'accesso a specifici database, bucket S3 e log di CloudWatch.
- Abilita la cifratura a riposo
- Usa AWS Key Management Service (KMS) per cifrare i dati su Amazon S3 o RDS.
- Assicurati che il database di destinazione supporti la cifratura per un'archiviazione sicura.
Risoluzione dei problemi con AWS DMS
DMS è uno strumento potente, ma non privo di problemi. Ecco come risolvere quelli più comuni.
Errori comuni e soluzioni
Le migrazioni AWS DMS possono incontrare errori legati alla connettività del database, a incongruenze di schema e a errori di replica.
1. Errori di connessione al database
- Errore: "Failed to connect to database endpoint."
- Soluzione:
- Verifica VPC, security group e impostazioni delle subnet.
- Controlla che il database sia accessibile dall'istanza di replica DMS.
- Assicurati che host, porta e credenziali siano corretti nelle impostazioni dell'endpoint DMS.
- Testa la connettività usando l'opzione "Test Endpoint Connection" nella console DMS.
2. Problemi di compatibilità dei tipi di dati
- Errore: "Unsupported data type conversion between source and target."
- Soluzione:
- Usa AWS Schema Conversion Tool (SCT) per identificare i tipi di dati incompatibili.
- Modifica manualmente i tipi di dati delle colonne nello schema di destinazione se necessario.
- Abilita regole di trasformazione in DMS per convertire automaticamente i tipi incompatibili.
3. Violazioni di vincoli di chiave esterna
- Errore: "Foreign key constraint violation in target database."
- Soluzione:
- Disabilita i vincoli di chiave esterna prima della migrazione e riabilitali al termine.
- Usa "Truncate before load" se ricarichi dati in una tabella esistente.
4. Prestazioni di migrazione lente
- Errore: "Replication lag increasing significantly."
- Soluzione:
- Usa un'istanza di replica DMS più grande (
dms.r5.largeo superiore). - Abilita Parallel Load e Batch Optimized Apply per un'ingestione più rapida.
- Ottimizza le connessioni di rete posizionando DMS, sorgente e target nella stessa VPC.
5. Interruzione imprevista della replica continua (CDC)
- Errore: "CDC task stopped due to missing log files."
- Soluzione:
- Assicura un retention dei log sufficiente sul database sorgente (ad es., 24 ore per Oracle LogMiner).
- Riavvia il task CDC dall'ultima transazione applicata.
Uso dei log DMS per il troubleshooting
AWS DMS fornisce log dei task e integrazione con CloudWatch per aiutarti a identificare e risolvere in modo efficiente i problemi di migrazione.
1. Accesso ai log dei task DMS
- Nella Console AWS DMS, vai su Database Migration Tasks.
- Seleziona il task di migrazione che presenta problemi.
- Clicca su Monitoring per accedere ai messaggi di errore e ai dettagli di esecuzione.

Figura 27 Log AWS CloudWatch con errori di migrazione
2. Uso di AWS CloudWatch per il debugging dettagliato
- Vai su AWS CloudWatch Console > Logs.
- Cerca il gruppo di log dell'istanza di replica DMS (
/aws/dms/replication-instance-ID). - Abilita il verbose logging nelle impostazioni del task DMS per acquisire maggiori dettagli.

Figura 28 Panoramica degli eventi AWS CloudWatch
Conclusione
AWS Database Migration Service (DMS) semplifica lo spostamento dei dati tra diversi motori di database con downtime minimo. Seguendo le best practice — come ottimizzare le prestazioni, mettere al sicuro i dati, gestire le modifiche allo schema e risolvere i problemi più comuni — puoi garantire un processo di migrazione fluido.
Adesso che hai completato una migrazione AWS DMS end-to-end, sei pronto a sfruttare al massimo il tuo nuovo database nel cloud per una migliore scalabilità, analytics e ottimizzazioni cloud-native. Se vuoi approfondire le tue conoscenze su AWS, esplora il percorso di certificazione AWS Cloud Practitioner oppure inizia con AWS Concepts e AWS Security & Cost Management.
Rahul Sharma è un AWS Ambassador, DevOps Architect e blogger tecnico specializzato in cloud computing, pratiche DevOps e tecnologie open source. Con esperienza in AWS, Kubernetes e Terraform, semplifica concetti complessi per chi studia e per i professionisti attraverso articoli e tutorial coinvolgenti. Rahul è appassionato di risolvere le sfide DevOps e di condividere idee per dare forza alla community tech.



Man mano che le organizzazioni procedono alla modernizzazione dell’infrastruttura tramite il cloud, migrare i database su AWS diventa essenziale. AWS offre un potente strumento di migrazione chiamato AWS Database Migration Service (DMS), che consente migrazioni a basso rischio e quasi istantanee da database on-premise, database cloud gestiti in autonomia e altri servizi AWS.
In questo tutorial scoprirai come configurare e usare AWS DMS per le tue esigenze di migrazione dei database. Imparerai:
Iniziamo!
Che cos’è AWS DMS?
AWS Database Migration Service (DMS) semplifica la migrazione dei database su AWS senza tempi di inattività. Supporta migrazioni omogenee e eterogenee, come MySQL verso MySQL o Oracle verso PostgreSQL, rendendolo uno strumento cruciale per le organizzazioni che si spostano sul cloud.
Con AWS DMS puoi:
AWS DMS è ampiamente utilizzato per:
Funzionalità di AWS DMS
AWS DMS offre diverse funzionalità importanti a supporto della migrazione dei database.
1. Migrazioni omogenee ed eterogenee
2. Downtime minimo con Change Data Capture (CDC)
3. Servizio completamente gestito e scalabile
4. Ampia compatibilità con i database
5. Conversione dello schema con AWS SCT
6. Monitoraggio e logging continui
7. Sicurezza e compliance