Vai al contenuto principale

AWS DMS Tutorial: guida passo passo alla migrazione dei database

Questo tutorial ti guida nella configurazione e nell'uso di AWS DMS per migrare database su AWS, ottimizzare le prestazioni e risolvere i problemi.
· 15 min leggi

Scopri con l'IA

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:

  • Come funziona AWS DMS e le sue funzionalità chiave.
  • Il processo passo passo per configurare ed eseguire una migrazione.
  • Best practice per ottimizzare prestazioni, sicurezza e costi.
  • Tecniche di troubleshooting per risolvere i problemi di migrazione più comuni.

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:

  • Usare il Change Data Capture (CDC) per migrare i dati in modo continuo causando scarse o nulle interruzioni all’ambiente di produzione.
  • Lasciare che AWS DMS automatizzi e gestisca i task di migrazione senza richiedere conoscenze specialistiche sui tuoi database.
  • Replicare i dati verso servizi come Amazon RDS, Aurora, Redshift, DynamoDB, S3, ecc.

AWS DMS è ampiamente utilizzato per:

  • Migrazioni lift-and-shift di database da on-premise ad AWS.
  • Replica cross-region dei database per il disaster recovery.
  • Consolidamento dei dati migrando più database in un data warehouse.

Funzionalità di AWS DMS

AWS DMS offre diverse funzionalità importanti a supporto della migrazione dei database. 

1. Migrazioni omogenee ed eterogenee

  • Migrazione omogenea: trasferimento da un tipo di database a un altro uguale (ad es., MySQL verso MySQL). 
  • Migrazione eterogenea: conversione di schema e dati tra motori diversi (ad es., Oracle verso PostgreSQL).

2. Downtime minimo con Change Data Capture (CDC)

  • Il Change Data Capture (CDC) monitora in tempo reale le modifiche nel database di origine e trasferisce tali cambiamenti al database di destinazione, riducendo così i tempi di inattività.
  • Adatto per aziende che eseguono applicazioni critiche e richiedono accesso ai dati senza interruzioni. 

3. Servizio completamente gestito e scalabile

  • AWS DMS crea e gestisce le risorse, monitora le prestazioni e gestisce i casi di failover.
  • Supporto Multi-AZ per alta disponibilità.

4. Ampia compatibilità con i database

  • Database di origine: Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, Amazon Aurora e altri.
  • Database di destinazione: Amazon RDS, Aurora, Redshift, DynamoDB, S3 e OpenSearch.

5. Conversione dello schema con AWS SCT

  • AWS Schema Conversion Tool (SCT) aiuta a convertire gli schemi dei database durante le migrazioni eterogenee.
  • Trasforma automaticamente stored procedure, view e trigger per adattarli al database di destinazione.

6. Monitoraggio e logging continui

  • L’integrazione con AWS CloudWatch ti consente di monitorare l’avanzamento della migrazione e individuare i colli di bottiglia.
  • Registra statistiche dettagliate di migrazione, inclusi tassi di errore, latenza e lag di replica.

7. Sicurezza e compliance

  • Supporta la crittografia TLS per un trasferimento sicuro dei dati.
  • Si integra con AWS IAM per un controllo degli accessi granulare.
  • Conforme ai principali standard di sicurezza, inclusi HIPAA, PCI DSS e SOC.

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

  1. Accedi alla AWS Management Console usando le tue credenziali.
  2. Clicca sul menu a tendina in alto a destra e seleziona la tua regione. Per questo tutorial selezionerò la regione N. Virginia.

La Console di gestione AWS con il menu a tendina di selezione della regione aperto, che mostra varie regioni disponibili

Figura 1 Selezione della regione AWS nella AWS Management Console.

  1. Vai alla Console EC2 e apri la sezione Key Pair. Assicurati di essere nella stessa regione AWS dello step precedente.
  2. Clicca su Create Key Pair e chiamala “DMS”.

Interfaccia AWS EC2 che mostra la pagina di creazione della key pair con opzioni RSA ed ED25519.                                        

Figura 2 Creazione di una key pair per l’accesso sicuro in AWS EC2.

  1. Clicca su Create e il browser scaricherà DMS.pem.
  2. 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.

  1. Apri la console AWS CloudFormation e clicca Create Stack.
  2. Seleziona Choose an existing template, poi scegli Upload a template file.

Interfaccia AWS CloudFormation con l’opzione per caricare un file template per la creazione dello stack.

Figura 3 Caricamento di un template CloudFormation per creare un nuovo stack.

  1. Scarica il file da Github Gist e clicca Choose file.
  2. Carica il file DMS.yaml e clicca Next.
  3. Compila i parametri richiesti come indicato, quindi clicca Next.

Pagina di configurazione dello stack CloudFormation con parametri per la migrazione del database, configurazione EC2 e impostazioni di rete

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’è.

  1. Nella pagina Stack Options, mantieni le impostazioni predefinite e clicca Next.
  2. Rivedi la configurazione e clicca Create stack.
  3. Verrai reindirizzato alla console CloudFormation, dove lo stato mostrerà “CREATE_IN_PROGRESS”. Attendi finché non passa a “CREATE_COMPLETE”.

Elenco risorse di CloudFormation che mostra ID logici e fisici con stato

Figura 5  Verifica dello stato di creazione delle risorse in AWS CloudFormation

  1. 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.

Pagina di configurazione del security group AWS che mostra le regole in ingresso per l’accesso al database e RDP.

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.

Interfaccia AWS EC2 che mostra il campo di caricamento della chiave privata per decrittare la password dell’amministratore.

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.

Interfaccia di Oracle SQL Developer che mostra una finestra di configurazione connessione con tipo di database, hostname, porta e campi credenziali.

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.

Esecuzione di script SQL in Oracle SQL Developer, con supplemental logging e modifiche alle tabelle

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

Interfaccia di MySQL Workbench che mostra la configurazione di una nuova connessione con hostname, porta, username e password.

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.

AWS Schema Conversion Tool che mostra un avviso di connessione riuscita dopo il test di connettività al database Oracle.

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:

Assessment report di AWS Schema Conversion Tool che riassume le azioni di conversione e la compatibilità degli oggetti di storage.

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_SAMPLE nel 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_SAMPLE nel pannello a sinistra.
  • Seleziona Convert Schema per generare le istruzioni DDL del database di destinazione.
  • Quando richiesto sugli oggetti esistenti, clicca Yes.

AWS Schema Conversion Tool che mostra le strutture dei database Oracle e MySQL con un prompt per sostituire gli oggetti

Figura 13 Conversione di uno schema Oracle con AWS Schema Conversion Tool.

  • Clic destro sullo schema dms_sample_dbo (origine SQL Server) o dms_sample (altre origini) nel pannello di destra.
  • Seleziona Apply to database.
  • Quando richiesto, clicca Yes per confermare.
  • Espandi lo schema dms_sample_dbo o dms_sample nel 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

Creazione di una replication instance

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, DMSReplication o l’istanza di replica che hai creato (se pronta)
  • Clicca Run Test per verificare la connettività.

verify connectivity

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, DMSReplication o 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.

Interfaccia di MySQL Workbench che mostra query SQL

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

La sezione Configure table mapping mostra varie regole applicabili

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.

Immagine che mostra lo stato della migrazione dei dati

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.

Grafici di monitoraggio AWS CloudWatch che mostrano l’andamento di CPU, memoria e memoria disponibile.

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à.

AWS CloudWatch che mostra larghezza di banda del full load e metriche di trasferimento righe.

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.

Riepilogo di validazione AWS DMS che mostra nessuna validazione in sospeso, fallita o sospesa.

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.

Arresto dell’attività di migrazione AWS DMS

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.

Eliminazione degli endpoint AWS DMS

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).

Interfaccia AWS che richiede conferma per eliminare uno stack CloudFormation.

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.

Interfaccia di gestione dei permessi AWS IAM con policy associate

Figura 25 Gestione delle policy AWS IAM.

  • Seleziona DMS-LAB-S3-Access-Policy e 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

Configura la mappatura delle tabelle

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.large o 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.large o 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.

Log AWS CloudWatch che mostrano errori e avvisi relativi alla migrazione DMS.

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.

AWS CloudWatch che mostra eventi di log dettagliati per un task di migrazione.

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

Autore

Rahul Sharma

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.

Argomenti

Correlato