Cloudfacturen liegen niet, maar ze verbergen wel dingen. Elke maand vloeit er stilletjes geld weg van je AWS-, GCP- of Azure-account door beslissingen die op dat moment volkomen logisch leken. Een database die is gedimensioneerd voor het piekverkeer op Black Friday. Een NAT-gateway die niemand heeft verwijderd. Logbestanden die al drie jaar lang naar S3 worden doorgestuurd en die nog nooit iemand heeft geopend.
Dit gaat niet over grote fouten. Het gaat over de langzame, onzichtbare last die zich opstapelt totdat je CFO een vraag stelt die je niet kunt beantwoorden.
Laat me je precies laten zien waar het geld naartoe gaat, en hoe je het bloeden kunt stoppen.
Probleem #1: Je betaalt voor beschikbaarheid die je niet nodig hebt
Multi-AZ RDS. Cross-region replicatie. Active-active load balancers verspreid over drie datacenters. Dit klinkt verantwoord. Dat zijn ze ook, voor sommige workloads. Maar ik heb startups met 200 dagelijkse actieve gebruikers gezien die $ 4.000 per maand betalen voor infrastructuur die een nucleaire aanval zou overleven.
De vraag die niemand stelt is: wat kost downtime ons eigenlijk?
Als je antwoord "misschien een paar boze e-mails" is, heb je geen vijf-negenen nodig. Je moet de berekening maken:
Maandelijkse downtime-kosten = (inkomstenderving per uur) × (aanvaardbare downtime-uren)
Een SaaS-bedrijf dat $ 50.000 ARR in rekening brengt voor 500 gebruikers kan twee uur downtime verdragen voordat de kosten gelijk zijn aan één maand redundante infrastructuur. Stem uw betrouwbaarheid af op uw werkelijke risico, niet op wat AWS u gemakkelijk laat controleren.
Probleem #2: NAT-gateways zijn een stille budgetkiller
Dit zal je boos maken. De prijs voor NAT-gateways op AWS is $ 0,045 per GB verwerkte data. Dat klinkt niet als veel. Maar dan realiseer je je dat je applicatie al het interne verkeer — service-naar-service-oproepen, S3-opvragingen, DynamoDB-query's — via die gateway routeert.
De oplossing? Gebruik VPC-eindpunten voor AWS-services. S3, DynamoDB, SQS en tientallen andere ondersteunen Gateway- of Interface-eindpunten die verkeer privé routeren, zonder je NAT-gateway aan te raken. Een enkel S3 VPC-eindpunt op een dataintensieve workload kan honderden dollars per maand aan transitkosten besparen.
Voorheen: EC2 → NAT-gateway ($0,045/GB) → S3
Na: EC2 → VPC-eindpunt (gratis) → S3
Controleer uw VPC-stroomlogboeken. Als uw NAT-gateway meer dan een paar gigabyte per dag verwerkt, valt hier vrijwel zeker geld te besparen.
Probleem #3: Uw instances hebben de verkeerde vorm, niet de verkeerde grootte
Teams zijn geobsedeerd door het verkleinen van instances. Ze negeren de familie van instances volledig. Dit is achterhaald.
Een c6i.2xlarge (compute-optimized) kost ongeveer evenveel als een r6i.xlarge (memory-optimized), maar heeft twee keer zoveel vCPU's en de helft van het RAM-geheugen. Als u een CPU-gebonden API-server draait op een instance uit de r-familie omdat dit de standaard was, betaalt u een geheugenpremie voor resources die uw applicatie nooit gebruikt.
Voer een week lang CloudWatch-metrics uit op uw productie-instances. Als het geheugengebruik consequent onder de 40% blijft, zit u in de verkeerde familie. Als de CPU constant vol draait maar het geheugen inactief is, zit u zeker in de verkeerde familie.
| Workload | Juiste familie | Verkeerde familie |
|---|---|---|
| API-servers, batchtaken | c (rekenkracht) | r (geheugen) |
| In-memory caches, databases | r (geheugen) | c (rekenkracht) |
| ML-inferentie | inf of g | alles wat algemeen is |
De juiste instancetype kan u tegelijkertijd betere prestaties en een lagere rekening opleveren.
Probleem #4: Inactieve resources draaien 24/7 in de productieomgeving
Ontwikkelingsdatabases. Staging-omgevingen. Loadtestclusters die één keer in januari hebben gedraaid. QA-omgevingen die de productieomgeving spiegelen "voor het geval dat". Ze staan er allemaal, tegen de volle prijs, en doen absoluut niets om 3 uur 's nachts op een zondag.
De oplossing is beschamend eenvoudig: geplande uitschakelingen.
# AWS EventBridge-regel om RDS elke avond om 20.00 uur te stoppen
aws events put-rule \
--schedule-expression "cron(0 20 * * ? *)" \
--name StopDevDatabase
# Opnieuw starten om 08.00 uur
aws events put-rule \
--schedule-expression "cron(0 8 * * ? *)" \
--name StartDevDatabase
Niet-productieomgevingen die 24/7 draaien, zijn omgevingen die 168 uur per week draaien. Beperk ze tot kantooruren — 50 uur per week — en je hebt de rekenkosten van die omgeving van de ene op de andere dag met 70% verlaagd, zonder ook maar één regel applicatiecode te wijzigen.
Probleem #5: Kosten voor gegevensoverdracht zijn de kleine lettertjes die niemand leest
De prijs voor rekenkracht staat prominent vermeld. De kosten voor gegevensoverdracht staan verborgen in een voetnoot, totdat je factuur arriveert.
De regels die de meeste teams overrompelen:
- Verkeer tussen AZ's kost geld. Voor twee EC2-instances in dezelfde regio maar in verschillende beschikbaarheidszones wordt per GB in rekening gebracht, in beide richtingen.
- Uitgaand verkeer naar het internet is duur. Inkomend verkeer is gratis. Als uw applicatie grote bestanden rechtstreeks vanaf EC2 serveert, betaalt u voor elke byte uitgaand verkeer.
- Replicatie tussen regio's is uitgaand verkeer. Repliceert u uw RDS-snapshot van
us-east-1naareu-west-1voor disaster recovery? Dat kost elke keer een vergoeding per GB.
De architecturale oplossing: verplaats de gegevenslevering naar CloudFront (of gelijkwaardige CDN's). Uitgaand verkeer vanuit CloudFront is goedkoper dan uitgaand verkeer rechtstreeks vanuit EC2 of S3, en CDN-cachehits zorgen ervoor dat u niet herhaaldelijk dezelfde bytes tegen de volle prijs hoeft te leveren.
Probleem #6: U gebruikt on-demand-prijzen voor voorspelbare workloads
On-demand-instances zijn bedoeld voor onvoorspelbare, piekerige workloads. Uw productie-API-server die 24 uur per dag consistent verkeer verwerkt, valt daar niet onder.
Reserved Instances en Savings Plans bieden kortingen van 30-60% ten opzichte van on-demand als u zich voor één of drie jaar vastlegt. Toch maken de meeste teams er geen gebruik van, of gebruiken ze deze verkeerd — ze kopen reserveringen voor instancetypes die ze zes maanden later weer wijzigen.
De pragmatische aanpak:
- Draai 2-3 maanden on-demand op nieuwe workloads
- Analyseer je basisgebruik in Cost Explorer
- Koop Compute Savings Plans (geen instancespecifieke reserveringen) — deze zijn automatisch van toepassing op elke EC2-instancefamilie en Fargate
- Dek alleen je basisgebruik af met verbintenissen; gebruik Spot voor piekcapaciteit daarboven
Een Compute Savings Plan op een stabiele workload is geen lock-in-risico. Het is gewoon rekenwerk.
Probleem #7: Logs worden opgeslagen alsof ze van goud zijn
Logs zijn goedkoop om te genereren en duur om voor altijd op te slaan. Toch sturen de meeste teams alles door naar CloudWatch Logs of S3 zonder bewaarbeleid, zonder tiering en zonder vervaldatum. Drie jaar later is de opslagrekening een aanzienlijke kostenpost en heeft niemand ook maar één keer een logbestand uit 2021 geopend.
Stel onmiddellijk bewaarbeleidsregels in:
# Stel de bewaartermijn voor CloudWatch-loggroepen in op 30 dagen
aws logs put-retention-policy \
--log-group-name /app/production \
--retention-in-days 30
Voor logbestanden die je echt moet bewaren — compliance, audittrails, beveiligingsincidenten — moet je ze agressief indelen in lagen:
0–30 dagen: S3 Standard (hot access)
30–90 dagen: S3 Infrequent Access (60% goedkoper)
90+ dagen: S3 Glacier Instant Retrieval (80% goedkoper)
Je hebt geen toegang in milliseconden nodig tot een logboek van veertien maanden geleden. Stop met ervoor te betalen.
De rekening die je eigenlijk zou moeten lezen
De meeste engineers kijken naar de totale cloudrekening en voelen zich vaag schuldig. De juiste gewoonte is anders: kijk naar de unit economics.
Kosten per API-verzoek
Kosten per actieve gebruiker per maand
Kosten per opgeslagen GB per jaar
Deze cijfers leggen inefficiëntie bloot die verborgen blijft achter de ruwe bedragen in dollars. Als uw kosten per API-verzoek stijgen terwijl het verkeer stabiel blijft, is er iets mis — en dat is bijna nooit het voor de hand liggende.
Uw cloudinfrastructuur is niet zomaar infrastructuur. Het is een langzame lek of een strak georganiseerde organisatie, volledig afhankelijk van de beslissingen die u neemt over zaken die te klein lijken om ertoe te doen.
Ze stapelen zich op. Dat doen ze altijd.