Wat kost Kubernetes voor een webshop? De kostenposten

Wat Kubernetes voor een webshop kost, hangt af van een stuk of tien kostenposten: control plane, nodes, load balancers, storage, dataverkeer, managed diensten, monitoring, registry en CI, extra omgevingen, en vooral de uren voor beheer. De infrastructuur is meestal niet de grootste post. De mensen die het cluster bijhouden wel. Hieronder alle posten op een rij, plus een rekenstap die je met je eigen offertes kunt invullen.

Waarom we hier geen bedragen noemen

Prijzen van cloudaanbieders veranderen, verschillen per regio en hangen af van kortingen en contractvormen. Een bedrag dat vandaag klopt, is over een halfjaar misleidend. En een rekenvoorbeeld met verzonnen getallen is erger dan geen voorbeeld.

Wat wel stabiel is: de structuur van de kosten. Welke posten er zijn, waar ze van afhangen en welke vaak vergeten worden. Daarmee kun je elke offerte zelf narekenen.

Post 1: het control plane

Het control plane is het brein van het cluster: de API-server, de scheduler, etcd. Bij managed Kubernetes beheert de aanbieder dat. De prijsmodellen verschillen:

• Amazon EKS rekent een vast bedrag per cluster per uur. Draai je een Kubernetes-versie die buiten de standaard supportperiode valt, dan geldt een hoger tarief voor extended support.
• Google GKE rekent in Standard-modus een clusterfee per uur, met een tegoed dat één cluster per billing-account dekt. In Autopilot betaal je voor de resources die je pods aanvragen.
• Azure AKS heeft een Free-tier zonder control-plane-fee, maar ook zonder financieel gedekte SLA. De Standard- en Premium-tier kosten per cluster per uur.
• Europese aanbieders zoals Scaleway, OVHcloud en DigitalOcean hebben elk hun eigen model. Kijk op hun prijspagina.
• Zelf beheren, bijvoorbeeld k3s of Talos op Hetzner, dat zelf geen managed Kubernetes aanbiedt: geen fee, wel al het beheerwerk.

Let op het aantal clusters. Een apart cluster voor productie, staging en test betekent drie keer deze post. Meer over de keuze tussen aanbieders: managed Kubernetes kiezen.

Post 2: nodes

De nodes zijn de virtuele machines waarop je pods draaien. Dit is de grootste infrastructuurpost, en de post waar de meeste rekenfouten zitten.

Drie dingen die je meerekent:

• Je betaalt voor requests, niet voor gebruik. Kubernetes plant pods op basis van wat ze aanvragen. Vraagt een PHP-pod 1 GB geheugen aan en gebruikt hij er 400 MB, dan is die andere 600 MB bezet voor niets.
• Systeemcomponenten eten mee. Op elke node draaien DaemonSets voor logging, monitoring, netwerk en storage. Daarnaast reserveert de node zelf geheugen en CPU voor het besturingssysteem en de kubelet.
• Je hebt reserve nodig. Bij een node-upgrade of -storing moeten de pods ergens anders heen kunnen. Zonder reserve heb je bij elk onderhoud een capaciteitsprobleem.

Je ziet het verschil tussen aangevraagd en gebruikt met:

kubectl describe node <node-naam> | grep -A 8 "Allocated resources"
kubectl top pods -n shop-productie

Of over het hele cluster, in Prometheus met kube-state-metrics:

sum by (namespace) (kube_pod_container_resource_requests{resource="cpu"})
/
sum by (namespace) (rate(container_cpu_usage_seconds_total{container!=""}[1h]))

Een hoge verhouding betekent dat je meer reserveert dan je gebruikt. Requests bijstellen op basis van een paar weken metingen is vaak de goedkoopste optimalisatie die er is.

Post 3: load balancers en IP-adressen

Een Service van het type LoadBalancer of een Gateway maakt bij de meeste cloudaanbieders een load balancer aan. Die kost per uur, en soms ook per hoeveelheid verkeer of verbindingen.

Gebruik één Gateway voor al je shops en apps, met HTTPRoutes per hostnaam, in plaats van een load balancer per applicatie. Dat scheelt een post per app. Nu ingress-nginx in maart 2026 met pensioen is gegaan, is dit ook het moment om naar de Gateway API over te stappen.

Post 4: storage

Verschillende soorten, verschillende prijzen:

• Block storage voor StatefulSets zoals OpenSearch, Valkey of RabbitMQ in het cluster. Je betaalt per GB per maand, soms ook voor IOPS.
• ReadWriteMany-volumes voor gedeelde bestanden, zoals pub/media als je geen object storage gebruikt. Vaak duurder per GB dan block storage.
• Object storage voor media, back-ups en logs. Goedkoop per GB, maar let op de kosten per request en voor uitgaand verkeer.
• Snapshots en back-ups. Groeien ongemerkt als je geen bewaartermijn instelt.

Post 5: dataverkeer

Deze post wordt het vaakst vergeten. Bij de grote clouds betaal je voor:

• Uitgaand verkeer naar internet. Bij een webshop met veel afbeeldingen kan dat oplopen. Een CDN ervoor verschuift de kosten, maar haalt ze niet weg.
• Verkeer tussen zones. Staan je pods in drie availability zones en je database in één, dan betaal je voor het verkeer ertussen.
• NAT-gateways voor uitgaand verkeer van pods zonder publiek IP, zoals API-calls naar je ERP of betaalprovider.

Europese aanbieders hebben hier vaak eenvoudiger modellen, met inbegrepen verkeer. Vergelijk dit expliciet.

Post 6: managed diensten naast het cluster

Een Magento- of Laravel-platform heeft meer nodig dan alleen pods:

• Database: een managed MySQL of MariaDB. Dit raden we bijna altijd aan. Kosten hangen af van grootte, replica's en back-up-retentie.
• Cache en sessies: managed Valkey of Redis, of zelf in het cluster.
• Zoeken: managed OpenSearch, of zelf in het cluster met de operator.
• Queue: managed RabbitMQ, of zelf.

Zelf draaien in het cluster lijkt goedkoper, omdat je alleen node-capaciteit betaalt. Maar je betaalt dan met uren: upgrades, back-ups, failover testen. Zet dat eerlijk naast elkaar.

Een aandachtspunt bij zelf draaien: Bitnami heeft in 2025 zijn gratis containerimages grotendeels naar een legacy-repository verplaatst die geen updates meer krijgt. Actuele images zitten nu grotendeels achter het betaalde Bitnami Secure Images. Gebruik je Bitnami-charts, dan kies je tussen betalen, een andere bron of een eigen build. Dat is een kostenpost of een uren-post.

Post 7: monitoring en logging

Je wilt metrics, logs en alerts. Twee routes:

• Zelf hosten: Prometheus, Grafana en Loki in het cluster. Kost node-capaciteit en storage, plus beheer. Retentie bepaalt de storagekosten.
• SaaS: een monitoringdienst die per host, per GB logs of per metric-serie rekent. Minder beheer, maar de rekening groeit mee met je volume.

Bepaal vooraf hoe lang je logs en metrics bewaart. Een webshop met chatty extensies kan veel logregels per minuut produceren. Stuur debug-logging niet naar je productie-logstack. Onze aanpak staat op monitoring en logging.

Post 8: registry, CI en scanning

• Container registry: opslag van images, plus verkeer bij het pullen.
• CI-minuten: een Magento-image bouwen met DI-compilatie en static content duurt een paar minuten per build. Bij veel commits telt dat op.
• Image-scanning: met Trivy kan het zonder licentiekosten. Commerciële scanners rekenen per image of per node.

Zet een opschoonbeleid op je registry. Elke commit levert een image op; zonder opruimen groeit de opslag elke maand.

Post 9: extra omgevingen

Productie is één omgeving. Daarnaast heb je meestal:

• Staging, zo veel mogelijk gelijk aan productie;
• Test- of review-omgevingen per feature-branch;
• Een acceptatieomgeving voor de klant of de business.

Je kunt die scheiden met namespaces in één cluster, of met aparte clusters. Namespaces zijn goedkoper. Aparte clusters isoleren beter en laten je een Kubernetes-upgrade eerst op staging testen. Met een ResourceQuota per namespace voorkom je dat een testomgeving ongemerkt veel capaciteit opslokt:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
  namespace: shop-staging
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    persistentvolumeclaims: "5"

En staging hoeft 's nachts niet te draaien. Met een KEDA cron-trigger schaal je hem buiten kantoortijd naar nul:

triggers:
  - type: cron
    metadata:
      timezone: Europe/Amsterdam
      start: 0 7 * * 1-5
      end: 0 19 * * 1-5
      desiredReplicas: "2"

Post 10: de mensen

Dit is de post die in offertes het vaakst te laag staat. Het werk dat structureel terugkomt:

• Kubernetes-upgrades. Er verschijnen ongeveer drie minor-versies per jaar, elk met ongeveer veertien maanden patches. Bij EKS kost het achterblijven ook direct geld, via het extended-support-tarief.
• Add-ons bijhouden: Gateway-implementatie, cert-manager, External Secrets, Argo CD, KEDA, monitoring. Elk met eigen releases en soms brekende wijzigingen.
• Security: CVE's in images, RBAC, NetworkPolicies, secrets-rotatie.
• Bereikbaarheid buiten kantoortijd. Een webshop verkoopt ook zondagavond.
• Incidenten en capaciteitsplanning rond pieken als Black Friday.

Die uren maak je intern of je koopt ze in. Ze zijn er altijd. Een cluster dat niemand bijhoudt, is na een jaar een beveiligingsrisico.

Waar Kubernetes wel geld bespaart

De eerlijke versie heeft twee kanten. Kubernetes kan ook besparen:

• Consolidatie. Meerdere shops en apps delen nodes, monitoring en beheer, in plaats van elk een eigen omgeving met eigen overcapaciteit.
• Afschalen. Workers naar nul als de queue leeg is, staging uit in de nacht, minder webpods buiten piekuren.
• Goedkopere capaciteit voor workers. Achtergrondwerk dat onderbroken mag worden, kan op spot- of preemptible-nodes. Karpenter regelt dat op AWS, en voegt nodes samen als ze half leeg staan:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: workers
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m

Zet hier geen webpods of de checkout op spot-nodes. Een node die verdwijnt midden in een betaling, kost meer dan hij bespaart. Meer over schalen: autoscaling met HPA, KEDA en Karpenter.

De rekenstap

Vul deze vergelijking in met je eigen offertes. Per maand:

Kubernetes = control plane × aantal clusters

\+ nodes (requests + systeemoverhead + reserve)

\+ load balancers + storage + dataverkeer

\+ managed diensten (database, cache, zoeken, queue)

\+ monitoring + registry + CI

\+ beheeruren × uurtarief

Huidige situatie = hostingplannen × aantal omgevingen

\+ losse servers voor koppelingen en workers

\+ tijdelijk opschalen bij pieken

\+ beheeruren × uurtarief

Kubernetes is pas goedkoper als de besparing op losse omgevingen, overcapaciteit en handwerk groter is dan de extra posten. Bij één shop met voorspelbaar verkeer valt die som bijna altijd uit in het voordeel van managed hosting. Bij meerdere apps, wisselend verkeer en veel achtergrondwerk kan hij omslaan. De afweging uitgewerkt: Kubernetes of managed hosting voor je webshop?.

Kijk ook naar wat je bestaande hosting echt kost. Onze overzichten van Magento hosting en de TCO van Magento 2 helpen bij het invullen van de rechterkant.

Hoe wij een kostenraming maken

We beginnen met metingen, niet met aannames:

1. Huidig gebruik van CPU, geheugen, storage en verkeer, over een periode met een piek erin.
2. Workloads in kaart: web, cron, consumers, imports, koppelingen.
3. Keuze per dienst: managed of in het cluster, met de uren erbij.
4. Prijzen ophalen bij de aanbieders die passen, met hun actuele prijspagina's.
5. Beheer apart begroot, zodat je ziet welk deel infrastructuur is en welk deel werk.

Wil je zo'n raming voor je eigen situatie? Neem contact op, of lees eerst ons overzicht Kubernetes voor webshops en Laravel-platformen.