Skaalautuva nettipalvelu AWS:ssä: serverless, Fargate vai EC2 Auto Scaling?

Kolme realistista tapaa: Lambda skaalaa pyynnöittäin, Fargate luo kontteja tarpeen mukaan, EC2 Auto Scaling Group käynnistää virtuaalikoneita kuorman mukaan. Load balancer ei ole aina pakollinen — web-API:lle se yleensä on.

Julkaistu 31.7.2026 · Ei kaupallista yhteyttä AWS:ään · liittyy autoscaling-vertailuun, serverless- ja load balancer -sivusten dataan

Tavoite on sama: sivusto tai API kestää enemmän (ja vähemmän) liikennettä ilman että avaat konsolia joka piikissä. AWS:ssä “skaalautuva” ei ole yksi tuote — se on arkkitehtuuri. Alla kolme polkua yksinkertaisesta monimutkaiseen, plus yhteiset rakennuspalikat.

Yhteiset osat (lähes aina)

• DNS — Route 53 (tai ulkoinen DNS) → CloudFront / ALB / API Gateway.
• CDN — CloudFront leikkaa originin kuormaa; usein tärkeämpi kuin “enemmän koneita”.
• Tallennus — S3 staattiselle ja uploadeille; ei sovelluksen paikalliselle levylle.
• Tietokanta — hallittu Postgres/MySQL (RDS) tai erillinen VPS; skaalaa compute ja kanta erikseen.
• Salaisuudet — Secrets Manager / SSM Parameter Store, ei .env gitiin.

AWS ei skaalaa “kävijämäärän” mukaan Analyticsista. Se skaalaa mittareita: pyyntöjä, CPU:ta, jonon pituutta, p95-latenssia.

A. Serverless: Lambda + API Gateway

Jokainen HTTP-pyyntö (tai tapahtuma) käynnistää funktion. Kuorman noustessa AWS ajaa enemmän rinnakkaisia suorituksia; kuorman laskiessa maksat vähemmän tai et juuri mitään.

Internet
   → CloudFront (valinnainen)
   → API Gateway (HTTP API)
   → Lambda (N rinnakkaista)
   → RDS / DynamoDB / S3

Mitä rakennat

• Funktio(t) Node/Python/Go… — yksi reitti tai monoliitti-handler.
• API Gateway HTTP API (yleensä halvempi ja riittävä REST/JSON:lle).
• IAM-rooli, VPC-liitos vain jos Lambda tarvitsee yksityistä RDS:ää (lisää kustannusta ja kylmäkäynnistystä).
• Valinnainen: CloudFront edessä, WAF, Cognito/auth.

Hyvä / huono

• + Ei ASG:tä, ei EC2-päivityksiä; skaalaus sisäänrakennettu.
• + Tyhjäkäynti halpaa — sopii sparingly käytettyyn API:in.
• − Cold start, 15 min max kesto, ei “aina päällä” -websocket-palvelinta ilman erillistä palvelua (API GW WebSocket / AppSync).
• − Pitkään pyörivä tai raskas tausta → Fargate/EC2 tai erillinen worker (SQS + Lambda).

Hinnoittelulogiikka (pyyntö + GB-sekunti): serverless-vertailu.

B. Kontit: ECS Fargate + ALB

Pakkaat sovelluksen Docker-imageen. Fargate ajaa kontteja ilman että hallitset virtuaalikoneita. Service Auto Scaling säätää tehtävien (task) määrää CPU/pyyntömittareilla.

Internet
   → ALB
   → ECS Service (Fargate tasks 1…N)
   → RDS / ElastiCache / S3

Mitä rakennat

• ECR-repositorio + image CI:stä (GitHub Actions / CodePipeline).
• ECS-klusteri + task definition (CPU/RAM) + service.
• Application Load Balancer + target group (HTTP health check).
• Service Auto Scaling: min/max tasks, target tracking (esim. CPU 50 % tai ALB RequestCountPerTarget).

Hyvä / huono

• + Sama Docker-kuva lokalista tuotantoon; ei OS-patchausta EC2:lla.
• + Sopii pitkään pyörivään web-appiin paremmin kuin Lambda.
• − ALB + aina vähintään 1 task = kiinteä pohjakulu (toisin kuin “nukkuva” Lambda).
• − Fargate-yksikköhinta on usein korkeampi kuin itse hallittu EC2 — maksat mukavuudesta.

C. VPS:t tarpeen mukaan: EC2 Auto Scaling Group + ALB

Klassinen malli: AMI tai launch template määrittää koneen. Auto Scaling Group (ASG) pitää ryhmässä min–max instanssia ja luo/tuhoaa EC2:ita mittareiden mukaan. ASG-ominaisuus maksaa 0 € — maksat käynnissä olevista koneista, levyistä ja yleensä ALB:stä.

Internet
   → ALB
   → Auto Scaling Group (EC2 1…N)
   → RDS / S3

Mitä rakennat

• Launch template: AMI, instanssityyppi, security group, user data (asenna app / vedä image).
• ASG: min/desired/max, scaling policy (target tracking).
• ALB + target group — web-liikenteelle. Pelkille SQS-työläisille ALB ei ole pakollinen.
• Stateless-app: sessiot Redis/DB:hen, ei paikalliselle levylle.

Hyvä / huono

• + Tuttu Linux-VPS; Spot-instanssit ja Savings Plans voivat laskea hintaa.
• + Täysi kontrolli (kernel, agentit, erikoisajurit).
• − Patchaus, AMI-putki, boot-aika ennen kuin uusi kone ottaa liikennettä.
• − Yksi aina-päällä oleva EC2 + ALB on kalliimpi tyhjäkäynnillä kuin Lambda.

EC2-hintoja suhteessa muihin pilviin: VPS-vertailu. Kenellä muilla on ASG-tyylinen tuote: autoscaling-artikkeli.

Tarvitaanko load balancer aina?

Ei. ASG voi skaalata työläisiä ilman ALB:tä (esim. SQS-kuluttajat). Lambda käyttää API Gatewayä / Function URLia — ei Classic/ALB:tä.

Käytännössä kyllä webille ja HTTP-API:lle usealla instanssilla/taskilla: asiakas tarvitsee yhden vakaana pysyvän päätepisteen, joka jakaa liikenteen terveisiin kohteisiin. Vertailussamme ALB:n perusarvio on noin 14 €/kk + LCU-käyttö (load-balancerit) — käyttöpohjainen, ei kiinteä “pakettihinta”.

Mistä lasku koostuu (ei keksittyjä rivejä)

Kolme realistista aloitusta

• Pieni API / webhook: Lambda + HTTP API (+ ehkä CloudFront). Ei ASG:tä.
• Docker-webapp, tiimi tuntee kontit: Fargate + ALB, min 1–2 taskia, max sen mukaan mitä budjetti kestää.
• “Haluan Linux-koneita jotka lisääntyvät itse”: EC2 ASG + ALB, launch template, health check joka oikeasti kertoo onko app valmis.

Jos et ole jo AWS-ekosysteemissä ja tarvitset vain yhden koneen Helsingissä, eurooppalainen VPS + myöhemmin hot resize / K8s voi olla halvempi — ks. hyperscalerin kokonaiskustannus. AWS kannattaa kun tarvitset juuri näitä managed-osia (jonot, Lambda, tiukka integraatio) tai olet jo siellä.

Yhteenveto

Serverless skaalaa pyynnöt. Fargate skaalaa kontit. EC2 ASG skaalaa virtuaalikoneet. Kaikki kolme voivat palvella nettipalvelua; ero on kontrollissa, pohjakulussa ja siinä, miten sovellus pakataan.

Aloita yksinkertaisimmasta joka täyttää tarpeen. Lisää ALB ja horisontaalinen skaalaus kun yksi instanssi ei riitä — ei “varmuuden vuoksi” ensimmäisenä päivänä.