Så använder du Azure Pricing Calculator (steg för steg)

Molnkostnader är lätta att underskatta tills den första fakturan kommer. Som tur är finns Azure Pricing Calculator, Microsofts kostnadsfria verktyg utan inloggning för att uppskatta kostnaden för Azure-tjänster innan du distribuerar något.

Haken är att Azure inte har ett pris per tjänst. En virtuell dator kostar till exempel olika beroende på region, storlek, hur många timmar i månaden den körs och vilken prisplan du väljer. Multiplicera det över en verklig arkitektur med fem eller sex tjänster, och ett enda listpris blir i stort sett värdelöst.

I den här artikeln bygger jag en uppskattning från grunden, går igenom ett exempel med en virtuell dator i detalj och tar upp misstagen som tyst förstör annars noggranna uppskattningar.

Det snabba svaret: Så använder du Azure Pricing Calculator

Öppna Azure Pricing Calculator och följ stegen nedan:

1. Sök i produktväljaren efter den Azure-tjänst du vill prissätta, till exempel Virtual Machines.
2. Välj den för att lägga till den i din uppskattning med standardkonfigurationen.
3. Ställ in region, nivå, storlek och andra tjänstespecifika alternativ som du kommer att använda.
4. Ange förväntad användning, såsom timmar per månad, lagring i GB eller förfrågningar per sekund, beroende på vad tjänsten debiterar för.
5. Välj en prismodell, till exempel Pay-As-You-Go, Reserved Instance eller Azure Savings Plan.
6. Granska månadskostnaden och, där det är relevant, förskottskostnaden som visas för den produkten.
7. Upprepa för alla andra tjänster i din arkitektur, såsom databasen, lagringskontot och lastbalanseraren.
8. Lägg till en supportplan längst ned på sidan.

Totalsumman uppdateras i realtid när du ändrar något fält. Det är också här de flesta uppskattningar faller i produktion: team prissätter den ena tjänsten de fokuserar på och glömmer de tjänster den är beroende av.

Läsa din uppskattning

Kalkylatorn har tre delar som är viktigast, och det hjälper att veta vad var och en gör innan du börjar skriva in siffror.

• Produktväljaren: Detta är sök- och kategori­bläddraren högst upp på sidan. Kategorierna omfattar Compute, Storage, Databases, Networking samt AI and Machine Learning. Om du inte kan det exakta produktnamnet går det oftast snabbare att bläddra efter kategori än att gissa sökord.
• Tjänstkonfigurationen: Varje produkt du lägger till får sitt eget konfigurationsblock, och innehållet i blocket beror på tjänsten. En VM ber om till exempel OS, storlek och region. Ett lagringskonto ber däremot om redundansnivå och åtkomstfrekvens. Det finns inget universellt formulär, så du konfigurerar varje tjänst på dess egna villkor.
• Beräknad användning: Här omvandlas prognostiserad förbrukning, såsom timmar, GB och transaktioner, till en kostnad. Det är också fältet som oftast lämnas på standardvärdet, ett misstag jag tar upp senare i artikeln.

Vissa tjänster visar både en förskottskostnad och en månadskostnad. Den uppdelningen dyker främst upp med reservationer, där du betalar en del nu för att låsa in en lägre återkommande kostnad. En månadssiffra utan förskottskostnad brukar innebära att du använder Pay-As-You-Go.

Genomgång: Prissätta en virtuell dator

Tänk dig en allmän VM för en stagingmiljö. 

Först söker vi efter ”Virtual Machine” och lägger till den i uppskattningen. Produkten har standard för storlek och region. Ändra region först, eftersom den påverkar alla priser på sidan, och välj sedan OS och VM-storlek. Notera att Windows innebär en licensavgift jämfört med Linux om du inte slår på Azure Hybrid Benefit.

Ställ nu in förväntad användning. Microsofts standardantagande är 730 timmar per månad, vilket motsvarar genomsnittligt antal timmar i en månad. Med andra ord antar kalkylatorn att VM körs dygnet runt. Det stämmer oftast för en produktionsserver, men inte för en stagingmaskin som bara behöver vara uppe under kontorstid.

Sänk timmarna från 730 till, säg, 200, så uppdateras uppskattningen direkt. Förändringen är ofta inte proportionell, eftersom vissa prisnivåer har minimigränser eller stegfunktioner. En minskning med 70% i timmar ger inte alltid 70% lägre kostnad. Denna icke-linearitet är skälet till att en statisk prislista inte kan ge dig den verkliga kostnaden, och det är den praktiska anledningen att använda kalkylatorn i stället för att uppskatta utifrån listpriser.

Jämföra prisplaner

När du har en grunduppskattning visar kalkylatorn sitt verkliga värde. Du kan köra samma VM under olika åtagandenivåer och se exakt vad som förändras.

Pay-As-You-Go kräver inget åtagande och har det högsta timpriset, med full flexibilitet att ändra storlek eller ta bort när som helst. Reserved Instances låter dig binda dig till en specifik VM-storlek i en specifik region i ett eller tre år i utbyte mot ett påtagligt lägre pris. Besparingar för allmänna storlekar ligger typiskt i intervallet 40–70%, beroende på åtagandets längd.

Azure Savings Plan låter dig binda dig till ett timbelopp i stället för en specifik VM, och Azure tillämpar rabatten på all berättigad compute även om du byter storlek eller flyttar arbetslaster.

Det finns inget enda rätt val här. Det beror på hur stabil din arbetslast är och hur mycket flexibilitet du behöver.

Vad som faktiskt flyttar siffran

Ett fåtal arkitekturbeslut, inte finansiella, styr större delen av din faktura:

Region

Region spelar en stor roll, eftersom samma VM-storlek kan kosta märkbart mer i en region än i en annan. Om efterlevnad inte binder dig till en viss region, jämför några närliggande alternativ.

Tjänstenivå och storlek

Tjänstenivå och storlek spelar också roll, eftersom det är vanligt och dyrt att hoppa upp en nivå ”för säkerhets skull”. Modellera dina faktiska behov, inte en buffert ovanpå dem.

Operativsystem och licensiering

Operativsystemet påverkar också priset, eftersom licenser för Windows och SQL Server innebär en verklig kostnad. Som nämnts är Azure Hybrid Benefit reglaget för team som redan äger licenser, och det är lätt att missa.

Användningsvolym och prisplan

Användningsvolym och prisplan, som täcks ovan, är där de flesta variationerna finns.

Vanliga misstag som sabbar en uppskattning

Även en noggrant byggd uppskattning kan bli fel på några förutsägbara sätt. Det här är de som är värda att kontrollera innan du litar på siffran.

Låta standardanvändningen vara oförändrad

Det första misstaget är att låta standardanvändningen vara oförändrad. Standardvärdet 730 timmar är en bra startpunkt men ett dåligt slutgiltigt svar för allt som inte körs dygnet runt. 

Glömma stödtjänster

Det andra är att glömma stödtjänster: en VM behöver en disk, och en applikation behöver vanligtvis en databas. Uppskattningar som prissätter den primära tjänsten och utelämnar infrastrukturen runt den kommer konsekvent att underskatta den faktiska fakturan. 

Välja fel region

Det tredje är att välja fel region, vilket är lätt hänt när du uppskattar åt en kund eller ett team på en annan plats än din. 

Ignorera dataöverförings- och nätverkskostnader

Det fjärde är att ignorera dataöverförings- och nätverkskostnader, som varierar med din förbrukning. 

Jämföra listpriser med förhandlade priser

Det femte är att jämföra listpriser med förhandlade priser: om din organisation har ett Enterprise Agreement kommer de offentliga listpriserna i kalkylatorn inte att matcha vad du faktiskt betalar om du inte loggar in och tillämpar ditt avtal. 

Behandla uppskattningen som den slutliga fakturan

Slutligen, behandla inte uppskattningen som den slutliga fakturan. Microsoft påpekar själv att sparade totalsummor kan skifta när Azures publicerade priser ändras, så bygg in en marginal.

Azure Pricing Calculator vs. Azure Cost Management

Detta är två separata verktyg som löser olika problem. Pricing Calculator uppskattar kostnaden innan du distribuerar något och låter dig modellera hypotetiska konfigurationer och jämföra scenarier som ännu inte finns. Azure Cost Management analyserar å andra sidan vad du faktiskt spenderar när resurserna är igång. Det handlar om faktisk användning, faktiska fakturor och faktiska avvikelser.

Du behöver båda, vid olika tidpunkter. Använd kalkylatorn för att uppskatta och planera en budget innan du bygger. Använd Cost Management efteråt för att kontrollera om verkligheten matchar planen och för att fånga den drift som oundvikligen dyker upp när verklig trafik träffar verklig infrastruktur.

Bästa praxis för att uppskatta Azure-kostnader

Några bästa praxis ger konsekvent mer tillförlitliga uppskattningar

• Modellera realistisk användning, varken maximal kapacitet eller minimum.
• Ta med varje komponent i arkitekturen, inte bara de som ser dyra ut
• Jämför ett par regioner om dina efterlevnadskrav tillåter det.
• Kör samma arbetslast med Pay-As-You-Go och med en åtagandenivå innan du väljer.
• Bygg tre scenarier (förväntad, låg och hög användning) i stället för ett enda tal, så att du har ett spann att planera efter.
• Se över uppskattningen när arkitekturen eller Azures prissättning ändras, eftersom inget av dem står still länge.

Slutsats

Arbetsflödet är enkelt: lägg till de tjänster du behöver, konfigurera dem så att de matchar hur de faktiskt kommer att köras, ange realistiska användningssiffror, välj en prisplan och granska totalen. Kalkylatorn sköter matematiken.

Träffsäkerheten i resultatet beror helt på hur väl indata stämmer med verkligheten. En exakt beräknad uppskattning byggd på ett felaktigt användningsantagande är fortfarande en felaktig uppskattning.

Bygg flera scenarier innan du låser en arkitektur, och när resurserna är distribuerade, jämför uppskattningen med den faktiska spendingen i Azure Cost Management. Varje gap mellan de två är informativt: det visar var dina ursprungliga antaganden skilde sig från verklig användning.