Derfor stiger cloud-regningen — og hvad I kan gøre

On-prem var dyr på en forudsigelig måde: I købte kapacitet, og den stod der. Cloud er billig på en uforudsigelig måde: I betaler for det, I glemmer at slukke. Den forskel er årsagen til, at mange CFO'er føler, at cloud "løb løbsk", selv når produktet ikke er vokset markant.

Tre mekanismer driver det. For det første er oprettelse friktionløs — en preview-database, et staging-cluster, en ekstra region tager minutter. For det andet er sletning sjældent nogens job. For det tredje er fakturaen forsinket i forhold til beslutningen: I ser stigningen uger efter, at nogen "bare midlertidigt" startede noget.

Derfor er det forkert at starte med at skifte leverandør. AWS, Vercel og Cloudflare prissætter forskelligt, men alle tre belønner disciplin og straffer glemsomhed. Hvis I ikke ved, hvilke ressourcer der hører til hvilket produkt, vil en ny faktura bare se anderledes forvirrende ud.

Målet er ikke den laveste mulige regning. Målet er en regning, I kan forklare: denne linje er produkt X, den linje er staging vi har besluttet at beholde, og den linje er noget vi lukker i denne sprint.

Egress er den stille dræber. Data der forlader en region, et CDN eller en database koster — og det er let at designe sig ind i chatty APIs, store assets uden caching, eller backups der kopieres på tværs af cloud-grænser uden at nogen lagde mærke til det. Når trafikken vokser, vokser egress lineært, mens I måske troede, at I havde "fast" hosting.

Idle compute er den næste. Udviklermiljøer der kører i weekenden, GPU-instanser der venter på jobs, Kubernetes-nodes der er overprovisioneret "for sikkerheds skyld". Cloud gør det fristende at lade ting køre; økonomien straffer det. Autostop, schedules og aggressive TTL'er på midlertidige miljøer er kedeligt arbejde — og det er ofte det, der giver den største effekt først.

Storage uden lifecycle er den tredje. Snapshots, logs, gamle S3-buckets, orphaned volumes. Det føles gratis, indtil det ikke er. En lifecycle-policy er ikke optimering — det er hygiejne.

Den fjerde er managed services uden forbrugstænkning: managed databaser i for stor størrelse, always-on queues, flere Redis-instanser end I har brug for. Managed er rigtigt, når det sparer driftstid. Det er forkert, når det er en genvej til at undgå at designe load.

Den femte — og vigtigste — er manglende tags og ejerskab. Uden cost allocation tags, projektnavne eller team-labels kan I ikke handle. I kan kun undre jer. Enhver kostkontrol der starter uden inventory, ender i gætterier.

På AWS er klassikerne underudnyttede EC2/ECS-tasks, NAT-gateways, datatransfer mellem AZ'er, og RDS-instanser der aldrig blev scaled ned efter lancering. Billing-konsollen kan vise jer det — men kun hvis tags er konsistente. Uden tags er Cost Explorer et museum for uforklarlige linjer.

På Vercel ser stigningen ofte anderledes ud: build-minutter, serverless-invocation spikes, bandwidth, og image optimization. Det er ikke "AWS i forkledning". Det er en platform, hvor frontend-trafik og preview-deploys er synlige. Hvis marketing kører tunge kampagner, eller hvis I regenererer for mange sider uden cache-disciplin, stiger regningen — også når backend er billig.

På Cloudflare kan Workers, R2-egress-politikker og image/video-pipelines overraske, hvis I antager at edge er gratis. Edge er ofte billigere end origin for de rigtige workloads — men "flyt alt til edge" uden at måle request-mønstre er stadig et gætteri.

Pointen er ikke at rangere platformene. Pointen er at hver platform har et lille sæt knapper, der forklarer 80% af stigningen. Find de knapper, før I redesigner arkitekturen.

Nogle gange er regningen høj, fordi arkitekturen er forkert for workloaden. Chatty microservices på tværs af AZ'er, synkron fil-processing i request-pathen, eller en database der bruges som kø. Så hjælper inventory ikke alene — I skal ændre designet.

Tegn er: de dyreste linjer er tydeligt knyttet til kerneproduktet, de vokser med trafik, og I kan forklare dem. Så er det ikke glemsomhed. Så er det et trade-off I har valgt (eller arvet), og det skal genforhandles.

Her er hybrid ofte det ærlige svar: hold frontend og cache tæt på brugerne, flyt tunge jobs til køer, og undgå at betale egress for data, I kunne have holdt tættere på hinanden. Det er ikke en religion om AWS vs. edge — det er placering af arbejde der, hvor det er billigst at udføre.

Hvis I overvejer at skifte hele platformen for at spare, så spørg først: vil den nye platform gøre ejerskab tydeligere, eller bare skjule de samme vaner bag en anden prisliste? Vaner flytter med jer.