Series: Building a Web App: A Beginner’s Guide to Cloud Architecture (Part 2 of 5)
In Part 1, we made our Web App Highly Available. If a server breaks, our load balancer silently shifts traffic to a backup. We don't have to worry about our app going offline due to a hardware failure.
But what if your app doesn't crash from a failure, but from success?
Imagine it is the final day of registration for your event. Suddenly, 50,000 users hit your website at the exact same time. Your two baseline servers max out their CPU, run out of memory, and the system grinds to a halt.
We are going to fix that by making our infrastructure scalable.
Scaling Up vs. Scaling Out
When a server runs out of computing power, you have two choices:
- Vertical Scaling (Scaling Up): You turn off the server, buy a bigger processor, add more RAM, and turn it back on. It is easy to understand, but it requires downtime. Eventually, you hit a limit—you can only buy a computer so big.
- Horizontal Scaling (Scaling Out): Instead of making one server bigger, you dynamically add more servers. If two servers handle 10,000 users, we can automatically spin up eight more servers to handle 50,000 users.
In the modern cloud, Horizontal Scaling is the gold standard because it is elastic. When the traffic goes down, we delete the extra servers so we stop paying for them.
How Does Auto-Scaling Actually Work?
When your system decides it needs more power, there isn't a person in a data center running over to plug in a new machine. It is entirely automated. Here is what happens when traffic spikes:
- The Alarm: A monitoring service notices your servers are struggling (e.g., CPU has been sitting at 80% for three minutes). It sends an alert.
- The Blueprint: The Auto Scaler looks at a "Blueprint" you provided earlier. This blueprint contains the exact operating system, application code, and settings needed to run your app perfectly.
- The Clone: The cloud provider instantly provisions brand new resources using that exact blueprint.
- The Introduction: Once the new servers or containers finish booting up, the Auto Scaler introduces them to the Load Balancer. The Load Balancer immediately starts sending user traffic to them, lowering the CPU usage across the board.
Setting the Rules (Scaling Policies)
Three rules you need to configure:
- The Scale-Out Rule (When to add): "If average CPU usage goes over 75% for 3 minutes, add 2 servers." This protects the application from crashing.
- The Scale-In Rule (When to remove): "If average CPU usage drops below 30% for 5 minutes, remove 2 servers." This protects your wallet when everyone goes to sleep.
- The Cooldown Period: A mandatory waiting period (e.g., 5 minutes) after a scaling event happens. This stops the system from panicking and adding 10 servers all at once before the first new server has even finished booting up.
The Architecture Blueprint
Both major cloud providers have dedicated services that monitor your traffic and automatically create or destroy servers based on the rules you set.
| Compute Type | AWS Service | Azure Service | Best For |
|---|---|---|---|
| Raw Servers (IaaS) | Auto Scaling Group (ASG) | Virtual Machine Scale Sets (VMSS) | Legacy apps or deep OS-level control. |
| Web Apps (PaaS) | Elastic Beanstalk | Azure App Service | Traditional web apps where you just want to upload code. |
| Simple Containers | AWS Fargate (Standalone) | Azure Container Instances (ACI) | Quick, single-task container execution without complex scaling. |
| Container Scaling | ECS / EKS with Fargate | Azure Container Apps (ACA) | Modern microservices that need to auto-scale instantly (even down to zero). |
Note: An Auto Scaling Group (ASG) is specifically built to manage EC2 instances (which is AWS's official name for raw virtual servers).
Architecture Diagram
AWS Architecture Diagram
Good to know stuff about AWS:
According to the official Amazon EC2 Auto Scaling documentation:
If a scaling action occurs, Amazon EC2 Auto Scaling automatically maintains balance across all of the Availability Zones that you specify.
When a scale-out event happens,
Amazon EC2 Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances.
Because our Auto Scaling Group spans two Availability Zones, AWS strictly enforces a 'balanced distribution' rule. If we tell it to add 2 instances, it looks at our zones and says, 'AZ 1 has one server, and AZ 2 has one server.' It will launch the first new server in AZ 1, and then launch the second new server in AZ 2 to ensure the high-availability balance remains perfectly intact.
Azure Architecture Diagram
Good to know stuff about Microsoft Azure:
A single VMSS(Virtual Machine scale set) can span across multiple Availability Zones, as long as those zones are inside the same Region.
If you build a VMSS in the "East US" region, you can tell Azure to spread your virtual machines across AZ 1, AZ 2, and AZ 3.
Because our Virtual Machine Scale Set (VMSS) in above diagram spans two Availability Zones, Azure enforces a 'zone balancing' rule. If we tell it to add 2 instances, it looks at our zones and says, 'AZ 1 has one server, and AZ 2 has one server.' It will launch the first new virtual machine in AZ 1, and then launch the second new virtual machine in AZ 2 to ensure the high-availability balance remains perfectly intact.
Further Reading & Official Documentation
If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:
- AWS Auto Scaling Group Benefits (Multi-AZ):https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html
- AWS Auto Scaling Availability Zone Distribution (Balancing): https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html
- Azure VMSS and Availability Zones (Zone-Spanning): https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-use-availability-zones
- Azure Monitor Autoscale Best Practices: https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices
Coming Up Next in Part 3: Locking Down the Castle (Networking & Security)
So far, we have built an application that is unbreakable (High Availability) and unstoppable (Scalability). But right now, we have a massive blind spot: Security.
If 50,000 legitimate users can easily reach our web servers, what is stopping a malicious hacker from trying to access our database directly?
Stay tuned as we take our cloud architecture from highly scalable to highly secure!
Top comments (0)