AWS Database Migrations
• Save time and cost by migrating to fully managed databases
• Managing databases to run at scale, with high availability and reliability is difficult, time consuming and expensive.
• AWS provides a portfolio of fully managed, high performance, and cost effective databases that can help. With AWS Database Migration Service, you can migrate your databases and data warehouses to AWS with no downtime. Get help from migrations experts from AWS Professional Services and the AWS Partner Network, and leverage the Migration Acceleration Program to accelerate your database migrations to AWS.
• More organizations run their databases and data warehouses on AWS than anywhere else. Customers like NASDAQ, Verizon, TIBCO, Expedia, US Dept. of Veterans Affairs, Snapchat, and Tinder run their business critical database workloads on AWS.
Database Migration – Types
1. Homogeneous Database Migrations
• In homogeneous database migrations, the source and target database engines are the same or are compatible like Oracle to Amazon RDS for Oracle, MySQL to Amazon Aurora, MySQL to Amazon RDS for MySQL, or Microsoft SQL Server to Amazon RDS for SQL Server. Since the schema structure, data types, and database code are compatible between the source and target databases, this kind of migration is a one step process. You create a migration task with connections to the source and target databases, then start the migration with the click of a button. AWS Database Migration Service takes care of the rest. The source database can be located in your own premises outside of AWS, running on an Amazon EC2 instance, or it can be an Amazon RDS database. The target can be a database in Amazon EC2 or Amazon RDS.
2. Heterogeneous Database Migrations
• In heterogeneous database migrations the source and target databases engines are different, like in the case of Oracle to Amazon Aurora, Oracle to PostgreSQL, or Microsoft SQL Server to MySQL migrations. In this case, the schema structure, data types, and database code of source and target databases can be quite different, requiring a schema and code transformation before the data migration starts. That makes heterogeneous migrations a two step process. First use the AWS Schema Conversion Tool to convert the source schema and code to match that of the target database, and then use the AWS Database Migration Service to migrate data from the source database to the target database. All the required data type conversions will automatically be done by the AWS Database Migration Service during the migration. The source database can be located in your own premises outside of AWS, running on an Amazon EC2 instance, or it can be an Amazon RDS database. The target can be a database in Amazon EC2 or Amazon RDS.
3. Development & Test
• AWS Database Migration Service can be used to migrate data both into and out of the cloud for development purposes. There are two common scenarios. The first is to deploy development, test or staging systems on AWS, to take advantage of the cloud’s scalability and rapid provisioning. This way, developers and testers can use copies of real production data, and can copy updates back to the on-premises production system. The second scenario is when development systems are on-premises (often on personal laptops), and you migrate a current copy of an AWS Cloud production database to these on-premises systems either once or continuously. This avoids disruption to existing DevOps processes while ensuring the up-to-date representation of your production system.
4. Database Consolidation
• You can use AWS Database Migration Service to consolidate multiple source databases into a single target database. This can be done for homogeneous and heterogeneous migrations, and you can use this feature with all supported database engines. The source databases can be located in your own premises outside of AWS, running on an Amazon EC2 instance, or it can be an Amazon RDS database. The sources databases can also be spread across different locations. For example, one of the source databases can be in your own premises outside of AWS, while the second one in Amazon EC2, and the third one is an Amazon RDS database. The target can be a database in Amazon EC2 or Amazon RDS.
5. Continuous Data Replication
• You can use AWS Database Migration Service to perform continuous data replication. Continuous data replication has a multitude of use cases including Disaster Recovery instance synchronization, geographic database distribution and Dev/Test environment synchronization. You can use DMS for both homogeneous and heterogeneous data replications for all supported database engines. The source or destination databases can be located in your own premises outside of AWS, running on an Amazon EC2 instance, or it can be an Amazon RDS database. You can replicate data from a single database to one or more target databases or data from multiple source databases can be consolidated and replicated to one or more target databases.
Database Migration – Common Use Cases
1. Oracle & MS SQL Server to Amazon Aurora
• Amazon Aurora is a fully managed, MySQL and PostgreSQL compatible relational database built for the cloud, that combines the performance and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Aurora is up to five times faster than standard MySQL databases and three times faster than standard PostgreSQL databases. It provides the security, availability, and reliability of commercial-grade databases at 1/10th the cost.
2. Cassandra & MongoDB to Amazon DynamoDB
• Amazon DynamoDB is a fully managed, multi-region, multi-master database that provides consistent single-digit millisecond latency, and offers built-in security, backup and restore, and in-memory caching. DynamoDB automatically scales throughput up or down, and continuously backs up your data for protection. DynamoDB gives your globally distributed applications fast access to local data by replicating tables across multiple AWS Regions.
3. Teradata to Amazon Redshift
• Amazon Redshift is a fast, scalable data warehouse that makes it simple and cost-effective to analyze all your data across your data warehouse and data lake. Redshift delivers ten times faster performance than other data warehouses. You can setup and deploy a new data warehouse in minutes, and run queries across petabytes of data in your Redshift data warehouse, and exabytes of data in your data lake built on Amazon S3.
4. Oracle & MS SQL Server to Amazon RDS
• Amazon Relational Database Service (Amazon RDS) is a managed relational database service with a choice of six popular database engines. RDS makes it easy to set up, operate, and scale a relational database in the cloud with just a few clicks. It provides cost-efficient and resizable capacity while automating time-consuming administration tasks such as hardware provisioning, database setup, patching and backups.
Database Migration – Links & Downloads
Database Migration – Links
• DB-Engines.com – Rankings
• Over 350,000 Databases Migrated To AWS
• AWS Prescriptive Guidance – Migration Strategy for RDBMS – 2021
AWS Migration White Paper – Downloads
• AWS Migration Prescriptive Guidance – 2020
• AWS Best Practices Migrating Apps with Databases – 2019
• AWS Migrating Oracle Database Workloads to Oracle Linux on AWS – 2020
• AWS Best Practices Migration Database Migration Service – 2016
• AWS Migration Professional Services – 2018
Oracle to PostgreSQL Migration – eBook Downloads
• eBook – Why & How & to Migrate from Oracle to PostgreSQL
• eBook – Don’t Let Oracle HA Features Stop You from Migrating to PostgreSQL
AWS Migration Step-by-step Guide – Links
• Step-by-step Guide – Migrate from Oracle to Amazon Aurora
• Step-by-step Guide – Migrate from Oracle to Amazon Redshift
AWS Database Migration Playbook – Links
• AWS Database Migration Service Resources
• The Database Migration Playbook has Landed – Blog Apr 2018
• Migrate from Microsoft SQL Server to Amazon Aurora MySQL – Blog Dec 2018
• Best Practices for Migrating an Oracle Database to Amazon RDS PostgreSQL or Amazon Aurora PostgreSQL: Migration Process & Infrastructure Considerations – Blog Nov 2018