Day 68: Scaling with Terraform 🚀
Day#68 Of 90 Days Of DevOps Challenge

Experienced QA professional with a passion for manual and automation testing. Proficient in DevOps practices, ensuring seamless integration and continuous delivery. Dedicated to ensuring top-notch software quality and efficiency. Eager to contribute my skills to Hashnode's vibrant tech community. Let's collaborate and create exceptional experiences!
👋Introduction
The ability to scale your infrastructure is fundamental to meeting the evolving requirements of your applications.
As your application expands, there's a need to allocate additional resources to manage heightened workloads, and when demand decreases, optimizing costs by eliminating excess resources becomes imperative.
In this blog post, we'll explore how Terraform, a renowned Infrastructure as Code (IAC) tool, simplifies the process of scaling your infrastructure on AWS.
Before we delve into the intricacies of scaling, it's essential to establish the foundational elements of our infrastructure.
We'll leverage AWS as our cloud provider and articulate our resources using Terraform.
Crafting an AWS Provider Configuration
In your project directory, initiate a file named provider.tf and inject the subsequent code:
provider "aws" {
region = "ap-south-1"
}
It's crucial to substitute the placeholders for access_key and secret_key with your AWS credentials.
Specifying Terraform and AWS Provider Versions
Forge a file named terraform.tf to define the essential versions of Terraform and the AWS provider:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}
required_version = ">=1.2.0"
}
This file explicitly specifies the necessary Terraform version and the compatible AWS provider version.
Constructing a Virtual Private Cloud (VPC)
To establish a Virtual Private Cloud (VPC) with a CIDR block of 10.0.0.0/16, fabricate a file named vpc.tf and embed the ensuing code:
resource "aws_vpc" "day68_main_example" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "main_example"
}
}
Shaping Public Subnets
Proceed to create public subnets within the VPC. Formulate a file named public_subnet.tf and infuse the subsequent code:
resource "aws_subnet" "public_subnet_1" {
vpc_id = aws_vpc.day68_main_example.id
cidr_block = "10.0.1.0/24"
tags = {
Name = "public subnet 1"
}
}
resource "aws_subnet" "public_subnet_2" {
vpc_id = aws_vpc.day68_main_example.id
cidr_block = "10.0.2.0/24"
tags = {
Name = "public subnet 2"
}
}
These configurations facilitate the establishment of two public subnets within the VPC.
Erecting an Internet Gateway
To enable your VPC to connect to the Internet, it's necessary to create an Internet Gateway (IGW). Create a file named igw.tf and append the ensuing code:
resource "aws_internet_gateway" "internet_gateway" {
vpc_id = aws_vpc.day68_main_example.id
tags = {
Name = "internet_gateway_devops"
}
}
This code sets up an Internet Gateway for your VPC.
Fashioning a Route Table
To ensure the smooth flow of traffic from your public subnets to the Internet Gateway, a route table is required. Create a file named route_table.tf and integrate the subsequent code:
resource "aws_route_table" "route_table" {
vpc_id = aws_vpc.day68_main_example.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.internet_gateway.id
}
tags = {
Name = "route_table_devops"
}
}
resource "aws_route_table_association" "public_subnet_association_1a" {
subnet_id = aws_subnet.public_subnet_1.id
route_table_id = aws_route_table.route_table.id
}
resource "aws_route_table_association" "public_subnet_association_1b" {
subnet_id = aws_subnet.public_subnet_2.id
route_table_id = aws_route_table.route_table.id
}
This code delineates a route table for the public subnets and establishes associations to enable internet connectivity.
Creating a Security Group
For our EC2 instances, we necessitate a security group to manage inbound and outbound traffic. Generate a file named security_group.tf and inject the ensuing code:
resource "aws_security_group" "web_server_grp" {
name_prefix = "web-server-sg"
vpc_id = aws_vpc.day68_main_example.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
This code establishes a security group for our EC2 instances, granting permission for HTTP (port 80) and SSH (port 22) traffic.
❄Scaling Your Infrastructure
With the groundwork laid, we can now turn our attention to scaling.
Our objective is to create an Auto Scaling Group that dynamically adjusts the number of EC2 instances based on demand.
Crafting an Auto Scaling Group
Generate a file named autoscaling.tf and introduce the ensuing code:
resource "aws_launch_configuration" "web_server_launch1" {
name = "web_server_launch1"
image_id = "ami-0f5ee92e2d63afc18"
instance_type = "t2.micro"
security_groups = [aws_security_group.web_server_grp.id]
associate_public_ip_address = true
user_data = <<-EOF
#!/bin/bash
echo "<html><body><h1>Welcome to Terraform</h1></body></html>" > index.html
nohup python -m SimpleHTTPServer 80 &
EOF
}
resource "aws_autoscaling_group" "web_server_asg1" {
name = "web_server-asg"
launch_configuration = aws_launch_configuration.web_server_launch1.name
min_size = 1
max_size = 3
desired_capacity = 2
health_check_type = "EC2"
vpc_zone_identifier = [
aws_subnet.public_subnet_1.id, aws_subnet.public_subnet_2.id
]
}
This code constructs an Auto Scaling Group that automatically fine-tunes the number of EC2 instances based on demand. It leverages the launch configuration defined earlier.
Applying Terraform
Having articulated your infrastructure and scaling components, the next step is to initialize and apply your Terraform configuration.
In your terminal, execute the following commands:
terraform init
terraform plan
terraform apply
These commands will kickstart Terraform and apply the configuration, thereby creating the designated resources on AWS.

Testing Scaling
Now that your infrastructure is in place, it's time to evaluate the scalability.
📜Task 1: Creating an Auto-Scaling Group
Verify the desired capacity of the Auto Scaling Group by navigating to the AWS Management Console.


📜Task 2: Testing Scaling
In the AWS Management Console, access the Auto Scaling Groups service.
Opt for the Auto Scaling Group you created and click on the "Edit" button.

Enhance the "Desired Capacity" to 3 and save your changes.


Wait for a few minutes for the new instances to be launched and confirm their operational status.

Reduce the "Desired Capacity" to 1 and wait for the excess instances to be terminated.

Visit the EC2 Instances service and confirm the termination of the surplus instances.

💥Conclusion
Scaling your infrastructure is pivotal in managing contemporary applications.
The combination of Terraform and AWS provides a potent framework for dynamically adjusting your resources to cater to shifting demands.
By adhering to the steps delineated in this blog post, you can forge a scalable infrastructure that adeptly adapts to your application's requisites, ensuring optimal performance and cost-effectiveness.
Happy learning & may your DevOps journey be filled with exciting discoveries🎊
Thank you for joining us on this exciting Day 68 of the 90 Days of DevOps challenge. I hope you found the information helpful and insightful.💥
So please keep yourself updated with my latest insights and articles on DevOps 🚀 by following me on :
Hashnode: vishaltoyou.hashnode.dev
LinkedIn: linkedin.com/in/vishalphadnis




