Strategieën en Best Practices 16 min leestijd

Serverless Kosten Optimaliseren: Bespaar tot 40% op AWS Lambda, Azure Functions en Google Cloud

Leer hoe je tot 40% bespaart op serverless-kosten bij AWS Lambda, Azure Functions en Google Cloud Functions. Met actuele prijzen, Power Tuning, Graviton2-tips en werkende codevoorbeelden voor 2026.

Editorial Team

Waarom Serverless Kostenoptimalisatie in 2026 Essentieel Is

Serverless computing heeft de manier waarop we applicaties bouwen en deployen fundamenteel veranderd. Geen servers meer beheren, geen capaciteitsplanning, en je betaalt alleen voor wat je daadwerkelijk gebruikt — klinkt als de ultieme kostenbesparing, toch?

In theorie wel. In de praktijk? Niet altijd.

Steeds meer organisaties zien hun serverless-rekeningen onverwacht oplopen. En dat is precies het probleem: de schijnbare eenvoud van pay-per-use maskeert een complex kostenmodel dat zonder actief beheer flink uit de hand kan lopen. Ik heb teams meegemaakt die dachten goedkoop uit te zijn met Lambda, om vervolgens te schrikken van een rekening die drie keer zo hoog was als verwacht.

Uit recent onderzoek blijkt dat organisaties die proactief hun serverless-functies optimaliseren 20 tot 40% kunnen besparen op hun maandelijkse rekening — zonder prestaties op te offeren. Die besparingen komen voort uit geheugenoptimalisatie, slimme architectuurkeuzes en het begrijpen van de (soms verrassende) kostenstructuur per provider.

In eerdere artikelen hebben we gekeken naar Kubernetes-kostenoptimalisatie en cloudopslagbesparingen. Deze gids completeert het plaatje door diep in te gaan op de derde grote uitgavenpost: serverless computing. We behandelen AWS Lambda, Azure Functions en Google Cloud Functions — met actuele prijzen, werkende codevoorbeelden en bewezen besparingsstrategieën voor 2026.

Het Serverless Kostenmodel Ontleed

Voordat we gaan optimaliseren, moeten we eerst snappen waarvoor we eigenlijk betalen. Het serverless-prijsmodel lijkt simpel, maar eerlijk gezegd heeft het meer variabelen dan de meeste teams beseffen.

De Drie Kostenpijlers

  • Aanroepen (invocations): Een vast bedrag per miljoen functie-aanroepen. Dit is doorgaans het kleinste deel van de rekening, maar kan bij hoge volumes toch flink oplopen.
  • Rekentijd (GB-seconden): De hoofdmoot van je kosten. Berekend als: toegewezen geheugen (in GB) × uitvoeringstijd (in seconden). Dit vormt typisch 60 tot 85% van je totale serverless-uitgaven.
  • Bijkomende kosten: Denk aan API Gateway-verzoeken (AWS), opslagkosten, netwerkverkeer (egress) en eventueel Provisioned Concurrency. Deze worden vaak over het hoofd gezien, maar ze kunnen behoorlijk aantikken.

Prijsvergelijking per Provider (maart 2026)

Hieronder een actueel overzicht van de basisprijzen. Bewaar dit als referentie — je hebt het nodig bij de optimalisatiestappen verderop.

┌──────────────────────┬─────────────────┬──────────────────┬──────────────────────┐
│ Component            │ AWS Lambda      │ Azure Functions  │ Google Cloud Func.   │
├──────────────────────┼─────────────────┼──────────────────┼──────────────────────┤
│ Gratis aanroepen     │ 1 miljoen/mnd   │ 1 miljoen/mnd    │ 2 miljoen/mnd        │
│ Gratis GB-sec        │ 400.000/mnd     │ 400.000/mnd      │ 400.000/mnd          │
│ Prijs per 1M aanr.   │ $0,20           │ $0,20            │ $0,40                │
│ Prijs per GB-sec     │ $0,0000166667   │ $0,000016        │ $0,0000025           │
│ Min. geheugen        │ 128 MB          │ 128 MB           │ 128 MB               │
│ Max. geheugen        │ 10.240 MB       │ 1.536 MB (Cons.) │ 32.768 MB (2e gen)   │
│ Facturatie-eenheid   │ 1 ms            │ 1 ms             │ 100 ms               │
│ ARM-ondersteuning    │ Ja (Graviton2)  │ Nee              │ Nee                  │
└──────────────────────┴─────────────────┴──────────────────┴──────────────────────┘

Let op: Google Cloud Functions heeft een aanzienlijk lagere prijs per GB-seconde, maar rekent ook apart voor CPU-tijd ($0,00001 per GHz-seconde) en hanteert een hogere prijs per miljoen aanroepen. De werkelijke kosten per functie-uitvoering liggen daardoor dichter bij elkaar dan je op het eerste gezicht zou denken.

AWS Lambda: Geheugen, Graviton en Power Tuning

AWS Lambda is veruit het meest gebruikte serverless platform, en biedt gelukkig ook de meeste knoppen om aan te draaien voor kostenoptimalisatie. De belangrijkste hefboom? Geheugenallocatie.

Waarom Geheugen de Sleutel Is

Bij Lambda bepaalt de geheugeninstelling meer dan alleen RAM. Het bepaalt proportioneel ook de CPU-kracht, netwerkbandbreedte en disk-I/O. Een functie met 1.792 MB geheugen krijgt ongeveer twee keer zoveel CPU als eentje met 896 MB.

Dit leidt tot iets dat contra-intuïtief aanvoelt: meer geheugen toewijzen kan je kosten verlagen, simpelweg doordat de functie sneller klaar is. Laat me dat even met een concreet voorbeeld laten zien:

# Kostenberekening bij 512 MB
geheugen_gb = 0.5
duur_sec = 3.0
gb_seconden = 0.5 * 3.0  # = 1.5 GB-sec
kosten = 1.5 * 0.0000166667  # = $0.000025

# Dezelfde functie op 1024 MB draait in 1.200 ms
geheugen_gb = 1.0
duur_sec = 1.2
gb_seconden = 1.0 * 1.2  # = 1.2 GB-sec
kosten = 1.2 * 0.0000166667  # = $0.000020

# Resultaat: 20% lagere kosten met dubbel geheugen!

Ja, je leest het goed — dubbel zoveel geheugen, 20% minder kosten. Dat is het soort optimalisatie waar ik enthousiast van word.

AWS Lambda Power Tuning: Data-gedreven Optimalisatie

Het handmatig testen van geheugenconfiguraties is tijdrovend en eerlijk gezegd ook een beetje saai. Gelukkig is er een uitstekende open-source tool: AWS Lambda Power Tuning. Deze tool, gebouwd op AWS Step Functions, test je functie automatisch met verschillende geheugenconfiguraties en geeft je een heldere visualisatie van kosten versus prestaties.

Deployen kan via de AWS Serverless Application Repository of via Terraform:

# Deployen via AWS SAM
sam deploy \
  --template-url https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:451282441545:applications~aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM

# Of via Terraform
resource "aws_serverlessapplicationrepository_cloudformation_stack" "power_tuning" {
  name           = "lambda-power-tuning"
  application_id = "arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning"
  capabilities   = ["CAPABILITY_IAM"]
}

Start vervolgens een tuning-run met deze Step Functions input:

{
  "lambdaARN": "arn:aws:lambda:eu-west-1:123456789:function:mijn-api",
  "powerValues": [128, 256, 512, 1024, 1536, 2048, 3008],
  "num": 50,
  "payload": {"key": "waarde"},
  "strategy": "balanced"
}

De tool genereert een interactieve grafiek waarmee je in één oogopslag ziet welke geheugenconfiguratie de beste prijs-prestatieverhouding biedt. In de praktijk levert dit 15 tot 35% kostenbesparing op per functie — dat is echt de moeite waard.

Schakel Over naar Graviton2 (ARM64)

Dit is eerlijk gezegd de makkelijkste besparing die je kunt doen op AWS Lambda: overstappen naar Graviton2-processoren (ARM64-architectuur). De cijfers spreken voor zich:

  • 20% lagere prijs per GB-seconde ($0,0000133334 vs. $0,0000166667)
  • Tot 34% betere prijs-prestatieverhouding voor de meeste workloads
  • Geen codewijzigingen nodig voor de meeste runtimes (Python, Node.js, Java)
# Lambda-functie configureren voor ARM64
aws lambda update-function-configuration \
  --function-name mijn-api \
  --architectures arm64

# Of in een SAM-template
Resources:
  MijnFunctie:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.12
      Architectures:
        - arm64
      MemorySize: 1024
      Timeout: 30

Belangrijk: Test altijd grondig na de overstap. Native C/C++-extensies en sommige binaire dependencies moeten opnieuw gecompileerd worden voor ARM64. Python-packages met C-extensies (zoals pandas of numpy) werken doorgaans probleemloos dankzij Lambda's package-management, maar vertrouw er niet blind op.

Azure Functions: Consumption vs. Premium — Wanneer Kies Je Wat?

Azure Functions biedt drie hostingplannen, elk met een eigen kostenstructuur. De keuze tussen deze plannen heeft verreweg de grootste impact op je rekening.

Consumption Plan: Voor Onvoorspelbare Workloads

Het Consumption Plan is het echte serverless model: je betaalt alleen voor wat je gebruikt. Ideaal voor event-driven workloads met wisselende belasting.

Maar er zitten wel beperkingen aan:

  • Maximaal 1.536 MB geheugen per functie
  • Geheugen wordt afgerond naar de dichtstbijzijnde 128 MB
  • Cold starts bij eerste aanroep na inactiviteit (typisch 1-3 seconden)
  • Maximale uitvoeringstijd van 10 minuten (configureerbaar tot 60 minuten)

Flex Consumption Plan: Het Nieuwe Middensegment

Het Flex Consumption Plan is relatief nieuw en biedt een interessante middenweg. Het combineert de schaalflexibiliteit van Consumption met always-ready instances die cold starts elimineren — en dat tegen een fractie van de Premium-kosten.

# Azure CLI: Flex Consumption function app aanmaken
az functionapp create \
  --resource-group mijn-rg \
  --name mijn-flex-app \
  --storage-account mijnopslag \
  --runtime python \
  --runtime-version 3.11 \
  --functions-version 4 \
  --flexconsumption-location westeurope \
  --instance-memory 2048

# Always-ready instances instellen om cold starts te voorkomen
az functionapp scale config set \
  --resource-group mijn-rg \
  --name mijn-flex-app \
  --always-ready-instances 2

De prijzen voor Flex Consumption zijn hoger dan het standaard Consumption Plan ($0,000026 per GB-sec versus $0,000016), maar de always-ready instances tegen slechts $0,000004 per GB-sec idle-tijd maken het aantrekkelijk voor latentiegevoelige applicaties. Teams die voorheen noodgedwongen het duurdere Premium Plan gebruikten puur vanwege cold starts, kunnen hier serieus op besparen.

Wanneer Loont Premium?

Het Premium Plan is eigenlijk alleen zinvol wanneer je aan alle drie deze voorwaarden voldoet:

  1. Je hebt consistente, voorspelbare belasting (niet event-driven pieken)
  2. Je hebt VNET-integratie nodig voor connectiviteit met private resources
  3. Je functies vereisen meer dan 1.536 MB geheugen of langere uitvoeringstijden

In alle andere gevallen is Consumption of Flex Consumption voordeliger. Veel teams kiezen te snel voor Premium vanwege cold starts, terwijl het Flex Consumption Plan daar nu een veel goedkopere oplossing voor biedt. Dus voordat je Premium aanschakelt — check eerst of Flex niet volstaat.

Google Cloud Functions: GHz-seconden en Gen 2

Google Cloud Functions (inmiddels hernoemd naar Cloud Run Functions) heeft een uniek prijsmodel dat apart factureert voor CPU en geheugen. Dat maakt de kostenoptimalisatie iets complexer, maar geeft je ook meer granulaire controle.

Het Dubbele Facturatiemodel

In tegenstelling tot AWS en Azure rekent Google apart voor:

  • Geheugen: $0,0000025 per GB-seconde (Tier 1-regio's)
  • CPU: $0,00001 per GHz-seconde
  • Aanroepen: $0,40 per miljoen (na 2 miljoen gratis)

Even concreet maken met een voorbeeld:

# Google Cloud Functions kostenberekening
# Functie: 256 MB geheugen, 200 MHz CPU, 500 ms uitvoeringstijd

geheugen_kosten = 0.256 * 0.5 * 0.0000025   # = $0.00000032
cpu_kosten = 0.200 * 0.5 * 0.00001          # = $0.000001
totaal_per_aanroep = 0.00000032 + 0.000001  # = $0.00000132

# Bij 10 miljoen aanroepen per maand:
maandkosten_compute = 10_000_000 * 0.00000132  # = $13.20
maandkosten_aanroepen = (10 - 2) * 0.40         # = $3.20
totaal = 13.20 + 3.20                          # = $16.40

Gen 2: Wanneer Overstappen?

Gen 2-functies draaien op Cloud Run en bieden flinke voordelen voor kostenoptimalisatie:

  • Concurrency: Eén instantie kan meerdere verzoeken tegelijk afhandelen (tot 1.000), waardoor je veel minder instanties nodig hebt
  • Langere uitvoeringstijd: Tot 60 minuten (vs. 9 minuten bij Gen 1)
  • Onafhankelijke CPU/geheugen-configuratie: Stel CPU en geheugen apart in voor optimale prijs-prestatie
  • Minimum instances: Configureerbaar om cold starts te voorkomen
# Google Cloud Function Gen 2 deployen met concurrency
gcloud functions deploy mijn-api \
  --gen2 \
  --runtime=python312 \
  --region=europe-west1 \
  --source=. \
  --entry-point=handler \
  --trigger-http \
  --memory=512Mi \
  --cpu=1 \
  --concurrency=80 \
  --min-instances=1 \
  --max-instances=100

# Controleer de huidige configuratie
gcloud functions describe mijn-api --gen2 --region=europe-west1

De concurrency-instelling is hier dé grote besparingshefboom. Door één instantie 80 verzoeken tegelijk te laten afhandelen in plaats van 1, bespaar je tot 80% op compute-kosten bij high-traffic endpoints. Dat is geen typfout — tachtig procent.

Cross-Platform Besparingsstrategieën

Ongeacht welke provider je gebruikt, zijn er universele strategieën die vrijwel altijd besparingen opleveren. Hier zijn de vijf die in mijn ervaring het meeste impact hebben.

1. Initialisatie Buiten de Handler

SDK-clients, databaseverbindingen en configuratie laden kost tijd. Door deze buiten de handler te plaatsen, worden ze hergebruikt bij warme starts. Het is zo'n simpele aanpassing dat je je afvraagt waarom niet iedereen het doet:

# ❌ Duur: elke aanroep initialiseert opnieuw
def handler(event, context):
    import boto3
    s3 = boto3.client("s3")
    data = s3.get_object(Bucket="mijn-bucket", Key="data.json")
    return process(data)

# ✅ Efficiënt: eenmalige initialisatie, hergebruik bij warme starts
import boto3
s3 = boto3.client("s3")

def handler(event, context):
    data = s3.get_object(Bucket="mijn-bucket", Key="data.json")
    return process(data)

Dit scheelt typisch 100 tot 500 ms per aanroep bij warme starts. Klinkt weinig, maar bij duizenden aanroepen per uur telt dat serieus op in GB-seconden.

2. Voorkom Function Sprawl

Function sprawl — de wildgroei van functies — is de serverless-variant van het zombie-server-probleem. En het komt vaker voor dan je denkt. Teams deployen functies voor tijdelijke tests of proof-of-concepts die vervolgens vergeten worden.

Hoewel ongebruikte functies zelf niets kosten aan compute, genereren ze wel degelijk kosten door:

  • CloudWatch Logs (AWS): loggroepen worden niet automatisch opgeruimd
  • Provisioned Concurrency die actief staat op ongebruikte functies
  • API Gateway-endpoints die nog steeds in rekening worden gebracht
  • Gekoppelde opslagresources zoals S3-buckets of DynamoDB-tabellen
# AWS: Vind functies die langer dan 90 dagen niet zijn aangeroepen
aws lambda list-functions --query "Functions[].FunctionName" --output text | \
while read fn; do
  last=$(aws cloudwatch get-metric-statistics \
    --namespace AWS/Lambda \
    --metric-name Invocations \
    --dimensions Name=FunctionName,Value=$fn \
    --start-time $(date -d "90 days ago" -u +%Y-%m-%dT%H:%M:%S) \
    --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
    --period 7776000 \
    --statistics Sum \
    --query "Datapoints[0].Sum" --output text)
  if [ "$last" = "None" ] || [ "$last" = "0.0" ]; then
    echo "ONGEBRUIKT: $fn"
  fi
done

Maak er een gewoonte van om dit script maandelijks te draaien. Je zult verbaasd zijn hoeveel vergeten functies er rondslingeren.

3. Batchverwerking in Plaats van Individuele Aanroepen

Wanneer je SQS-berichten of events verwerkt, is batch-processing een directe kostenbesparing. In plaats van per bericht een functie aan te roepen, verwerk je ze in groepen:

# AWS Lambda SQS Event Source Mapping met batching
Resources:
  MijnFunctie:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.12
      Events:
        SQSTrigger:
          Type: SQS
          Properties:
            Queue: !GetAtt MijnQueue.Arn
            BatchSize: 100          # Max 100 berichten per batch
            MaximumBatchingWindowInSeconds: 30  # Wacht max 30 sec
            FunctionResponseTypes:
              - ReportBatchItemFailures  # Alleen mislukte items opnieuw

Door 100 berichten in één aanroep te verwerken in plaats van 100 afzonderlijke aanroepen, bespaar je tot 99% op aanroepkosten en reduceer je de overhead van cold starts drastisch. Dat is absoluut een van de meest onderschatte optimalisaties.

4. Stel Budgetalarmen In

Serverless-kosten kunnen onverwacht exploderen door een runaway-functie, een DDoS-aanval of een simpele bug die oneindige loops veroorzaakt. Geloof me, het overkomt de beste teams. Stel daarom altijd budgetalarmen in:

# AWS: Budget-alarm instellen via CLI
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Lambda-Maandbudget",
    "BudgetLimit": {"Amount": "500", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "CostFilters": {
      "Service": ["AWS Lambda"]
    }
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "[email protected]"
    }]
  }]'

5. Gebruik Compute Savings Plans voor Lambda

Wat veel teams niet weten: AWS Compute Savings Plans gelden ook voor Lambda. Met een commitment van 1 of 3 jaar bespaar je tot 17% op alle Lambda-kosten. Dit komt bovenop de besparingen uit geheugenoptimalisatie en Graviton2.

Het is pas zinvol wanneer je een stabiele, voorspelbare Lambda-baseline hebt — combineer het dus altijd met een grondige analyse van je historische uitgaven via AWS Cost Explorer. Blindelings een Savings Plan afsluiten zonder die data is vragen om teleurstelling.

Monitoring en Doorlopende Optimalisatie

Kostenoptimalisatie is geen eenmalige actie. Dat kan ik niet genoeg benadrukken. Workloads veranderen, nieuwe functies worden gedeployd en verkeerspatronen verschuiven continu. Implementeer doorlopende monitoring met provider-specifieke tools:

  • AWS: Gebruik AWS Cost Explorer met filters op Lambda-service, combineer met CloudWatch Metrics voor per-functie inzichten. AWS Compute Optimizer geeft automatische geheugen-aanbevelingen — echt een aanrader.
  • Azure: Azure Cost Management + Budget Alerts bieden vergelijkbare mogelijkheden. Application Insights toont functie-niveau uitvoeringsstatistieken en kan bottlenecks identificeren.
  • Google Cloud: Cloud Billing Reports met filters op Cloud Functions. Cloud Monitoring dashboards voor uitvoeringstijden en resourceverbruik per functie.

Het doel is om maandelijks een review te doen van je serverless-uitgaven, gecombineerd met automatische alerts bij afwijkingen van meer dan 20% ten opzichte van het vorige maandgemiddelde. Maak er een vast agendapunt van — je toekomstige zelf zal je dankbaar zijn.

Veelgestelde Vragen

Is serverless altijd goedkoper dan containers of VM's?

Nee, zeker niet. Serverless is kostenefficiënt bij wisselende of onvoorspelbare workloads met periodes van inactiviteit. Bij constante, hoge belasting (meer dan 60-70% van de tijd actief) zijn containers op Kubernetes of gereserveerde VM's doorgaans goedkoper. De break-even ligt typisch bij zo'n 10 tot 20 miljoen aanroepen per maand, afhankelijk van de uitvoeringstijd per functie.

Hoe voorkom ik onverwachte kosten bij een serverless-applicatie?

Stel budgetalarmen in per service, implementeer concurrency-limieten op je functies (bijvoorbeeld ReservedConcurrentExecutions in AWS Lambda), en monitor actief op runaway-functies. Overweeg ook een API Gateway-throttle als bescherming tegen onverwacht hoog verkeer. Bij Azure biedt het Consumption Plan een automatische schaallimiet van maximaal 200 instanties.

Wat is het verschil tussen cold starts en Provisioned Concurrency?

Een cold start treedt op wanneer er geen warme instantie beschikbaar is om een verzoek af te handelen. De functie-runtime moet dan volledig geïnitialiseerd worden, wat typisch 100 ms tot 3 seconden duurt afhankelijk van de taal en package-grootte. Provisioned Concurrency (AWS) of Always Ready Instances (Azure Flex) houden een configureerbaar aantal instanties warm. Dit elimineert cold starts, maar brengt continue kosten met zich mee — ook wanneer de instanties niet actief worden gebruikt.

Welke programmeertaal is het goedkoopst voor serverless?

Python en Node.js hebben de snelste cold starts (50-200 ms) en het laagste basisgeheugengebruik, waardoor ze doorgaans de goedkoopste keuze zijn. Java en .NET hebben langere cold starts (1-3 seconden) maar presteren vaak beter bij CPU-intensieve taken. Met GraalVM native images of .NET AOT-compilatie zijn cold starts voor deze talen inmiddels behoorlijk verbeterd. Kies de taal die het beste past bij je workload — pure kosten mogen niet de enige factor zijn.

Kan ik Savings Plans combineren met Graviton2-korting op AWS Lambda?

Ja, absoluut. Compute Savings Plans en Graviton2-architectuur zijn onafhankelijke besparingen die je kunt stapelen. De Graviton2-korting verlaagt de prijs per GB-seconde met 20%, en de Savings Plan biedt daar bovenop tot 17% extra besparing. Gecombineerd met geheugenoptimalisatie via Power Tuning kun je tot 50% of meer besparen ten opzichte van de standaard x86 on-demand prijs. Dat is serieus geld bij grotere deployments.

Over de Auteur Editorial Team

Our team of expert writers and editors.

Gerelateerde Artikelen