Dedicated vs. public cloud: de echte kostenfactoren begrijpen
Kort antwoord
Het compute-tarief op een public cloud-factuur vertelt zelden het hele verhaal. Data egress, de kosten voor het verplaatsen van data uit het netwerk van een cloudprovider, is meestal de kostenpost die het snelst en het minst voorspelbaar groeit. Workloads met een stabiele, voorspelbare basisbelasting en veel dataverkeer zijn de workloads waarbij het bezit van dedicated infrastructuur vaak zinvoller is; workloads die piekend zijn of sterk leunen op managed cloud-diensten meestal niet. Specifieke workloads terugverplaatsen naar infrastructuur die je zelf beheert, is een erkend patroon dat cloud repatriation heet, en dat is normaal gesproken selectief, geen volledig vertrek uit de cloud.
Waarom de prijs op papier niet de echte vergelijking is
Het maandtarief van een dedicated server vergelijken met het uurtarief van een cloud-instance klinkt simpel, maar dat mist waar cloud-kosten in de praktijk oplopen zodra een workload live staat. Twee factoren bepalen of cloud of dedicated infrastructuur beter uitpakt voor een bepaalde workload: hoe voorspelbaar het gebruik van die workload is, en hoeveel data hij verplaatst. Beide komen terug op hetzelfde onderliggende mechanisme: de prijsstelling van public cloud is gebouwd rond elasticiteit, en die elasticiteit blijft geld kosten zodra een workload hem niet meer nodig heeft.
Het mechanisme achter egress fees
Egress fees zijn kosten voor data die het netwerk van een cloudprovider verlaat, vaak aangeduid als "data transfer out", of dat nu naar het publieke internet gaat of naar een geheel andere locatie. Het mechanisme dat deze kosten significant maakt, is simpel: egress-kosten schalen recht evenredig met de hoeveelheid data die je verstuurt. Downloads, video, datasets, backups, output van AI-modellen, het telt allemaal mee, en de kosten lopen op, ook als je compute-gebruik gelijk blijft. Bij een dataintensief product kan egress uitgroeien tot de grootste losse post op de factuur, juist omdat die kosten meegroeien met het succes van je product, en niet vastzitten aan een vaste resource die je vooraf hebt ingericht.
Dedicated en private infrastructuur wordt over het algemeen niet op deze manier gefactureerd. Omdat je een public cloud-provider niet per gigabyte betaalt om je eigen data van hun netwerk af te halen, is een workload die veel data verplaatst een van de duidelijkste gevallen waarin het kostenprofiel van dedicated infrastructuur structureel anders is dan dat van cloud, los van elke specifieke prijsvergelijking.
Voorspelbare workloads versus variabele workloads
De andere helft van de vergelijking is hoe stabiel het resourcegebruik van de workload is over tijd:
| Voorspelbaar, steady-state | Variabel, bursty | |
|---|---|---|
| Gebruikspatroon | Draait continu op een redelijk constant, hoog gebruiksniveau | Piekt, staat stil, of schaalt onvoorspelbaar |
| Waar je voor betaalt op cloud | Elasticiteit die je eigenlijk niet gebruikt | Elasticiteit die daadwerkelijk werk verzet door de pieken op te vangen |
| Betere structurele fit | Dedicated of private infrastructuur, eenmalig gedimensioneerd voor de stabiele baseline | Public cloud, resources op- en afschalen naarmate de vraag verandert |
De kernwaarde van cloud is elasticiteit: je betaalt alleen voor extra capaciteit wanneer je die nodig hebt. Dat is een echt voordeel voor een workload die daadwerkelijk fluctueert. Het houdt op een voordeel te zijn zodra een workload uitkomt op een constante, voorspelbare baseline, want dan betaal je voortdurend een meerprijs voor flexibiliteit die de workload niet meer gebruikt.
Cloud repatriation: workloads terugverplaatsen naar infrastructuur die je zelf beheert
Cloud repatriation is de term voor het terugverplaatsen van specifieke workloads uit een public cloud, zoals AWS, Azure of Google Cloud, naar infrastructuur die je zelf beheert: dedicated servers, private cloud, of hardware on-premises. De belangrijkste drijfveren zijn meestal het verlagen van structurele kosten, voorspelbaardere prestaties, of het voldoen aan eisen rond datacontrole en jurisdictie. Repatriation is meestal selectief: een bedrijf verplaatst de workloads waarvoor de business case of compliance-case het duidelijkst is, en laat de rest gewoon in de cloud draaien. Een volledig vertrek uit de cloud komt zelden voor.
Is jouw workload een goede kandidaat voor repatriation?
Vier kenmerken maken een workload een sterke kandidaat om van public cloud af te halen:
- Voorspelbaar basisgebruik: de workload draait continu op een redelijk constant, hoog gebruiksniveau, in plaats van het grootste deel van de tijd stil te staan.
- Veel uitgaand dataverkeer: de workload verstuurt regelmatig grote hoeveelheden data naar buiten, precies het gebruikspatroon waarbij egress fees het snelst oplopen.
- Grote, blijvende datasets: de data zelf ligt inmiddels vast op zijn plek, ook wel "data gravity" genoemd, waardoor het verplaatsen ervan, of juist de kosten van het laten staan waar het staat, in de loop van de tijd zwaarder gaat wegen.
- Strenge controle-eisen: auditeerbaarheid, tenancy-isolatie, of een specifieke jurisdictie waarbinnen de data moet blijven.
Workloads die niet in dit profiel passen, kun je meestal beter laten staan waar ze staan. Piekende of experimentele workloads, en alles wat sterk leunt op managed cloud-diensten, zoals serverless functions of auto-scaling managed databases, horen doorgaans langer thuis in de cloud: die managed functionaliteit zelf nabouwen op dedicated infrastructuur is een project op zich, en is vaak niet de moeite waard, tenzij de workload al is uitgegroeid tot iets stabiels.
Een hybride aanpak: dedicated voor de baseline, cloud voor de burst
Repatriation hoeft niet te betekenen dat je voor alles één platform kiest. Een veelgebruikt patroon houdt cloud-diensten aan voor waar ze echt het beste in zijn, automatisering, managed control planes, snel opschalen, en leidt tegelijk steady-state en bandbreedte-intensief verkeer via dedicated infrastructuur. In de praktijk kan dat betekenen dat je verkeer met veel egress vanuit een dedicated omgeving bedient, grote bestanden offloadt naar dedicated object storage, of de baseline-workload op dedicated infrastructuur laat draaien en alleen naar cloud burst wanneer de vraag daadwerkelijk piekt. Het doel is om de flexibiliteit van cloud te behouden waar die zichzelf terugverdient, en tegelijk de kosten weg te halen die tegen je gaan werken naarmate je product groeit.