feat(ec2): select subnets that contain IP address(es)

[flemjame-at-amazon]

---

feat(ec2): select subnets that contain IP address(es)

It is currently not possible to search for subnets that contain a particular IP address or range of addresses, because ISubnet does not expose the CIDR blocks. Users with fixed-ip resources in a VPC cannot then determine what the associated subnet is.

This commit exposes the CIDR block for ISubnet, and adds a feature to SubnetSelection that allows a user to select subnets based on whether they contain any of a set of IPv4 addresses.

  new BastionHostLinux(stack, 'Bastion', {
    vpc,
    subnetSelection: {
      containsIPv4Addr: ['10.0.160.0'],
    },
  });

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

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[rix0rrr]

I'm going to put my foot down and say no to this. We should have stopped adding random J selector for everyone's use case to this interface a long time ago.

Please turn this into a protocol with an interface that people can implement in their own projects (mark the interface @subclassable), and then use that protocol to solve your use case in your app code.

[flemjame-at-amazon]

I'm going to put my foot down and say no to this. We should have stopped adding random J selector for everyone's use case to this interface a long time ago.

Please turn this into a protocol with an interface that people can implement in their own projects (mark the interface @subclassable), and then use that protocol to solve your use case in your app code.

To clarify -- a user would instantiate an object which implements this protocol, and the user passes to subnet selection?

Also, I assume we leave support for existing subnet selection options?

[rix0rrr]

To clarify -- a user would instantiate an object which implements this protocol, and the user passes to subnet selection?

Yes, exactly that.

Also, I assume we leave support for existing subnet selection options?

Yes we can't take those away without breaking compatibility.

[flemjame-at-amazon]

Resolving in favor of #10112