3 Tier Web Architecture in AWS [Part 1]

3 Tier Web Architecture in AWS

Today, we’ll be creating the above architecture using terraform. Terraform is a popular IaC tool that uses Hashicorp Configuration Language behind the scenes.

Now some of you might be wondering why it is called a “3 Tier Web Architecture” ?

assistant to the regional manager

Well if you look closely at the above diagram, you’ll observe 3 vertical segments. Each represents a tier of our web architecture.
The first is the “web-tier” which consists of everything that is present in the 2 public subnets i.e bastion hosts, load balancer nodes, nat gateways, internet gateways, etc. The second is the “application-tier” which consists of the application servers residing in the 2 private subnets under an autoscaling group. The third is the “database-tier” consisting of RDS and Elasticahe databases present in the private subnet with which our application servers will interact.

Whoa, that is a lot of details, don’t worry.

I’ll start by explaining one by one all the different terraform modules which constitute our architecture and then we’ll combine them all together in a single main.tf.

1. Networking Module:
   Create a folder networking_module in the root of your working directory and add the below files one by one.

input_variable.tf declares the necessary input variables that will be used by the different resources in the networking_module

vpc.tf creates 2 VPCs internal_systems_vpc and wholesale_vpc with CIDRs 10.0.0.0/16 and 10.1.0.0/16 respectively

eip.tf creates 3 elastic IPs.

subnet.tf creates a total of 8 subnets. 2 public and 4 private subnets in the wholesale_vpc and 1 public and 1 private subnet in the internal_systems_vpc.

endpoints.tf creates 2 gateway endpoints for s3 in the above 2 VPCs. This endpoint will enable private connectivity to s3 buckets without letting the traffic traverse the internet thus making our architecture more secure.

internet_gateway.tf creates 1 internet gateway each in the above 2 VPCs. This will let traffic from the internet reach our public subnets. 1 internet gateway per VPC is enough because they are highly available by default.

nat_gateway.tf creates 1 nat gateway each in the 3 public subnets. We are creating 1 nat gateway per public subnet because if 1 AZ goes down, it should not affect traffic flow to the other subnets/AZs in our VPC thus making our architecture fault-tolerant and highly available. The depends_on make sure that the nat gateway is created after the internet gateway.

nacl.tf creates 1 nacl per VPC. We can even have 1 nacl per subnet for more granularity and restriction on the traffic flow at the subnet level, but for the sake of simplicity, we are creating 1 nacl per VPC.

peering_connection.tf creates a peering connection between internel_systems_vpc and wholesale_vpc. This lets you communicate between the 2 VPCs using private IP addresses and the traffic never leaves the AWS network. Inter-region traffic is encrypted.

route_table.tf creates 2 route tables in the internel_systems_vpc and 3 route tables in the wholesale_vpc . These route tables have routes for the different resources created above like internet gateways, nat gateways, vpc endpoints, peering connections, etc. Then we associate these route tables to the different subnets and endpoints defined above using the aws_route_table_association and aws_vpc_endpoint_route_table_association resource.

security_group.tf creates various security groups and security group rules for the different resources we’ll be creating in the coming modules like load balancers, bastion hosts, application servers, relational databases, caches, etc. Replace the cidr_block with your IP in the wholesale_bastion_sg security group.

output.tf creates various outputs for cidr_blocks, security_groups_ids, subnet_ids, etc. These will come in handy when we will be creating resources like load balancers, databases, etc in the forthcoming modules. Basically, we are referencing/sharing data from one module to another module.

This completes our networking module :)

As the networking module was quite big, I’ll be adding the other modules in the second part of the “3 Tier Web Architecture in AWS” series.

For any questions/suggestions please add your comments and if you liked the content, please give this blog a clap 👏.