DEV Community: Ian Gitonga

Deploying a Highly Available Web App on AWS Using Terraform

Ian Gitonga — Mon, 23 Mar 2026 13:33:56 +0000

Introduction

Running a single server is a good start, but in the real world, a single server is a single point of failure. If that server crashes, or if it becomes overloaded from too much traffic, users will be unable to access your site. The solution is to run a cluster of
servers, routing around servers that go down and adjusting the size of the cluster up or down based on traffic.

Managing such a cluster manually is a lot of work. Fortunately, you can let AWS take care of it for you by using an Auto Scaling Group (ASG). An ASG takes care of a lot of tasks for you completely automatically, including launching a cluster of EC2 Instances, monitoring the health of each instance, replacing failed instances and adjusting the size of the cluster in response to load.

Create repository This is how i have organized my project:

terraform/
├── main.tf                      # All resource definitions
├── variables.tf                 # Variable declarations
└── README.md

Define Variables To allow you to make your code more DRY_(Don't Repeat Yourself)_ and more configurable, Terraform allows you to define input variables.

variable "server_port" {
    description = "The port the server will use for HTTP requests"
    type = number
    default = 8080
}
variable "ami_id" {
  description = "Amazon Machine Image (AMI) ID for the EC2 instance"
  type = string
  default = "ami-0aaa636894689fa47"
}

You'll define the above inside variables.tf file.

Using Auto Scaling Group ASG An ASG takes care of a lot of tasks for you completely automatically, including launching a cluster of EC2 Instances, monitoring the health of each Instance, replacing failed instances and adjusting the size of the cluster in response to load. The first step in creating an ASG is to create a launch tempalte in main.tf.

resource "aws_launch_template" "instance1" {
  image_id = var.ami_id
  instance_type = var.instance_type
  vpc_security_group_ids = [aws_security_group.instanceSecurityGroup.id]

  user_data = base64encode(<<-EOF
              #!/bin/bash
              echo "Hello, World" > index.html
              nohup busybox httpd -f -p ${var.server_port} &
              EOF
            )

  # Required when using a launch configuration with an auto scaling group.
  lifecycle {
    create_before_destroy = true
  }
}

Now you can create the ASG itself using the aws_autoscaling_group resource:

resource "aws_autoscaling_group" "asg1" {
  launch_template {
      id      = aws_launch_template.instance1.id
      version = "$Latest"
  }

  vpc_zone_identifier = data.aws_subnets.default.ids

  min_size = 2
  max_size = 5

  tag {
    key = "Name"
    value = "terraform-asg-example"
    propagate_at_launch = true
  }
}

There’s also one other parameter that you need to add to your ASG to make it work: subnet_ids. This parameter specifies to the ASG into which VPC subnets the EC2 instances should be deployed. Each subnet lives in an isolated AWS AZ (that is, isolated datacen‐
ter), so by deploying your Instances across multiple subnets, you ensure that your service can keep running even if some of the datacenters have an outage. You could hardcode the list of subnets, but that won’t be maintainable or portable, so a better
option is to use data sources to get the list of subnets in your AWS account.

data "aws_vpc" "default" {
  default = true
}

data "aws_subnets" "default" {
  filter {
    name = "vpc-id"
    values = [data.aws_vpc.default.id]
  }
}

Creating EC2 Instances If this is a new project you'll need to first run this command:

terraform init

However, if you've had initiated before you can apply the changes:

terraform apply

Conclusion

And with that we are able to deploy more than one instance. Throughout this series, we'll see how the right combination of Auto Scaling Groups, launch templates, security groups, and multi-AZ networking can transform a fragile single-instance setup into a resilient, self-healing system.

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

Ian Gitonga — Thu, 19 Mar 2026 17:03:13 +0000

Introduction

What if provisioning a server took less time than brewing your morning coffee?
That's the promise of Infrastructure as Code (IaC) and Terraform makes good on it. Instead of clicking through cloud dashboards or memorizing provider specific CLIs, you write a configuration file, run two commands, and your infrastructure exists.
In this guide, we'll build something real: a running EC2 instance on AWS, defined entirely in Terraform. You don't need a background in DevOps or cloud architecture — just a willingness to write a little code and watch it come to life.

1. Setting up your project
Create a directory for your project:

mkdir terraform-first-server

2. Create your terraform file
Inside your directory create a file main.tf. Inside configure a provider you want to use.

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

This tells Terraform that you are going to be using AWS as your provider and that you want to deploy your infrastructure into the us-east-2 region.

3. Add resources to your provider
For each type of provider, there are many different kinds of resources that you can create, such as servers, databases, and load balancers.

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

4. Initialize Terraform
In your terminal, run:

terraform init

the command tells Terraform to scan the code, figure out which providers you’re using, and download the code for them.

5. Checkout the plan
Run the command below (Optional):

terraform plan

The plan command lets you see what Terraform will do before actually making any changes. This is a great way to sanity-check your code before unleashing it onto
the world.

6. Create instance
To actually create the Instance, run the the command:

terraform apply

You’ll notice that the apply command shows you the same plan output and asks you to confirm whether you actually want to proceed with this plan. So, while plan is available as a separate command, it’s mainly useful for quick sanity checks and during code reviews.

Congrats, you’ve just deployed an EC2 Instance in your AWS account using Terraform! To verify this, head over to the EC2 console,

7. Destroy the instance
To avoid extra AWS charges, destroy the infrastructure when you’re done:

terraform destroy

Conclusion

What started as a configuration file is now a live server running in the cloud. No console clicking, no guesswork, no waiting on someone else to provision an environment for you. Just code, a couple of commands, and a result you can see, version, and reproduce.

The coffee's probably still warm. Not bad for an afternoon's work.

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

Ian Gitonga — Wed, 18 Mar 2026 14:48:43 +0000

Setting Up Your AWS Account
If you don’t already have an AWS account, head over to https://aws.amazon.com and sign up. When you first register for AWS, you initially sign in as the root user. This user account has access permissions to do absolutely anything in the account, so
from a security perspective, it’s not a good idea to use the root user on a day-to-day
basis.

You'll need to use the Identity and Access Management (IAM) service. To create a new IAM user;

Go to the IAM Console.
Click Users and then click the Add Users button.
Enter a name for the user and make sure “Access key - Programmatic access” is selected.
Click the Next button.

AWS will ask you to add permissions to the user. By default, new IAM users have no permissions whatsoever and cannot do anything in an AWS account. To give your IAM user the ability to do something, you need to associate one or more IAM Policies with that user’s account.

Click Next a couple more times and then the “Create user” button.

AWS will show you the security credentials for that user, which consist of an Access Key ID and a Secret Access Key. You must save these immediately because they will never be shown again.

Installing Terraform
The easiest way to install Terraform is to use your operating system’s package manager. For my case since its macOS i use Homebrew.

$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform

To check if terraform is properly installed run this command
terraform --version

Install and Configure the AWS CLI

Download the package installer using curl in your terminal

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

Run the installer

sudo installer -pkg AWSCLIV2.pkg -target /

Verify the installation

aws --version

Now to configure aws cli to your AWS account. This will also prompt you for 4 things. You'll get these credentials from the IAM user we created earlier.

aws configure

AWS Access Key ID [None]: AKIA...
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxx
Default region name [None]: us-east-1
Default output format [None]: json

Verify this works. The command below will return your account info.

aws sts get-caller-identity

Conclusion
Just like that your setup for Terraform and AWS CLI is complete.

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

Ian Gitonga — Tue, 17 Mar 2026 12:30:54 +0000

What IaC is and the problem it solves
The idea behind infrastructure as Code (IaC) is that you write and execute code to define, deploy, update and destroy your infrastructure. This represents an important shift in mindset in which you treat all aspects of operations as software, even those aspects that represent hardware e.g setting up physical servers. A key insight is that you can manage almost everything in code like; servers, databases, network, application configuration, documentation, automated tests, deployment processes etc.

Now a good question to ask is why bother?

Self-service

Most teams that deploy code manually have a small number of system admins 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. Also it's safer given that an automated process will be more consistent, more repeatable and not prone to manual error.

Documentation

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 system admin isn't available which happens sometimes.

Version control

IaC source files can be stored in version control. 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 can resolve problem by reverting back.

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.

The difference between declarative and imperative approaches
Imperative approach
This is a style you write code that specifies, step by step, how to achieve some desired end state.

- ec2:
    count: 10
    image: ami-0fb653ca2d3203ac1
    instance_type: t2.micro

Declarative approach
In this style you write code that specifies your desired end state,
and the IaC tool itself is responsible for figuring out how to achieve that state.

resource "aws_instance" "example" {
  count = 10
  ami = "ami-0fb653ca2d3203ac1"
  instance_type = "t2.micro"
}

Note: The code snippets represent this;
I want to deploy 10 EC2 instances to run AMI with ID ami-0fb653ca2d3203ac1 (Ubuntu 22.04).

Why Terraform is worth learning
Terraform is worth learning because it removes a lot of pain you don’t realize is avoidable unless you hear of it's capability or even get to use it. Instead of guessing or repeating manual steps, you just write down what your infrastructure should look like, and it handles the rest. The big win is consistency, you can spin up the same setup today, next week or on someone else’s machine and get the same result.

Your personal goals for this 30-day challenge

Get comfortable enough to use Terraform without overthinking it.
Be able to spin up and tear down real infrastructure confidently.
Understand what’s happening under the hood (not just copy-paste configs).
We all talk about scalability, this is my part of the journey in understanding that.

At the end of it, I just want to reach a point where if I need infra, I don’t hesitate....I just write it.