Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VPC construct should allow using custom route table for many subnets #4308

Open
konstantinj opened this issue Oct 1, 2019 · 15 comments
Open
Labels
@aws-cdk/aws-ec2 Related to Amazon Elastic Compute Cloud effort/large Large work item – several weeks of effort feature-request A feature should be added or improved. p1

Comments

@konstantinj
Copy link

Currently it's not possible to specify either the number of route tables or inject a custom route table to the VPC construct.

Use Case

When creating VPN or Peering connections together with the VPC it would be great when I can customise the route table. For me there is no drawback having only one for many subnets - it's less complex when modifying it.

Proposed Solution

Make it possible to set the route table per subnet. Currently it's readonly. Why?

const privateRouteTable = new CfnRouteTable(this, "privateRouteTable", {
    vpcId: vpc.vpcId
})

const selection = vpc.selectSubnets({
    subnetType: ec2.SubnetType.PRIVATE
});
for (const subnet of selection.subnets) {
    subnet.routeTable = privateRouteTable
}
@konstantinj konstantinj added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Oct 1, 2019
@SomayaB SomayaB removed the needs-triage This issue or PR still needs to be triaged. label Oct 1, 2019
@konstantinj
Copy link
Author

@rix0rrr Is this something you would support? In that case I could create a PR maybe.

@rix0rrr
Copy link
Contributor

rix0rrr commented Oct 10, 2019

Can you describe your use case a bit more? What are you trying to achieve?

@konstantinj
Copy link
Author

konstantinj commented Oct 10, 2019

It's more or less for convenience. Our vpc stack currently has 1 route table for all private and 1 for all public subnets. Which is enough imho since we use different subnets/az for making apps HA, nothing more. So routes will be always the same. It seems more effort to me to mange 1 table per subnet when it comes to peering connections, vpns and so on. Also I'm having a problem switching to cdk managed vpc stacks currently since cdk would drop my existing tables and will add new tables that won't have routes for already existing peerings and vpns. By adding my own custom table I can name it like my already existing table (same logical id) and routes will be kept.

@konstantinj
Copy link
Author

@rix0rrr I still could provide some code here if this would be fine for you. If you don't like it you should close this.

@mikepietruszka
Copy link

I second this use case. It would be nice to manage the route tables in VPC construct. Currently it's hard to get a list of created route tables.

@konstantinj
Copy link
Author

@maschinetheist Last workaround I've tried was deleting the elements in the tree. This is now officially possible with #1408

@rix0rrr
Copy link
Contributor

rix0rrr commented Jan 23, 2020

Related to #5927

@rix0rrr rix0rrr added the effort/large Large work item – several weeks of effort label Jan 23, 2020
@SomayaB SomayaB added @aws-cdk/aws-ec2 Related to Amazon Elastic Compute Cloud and removed package/vpc labels May 27, 2020
@rix0rrr rix0rrr added the p1 label Aug 12, 2020
@kennu
Copy link

kennu commented Apr 12, 2021

I just had to use:

subnetA.node.tryRemoveChild('RouteTableAssociation')
subnetA.node.tryRemoveChild('RouteTable')

To get rid of the autogenerated route tables in my project. They caused problems in replicating an existing VPC configuration to a new deployment of a project. More specifically they caused problems with VPC S3 Endpoint routing.

@frij-aws
Copy link

One more example use case. Some HA solutions manipulate the VPC routing tables to move an IP address across AZs -- this technique is called "overlay IP addresses" e.g.: https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html. Having separate, duplicate/redundant routing tables for each subnet will be problematic in these situations because it will slow the clustering software down as it loops and updates all the required routing tables.

I'd say it's a best practice to have one routing table shared by all private subnets, another shared by all public subnets, etc. This also ensures each layer of the network has a consistent routing table across all equivalent subnets. +1 on this request!

@cesarpachon
Copy link

hello I wonder if there had been some update on this topic.. I am also facing the request of pointing all the subnets through a shared Route Table instead of having one route table per subnet.

@MrArnoldPalmer MrArnoldPalmer added p2 and removed p1 labels Jan 25, 2023
@github-actions github-actions bot added p1 and removed p2 labels Jan 29, 2023
@github-actions
Copy link

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.

@irobinson-ntirety
Copy link

Can we get this done sooner? I find the need for this to more easily control routes for a hub and spoke model with transitgateways and managing 2 route tables instead of 6 make it much easier.

@irobinson-ntirety
Copy link

Can we get this done sooner? I find the need for this to more easily control routes for a hub and spoke model with transitgateways and managing 2 route tables instead of 6 make it much easer.

@tdalbo92
Copy link

tdalbo92 commented Mar 1, 2024

Chiming in to add support for this - having to traverse cloudformation nodes to modify and delete sections, just to modify routes, feels like a huge hack.

@emacthecav
Copy link

Any update on this? Not a fan of having to write custom assets to take care of this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-ec2 Related to Amazon Elastic Compute Cloud effort/large Large work item – several weeks of effort feature-request A feature should be added or improved. p1
Projects
None yet
Development

No branches or pull requests