Auto Scaling y balanceo de carga

One EC2 instance is a single point of failure. Backends run an Auto Scaling Group of instances behind a load balancer that spreads requests across them.

An ASG needs a recipe for the instances it spins up. A launch template defines the AMI, instance type, and startup configuration.

An Auto Scaling Group holds a minimum, desired, and maximum count. It keeps the desired number running and replaces unhealthy instances on its own.

The ASG runs health checks: when an instance fails, it terminates that one and launches a replacement, holding the fleet at the desired size.

A load balancer gives clients one stable endpoint while spreading requests across healthy instances. The ALB works at HTTP and routes by path or host.

Two ALB pieces: a listener watches a port (like 80) for connections, and a target group is the pool of instances it forwards to.

The ASG auto-registers its instances with the target group, so new instances start getting traffic and terminated ones are removed — no manual wiring.

A scaling policy adjusts the desired count by metric. Target tracking is simplest: hold average CPU near, say, 50% and AWS adds or removes instances to keep it.

This snippet models target tracking — comparing current CPU to the target to compute the new instance count.

Spread the ASG across multiple Availability Zones. If one AZ goes down, instances in the others keep serving and the ALB stops routing to the failed zone.

Scaling out costs money, and rapid up-down thrashing wastes it. A cooldown pauses further scaling so the fleet stabilizes before reacting again.

A traffic spike hits your fleet — what does target tracking do, and how does the ALB keep responses flowing?

Recap: launch templates define instances, Auto Scaling Groups self-heal around min/desired/max, and an ALB with target-tracking and multi-AZ adds elasticity and resilience.