0
votes

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:

Shows that the subnets are associated

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

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
1

1 Answers

2
votes

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.