Description
Production databases often hold core application data and customer information. RDS storage encryption protects data, logs, automated backups and snapshots, so verify the actual instance’s encryption state.
Encryption does not replace database permissions or network access controls. For restored or replicated instances, also review source encryption and the applicable creation path.
Potential impact
Unauthorized acquisition of actually unencrypted storage or backups can expose sensitive information. Organizational database-encryption requirements may also be unmet.
Remediation
- Explicitly set
storage_encrypted = truefor new instances, adding an appropriatekms_key_idif separate key control is required. - Migrate an existing unencrypted instance by restoring an encrypted snapshot copy. A flag change alone does not encrypt its existing storage.
- Review Terraform replacement, data consistency and connection cutover, and verify actual database and snapshot encryption and KMS permissions.
Examples
These are new MySQL-instance excerpts. Verify support for the engine-version and instance combination in the target Region. Supply the password securely, protect Terraform state, and configure networking and backups separately.
Before
resource "aws_db_instance" "db_instance" {
allocated_storage = 20
storage_type = "gp2"
engine = "mysql"
engine_version = "5.7"
instance_class = "db.t2.micro"
db_name = "mydb"
username = "foo"
password = var.db_password
storage_encrypted = false
}
This does not enable storage encryption for the new instance.
After
resource "aws_db_instance" "db_instance" {
allocated_storage = 20
storage_type = "gp2"
engine = "mysql"
engine_version = "5.7"
instance_class = "db.t2.micro"
db_name = "mydb"
username = "foo"
password = var.db_password
storage_encrypted = true
}
This requests storage encryption. Before applying this difference to an existing instance, review data migration and replacement plans.