MariaDB 10.6 to MySQL Aurora 8.0 Migration Guide — 5-Part Series
- Part 1: Pre-Migration Requirements
- Part 2: AWS DMS Infrastructure Setup (You Are Here)
- Part 3: Schema and User Migration
- Part 4: DMS Endpoints, Task Configuration, and Assessments
- Part 5: Execution, Validation, Cutover, and Cleanup
With source and target database requirements verified, the next step is provisioning the AWS DMS infrastructure. This consists of three components: IAM roles that grant DMS the permissions it needs, a replication instance that runs the migration process, and security group rules that allow the replication instance to reach both databases.
Getting the infrastructure right before creating endpoints saves significant troubleshooting time. Most DMS endpoint test failures trace back to security group rules or missing IAM permissions, not the database configuration itself.
IAM Roles for AWS DMS
AWS DMS requires specific IAM roles to manage VPC resources and publish CloudWatch logs. These roles use a trust policy that authorizes the DMS service principal to assume them.
Create the dms-vpc-role
This role grants DMS permission to create and manage network interfaces within your VPC. It is required before creating any replication instance.
- Go to the IAM Console → Roles → Create Role
- Select AWS Service as the trusted entity type
- Under Use cases for other AWS services, select DMS
- Attach the following managed policies:
AmazonDMSVPCManagementRole— allows DMS to manage ENIs and security groups within the VPCAmazonDMSCloudWatchLogsRole— enables CloudWatch logging for replication instances
- Name the role exactly
dms-vpc-role(DMS looks for this exact name) - Create the role
Exact name required: The role must be named dms-vpc-role. AWS DMS looks for this specific role name during replication instance creation. If the role exists under a different name, the console will fail silently when attempting to create a replication instance in a VPC.
Create the dms-cloudwatch-logs-role (Optional)
This role allows DMS to publish task-level logs to Amazon CloudWatch Logs. It is optional but strongly recommended — CloudWatch logs are the primary debugging tool when a migration task encounters errors.
Follow the same steps as dms-vpc-role, attaching the AmazonDMSCloudWatchLogsRole managed policy. Name the role dms-cloudwatch-logs-role.
Create a Replication Instance
The replication instance is the compute resource that runs DMS. It connects to both the source and target databases simultaneously and handles data transformation between the two engines.
Choosing the Instance Class
The right instance class depends on your dataset size, write throughput, and whether your tables have LOB (Large Object) columns.
| Instance Family | Use Case | Notes |
|---|---|---|
t3 | Staging and development | Burstable CPU — suitable for low-throughput workloads and testing. Not recommended for production. |
c7i | Production (compute-optimized) | Good for high-throughput migrations without significant LOB columns. |
r7i | Production with LOB columns | Memory-optimized — recommended when migrating tables with BLOB, TEXT, MEDIUMBLOB, or LONGTEXT columns. LOB processing is memory-intensive. |
LOB columns and instance sizing: If your schema contains LOB columns and you use Full LOB mode (required for complete fidelity), DMS loads each LOB individually after inserting the row. This pattern is memory-intensive and significantly slower than standard row processing. Use r7i instances for workloads with LOBs.
For detailed instance class specifications, refer to the AWS DMS replication instance types documentation.
Instance Configuration
In the DMS console, navigate to Replication instances → Create replication instance and configure:
- Engine version — use the default unless you have a specific reason to pin a version
- Multi-AZ — enable for production to avoid replication instance failure during AZ outage
- Storage — the default allocation is sufficient for most migrations; DMS uses local storage as a temporary buffer during CDC operations
- VPC — select the same VPC as your MariaDB and Aurora instances. If they are in different VPCs, configure VPC peering before proceeding
- Public accessibility — leave unchecked. The replication instance should only communicate within the VPC
- VPC security groups — assign the security group associated with the Aurora cluster (this avoids creating temporary rules and is covered in the next section)
- Automatic version upgrade — disable to prevent unexpected version changes during an active migration
Security Group Configuration
The replication instance must be able to establish TCP connections to port 3306 on both the MariaDB source and the Aurora MySQL target.
MariaDB Source Security Group
Locate the security group attached to the MariaDB RDS instance and add an inbound rule:
- Type: MySQL/Aurora (TCP 3306)
- Source: The security group ID of the DMS replication instance
Also verify the outbound rules of the replication instance's security group allow traffic to the MariaDB instance. By default, AWS security groups allow all outbound traffic, but custom outbound rules may block this.
Aurora MySQL Target Security Group
Apply the same inbound rule to the Aurora cluster's security group:
- Type: MySQL/Aurora (TCP 3306)
- Source: The security group ID of the DMS replication instance
Additionally, add an inbound rule allowing access from the jump server's security group on port 3306. This is needed for the schema import step in Part 3 and for running validation queries during cutover.
Why a jump server? RDS and Aurora instances are typically deployed in private subnets with no direct internet access — this is the recommended security posture for production databases. A jump server (also called a bastion host) is an EC2 instance in a public subnet that you SSH into, then connect to the database from there. If your project does not have a jump server in place, you have a few alternatives: launch a temporary EC2 bastion in the same VPC, use AWS Systems Manager Session Manager to tunnel without a public instance, or use AWS Cloud9. Whichever method you use, its security group needs the inbound rule on port 3306 added to the Aurora SG.
Security Group Rule Summary
| Security Group | Rule Direction | Protocol / Port | Source / Destination |
|---|---|---|---|
| MariaDB SG | Inbound | TCP 3306 | DMS replication instance SG |
| Aurora SG | Inbound | TCP 3306 | DMS replication instance SG |
| Aurora SG | Inbound | TCP 3306 | Jump server SG |
| DMS SG | Outbound | TCP 3306 | MariaDB SG (verify not blocked) |
| DMS SG | Outbound | TCP 3306 | Aurora SG (verify not blocked) |
Testing connectivity before continuing: Before proceeding to endpoint creation in Part 4, verify that the replication instance can reach both databases. Use the endpoint connection test built into the DMS console — it surfaces security group and network issues early, before a failed migration task consumes time troubleshooting mid-run.
With the replication instance provisioned and security groups in place, proceed to Part 3 to handle schema and user migration before any DMS data tasks run.