AWS VPC Route Table - Change default route table

Question

Is it possible to change the route table associated with a VPC? I am using CloudFormation and have created my own RT and associated subnets with it. However, since the VPC is using the default route table and it claims that I have not explicitly associated the subnets, they are associated with the main route table as a catch all. I am obviously doing something wrong as my subnets are associated with the route table I want, but the default route table seems to be taking precedence.

This shows that the subnets are associated:

This says the subnets are not associated with a route table:

If I add the IGW route to the default/main RT, everything works. Not what I want though.

Update

Here is the CloudFormation to create the VPC and components. The problem is that if a box is spun up in the subnet, the main route table is being used despite my subnets being explicitly associated with my custom route table.

Resources:
  TransitVPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: !Ref TransitVpcCidr
      EnableDnsSupport: 'true'
      EnableDnsHostnames: 'true'
      Tags:
      - Key: Name
        Value: Transit VPC
  TransitInternetGateway:
    Type: 'AWS::EC2::InternetGateway'
    Properties:
      Tags:
      - Key: Name
        Value: Transit Internet Gateway
    DependsOn:
    - TransitVPC
  TransitRouteTable:
    Type: 'AWS::EC2::RouteTable'
    Properties:
      VpcId: !Ref TransitVPC
      Tags:
      - Key: Name
        Value: Transit VPC RT
    DependsOn:
    - TransitVPC
  TransitIGWAttachment:
    Type: 'AWS::EC2::VPCGatewayAttachment'
    Properties:
      InternetGatewayId: !Ref TransitInternetGateway
      VpcId: !Ref TransitVPC
    DependsOn:
      - TransitVPC
      - TransitInternetGateway
  TransitSubnetA:
    Type: 'AWS::EC2::Subnet'
    Properties:
      VpcId: !Ref TransitVPC
      CidrBlock: !Ref TransitSubnetACidr
      AvailabilityZone: !Ref TransitSubnetARegion
      Tags:
      - Key: Name
        Value: Transit VPC Subnet A
    DependsOn:
    - TransitVPC
  TransitSubnetARTAssoc:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      RouteTableId: !Ref TransitRouteTable
      SubnetId: !Ref TransitSubnetA
  TransitSubnetB:
    Type: 'AWS::EC2::Subnet'
    Properties:
      VpcId: !Ref TransitVPC
      CidrBlock: !Ref TransitSubnetBCidr
      AvailabilityZone: !Ref TransitSubnetBRegion
      Tags:
      - Key: Name
        Value: Transit VPC Subnet B
  TransitSubnetBRTAssoc:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Ref TransitSubnetB
      RouteTableId: !Ref TransitRouteTable
  TransitIGWRoute:
    Type: 'AWS::EC2::Route'
    Properties:
      RouteTableId: !Ref TransitRouteTable
      DestinationCidrBlock: !Ref FinalGatewayCidr
      GatewayId: !Ref TransitInternetGateway
    DependsOn:
    - TransitIGWAttachment

score 1 · Answer 1 · answered Feb 27 '19 at 21:36

1

It would be much better to create the whole VPC via CloudFormation, including:

VPC
Internet Gateway
Subnets
Route Tables
Route Table Associations

This way, it is guaranteed to work the same way when deployed again in future. Plus, it is easy to reference all components of the VPC within the stack (as opposed to having to reference resources created outside of the stack).

Alternatively, your template could create its own Route Table (that should be used instead of the existing Route Table), then create a Subnet Association that configures your new subnets to use the new Route Table. This way, the Default Route Table won't be used because a subnet will only use the Default Route Table if it hasn't been specifically assigned to a Route Table.

answered Feb 27 '19 at 21:36

John Rotenstein

241,921
22
380
470

That's what I am doing but it seems as though the main route table is taking precedence over the new route table and there doesn't seem to be a way (that I've found thus far) to make my custom route table the main route table via CloudFormation. – Spechal Feb 27 '19 at 21:37
I will update the post with the CloudFormation used for the VPC. The problem is that when I spin a box up, I cannot get to it due to the association problems outlined in the OP. – Spechal Feb 27 '19 at 21:41
In general, it's a good idea to avoid using a default Route Table, since it does not explicitly define relationships. – John Rotenstein Feb 27 '19 at 22:30
1

I would really love to avoid setting the custom route table as the main one, but it's currently the only way I can make any progress on what I am working on until I/someone can help sort out why the main route table is implicitly including the subnets I have explicitly associated with my custom route table. – Spechal Feb 27 '19 at 22:33
1

The main route table for a VPC will only be used for subnets that have not been explicitly associated with a Route Table. What makes you think it is working differently to this? – John Rotenstein Feb 27 '19 at 22:36
I am under this impression because the first image shows my explicit associations on my custom route table for the VPC and the second image shows the default route table for the VPC but says that my subnets have not been explicitly associated and therefore are associated with the main route table. So, I am confused. – Spechal Feb 27 '19 at 22:38
Okay, I just ran your template (substituting values for the CIDR ranges) and I now understand what you are saying in your question. Yes, the main route table strangely claims that some subnets are not associated with route tables but the fact is _they are_ associated (as can be seen on the subnets themselves). Therefore, I suggest you ignore the message in your second screenshot and remain confident that they are correctly associated. You might want to hit the "Feedback" button in the console to report this apparent incorrect labelling. – John Rotenstein Feb 27 '19 at 23:00
I will submit feedback to AWS. I appreciate you taking a look at the CloudFormation template. If you add an instance to the subnets you cannot get to it ... until you add the IGW to the main route table. I may have to open a support ticket to get this resolved but the account I am working with only has a Basic plan. :/ Thank you for your help thus far. – Spechal Feb 28 '19 at 00:39
2

I added an instance to `Transit Subnet A` and could SSH into the instance just fine. I set `TransitIGWRoute`.`DestinationCidrBlock` to `0.0.0.0/0`. You could also consider setting `MapPublicIpOnLaunch = True` on the public subnet configurations. – John Rotenstein Feb 28 '19 at 01:23

AWS VPC Route Table - Change default route table

1 Answers1