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

You can 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.78 per month.

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

Using the Sample prices that appear in this article, the following table compares 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 1-year reserved capacity for cool tier storage is $966 and the pay-as-you-go rate is $0.0115, then 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 entirety of the reservation period, then reserved capacity begins to make sense. The following table calculates 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're billed for write and read operations. Some client applications use additional operations to transfer data such as operations to list blobs or get properties. The AzCopy utility is optimized to data transfer 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 block that is upload is billed as a write operation. A final write operation is needed to assemble blocks into a blob that is stored in the account. The number of write operations required to upload a blob depends on the size of each block. 8 MiB is the default block size for uploads to the Blob Service endpoint (blob.core.windows.net) and that size is configurable. 4 MiB is the block size for uploads to the Data Lake Storage endpoint (dfs.core.windows.net) and that size isn't configurable. A smaller block size performs better because blocks can upload in parallel. However, the cost is higher because more write operations are required to upload a blob.

Using the Sample prices that appear in this article, and assuming an 8-MiB block size, the following table estimates the cost to upload 1000 blobs that are each 5 MiB 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're billed the cost of a single read operation. If you download a blob from the Data Lake Storage endpoint, you're billed for cost of multiple read operations because blobs must be downloaded in 4-MiB blocks. If you download blobs from the cool or cold tier, you're also charged a data retrieval per GiB downloaded from the cool, cold, or archive tier.

Using the Sample prices that appear in this article, the following table estimates the cost to download 1,000 blobs that are 5 GiB each in size from the cool tier by using the Blob Storage endpoint.

Utilities such as AzCopy also use list operations and operations to obtain blob properties. As a proportion of the overall bill, these charges are relatively small. 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, then you're billed the cost of a single write operation that is based on the destination tier. If the destination container is in another account, then you're also billed the cost of data retrieval and the cost of a read operation that is based on the source tier. If the destination account is in another region, then the cost of network egress is added to your bill.

Using the Sample prices that appear in this article, the following table estimates 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 then delete the source blob. Delete operations are free. Therefore, when you rename a blob, you're billed for the cost of single write operation. If the account has a hierarchical namespace, then 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, the cost to rename blobs one-by-one, it costs less in accounts that have a flat namespace.

Using the Sample prices that appear in this article, the following table calculates 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, then 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. There's no way to 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 then 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 blob is far more efficient because client applications can rename a blob in a single operation.

Using the Sample prices that appear in this article, the following table calculates 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 uploads, downloads, and the impact of moving objects between tiers.

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, half of these files read by client workloads. 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 that is stored in the cool access tier. A lifecycle management policy is configured to move those blobs back to the hot tier after they're read.

Twenty days into April, clients once again read 10% of the data that is stored in the cool access tier. However, those blobs were 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, an early penalty is assessed. The early deletion penalty is the cost of cool storage for 10 days.

Calculations

Using the Sample prices that appear in this article, the following table demonstrates four months of spending.

¹The number of operations required to complete each monthly upload is 641,000. The formula to calculate that number is 1000 blobs * 5 GB / 8-MiB block + the write operation that is required to assemble all of the blocks into a blob.

Sample prices

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

The following table includes sample prices (fictitious) prices for each request to the Data Lake Storage endpoint (dfs.core.windows.net). For official prices, see Azure Data Lake Storage pricing.

See also

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