Mastering AWS Database Migration: AWS DMS and AWS SCT

This study guide covers the essential tools used in the Migrate Phase of the AWS Cloud Adoption Framework, specifically focusing on the AWS Schema Conversion Tool (SCT) and AWS Database Migration Service (DMS).

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between homogeneous and heterogeneous database migrations.
• Explain the role of AWS SCT in converting schemas and application code.
• Describe the architectural components of AWS DMS (Replication Instance, Endpoints, Tasks).
• Determine when to use SCT versus DMS for a given migration scenario.
• Identify security best practices for data at rest and in transit during migration.

Key Terms & Glossary

• AWS SCT (Schema Conversion Tool): A Java-based UI tool used to convert database schemas from a source engine to a different target engine.
• AWS DMS (Database Migration Service): A managed service used to migrate data from a source datastore to a target datastore in the AWS cloud.
• Homogeneous Migration: A migration where the source and target database engines are the same or compatible (e.g., Oracle to Oracle).
• Heterogeneous Migration: A migration where the source and target database engines are different (e.g., Oracle to Amazon Aurora).
• Replication Instance: A managed EC2 instance that runs the DMS replication software to move data.
• Endpoints: Connection information (credentials, host, port) used by DMS to connect to source and target datastores.

The "Big Idea"

Database migration is rarely a single-click event. It is a two-step orchestration: Schema First, Data Second. If you are changing database engines, you must first "translate" the language of the database (SCT) before you can move the "words" (DMS). Together, these tools minimize downtime and ensure data integrity across environments.

Formula / Concept Box

Hierarchical Outline

• I. The Assess & Convert Phase (SCT)
  • Automation: Automates conversion of views, stored procedures, and functions.
  • Assessment Report: Highlights manual interventions needed for code that cannot be auto-converted.
  • Application Scanning: Scans application code for embedded SQL to ensure compatibility.
• II. The Migrate Phase (DMS)
  • Connectivity: Uses Source Endpoints and Target Endpoints.
  • Execution: Migration activities are defined as Tasks.
  • Flexibility: Supports full-load (one-time) or ongoing replication (Sync).
• III. Security and Auditing
  • Encryption: KMS for at-rest; SSL/TLS for in-transit.
  • Monitoring: API calls tracked via AWS CloudTrail.

Visual Anchors

Migration Workflow Logic

AWS DMS Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, rounded corners, minimum height=1cm, text centered}] \node (source) {Source DB}; \node (endpointS) [right of=source, xshift=1cm] {Source Endpoint}; \node (rep) [right of=endpointS, xshift=1.5cm, fill=orange!20] {\begin{tabular}{c} DMS Replication \ Instance \end{tabular}}; \node (endpointT) [right of=rep, xshift=1.5cm] {Target Endpoint}; \node (target) [right of=endpointT, xshift=1cm] {Target DB};

\end{tikzpicture}

Definition-Example Pairs

• Replatforming: Changing the database platform while keeping the core schema mostly intact.
  • Example: Moving a self-managed MySQL database on EC2 to Amazon Aurora MySQL.
• Refactoring: Changing the database engine entirely, requiring schema transformation.
  • Example: Moving a legacy on-premises IBM Netezza data warehouse to Amazon Redshift.
• Change Data Capture (CDC): Capturing ongoing changes from the source while the migration is in progress.
  • Example: A retail database remains live for customers while DMS streams new orders to the AWS target in real-time.

Worked Examples

Scenario: Migrating Oracle (On-Premise) to Amazon Aurora PostgreSQL

1. Step 1: Assessment (SCT). Download and run SCT. Connect to the local Oracle instance. Generate a Modernization Report. SCT identifies that 85% of stored procedures convert automatically, but 15% use Oracle-specific packages that need manual rewriting.
2. Step 2: Schema Application (SCT). Apply the converted schema to an empty Aurora PostgreSQL instance. SCT creates the tables, indexes, and converted functions.
3. Step 3: Replication Setup (DMS). Create a DMS Replication Instance. Define the Source Endpoint (On-prem Oracle) and Target Endpoint (Aurora PG).
4. Step 4: Task Execution (DMS). Create a migration Task. Select "Full load + ongoing replication."
5. Step 5: Cutover. Monitor the DMS task until the latency between source and target is near zero. Stop application traffic, let final changes sync, then point application to Aurora.

Checkpoint Questions

1. Which tool would you use to scan application code for embedded SQL statements?
2. True or False: DMS handles the conversion of stored procedures during a heterogeneous migration.
3. What component of DMS is actually an EC2 instance under the hood?
4. How does DMS ensure security for data moving from an on-premises data center to AWS?

[!NOTE] Answers: 1. AWS SCT; 2. False (SCT handles procedures); 3. The Replication Instance; 4. Using SSL/TLS for in-transit encryption.

Muddy Points & Cross-Refs

• When to skip SCT? If you are doing a Rehost (Homogeneous) migration (e.g., SQL Server to SQL Server on RDS), SCT is usually unnecessary as the schema is already compatible. Use native tools or DMS directly.
• Large Objects (LOBs): DMS handles LOBs differently depending on the task settings (Limited LOB mode vs. Full LOB mode). This often affects performance.
• DMS vs. Snowball: For multi-terabyte migrations, consider using AWS Snowball Edge in conjunction with DMS to avoid network bottlenecks.

Comparison Tables