Kennisbank
Hosting 7 min leestijd

Kosten-optimalisatie bij AWS serverless.

Concrete keuzes om cloudkosten voorspelbaar te houden. Over Lambda pricing, S3 lifecycle policies en waarom serverless niet automatisch goedkoop is.

Serverless is niet automatisch goedkoop

Het verkoopverhaal van serverless klinkt fantastisch: betaal alleen voor wat je gebruikt, geen idle servers, kosten die meeschalen met je business. En dat klopt — deels. Maar de realiteit is genuanceerder dan de marketingpagina's van AWS suggereren.

De misvatting die we het vaakst tegenkomen: "geen servers = geen kosten". Dat is niet hoe het werkt. Serverless verplaatst de kosten, het elimineert ze niet. In plaats van een vaste maandelijkse factuur voor een server krijg je een variabele factuur die afhangt van tientallen parameters: het aantal Lambda-invocations, de duur van elke executie, het toegewezen geheugen, het aantal API Gateway-requests, de hoeveelheid data die je opslaat in S3, de data transfer tussen services, je database-uren, je cache-nodes.

Die complexiteit is precies het probleem. AWS heeft meer dan 200 services met elk hun eigen prijsmodel. Zonder bewuste keuzes kan een serverless architectuur duurder uitvallen dan een simpele VPS van EUR 50 per maand. Niet omdat serverless slecht is, maar omdat het een ander soort aandacht vraagt.

Waar de kosten zitten

Om te optimaliseren moet je eerst begrijpen waar je geld naartoe gaat. Dit zijn de belangrijkste kostenposten bij een typische serverless Laravel-applicatie op AWS:

Lambda. Je betaalt per invocation (verzoek) en per milliseconde uitvoeringstijd, vermenigvuldigd met het toegewezen geheugen. Bij een applicatie met 100.000 requests per dag zijn de Lambda-kosten vaak verrassend laag — enkele euro's per maand. Het wordt pas duur bij hoge volumes of inefficiente code die lang draait.

RDS (database). Dit is vrijwel altijd de grootste kostenpost. Een RDS-instance draait 24/7, ook als niemand je applicatie gebruikt. Een db.t3.medium kost al snel EUR 60-80 per maand. Tel daar Multi-AZ voor failover bij op en je zit op het dubbele.

API Gateway. Elke HTTP-request naar je applicatie gaat via API Gateway, en je betaalt per request. Bij hoog verkeer tikt dit door. Een miljoen requests kost ongeveer EUR 3,50, maar bij tientallen miljoenen per maand wordt het een relevante post.

S3. Opslagkosten zijn laag, maar requests en data transfer niet. Elk GET- en PUT-request kost geld. Sla je miljoenen kleine bestanden op en worden ze vaak opgevraagd, dan loopt dit op.

CloudFront. Data transfer out — de data die je naar gebruikers stuurt — is een van de duurste onderdelen van AWS. CloudFront is goedkoper dan direct vanuit S3 serveren, maar bij mediarijke applicaties kan dit een significante post worden.

Data transfer tussen services. Dit is de kostenpost die de meeste teams over het hoofd zien. Data die tussen AWS-services beweegt — van Lambda naar S3, van SQS naar Lambda, van je applicatie naar RDS — kost geld. Het is per gigabyte niet veel, maar het accumuleert.

De duurste cloudkosten zijn de kosten die je niet zag aankomen. Serverless is pas goedkoop als je weet waar je op moet letten.

Concrete optimalisaties

Lambda tuning

De belangrijkste variabele bij Lambda is geheugen. Meer geheugen betekent een snellere CPU en daarmee kortere uitvoeringstijd. Een functie die met 128MB geheugen 800ms draait, doet met 512MB hetzelfde werk in 200ms. De kosten per milliseconde zijn hoger, maar de totale kosten per request zijn lager. Test dit per functie — het optimale punt verschilt per workload.

Minimaliseer cold starts door je deployment-package klein te houden en onnodige dependencies te elimineren. Hergebruik database-connecties en HTTP-clients tussen invocations door ze buiten je handler te initialiseren. Dit bespaart niet alleen kosten maar verbetert ook de response-tijden.

Database

De database is de grootste kostenpost, dus hier valt het meeste te besparen. Aurora Serverless v2 is een serieuze optie voor workloads met variabel verkeer: de database schaalt automatisch op en af, tot een minimum van 0.5 ACU. Voor applicaties met duidelijke piek- en daluren scheelt dit fors ten opzichte van een vaste RDS-instance.

Gebruik read replicas voor leesintensieve applicaties. De meeste webapplicaties lezen tien keer zoveel als ze schrijven. Door reads naar een replica te sturen, verlaag je de load op je primaire database en kun je een kleinere (goedkopere) instance kiezen. Zet RDS Proxy in voor connection pooling — het voorkomt dat Lambda-functies je database overspoelen met connecties en reduceert de overhead per request.

Opslag

S3 lifecycle policies zijn een van de meest onderbenutte besparingsmogelijkheden. Configureer regels die bestanden automatisch verplaatsen naar goedkopere storage classes: na 30 dagen naar S3 Infrequent Access, na 90 dagen naar Glacier. Voor data die je zelden nodig hebt maar moet bewaren, scheelt dit tot 80% op opslagkosten.

Ruim tijdelijke bestanden actief op. Exports, tijdelijke uploads, gegenereerde PDF's die al verstuurd zijn — veel applicaties laten dit sluipenderwijs groeien. Een simpele cleanup-job die dagelijks draait voorkomt dat je betaalt voor data waar niemand meer naar kijkt. Comprimeer bestanden voordat je ze opslaat: gzip op tekstbestanden en logs scheelt 60-80% opslagruimte.

Caching

Elke response die je uit cache serveert is een Lambda-invocation die niet hoeft te draaien, een database-query die niet wordt uitgevoerd en een API Gateway-request die niet wordt afgehandeld. Caching is daarmee een van de meest effectieve kostenoptimalisaties.

Zet CloudFront in voor alle statische assets en overweeg full-page caching voor pagina's die niet per gebruiker verschillen. Gebruik Redis via ElastiCache voor applicatie-level caching: database-queries, API-responses van externe services, berekende waarden. De kosten van een kleine Redis-node verdien je terug zodra het een paar duizend Lambda-invocations per dag bespaart.

Monitoring van kosten

Optimalisatie zonder monitoring is gokken. AWS Cost Explorer is je startpunt: het toont precies welke services hoeveel kosten, uitgesplitst per dag, week of maand. Stel budget alerts in die je waarschuwen wanneer je kosten een drempelwaarde naderen — voordat de factuur een verrassing wordt.

Tag al je resources per project en per omgeving. Zonder tags is het onmogelijk om te achterhalen welk project welk deel van de factuur veroorzaakt. Dit is vooral kritisch als je meerdere applicaties op hetzelfde AWS-account draait.

Bouw een maandelijkse review in. Bekijk de kostentrends, identificeer uitschieters, stel vast of optimalisaties effect hebben. Dit hoeft geen uren te kosten — een kwartier per maand met Cost Explorer open is voldoende om verrassingen te voorkomen.

Cloudkosten beheersen is geen eenmalige actie. Het is een gewoonte — net als je code reviewen en je dependencies updaten.

Conclusie

Serverless op AWS is een uitstekend model voor applicaties die moeten schalen en betrouwbaar moeten zijn. Maar goedkoop is het alleen wanneer je bewuste keuzes maakt: de juiste Lambda-configuratie, een doordachte database-strategie, lifecycle policies op je opslag en caching waar het kan.

De investering in kostenoptimalisatie betaalt zich dubbel terug. Niet alleen in lagere facturen, maar ook in voorspelbaarheid. En voorspelbare kosten betekent dat je met vertrouwen kunt groeien, zonder dat de AWS-factuur sneller stijgt dan je omzet. Wij helpen onze klanten om die balans te vinden — en te houden.

Onderwerpen
AWS Serverless Kosten Lambda Optimalisatie

/Hulp nodig?

Vragen over dit onderwerp? Laten we het erover hebben.

Neem contact op