AWS Lambda -kustannusoptimointi 2026

Päivitetty: 4. elokuuta 2026

AWS Lambda -kustannusten optimointi 2026 tarkoittaa neljää konkreettista vipua: muistiasetuksen viritystä Power Tuningilla, siirtymää x86:sta ARM Gravitoniin (20 % halvempi GB-sekunti), SnapStartin käyttöönottoa Java-, Python- ja .NET-funktioille sekä provisioned concurrencyn rajaamista vain tunnettuun perusliikenteeseen. Näiden yhdistelmällä olen leikannut asiakkaiden Lambda-laskuja tyypillisesti 35–60 % ilman että yksikään SLA on rikkoutunut. Käyn tässä oppaassa jokaisen vivun läpi numeroineen ja esittelen kaksi työkalua, jotka teen itse osaksi jokaista FinOps-arviointia.

Lambdan hinta koostuu kolmesta osasta: kutsut ($0,20 / miljoona), GB-sekunnit ja ephemeral storage yli 512 Mt:n. GB-sekunnit ovat lähes aina se osa, joka räjähtää.
ARM Graviton -arkkitehtuuri on 20 % halvempi ja tyypillisesti 19 % nopeampi Python-, Node.js- ja Go-työkuormille. Vaihto on kertaluontoinen ja se kannattaa tehdä ensimmäisenä.
Muistiasetus vaikuttaa suoraan CPU-suorituskykyyn: liian pieni muisti tekee funktioista hitaita ja kalliita. Lambda Power Tuning löytää optimipisteen tyypillisesti 4–8 ajolla.
SnapStart poistaa Javan, Pythonin ja .NET:n kylmäkäynnistysrangaistuksen käytännössä kokonaan. Ominaisuus on ilmainen, ja moni tiimi ei ole vieläkään ottanut sitä käyttöön.
Provisioned concurrency maksaa aina, myös kun sitä ei käytetä. Kannattava vain kun perusliikenne on tunnettu ja pysyvä; muutoin on-demand voittaa.
Yli 6 miljardin GB-sekunnin kuukausikäytön jälkeen Lambda siirtyy portaittain halvempaan hintaan. Suuret asiakkaat voivat neuvotella EDP-alennuksia päälle.

Näin AWS Lambda hinnoitellaan 2026

Lambdan hinta koostuu 2026 kolmesta laskutettavasta komponentista, jotka on syytä ymmärtää ennen optimointia. Ensimmäinen on kutsut: $0,20 miljoonalta kutsulta, ja ensimmäinen miljoona kuukaudessa on ilmainen (always-free-taso, jota AWS ei ole poistanut). Toinen ja käytännössä tärkein on GB-sekunnit, eli varatun muistin ja suoritusajan tulo. x86-arkkitehtuurilla hinta on $0,0000166667 per GB-sekunti ja ARM Graviton -arkkitehtuurilla $0,0000133334 per GB-sekunti. Kaava on sama, mutta laskuri lyö 20 % vähemmän. Kolmas on ephemeral storage eli /tmp-hakemiston koko yli 512 Mt:n; sitä laskutetaan $0,0000000308 per Gt-sekunti.

Yhdysvaltain vuoden 2024 lopulla käyttöön ottama porrastettu hinnoittelu alkaa vaikuttaa vasta, kun kuukausikäyttö ylittää 6 miljardia GB-sekuntia. Silloin GB-sekunnin hinta laskee noin 17 % ja seuraava porras 15 miljardin kohdalla laskee vielä lisää. Rehellisesti sanottuna useimmat asiakkaani eivät edes lähesty ensimmäistä porrasta, joten en luota siihen budjetoinnissa. Enterprise Discount Program (EDP) -sopimusalennukset päälle voivat kuitenkin siirtää tilannetta.

Yksi hiljainen kuluerä on Provisioned Concurrency, joka laskutetaan erikseen: $0,0000041667 per GB-sekunti provisionoitua kapasiteettia, riippumatta siitä kutsutaanko funktiota vai ei. Tästä lisää alempana.

Miten optimoit Lambda-kustannuksia käytännössä?

Optimointi etenee järjestyksessä, jossa jokainen askel on halvempi tehdä ja tuottaa suuremman säästön kuin seuraava. Näin teen sen asiakkaani ympäristössä:

Kartoita kustannukset per funktio. Ota CloudWatch Metricsistä Invocations, Duration ja MemorySize ja järjestä funktiot GB-sekuntien mukaan. 80 % laskusta tulee tyypillisesti 5–10 funktiosta.
Vaihda arkkitehtuuri x86:sta ARM:iin. Yhden rivin muutos architectures = ["arm64"] IaC:ssä. Testaa ensin dev-ympäristössä, koska natiivit riippuvuudet (esim. sharp, pandas C-osat) vaativat ARM-binäärit.
Aja Lambda Power Tuning kalleimmille funktioille. Löytää muistin optimipisteen 4–8 ajolla. Tyypillinen säästö 15–40 %.
Ota SnapStart käyttöön Java/Python/.NET-funktioille. Poistaa kylmäkäynnistykset ja vähentää suoritusaikaa. Ilmainen ominaisuus.
Poista tai skaalaa alas provisioned concurrency. Käytä CloudWatchin ProvisionedConcurrencyUtilization -mittaria: jos alle 60 %, karsi.
Karsi zombie-funktiot. Kaikki funktiot, jotka eivät ole saaneet kutsua 90 päivässä, mutta joilla on provisioned concurrency tai päälle jäänyt CloudWatch Logs -retention Never expire.

Muistin viritys Lambda Power Tuningilla

Lambdassa muistin määrä ei ole vain muistia. Se skaalaa suhteessa myös CPU:ta ja verkon kaistanleveyttä. Tämä johtaa vastaintuitiiviseen tulokseen: pienempi muisti voi olla kalliimpi, koska funktio ajaa hitaammin. 128 Mt:n funktio, joka ajaa 3000 ms, maksaa käytännössä saman kuin 1024 Mt:n funktio 400 ms:n ajolla, mutta jälkimmäinen palvelee käyttäjää seitsemän kertaa nopeammin. Törmäsin tähän itse ensi kerran Node-batch-työkuormaa migroidessa: "säästimme" muistia ja huomasimme, että kokonaislasku nousi.

AWS Lambda Power Tuning on Step Functions -pohjainen työkalu, joka ajaa funktion useilla muistiasetuksilla ja piirtää kustannus- vs. kestokäyrän. Käyttöönotto SAR:sta (Serverless Application Repository):

aws serverlessrepo create-cloud-formation-template \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --semantic-version 4.3.6

# Käynnistys AWS CLI:llä
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:eu-west-1:123456789012:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:eu-west-1:123456789012:function:my-api-handler",
    "powerValues": [128, 256, 512, 1024, 1536, 2048, 3008],
    "num": 50,
    "payload": {"userId": "test-123", "action": "list"},
    "strategy": "balanced"
  }'

Strategiavaihtoehdot ovat cost (halvin), speed (nopein) ja balanced (kompromissi kustannuksen ja keston välillä). Käytän itse lähes aina balanced-strategiaa API-taustapalveluille, koska käyttäjän kokema latenssi on rahaa sekin. Batch-työille valitsen cost.

Tyypillinen tulos: Python API-funktio, joka oli asetettu 512 Mt:iin, sai optimipisteen 1024 Mt:ssä. Suoritusaika puolittui 380 ms:sta 190 ms:iin, jolloin kokonaiskustannus tippui 22 %. Samalla p95-latenssi laski merkittävästi.

ARM Graviton -siirtymä: 20 % halvempi arkkitehtuuri

AWS Graviton2 -pohjaiset Lambda-funktiot ovat olleet saatavilla vuodesta 2021 lähtien ja niiden hinta on 20 % alhaisempi kuin x86:n. AWS:n omat vertailut osoittavat Graviton2:n olevan 34 % parempi hinta-suorituskyvyltään monille työkuormille, ja omat mittaukseni ovat tukeneet lukua Python-, Node.js- ja Go-sovelluksille. Poikkeuksia löytyy: raskaan lineaarialgebran (numpy MKL-optimoinnit) tai natiivikirjastojen kanssa arkkitehtuurin vaihto voi olla nollasumma tai jopa hidastaa.

Siirtymä on Infrastructure-as-Code -tasolla yhden rivin muutos. Terraformilla:

resource "aws_lambda_function" "api_handler" {
  function_name = "my-api-handler"
  runtime       = "python3.13"
  handler       = "app.handler"
  role          = aws_iam_role.lambda_role.arn
  filename      = data.archive_file.lambda_zip.output_path

  # Ainoa muutettava rivi
  architectures = ["arm64"]

  memory_size = 1024
  timeout     = 15

  environment {
    variables = {
      LOG_LEVEL = "INFO"
    }
  }
}

Kaksi asiaa on tarkistettava ennen tuotantosiirtoa. Ensimmäinen on natiivit riippuvuudet: jos käytät esimerkiksi sharp-kirjastoa Node.js:llä, pandas-numeerisia osia Pythonilla tai Pillowia, buildaa deployment-paketti ARM-arkkitehtuurin Docker-kontissa (docker buildx build --platform linux/arm64). Toinen on Lambda Layers: kaikkien käytettyjen layerien on tuettava arm64:ää. AWS:n hallinnoidut layerit tekevät niin, mutta vanhemmat kolmannen osapuolen layerit eivät välttämättä.

SnapStart ja kylmäkäynnistysten poistaminen

Kylmäkäynnistys on ollut Lambdan pitkäaikainen kipupiste erityisesti Javalla, jossa JVM:n käynnistys voi viedä 2–8 sekuntia. AWS SnapStart, joka julkaistiin re:Invent 2022:ssa Javalle ja laajennettiin Pythoniin ja .NET:iin 2024, poistaa tämän käytännössä kokonaan. Tekniikka on yksinkertainen: Lambda käynnistää funktion kerran, ottaa muistivedoksen (Firecracker microVM -snapshot) ja palauttaa saman tilan takaisin jokaista kylmäkäynnistystä varten. Käynnistysaika putoaa tyypillisesti sekunneista alle 200 ms:iin.

SnapStartin käyttöönotto CDK:lla (v2):

import * as lambda from "aws-cdk-lib/aws-lambda";

const fn = new lambda.Function(this, "OrdersApi", {
  runtime: lambda.Runtime.JAVA_21,
  handler: "com.example.OrdersHandler::handleRequest",
  code: lambda.Code.fromAsset("target/orders-1.0.jar"),
  memorySize: 1024,
  timeout: Duration.seconds(15),
  snapStart: lambda.SnapStartConf.ON_PUBLISHED_VERSIONS,
});

SnapStart on ilmainen ominaisuus, mutta sillä on kaksi ehtoa. Ensimmäinen: se toimii vain julkaistuille funktioversioille (Versions), ei $LATESTille. Deployment-flown pitää julkaista versio ja päivittää alias siihen. Toinen: satunnaislukugeneraattorit ja verkkoyhteydet on käynnistettävä uudelleen jokaisella palautuksella. AWS tarjoaa Runtime Hooks -mekanismin tähän. Jos et hoida sitä, kaikki funktion instanssit jakavat saman satunnaissiemenen, mikä on turvallisuusongelma (törmäsin siihen ensimmäisenä Spring-projektin migraatiossa 2024, ja se on juuri sellainen bugi jonka löydät vasta code review'ssa).

Käytännössä olen nähnyt SnapStartin tiputtavan Spring Boot -pohjaisen Lambda-funktion p99-käynnistysajan 4,2 sekunnista 180 ms:iin. Tämä ei suoraan alenna hintaa (kylmäkäynnistys on jo maksettu ensimmäisessä ajossa), mutta se poistaa syyn ottaa käyttöön provisioned concurrency, ja siinä ovat säästöt.

Milloin provisioned concurrency kannattaa?

Provisioned concurrency pitää tietyn määrän funktioinstansseja "lämpimänä" ja poistaa kylmäkäynnistykset kokonaan. Se maksaa aina, oli funktio käytössä tai ei: $0,0000041667 per GB-sekunti (arm64) tai $0,0000052083 (x86). Käytännössä 1024 Mt:n funktion pitäminen yhtenä instanssina kuukaudessa maksaa noin $10,8. Kymmenen instanssia = $108/kk.

Milloin se kannattaa? Yksinkertainen sääntö: jos kutsut ovat riittävän tiheitä, että instanssi säilyy joka tapauksessa lämpimänä (Lambda pitää instansseja 10–60 minuuttia ilman kutsua), on-demand voittaa. Provisioned concurrency kannattaa vain kun:

On tunnettu, pysyvä perusliikenne (esim. 24/7 API, jolla 20 rinnakkaista pyyntöä koko ajan)
Kylmäkäynnistys on liiketoiminnalle kriittinen (esim. mobiilisovelluksen käynnistys, kuluttaja-API)
SnapStart ei ole vaihtoehto (esim. runtime, jota SnapStart ei tue, kuten Go)

Käytännön viritys: yhdistä provisioned concurrency Application Auto Scalingiin niin, että perustaso on esim. 5 instanssia arkisin 08–20 ja 1 instanssi öisin. Näin maksat 3 000 $/vuosi 10 000 $/vuosi -tason tilalta, eivätkä käyttäjät huomaa mitään.

# Scheduled scaling arkisin 08:00 EEST
aws application-autoscaling put-scheduled-action \
  --service-namespace lambda \
  --scheduled-action-name lambda-scale-up-workday \
  --resource-id function:my-api:PROD \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --schedule "cron(0 6 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=5,MaxCapacity=20

Lambda vs Fargate vs EC2: kustannusten taittopiste

Yleinen kysymys on: milloin Lambda muuttuu Fargate- tai EC2-vaihtoehtoa kalliimmaksi? Vastaus riippuu käyttöasteesta ja hinnoitteluvertailusta. Alla oleva taulukko näyttää tyypilliset taittopisteet 1 vCPU / 2 GB muistin työkuormalle eu-west-1:ssä (heinäkuu 2026):

Ominaisuus	AWS Lambda (arm64)	AWS Fargate Spot	EC2 t4g.small + ASG
Perushinta	$0,0000133 / GB-s	~$0,012 / vCPU-h	~$0,015 / instanssi-h
Idle-kustannus	$0 (ei kutsuja = ei laskua)	Aina päällä = aina maksullinen	Aina päällä = aina maksullinen
Kylmäkäynnistys	50–200 ms (SnapStartilla)	10–30 s uudelle taskille	1–3 min uudelle instanssille
Maksimikesto	15 min per kutsu	Rajaton	Rajaton
Taittopiste (jatkuva käyttö)	< 45 % vuorokausikäyttö	45–70 % vuorokausikäyttö	> 70 % vuorokausikäyttö
Toiminnalliset kustannukset	Matalat (ei OS-hallintaa)	Keskitaso (kontit)	Korkeat (patchit, monitorointi)

Käytännön johtopäätös: tapahtumapohjaisille työkuormille (webhookit, S3-triggerit, Cognito-triggerit, batch-työt) Lambda on lähes aina paras. Vakiokuormituksille API-taustapalvelu, joka saa yli 500 pyyntöä/sekunti 24/7, taittopiste kulkee Fargaten kautta. Todella suurille, tasaisille kuormille EC2 spot -pohjainen ASG voittaa. Jos suunnittelet Lambda-arkkitehtuuria, tarkista taittopiste ennen kuin komponentti kasvaa siihen kokoon. Refaktorointi jälkikäteen on kalliimpaa kuin arkkitehtuuripäätös etukäteen. Kirjoitin aiemmin Kubernetes-kustannusten optimoinnista Karpenterilla, jossa käsittelen konttien puolta samasta valinnasta tarkemmin.

Lambda vs Azure Functions vs GCP Cloud Functions

Monipilviasiakkailla tulee usein kysymys: onko toinen pilvi halvempi serverlessille? Alla suora vertailu identtisen työkuorman hinnoista (128 MB muistia, 100 ms suoritusaika, 10 miljoonaa kutsua kuukaudessa) heinäkuun 2026 listahinnoilla:

Ominaisuus	AWS Lambda (arm64)	Azure Functions (Consumption)	GCP Cloud Functions (Gen 2)
Hinta / 1 M kutsua	$0,20	$0,20	$0,40
Hinta / GB-s	$0,0000133	$0,000016	$0,0000025 (CPU) + $0,0000025 (RAM)
Vapaataso / kk	1 M kutsua + 400 000 GB-s	1 M kutsua + 400 000 GB-s	2 M kutsua + 400 000 GB-s
Maksimikesto	15 min	10 min (Consumption) / rajaton (Premium)	60 min (HTTP) / 9 min (event)
ARM-tuki	Kyllä (Graviton, 20 % halvempi)	Ei (vain x86)	Ei suoraan (Cloud Run-pohjainen)
Kylmäkäynnistysratkaisu	SnapStart, Provisioned Concurrency	Premium Plan, Always Ready	Min instances (jatkuva lasku)

Rehellinen yhteenveto: raakahinnalla Lambda ja Azure Functions ovat käytännössä tasan, GCP Cloud Functions on hieman kalliimpi kutsuista mutta halvempi compute-osasta pitkille funktioille. ARM-tuki on Lambda-etu, jota kilpailijat eivät ole vieläkään tuoneet. Ekosysteemi (tapahtumalähteet, hallintatyökalut, IAM-integraatio) on kuitenkin useimmiten ratkaisevampi kuin listahinta. Pidä tämä mielessä kun laskelmasi näyttää 5 %:n eron per palveluntarjoaja. Multi-cloud-arkkitehtuurissa yhdenmukainen kustannusten kohdistus vaatii omat käytäntönsä; kirjoitin siitä tageilla ja kustannusten kohdistamisella AWS:ssä, Azuressa ja GCP:ssä.

Lambda-kustannusten seuranta ja hälytykset

Optimointi ilman seurantaa taantuu 3–6 kuukauden sisällä. Suosittelen kolmea tasoa:

1. Cost Explorerin ryhmittely funktion mukaan. Ota käyttöön Cost Allocation Tags ja tageaa jokainen Lambda-funktio vähintään app, env ja owner -tageilla. Cost Explorerissa suodata palvelu = AWS Lambda ja ryhmittele app-tagin mukaan.

2. AWS Budgets -hälytys per funktio-ryhmä. Aseta esimerkiksi tuotannon Lambda-käyttöön $500/kk budjetti ja hälytys 80 %:ssa. Käytännössä hälytys palautuu ennen kuin CFO huomaa laskun (ja se järjestys on oikeasti tärkeä).

3. CloudWatch-hälytys GB-sekunneista. Luo synteettinen mittari (Metric Math): (m1 * m2) / 1024 / 1000, missä m1 = Duration, m2 = MemorySize. Hälytä kun GB-sekunnit kasvavat yli 30 % viikkokeskiarvosta. Se paljastaa regressiot ennen laskua.

aws cloudwatch put-metric-alarm \
  --alarm-name "lambda-gb-seconds-spike-prod-api" \
  --metric-name Duration \
  --namespace AWS/Lambda \
  --dimensions Name=FunctionName,Value=prod-api-handler \
  --statistic Average \
  --period 3600 \
  --evaluation-periods 3 \
  --threshold 800 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:eu-west-1:123456789012:cost-alerts

Yleisemmällä tasolla suosittelen lukemaan FinOps-oppaan pilvikustannusten kokonaisoptimointiin, koska Lambda on vain yksi vipu. Suuret säästöt tulevat, kun sama kuri viedään myös RDS:ään, S3:een ja EC2:een. Jos työkuormasi ovat vahvasti tapahtumapohjaisia, kannattaa tutkia myös Spot-instanssien hyödyntämistä AWS:ssä, Azuressa ja GCP:ssä Fargate- tai EC2-taustan puolella.

AWS:n virallinen dokumentaatio kannattaa käydä läpi ennen isoja arkkitehtuurimuutoksia: AWS Lambdan viralliset hinnastot ja SnapStartin kehitysdokumentaatio päivittyvät useammin kuin ehdit skannata blogit.

Usein kysytyt kysymykset

Kuinka paljon ARM Graviton säästää Lambda-kustannuksissa?

ARM Graviton -arkkitehtuurin GB-sekuntihinta on 20 % alhaisempi kuin x86:n ja tyypillisesti suoritusaika on 5–19 % lyhyempi Python-, Node.js- ja Go-työkuormille. Kokonaissäästö on käytännössä 25–35 %. Vaihto vaatii natiivien riippuvuuksien ja Lambda Layerien arm64-yhteensopivuuden tarkistamisen.

Miksi pienemmällä muistilla ajaminen ei säästä Lambda-kustannuksia?

Muistiasetus skaalaa myös CPU:ta ja verkkoa: 128 Mt:n funktio saa noin 1/8 CPU:sta verrattuna 1024 Mt:iin. Tämä tekee funktioista niin hitaita, että pidennetty suoritusaika kumoaa muistin säästön ja lopputulos on usein kalliimpi. Lambda Power Tuning löytää muistin optimipisteen, joka on yleensä 512 Mt ja 2048 Mt:n välillä.

Mikä on SnapStart ja miten se vähentää kustannuksia?

SnapStart on AWS:n Firecracker-snapshot -tekniikka, joka poistaa Java-, Python- ja .NET-funktioiden kylmäkäynnistysrangaistuksen. Se on ilmainen käyttää, mutta se vähentää epäsuoraa kustannusta poistamalla tarpeen provisioned concurrencyyn (joka voi maksaa satoja dollareita kuukaudessa). Ainoa vaatimus on käyttää julkaistuja funktioversioita eikä $LATEST-aliasta.

Milloin AWS Lambda tulee EC2:ta tai Fargatea kalliimmaksi?

Yleinen nyrkkisääntö on, että Lambda voittaa alle 45 %:n vuorokausikäytöllä, Fargate 45–70 %:ssa ja EC2 Reserved/Spot yli 70 %:ssa. Tarkka piste riippuu muistiasetuksesta ja instanssikoosta. Tapahtumapohjaiset työkuormat (webhookit, S3-triggerit, jonon kuluttajat) pysyvät Lambdassa lähes aina, kun taas 24/7 API:t yli 500 RPS:ssä siirretään usein Fargatelle.

Miten seuraan yksittäisen Lambda-funktion kustannuksia?

Ota käyttöön AWS Cost Allocation Tags ja tageaa jokainen funktio vähintään app-, env- ja owner-tageilla. Cost Explorerissa suodata palvelu = AWS Lambda ja ryhmittele valitun tagin mukaan. Lisäksi CloudWatch Metric Math -kaavalla (Duration × MemorySize) / 1024 / 1000 saat GB-sekunnit reaaliajassa ja voit hälyttää poikkeamista ennen kuukausilaskua.