# Cloudkosten onder controle houden

URL: https://brainpowergroup.eu/nl/blog/cloudkosten-onder-controle
Datum: 2025-09-11 (bijgewerkt 2026-07-16)
Door: Aleksa, Brainpower Group

Cloudverspilling zit in testomgevingen die 's nachts draaien, losse schijven en logs zonder bewaartermijn. Een maandelijkse review per eigenaar houdt het klein.

Verspilling in de cloud zit meestal in dingen waar niemand meer naar kijkt: testomgevingen die 's nachts doordraaien, schijven van servers die al weg zijn, oude snapshots en logs zonder bewaartermijn. Om dat op te ruimen is een vaste routine genoeg: je weet wat er draait en van wie het is, en je bekijkt elke maand de rekening per eigenaar.

Ik werk in klantprojecten zelf aan infrastructuur en de kosten daarvan. Mijn voorbeelden komen uit AWS, maar de aanpak werkt op elke cloud.

## Begin met een inventaris

Maak een lijst van alle accounts, subscriptions en projecten, en per account van de regio's waarin iets draait. Een resource in een regio die verder niemand gebruikt, valt anders nooit op.

Zet per resource erbij wat het is, in welke omgeving het draait (productie, staging of test), wie de eigenaar is en of het nog nodig is. Voor de eerste ronde is een spreadsheet prima. Het doel is dat elke regel op de rekening bij een persoon en een product hoort.

Neem ook de diensten rond je cloud mee, zoals monitoring, logging, CI-minuten en een CDN. Die komen op een andere factuur binnen, maar horen bij dezelfde kosten.

## Geef elke resource tags

Met tags blijft de inventaris bij. Om te beginnen zijn `owner`, `environment` en `project` genoeg. Leg ze vast in je infrastructure as code, zodat een nieuwe resource zonder tags niet door de review komt.

Op AWS moet je user-defined cost allocation tags eerst activeren in de Billing-console voordat ze in Cost Explorer en in het cost allocation report verschijnen, en daarna kan het tot 24 uur duren voordat ze zichtbaar zijn. Activeer een nieuwe tag dus meteen en wacht niet tot je een rapport nodig hebt.

Houd ook een lijst bij van resources zonder tags en bekijk die bij elke review. Staat iets er langer dan een maand op, dan krijgt het een eigenaar of gaat het weg.

## Zet uit wat niemand gebruikt

Testomgevingen en ontwikkelservers hoeven 's nachts en in het weekend niet te draaien. Een schema dat ze om 19.00 uur uitzet en om 7.00 uur weer aan, is een paar regels code.

Een server die uit staat, kost nog steeds geld. Voor een gestopte EC2-instance betaal je geen rekentijd, maar de opslag van de EBS-volumes wordt wel gefactureerd. Elastic IP-adressen kosten ook geld, ongeacht de status van de instance.

Ook na het verwijderen blijft er soms iets achter. Bij het beëindigen van een instance verwijdert AWS standaard het rootvolume, maar andere EBS-volumes blijven standaard bestaan. Snapshots staan los van de instance en blijven ook staan. Zoek daarom elke maand naar volumes die nergens aan hangen en naar oude snapshots zonder eigenaar.

Mijn advies is om een laatste backup te maken en een resource te verwijderen als niemand hem binnen twee weken claimt.

## Right-sizing op basis van metingen

Teams kiezen servers en databases vaak ruim, "voor de zekerheid", en kijken er daarna niet meer naar. Bekijk CPU en geheugen over een paar weken in plaats van één dag, en zorg dat er een druk moment in zit.

AWS Compute Optimizer doet dat voor je, als je hem eerst aanzet (opt-in). Hij analyseert standaard de CloudWatch-metrics van de afgelopen 14 dagen, stelt een ander formaat voor en wijst resources aan die stilstaan. Zo'n voorstel is een startpunt. De beslissing neem je zelf, want jij weet welke pieken eraan komen.

Een database verdient extra aandacht, want verkleinen vraagt een onderhoudsmoment. Kijk ook of hij groot is omdat hij werk doet dat met een index of een cache goedkoper kan (zie [schaalbaarheid: wat je echt nodig hebt](/nl/blog/schaalbaarheid-wat-je-echt-nodig-hebt)). Of een workload beter serverless of op eigen servers draait, hangt af van de vorm van je verkeer. Daarover gaat [serverless of eigen servers](/nl/blog/serverless-of-eigen-servers).

Pas als de omvang klopt, kijk je naar reserveringen of commitments voor langere tijd. Wie eerst reserveert en daarna verkleint, betaalt voor capaciteit die hij niet gebruikt.

## Opslag en logs groeien stil door

Opslag is goedkoop per gigabyte, maar groeit elke dag, en meestal ruimt niemand het op.

Zet op elke bucket een lifecycle-regel. In S3 kun je objecten na een aantal dagen naar een goedkopere storage class laten verplaatsen, of ze laten verlopen zodat S3 ze voor je verwijdert. Aan transities hangen wel requestkosten, dus bij heel veel kleine bestanden kan verplaatsen meer kosten dan het oplevert.

Logs zijn de andere stille groeier. Geef elke loggroep een bewaartermijn en zet debuglogging in productie alleen tijdelijk aan. Een paar weken logs in doorzoekbare opslag en daarna een goedkoop archief is voor veel teams genoeg.

Backups en snapshots horen er ook bij. Kopieën die je bewaarbeleid niet voorschrijft, kosten alleen geld. Hoe je dat beleid opstelt, staat in [backups en disaster recovery](/nl/blog/backups-en-disaster-recovery). Houd ten slotte dataverkeer in de gaten, zoals verkeer naar internet en tussen regio's. Dat groeit mee met je gebruik en valt vaak pas op als het al een flinke post is.

## Budgetten en alerts

Stel per account of project een budget in met alerts, bijvoorbeeld bij 80 en 100 procent van wat je verwacht. Laat de alert binnenkomen in een kanaal dat iemand leest, en niet in de mailbox van een oud account.

Een budget met alleen alerts waarschuwt je, maar zet niets uit. Google Cloud schrijft in de documentatie dat zo'n budget het gebruik en de uitgaven niet automatisch begrenst. Iemand moet dus op de alert reageren.

## Een vaste review van een uur per maand

Zonder vaste review zakt dit weer weg. Plan elke maand een uur met de tech lead van het team en iemand die het budget kent, zoals de CTO of de oprichter. Loop dan steeds dezelfde lijst af:

1. Vergelijk de kosten per tag met vorige maand en zoek de grootste stijgers.
2. Bekijk de tien grootste kostenposten. Weet je van elk waarom die er staat?
3. Loop de resources zonder tags door.
4. Zoek losse volumes, oude snapshots en servers die al lang uit staan.
5. Lees de right-sizingvoorstellen, op AWS bijvoorbeeld die van Compute Optimizer.
6. Schrijf op wat je besluit, wie het doet en wanneer.

Het verslag hoeft niet meer te zijn dan een paar regels in je wiki. De volgende review begint met de vraag of de acties van vorige keer zijn gedaan.

## Bronnen

- [AWS: cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
- [AWS: EC2 instance state changes en billing](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html)
- [AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html)
- [Amazon S3: lifecycle van objecten beheren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)
- [Google Cloud: budgetten en budget-alerts](https://docs.cloud.google.com/billing/docs/how-to/budgets)

## Veelgestelde vragen

**Hoe krijg je inzicht in waar je cloudkosten vandaan komen?**

Tag elke resource met een eigenaar, een omgeving en een project, en bekijk de kosten elke maand per tag. Op AWS moet je cost allocation tags eerst activeren in de Billing-console voordat ze in Cost Explorer verschijnen.

**Betaal je in AWS voor een gestopte server?**

Niet voor de rekentijd van de instance. De opslag van de EBS-volumes en Elastic IP-adressen worden wel gefactureerd. Heb je een server lang niet nodig, maak dan een backup en verwijder hem.

**Begrenst een budget in Google Cloud je uitgaven?**

Een budget met alleen alerts doet dat niet. Google Cloud schrijft in de documentatie dat zo'n budget gebruik en uitgaven niet automatisch begrenst. Iemand moet dus op de alert reageren.

---

Bron: https://brainpowergroup.eu/nl/blog/cloudkosten-onder-controle
Brainpower Group, contact: https://brainpowergroup.eu/nl/contact, hello@brainpowergroup.eu