-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Comments
@rix0rrr Is this something you would support? In that case I could create a PR maybe. |
Can you describe your use case a bit more? What are you trying to achieve? |
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. |
@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. |
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. |
@maschinetheist Last workaround I've tried was deleting the elements in the tree. This is now officially possible with #1408 |
Related to #5927 |
I just had to use:
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. |
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! |
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. |
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. |
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. |
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. |
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. |
Any update on this? Not a fan of having to write custom assets to take care of this |
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?
The text was updated successfully, but these errors were encountered: