Press enter or click to view image in full size

A hands-on implementation of an Application Load Balancer routing HTTP traffic to an EC2-hosted Nginx service — laying the groundwork for scalable application delivery.

3 min read18 hours ago

–

Introduction

Day 24 of the KodeKloud AWS Challenge focused on introducing an Application Load Balancer (ALB) in front of an EC2 instance running Nginx.

This is a core production pattern. You never expose application servers directly to users. You put a load balancer in front — whether you’re serving one instance today or fifty tomorrow.

The task was to:

• Create an ALB
• Route HTTP traffic (port 80) to an EC2 instance
• Configure security groups correctly on both ends

Simple in theory. Critical in practice.

Concept Explanation: Application Load Balancer (ALB)

An Application Load Balancer operates at Layer 7 (HTTP/HTTPS) and routes traffic based on request attributes such as:

• Host headers
• Paths
• Ports

In Amazon Web Services, ALBs are used to:

• Decouple traffic from backend servers
• Enable horizontal scaling
• Provide a single stable entry point
• Integrate cleanly with auto scaling, SSL, and health checks

If you plan to scale or update applications without downtime, ALB is non-negotiable.

Why This Matters in Real Environments

Putting ALB in front of EC2 enables:

• Zero-downtime deployments
• Backend replacement without DNS changes
• Traffic control and observability
• Cleaner security boundaries

Direct EC2 exposure is fine for labs. In production, it’s a liability.

Prerequisites / Gotchas

Common mistakes engineers make at this stage:

• Forgetting to open port 80 on the EC2 security group
• Attaching the wrong security group to the ALB
• Misconfigured target group health checks
• Assuming ALB forwards traffic without explicit listener rules

Security groups must be intentionally designed, not guessed.

Hands-On Task: What I Did

1️⃣ Created a Security Group for the ALB

• Created a security group named devops-sg
• Allowed inbound HTTP (port 80) from the public
• Attached this security group to the ALB

Press enter or click to view image in full size

This ensures users can reach the load balancer.

2️⃣ Created the Target Group

• Created a target group named devops-tg
• Target type: Instance
• Protocol: HTTP
• Port: 80
• Registered the EC2 instance (devops-ec2) as a target

Press enter or click to view image in full size

This defines where the ALB sends traffic.

3️⃣ Set Up the Application Load Balancer

• Created an ALB named devops-alb
• Internet-facing
• Listener configured on port 80
• Forward action set to devops-tg
• Attached security group devops-sg

Press enter or click to view image in full size

This completed the traffic entry point.

4️⃣ Updated EC2 Security Group

• Ensured the EC2 security group allows:
• Inbound port 80
• Source: ALB security group (devops-sg)

Press enter or click to view image in full size

This is critical. ALB → EC2 traffic is still subject to security group rules.

What I Learned / Key Takeaways

• ALB should always sit in front of application servers
• Security groups must allow ALB-to-EC2 traffic explicitly
• Target groups define backend behavior — not the ALB itself
• Even single-instance setups should follow scalable patterns
• Good architecture starts early, not “later”

This is how small systems grow safely.

Conclusion

Deploying an Application Load Balancer is a design decision, not just a configuration task.

Get Kishor Bhairat’s stories in your inbox

Join Medium for free to get updates from this writer.

This challenge reinforced a production-grade principle: Applications should be replaceable; entry points should be stable.

With ALB in place, the infrastructure is now ready for:

• Scaling
• Blue/green deployments
• Real application rollout

On to the next challenge.

Call to Action

If you’re learning AWS or DevOps through hands-on, architecture-focused challenges, follow the journey. This series focuses on building infrastructure the way real teams do.