Allow filtering out IP exhausted Subnets during subnet selection [ec2, rds, VpcLookup] - SubnetSelection

Expose a SubnetSelection option that allows filtering out Subnets with 0 available IPs (IP “exhausted” subnets).

Use Case

I work in a massive organization where we all share a set of accounts - managed by central resources and deployed with aging Terraform configs. We’ve reached the point where one of 3 of our private subnets has run out of IPs. The other two subnets still have quite a bit of IP space left.

It would be nice to be able to filter out IP-unavailable Subnets when creating resources to avoid failed deploys to those Subnets. For example, creating a DBCluster, I want to avoid including unavailable Subnets when the DbSubnetGroup is created.

Proposed Solution

I have implemented this change by exposing the availableIpAddressCount Subnet property source from the context provider and exposed a filterOutIpExhausted SubnetSelection option - defaulted to false. Exhausted subnets are still pulled back as part of the vpc lookup. This just allows consumers to filter them out during subnet selection.

I’m a CDK codebase noob so there are cases I’m not sure about, particularly regarding context management (e.g. stuff like #6929). If an existing (deployed) resource is ignoring IP exhausted Subnets, and one of the subnets it’s referencing runs out of IPs, then what happens the next time the resource is deployed? If the context is version controlled, then will the subnet still show as available?

Edit: After re-reading the CDK context/environment docs and Rico’s super helpful post in #6929, the questions I had above don’t seem concerning anymore, provided people are managing context according to the supplied guidelines. Playing around with my own stack, which is deployed to 3 different accounts has also assuaged some fears I had. Now I’m just dying to know what I’ve missed and what the experts think. 😄

Other

The PR was really just a fun exercise to start getting familiar with CDK code. If it’s useful, great. If not, no sweat.

I’m also aware of #5927 + #7720, but I don’t see any major conflicts between the changes. There might however be impacts depending on what sort of other rework is under consideration.

Cheers!

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[rix0rrr]

The CDK’s goal is to be a platform for building these kinds of features as much (or more) as delivering them out of the box.

Especially if the feature is going to have caveats and there are multiple reasonable implementations imaginable, this is something that should be solved in the broader CDK ecosystem rather than a single “one-size-fits-all” solution that we are supposed to vend and maintain.

(Especially since doing so would more likely than not translate into a slew of “my use case is slightly different than what you support can you add a single flag just for me pretty please?” feature requests).

For now, I would recommend you build your own context-provider-like system outside the CDK regular build. Store some state in JSON files, read them in your application and configure your app accordingly. How you push around state is then completely under your control and as flexible as you need it to be.

When the open provider framework materializes, the same code can then be more nicely integrated and re-used, but fundamentally it doesn’t change much about how this would work.

Thanks for the energy behind the idea! Closing this issue as not really appropriate for CDK itself, but I wish you the best of luck implementing this and releasing it to the broader community if you feel it fills an important need.

[gradybarrett]

Does this being part of the Lookup layer change your mind at all about the feature? It still seems like putting resources into an unavailable subnet is a universal concern.