Microsoft Azure ger företag möjlighet att snabbt skala upp och ned sin IT-kapacitet. Flexibiliteten är en av molntjänstens största fördelar, men innebär också att kostnaderna kan vara svåra att förutse och kontrollera.

Till skillnad från traditionella IT-tjänster med ett fast månadspris består Azurekostnaden ofta av ett stort antal mindre kostnadsposter. Kunden kan betala för beräkningskapacitet, lagring, transaktioner, datatrafik, databaser, säkerhetsfunktioner, loggning, licenser, support och externa tjänster från Azure Marketplace.

För en inköpare räcker det därför inte att förhandla fram en rabatt på Microsofts prislista. Den långsiktiga kostnaden påverkas minst lika mycket av hur miljön designas, dimensioneras, används och följs upp.

Den viktigaste principen är:

Förhandla inte bara om priset. Styr även vilken förbrukning som får uppstå.

Azure har inte en enda prismodell

Microsoft Azure är inte en enskild tjänst utan en plattform med ett stort antal olika produkter. Varje produkt kan ha sin egen prismätare och sin egen prisstruktur.

Kunden kan exempelvis betala:

  • per timme eller sekund för beräkningskapacitet,
  • per gigabyte för lagring,
  • per transaktion för läsning och skrivning,
  • per databaskärna eller kapacitetsenhet,
  • per API-anrop,
  • per token för vissa AI-tjänster,
  • per gigabyte utgående datatrafik,
  • per loggad eller analyserad datamängd,
  • per användare för vissa säkerhets- och supporttjänster.

Den totala kostnaden kan förenklat beskrivas på följande sätt:

Azurekostnad = användning × enhetspris + licenser + lagring + datatrafik + support och tilläggstjänster − rabatter och licensförmåner

Microsofts prissättning påverkas bland annat av vald tjänst, region, kapacitet, operativsystem, tillgänglighetsnivå och kundens kommersiella avtal. Microsofts priskalkylator kan användas för att uppskatta kostnader och kan, när en behörig användare loggar in, även visa organisationens förhandlade priser i stället för enbart offentliga listpriser.

Pay-as-you-go ger flexibilitet

Pay-as-you-go innebär att kunden betalar för den användning som faktiskt registreras utan att först göra ett flerårigt ekonomiskt åtagande.

Modellen passar ofta för:

  • nya system där användningen ännu är osäker,
  • pilotprojekt,
  • test- och utvecklingsmiljöer,
  • tillfälliga projekt,
  • säsongsvariationer,
  • tjänster där belastningen förändras snabbt.

Fördelen är att organisationen kan öka, minska eller avsluta användningen utan att först behöva köpa en långsiktig reservation.

Nackdelen är att Pay-as-you-go normalt har ett högre enhetspris än de alternativ där kunden binder sig under en längre period.

För en inköpare är Pay-as-you-go ofta en lämplig startmodell. Den gör det möjligt att samla in verklig användningsdata innan organisationen bestämmer hur stor del av förbrukningen som bör bindas genom reservationer eller Savings Plans.

Det är ofta bättre att betala ett något högre pris under en begränsad inledande period än att omedelbart göra ett treårigt åtagande baserat på en osäker prognos.

Azure Reservations passar stabil användning

Azure Reservations innebär att kunden gör ett åtagande för en viss typ av resurs under ett eller tre år.

En reservation kan exempelvis avse en viss typ av virtuell server eller instansfamilj i en bestämd Azure-region. Rabatten appliceras på användning som motsvarar reservationens villkor.

Microsoft beskriver reservationer som särskilt lämpade för arbetslaster som körs kontinuerligt och där instanstyp, kapacitet och region förväntas vara stabila. När en reservation utnyttjas fullt kan den ge en större besparing än en mer flexibel Savings Plan.

Microsoft anger för närvarande att vissa reservationer kan ge besparingar på upp till 72 procent jämfört med Pay-as-you-go. Detta är dock ett maximalt exempel. Den verkliga besparingen beror på bland annat resurstyp, region, användning och hur stor del av reservationen som faktiskt utnyttjas.

Hög rabatt innebär inte automatiskt låg kostnad

En reservation kan ha ett attraktivt rabatterat enhetspris men ändå bli olönsam om resursen inte används.

Om organisationen reserverar en server som bara utnyttjas till 50 eller 60 procent betalar kunden för en kapacitet som verksamheten inte behöver. Den nominella rabatten kan då döljas av ett stort underutnyttjande.

Inköparen bör därför alltid kontrollera:

  • hur stabil användningen är,
  • om resursen verkligen behöver köras dygnet runt,
  • om kapaciteten redan är korrekt dimensionerad,
  • om systemet kan komma att flyttas till en annan region,
  • om arkitekturen kan förändras under avtalsperioden,
  • om applikationen kan ersättas eller avvecklas,
  • om reservationen kan användas av andra arbetslaster.

Microsoft rekommenderar att oanvända och överdimensionerade resurser tas bort eller rättdimensioneras innan nya reservationer köps. Rabatten minskar priset på resursen, men tar inte bort kostnaden för en resurs som egentligen inte behövs.

Azure Savings Plan ger större flexibilitet

En Azure Savings Plan innebär att kunden åtar sig att köpa berättigad beräkningskapacitet för ett visst belopp per timme under ett eller tre år.

Till skillnad från en reservation är åtagandet inte lika hårt knutet till en specifik serverstorlek och region. Rabatten kan appliceras på berättigad användning inom flera beräkningstjänster och regioner upp till det avtalade timbeloppet.

Microsoft rekommenderar Savings Plans när arbetslasterna är mer dynamiska, exempelvis när organisationen:

  • använder flera instansfamiljer,
  • förändrar serverstorlekar,
  • använder olika beräkningstjänster,
  • flyttar användning mellan regioner,
  • har en teknisk miljö som fortfarande utvecklas.

Microsoft anger för närvarande att en Savings Plan för beräkning i vissa fall kan ge en besparing på upp till 65 procent jämfört med Pay-as-you-go. Den faktiska besparingen varierar beroende på konfiguration, region och användningsmönster.

En Savings Plan är ett ekonomiskt åtagande

Savings Plans är mer flexibla än reservationer, men de är inte riskfria.

Kunden åtar sig att köpa en viss lägsta konsumtion varje timme. Om den berättigade användningen är lägre än åtagandet kan den outnyttjade delen normalt inte sparas till en senare timme.

Inköparen bör därför inte se en Savings Plan som en allmän rabatt på hela Azureförbrukningen. Den bör i stället betraktas som ett minimiåtagande.

Ett lämpligt arbetssätt är att identifiera organisationens stabila basförbrukning och endast binda den del som med hög sannolikhet kommer att finnas kvar under hela avtalsperioden.

Tillfälliga behov, säsongsvariationer och osäkra projekt kan fortsatt hanteras genom Pay-as-you-go.

När ska köparen välja reservation respektive Savings Plan?

En reservation är vanligtvis mest relevant när:

  • arbetslasten körs kontinuerligt,
  • resurstypen är stabil,
  • regionen inte förväntas ändras,
  • kapacitetsbehovet är väl känt,
  • användningen kan prognostiseras med hög säkerhet.

En Savings Plan är vanligtvis mer relevant när:

  • beräkningsbehovet är stabilt men fördelningen mellan resurser varierar,
  • organisationen använder flera instansfamiljer,
  • arbetslaster flyttas mellan regioner,
  • tekniken eller arkitekturen fortfarande förändras,
  • kunden behöver större flexibilitet än vad en reservation ger.

Pay-as-you-go är normalt mer lämpligt när:

  • projektet är nytt,
  • konsumtionen är osäker,
  • resursen är tillfällig,
  • miljön kan komma att avvecklas,
  • organisationen ännu saknar tillförlitlig användningsdata.

Det är inte nödvändigt att välja endast en modell. En organisation kan kombinera reservationer för mycket stabil användning, Savings Plans för en mer flexibel basförbrukning och Pay-as-you-go för variationer och tillfälliga toppar.

Azure Hybrid Benefit kan minska licenskostnaden

Azure Hybrid Benefit gör det möjligt för berättigade kunder att använda vissa befintliga licenser för exempelvis Windows Server och SQL Server i Azure.

För Windows Server krävs normalt kvalificerande kärnlicenser med aktiv Software Assurance eller motsvarande prenumerationsrättigheter. Kunden måste också säkerställa att licenserna är tillräckliga för den användning som aktiveras i Azure. Microsoft anger att organisationen regelbundet bör inventera användningen och kunna visa att den har rätt antal kvalificerande licenser.

Ur inköpsperspektiv bör följande kontrolleras:

  • vilka licenser organisationen redan äger,
  • vilka licenser som har aktiv Software Assurance,
  • vilka licenser som används i den lokala miljön,
  • om licenserna får användas parallellt under en migreringsperiod,
  • hur många kärnor eller virtuella servrar licenserna täcker,
  • vem som ansvarar för licensdokumentationen,
  • hur användningen ska styrkas vid en revision.

Azure Hybrid Benefit bör inte tas med som en säker besparing i affärskalkylen innan licensrättigheterna har verifierats.

En felaktigt aktiverad Hybrid Benefit kan skapa både en framtida licenskostnad och en avtalsrisk.

Azure Spot Virtual Machines kan ge lägre pris men med högre risk

Azure Spot Virtual Machines ger kunden tillgång till ledig Azurekapacitet till ett rörligt och ofta lägre pris.

Microsoft kan dock avbryta resursen när kapaciteten behövs för andra kunder eller när vissa prisvillkor inte längre uppfylls. Priset varierar beroende på region och servertyp, och kunden kan granska historisk pris- och avbrottsdata för olika resurser.

Spot passar främst för arbetslaster som klarar avbrott, exempelvis:

  • batchbearbetning,
  • rendering,
  • testkörningar,
  • simuleringar,
  • tillfälliga analyser,
  • distribuerade processer som automatiskt kan startas om.

Spot bör normalt inte användas för verksamhetskritiska system som kräver kontinuerlig tillgänglighet.

För en köpare är det viktigt att kontrollera om leverantören verkligen har utformat applikationen för att hantera avbrott. Ett lågt pris på beräkningskapaciteten är inte en besparing om avbrotten leder till omfattande manuellt arbete eller förlorade transaktioner.

Lagring kostar mer än antalet gigabyte

Priset för lagring i Azure påverkas inte bara av mängden information som lagras.

Kostnaden kan även påverkas av:

  • vald lagringsnivå,
  • antalet läs- och skrivtransaktioner,
  • hur ofta informationen hämtas,
  • redundans och geografisk replikering,
  • säkerhetskopior och snapshots,
  • dataöverföring,
  • hur länge informationen behålls.

Azure Blob Storage erbjuder bland annat nivåerna Hot, Cool, Cold och Archive. Lägre lagringsnivåer har normalt ett lägre pris för själva lagringskapaciteten, men högre kostnader för åtkomst, transaktioner och återställning. Vissa nivåer har även minsta rekommenderade lagringsperioder eller avgifter om informationen tas bort eller flyttas för tidigt.

Den billigaste lagringsnivån per gigabyte är därför inte alltid den billigaste lösningen totalt sett.

Om data ofta behöver hämtas från en arkivnivå kan åtkomst- och återställningskostnaderna bli större än besparingen på lagringspriset.

Inköparen bör begära en kalkyl som beskriver:

  • hur mycket data som ska lagras,
  • hur snabbt datamängden förväntas öka,
  • hur ofta informationen ska användas,
  • hur länge informationen ska bevaras,
  • hur snabbt arkiverad information måste kunna återställas,
  • hur många kopior och säkerhetskopior som krävs.

Datatrafik kan bli en betydande kostnad

Dataöverföring in till Azure är i många vanliga scenarier kostnadsfri. Utgående trafik från Azure, trafik mellan olika regioner och vissa andra nätverksflöden kan däremot debiteras separat. Priset varierar bland annat beroende på region, destination, volym och nätverkslösning.

Datatrafikkostnaden blir särskilt viktig när:

  • stora datamängder skickas till användare eller kunder,
  • data replikeras mellan regioner,
  • Azure integreras med andra molnplattformar,
  • säkerhetskopior överförs till en annan geografisk plats,
  • applikationen har många externa integrationer,
  • loggar eller analysdata flyttas mellan olika miljöer.

En köpare bör därför inte bara fråga var informationen lagras. Det är minst lika viktigt att förstå hur informationen förflyttas.

Leverantören bör kunna beskriva:

  • vilka datamängder som skickas,
  • mellan vilka regioner data överförs,
  • hur ofta överföringen sker,
  • vilka delar som debiteras,
  • hur volymen förväntas utvecklas,
  • vilka kostnader som uppstår vid dataexport och avveckling.

Loggning, säkerhet och övervakning måste ingå i kalkylen

I många projekt prissätts först servrar, databaser och lagring. Kostnaderna för logghantering, övervakning, säkerhetskopiering och säkerhetsfunktioner läggs till senare.

Det kan leda till stora avvikelser mellan beslutad budget och faktisk faktura.

Särskilt inom reglerade verksamheter kan kraven på spårbarhet, loggning, incidenthantering och långtidslagring vara omfattande. Dessa krav bör därför prissättas redan under upphandlingen.

Inköparen bör efterfråga:

  • uppskattad loggvolym per månad,
  • förväntad årlig tillväxt,
  • hur länge olika typer av loggar ska sparas,
  • vilka loggar som ska vara direkt sökbara,
  • vilka loggar som kan arkiveras,
  • kostnaden för analys och sökningar,
  • kostnaden för backup och återställning,
  • kostnaden för säkerhetsövervakning.

Det bör också framgå vem som får besluta om att öka detaljnivån eller lagringstiden. En mindre teknisk förändring kan i vissa miljöer snabbt öka mängden insamlad data och därmed kostnaden.

Azure Marketplace kan skapa kostnader utanför den ursprungliga kalkylen

Azure Marketplace gör det möjligt att köpa programvara och tjänster från externa leverantörer.

Dessa tjänster kan ha egna prismodeller, exempelvis:

  • användningsbaserad debitering,
  • fasta månadsavgifter,
  • licens per användare,
  • kapacitetsbaserade avgifter,
  • kombinationer av fasta och rörliga priser.

Beroende på avtalstyp kan tredjepartstjänster faktureras tillsammans med övriga Azuretjänster eller på en separat faktura. Microsoft anger också att kostnadsfria Azurekrediter normalt inte kan användas för tredjepartstjänster.

Organisationen bör därför ha en tydlig godkännandeprocess för Marketplace-köp.

Det bör regleras:

  • vilka roller som får köpa nya tjänster,
  • vem som ska godkänna återkommande abonnemang,
  • hur kostnaden ska fördelas,
  • hur tjänster ska avslutas,
  • vem som följer upp om produkterna fortfarande används.

Utan kontroll kan en tjänst fortsätta att generera kostnader långt efter att projektet som beställde den har avslutats.

Offentliga listpriser är inte alltid kundens verkliga pris

Azure Pricing Calculator och Microsofts offentliga prislistor kan användas för en första uppskattning. De bör däremot inte automatiskt betraktas som kundens slutliga pris.

Kundens faktiska pris kan påverkas av:

  • avtalstyp,
  • kundspecifika rabatter,
  • volymnivåer,
  • inkluderade kvantiteter,
  • valuta,
  • reservationer,
  • Savings Plans,
  • avtalet med en CSP-partner.

Microsofts prisdokument för ett Microsoft Customer Agreement kan bland annat innehålla marknadspris, enhetspris, måttenhet, prisperiod, inkluderade kvantiteter och olika pristyper. Microsoft anger att enhetspriset kan inkludera rabatter utöver marknadspriset.

En inköpare bör därför inte godkänna en affärskalkyl som enbart bygger på publika listpriser.

Kalkylen bör baseras på:

  • kundens aktuella prisdokument,
  • organisationens verkliga avtalspriser,
  • ett bindande kommersiellt erbjudande,
  • dokumenterade antaganden om användning.

Varför Azurekostnader ofta blir högre än planerat

Det är sällan en enskild prisökning som får kostnaden att öka kraftigt. Vanligare är att flera mindre problem byggs upp över tid.

Resurserna är överdimensionerade

Tekniska team kan välja större serverkapacitet än vad applikationen faktiskt behöver. Säkerhetsmarginaler kan vara motiverade, men blir dyra om de aldrig omprövas.

Om den överdimensionerade resursen dessutom binds i en treårig reservation riskerar organisationen att låsa in en onödigt hög kostnadsnivå.

Testmiljöer körs dygnet runt

Utvecklings-, test- och utbildningsmiljöer används ofta endast under kontorstid men fortsätter ändå att generera kostnader under kvällar, nätter och helger.

Automatisk avstängning kan därför ge en betydande besparing utan att påverka verksamheten.

Resurser tas inte bort när projekt avslutas

Diskar, snapshots, IP-adresser, lagringskonton, testdatabaser och nätverkskomponenter kan fortsätta att debiteras även efter att den ursprungliga applikationen har stängts av.

Organisationen behöver därför en formell avvecklingsprocess som omfattar hela resursgruppen och inte bara huvudservern.

Rabatter köps för tidigt

En reservation eller Savings Plan kan se ekonomiskt attraktiv ut, men bli dyr om användningsprognosen är felaktig.

Rabatter bör köpas först när organisationen har:

  • rensat bort oanvända resurser,
  • rättdimensionerat kvarvarande kapacitet,
  • analyserat verklig användning,
  • identifierat den stabila basförbrukningen.

Kostnaden saknar tydlig ägare

När kostnader inte kan kopplas till ett system, projekt, kostnadsställe eller affärsområde blir det svårt att avgöra om förbrukningen är affärsmässigt motiverad.

Ingen känner ansvar för att stänga av resursen, och fakturan behandlas som en gemensam IT-kostnad.

Datatrafik och loggning underskattas

När användningen ökar kan flera kostnadsposter växa samtidigt. Fler användare kan exempelvis innebära mer beräkningskapacitet, mer nätverkstrafik, fler loggar och större backupvolymer.

Kalkylen måste därför visa hur de olika kostnadsdelarna påverkas av en volymökning.

Så bör köparen arbeta före upphandlingen

Skapa en gemensam konsumtionsmodell

Alla leverantörer bör räkna på samma användningsscenario.

Underlaget bör minst beskriva:

  • antal användare,
  • antal transaktioner,
  • beräkningskapacitet,
  • drifttider,
  • lagringsvolym,
  • årlig datatillväxt,
  • krav på backup och redundans,
  • loggvolymer,
  • utgående datatrafik,
  • trafik mellan regioner,
  • test- och utvecklingsmiljöer,
  • tillgänglighetskrav.

Utan en gemensam konsumtionsmodell går det inte att jämföra leverantörernas priser på ett rättvisande sätt.

Begär flera kostnadsscenarier

Kalkylen bör innehålla minst tre scenarier:

  • låg användning,
  • förväntad användning,
  • hög användning.

Det höga scenariot visar hur känslig lösningen är för ökade volymer.

Leverantören bör även beskriva vilka prismätare som har störst påverkan på kostnaden. Det gör det möjligt att rikta förhandlingen mot de kostnadskomponenter som verkligen är viktiga.

Separera Microsoftkostnaden från partnerns avgifter

Om Azure köps genom en CSP-partner eller ingår i en managed service bör priset delas upp.

Kunden bör kunna skilja mellan:

  • Microsofts Azurekostnad,
  • partnerns påslag,
  • supportavgift,
  • förvaltningsavgift,
  • säkerhet och övervakning,
  • konsulttjänster,
  • Marketplace-tjänster,
  • reservationer och andra åtaganden.

En enda totalsumma gör det svårt att förstå om en kostnadsökning beror på högre Azureanvändning, ändrade Microsoftpriser eller partnerns egna avgifter.

Kräv en tydlig prisbilaga

Prisbilagan bör ange:

  • tjänst och resurstyp,
  • region,
  • måttenhet,
  • listpris,
  • avtalat nettopris,
  • rabatt eller påslag,
  • valuta,
  • giltighetsperiod,
  • prisändringsmekanism,
  • minimiåtaganden,
  • villkor för reservationer och Savings Plans.

Prismodellen ska kunna följas upp mot faktisk användningsdata och faktura.

Optimera innan ni binder förbrukningen

Organisationen bör först samla in och analysera användningsdata.

Därefter bör den:

  • ta bort oanvända resurser,
  • minska överdimensionerad kapacitet,
  • stänga av miljöer som inte behöver köras kontinuerligt,
  • korrigera felaktig lagringsnivå,
  • identifiera stabil basförbrukning,
  • köpa åtaganden först efter optimeringen.

Det är ofta bättre att reservera en mindre, stabil basnivå än att binda hela den prognostiserade konsumtionen.

Bind inte hela prognosen

En prognos innehåller alltid osäkerhet.

Organisationen bör därför överväga att:

  • reservera mycket stabila arbetslaster,
  • använda Savings Plans för en mer flexibel basförbrukning,
  • behålla Pay-as-you-go för variationer och tillväxt,
  • successivt öka åtagandena när användningen är bekräftad.

Det minskar risken för att kunden betalar för kapacitet som aldrig används.

Så bör Azureavtalet utformas

Kunden ska ha full kostnadsinsyn

Kunden bör ha tillgång till kostnads- och användningsdata på resursnivå och inte endast få en sammanfattad månadsfaktura.

Azure Cost Management kan användas för att automatiskt exportera kostnads- och användningsdata till Azure Storage, bland annat dagligen eller månadsvis. Exporterna kan även användas för vidare analys i organisationens egna system.

Avtalet bör ge kunden rätt till:

  • fullständiga kostnadsfiler,
  • användningsdata,
  • aktuella prisdokument,
  • reservationstransaktioner,
  • Marketplace-kostnader,
  • partnerns beräkningsunderlag,
  • historisk kostnadsdata vid leverantörsbyte.

Ägandet av reservationer ska vara tydligt

Det ska framgå:

  • vem som får besluta om ett nytt åtagande,
  • vem som äger reservationen,
  • vem som bär risken vid underutnyttjande,
  • hur rabatten fördelas,
  • vad som händer om arkitekturen förändras,
  • vad som händer vid byte av CSP-partner,
  • hur kvarvarande åtaganden hanteras vid avtalets slut.

En leverantör bör normalt inte få köpa fleråriga åtaganden för kundens räkning utan ett uttryckligt godkännande.

Prisändringar ska kunna verifieras

Leverantören bör inte kunna ändra egna påslag eller supportavgifter genom att generellt hänvisa till att Microsoft har förändrat sina priser.

Avtalet bör skilja mellan:

  • ändrade Microsoftpriser,
  • valutaförändringar,
  • förändrad användning,
  • nya eller ändrade tjänster,
  • leverantörens egna avgifter.

Kunden bör ha rätt att kontrollera underlaget bakom varje prisförändring.

Kostnadsoptimering bör vara en avtalad leverans

Om leverantören ansvarar för drift eller förvaltning bör kostnadsoptimering ingå som en uttrycklig del av tjänsten.

Leverantören bör regelbundet rapportera:

  • oanvända resurser,
  • överdimensionerade resurser,
  • möjliga avstängningsscheman,
  • reservationernas utnyttjandegrad,
  • underutnyttjade Savings Plans,
  • möjliga Hybrid Benefit-besparingar,
  • avvikande kostnadsökningar,
  • resurser utan korrekt kostnadsägare,
  • prognos mot budget.

Det bör också framgå vilka åtgärder leverantören får genomföra själv och vilka som kräver kundens godkännande.

Exitkostnader ska ingå i totalkostnaden

Avtalet bör reglera:

  • export av data,
  • kostnader för dataöverföring,
  • dokumentation,
  • överföring av konfigurationer,
  • överlämning av kostnadshistorik,
  • flytt av prenumerationer,
  • avveckling av resurser,
  • hantering av reservationer och Savings Plans,
  • stöd vid migrering till en annan plattform.

Kunden bör ha kontroll över sin Azure-miljö, sina prenumerationer och sin användningsdata. En struktur där leverantören ensam kontrollerar miljön kan försvåra framtida konkurrensutsättning.

Budgetar stoppar inte automatiskt förbrukningen

Azure Cost Management kan användas för att skapa budgetar och aviseringar baserade på faktisk eller prognostiserad kostnad.

En viktig begränsning är att en budget i sig inte stoppar resurser eller förbrukning när gränsvärdet överskrids. Microsoft anger också att kostnadsdata normalt har en viss fördröjning. Budgetar ska därför ses som ett styr- och varningsverktyg, inte som ett automatiskt kostnadstak.

Budgetar bör kompletteras med:

  • automatiska åtgärder,
  • godkännanderegler,
  • begränsning av tillåtna resursstorlekar,
  • regler för vilka regioner som får användas,
  • automatisk avstängning,
  • behörighetsstyrning,
  • larm till både teknisk och ekonomisk ägare.

Taggning skapar ekonomiskt ansvar

Varje Azure-resurs bör kunna kopplas till en ägare och ett affärsbehov.

Obligatoriska taggar kan exempelvis ange:

  • system,
  • projekt,
  • affärsområde,
  • kostnadsställe,
  • teknisk ägare,
  • verksamhetsägare,
  • miljö,
  • planerat avvecklingsdatum.

Microsoft Cost Management kan använda taggar för att gruppera och fördela kostnader mellan olika organisatoriska enheter. Microsoft erbjuder även tag inheritance, där taggar från bland annat prenumerationer och resursgrupper kan appliceras på underliggande användningsposter.

Resurser som saknar obligatoriska taggar bör blockeras eller fångas upp genom återkommande kontroller.

Förhandla inte bara om rabatten

En stor procentuell rabatt kan ge en falsk känsla av kostnadskontroll.

En köpare bör förhandla om hela den ekonomiska modellen:

  • nettopriser,
  • partnerpåslag,
  • supportavgifter,
  • licenser,
  • kostnadsoptimering,
  • valutahantering,
  • prisändringsmekanismer,
  • rapportering,
  • fakturatransparens,
  • ekonomiska åtaganden,
  • exitkostnader.

Det är ofta mer värdefullt att minska en överdimensionerad resurs med 30 procent än att förhandla fram ytterligare några procents rabatt på samma resurs.

Den centrala frågan är därför inte bara:

Vilken rabatt får vi?

Den viktigare frågan är:

Vilken förbrukning behöver vi faktiskt köpa, hur kan den förändras och vem ansvarar för att den löpande optimeras?

En praktisk modell för löpande kostnadsstyrning

Varje månad

Organisationen bör följa upp:

  • faktisk kostnad mot budget,
  • prognos för kommande månader,
  • nya resurser,
  • onormala kostnadsökningar,
  • oanvända resurser,
  • resurser utan ägare,
  • testmiljöer som körs i onödan.

Varje kvartal

Organisationen bör kontrollera:

  • utnyttjandet av reservationer,
  • utnyttjandet av Savings Plans,
  • behovet av nya åtaganden,
  • förändringar i arkitekturen,
  • möjligheter till rättdimensionering,
  • användning av Hybrid Benefit,
  • kostnader för Marketplace-tjänster.

Minst en gång per år

Organisationen bör granska:

  • Microsoftavtalet,
  • partnerns påslag,
  • supportmodellen,
  • licensrättigheter,
  • prisändringsvillkor,
  • möjligheten att konkurrensutsätta tjänsten,
  • exitkostnader och leverantörsberoenden.

Frågor som en köpare bör ställa

Före avtal bör köparen kunna få tydliga svar på följande frågor:

  • Vilka antaganden ligger bakom kostnadskalkylen?
  • Vilka kostnader är fasta och vilka är rörliga?
  • Vilka prismätare har störst påverkan på totalkostnaden?
  • Hur påverkas kostnaden om användningen ökar med 20, 50 eller 100 procent?
  • Vilka resurser ska reserveras och varför?
  • Vilken utnyttjandegrad krävs för att reservationen ska vara lönsam?
  • Vem bär kostnaden om ett åtagande inte används?
  • Hur hanteras Savings Plans vid förändrad arkitektur?
  • Vilka licenser kan användas genom Azure Hybrid Benefit?
  • Hur mycket datatrafik förväntas lämna Azure?
  • Vad kostar loggning, backup och säkerhetsövervakning?
  • Vilka Marketplace-produkter ingår?
  • Hur redovisas Microsofts kostnad respektive partnerns avgifter?
  • Hur ofta ska leverantören genomföra kostnadsoptimering?
  • Hur får kunden tillgång till kostnads- och användningsdata?
  • Vad kostar det att exportera data och lämna lösningen?

Sammanfattning

Microsoft Azures prismodell ger stor flexibilitet, men kräver aktiv ekonomisk styrning.

Kostnaden bestäms inte bara av Microsofts enhetspriser. Den påverkas även av:

  • teknisk arkitektur,
  • kapacitetsval,
  • användningsmönster,
  • lagring,
  • datatrafik,
  • loggning,
  • licenser,
  • kommersiella åtaganden,
  • partnerns avgifter.

För att hålla nere kostnaderna bör köparen:

  • skapa en tydlig konsumtionsmodell,
  • räkna på flera användningsscenarier,
  • kräva full pris- och fakturatransparens,
  • separera Microsoftkostnader från partnerns avgifter,
  • optimera resurser innan reservationer köps,
  • endast binda den stabila basförbrukningen,
  • kontrollera licensrättigheterna för Azure Hybrid Benefit,
  • införa budgetar, larm och automatiska åtgärder,
  • kräva obligatorisk taggning,
  • avtala om löpande kostnadsoptimering,
  • reglera prisändringar, åtaganden och exit.

Den mest framgångsrika Azureförhandlingen är inte nödvändigtvis den som ger den största rabatten.

Det är den som ger kunden kontroll över både priset, konsumtionen och den långsiktiga totalkostnaden.

Kontakta IJMO Consulting


Om författaren

Mathias Olsson är grundare av IJMO Consulting och senior inköpskonsult med erfarenhet av IT-inköp, SaaS, ERP, strategisk sourcing, avtalsförhandling och leverantörsstyrning. Han har arbetat i ledande inköps- och sourcingroller inom bland annat försäkring, IT, telekom och transport. Hans artiklar bygger på praktisk erfarenhet från upphandlingar, avtalsförhandlingar och förändringsprojekt.

Läs mer om Mathias Olsson →

Publicerad: 26 augusti 2026

Senast uppdaterad: 26 augusti 2026

Källor

  • Microsoft Azure, översikt över priser och erbjudanden för Azure.
  • Microsoft Learn, vägledning om valet mellan reservationer och Savings Plans.
  • Microsoft Azure, information om Azure Reservations.
  • Microsoft Learn, dokumentation om Azure Hybrid Benefit.
  • Microsoft Learn, dokumentation om Azure Spot Virtual Machines.
  • Microsoft Learn, åtkomstnivåer för Azure Blob Storage.
  • Microsoft Azure, priser för bandbredd och dataöverföring.
  • Microsoft Learn, Azure Pricing Calculator och kundspecifika priser.
  • Microsoft Learn, prisdokument för Microsoft Customer Agreement.
  • Microsoft Learn, budgetar och kostnadsexporter i Azure Cost Management.
  • Microsoft Learn, taggning och kostnadsfördelning.
  • Microsoft Learn, kostnader för externa tjänster från Azure Marketplace.