VPC and Subnet to allow developer to set the Cidr_Block

[slipdexic]

:rocket: Feature Request

General Information

• [ ] :wave: I may be able to implement this feature request
• [x] :warning: This feature might incur a breaking change

Description

Currently when you create a VPC , you say how many AZ's and the Cidr_mask for each subnet in the respective ZONE , e.g Public, Private.... The Cidr ranges are then automatically assigned, and also not surfaced.

What I need to do is have control over the ISubnets CidrBlock. Currently you can only say what the Subnet mask is range (/16 - /28), the CDK/ VPC inside CreateSubnets() calculate and assigns the CidrBlock. it does not even report it back #3951

This is great for a simple environment , but in a enterprise environment this just does not work with complex networks, the design will be passed down IP ranges agreed and assigned a head of a single line of code being written.

Proposed Solution

Allow the enduser/developer/devops person to have the option of assigning the IP ranges (CIRDBlocks) themselves

Environment

• CDK CLI Version: 1.6
• Module Version:
• OS: all
• Language: all

Other information

[NGL321]

Hey @slipdexic,

Thank you for submitting a feature request! I looked in the docs and saw that one of the VPC props is a specific definition for CIDR. From how I was reading the request, this is what you are asking for. Please let me know if I am wrong and if it is different functionality you are looking for! 😸

[slipdexic]

@NGL321 , no this is not that is at VPC level I need this at subnet level I have updated the feature request description .

IMHO new need a more simplistic base VPC class , that we can inherit from, the current one does to much and makes a lot of assumptions (not all networks are symmetrical). It is a lot of work to create your own custom VPC as I discovering , so I'm feeding back into this project so others in PCI-DSS / HIPPA / locked down environments don't have these issues.

Adding these features give the developer a lot more power and control.

[rix0rrr]

Related to https://github.com/aws/aws-cdk/issues/5927

[mrpackethead]

Adding my support to this this problem .. Its easy enough for me to use the cfn constructs but, given they dont' create an ec2.Vpc type, it makes things difficult as i can't use many of the other contrstructs that want a VPC, or any number of the useful methods for the VPC. As a result i'm building the VPC in one stack then importing it via lookup in others. Really not ideal.

[APAC-DevOps]

The ability of setting CIDR at subnet level is really important for serious business customers. Without this capability, say 6 months after the initial launch of VPC stacks via CDK, if I ever want to add new public subnets, then, the IP address ranges from my public subnets won't be contiguous. This would make the configuration of routing complicated (e.g. on TGW, or the router which has site-to-site VPN to VPC VPN gateway.)

here is what I have come up so far. with a mixture of L2 constructs and L1 constructs, I am able to specify CIDR at subnets level. However, in order to give the resources in the subnet created via L1 construct internet access (or any sort of other cross VPC connectivity via TGW), I would have to do route association explicitly, otherwise, the subnet would be associated to a default route table which doesn't have any route to internet.

And I noticed, that with the L2 VPC construct, there will be a route table for each subnet. which is to say there is 1 to 1 map in regards to route table and subnet. It won't cause any harm, but it just makes the overall network management tedious which seems to against one of the principals of CDK, make the writing of IaC code easier and simplier.

@mrpackethead would you mind sharing your tricky?

    self.vpc = ec2.Vpc(self, 'kVPC',
        cidr=vpc_cidr,
        max_azs=99, # 
        enable_dns_hostnames=True,
        enable_dns_support=True,
        subnet_configuration=[
            ec2.SubnetConfiguration(
                name="Public",
                subnet_type=ec2.SubnetType.PUBLIC,
                cidr_mask=24
            ),
            ec2.SubnetConfiguration(
                name="Private",
                subnet_type=ec2.SubnetType.PRIVATE,
                cidr_mask=24
            ),
            ec2.SubnetConfiguration(
                name="ISOLATED",
                subnet_type=ec2.SubnetType.ISOLATED,
                cidr_mask=24
            ),
            ec2.SubnetConfiguration(
                name="Tgw",
                subnet_type=ec2.SubnetType.ISOLATED,
                cidr_mask=24
            )
        ],
        nat_gateways=1
    )

    # priv_subnets = [subnet.subnet_id for subnet in self.vpc.private_subnets]

    self.cfn_subnet = ec2.CfnSubnet(self, 'Jianhua',
        cidr_block="192.193.193.0/24",
        vpc_id=self.vpc.vpc_id,
        availability_zone=self.vpc.availability_zones[0]
    )

[APAC-DevOps]

Correction: it seems there are L2 constructs like Subnet, PrivateSubnet, IsolatedSubnet in CDK v2.

[toritroniks]

I was able to do it by using the provided escape hatches to override the subnets.

More information about the escape hatches can be found here: https://docs.aws.amazon.com/cdk/latest/guide/cfn_layer.html

I still think that it would be nice to be able to do it directly in the vpc construct.

The sample code:

    const vpc = new ec2.Vpc(this, 'Vpc', {
      maxAzs: 2,
      cidr: '10.10.0.0/16',
    });

    vpc.publicSubnets.forEach((subnet, index) => {
      const cfnSubnet = subnet.node.defaultChild as ec2.CfnSubnet;
      cfnSubnet.addPropertyOverride('CidrBlock', `10.10.${10 + index}.0/24`);
    });
    vpc.privateSubnets.forEach((subnet, index) => {
      const cfnSubnet = subnet.node.defaultChild as ec2.CfnSubnet;
      cfnSubnet.addPropertyOverride('CidrBlock', `10.10.${20 + index}.0/24`);
    });

[Pharrox]

I want to offer a warning about using the escape hatches to override the CIDR blocks for a subnet. It looks like the L2 subnet constructs, as well as ISubnet now expose an ipv4CidrBlock property. This property is being set in the constructor from the input props directly and cannot be changed or controlled when created under a VPC.

While using the escape hatches to override the CDK provided CIDR's will get you subnets with the desired ranges, the actual ISubnet objects will continue to report the wrong CIDR that was generated before being overridden. Who knows what implications this could have now and in the future for any other constructs referencing the ISubnet.ipv4CidrBlock property on your VPC subnets.

[jishi]

I ran into the same problem here as well. I want to make modifications to my VPC and remove the public subnets, but since those are allotted first from the VPC CIDR block, removing them moves all of the private subnet CIDR blocks, thus requiring replacement.

I tried moving up the VPC CIDR so it would start where the previous subnet started, but changing CIDR for the VPC forces a replacement of VPC instead, which is even worse.

For my needs, just adjusting the starting point of the allotment would suffice, but some more flexibility would be nice. Just to allow changing the Subnet.ipv4CidrBlock after the fact might be enough perhaps?

[github-actions[bot]]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[corymhall]

Hello all, We have noted the community engagement on this issue and we understand its importance. Since there are a number of such items, we need to make sure that we’re working on the most important ones. This means that the issue will be moved into the backlog; it will be checked against the other projects for complexity, risk and effort versus benefit.

Most likely this will be addressed as part of #5927.

We will keep posting updates as they become available!

[AmitLaviDev]

Hi all, any news?