aws-cloudformation
AWS::RDS::DBInstance should ignore AllocatedStorage if less than actual storage
Currently, a CloudFormation deployment fails if the AWS::RDS::DBInstance property AllocatedStorage is less than the actual storage of the existing RDS instance. Yet auto-scaling of storage is a supported feature in RDS and also in CloudFormation deployments (enabling via MaxAllocatedStorage). So when auto-scaling of RDS storage occurs, it will break future CloudFormation deployments of that RDS if the value of AllocatedStorage is not first manually updated to the new storage amount.
The impact of this is that the unsupported configuration could go undiscovered until the next deployment. And then it will block that deployment until someone figures out and resolves the problem with the required, manual update to the CF template. And the deployment being blocked could be a critical Production change to resolve high business impact. Therefore this issue should be prevented.
Since storage cannot be reduced in RDS anyway, then the AllocatedStorage value should simply be ignored in the CF template/deployment if the value is less than the actual, deployed amount. Or at the very least, this rule should be followed if the template has MaxAllocatedStorage, since that means storage autoscaling is turned on.
An update to AllocatedStorage should still be deployed through CloudFormation if it is greater than the storage of the actual, deployed RDS instance.
Steps to reproduce this issue:
- Deploy CloudFormation template to a stack, including a MaxAllocatedStorage value and also an AllocatedStorage value that matches what the RDS instance already has.
- Run a process that triggers autoscaling of the RDS storage
- Do another CloudFormation deployment, changing BackupRetentionPeriod value
- Confirm error similar to this: Invalid storage size for engine name sqlserver-ee and storage type" ... "Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination"...
- Confirm the error is resolved by changing AllocatedStorage value in the template (to match actual RDS) and redeploying successfully.
Just hit this exact issue - Existing CFN template snippet
AllocatedStorage: 1000,
MaxAllocatedStorage: 1500.
At some stage, the storage on the RDS instance auto-scaled to 1250, but the next time we run the Cloudformation template, we get the error Invalid storage size for engine name oracle-se2 and storage type gp2: 1000
We have to login to the Console, find the new value of AllocatedStorage and then amend the AllocatedStorage value in our template.
There has to be a way to avoid this right?
So my most recent attempt to at least put us in a steady state where CFN can deploy in-between autoscaling...
MyDB:
...
Properties:
AllocatedStorage: !GetAtt MyDB.AllocatedStorage
...
...failed because AllocatedStorage doesn't exist, although the CFN documentations suggests it should be accessible via !GetAtt. I have my suspicions that !GetAtt might not be able to be used with the same resource it's being used in.
I have the same issue, it is very frustrating, if you manually change the CF script allocated storage to a size larger than the current size it will run, but then you fall into the trap of storage optimization which can block you again if you need to make a further change in a short space of time
This severely limits the utility of storage autoscaling if your DB is managed by CloudFormation. All autoscaling changes have to be copied back into CloudFormation, defeating much of the purpose of the "auto" scaling.
I just ran into this too. This very behavior makes auto scaling completely unhelpful.
I'm using typescript's CDK, and after the first cdk deploy, I changed my code to:
new rds.DatabaseInstance(this, "database", {
vpc,
engine,
instanceType,
maxAllocatedStorage,
databaseName,
...
allocatedStorage: Lazy.number({ produce: () => undefined }),
});
This way, I have no problems when the values differ from what's updated on the AWS RDS configuration.
If I need to re/create this from scratch, I need to change the value before cdk apply.
It's not the best approach if you're using gitops like workflow, but it's the best that I have for now.,
