aws-cdk: Cannot update serverless aurora maxCapacity with CfnDBCluster
If you create a serverless Aurora database with CfnDBCluster, and then try to update the maxCapacity, the deployment fails with the message: "DatabaseCluster You currently can’t modify EndpointPort with Aurora Serverless. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination; " Even though the port was not changed.
Reproduction Steps
Create a serverless database:
const dbCluster = new rds.CfnDBCluster(this, "DatabaseCluster", {
engine: "aurora-postgresql",
engineMode: "serverless",
engineVersion: "10.7",
masterUsername: 'postgres',
databaseName: "collab",
masterUserPassword: "Foobar",
dbSubnetGroupName: new rds.CfnDBSubnetGroup(this, "CollabDbSubnetGroup", {
dbSubnetGroupDescription: ` Collab Db cluster subnet group`,
subnetIds: vpc.selectSubnets({subnetType: ec2.SubnetType.PRIVATE}).subnetIds
}).ref,
vpcSecurityGroupIds: [mySecurityGroupId],
storageEncrypted: true,
backupRetentionPeriod: 35,
deletionProtection: false,
port: 5432,
scalingConfiguration: {
autoPause: true,
secondsUntilAutoPause: 300,
minCapacity: 2,
maxCapacity: 2
}
});
Deploy this.
Change nothing other than maxCapacity (to 4).
Running cdk diff shows:
Stack TestCollabDbStack
Resources
[~] AWS::RDS::DBCluster DatabaseCluster DatabaseCluster
└─ [~] ScalingConfiguration
└─ [~] .MaxCapacity:
├─ [-] 2
└─ [+] 4
Which is what you’d expect. However, if you run cdk deploy, the following happens:
TestCollabDbStack
TestCollabDbStack: deploying...
TestCollabDbStack: creating CloudFormation changeset...
0/2 | 11:45:35 PM | UPDATE_IN_PROGRESS | AWS::RDS::DBCluster | DatabaseCluster
1/2 | 11:45:36 PM | UPDATE_FAILED | AWS::RDS::DBCluster | DatabaseCluster You currently can't modify EndpointPort with Aurora Serverless. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: 83490936-5bdf-418e-b065-7a79a176beea)
Environment
- CLI Version :
- Framework Version: 1.15.0
- OS : Windows 10
- Language : Typescript
This is 🐛 Bug Report
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 18 (3 by maintainers)
Ran into this issue as well. The solution or at least work-around, if you’re not using a custom port, is to just omit the port from the template. It’s optional and will use the default port for the engine specified and won’t be seen as a change.
Had the same issue. Removing the port reference worked. I have submitted this as a bug report to AWS via our paid support account. My suggestion to both the CDK and RDS team would be to make bug reports available to all users when they can’t be escalated on the appropriate repo.
I can confirm that AWS support also let us know that a patch had been deployed, and we were able to get our deployment through, with an Aurora Postgres engine upgrade and no
EndpointPorterrors.Thanks everyone for the quick patch and responses.
I opened a support ticket with AWS and got feedback today: According to AWS a fix was applied and this should now longer be an issue. I can confirm that at least changing
CopyTagsToSnapshotandBackupRetentionPeriodvia CloudFormation does not anymore result inYou currently can't modify EndpointPort with Aurora Serverless ...Currently experiencing this error after having updated
CfnDBCluster.engineVersion(aws-cdk-lib@2.45.0). Port is not specified in the cluster construct.How were you able to get your deployment through ?
I was having this issue as well using the CDK when simply adding a tag to the RDS Cluster. After the CfnDBCluster deployed the first time and their respective values are set I had to omit both, preferred_maintenance_window and port, for subsequent releases that modify cdk’s CfnDBCluster resource. After making the update, preferred_maintenance_window and port values persisted from the first release, my tag changes took place, and deployment was successful.
Update - AWS are aware of the issue internally - Their Response -
That being said, I have checked internally and can currently see that there is a feature request for this and our internal team is aware of it. However, I will not be able to provide an ETA as to when it would be available.
As you must already be aware, any new fix/feature requires rigorous testing and compatibility checks before rolling it out globally in order to make sure that there are no issues caused due to the same. However, please be assured that I have added a +1 on your behalf for this feature request in order to get traction on the same.
For those of you who commented, if you have access to AWS Support, it’d be great if you file an issue with them. Unfortunately, you can’t contact AWS Support for a technical issue unless you have a paid support plan, which my company doesn’t (and currently isn’t willing to pay hundreds of dollars a month just in order to submit a bug report) – so I don’t think the RDS team even knows they have this bug.