Learn Cloud Computing - Cloud Load Balancing & Auto-Scaling

#Introduction

In episode 5 we built a VPC with subnets across several AZs, and in episode 6 we filled it with VMs. But a single VM handling all traffic is a weak point: if it dies, the application dies with it. Episode 8 answers two big cloud architecture questions: how to distribute load across many machines, and how the number of machines adjusts itself to the load.

We'll start with the concept of high availability and no single point of failure, then compare L4 and L7 load balancers, map each provider's services, and close with auto-scaling complete with AWS CLI examples.

#The Concepts: High Availability, Fault Tolerance, and No Single Point of Failure

Before touching any tooling, understand three terms that shape architecture design:

• High availability (HA): the service stays available even when one component fails. There may be a small dip, but users can still use the application.
• Fault tolerance: the system keeps running without meaningful degradation even when a component fails.
• No single point of failure (no SPOF): there is no single component whose failure would bring down the entire system.

The basic principle for achieving all three is redundancy across AZs. Because an AZ is a physically separate data-center building, placing machines in at least two AZs means that if the power or network of one building goes out, the other building keeps serving. This is why in episode 5 we always placed subnets across several AZs, never just one.

#L4 vs L7: Two Load Balancer Levels

A load balancer is the "single entry point" that receives traffic and distributes it across many servers. But it can work at two different layers:

• L4 (transport layer) works at the TCP/UDP level. It only looks at the destination IP and port, then forwards packets to the backend servers. Fast and lightweight because it never reads packet contents — suitable for non-HTTP protocols and lowest-latency needs.
• L7 (application layer) reads HTTP contents. It can route based on path (/api to service A, /assets to service B), read headers and cookies, terminate TLS connections, and perform HTTP-based health checks.

#Comparing the Big 3 Load Balancer Services

Same concept, different names. The complete map:

One thing worth noting: because a load balancer is a single entry point, it itself should be replicated. In the cloud, load balancers are usually run as managed services that are redundantly implemented internally by the provider — you don't need to build HA for the load balancer itself, only make sure its configuration spans several AZs.

#Auto-Scaling: Capacity That Follows Load

Redundancy handles failures, but not surges. Auto-scaling solves that: the number of machines adjusts to load automatically.

• AWS calls it Auto Scaling Group (ASG), GCP Managed Instance Group (MIG), Azure Virtual Machine Scale Set (VMSS).
• The core configuration is three numbers: minimum (the fewest that always run), maximum (the upper limit), and desired (the current target).
• Scale-out/scale-in triggers can be metrics: CPU utilization, RAM usage, request count, or queue length. It can also be schedule-based — for example, raising capacity before predictable peak hours or flash sales.

Imagine a restaurant that adds chefs at lunchtime and lets them go when it's quiet — with three simple rules: at least two chefs are always present, at most ten, and add one more if the customer queue exceeds a certain threshold. That's exactly how auto-scaling works.

#Practice with the AWS CLI

The first step is creating a launch template — a configuration blueprint for every new instance. The aws ec2 create-launch-template command stores that blueprint in the cloud:

aws ec2 create-launch-template \
  --launch-template-name web-template \
  --launch-template-data '{
    "ImageId": "ami-0abcdef1234567890",
    "InstanceType": "t3.medium",
    "KeyName": "lab-key",
    "SecurityGroupIds": ["sg-0abc123"]
  }'

Then form an Auto Scaling Group that uses that template and spreads across several subnets in different AZs — done via aws autoscaling create-auto-scaling-group:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template "LaunchTemplateName=web-template" \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --vpc-zone-identifier "subnet-0aaa,subnet-0bbb" \
  --health-check-type ELB

Finally, attach a target-based scaling policy: let the cloud keep average CPU around 60 percent, adding or removing instances automatically:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" },
    "TargetValue": 60
  }'

If the target feels too aggressive or too loose, just change one number:

{
  "PredefinedMetricType": "ASGAverageCPUUtilization",
  "TargetValue": 60, # [!code --]
  "TargetValue": 75 # [!code ++]
}

#Conclusion

In this episode 8, we designed a resilient architecture: high availability through cross-AZ redundancy, no single point of failure, L4 and L7 load balancers that distribute traffic intelligently, and auto-scaling that adjusts the number of machines to the load. You also saw concrete examples of creating a launch template, an Auto Scaling Group, and a scaling policy via the AWS CLI.

The keys to take away:

• Spread across several AZs — redundancy is the foundation of HA, not an add-on feature.
• L4 for speed and non-HTTP protocols, L7 for application-based routing.
• Auto-scaling needs three numbers (min, max, desired) and the right metric — plus health checks that truly reflect application health.

Your application can now grow and survive. But the database that follows it hasn't yet: scaling an application without a reliable database is like adding more entrances without reinforcing the warehouse. Episode 9 next covers Relational Managed Databases (RDBMS) — managed versus self-hosted, multi-AZ high availability with automatic failover, and cloud-native distributed SQL like Aurora and Spanner.