CDK v2.0

PR	Champion
#156	@eladb

Description

Proposal detailing how we release aws-cdk 2.0 and how we want to handle major versions in the future.

Things to consider

• Release process
• Long-term support for previous major versions
• Regular clean ups across major versions such as:
  • Remove all deprecated APIs
  • Reset all feature flags

v2.0 Candidates

Required

• Monocdk
• Reset Feature Flags
• Remove All Deprecations

Recommended

• Easier Identification of Experimental Modules and APIs
• Public S3 Artifacts
• Rename ID Parameter
• Remove all usage of Type unions

Not Recommended

• Unmangled L2 Logical IDs
• Removal of All Union Types
• Remove Custom Resource Implementation of Fargate Event Target
• Change Logical IDs to Avoid Potential Collisions
• Replace addToPolicy with addTo{Principal,Identity}Policy

More Info Needed

• AliasOptions and VersionOptions should not extend EventInvokeConfigOptions
• Remove Support for Docker Assets with Parameters

Progress

• Tracking Issue Created
• RFC PR Created
• Core Team Member Assigned
• Initial Approval / Final Comment Period
• Ready For Implementation
  • implementation issue 1
• Resolved

[GriffinMB]

Along the lines of what @flemjame-at-amazon said, it would be great if security-relevant properties either defaulted to a “most secure” setting, or, where the property may be availability or cost impacting, were required properties so developers could make a conscious decision about the setting.

To give a concrete example:

new Bucket(this, 'MyBucket');

It may not be clear to developers that this would default to unencrypted, or that encryption is even a property. If something like encryption was a required property, then devs would be aware of the property and could make the decision to use it or not.

[mwfpope]

One of the well-architected tenets is cost optimization (and there’s the Amazon LP of Frugality), so can we try to avoid having CDK create unnecessary resources?

Eg: By default, the L3 VPC construct creates an EIP for each AZ. The default limit is 5 EIPs. To deploy more than one VPC in the same region, you first need to request a quota increase. If you’re using those VPCs for Lambda(s), then the EIPs will go unused. (And of course, EIPs are billed only if they are unused.) There seems to be no option in the L3 construct to not have EIPs for the VPC.

In a multi-region, microservice architecture, this could easily end up being hundreds of unused EIPs. Suppose we have a distributed system that consists of 10 microservices, each in their own VPC. Suppose for each microservices, we deploy 1 test instance, and a production instance in 4 regions, with 3 AZs per VPC. Now, we have 150 unused EIPs which will cumulatively cost over $500 per month.

It’s possible to delete unnecessary resources (once you realize that they exist) using this obscure and undocumented method, but in this case, a better solution might be to have no EIPs by default or to have different L3 VPC constructs for different purposes (ie. create a LambdaVPC that encompasses best practices for running a Lambda VPC).

I only have this one example, but I wouldn’t have even noticed this example if I didn’t run into the quota limit when I was trying to deploy multiple serverless applications to the same development account. It would be very easy for other instances of this problem to occur completely unnoticed until you dive deep into a bill at some point in the future.