Giters

aws / aws-cdk-rfcs

RFCs for the AWS CDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CDK v2.0

eladb opened this issue · comments

commented
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:

v2.0 Candidates

Required

  • Monocdk
  • Reset Feature Flags
  • Remove All Deprecations

Recommended

Not Recommended

More Info Needed

Progress

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

Perhaps you should pin this issue?

commented

Could we define a comment tag to identify code that will become obsolete once these depreciations are removed? Something like:

// TODO:v2.0.0 remove this block
legacy_method();
// TODO:v2.0.0 end remove this block

EDIT: I used this kind of comment a few times in this PR: aws/aws-cdk@12d99eb

commented

Not sure if you want to go this route, but the Angular repo uses a tslint rule to manage this, and similarly to @nmussy's suggestion, you tag code like this:

@deprecated
@deletion-target v2.0.0

This prevents CI from passing on a version-bump PR if the deletion-target has been met but the code block hasn't been removed

commented

I think this issue would need a major version bump. Moving a resource from a CR to a native CFN resource would most likely delete and recreate the resource.

aws/aws-cdk#3930

commented

I think this issue would need a major version bump. Moving a resource from a CR to a native CFN resource would most likely delete and recreate the resource.

aws/aws-cdk#3930

In this case it won't because the CR doesn't implement a DELETE and moreover it's used only to update a property of a managed CF resource (AWS::Events::Rule).

commented

Closing this in favor of #118

commented

How can we make suggestions for things to consider for CDK v2.0? Open an issue?

commented

How can we make suggestions for things to consider for CDK v2.0? Open an issue?

Comments here with the suggested issue are good. #79

commented

One of AWS's core tenets is to be secure, and many constructs have defaults that are overly permissive. I propose changing construct defaults to be more aligned with AWS defaults, or to be secure by default.

Two examples off the top of my head are:

By default, VPC endpoints allow all traffic from the VPC (see the open parameter). When creating an endpoint in the console, by default no traffic is allowed. I would change this default to be "false".

By default, NetworkLoadBalancedFargate service is fully open to the public internet (see the publicLoadBalancer parameter). I would change this to be false by default.

commented

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.

commented

Adding aws/aws-cdk#3763 to the radar of 2.0 since it involves replacing existing deployed constructs.

@SoManyHs
@pkandasamy91

commented

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.