How can the security team resolve the noncompliance with the LEAST disruption of application availability for the end users?
Use AWS Database Migration Service (AWS DMS) with full load and change data capture (CDC) between the noncompliant database and a new database with storage encrypted. When full load is finished, cut over any application endpoints to the new encrypted database.
Create a snapshot of the noncompliant DB instance. Make a copy of the snapshot in the same AWS Region with encryption configured. Restore the snapshot as a new DB instance. Cut over any application endpoints to the newly restored database.
Deploy a patch to the application to stop writing to the noncompliant database. Enable storage encryption by using the AWS CLI. Patch the application again to restore writing to the database.
Add a read replica to the noncompliant DB instance. Enable storage encryption on the read replica. When the read replica is available, cut over from the writer DB instance to the read replica. Delete the unencrypted DB instance after the cutover.
Explanations:
Using AWS DMS with full load and change data capture (CDC) allows seamless migration with minimal downtime, maintaining continuous data sync between the original and new encrypted databases. Endpoint cutover is smooth, reducing disruption to users.
While snapshot creation and restoration with encryption would encrypt the database, the process involves downtime during snapshot copying, restoration, and endpoint redirection, which disrupts application availability.
AWS RDS does not support enabling encryption on an existing unencrypted database directly. This approach is not feasible without migrating to a new encrypted instance, making this option invalid.
Adding a read replica with encryption does not resolve the issue, as read replicas do not support conversion to the primary instance. Also, read replicas are only for read traffic, limiting write operations and affecting availability.