Gnu Group Learning AcademyGnu Group ↗
Cloud Infrastructure Fundamentals · Module 06 of 12

Load balancing and high availability

Understand L4 versus L7 load balancing, health checks, multi-AZ failure domains and how load balancing integrates with autoscaling.

Learning objectives

By the end of this module, you should be able to:

  • Distinguish transport-layer (L4) and application-layer (L7) load balancing.
  • Explain why health checks must test useful service behavior.
  • Design multi-AZ traffic paths that avoid a single failure domain.
  • Explain how load balancers and autoscaling groups complement one another.

L4 and L7 load balancers make decisions at different layers

Layer 4 load balancing primarily distributes connections using transport information such as IP address and TCP/UDP port. Layer 7 load balancing understands application protocols such as HTTP and can route using host, path or headers.

Choose the layer based on protocol needs, observability and routing requirements rather than assuming L7 is always better.

Health checks should remove unhealthy targets before users discover them

A load balancer can probe targets and route only to those considered healthy. A useful health endpoint should validate enough of the service to signal readiness without becoming an expensive dependency test.

Readiness, liveness and external load-balancer health checks solve related but different problems.

High availability requires independent failure paths

Running two instances in one failure domain does not provide the same resilience as spreading capacity across independent zones. Network, compute and data dependencies must also be distributed.

Autoscaling changes capacity; the load balancer changes traffic distribution

An autoscaling system adjusts the number of compute targets based on policy. The load balancer discovers/uses healthy targets and distributes traffic. Integration needs registration, health checks, warm-up and safe scale-in behavior.

Worked examples

See the idea in practice.

Request path

client → DNS → load balancer → healthy target in AZ-A or AZ-B
  • The load balancer should remove unhealthy targets.
  • The application should expose a meaningful readiness/health endpoint.
Core lab · Modes 1–2 · Concept + local simulation

Lab — Simulate load-balancer health selection

Goal: Model a health-aware target pool locally.

Before you start

  • Python 3 only.
STEP 1

Create target health

cat > /tmp/lb.py <<'PY'
targets=[{'name':'a','healthy':True},{'name':'b','healthy':False},{'name':'c','healthy':True}]
healthy=[t['name'] for t in targets if t['healthy']]
assert healthy==['a','c']
for i in range(6): print('request',i,'->',healthy[i%len(healthy)])
PY
STEP 2

Run distribution

python3 /tmp/lb.py
STEP 3

Reason about failure

Mark both healthy targets as failed and explain why a load balancer cannot manufacture capacity when no backend is ready.

Verify

  • Unhealthy target b receives no simulated requests.
  • Healthy requests alternate between a and c.

Expected outcome

  • You understand that load balancing depends on accurate health and sufficient healthy capacity.

Diagnose / troubleshoot

  • If healthy targets still receive no traffic, check listener/routing rules and target registration before changing health-check thresholds.
  • If a target flaps healthy/unhealthy, compare check interval/timeout and the health endpoint dependency chain.
Real-world connection

Production high availability depends on independent zones, accurate health checks, sufficient healthy capacity and safe autoscaling integration.

Mode 3 · Optional AWS lab

Optional AWS — inspect load balancers and health

Inspect existing load balancers/target health without creating billable load-balancer resources.

Resources created

  • None — this is a read-only inspection lab.

Estimated cost / risk

  • Expected incremental resource cost: none because the supplied commands are read-only.
  • Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

  • Optional sandbox AWS account and AWS CLI.
  • Use a least-privilege or federated identity; do not paste long-lived access keys into course files.
AWS 1
aws elbv2 describe-load-balancers --query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,Scheme:Scheme,DNS:DNSName}' --output table
AWS 2
aws elbv2 describe-target-groups --query 'TargetGroups[].{Name:TargetGroupName,Protocol:Protocol,Port:Port}' --output table

Verify

  • Existing load balancers/target groups are visible if present in the sandbox.
  • No AWS resources are created by the supplied commands.

Cleanup

  • No AWS cleanup is required because this lab creates no AWS resources.

Warnings

  • Optional only: not required for course completion or the main validator.
  • Do not create an ALB/NLB solely for this lab; load balancers can incur hourly and usage charges.
Avoid these traps

Common mistakes

  • Treating multiple instances in one zone as multi-AZ high availability.
  • Using a health check that returns success while the application cannot serve useful traffic.
  • Scaling compute without ensuring new targets are registered and healthy before receiving traffic.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What is a key L4 versus L7 difference?

L4 routes transport connections using network/port information, while L7 can make application-protocol-aware decisions such as HTTP host or path routing.

2Why do load balancers use health checks?

To avoid sending new traffic to targets that are not ready to serve it.

3Why spread capacity across availability zones?

To reduce dependence on a single failure domain when the complete traffic path is distributed.

4Scenario: one availability zone fails and half the targets disappear. What must be true for the load-balanced service to remain available?

Healthy capacity must exist in another failure domain, the load balancer must be able to route to it, and dependencies/data paths must also tolerate the failed zone.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.