Featured image of post Scale Deployments Horizontally in AWS-Iac

Scale Deployments Horizontally in AWS-Iac

Terraform + Auto Scaling Groups (ASG) + Elastic Load Balancers (ELB)


A Brief History of Infrastructure as Code

The Dark Ages (Pre-IaC Era)

Back in the ancient times (aka before IaC), developers and sysadmins had to manually configure servers, databases, and networking. This usually involved:

  1. Clicking around in AWS like it’s a game of Minesweeper.
  2. Copy-pasting long bash scripts that broke when your colleague looked at them wrong.
  3. Manually provisioning infrastructure and forgetting how you did it when things went down.

In short: it was chaotic, error-prone, and not scalable. 😵

The Rise of IaC (2010s - Present)

Then came the heroes of Infrastructure as Code:

  • AWS CloudFormation (2011): AWS’s first attempt at automation using JSON/YAML.
  • Terraform (2014): HashiCorp introduced Terraform, bringing a multi-cloud, declarative IaC approach.
  • Pulumi, Ansible, and CDK: The IaC family expanded with more flexible tools.

Now, DevOps engineers could manage infrastructure the same way developers manage code—with version control, repeatability, and automation. 🎉


What is Infrastructure as Code? 🤔

Infrastructure as Code (IaC) is the practice of defining and managing cloud infrastructure using configuration files instead of manually setting things up.

Key benefits:

Automation: No more clicking through AWS Console like a lost tourist.

Version Control: Infrastructure changes are tracked in Git—no more “it worked on my machine” excuses.

Repeatability: Deploy the same stack across different environments effortlessly.

Scalability: Spin up 100 servers with a single command (or by accident—oops 🤭).

IaC is typically declarative (you define the desired state, and the tool figures out how to get there). The most popular tools include:

  • Terraform 🏗️ (multi-cloud, declarative HCL)
  • AWS CloudFormation ☁️ (AWS-only, YAML/JSON)
  • Pulumi (uses real programming languages)
  • Ansible (great for server configuration)

How to Deploy Applications in AWS Using IaC

Now that we understand IaC, let’s get our hands dirty with some examples. 🛠️

1. Deploying an EC2 Instance with Terraform

Terraform is an awesome IaC tool that lets you manage AWS, Azure, GCP, and more with a single config file.

📜 Terraform example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "my_server" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"

  tags = {
    Name = "MyTerraformInstance"
  }
}

Run it:

1
2
terraform init
terraform apply

Your EC2 instance is now automated and repeatable. 🚀

!!!!
Cool eh?


2. Deploying an S3 Bucket with AWS CloudFormation

AWS CloudFormation lets you define AWS infrastructure using YAML or JSON.

📜 CloudFormation template:

1
2
3
4
5
6
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  MyS3Bucket:
    Type: "AWS::S3::Bucket"
    Properties:
      BucketName: "my-cloudformation-bucket"

Deploy it:

1
aws cloudformation deploy --template-file template.yaml --stack-name MyS3Stack

You now have an S3 bucket without touching the AWS console. 🎉

!!!!!!
very cool…
!!!!!!


How to Scale Deployments Horizontally in AWS

Scaling horizontally means adding more instances rather than making a single instance more powerful. This is crucial for handling increased loads efficiently.

Using Auto Scaling Groups and Load Balancers

AWS provides Auto Scaling Groups (ASG) and Elastic Load Balancers (ELB) to distribute traffic and automatically add/remove instances based on demand.

📜 Terraform Example for Auto Scaling:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
resource "aws_launch_configuration" "my_app" {
  name          = "my-app-config"
  image_id      = "ami-12345678"
  instance_type = "t2.micro"
}

resource "aws_autoscaling_group" "my_asg" {
  launch_configuration = aws_launch_configuration.my_app.id
  min_size             = 2
  max_size             = 10
  desired_capacity     = 3
  vpc_zone_identifier  = ["subnet-abc123"]
}

This setup ensures more instances are added automatically when needed and removed when traffic decreases. 🚀


Pros and Cons of NOT Using IaC

The Nightmare of Manual Deployment

Without IaCWith IaC
Manually provisioning servers ☠️Automate everything with scripts 🎉
Hard to replicate environmentsDeploy the same infra repeatedly
Prone to human errorsVersion-controlled infrastructure
Scaling means manually launching new instancesAuto Scaling ensures dynamic scaling
Debugging is painfulLogs and state management make troubleshooting easy

If you don’t use IaC, scaling becomes a tedious, manual nightmare. Imagine adding 50 EC2 instances manually while your website crashes—yeah, no thanks. 😅


Key Ideas Table

ConceptExplanation
Infrastructure as CodeManaging infrastructure with configuration files instead of manual processes.
TerraformA multi-cloud declarative IaC tool using HCL.
AWS CloudFormationAWS-native IaC tool using YAML/JSON.
Benefits of IaCAutomation, repeatability, scalability, and version control.
Horizontal ScalingAdding more instances dynamically using Auto Scaling Groups.
Example DeploymentsTerraform for EC2, CloudFormation for S3, ASG setup for scaling.
Cons of No IaCManual errors, lack of version control, slow scaling, and chaos.