# Ensure RDS instance storage is encrypted - Source: https://support.icompaas.com/support/solutions/articles/a_1793292220192904-ensure-rds-instance-storage-is-encrypted - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that every Amazon RDS DB instance has storage encryption at rest enabled, so that StorageEncrypted is true. Every DB instance, including read replicas, is evaluated on its own StorageEncrypted setting; DB snapshots are evaluated by a separate check, and automated backups are not examined. When encryption is enabled on an instance, AWS KMS keys also protect its automated backups, snapshots, read replicas and logs. **Rationale** Without encryption at rest, database files, automated backups and snapshots are stored unencrypted. Anyone who gains access to copied snapshots, shared backups or the underlying storage can read the data, leading to loss of confidentiality and large-scale data exposure. Encrypting DB instances, preferably with customer managed KMS keys whose use is restricted and monitored, adds a layer of protection that is independent of database permissions. **Impact** - Protects data at rest, including backups, snapshots and read replicas - Customer managed KMS keys allow control and auditing of who can use the data - Encryption cannot be turned on for an existing instance; a new encrypted instance must be created from a snapshot, which requires a cutover with downtime or a data migration - The new instance has a new endpoint unless it is given the same identifier after the old one is renamed or deleted **Default Value** Encryption at rest is chosen when a DB instance is created and cannot be enabled later on an existing unencrypted instance. The RDS console selects encryption by default for new DB instances. **Pre-Requisites** - IAM permissions: rds:DescribeDBInstances, rds:CreateDBSnapshot, rds:CopyDBSnapshot, rds:RestoreDBInstanceFromDBSnapshot, rds:ModifyDBInstance, kms:DescribeKey and kms:CreateGrant - A KMS key to use for encryption (the AWS managed key aws/rds or a customer managed key) - A planned maintenance window for the cutover, and a list of the applications and settings (parameter groups, security groups, read replicas) that must be moved to the new instance **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon RDS console and select **Databases**. 3. Select a DB instance and open the **Configuration** tab. 4. Check that **Encryption** is **Enabled**. 5. Repeat for each DB instance in each region in use. 6. If encryption is not enabled, follow the implementation steps. **CLI:** Show the encryption status of all DB instances: aws rds describe-db-instances --region --query "DBInstances\[\].\[DBInstanceIdentifier,StorageEncrypted,KmsKeyId\]" --output table A DB instance fails if StorageEncrypted is False. Every DB instance, including read replicas, is evaluated on its own setting; snapshots and automated backups are not examined by this check. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon RDS console and select **Databases**. 3. Select the unencrypted DB instance and choose **Actions**, then **Take snapshot**. 4. When the snapshot is available, select **Snapshots**, select it and choose **Actions**, then **Copy snapshot**. 5. Select **Enable encryption**, choose the KMS key and choose **Copy snapshot**. 6. When the encrypted copy is available, select it and choose **Actions**, then **Restore snapshot**. 7. Configure the new DB instance with the same settings as the original (instance class, subnet group, security groups, parameter group) and choose **Restore DB instance**. 8. Stop writes to the original instance, update applications to use the new endpoint and confirm they work. 9. Delete the original unencrypted DB instance after the cutover is verified. 10. Repeat for each affected DB instance in each region in use. **Backout Plan** Keep the original unencrypted DB instance (or a final snapshot of it) until the new instance has been verified. 1. Point applications back to the endpoint of the original DB instance. 2. If the original instance was already deleted, restore it from its final snapshot in the Amazon RDS console (**Snapshots**, **Actions**, **Restore snapshot**). 3. Delete the new encrypted DB instance once it is no longer needed. Note: data written to the new instance after the cutover is not present in the original instance. Rolling back also leaves the data unencrypted at rest. **Reference** - [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) - [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER\_CopySnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html) - [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER\_RestoreFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.