Building Scalable Web Apps on AWS: My Hands-On Journey with ALBs, ASGs, and Custom VPCs

Deepak Soni — Thu, 24 Jul 2025 00:46:16 +0000

Posted at 5 AM, after another late-night deep dive into the cloud.

After learning from a painful mistake last night (read my previous post if you're curious), I promised myself to rebuild everything from scratch today, this time the right way.

And I did. I combined my learnings from the past two days: Application Load Balancers and Auto Scaling Groups into one working mini project.

🛠️ What I Built

To keep it structured, here’s what the setup looked like:

VPC Setup: Created a custom VPC with 3 public and 3 private subnets (spread across multiple Availability Zones for high availability).
Internet & NAT Gateways:
- Attached an Internet Gateway (IGW) to allow public access to public subnets.
- Deployed one NAT Gateway per public subnet to route internet traffic for the private subnets securely.
Routing & Security:
- Created Route Tables and associated them with respective subnets.
- Configured Security Groups for public-facing and internal components.
Flask App & Launch Template:
- Set up a simple Flask server running on port 8080.
- Created a custom AMI from this EC2 instance.
- Used it to define an EC2 Launch Template.
Target Group & Load Balancer:
- Created a Target Group pointing to instances in the private subnets on port 8080.
- Deployed an Application Load Balancer (ALB) in the public subnets and connected it to the target group.
Auto Scaling Group (ASG):
- Configured the ASG using the launch template and attached it to the target group.
- This enabled instances to scale in and out automatically based on demand.
Bastion Host for Debugging:
- Deployed a Bastion EC2 instance in a public subnet with a public IP.
- Used it to SSH into the private EC2 instances for validation and debugging.

✅ Final Result

The Application Load Balancer started successfully routing traffic to EC2 instances launched by the Auto Scaling Group. Each response was coming from a different instance depending on the load, a satisfying sight after a night of building.

🌙 Reflection

Compared to yesterday, this build felt cleaner and more intentional. Every service was tested step-by-step before stitching them together. A reminder that in the cloud (and in life), skipping fundamentals can cost you time, but every mistake brings clarity.

📌 Tech Stack

AWS EC2, VPC, IGW, NAT Gateway
Application Load Balancer (ALB)
Auto Scaling Groups (ASG)
Flask (Python)
Custom AMIs & Launch Templates

💬 Let’s Connect

Have you tried setting up ASGs + ALBs from scratch before? Got tips for a smoother setup or common pitfalls? Let’s chat in the comments!

AWS Auto Scaling Groups: A Fundamental Mistake (Beginner Edition)

Deepak Soni — Tue, 22 Jul 2025 10:49:51 +0000

The Mistake

It was 5 AM. I was tired, a bit overconfident, and really wanted to see my ASG + ALB setup in action. So I skipped a pretty important step - testing the EC2 Launch Template, and jumped straight into building the full infrastructure.

Once everything was up, I opened the ALB’s DNS URL… and saw a blank page.

After some digging, I realized: the EC2 Launch Template I used didn’t have my server. It was empty. That’s when I learned that launch templates don’t store your file system. If you want your server to work, you need to create a proper AMI or add user data to install everything during boot.

The Story

I was learning about AWS Auto Scaling Groups (ASGs). I already had a decent understanding of VPCs, subnets, route tables, IGWs, and NAT Gateways. I’d also played around with Application Load Balancers (ALBs) in a small project that used three EC2 instances.

So I thought - why not combine it all? I decided to build a mini project using both ASGs and ALBs to create a scalable infrastructure setup.

Here’s what I did:

Created a new custom VPC for the project
Set up 3 public subnets and 3 private subnets, each in a different Availability Zone for high availability
Attached an Internet Gateway (IGW) to the VPC and linked it to the public subnets via route tables
Created 3 separate NAT Gateways (one in each public subnet) and connected them to the private subnets in the same AZ — because my EC2 instances were in the private subnets, and they also needed egress internet access for downloading packages, configuration files, etc.
Created a Target Group for EC2 instances, set it to listen on port 8080
Deployed an Application Load Balancer (ALB) in the public subnets and attached it to the target group
Made an EC2 Launch Template from an existing instance where I had already set up my server (or so I thought)
Created an Auto Scaling Group (ASG) using that launch template and connected it to the target group
Set up Security Groups for the ALB, Bastion Host, and EC2 instances accordingly

All done. Everything looked solid. I opened the ALB DNS in my browser… and it just didn’t work.

I checked security groups, route tables, load balancer health checks - everything looked fine.

Confused, I launched a bastion host and SSH'ed into one of the EC2 instances. And then… surprise: it was completely blank. No app. No server. Nothing.

That’s when I realized: Launch Templates don’t include your app or server files. They only store instance config. If you want a working server, you either need to create an AMI or provide user data.

What I Learned

At that point, I was exhausted and just shut everything down. I’ll redo it properly with AMIs next time - and I’ll test things step by step.

But honestly, I’m glad this happened. These small failures during the learning phase help you understand the “why” behind things. Now I’ll never forget how EC2 bootstrapping really works.

Thanks for reading!

If you’re also figuring out AWS like me, feel free to connect on LinkedIn. Let’s learn together! 😊

DEV Community: Deepak Soni