DEV Community: Samuel Udeh

🚀 Building a Multi-Environment Web Application Infrastructure with Auto-Scaling on AWS Using Terraform

Samuel Udeh — Thu, 28 Aug 2025 15:27:43 +0000

Introduction

In today’s cloud-native world, applications need to scale dynamically, stay cost-efficient, and remain reproducible across environments (dev, staging, prod). To achieve this, I built a Multi-Environment Web Application Infrastructure with Auto-Scaling using Terraform on AWS.

This project was a hands-on demonstration of Infrastructure as Code (IaC), scalable architecture design, and DevOps automation.

🎯 Project Goals

Provision AWS infrastructure for multiple environments (dev, prod).
Automate resource creation using Terraform modules.
Deploy a simple web app served by Nginx.
Configure Application Load Balancer (ALB) + Auto Scaling Group (ASG).
Ensure traffic is distributed and scaling happens automatically under load.

🏗️ Architecture

Here’s the high-level architecture I built:

VPC with public and private subnets across multiple AZs.
Internet Gateway and NAT Gateway for proper routing.
Application Load Balancer (ALB) in public subnets.
Auto Scaling Group (ASG) in private subnets.
EC2 instances bootstrapped with user_data to install Nginx and serve a web page.
CloudWatch Alarms to scale out/in based on CPU utilization.

📌 When traffic increases → ASG scales out by launching new EC2 instances.
📌 When traffic decreases → ASG scales in, saving costs.

Prerequisites

Before you start, ensure you have:

AWS account
Terraform installed
AWS CLI installed

Authenticate Terraform With AWS

To authenticate Terraform with AWS, you can follow these steps:

Configure AWS CLI

Open your terminal, and run the following command to configure the AWS CLI:

aws configure

Enter the following details when prompted:

AWS Access Key ID: Your access key ID.
AWS Secret Access Key: Your secret access key.
Default region name: The AWS region you want to use (e.g., us-east-1).

Project Structure:

terraform-web-platform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   ├── terraform.tfvars         
│   │                 
│   └── prod/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       ├── terraform.tfvars
│       
├── modules/
│   ├── networking/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── compute/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── database/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── monitoring/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf                  
├── README.md
└── .gitignore

🛠️ Implementation with Terraform

I structured my Terraform project into reusable modules:

Network/ → VPC, Subnets, Routing, NAT
Security/ → Security Groups, Ingress/Egress rules
Compute/ → ASG, Launch Templates, User Data
Loadbalancer/ → ALB + Target Groups + Listeners

A snippet of my user_data (runs on EC2 launch):

!/bin/bash

apt-get update -y
apt-get install -y nginx
echo "Hello from ${var.environment} - ${var.project}" > /var/www/html/index.html
systemctl enable nginx && systemctl start nginx

This ensures every new EC2 instance in the ASG automatically serves a simple environment-specific message.

🔍 Testing the Setup

After applying Terraform (terraform apply), I tested the deployment:

Checked the ALB DNS Name

Terraform outputs alb_dns_name:

https://web-platform-dev-alb-495228054.eu-north-1.elb.amazonaws.com/

Opening this URL displayed my Nginx welcome message. ✅

Load Testing For Auto Scaling

I validated the Auto Scaling setup by simulating high traffic using Apache Bench. The test successfully triggered CloudWatch alarms, which in turn scaled out the Auto Scaling Group by adding EC2 instances. When traffic normalized, scale-in policies removed extra instances, ensuring efficiency and cost optimization

ab -n 1000 -c 100 http://<your-alb-dns-name>/

Explanation:

-n 1000 → Total number of requests = 1000
-c 100 → Concurrency level = 100 requests at the same time
http:/// → Target URL (the ALB’s DNS name)

At high load, CloudWatch alarms triggered scale-out.

Observed Scaling

ASG increased desired capacity.
New EC2 instances launched and registered with the ALB.
When traffic reduced, ASG scaled back in automatically.

📊 Results

✅ Highly Available: Load Balancer ensured zero downtime during scaling.

✅ Scalable: ASG responded dynamically to CPU load.

✅ Environment-Aware: Different environments (dev, staging, prod) could be deployed with the same modules.

✅ Cost-Efficient: Unused capacity scaled in automatically.

💡 Key Learnings

Modular Terraform makes infrastructure reusable and easy to extend.
CloudWatch Alarms + ASG are powerful for real-world auto-healing & scaling.
IaC ensures consistency across environments and reduces manual errors.
Testing Auto Scaling with stress/load tools validates that your setup actually works.

📌 Next Steps

Add HTTPS (TLS/SSL) with ACM + ALB.
Implement Terraform remote backend with state locking (e.g., S3 + DynamoDB or HCP Terraform).
Integrate CI/CD pipeline for infrastructure deployments.

🎉 Conclusion

This project gave me a solid foundation in building scalable, production-ready infrastructure on AWS using Terraform. It reflects real-world patterns used in modern cloud deployments and can be extended to host any kind of application.

👉 Check out the repo here: https://github.com/SamuelUdeh/terraform-aws-multi-env

Deploying a Netlify Site with Terraform + HCP Remote State

Samuel Udeh — Fri, 22 Aug 2025 11:00:23 +0000

Infrastructure as Code (IaC) is about making deployments reproducible, automated, and collaborative. In this project, I built and deployed a static website on Netlify using Terraform, while storing the Terraform state securely in HCP Terraform (Terraform Cloud).

This was part of the Terraform Challenge, and I’ll walk you through what I did and how you can replicate it.

🎯 Project Goals

Deploy a static frontend site to Netlify
Manage it with Terraform (Infrastructure as Code)
Store Terraform state in HCP Terraform (Terraform Cloud)
Keep secrets out of the repo (use workspace env vars instead)
Make the setup re-runnable and reproducible

Live Site 👉 comforting-fudge-57ff13.netlify.app

Repo 👉 github.com/SamuelUdeh/terraform-netlify-challenge

🛠 Tools I Used

Terraform → To define infrastructure as code
HCP Terraform (Terraform Cloud) → To store remote state securely
Netlify → To host the static site
GitHub → Version control + Netlify deploy hook

⚙️ How It Works

Static Site → A minimal index.html page lives in /site.
Netlify → Hosts the site, automatically deploying on every push to main.
Terraform → Manages Netlify site settings (publish dir, environment variables).
HCP Terraform → Stores state remotely, enabling collaboration and history.

Architecture Flow:

GitHub Repo ---> Netlify (Site Hosting) ---> Live URL
|
+---> Terraform ---> HCP Terraform (Remote State)

🧑‍💻 Step-by-Step Setup

Prerequisites

Terraform ≥ 1.6
Accounts: Netlify, GitHub, HCP Terraform
Netlify Personal Access Token (NETLIFY_TOKEN)

2.Create Site in Netlify

In Netlify: New site from Git → connect repo → publish directory = site

3.Configure HCP Terraform

Create Organization + Workspace
Add NETLIFY_TOKEN as a sensitive environment variable

4.Terraform Config

Example versions.tf:

terraform {
required_providers {
netlify = {
source = "netlify/netlify"
version = "~> 0.2"
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}

cloud {
organization = "your-org"
workspaces {
name = "portfolio-site-workspace"
}
}
}

outputs.tf:

output "live_url" {
value = "https://${var.site_name}.netlify.app"
}

5.Run Terraform

terraform init
terraform plan
terraform apply

Output:

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:
live_url = "https://comforting-fudge-57ff13.netlify.app"
repo = "https://github.com/SamuelUdeh/terraform-netlify-challenge"

🔑 Lessons Learned

Netlify provider doesn’t create sites (yet), you create the site in the UI once, then manage settings via Terraform.
Remote state in HCP Terraform is safer and team-ready vs local terraform.tfstate.
Keep secrets out of code, use workspace environment variables like NETLIFY_TOKEN.

Even a minimal project (simple HTML site) is enough to demonstrate IaC principles.

📸 Deliverables

✅ Repo with Terraform + site

✅ Remote state in HCP Terraform

✅ Live Netlify URL

🌟 Wrap Up

This challenge showed how simple it is to connect Terraform → Netlify → HCP Terraform and manage even small projects as Infrastructure as Code.

Try it yourself:
👉 Clone my repo, configure HCP Terraform, and run terraform apply.

Happy coding, and thanks to HUG-Ibadan for the challenge inspiration! 🙌

State Isolation: Layout vs Workspace

Samuel Udeh — Wed, 25 Dec 2024 06:51:32 +0000

Terraform State isolation refers to the practice of managing and organizing your infrastructure state files to ensure that different environments or projects do not interfere with one another. There are two ways you could isolate state files:
Isolation via workspaces
Useful for quick, isolated tests on the same configuration
Isolation via file layout
Useful for production use cases for which you need strong separation between environments.

In this blog post, we’ll focus on Workspace-based Isolation, providing examples to demonstrate its capabilities.
Isolation via Workspaces
Terraform workspaces allow you to store your Terraform state in multiple, separate, named workspaces. Terraform starts with a single workspace called “default,” and if you never explicitly specify a workspace, the default workspace is the one you’ll use
the entire time. To create a new workspace or switch between workspaces, you use the terraform workspace commands.

main.tf

provider "aws" {
region = "us-east-1" # Adjust as needed
}

resource "aws_instance" "example" {
ami = "ami-0e2c8caa4b6378d8c"
instance_type = "t2.micro"
}

resource "aws_s3_bucket" "terraform_state" {
bucket = "samley-bucket" # Ensure this name is unique across all of AWS
acl = "private" # Set the ACL for the bucket

versioning {
enabled = true # Enable versioning
}

# Enable server-side encryption
server_side_encryption_configuration {
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256" # Use S3-managed keys for encryption
}
}
}

lifecycle {
prevent_destroy = false # Prevent accidental deletion
}
}

Block public access settings for the bucket

resource "aws_s3_bucket_public_access_block" "public_access" {
bucket = aws_s3_bucket.terraform_state.id
block_public_acls = true
ignore_public_acls = true
block_public_policy = true
restrict_public_buckets = true
}

resource "aws_dynamodb_table" "terraform_locks" {
name = "state-locks"
billing_mode = "PAY_PER_REQUEST"
hash_key = "LockID"

attribute {
name = "LockID"
type = "S"
}
}

output "s3_bucket_arn" {
value = aws_s3_bucket.terraform_state.arn
description = "The ARN of the S3 bucket"
}

output "dynamodb_table_name" {
value = aws_dynamodb_table.terraform_locks.name
description = "The name of the DynamoDB table"
}

Run the terraform plan
Run the terraform apply

After creating the resources, the new backend s3 code can now be added to the configuration...

terraform {
backend "s3" {
bucket = "samley-bucket"

key = "workspaces-example/terraform.tfstate"

region = "us-east-1"

dynamodb_table = "state-locks"

encrypt = true

}
}

Run terraform init
Run terraform apply

The state for this deployment is stored in the default workspace. You can confirm this by running the terraform workspace show command,

The default workspace stores your state in exactly the location you specify via the key configuration. As shown in the Figure below, if you take a look in your S3 bucket, you’ll
find a terraform.tfstate file in the workspaces-example folder.

Managing Workspaces
You can create and switch between workspaces using the Terraform commands:

Create workspaces

terraform workspace new example1
terraform workspace new example2

Switch to a workspace

terraform workspace select example1

Plan and Apply changes to the current workspace

terraform plan
terraform apply

Terraform wants to create a totally new EC2 Instance from scratch! That’s because the state files in each workspace are isolated from one another, and because you’re now in the example1 workspace, Terraform isn’t using the state file from the default
workspace and therefore doesn’t see the EC2 Instance was already created there.
By running terraform apply, to deploy this second EC2 Instance in the new workspace.

In this example above,

The example1 workspace uses the state file example1/terraform.tfstate. The example2 workspace uses the state file example2/terraform.tfstate.

Inside each of those workspaces, Terraform uses the key you specified in your backend configuration, so you should find an example1/workspaces-example/terraform.tfstate and an example2/workspaces-example/terraform.tfstate. In other words,
switching to a different workspace is equivalent to changing the path where your statefile is stored.

To avoid unnecessary charges, delete the bucket by destroying the infrastructure using the terraform destroy command

CONCLUSION
Terraform workspaces allow you to run terraform workspace new and deploy a new copy of the exact same infrastructure, but storing the state in a separate file.
Workspace-based isolation offers a flexible way to manage multiple environments with a shared Terraform configuration. By associating each workspace with its own state file, you can ensure environment-specific changes without interference.

Let us know how you’re using Terraform workspaces in your projects! Happy Terraforming!

Managing Terraform State: Best Practices for DevOps

Samuel Udeh — Sun, 22 Dec 2024 12:35:18 +0000

Managing Terraform state is crucial for maintaining the integrity and reliability of your infrastructure as code (IaC) deployments.

The Terraform state file is a crucial component of how Terraform manages infrastructure. It acts as a source of truth for the current state of your managed resources.

This project can help teams understand and implement effective state management practices in their Terraform workflows. It aims to demonstrate best practices for managing Terraform state files in a collaborative DevOps environment. It will cover setting up a Terraform project, configuring remote state storage, applying state locking, and implementing security measures.

Objectives

Understand the structure and purpose of the Terraform state file.
Configure remote state storage using AWS S3 with state locking.
Implement best practices for managing sensitive data.
Demonstrate regular maintenance and backup strategies for state files.

Prerequisites

Basic knowledge of Terraform and infrastructure as code (IaC).
AWS account with necessary permissions.
Terraform installed on your local machine.

Tools and Technologies

Terraform
AWS (S3, DynamoDB)
Git (for version control)
HashiCorp Vault (optional for secrets management)

Step-by-Step Guide to Managing Terraform State
Step 1: Set Up the Terraform Project
Create a Project Directory:

Step 2: Set Up the AWS Provider

Step 3: Create an S3 Bucket for Remote State Storage

An S3 bucket is configured to store the Terraform state file. The prevent_destroy lifecycle rule ensures the bucket cannot be accidentally deleted

Step 4: Enable Versioning on the S3 Bucket
Versioning allows you to see older versions of the file and revert to those older versions at any time, which can be a useful fallback mechanism if something goes wrong.

Step 5: Set Up Server-Side Encryption
This ensures that your state files, and any secrets they might contain, are always encrypted on disk when stored in S3

Step 6: Block Public Access to the S3 Bucket
Block all public access to the S3 bucket to ensure no one on your
team can ever accidentally make this S3 bucket public.

Step 7: Create a DynamoDB Table for State Locking
A DynamoDB table is configured to enable state locking, which prevents concurrent updates to the state file, preventing two team members from running terraform apply on the same state file at the same time.

Backend Configuration Restrictions:
No References to Resources: In Terraform, when configuring the backend (like S3), you cannot reference resources that are defined in the same file. This is a fundamental design choice to ensure that the backend is properly initialized before any resources are created.
Direct Specification Required: You must specify the bucket name and DynamoDB table name directly in the backend configuration.
State Initialization:
If you're trying to initialize a backend that references resources not yet created, you'll get errors. You need to ensure that the backend is set up in a way that allows for its own initialization.

Steps to Resolve
Separate the Initialization:

First, create the S3 bucket and DynamoDB table in a separate configuration.
Deploy the State Management Resources: Here, you use the terraform init and terraform apply
Update the Main Configuration: After successfully creating the resources, update your main Terraform configuration to use the bucket and table names directly.

Step 8: Configure Terraform Backend
The Terraform backend stores the state in your S3 bucket with encryption and locking.

Step 9: Output Key Resource Information
These variables will print out the Amazon Resource Name (ARN) of your S3 bucket and the name of your DynamoDB table.

How Each Step Aligns with Best Practices

Remote State Storage: The S3 bucket ensures the state file is stored securely and accessible to the team.

State Locking: The DynamoDB table prevents simultaneous state modifications, avoiding conflicts.

Versioning: Versioning allows you to see older versions of the file and revert to those older versions at any time.

Encryption: AES256 encryption secures the state file.
Access Control: Public access to the S3 bucket is restricted to protect sensitive data.
Lifecycle Management: The prevent_destroy rule ensures critical resources are not accidentally deleted.

By following these steps and best practices, you can effectively manage Terraform state, enhancing the security, collaboration, and reliability of your infrastructure.

Managing high traffic applications with AWS Elastic Load Balancer and Terraform

Samuel Udeh — Fri, 20 Dec 2024 22:01:45 +0000

Introduction
Managing high-traffic applications can be a daunting challenge, especially when trying to ensure that the system is both scalable and highly available. As businesses grow and their user bases expand, the ability to scale infrastructure dynamically becomes crucial. AWS Elastic Load Balancer (ELB) is one of the most powerful tools for distributing incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, or IP addresses. When paired with Terraform, an infrastructure-as-code tool, it becomes even easier to provision, manage, and scale high-traffic applications.

What is AWS Elastic Load Balancer?
AWS Elastic Load Balancer (ELB) is a fully managed service that automatically distributes incoming application traffic across multiple targets to ensure that your application performs reliably.
AWS offers three types of load balancers:
Application Load Balancer (ALB)
Best suited for load balancing of HTTP and HTTPS traffic. Operates at the
application layer (Layer 7) of the Open Systems Interconnection (OSI) model.
Network Load Balancer (NLB)
Best suited for load balancing of TCP, UDP, and TLS traffic. Can scale up and
down in response to load faster than the ALB (the NLB is designed to scale to
tens of millions of requests per second). Operates at the transport layer (Layer 4)
of the OSI model.
Classic Load Balancer (CLB)
This is the “legacy” load balancer that predates both the ALB and NLB. It can handle HTTP, HTTPS, TCP, and TLS traffic but with far fewer features than either the ALB or NLB. Operates at both the application layer (L7) and transport layer (L4) of the OSI model.
Most applications these days should use either the ALB or the NLB. Because the simple web server example you’re working on is an HTTP app without any extreme performance requirements, the ALB is going to be the best fit.

Key Components
Elastic Load Balancer (ELB): Distributes incoming application traffic across multiple targets, such as EC2 instances.
Auto Scaling Groups (ASG): Automatically adjusts the number of EC2 instances based on traffic demands.
Health Checks: Ensures that only healthy instances receive traffic.
Security Groups: Controls access to the load balancer and backend instances.

Setting Up The Infrastructure
Step 1: Define the provider

Provider: Specifies the AWS provider and the region where the resources will be created.
Data Resource: Fetches the available availability zones for resource distribution.

Step 2: Create the VPC and Subnets

VPC: Creates a VPC with a CIDR block of 10.0.0.0/16.
Internet Gateway: Allows external access to the VPC.
Route Table: Defines routes that send traffic to the internet.
Subnets: Creates two public subnets in different availability zones for high availability.

Step 3: Create Security Groups

Security Group: Allows incoming traffic on port 80 (HTTP) from any IP address. Egress rules allow all outbound traffic.

Step 5: Create Application Load Balancer

ALB: Creates an application load balancer that distributes incoming traffic across the healthy targets. It is publicly accessible and associated with the security group and public subnets.

Step 6: Create Target Group

Target Group: Defines a group of instances that the ALB will forward traffic to. It includes health checks to monitor the status of the instances

Step 7: Create Load Balancer Listener

Listener: Configures the ALB to listen on port 80 and forward traffic to the target group.

Step 8: Create Launch Template

Launch Template: Defines the configuration for EC2 instances, including the AMI ID, instance type, and network settings.

Step 9: Create Auto Scaling Group

ASG: Manages a group of EC2 instances. It defines the desired, minimum, and maximum number of instances. It uses the launch template for configuration.

Step 10: Create Scaling Policies

Scaling Policies: Define how the ASG should respond to changes in demand. The scale-out policy increases the number of instances, while the scale-in policy decreases them.

Step 11: Create Output

Output: Displays the DNS name of the load balancer once the infrastructure is created.

Congratulations!
This Terraform configuration sets up a robust architecture for handling high-traffic applications by combining an Application Load Balancer with an Auto Scaling Group. The ALB ensures efficient traffic distribution, while the ASG automatically adjusts the number of EC2 instances based on demand. This setup enhances reliability, scalability, and performance.

Deploying a Highly Available Web App on AWS Using Terraform

Samuel Udeh — Thu, 19 Dec 2024 09:56:41 +0000

Deploying a highly available web application on AWS using Terraform involves several key components to ensure redundancy, scalability, and fault tolerance. This will guide you through deploying a clustered web server on AWS with Terraform using the Auto Scaling Group(ASG) and the Application Load Balancer.

Learning Outcome
Master deploying highly available infrastructure using Terraform by understanding the following;

Set up an Auto Scaling Group (ASG) for managing server instances.
Configure an Application Load Balancer to distribute traffic.
Use a Launch Template for consistent instance provisioning.
Test the deployment.

Overview of Components

VPC: Create a Virtual Private Cloud to host your resources.
Subnets: Use multiple availability zones with public and private subnets.
Load Balancer: Use an Application Load Balancer (ALB) to distribute traffic.
EC2 Instances: Launch instances in multiple availability zones.
Auto Scaling Group: Automatically scale your instances based on demand.
Security Groups: Control inbound and outbound traffic.

Terraform Script Overview
Below is the terraform configuration file to set up the infrastructure:
main.tf

provider "aws" {
region = "us-east-1"
}

data "aws_availability_zones" "available" {}

resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}

resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
}

resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id

route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
}

resource "aws_subnet" "public" {
count = 2
vpc_id = aws_vpc.main.id
cidr_block = "10.0.${count.index + 1}.0/24"
availability_zone = element(data.aws_availability_zones.available.names, count.index)
map_public_ip_on_launch = true
}

resource "aws_route_table_association" "public" {
count = 2
subnet_id = aws_subnet.public[count.index].id
route_table_id = aws_route_table.public.id
}

resource "aws_subnet" "private" {
count = 2
vpc_id = aws_vpc.main.id
cidr_block = "10.0.${count.index + 3}.0/24"
availability_zone = element(data.aws_availability_zones.available.names, count.index)
}

resource "aws_security_group" "web_sg" {
vpc_id = aws_vpc.main.id

ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # Consider restricting this in production
}

ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # Consider restricting this in production
}

egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}

resource "aws_lb" "app_lb" {
name = "app-lb" # Ensure this is unique
internal = false
load_balancer_type = "application"
security_groups = [aws_security_group.web_sg.id]
subnets = aws_subnet.public[*].id

# depends_on = [aws_security_group.web_sg]
}

resource "aws_launch_template" "app" {
name_prefix = "app-launch-template-"
image_id = "ami-0b0ea68c435eb488d"

instance_type = "t2.micro"

lifecycle {
create_before_destroy = true
}

network_interfaces {
associate_public_ip_address = true
security_groups = [aws_security_group.web_sg.id]
}
}

resource "aws_autoscaling_group" "app_asg" {
desired_capacity = 2
max_size = 5
min_size = 2
vpc_zone_identifier = aws_subnet.private[*].id
launch_template {
id = aws_launch_template.app.id
version = "$Latest"
}

tag {
key = "Name"
value = "app-instance"
propagate_at_launch = true
}
}

resource "aws_lb_target_group" "app_tg" {
name = "app-tg"
port = 80
protocol = "HTTP"
vpc_id = aws_vpc.main.id

health_check {
path = "/"
interval = 30
timeout = 5
healthy_threshold = 2
unhealthy_threshold = 2
}
}

resource "aws_lb_listener" "front_end" {
load_balancer_arn = aws_lb.app_lb.arn
port = 80
protocol = "HTTP"

default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app_tg.arn
}
}

output "load_balancer_dns" {
value = aws_lb.app_lb.dns_name
}

Deploying the Infrastructure
Initialize Terraform:

Review the Plan:

Apply the Configuration:

Confirm the action by typing your key_value and yes.

Verifying the Deployment

Load Balancer:

To see the DNS NAME of the ALB, you can access the AWS console or check the output from the code:

Auto Scaling

Conclusion
By leveraging Terraform, you’ve created a scalable and robust web server deployment. The Auto Scaling Group ensures high availability, while the Load Balancer distributes traffic efficiently. This setup serves as a strong foundation for more advanced infrastructure automation.

Have you tried deploying an Auto Scaling web server? Share your thoughts and experiences in the comments!

Deploying Your First Server with Terraform: A Beginner's Guide"

Samuel Udeh — Fri, 13 Dec 2024 08:29:10 +0000

Welcome to Day 3 of my Terraform learning journey! Today, I will walk through deploying your first server on AWS using Terraform. This guide is designed for beginners, so don’t worry if you’re new to infrastructure as code I've got you covered.

Why Terraform?

Terraform simplifies infrastructure management by using code to provision and manage resources. Instead of manually creating servers in the AWS console, Terraform automates this process, ensuring consistency and repeatability

What We’ll Achieve
By the end of this guide, you’ll have:

Deployed an AWS EC2 instance running a simple web server.
Configured the instance with an HTTP server (Apache) using a startup script.
Accessed your web server via a public IP.

Prerequisites:

AWS Account: Ensure you have an AWS account.
Terraform Installed: Make sure you have Terraform installed on your local machine.
AWS CLI Installed: Optional, but recommended for managing AWS resources.

Step 1: Configure AWS Credentials
Set Up AWS CLI :
Open your terminal and run the following command to configure your AWS credentials:

Enter your AWS Access Key ID, Secret Access Key, region, and output format.

Note: When you are working with AWS using Terraform, you need the Access keys and Secret Access key unlike when you are working on the AWS Console where you require passwords.

To get the Access Keys,

login into your AWS Console as IAM user
Go to your name and select security credentials
Go to access keys and click on create Access key
Select the use case as Command Line Interface
Enter the description tag, then go on to create the access key. P.S: Ensure you don't share the access keys with anyone

Step 2: Set Up Your Project

Create Project Directory
Create a new directory for your Terraform project:

mkdir terraform_project
cd terraform_project

Step 3: Create Configuration Files

main.tf: This file will contain the main configuration for your infrastructure.
variables.tf: This file is for defining variables.
outputs.tf: This file will contain outputs to display after deployment.

File Structure

terraform_project/
├── main.tf
├── variables.tf
└── outputs.tf

Write Your Terraform Configuration

main.tf

provider "aws" {
region = "us-east-1"
}

Create a VPC

resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}

Create a Public Subnet

resource "aws_subnet" "public" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
map_public_ip_on_launch = true
}

Create an Internet Gateway

resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
}

Create a Route Table for Public Subnet

resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id

route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
}

Associate the Route Table with the Public Subnet

resource "aws_route_table_association" "public_association" {
subnet_id = aws_subnet.public.id
route_table_id = aws_route_table.public.id
}

Create a Security Group

resource "aws_security_group" "allow_ssh" {
vpc_id = aws_vpc.main.id

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"]
}
}

Create an EC2 Instance

resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0" # Example AMI ID for Amazon Linux 2
instance_type = "t2.micro"
subnet_id = aws_subnet.public.id
security_groups = [aws_security_group.allow_ssh.name]

user_data = <<-EOF
#!/bin/bash
echo "Hello, World!" > /var/www/html/index.html
apt-get update
apt-get install -y apache2
systemctl start apache2
systemctl enable apache2
EOF

tags = {
Name = "WebServer"
}
}

Step 4: Deploy The Server

Initialize Terraform

Plan the deployment

Apply The Configuration

Type yes when prompted.

When successfully created ;

Step 5: Test the Deployment

Copy the public IP of your EC2 instance.
Open a browser and visit:

You should see "Hello, World" displayed on the page.

Congratulations !

You've successfully used Terraform to create EC2 instance, and also access the Apache Server through the IP Address.

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and VS Code

Samuel Udeh — Mon, 09 Dec 2024 15:10:24 +0000

A Step-by-Step Guide to Setting Up Terraform, AWS CLI, and VS Code. Whether you’re a beginner or looking to refresh your setup, this guide will walk you through installing Terraform, configuring the AWS CLI, and setting up VS Code for smooth Infrastructure as Code (IaC) workflows.

Installing Terraform:

On Windows:

Download the Terraform binary from Terraform’s official website.
Extract the binary to a directory (e.g., C:\Terraform).
Add the directory to your system’s PATH:
Open System Properties > Environment Variables.
Edit the PATH variable and add C:\Terraform.

On macOS/Linux:
Install using a package manager

Verify installation:

terraform version

Set Up the AWS CLI
The AWS CLI allows Terraform to communicate with AWS for provisioning resources.

Installation:
1.Download the AWS CLI from AWS CLI Installation Guide.
2.Follow the installation steps for your OS.

Verify AWS CLI

Configuration
Run the following command to configure the CLI:

aws configure

Provide your Access Key ID, Secret Access Key, Region, and output format (e.g., json).

Test the configuration:
use the command "aws s3 ls"
If this works, your AWS CLI is ready to go!

Install and Configure VS Code

VS Code is a lightweight and powerful editor perfect for Terraform projects.

Installation
Download VS Code from VS Code's website.

Install Terraform extensions:

Open VS Code.
Go to Extensions (Ctrl+Shift+X or Cmd+Shift+X).
Search for and install "HashiCorp Terraform".
Optional Extensions for Productivity
AWS Toolkit: For managing AWS services directly from VS Code.
Prettier: For consistent formatting of your Terraform code.

What is Infrastructure as Code (IaC) and Why It's Transforming DevOps

Samuel Udeh — Sun, 08 Dec 2024 14:32:50 +0000

Infrastructure as Code (IaC) is a modern approach to managing and provisioning computing infrastructure through code and automation tools rather than manual processes. This practice enables developers and operations teams to define infrastructure in a descriptive manner, making it easy to deploy and manage.

The idea behind infrastructure as code (IaC) is that you write and execute code to define, deploy, update, and destroy your infrastructure.

WHY IT IS TRANSFORMING DevOpS

. According to the 2016 State of DevOps Report, organizations that use DevOps practices, such as IaC, deploy 200 times more frequently, recover from failures 24 times faster, and have lead times that are 2,555 times lower.
When your infrastructure is defined as code, you are able to use a wide variety of software engineering practices to dramatically improve your software delivery process, including the following:

Self-service

Most teams that deploy code manually have a small number of sysadmins (often,
just one) who are the only ones who know all the magic incantations to make the
deployment work and are the only ones with access to production. This becomes
a major bottleneck as the company grows. If your infrastructure is defined in
code, the entire deployment process can be automated, and developers can kick
off their own deployments whenever necessary.

Speed and safety

If the deployment process is automated, it will be significantly faster, since a computer can carry out the deployment steps far faster than a person, and safer, given that an automated process will be more consistent, more repeatable, and not prone to manual error.

Documentation

If the state of your infrastructure is locked away in a single sysadmin’s head, and that sysadmin goes on vacation or leaves the company or gets hit by a bus, you may suddenly realize you can no longer manage your own infrastructure. On the other hand, if your infrastructure is defined as code, then the state of your infrastructure is in source files that anyone can read. In other words, IaC acts as documentation, allowing everyone in the organization to understand how things work, even if the sysadmin goes on vacation.

Version control

You can store your IaC source files in version control, which means that the entire history of your infrastructure is now captured in the commit log. This becomes a powerful tool for debugging issues, because any time a problem pops up, your first step will be to check the commit log and find out what changed in your infrastructure, and your second step might be to resolve the problem by simply reverting back to a previous, known-good version of your IaC code.

Validation

If the state of your infrastructure is defined in code, for every single change, you can perform a code review, run a suite of automated tests, and pass the code through static analysis tools—all practices that are known to significantly reduce the chance of defects.

Reuse

You can package your infrastructure into reusable modules so that instead of doing every deployment for every product in every environment from scratch, you can build on top of known, documented, battle-tested pieces.

Happiness

There is one other very important, and often overlooked, reason for why you should use IaC: happiness. Deploying code and managing infrastructure manually is repetitive and tedious. Developers and sysadmins resent this type of work, since it involves no creativity, no challenge, and no recognition. You could deploy code perfectly for months, and no one will take notice—until that one day when you mess it up. That creates a stressful and unpleasant environment.
IaC offers a better alternative that allows computers to do what they do best(automation) and developers to do what they do best (coding).