feat(rds): construct for Aurora Serverless Clusters

[shivlaks]

Adds a new construct to specify Aurora Serverless clusters

This is largely a stripped down version of Cluster as there are many properties
within clusters that do not apply to Aurora Serverless. Some of the notable
exclusions are:

• backup windows
• maintenance windows
• associated roles (as S3 import/exports are not supported)
• iam database authentication
• exporting cloudwatch log exports
• storage encryption is always true in Aurora serverless

Added:

• Scaling options which only apply to Aurora serverless and cannot be used for
  provisioned clusters
• Enum AuroraCapacityUnit to specify the provisioned capacity
• Enable http endpoint for a serverless cluster

Closes #929

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[skinny85]

Looks great! Some minor notes below.

[skinny85]

I would also move the tests out of the serverless directory, I think it's a little early for that too 🙂.

[skinny85]

For reducing duplication, here are my thoughts.

I don't think inheritance will cut it here, because of the conflicting requirements between the serverless and regular Clusters (the fact that they need separate Resource interfaces I think makes it impossible to simply inherit the implementation from). So, how about, after you've completed the implementation of the serverless Cluster and written all of the tests, you extract a new module-private Construct called something like SuperCluster (name is up to you of course) that essentially has all of the capabilities of both the serverless and regular clusters? And then, in the serverless and regular Cluster Resource classes, you would basically instantiate it with: new SuperCluster(this, 'Default', props); - the 'Default' ID should make all of the existing identifiers (that users already rely on through DatabaseCluster) stable. You just have to set the correct defaultChild in your ConstructNode, like this. The tests should not be modified after this extraction, and they should all keep passing.

Thoughts on the idea?

[shivlaks]

For reducing duplication, here are my thoughts.

I don't think inheritance will cut it here, because of the conflicting requirements between the serverless and regular Clusters (the fact that they need separate Resource interfaces I think makes it impossible to simply inherit the implementation from). So, how about, after you've completed the implementation of the serverless Cluster and written all of the tests, you extract a new module-private Construct called something like SuperCluster (name is up to you of course) that essentially has all of the capabilities of both the serverless and regular clusters? And then, in the serverless and regular Cluster Resource classes, you would basically instantiate it with: new SuperCluster(this, 'Default', props); - the 'Default' ID should make all of the existing identifiers (that users already rely on through DatabaseCluster) stable. You just have to set the correct defaultChild in your ConstructNode, like this. The tests should not be modified after this extraction, and they should all keep passing.

Thoughts on the idea?

taking a stab at this now

update (9/30/2020): I'm going to defer this change to a chore/refactor PR. I think it's super valuable and do agree it's the right place to get to. rather than grow scope of this PR, I'd like to get good scrutiny on it as well. also briefly chatted with @njlynch and his instinct was also to do it in a separate PR.

[njlynch]

Woohoo! 🎉

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[skinny85]

Looks good! Some minor comments.

[skinny85]

As discussed offline - please also mark IServelessCluster, ServerlessCluster, SeverlessClusterProps and ServerlessClusterAttributes as @experimental.

[skinny85]

Looks great! 🎉

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
• Commit ID: b040334
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[moltar]

Thank you @shivlaks