Õnneks langevad andmemahtude tasud tänu andmekandjate ja võrguseadmete tehnoloogia pidevale arengule ning nii talletusmahtude kui ka võrgu läbilaskevõime kasvule. Sellest hoolimata on oluline hinnata ettevõtte andmemahtu nii praegu kui ka tulevikuperspektiivis.

On olemas kahte tüüpi andmemahte, mida tasuks teada nii pilvteenuseid kasutades kui ka üldisemalt.
Esimene, mis tuleb tõenäoliselt kõigile ka esimesena pähe, on talletusmaht, mis tähendab täpselt seda, mida ka nimi ütleb – kui palju andmeid saab seadmesse või teenusesse salvestada. See on näitaja, millega arvestatakse nii uut telefoni ja arvutit kui ka pilveteenuseid valides.

Lisaks sellele on veel andmeedastusmaht, mis tähendab seda, kui palju andmeid liigub erinevate andmekandjate vahel, olgu see siis üle lokaalse ühenduse või võrgus. See maht muutub eriti oluliseks üle veebi pakutavate teenuste, näiteks ettevõtte veebilehe puhul. Kuna serveriteenuse pakkujate võrguühenduse võimekus on piiratud, on veebimaailmas andmeedastusmaht tavaliselt kas limiteeritud või kasutuspõhiselt hinnastatud.

Andmemahu puhul tasub ka arvestada, kas tegemist on pideva või ühekordse mahuga. Näiteks pilvteenustele migreerides või serveriruumide vahel kolides on ajalooliste andmete ületoomine
tavaliselt ühekordne tegevus, kuid ajalugu kaasa tuues võivad andmemahud niivõrd suured olla, et tasub tugevalt kaaluda, kas teha seda üle võrgu või füüsiliste seadmete abil. Olgu selleks siis oma salvestusseadmetega andmete liigutamine või näiteks AWS puhul krüpteeritud Snowball salvestuskohvri tellimine. Ekstreemsematel juhtudel on võimalik tellida isegi petabaitide jagu andmeid mahutav suur veoauto AWS Snowmobile.

Veebiteenused
Veebiteenuste (koduleheküljed, iseteeninduskeskkonnad, e-poed jms) puhul on olulised nii talletus- kui ka andmeedastusmaht, sest mõlemad on tavaliselt limiteeritud või kasutuspõhiselt tasustatud.

Lisaks on veebiteenuse puhul mõlemad mahud väga otseselt seotud kasutusjuhuga ning sõltuvad kasutatavast rakendusest.
Salvestusmaht jaguneb üldiselt kaheks – rakendus ja selle jooksutamiseks vajalik maht, mis tavaliselt ei ole eriti märkimisväärne ja seetõttu seda tihti ka eraldi välja ei arvutata. Küll aga tulenevalt rakenduse kasutusjuhust on üpriski tavaline, et töö käigus toodab rakendus ise suuremaid andmemahte, nt logikanded analüütika jaoks või kasutajate üleslaetavad meediafailid.

Andmeedastusmaht on samuti väga tugevalt seotud rakenduse kasutusjuhuga, kuid enamus nendest juhtudest on võimalik prognoositavat andmeedastusmahu suurusjärku välja arvestada. Veebilehekülge või veebirakenduse strateegiat luues on teada juba eesmärk, mille jaoks ja kellele see luuakse. See tähendab, et on ka juba teada, milliseid nö teekondi hakkavad kasutajad kõigi eelduste kohaselt seal läbima ning mis neid neil teekondadel ees ootab. Selle põhjal saab kokku võtta juba andmeedastusmahu, mis ühel külastajal selle teekonna läbimiseks kulub (liites kokku lehtede allalaaditava sisu mahud teekonnal). Ning seejärel – väga lihtsustatult öeldes – korrutada see maht prognoositava külastajate arvuga.

Loomulikult ei saa väga täpselt sellist asja ette kalkuleerida, sest see on väga haruldane juhus, kui külastajate teekonnad ja nende arv on 100% täpselt ette teada. Kuid see ei ole ka probleem, sest arvestades andmesalvestuse ja -edastuse mahtude hindu, on oluline aru saada suurusjärkudest.
Küll aga on alati tagantjärgi näha väga täpselt, kui palju mingit mahtu kulunud on.

Tagavarakoopiad
Tagavarakoopiate puhul on mahu hindamine natuke lihtsam. Enamikel juhtudest on juba teada, kui paljudest seadmetest ja teenustest tehakse tagavarakoopiad ning kui palju andmeid need seadmed talletada suudavad. Lisaks tuleks veel otsustada, kui kaua andmeid alles hoitakse ja kui pikalt peavad andmed olema kiiresti kättesaadavad. Näiteks, kui eesmärk on hoida alles kõiki tagavarakoopiaid kuni 30 päeva (finants jms andmete puhul näiteks 7 aastat), siis tavaliselt peaksid koheselt kättesaadavad olema viimase paari päeva andmed (kui peaks juhtuma õnnetus ja andmeid on vaja võimalikult kiiresti taastada).

Selle loogika järgi on võimalik valida kõige paremini sobivad ja võimalikult kuluefektiivsed arhiveerimisteenused. Näiteks AWS teenuste puhul tuleb kiiret ligipääsemist vajavad andmed talletada S3 teenusesse ning sellised, millega on rohkem aega - AWS Glacier teenusesse, mis hoiab kulud madalal.
Kui eelnevad mahud ja andmete säilitamise ajavahemikud on kokku lepitud, saab juba välja arvutada ka sellise automatiseeritud ja turvalise tagavarakoopiate lahenduse täpsemad mahud, ning nendest tulenevad kulud.