Undersøg stigende cloudomkostninger: mængde, pris og ressourcer

Når cloudregningen stiger, skal du først sikre, at omkostningerne opgøres på samme grundlag. Derefter kan du undersøge, om beløbet skyldes øget brug, en anden enhedspris eller en ekstra ressource. Den tekniske årsag kræver desuden viden om arbejdsforløbet.

Fasthold sammenligningsgrundlaget

Notér periode, valuta, mængdeenhed, berørte tjenester og den anvendte omkostningstype. Et foreløbigt beløb for den igangværende måned svarer ikke til en hel foregående måned. Undersøg også, hvordan rabatter, krediteringer og skatter behandles. En ændret kreditering kan ændre regningen, selv om brugen er uændret.

Omkostningsrapporter kan indeholde data, der tilføjes senere. AWS gør udtrykkeligt opmærksom på forsinkede dataopdateringer i Cost Explorer. Notér derfor, hvilken rapportversion du sammenligner; en prognose og allerede faktureret brug er forskellige grundlag.

Beregn tre eksempelposter hver for sig

Et fiktivt softwareteam sammenligner to faktureringsperioder på hver 30 dage. Tabellen omfatter kun tre udvalgte poster. Alle beløb er frit valgte nettoeksempler i EUR uden rabatter, krediteringer eller skatter; de er hverken leverandørpriser eller et tilbud fra ASES. Workers er her programmer, der udfører baggrundsopgaver. Beregningscellerne viser mængde × antaget enhedspris = beløb i EUR.

Forskellen er 440 - 250 = 190. Her skyldes den flere worker-timer, en ændret antaget sats for dataoverførsel og nye timer på testserveren. Det er en opdeling af eksempelværdierne, ikke en konstatering af spild eller en faktisk prisændring.

Forbind beløbet med driften

For workers undersøges det, om der blev udført flere nyttige opgaver, forekom flere gentagelser, eller en opgave tog længere tid. Mere fakturerbar køretid kan have forskellige tekniske årsager. Derfor sammenholdes opgavehistorikken med forbruget.

Ved dataoverførslen er mængden uændret i eksemplet. I virkelige data skal du også afklare, om brugstype, region, rabat og omkostningstype er sammenlignelige. En ændret effektiv sats er ikke automatisk en forhøjelse af listeprisen. Hvis både mængde og sats ændres, skal begge ændringer fremgå.

Testserveren hedder i eksemplet test-old og tilhører et afsluttet forsøg. Først denne ekstra viden gør den til en mulig kandidat til nedlukning. Den ansvarlige undersøger først afhængigheder, nødvendige data og behovet for at kunne vende tilbage. En post på regningen er ikke i sig selv nok til beslutningen. FinOps Allocation beskriver fordeling via konti, tags og andre metadata; en ukendt ejer forbliver et uafklaret punkt.

Dokumentér værktøjets grænser og næste arbejde

I AWS Cost Explorers dokumenterede omkostningssammenligning kan der blandt andet grupperes efter tjeneste, konto, region eller tag. Gruppering og filtrering efter en enkelt ressource er ikke tilgængelig i denne sammenligningsvisning. For at identificere testserveren har du derfor brug for supplerende ressource- eller forbrugsdata. Eksempeltabellen gengiver ikke leverandørens visning.

Notér for hver påfaldende post den konstaterede forskel, den tekniske sammenhæng, åbne spørgsmål og næste skridt med en ansvarlig. Allerede påløbne gebyrer forsvinder ikke, fordi en ressource senere lukkes ned. Hvilke fremtidige omkostninger der eventuelt bortfalder, og hvilke poster for lagring eller sikkerhedskopiering der bliver tilbage, undersøges særskilt.

Kilder

• AWS — Performing a cost comparison

• AWS — Analyzing costs and usage with Cost Explorer

• FinOps Foundation — Allocation