What should a solutions architect do to ensure the database and snapshots are always encrypted moving forward?
Encrypt a copy of the latest DB snapshot. Replace existing DB instance by restoring the encrypted snapshot.
Create a new encrypted Amazon Elastic Block Store (Amazon EBS) volume and copy the snapshots to it. Enable encryption on the DB instance.
Copy the snapshots and enable encryption using AWS Key Management Service (AWS KMS). Restore encrypted snapshot to an existing DB instance.
Copy the snapshots to an Amazon S3 bucket that is encrypted using server-side encryption with AWS Key Management Service (AWS KMS) managed keys (SSE-KMS).
Explanations:
Encrypting a copy of the latest DB snapshot and replacing the existing DB instance by restoring the encrypted snapshot ensures that both the database and its snapshots will be encrypted going forward. Amazon RDS does not allow you to directly enable encryption on an existing unencrypted DB instance; instead, you must restore from an encrypted snapshot.
Creating a new encrypted Amazon EBS volume and copying snapshots to it does not apply directly to RDS instances. Amazon RDS abstracts the underlying storage, so EBS volume management is not the correct approach. The database itself must be migrated using snapshots.
While copying snapshots and enabling encryption using AWS KMS is a good practice, you cannot simply restore an encrypted snapshot to an existing DB instance. You must create a new RDS instance from the encrypted snapshot, as existing instances cannot be directly encrypted.
Copying the snapshots to an S3 bucket encrypted with SSE-KMS does not encrypt the RDS database itself. This option only addresses the storage of snapshots in S3, but does not ensure that the RDS instance is encrypted, which is the main requirement.