Learn how to describe multiple use cases for AWS Database Migration Service.
- [Narrator] Chances are if you're interested in cloud data storage, you're not starting from scratch, you've already got a significant amount of data on premises in your local data center or co-location and you're wondering how to get it to the cloud. Maybe you've been running a relational database, or two or three, for years, and you're ready to let AWS take over the operational details by migrating to RDS. Perhaps you've been running my-sequel and you're interested by the performance enhancements promised by Aurora, or maybe you have some new architectural goals and just want to switch database engines. How do you get from here to there? Well, you have a number of do it yourself options.
You can use native tools, such as Oracle's Data Pump, but these tools are often geared toward homogenous transfers and not for migrating from one platform to another. You could use your database's export tools to export data and schemas to sequel scripts and run them. But again, changing engines would mean you're responsible for translating the resulting output into a syntax suitable for your destination. The files can also be quite large at which point you're met with the challenges of getting 'em to the cloud in the first place. Finally, you could export your data in some other format, such as CSV but then it's all on you to write import scripts that will work with your destination platform.
That's where the Database Migration Service comes in. AWS has essentially abstracted away the details of a number of existing migration tools and created a service that gives you a single interface for moving data from one database to another. DMS can do one time or continuous data migrations to and from a variety of relational and no-sequel databases. It can even move data to S3. Let's take a look at how this works. The key component of a Database Migration Service task is the replication instance.
The replication instance is an EC2 virtual machine provisioned by DMS. This host must be able to access both your source and target databases on the respective service boards. For example, port 5432 for Postgres. The replication instance runs migration tasks, moving relational data from your source database to the target. This process can be a one time event or you can keep the instance and use it as a persistent replication engine. Just be aware that as long as the replication instance is running, you will incur the cost of that EC2 host, which varies based on the sizing you choose.
The two sides of the migration can both be in AWS, or they can be local on premises databases. The AWS side can be an RNES database, a database running on EC2, a no-sequel database like Mongo or Dynamo, or even S3. This means that you can set up a migration from a local DBMS to a database in AWS, giving you yet another way to move data to the Amazon Cloud. When you're ready to go cloud-native you can just point your applications to the remote database, decommission your old one on premises, and terminate the replication instance.
Of course, if your target is RDS, you can easily set it up with a read replica or multi-AZ functionality, to keep that high availability you get from having multiple copies of your data. The data stored on the replication instance itself is encrypted with an AMS key management service key of your choosing. It can be one auto-generated for DMS, or it can be one you've created on your own. If you upload your own SSL certificate, you can also encrypt the traffic to and from the source and target. The other great thing about Data Migration Service, as I've implied, is that it not only gives you a way to move data to AWS, it also makes it possible to migrate to a different database engine than the one you're currently using.
This is called a heterogeneous migration. AWS provides documentation that makes clear exactly what conversions are supported. This includes many transactional databases. For instance, you can migrate a sequel server 2008 or newer database to Aurora, my-sequel, another sequel server, or Postgres. Plus, you can migrate many different data warehouse platforms into Redshift. Take a look at AWS's documentation to see what moves are possible. AWS also provides a lot of specific detail on the use of each database platform as both a source and target.
Be sure to read the documentation carefully to make sure you understand the nuances of the migration you're beginning to undertake with DMS. To summarize, let's look at the key concepts behind Database Migration Service. First, you'll create a replication instance to connect to both databases and execute the actual data migration. Second, you'll establish endpoints, which is just another way of saying you'll set up the connection information on both sides. Third, you'll create a migration task, which can be set up as either a one time or continuous migration.
Finally, within a task, you can set up simple transformations, such as filtering out certain tables or schemas. Let's head to the AWS console and try all this out.
Join AWS architect Brandon Rich and learn how to configure object storage solutions and lifecycle management in Simple Storage Service (S3), a web service offered by AWS, and migrate, back up, and replicate relational data in RDS. Find out how to leverage flexible network storage with Elastic File System (EFS), and use the new AWS Glue service to move and transform data. Plus, learn how Snowball can help you transfer truckloads of data in and out of the cloud.
- What is data management?
- AWS S3 basics
- S3 bucket creation
- S3 upload and logging
- S3 event notifications
- S3 data lifecycle configuration
- Working with Amazon Elastic Block Store volumes
- Creating and mounting an EFS
- Creating an AWS RDS instance
- RDS backup and recovery
- Moving data with AWS Database Migration Service
- Moving data with Data Pipeline and Glue