Estimate the cost of using Azure Blob Storage

This article helps you estimate the cost to store, upload, download, and work with data in Azure Blob Storage.

All calculations are based on a fictitious price. You can find each price in the sample prices section at the end of this article.

The cost to store data

Calculate your storage costs by multiplying the size of your data in GB by the storage price of the chosen access tier. For example, assuming sample pricing, if you plan to store 10 TB of blobs in the cool access tier, the capacity cost is $0.0115 * 10 * 1024 = $117.76 per month.

Depending on how much storage space you need, it might make sense to reserve capacity at a discount. You can reserve capacity in increments of 100 TiB and 1 PiB for a one-year or three-year commitment duration. Reserved capacity is available only for data stored in the hot, cool, and archive access tiers.

The following table uses the sample prices in this article to compare the pay-as-you-go and reserved capacity cost of storing 100 TB (102,400 GB) of data.

To calculate the point at which reserved capacity begins to make sense, divide the cost of reserved capacity by the pay-as-you-go rate. For example, if the cost of one-year reserved capacity for cool tier storage is $966 and the pay-as-you-go rate is $0.0115, the calculation is $966 / $0.0115 = 84,000 GB (roughly 82 TB). If you plan to store at least 82 TB of data in the cool tier for the entire reservation period, reserved capacity begins to make sense. The following table calculates the break-even point in TB for each access tier.

¹The hot tier has multiple pay-as-you-go rates. The price of the first 50 TB and the price of the second 50 TB are factored into this calculation.

To learn more about reserved capacity, see Optimize costs for Blob Storage with reserved capacity.

For general information about storage costs, see Data storage and index meters.

The cost to transfer data

When you transfer data, you pay for write and read operations. Some client applications use extra operations to transfer data, such as operations to list blobs or get properties. The AzCopy utility is optimized to transfer data efficiently and can serve as a canonical example on which to base your cost estimates.

See Estimate the cost of using AzCopy to transfer blobs.

The cost to upload

When you upload data, your client divides that data into blocks and uploads each block individually. Each uploaded block counts as a write operation. You need a final write operation to assemble blocks into a blob stored in the account. The number of write operations required to upload a blob depends on the size of each block. The default block size for uploads to the Blob Service endpoint (blob.core.windows.net) is 8 MiB, and you can configure it. The block size for uploads to the Data Lake Storage endpoint (dfs.core.windows.net) is 4 MiB, and you can't configure it. Smaller blocks can increase upload parallelism, but they also require more write operations and can increase costs.

The following table uses the sample prices in this article and assumes an 8-MiB block size to estimate the cost to upload 1,000 blobs that are each 5 GiB in size to the hot tier.

For more detailed examples, see Estimate the cost to upload.

The cost to download

The number of operations required to download a blob depends on which endpoint you use. If you download a blob from the Blob Service endpoint, you pay for a single read operation. If you download a blob from the Data Lake Storage endpoint, you pay for multiple read operations because blobs download in 4-MiB blocks. If you download blobs from the cool or cold tier, you also pay a data retrieval fee per GiB downloaded from the cool, cold, or archive tier.

The following table uses the sample prices in this article to estimate the cost to download 1,000 blobs that are 5 GiB each in size from the cool tier by using the Blob Service endpoint.

Utilities such as AzCopy also use list operations and operations to get blob properties. These charges are relatively small compared to the overall bill. For examples, see Estimate the cost to download.

The cost to copy between containers

If you copy a blob to another container in the same account, you pay for a single write operation based on the destination tier. If the destination container is in another account, you also pay for data retrieval and a read operation based on the source tier. If the destination account is in another region, you pay for network egress.

The following table uses the sample prices in this article to estimate the cost to copy 1,000 blobs that are 5 GiB each in size between two containers in the hot tier.

For a complete example, see Estimate the cost to copy between containers.

The cost to rename a blob

The cost to rename blobs depends on the file structure of your account and the number of blobs that you're renaming.

If the account has a flat namespace, there's no dedicated operation to rename a blob. Instead, your client tool copies the blob to a new blob and deletes the source blob. Delete operations are free. Therefore, when you rename a blob, you're billed for the cost of a single write operation. If the account has a hierarchical namespace, there's a dedicated operation to rename a blob, and it's billed as an iterative write operation.

The cost of a write operation against the Blob Service endpoint is lower than the cost of an iterative write operation against the Data Lake Storage endpoint. Therefore, renaming blobs individually costs less in accounts that have a flat namespace.

The following table uses the sample prices in this article to calculate the cost to rename 1,000 blobs.

Based on these calculations, the cost to rename 1,000 blobs in the hot tier differs by 70 cents.

The cost to rename a directory

If the account has a flat namespace, blobs are organized into virtual directories that mimic a folder structure. A virtual directory forms part of the name of the blob and is indicated by the delimiter character. Because a virtual directory is a part of the blob name, it doesn't actually exist as an independent object. You can't rename a virtual directory without renaming all of the blobs that contain that virtual directory in the name. To effectively rename each blob, client applications have to copy a blob and delete the source blob.

If the account has a hierarchical namespace, directories aren't virtual. They're concrete, independent objects that you can operate on directly. Therefore, renaming a directory is far more efficient because client applications can rename a directory in a single operation.

The following table uses the sample prices in this article to calculate the cost to rename 1,000 directories that each contain 1,000 blobs.

Based on these calculations, the cost to rename 1,000 directories in the hot tier that each contain 1,000 blobs differs by almost $5.00. For directories in the cold tier, the difference is over $17.

Example: upload, download, and change access tiers

This example shows four months of spending based on uploads, downloads, and the impact of moving objects between tiers.

Upload, download, and access tier parameters

At the beginning of each month, 1,000 files are uploaded to the hot access tier. Each file is 5 GB in size. During the month, client workloads read half of these files. After 30 days, a lifecycle management policy moves the other half to the cool access tier to save on storage costs.

In March, client applications read 10% of the data stored in the cool access tier. A lifecycle management policy moves those blobs back to the hot tier after clients read them.

Twenty days into April, clients once again read 10% of the data stored in the cool access tier. However, those blobs are stored in the cool tier for less than 30 days. Because the lifecycle management policy moves those blobs back to the hot tier before the minimum 30 days elapses, you incur an early penalty. The early deletion penalty is the cost of cool storage for 10 days.

Four-month Azure Blob Storage cost calculations

The following table uses the sample prices in this article to demonstrate four months of spending.

¹The number of operations required to complete each monthly upload is 641,000. The formula is 1,000 blobs * (5 GiB / 8-MiB blocks + 1 write operation to assemble each blob).

Sample prices

The following tables include sample (fictitious) prices for each request to the Blob Service endpoint (blob.core.windows.net).

See also

• Plan and manage costs for Azure Blob Storage
• Map each REST operation to a price
• Get started with AzCopy