VPC/RDS Sub Nets, Routing and Internet Access

This is the continuation of a Terraform and Ansible demo for AWS. It is used to create a VPC in AWS with an EC2 instance connected to MariaDB database running in RDS using a single Terraform plan. Ansible is used to configure the server and install all the needed packages.

Continue the demo, see:

Download de the code from IT Wonder Lab public GitHub repository.

VPC Sub Net Routing

Since we have deleted the default VPC, AWS needs new routing tables to connect our VPC subnets to the Internet.

terraform-aws-ec2-rds-basic-free - ITWL_AWS_Terraform_VCP_Routing.png

Following IT Wonder Lab best practices different routing tables will be created, one for all the public subnets and one for each of the private subnets.

The name of the resources will follow a pattern:

  • Cloud: a prefix specifying the unique name of this cloud across all available clouds and providers. In this case the prefix will be: ditwl that stands for Demo IT Wonder Lab in lowercase.
  • Resource: a short name identifying the resource, in this case:
    • rt: for routing table
    • igw: for Internet gateway
    • ir: for Internet route
  • Visibility: for resources that can be either public or private, a 3 letter acronym for the visibility:
    • pub: for public resources
    • pri: for private resources
  • Name: optional a name that describes the usage of the resource, for example the routing tables for private zones A and B will be za and zb.

Since we are provisioning a low budget infrastructure, the private subnets will not have access to the Internet. Giving access to the Internet to a private subnet requieres provisioning of NAT instances and it is recommend to place a NAT instance in each availability zone, therefore each zone will have its own routing table for private subnets.

Public subnets get access to the Internet using an Internet Gateway.

Routing is configured in the terraform.tfvars.

Internet Access for Public Subnets

The file aws_internet_gateway.tf creates the Internet Gateway using a Terraform module.

Routing Tables for Subnets

The actual routing tables are added in aws_vpc_routing.tf 

The module “aws_main_route_table_public” in line 18 creates a new routing table, the created table is assigned as the default (or main) table using the “aws_main_route_table_association” resource in line 34.

Main table contains a local entry for the routing inside the VPC and a route to the Internet ( whose target is the Internet Gateway “${module.aws_internet_gw.id}” created before and assigned as routing table route in line 25.

All the VPC subnets that are not assigned a specific routing table use the main routing table, therefore public subnets are not assigned to any specific routing table.

For private subnets, two routing tables are created on lines 49 and 56, then assigned to the corresponding subnets in lines 63 and 69.

RDS Subnet Group

Another type of Subnet is the one used for AWS RDS. In the example we are using a MariaDB database as a service.

To configure the Database a RDS Subnet Group has to be created, the RDS Subnet Group is an aggregation of VPC Subnets, and the same principles of resource distribution, high availability and isolation of resources applies. See RDS Subnet Group for a description.

Following IT Wonder Lab best practices the RDS Subnet will have networks in two availability zones and the name of the resources will follow a pattern:

  • Cloud
  • Resource: a short name identifying the resource, in this case:
    • rds-sn: for RDS Subnet
  • Environment: for resources that are not to be shared between environments, a 3 letter acronym for the environment:
    • pro: production
    • pre: preproduction
    • dev: development
  • Visibility: for resources that can be either public or private, a 3 letter acronym for the visibility:
    • pub: for public resources
    • pri: for private resources
  • Name/ID: optional a name or ID that describes the usage of the resource or the number of the resource instance, for example this will be the RDS Subnet 01 for Public Zones and Pro Environment. We might have new RDS Subnets groups on the future, adding a number now will make it easier to grow the infrastructure later on.

In this example we are adding subnets located in two Availability Zones for the RDS Subnet Group, this can have an impact in costs as AWS will launch the RDS Instance in an Availability zone that might be different to the Availability Zone of the EC2 instances using the RDS Instance. See aws_rds_sn_pro.tf  for a solution.

The ditwl-rdssn-pro-pub-01 RDS Subnet Group is shown in yellow, the RDS Database can be lauched by AWS in any of the two subnets.

We are creating a RDS Subnet Group using Public Subnets as we want to be able to access the RDS Database from the Internet. In a real escenario, this is dangerous and all the databases should be in private subnets.

terraform-aws-ec2-rds-basic-free - ITWL_AWS_Terraform_VCP_RDS-SN.png

terraform.tfvars defines the RDS Subnet Group name and description. Unfortunately Terraform’s tfvars doesn’t allow interpolations as values (references to other variables, modules or functions), so the subnet_ids have to be specified in the file creating the RDS Subnet Group aws_rds_sn_pro.tf

aws_rds_sn_pub_pro_01.tf uses a module to create the RDS subnet and sets the subnet_ids to the output of a the modules that created aws_sn_za_pro_pub_32 and aws_sn_zb_pro_pub_36.

You can comment line 19 and uncomment line 21 if you want to use a single Availability Zone.

Continue the Terraform and Ansible demo, see:

Leave a Reply


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Notify of