Hoe werkt auto scaling in AWS?

Question

Accepted Answer

**Auto Scaling** past het aantal actieve resources (bijv. EC2-instanties) automatisch aan op basis van vraag — voegt capaciteit toe wanneer de belasting toeneemt en verwijdert deze wanneer de belasting afneemt. Het is essentieel voor het bouwen van applicaties die zowel **betrouwbaar** zijn (verkeersspitzen afhandelen) als **kostenefficiënt** (niet over-inrichten).

## Wat auto scaling doet

```text
Auto Scaling adjusts capacity AUTOMATICALLY based on demand:
  → load INCREASES (traffic spike) → add instances (scale OUT) → handle the load
  → load DECREASES → remove instances (scale IN) → save money
→ Match capacity to demand automatically: reliable under load, cheap when idle.
```

## EC2 Auto Scaling Groups (ASG)

```text
An AUTO SCALING GROUP manages a fleet of EC2 instances:
  MIN / MAX / DESIRED capacity → bounds and target number of instances
  LAUNCH TEMPLATE → how to launch new instances (AMI, type, config)
  SCALING POLICIES → rules for when to scale (see below)
  HEALTH CHECKS → replace unhealthy instances automatically (self-healing!)
  → typically spread across multiple AZs (high availability)
```

## Scaling policies (wanneer schalen)

```text
TARGET TRACKING → keep a metric at a target (e.g. "keep average CPU at 50%") — simplest
STEP / SIMPLE SCALING → add/remove N instances when a metric crosses a threshold
SCHEDULED → scale at known times (e.g. more capacity during business hours)
PREDICTIVE → ML-based, anticipating load
→ Usually based on CloudWatch metrics (CPU, request count, custom metrics).
```

## Waarom het belangrijk is

```text
✓ RELIABILITY — handle traffic spikes automatically (no manual intervention, no overload)
✓ COST-EFFICIENCY — scale IN during low demand → don't pay for idle capacity
✓ SELF-HEALING — auto-replace failed instances (combined with health checks)
✓ Pairs with a LOAD BALANCER (distributes traffic across the scaled instances)
```

## Waarom het belangrijk is

Het begrijpen van auto scaling is waardevol voor het bouwen van applicaties die zowel betrouwbaar als kostenefficiënt zijn, dus het is belangrijk praktisch AWS-kennis.

Auto scaling lost een fundamentele cloud-uitdaging op: capaciteit automatisch aanpassen aan **variabele vraag** — **instanties toevoegen wanneer de belasting toeneemt** (verkeersspitzen afhandelen zonder handmatige interventie of overbelasting, wat betrouwbaarheid garandeert) en **ze verwijderen wanneer de belasting afneemt** (voorkomen dat je voor inactieve capaciteit betaalt, wat kostenefficiëntie garandeert).

Dit dubbele voordeel (betrouwbaarheid onder belasting + kostenbesparingen wanneer inactief) staat centraal in het benutten van de elasticiteit van de cloud, en is veel beter dan statisch inrichten voor piekbelasting (verspillend) of voor gemiddelde belasting (faalt onder spitzen).

Het begrijpen van **Auto Scaling Groups** (beheren van een vloot EC2-instanties met min/max/gewenste capaciteit, launch templates en health checks die automatisch ongezonde instanties vervangen voor **zelf-healing**) en hoe deze doorgaans verdeeld zijn over **meerdere AZ's** (schaling combineren met hoge beschikbaarheid) is de kernpraktische kennis.

Het begrijpen van **scaling policies** (target tracking om een metric zoals CPU op een doel te handhaven — het eenvoudigste en meest voorkomend; step scaling op drempels; geplande schaling voor bekende patronen; voorspellende schaling) gebaseerd op CloudWatch-metrics is nodig voor het correct configureren van schaling.

Weten dat auto scaling **samenwerkt met een load balancer** (die verkeer distribueert over de dynamisch veranderende instanties) completeert het plaatje van een schaalbare, veerkrachtige architectuur.

Omdat het betrouwbaar en kosteneffectief afhandelen van variabele vraag een kernvereiste in de cloud is, en omdat auto scaling (met scaling groups, policies, health checks en load balancing) het mechanisme is dat dit bereikt, is het begrijpen van auto scaling waardevol, praktisch-belangrijk AWS-kennis voor het bouwen van applicaties die meegroeien met de vraag — een fundamenteel vermogen voor betrouwbare, kostenefficiënte cloud-architectuur en een belangrijk onderwerp voor het ontwerpen van systemen die echte variabele verkeer afhandelen.