aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap
Adding the StorageEncrypted property to AWS::RDS::DBCluster shouldn't replace the cluster if it is set to false and the cluster isn't encrypted
- Dominant language
- No language data
- Stars
- 1.1k
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
### Name of the resource
AWS::RDS::DBCluster
### Resource name
_No response_
### Description
I ran into this recently:
1. I had a CloudFormation stack with an Aurora DB Cluster. The cluster resource did not have the `StorageEncrypted` property defined at all, and the cluster was not encrypted as is the default behaviour in this case (i.e. the apparent setting is effectively "false")
2. I added the `StorageEncrypted` property to the cluster with a value of "false". (This value came from a parameter reference, but I don't think that matters)
3. I updated my stack and CloudFormation _replaced_ my cluster, even though it was effectively keeping the same, unencrypted setting.
Since the configuration of the database cluster encryption setting was effectively unchanged, I would not expect that the cluster would get replaced. The docs do say that updates require replacement, but it's unclear from that whether going from "no setting" (implicitly false) to explicitly setting the value to explicitly false would cause a replacement. Fortunately, I had set my `UpdateReplacePolicy` to "Retain" (and this wasn't a production DB anyway).
As an additional note, if you do have `StorageEncrypted` set to false in your CF stack, you _remove_ the property, and update your stack, you get the same replacement effect which is unexpected and potentially dangerous if you haven't set the right `UpdateReplacePolicy`.
### Other Details
_No response_
Contributor guide
Research direction
Start with the reported AWS::RDS::DBCluster scenario: compare stack updates when StorageEncrypted is omitted, explicitly false, and removed. Verify whether each update replaces the unencrypted cluster, and consider the work done when equivalent false settings no longer trigger replacement without changing encryption.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100