AWS Database Blog
Migrate to the MySQL-compatible edition of Amazon Aurora while protecting personal data using encryption
Security is a top priority at AWS, and the same is true for our customers. We spend a significant amount of resources protecting personal data and are constantly enhancing our capabilities to make data protection easier for our customers. All AWS services including the MySQL-compatible edition of Amazon Aurora comply with the European Union’s General Data Protection Regulation (GDPR). For more details, see the General Data Protection Regulation (GDPR) Center on the Amazon website.
As one of our key data storage and processing services, the MySQL-compatible edition of Amazon Aurora offers a wide range of encryption and data access control options. These are designed to make it easier for you to protect personal data stored within the service. Data protection responsibilities aren’t limited to just ongoing operations, but also encompass data movement and migration activities.
Customers today are taking a closer look at how they protect personal data and are also reassessing what data they store and process. This often results in the decision to migrate their data to encrypted databases, and also transport their data in an encrypted form. In this blog post, I discuss some of the broad patterns to execute secure migrations to MySQL-compatible edition of Amazon Aurora, and the service features that enable them.
Encrypted data storage and processing capabilities of MySQL-compatible edition of Amazon Aurora
MySQL-compatible edition of Amazon Aurora provides several features to enable customers to store and process personal data using encryption:
- Amazon Aurora allows you to encrypt your databases using keys you manage through AWS Key Management Service (AWS KMS). With encryption enabled in an Amazon Aurora database, data stored at rest, automated backups, and snapshots are encrypted.
- With the MySQL-compatible edition of Amazon Aurora, you can establish encrypted connections to your database instances, and even force clients to use encrypted connections.
- You can create a new encrypted Aurora cluster from a snapshot of an unencrypted cluster by specifying the desired AWS KMS master key at the time of the restore. You can also encrypt a cluster snapshot, by copying and providing a KMS master key.
- You can restore an Aurora cluster from Amazon S3 hosted database backup files that are KMS encrypted from source databases running MySQL 5.5 and 5.6 versions.
- You can configure encrypted replication using binary logs (binlogs) from external MySQL source databases to Aurora clusters in order to minimize downtime during migrations.
- You can also create an encrypted Aurora cluster read replica for an Amazon RDS MySQL DB instance. In this use case, the logical, binary log replication traffic between the RDS MySQL source database instance and the Aurora cluster is encrypted automatically using TLS.
- The AWS Database Migration Service (AWS DMS) provides several mechanisms to secure data both in transit and at rest.
You can use these features together to migrate your data to MySQL-compatible edition of Amazon Aurora, while protecting the data both during transit and encrypting the data at rest on the destination. If your source database is also encrypted, you can achieve full end-to-end encryption for data migrations. With these features, you can perform a migration with minimal downtime, using replication to catch up with changes.
Common encrypted migration patterns
There are several migration mechanisms you can use, based on the capabilities preceding. 
The methodologies represented in the workflows preceding are similar whether you decide to encrypt or not. Using encryption might add a few additional steps in some cases. But more important is the starting point—where you are migrating from.
1. Migrating from self-managed MySQL databases
When you migrate from a self-managed MySQL database, whether it’s external to AWS or hosted on Amazon EC2, we recommend migrating using physical database backup files. We recommend this process because it’s typically faster than using logical export and import.
We support migrations using XtraBackup files uploaded into Amazon S3. Once the backup files are generated, you can upload them to S3 using TLS encrypted data transfers. You then can store them in S3 buckets in encrypted form, using server-side encryption (SSE). From there, given the correct permissions to the S3 objects and access to the relevant KMS encryption keys, Amazon Aurora can restore your backups into a new cluster.
The step-by-step migration process with Amazon S3-based backup files is described in our documentation.
At present, we don’t provide a managed experience for migrations from source databases running MySQL 5.7 or higher using XtraBackup files. For these use cases, or in case you can’t use backup files for other reasons, you can use logical database exports and then import them into a new Aurora cluster.
Regardless of how you perform the initial data load, to implement a reduced downtime migration you should enable encrypted binary log replication. Using this approach, you can catch up your Aurora cluster with any changes that have occurred in the meantime on the source before cutting over. To do this, you might need to reconfigure your source MySQL database for binary log replication, and you need to generate keys that Aurora can use to connect to the source securely. After you have the key material generated on the source database, you import it to the Aurora cluster using the following stored procedure:
2. Migrating using AWS DMS from MySQL or other database engines
AWS DMS helps you migrate databases to Amazon Aurora quickly and securely. The source database remains fully operational during the migration, minimizing downtime to applications that rely on the database. AWS DMS can migrate your data from most widely used commercial and open-source databases. You can also use AWS DMS as an alternative for migrations from self-managed MySQL databases, if you can’t use physical backups or logical database exports as described preceding.
Working with AWS DMS requires that you configure your source database to use encrypted connections and enable the appropriate features for your source database engine to perform change data capture.
To use DMS, import the desired SSL certificates for the source and target databases. Then create a source endpoint and target endpoint for your source database and new Aurora cluster respectively. Be sure to enable the relevant SSL mode for the connection and configure the KMS master key to use for encrypting the replication storage.
Beyond the encryption-specific settings, the workflow follows the DMS migration walkthroughs in our documentation, available for the most popular source database engines.
3. Migrating from Amazon RDS MySQL DB instances
The encrypted migration workflow for moving from an Amazon RDS MySQL DB instance, whether the source is encrypted or not, is simpler to manage. You can create an Amazon Aurora cluster that acts as a read replica for the source database using a few simple clicks in the AWS Management Console. Alternatively, you can do this by using commands in the AWS CLI or by calling the Amazon RDS API using the SDKs. You can instruct AWS to encrypt your read replica part of the provisioning process. Binary log replication from your source Amazon RDS MySQL DB instance is configured automatically to use TLS encryption.
The steps following illustrate the process using the AWS Management Console:
- From the RDS Instances list, select the desired MySQL DB instance, choose Instance Actions, and choose Create Aurora read replica.
- On the configuration screen, make sure to enable encryption in the Encryption section, along with the other parameters specific to your environment. Select the desired KMS master key to use and choose Create read replica at the bottom of the configuration screen.
- Once the replica has been created, has caught up with the source, and you are ready to cut over, simply promote the Aurora read replica to a standalone cluster and begin using it.
4. Migrating from unencrypted Amazon Aurora database clusters
If you are already operating Amazon Aurora database clusters, but want to encrypt them for added data security or to meet compliance requirements, you can do so by using snapshots. Take a manual snapshot of the database cluster, and then provision a new database cluster with encryption enabled and using the desired KMS master key based on that snapshot.
You can also set up binlog replication manually between two Aurora clusters using the step-by-step instructions available in our documentation. However, this replication configuration does not support encryption.
Summary
You have several migration paths available to encrypt your database workloads, or migrate to encrypted Amazon Aurora database targets. For workloads containing sensitive data, you can ensure that your data stays encrypted end-to-end during the migration process.
To ensure the best results, you should test the selected migration process thoroughly and ensure that you have a way to roll back, if any of the migration steps fail. For more comprehensive guidance on migrating workloads to MySQL-compatible edition of Amazon Aurora, review the Amazon Aurora Migration Handbook.
About the Authors
Vlad Vlasceanu is a specialist solutions architect at Amazon Web Services. He works with our customers to provide guidance and technical assistance on database projects, helping them improving the value of their solutions when using AWS.
Chayan Biswas is a product manager at Amazon Web Services.