RDS

Select the primary instance in the RDS console.

💡 Read replicas are created from an existing primary instance.

Choose 'Action' and then 'Create Read Replica'.

💡 Initiates the read replica creation process.

Configure the read replica, similar to creating a primary instance.

💡 Define the properties for the new replica.

Specify identifier, size, region (can be cross-region), storage, availability (Single-AZ or Multi-AZ), public access (recommend “No”), and authentication.

💡 These settings define the replica's characteristics and location.

RDS handles snapshotting the primary instance and establishing replication to the replica.

💡 AWS automates the replication setup.

After creation, connect to the new endpoint provided for the read replica.

💡 Each read replica has its own endpoint for read-only access.

Select the desired snapshot or point-in-time from the RDS console.

💡 Identifies the specific recovery point.

Initiate the restore process.

💡 This will create a new DB instance.

Define Instance Configuration for the new instance, just like provisioning a new instance.

💡 Allows setting up the new instance with desired specifications.

Parameter Group and Security Group settings are retained from the original instance by default.

💡 Ensures consistency with the original database's behavior and network access.

Database Creation Process

💡 Initiates and monitors the provisioning of a new database instance.

Configure instance settings (Easy Create or Standard Create) and await 'Creating' -> 'Backing up' -> 'Available' status transitions.

💡 Ensures the database is set up with desired parameters and is ready for use.

Utilize the provided unique connection Endpoint to access the database.

💡 The endpoint is the primary access method for applications and clients.

Modify Database Instances Post-Creation

💡 Adjusts instance parameters as workload or requirements change.

Many parameters can be modified, including engine version (cannot downgrade), password, instance size (vertical scaling), allocated storage, security groups, and deletion protection. Changes can be applied immediately or during the next maintenance window.

💡 Allows for flexible scaling and configuration updates.

Perform Replica Instance Actions

💡 Manages the state and functionality of read replicas.

Read replicas offer a range of actions, including rebooting, deleting, connecting them to EC2/Lambda, promoting them to standalone databases, converting them to Multi-AZ, turning on backups, taking snapshots, and creating associated RDS Proxy or ElastiCache clusters.

💡 Enables flexible management of read scalability and recovery options.

Database Deletion and Cleanup

💡 Removes resources and prevents unexpected costs.

Ensure 'Deletion Protection' is enabled to prevent accidental deletion of production databases. It must be explicitly disabled before the instance can be deleted.

💡 This crucial safety feature prevents accidental deletion.

When deleting, choose whether to retain automated backups and whether to create a final snapshot (recommended for production). Confirmation requires typing 'delete me' and acknowledging the loss of automated backups and point-in-time recovery if not retained.

💡 Provides options for data retention and confirms intent.

If the primary instance is deleted, a read replica can be promoted to become a new standalone primary database, maintaining data availability.

💡 Supports recovery and business continuity.

Delete any manual snapshots directly. System snapshots cannot be deleted directly and are tied to automated backup retention or deleted when the instance is deleted and backups are not retained.

💡 Removes snapshot storage costs.

Follow comprehensive cleanup steps: Delete all database instances, delete any manual snapshots, delete any retained automated backups. Verify the RDS dashboard shows zero instances, snapshots, or active backups.

💡 Ensures no lingering resources incur charges.

Export data from the on-premises database to a logical dump file.

💡 Creates a portable representation of the database schema and data.

mysqldump -u [username] -p[password] [database_name] > [dump_file.sql]

Upload the dump file to Amazon S3.

💡 Provides secure and durable storage for the dump file, accessible from AWS.

aws s3 cp [dump_file.sql] s3://[your-s3-bucket]/[dump_file.sql]

Create a target RDS/Aurora database instance that is compatible with the source engine.

💡 Provisions the AWS managed database where the data will reside.

Restore data from the S3 file using a client tool (e.g., MySQL client from an EC2 instance in the same VPC).

💡 Ingests the data into the newly created RDS/Aurora instance.

mysql -h [rds_endpoint] -u [username] -p[password] [database_name] < [dump_file.sql]

Create an AWS DMS replication instance.

💡 This is a server that performs the actual migration tasks.

Configure source (on-premises database) and target (Aurora/RDS cluster) endpoints in DMS.

💡 DMS needs to know where to read data from and where to write it.

Create and run a migration task: DMS performs a full load and optionally replicates ongoing changes (Change Data Capture - CDC) to keep databases in sync.

💡 Transfers historical data and applies real-time updates.

Optionally configure a VPN connection or Direct Connect for secure, dedicated channels between on-premises and AWS.

💡 Ensures secure and reliable data transfer for the migration.

Once replication is complete, point applications to the new AWS database and perform a cutover.

💡 Switches live traffic to the migrated database.