Hvordan fungerer auto scaling i AWS?

Question

Accepted Answer

**Auto Scaling** justerer automatisk antallet kjørende ressurser (f.eks. EC2-instanser) basert på etterspørsel — legger til kapasitet når belastningen øker og fjerner den når belastningen synker. Det er nøkkelen til å bygge applikasjoner som er både **pålitelige** (håndterer trafikkstopper) og **kostnadseffektive** (ikke overbestilling).

## Hva auto scaling gjør

```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 (når skal skaleres)

```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).
```

## Hvorfor det er viktig

```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)
```

## Hvorfor det er viktig

Å forstå auto scaling er verdifullt for å bygge applikasjoner som er både pålitelige og kostnadseffektive, så det er viktig praktisk AWS-kunnskap.

Auto scaling løser en fundamental skyutfordring: automatisk matching av kapasitet til **variabel etterspørsel** — **legge til instanser når belastningen øker** (håndtere trafikkstopper uten manuell intervensjon eller overbelastning, sikre pålitelighet) og **fjerne dem når belastningen synker** (unngå å betale for inaktiv kapasitet, sikre kostnadseffektivitet).

Denne doble fordelen (pålitelighet under belastning + kostbesparelser når inaktiv) er sentral for å utnytte skyens elastisitet, og er langt bedre enn statisk bestilling for toppbelastning (sløseri) eller for gjennomsnittlig belastning (svikter under stopper).

Å forstå **Auto Scaling Groups** (administrere en flåte av EC2-instanser med min/max/ønsket kapasitet, lanseringsmaler og helsesjekker som automatisk erstatter usunne instanser for **selvhelbredelse**) og hvordan de typisk spredes over **flere AZer** (kombinere skalering med høy tilgjengelighet) er kjernepraktisk kunnskap.

Å forstå **scaling policies** (målsporing for å opprettholde en metrikk som CPU på et målnivå — det enkleste og mest vanlige; trinnvis skalering på terskelkoder; planlagt skalering for kjente mønstre; prediktiv skalering) basert på CloudWatch-metrikker er nødvendig for å konfigurere skalering passende.

Å vite at auto scaling **kobles med en lastbalancer** (som distribuerer trafikk over de dynamisk skiftende instansene) fullfører bildet av en skalerbar, motstandsdyktig arkitektur.

Da håndtering av variabel etterspørsel på en pålitelig og kostnadseffektiv måte er et kjernesky-krav, og siden auto scaling (med skaleringsgrupper, policyer, helsesjekker og lastbalansering) er mekanismen som oppnår det, er forståelse av auto scaling verdifull, praktisk-viktig AWS-kunnskap for å bygge applikasjoner som skaleres med etterspørsel — en grunnleggende evne for pålitelig, kostnadseffektiv skyarkitektur og et nøkkelemne for design av systemer som håndterer virkelig variabel trafikk.