AWS prismodell för datalagring – så håller köparen kostnaderna nere

Amazon Web Services, AWS, använder huvudsakligen en förbrukningsbaserad prismodell. Kunden betalar för de tjänster och den kapacitet som används eller har provisionerats. Modellen ger stor flexibilitet, men gör samtidigt kostnadsbilden mer komplex än vid traditionell datalagring med ett fast månadspris.

För en köpare är det därför viktigt att inte enbart jämföra priset per gigabyte eller terabyte. Den totala kostnaden påverkas också av hur informationen används, hur ofta den läses, hur många filer som lagras, vilka prestandakrav som finns, hur många kopior som skapas och hur mycket data som överförs ut från AWS.

Den viktigaste principen är:

AWS-lagring ska utvärderas utifrån den totala kostnaden under hela avtalstiden – inte enbart utifrån priset för att lagra en gigabyte data.

AWS beskriver sin prismodell som huvudsakligen ”pay-as-you-go”. För vissa tjänster minskar enhetspriset när användningen ökar, och större kunder kan även förhandla om privata kommersiella villkor i utbyte mot ett åtagande.

AWS har flera olika lagringstjänster

Det finns inte en enda generell AWS-tjänst för datalagring. Vilken prismodell som gäller beror på vilken typ av lagring som används.

De tre vanligaste tjänsterna är Amazon S3, Amazon EBS och Amazon EFS.

Amazon S3

Amazon S3 är objektlagring och används bland annat för dokument, bilder, loggar, säkerhetskopior, arkiv, data lakes och annan applikationsdata.

Kunden kan behöva betala för:

• lagrad datamängd
• vald lagringsklass
• antalet skrivningar, läsningar och andra API-anrop
• hämtning av information från vissa lagringsklasser
• dataöverföring
• replikering
• funktioner för övervakning och analys
• återställning av arkiverad information

S3-priset är därför inte bara ett pris per gigabyte. Två kunder som lagrar lika mycket information kan få helt olika kostnader beroende på hur informationen används.

Amazon EBS

Amazon Elastic Block Store, EBS, används huvudsakligen som virtuella hårddiskar till EC2-servrar, databaser och andra applikationer som behöver blocklagring.

För EBS betalar kunden normalt för den kapacitet som har provisionerats. Om en volym på en terabyte har skapats men bara 200 gigabyte används, betalar kunden ändå för den provisionerade kapaciteten.

Beroende på volymtyp kan kunden också betala extra för provisionerade IOPS, det vill säga antal in- och utmatningsoperationer per sekund, samt för throughput. Snapshots och kopior av snapshots kan dessutom skapa ytterligare kostnader.

Amazon EFS

Amazon Elastic File System, EFS, är ett delat filsystem som kan användas av flera servrar och applikationer samtidigt.

EFS är elastiskt, vilket innebär att kunden normalt inte behöver provisionera själva lagringskapaciteten i förväg. Kostnaden kan i stället bestå av använd primär lagring, backuplagring, läsningar, skrivningar, flytt mellan lagringsnivåer och använd eller provisionerad throughput.

Valet mellan S3, EBS och EFS ska därför inte göras enbart utifrån vilket alternativ som har lägst pris per gigabyte. Köparen behöver även bedöma hur applikationen fungerar, vilka prestandakrav som finns och hur informationen ska användas.

S3 har olika lagringsklasser

Amazon S3 innehåller flera lagringsklasser. Grundprincipen är att information som används ofta och behöver vara direkt tillgänglig normalt har ett högre lagringspris. Information som används sällan eller kan vänta på återställning kan lagras till ett lägre pris.

S3 Standard

S3 Standard är avsett för information som används ofta och behöver vara direkt tillgänglig. Lagringspriset är högre än för arkivklasserna, men kunden slipper normalt särskilda avgifter för själva datahämtningen.

Det kan exempelvis vara ett lämpligt alternativ för aktiva dokument, applikationsdata, webbmaterial och filer som används regelbundet.

S3 Intelligent-Tiering

S3 Intelligent-Tiering kan användas när det är svårt att förutse hur ofta informationen kommer att användas. AWS övervakar åtkomstmönstret och flyttar automatiskt objekten mellan olika åtkomstnivåer.

Kunden betalar en övervaknings- och automatiseringsavgift per objekt. Mindre objekt under 128 KB övervakas inte på samma sätt utan ligger kvar på nivån för frekvent åtkomst. Intelligent-Tiering kan därför vara fördelaktigt för större objekt med varierande användning, men mindre lämpligt för miljontals mycket små filer.

S3 Standard-IA och S3 One Zone-IA

IA står för Infrequent Access. Dessa lagringsklasser är avsedda för information som används mer sällan men ändå behöver vara snabbt tillgänglig.

Det lägre lagringspriset kombineras med avgifter när data hämtas. Dessutom gäller normalt minst 30 dagars debitering. Om informationen tas bort eller flyttas tidigare kan kunden ändå få betala för återstående del av minimiperioden.

För dessa lagringsklasser finns även en minsta debiterbar objektstorlek på 128 KB. En fil som endast är 10 KB kan därför debiteras som om den vore 128 KB.

S3 Glacier

S3 Glacier-klasserna är avsedda för information som används sällan och huvudsakligen ska arkiveras.

Glacier Instant Retrieval ger direkt åtkomst men har ett lägre lagringspris och högre kostnader för hämtning än mer aktiva lagringsklasser.

Glacier Flexible Retrieval används för arkiv där kunden kan acceptera att återställningen tar från några minuter till flera timmar.

Glacier Deep Archive är avsett för mycket långsiktig arkivering och har ett mycket lågt lagringspris. Återställningen tar däremot längre tid.

Glacier Instant Retrieval och Glacier Flexible Retrieval har normalt minst 90 dagars lagringstid. Glacier Deep Archive har minst 180 dagar. Flexible Retrieval och Deep Archive har också ett metadatapåslag per arkiverat objekt.

Det billigaste lagringspriset är därför inte alltid det billigaste alternativet totalt. Om data behöver återställas ofta, snabbt eller i stora mängder kan kostnaden bli högre än för en mer aktiv lagringsklass.

Vilka kostnader måste en köpare räkna med?

En köpare behöver se AWS-kostnaden som summan av flera olika komponenter.

Kostnad för lagrad datamängd

Den mest uppenbara kostnaden är den mängd information som lagras. Priset påverkas bland annat av vald tjänst, lagringsklass och AWS-region.

Kostnaden kan även öka genom:

• äldre objektversioner
• säkerhetskopior
• snapshots
• replikering
• testkopior
• katastrofåterställningskopior
• data från avvecklade system
• tillfälliga filer som aldrig raderas

Det räcker därför inte att mäta den synliga produktionsdatan. Köparen behöver förstå hur många ytterligare kopior som faktiskt lagras.

Kostnad för API-anrop

Amazon S3 tar betalt för flera typer av anrop. Det kan exempelvis vara anrop för att:

• skapa eller skriva objekt
• läsa objekt
• lista innehåll
• kopiera objekt
• flytta objekt mellan lagringsklasser
• återställa arkiverade objekt

En applikation som kontinuerligt läser och skriver miljontals små filer kan därför få höga transaktionskostnader trots att den totala datamängden är relativt liten.

Kostnad för datahämtning

Flera billigare lagringsklasser tar betalt när information hämtas. Det innebär att ett lågt lagringspris kan kombineras med en hög rörlig kostnad när informationen används.

Köparen behöver därför förstå:

• hur ofta informationen kommer att hämtas
• hur stora datamängder som hämtas
• hur snabbt informationen måste bli tillgänglig
• om hela arkiv eller endast enstaka filer ska återställas
• hur kostnaden ser ut vid en större incident

Ett normalt användningsscenario räcker inte. Kostnaden för en större återställning behöver också beräknas.

Kostnad för dataöverföring

Data som överförs ut från AWS eller mellan olika AWS-regioner kan medföra kostnader. Replikering mellan regioner kan också innebära att kunden både betalar för överföringen och för lagringen av kopian i målregionen.

Dataöverföring är särskilt viktig för verksamheter som:

• skickar stora filer till kunder
• använder flera molnleverantörer
• överför data till ett eget datacenter
• genomför omfattande rapportering
• har integrationer mellan regioner
• behöver flytta data vid avtalets slut

Dataöverföring bör därför betraktas både som en löpande driftkostnad och som en potentiell exitkostnad.

Kostnad för prestanda

För EBS och EFS kan prestanda vara en separat prisdrivare. Kunden kan exempelvis betala för provisionerade IOPS eller throughput.

Det är vanligt att en lösning dimensioneras utifrån ett teoretiskt maximalt behov. Kunden kan då betala för prestanda som endast används under några få timmar per månad eller aldrig används alls.

Köparen bör därför kräva att leverantören skiljer mellan:

• normal belastning
• återkommande toppbelastning
• exceptionell toppbelastning
• säkerhetsmarginal
• faktiskt uppmätt användning

De vanligaste kostnadsfällorna

Fel lagringsklass

En vanlig kostnadsfälla är att välja lagringsklass utifrån priset per gigabyte utan att analysera hur informationen faktiskt används.

Att placera data i en billig arkivklass kan vara rätt om informationen sällan behöver hämtas. Om informationen används oftare än förväntat kan hämtningsavgifter och transaktionskostnader göra lösningen dyrare än S3 Standard eller Intelligent-Tiering.

Valet bör därför baseras på verkliga åtkomstmönster, inte enbart på filernas ålder.

För många små filer

Ett stort antal små objekt kan skapa kostnader genom API-anrop, minsta debiterbara objektstorlek, metadata och övervakningsavgifter.

En terabyte fördelad på några hundra stora filer får därför en annan kostnadsprofil än samma datamängd fördelad på hundratals miljoner små filer.

Köparen bör alltid begära information om både:

• total datamängd
• antal objekt
• genomsnittlig objektstorlek
• antal transaktioner per månad

Minsta lagringstid förbises

Billigare lagringsklasser har ofta en minsta debiteringstid. Om informationen raderas, skrivs över eller flyttas tidigare kan kunden fortfarande behöva betala för återstående tid.

Detta är särskilt viktigt för:

• tillfälliga filer
• kortlivade säkerhetskopior
• testdata
• snabbt roterande loggar
• filer som skrivs över ofta
• information med kort retentionstid

Köparen bör säkerställa att lagringsklassens minimiperiod passar informationens verkliga livslängd.

Versionering aktiveras utan begränsning

S3 Versioning kan skydda mot oavsiktlig radering och överskrivning. Funktionen kan samtidigt öka lagringskostnaden kraftigt.

Varje version lagras som ett fullständigt objekt. Det är alltså inte bara förändringen jämfört med föregående version som sparas. Om samma fil skrivs över tio gånger kan tio fullständiga versioner bli kvar och debiteras.

Versionering bör därför kombineras med regler för:

• hur många äldre versioner som får sparas
• hur länge äldre versioner ska behållas
• när äldre versioner ska arkiveras
• när äldre versioner ska raderas

Snapshots och säkerhetskopior saknar ägare

Snapshots och säkerhetskopior skapas ofta automatiskt, men raderas inte alltid när systemet förändras eller avvecklas.

Kostnaden kan därför fortsätta efter att den ursprungliga servern, databasen eller applikationen har tagits ur drift.

Varje säkerhetskopia bör ha:

• en dokumenterad ägare
• ett definierat syfte
• en bestämd retentionstid
• ett fastställt raderingsdatum
• ett dokumenterat återställningskrav

Onödig replikering

Replikering kan behövas för tillgänglighet, kontinuitet och regulatoriska krav. Men att replikera all information till flera regioner kan bli dyrt.

Kunden kan få betala för:

• originaldata
• replikerad data
• överföring mellan regioner
• replikeringsanrop
• versioner av den replikerade informationen
• backup av både original och kopia

Köparen bör därför fråga vilken information som faktiskt behöver replikeras och varför. Ett generellt krav på att all data ska finnas i två regioner kan skapa betydande merkostnader utan motsvarande verksamhetsnytta.

Överdimensionerade EBS-volymer

Eftersom EBS debiteras utifrån provisionerad kapacitet räcker det inte att radera filer från volymen. Volymens storlek måste också anpassas.

Det bör finnas en återkommande process för att identifiera:

• volymer med låg användningsgrad
• volymer som inte längre är anslutna
• onödigt hög provisionerad prestanda
• gamla snapshots
• testvolymer
• lagring som tillhör avvecklade system

Ingen vet vem som driver kostnaden

Om AWS-resurser inte märks upp och fördelas på rätt applikation, projekt, affärsområde och kostnadsställe blir kostnaden svår att styra.

En gemensam IT-kostnad utan tydlig ägare leder ofta till att ingen verksamhet känner ansvar för att minska sin användning.

AWS Cost Categories och kostnadstaggar kan användas för att kategorisera kostnader utifrån bland annat konto, tjänst, projekt, system och organisatorisk enhet.

Vad bör köparen göra före upphandlingen?

Kartlägg den verkliga användningen

Innan leverantörerna får lämna pris behöver köparen skapa en faktabaserad nulägesbild.

Kartläggningen bör omfatta:

• aktuell lagringsvolym
• förväntad tillväxt per år
• antal objekt och filer
• genomsnittlig objektstorlek
• antal läsningar och skrivningar
• antal kopieringar och listningar
• utgående datatrafik
• överföring mellan regioner
• återställningsfrekvens
• backup och snapshots
• versionering
• replikering
• retentionstider
• krav på IOPS och throughput
• krav på återställningstid
• vilka AWS-regioner som ska användas

När användningsdata saknas bör leverantörerna få räkna på flera tydligt definierade scenarier. De ska inte själva få göra dolda eller generella antaganden.

Klassificera informationen

All information behöver inte ha samma lagringsklass, prestanda eller tillgänglighet.

Köparen bör dela in informationen utifrån exempelvis:

• verksamhetskritisk information
• aktiv information
• information som används sällan
• säkerhetskopior
• regulatoriska arkiv
• testdata
• loggar
• tillfälliga filer
• data som kan återskapas

För varje kategori bör det framgå hur snabbt informationen måste kunna hämtas, hur länge den ska sparas och om den behöver replikeras.

Det förhindrar att den dyraste lagringsnivån används för all information.

Skilj mellan krav och önskemål

Krav på tillgänglighet, redundans, återställningstid och retention driver kostnader.

Köparen behöver skilja mellan:

• regulatoriska krav
• avtalade kundkrav
• verksamhetskritiska krav
• interna policykrav
• tekniska rekommendationer
• generella önskemål

Ett tekniskt önskemål bör inte automatiskt omvandlas till ett obligatoriskt upphandlingskrav utan att kostnad och verksamhetsnytta har bedömts.

Begär en transparent prismodell

Leverantören bör inte bara ange en uppskattad månadskostnad. Det ska framgå hur kostnaden har räknats fram.

Köparen bör kräva separat redovisning av:

• kostnad per AWS-tjänst
• kostnad per lagringsklass
• lagrad datamängd
• antalet API-anrop
• datahämtning
• återställning från arkiv
• utgående dataöverföring
• överföring mellan regioner
• replikering
• backup och snapshots
• versionering
• IOPS
• throughput
• övervakning
• AWS-support
• partnerns support
• partnerns marginal eller påslag
• migrering
• löpande förvaltning
• avveckling och exit

Det ska vara möjligt att skilja AWS faktiska kostnad från de avgifter som tas ut av en återförsäljare, driftpartner eller SaaS-leverantör.

Detta är särskilt viktigt när kunden köper en AWS-baserad tjänst som en del av ett större SaaS-avtal. Leverantören kan annars hänvisa till ökade molnkostnader utan att kunden kan kontrollera vad som faktiskt har förändrats.

Kräv flera kostnadsscenarier

En prisprognos baserad på ett enda normalscenario är inte tillräcklig.

Köparen bör minst begära följande scenarier.

Normalscenario

Detta ska visa förväntad kostnad utifrån normal användning, normal tillväxt och vanligt åtkomstmönster.

Tillväxtscenario

Detta ska visa kostnaden om datamängd, transaktioner eller utgående trafik ökar mer än förväntat.

Återställningsscenario

Detta ska visa kostnaden för att återställa en större mängd information efter exempelvis en incident, ett systemfel eller en ransomwareattack.

Exitscenario

Detta ska visa kostnaden för att återställa, exportera, överföra och verifiera all information när avtalet upphör eller när kunden byter leverantör.

Förändringsscenario

Detta ska visa hur kostnaden påverkas om krav på region, tillgänglighet, retention, replikering eller återställningstid förändras.

Genom att jämföra scenarierna får köparen en bättre bild av både den förväntade kostnaden och den ekonomiska risken.

Använd Lifecycle-regler

S3 Lifecycle-regler kan automatiskt flytta information till billigare lagringsklasser eller radera information när den inte längre ska sparas.

Reglerna kan bland annat användas för att:

• flytta äldre information till en billigare lagringsklass
• arkivera information efter en bestämd tid
• radera information när retentionstiden har löpt ut
• radera äldre objektversioner
• radera ofullständiga uppladdningar

Lifecycle-regler kan ge stora besparingar, men de behöver konfigureras utifrån objektens storlek, livslängd och användningsmönster. Övergångar mellan lagringsklasser kan också medföra transaktionskostnader och avgifter för tidig radering.

Köparen bör därför kräva att reglerna dokumenteras, testas och följs upp.

Inför löpande kostnadskontroll

AWS-kostnader bör inte enbart granskas när fakturan kommer. Kostnadsstyrningen behöver ske kontinuerligt.

AWS Cost Explorer kan användas för att analysera historiska kostnader, identifiera kostnadsdrivare, filtrera kostnader och skapa prognoser. AWS Budgets kan användas för att sätta budgetgränser och skicka varningar när faktisk eller prognostiserad kostnad närmar sig eller passerar en fastställd nivå.

S3 Storage Lens kan ge en samlad bild av användning, aktivitet, tillväxt och möjligheter till kostnadsoptimering i S3. Grundläggande mätvärden finns utan separat avgift, medan mer avancerade mätvärden kan medföra en objektsbaserad övervakningskostnad.

Köparen bör kräva:

• månatlig kostnadsrapportering
• prognos för kommande månader
• analys av större avvikelser
• larm vid överskridna gränsvärden
• identifiering av oanvänd lagring
• identifiering av gamla snapshots och versioner
• förslag på konkreta besparingar
• uppföljning av genomförda åtgärder
• namngivna ägare för de största kostnadsområdena

Rapporteringen bör visa både total kostnad och kostnad per system, verksamhet, projekt och kostnadsslag.

Optimera före prisförhandlingen

AWS erbjuder volymbaserade priser och möjligheter till privata kommersiella villkor för kunder som gör ett större åtagande.

Ett långsiktigt åtagande bör däremot inte göras innan miljön har optimerats.

Om kunden först förbinder sig till en viss kostnadsnivå och därefter minskar användningen kan åtagandet bli större än den verkliga förbrukningen. Kunden riskerar då att betala för en rabatt som inte kan utnyttjas fullt ut.

En bättre ordning är att:

1. kartlägga användningen
2. rensa bort oanvänd lagring
3. anpassa lagringsklasser
4. införa korrekta retentionstider
5. minska onödig replikering
6. anpassa EBS-kapacitet och prestanda
7. beräkna en optimerad basförbrukning
8. lägga till realistisk tillväxt
9. därefter förhandla om pris och åtagande

Vad bör köparen förhandla om?

Förhandlingen bör inte enbart handla om en generell rabatt på AWS-fakturan.

Köparen bör även klargöra:

• vilka AWS-tjänster rabatten omfattar
• om rabatten gäller i samtliga aktuella regioner
• hur volymbaserade rabatter kombineras med den avtalade rabatten
• hur användning utöver åtagandet prissätts
• vad som händer om användningen blir lägre än planerat
• om åtagandet kan flyttas mellan konton eller bolag
• hur nya AWS-tjänster ska hanteras
• hur AWS prisförändringar slår igenom
• hur valutaförändringar hanteras
• hur partnerns marginal redovisas
• hur AWS-support och partnerns support prissätts
• hur kostnaderna ska verifieras mot AWS faktiska faktura
• vilka kostnader som gäller vid migrering och exit

Kunden bör kunna se AWS bruttopris, avtalad rabatt, partnerns eventuella påslag och det slutliga nettopriset.

Krav att ta med i en RFP

En RFP för AWS-baserad datalagring bör kräva att leverantören:

• redovisar samtliga prisdrivare
• anger alla volym- och användningsantaganden
• visar kostnader per AWS-tjänst
• visar kostnader per lagringsklass
• separerar AWS-kostnader från partneravgifter
• redovisar priser för relevanta API-anrop
• redovisar kostnader för datahämtning
• redovisar kostnader för utgående dataöverföring
• redovisar kostnader för regional överföring
• redovisar kostnader för backup och snapshots
• redovisar kostnader för versionering
• redovisar kostnader för replikering
• redovisar kostnader för IOPS och throughput
• lämnar en kostnadsprognos för minst tre år
• räknar på normal-, tillväxt-, återställnings- och exitscenario
• beskriver hur kostnader ska följas upp
• beskriver hur avvikelser ska rapporteras
• beskriver hur kostnadsoptimering ska genomföras
• anger vilka rabatter och åtaganden som erbjuds
• beskriver hur kundens information ska återlämnas

Reglera kostnadsstyrningen i avtalet

Ett lågt initialt pris är inte tillräckligt om kostnaden därefter kan öka utan kontroll.

Avtalet bör därför reglera:

• vem som ansvarar för kostnadsprognosen
• hur ofta kostnaden ska följas upp
• vilket rapportformat som ska användas
• hur kostnader ska fördelas
• vilka gränsvärden som ska utlösa larm
• när kundens godkännande krävs
• vem som får öka kapacitet och prestanda
• vem som får aktivera nya regioner
• vem som får införa ytterligare replikering
• vem som ansvarar för att radera oanvända resurser
• hur gamla snapshots och versioner ska hanteras
• hur ofta leverantören ska föreslå optimeringar
• hur rabatter och prisförändringar ska redovisas
• kundens rätt att granska underliggande kostnader
• kundens rätt att exportera sin information
• ansvar och kostnader vid exit

Om driftpartnerns ersättning beräknas som en procentandel av AWS-kostnaden kan partnern få ett svagt ekonomiskt incitament att minska kundens förbrukning. Ersättningsmodellen bör därför granskas noggrant.

En modell där leverantören får del av verifierade besparingar kan i vissa situationer skapa bättre incitament än ett generellt procentuellt påslag.

Sammanfattning

AWS prismodell för datalagring ger stor flexibilitet, men kostnaden kan bli svår att förutse om köparen endast fokuserar på priset per gigabyte.

För att hålla kostnaden nere behöver köparen:

• förstå skillnaden mellan S3, EBS och EFS
• bedöma den totala kostnaden över hela avtalstiden
• kartlägga datamängd, objektstorlek, transaktioner och datatrafik
• välja lagringsklass utifrån verklig användning
• begränsa versioner, snapshots och onödiga kopior
• använda Lifecycle-regler
• kontrollera utgående dataöverföring
• undvika överdimensionerad EBS-kapacitet och prestanda
• införa kostnadstaggar, budgetar och varningar
• optimera miljön innan ett långsiktigt åtagande görs
• kräva en transparent prismodell
• begära flera kostnadsscenarier
• reglera kostnadsstyrning och exit i avtalet

Den största besparingen uppnås sällan genom att enbart pressa priset per terabyte. Den uppnås genom en kombination av rätt arkitektur, korrekta verksamhetskrav, löpande kostnadskontroll och ett avtal som ger kunden insyn och kontroll över hela kostnadsbilden.

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

1. AWS Product and Service Pricing – information om AWS förbrukningsbaserade prismodell, volympriser och Private Pricing.
2. Amazon S3 Pricing – information om lagring, API-anrop, datahämtning, överföring och replikering.
3. Amazon S3 Storage Classes och Glacier Storage Classes – information om lagringsklasser, minsta lagringstider och återställning.
4. Amazon EBS Pricing – information om provisionerad lagring, IOPS, throughput och snapshots.
5. Amazon EFS Pricing – information om primär lagring, backup, läsning, skrivning och throughput.
6. S3 Versioning – information om hur fullständiga objektversioner sparas och debiteras.
7. Managing the Lifecycle of Objects – information om automatiska övergångar och radering genom S3 Lifecycle.
8. AWS Cost Explorer och AWS Budgets – information om kostnadsanalys, prognoser, budgetar och varningar.
9. Amazon S3 Storage Lens – information om analys av S3-användning och kostnadsoptimering.
10. AWS Cost Categories – information om hur kostnader kan kategoriseras och fördelas inom organisationen.