(RDS): CDK overwrites DatabaseInstance AllocatedStorage back to default (100) on every deploy

The default behaviour of an RDS service update (specifically DatabaseInstance) is to maintain the existing AllocatedStorage if no value is specified by the user. Users often use RDS storage autoscaling, while setting only MaxAllocatedStorage. The CFN definition for AllocatedStorage is optional hence expected behaviour at the time of the deploy is to retain the existing AllocatedStorage.

However when you leave AllocatedStorage out of the DatabaseInstance construct in CDK it instead sets it to 100. This tries to overrides whatever the current AllocatedStorage is, which, as mentioned, already increased by the storage autoscaling which raises an error.

Reproduction Steps

1. Deploy RDS DatabaseInstance with MaxAllocatedStorage set to 500 (without setting AllocatedStorage)
2. Letting the autoscale get into action to increase allocated storage to > 500
3. Deploy the stack again with some minor change, i.e increase the MaxAllocatedStorage to 1000

What did you expect to happen?

Deploy should not assign default value (100) for AllocatedStorage, instead ket the CF use current value.

What actually happened?

1/3 | 12:27:21 PM | UPDATE_FAILED        | AWS::RDS::DBInstance                        | SpansDatabaseInstance (SpansDatabaseInstance76A399EE) Invalid storage size for engine name postgres and storage type gp2: 100 (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: 33851626-63a7-4b91-9451-374ae492aa57; Proxy: null)
        new DatabaseInstance (/private/var/folders/_l/mhjrnwdj54ld1fb77tlsw6bw0000gn/T/jsii-kernel-5b0Vtn/node_modules/@aws-cdk/aws-rds/lib/instance.js:352:26)
        \_ GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:3589:49
        \_ Kernel._wrapSandboxCode (GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:4073:16)
        \_ Kernel._create (GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:3589:26)
        \_ Kernel.create (GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:3324:21)
        \_ KernelHost.processRequest (GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:13191:28)
        \_ KernelHost.run (GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:13129:14)
        \_ Immediate._onImmediate (GitProjects/epsagon-backend/venv/lib/python3.6/site-packages/jsii/_embedded/jsii/jsii-runtime.js:13132:37)
        \_ processImmediate (internal/timers.js:456:21)

Workaround

To set the the CDK AllocatedStorage to the real current value taken from the RDS console.

Environment

• CDK CLI Version : 1.87.0
• Framework Version: 1.87.0
• Node.js Version: 12.18.2
• Language (Version): Python 3.6.5

---

This is 🐛 Bug Report

[rix0rrr]

thanks for opening the issue. You’re right that it’s probably a mistake to set that always to 100. However, we I’m not sure we can change that behavior now, as I’m worried it will be consider a backwards-incompatible change 😕.

I don’t think it will be. I don’t think the resetting to a fixed number on deployment is desirable behavior for anyone, and even if it were it is easily recreated by passing the parameter. Also, the downsides of “silently” switching off this behavior are very minor–it will not lead to data loss or anything. So I think it’s safe to make this change.

We had the same problem with AutoScalingGroups, where we accidentally set the “desiredCount” property to a default value (causing a scaling reset on every deploy). The solution was to not automatically set the values.

I would recommend escape hatches as a workaround for now

[corymhall]

After looking into this some more it’s not clear what the solution should be. It looks like there are valid ranges based on the engine type (e.g. MySQL gp2 must be an integer from 20 to 65536). It also looks like the value is used when updating the instance.

It seems like the ideal solution is for CloudFormation to handle this by not using the value of allocatedStorage if it is less than the current storage. There is an existing request with CloudFormation for this. https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/430

Please comment here and let us know if the CloudFormation issue would not resolve your issue.