Microsoft Azure offers a several storage options but requires some time to understand its sometimes. Essentially there are four different storage types, three classes within an object storage, two account types and two access tiers. This sounds complex but it isn’t really.

Let’s have a look at the differences then:-

can i buy Premarin over the counter in spain Storage Types

Azure has four major storage types:

  • source url Object/Blob Storage
    a service for storing large amounts of unstructured data that can be accessed from anywhere in the world via HTTP or HTTPS common uses for Azure Blob storage might include (but are definitely not limited to):
    • Serving images or documents directly to a browser
    • Storing files for distributed access
    • Streaming video and audio
    • Performing secure backup and disaster recovery
    • Storing data for analysis by an on-premises or Azure-hosted service

    The Object/Blob Storage type also includes the following Storage Classes:

    • Block Blob
    • Append Blob
    • Page Blob (Disk)

    These are explained below in the relevant section.

  • safe buy viagra online canada Table Storage
    stores structured NoSQL data
    , store flexible datasets, such as user data for web applications, address books, device information, and any other type of metadata.
  • Queue Storage
    – provides cloud messaging between application components
  • File Storage
    – shared storage for applications using the standard SMB 2.1 or SMB 3.0 protocol.

Account Types

Recently Microsoft introduced 2 different account types, a General-Purpose Account and a Blob Storage Account. General Purpose storage accounts provide storage for blobs, files, tables, queues and Azure virtual machine disks under a single account. However, a Blob Storage Account can be Hot or Cold depending on how frequently the data in the account needs to be accessed. You can then choose an access tier that matches your needs and optimizes costs. See the Blob Storage section below.

  • General-Purpose Account

    • A general-purpose storage account gives you access to Azure Storage services such as Tables, Queues, Files, Blobs and Azure virtual machine disks under a single account. This type of storage account has two performance tiers:
    • A standard storage performance tier which allows you to store Tables, Queues, Files, Blobs and Azure virtual machine disks.
    • A premium storage performance tier which currently only supports Azure virtual machine disks. See Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads for an in-depth overview of Premium storage.
  • Blob Storage Account
    — designed to work with Block and Append Blob Storage services only in the Object/Blob Storage environment. Note that Blob storage accounts do not yet support page blobs or Zone-redundant storage (ZRS).


To make life a little easier this diagram should help you visualize the layout.

Detailed Explanation

Azure Blob Storage Model

Azure Storage Accounts consist of one or more Containers and cannot exceed a total size of 100Tb at present. All blobs must be located in a container. For Limits see

Container Names must begin with a letter or a number, can contain only letters, numbers, and the dash (-) character, and all letters must be lowercase. Container names must be a minimum of 3 and not more than 63 characters in length.

Blob Names can contain any characters, but special characters and characters reserved for use in URLs must be escaped. Blob names can include upper and lower-case letters, and cannot exceed 1024 characters in length.

Object/Blob Storage

Block Blobs

The term blob basically stands for Binary Large Objects. This is a typical database term, where blob data may be data stored in a database which does not conform to a standard data type as defined by the database. This type of data typically is persisted as plain binary data such as image files.

Block Blobs are designed for very large amounts of unstructured data such as backups, documents or images. Basically blobs are containers, where your data is stored. When you upload or create files in a blob, they break up into a multitude of 4MB chunks called blocks. Each blob can currently contain 50.000 blocks. So the total capacity of a blob (file for example) is in theory 195 GB (4MB * 50,000). Blocks acquire a unique ID so they can be deleted from the file or replaced by other blocks

One thing to note is you have to commit new blocks — is basically means you have to merge them with the blob otherwise all unassociated blocks would be deleted within a week. The good news here though is that blocks upload in parallel which saves time time and can be uploaded in any order, which in turn helps provide a stable backup even if you have a poor Internet connection. The user can set the order of blocks in the blob manually after the upload is done, which allows to quickly determine failed or unnecessary blocks and re-upload them.

See the Access
Keys below for more information about security and access.

Append Blobs

Append Blobs are in the most, the same as Block Blobs: they also consist of blocks and have the same limitations, but were designed mainly for append operations. Updating and deleting existing blocks is not supported. Append Blob is optimized for fast append operations, making it ideal for scenarios where the data must be added to an existing blob without modifying the existing contents of that blob (Eg. logging, auditing). Append Blobs don’t use block IDs.

Page Blobs (Disks)

Page Blobs represent a slightly concept within Microsoft Azure. Unlike Block and Appended Blobs they consist of 512-byte pages optimized for both read and write operations. Page blobs are used with Azure virtual machines. To upload data into the Page Blob a user has to write pages and specify an offset within 512-byte range.

There are two types of Page Blob storage:

  • Standard — for VMs with an average amount of write/read operations. This SAS drives.  With Standard Storage you only pay for used capacity but do incur charges for transactions.
  • Premium — for high amount of write/read operations and decreased latency. Think SSD drives.  With Premium Storage, you pay for provisioned capacity rather than used capacity and Premium Storage does not incur separate charges for transactional volume!

Cold Blob v Hot Blob

There are also two access tiers available for users divided by two different types of data.

  • Hot Blob — for data that require frequent access, i.e. user data or recent backups. The pricing of storing the data is higher than the Cool tier, but the cost of access requests is much lower.
  • Cool Blob — for data that doesn’t require frequent access: old backup versions, archives and so on. Here you pay less for storing such data, but the cost of access request is higher.

Note: Hot and Cool access tiers are currently available in Central US, East US 2, North Central US, North Europe, West Europe, Southeast Asia, Japan East and Japan West regions.

In summary:

Block Blob

Append Blob

Page Blob

Consists of




Minimum object length

4 Mb

4 Mb


Maximum container size

195 Gb

195 Gb

1 Tb

Premium Storage option




Hot & Cold access options




Suitable for VM’s




Suitable for backup




Understanding of storage classes is not the only thing that affects data security and availability. Looking at how Azure protects your data and how much it costs.

Redundancy Levels

Microsoft Azure offers 4 data redundancy options:

  • Locally Redundant Storage (LRS) — a few copies of your data inside one data center. On practice it means the lowest level of disaster protection, since data center can be knocked out by power outage or a region-level natural disaster
  • Zone Redundant Storage (ZRS) — three copies of your data set spread within one region or across regions. Works only for Block Blob
  • Geographically Redundant Storage (GRS) — three copies within one region plus another three copies in a distant region
  • Read-Access Geographically Redundant Storage (RA-GRS) — the same as GRS option, but also allows to have the read access to the data in the distant data center

The following table compares all the replication levels:





Data replicated across multiple data centers





Number of replicated copies



3 + 3

3 + 3

Access to replicated data





Where to put your storage?

Well before you decide where to put your storage you should run an Azure Speed Test located at This will determine the best region to ensure less latency and fast throughput.

Access to the Storage (Security and Access Keys)

Access keys are used in authentication for accessing the storage account. When you create a storage account you are provided with two storage access a Primary and Secondary. These can be access from the portal:

Click on Access Keys and you should see the following:

So why are there two keys? Well, essentially there are two reasons:

To avoiding downtime

You might want to change the access keys on regular basis as per your corporate security policy. However, when you change the access the keys, your cloud services using the storage account will no longer be able to access the storage account. This will lead to a downtime. The resources will be able to access the storage account only after you update the new storage access keys in your configuration file. Hence to avoid this, update the configuration file with the secondary access keys and only then regenerate the primary access key. Once the new primary access key is regenerated you can now use this key to update the configuration file once again.

For temporary sharing of access keys

You might on some occasion want to share your storage access keys with your colleagues instead of sharing the primary access key (which is used in your cloud services), share the secondary key. When you want to revoke the access from that individual, regenerate the secondary key. Once the secondary key is regenerated the old secondary key will no longer be valid.

Shared Access Signatures & Additional Security.

Another method of granting access to Azure Storage is by leveraging the Shared Access Signatures. Using a shared access signature (SAS) is a powerful way to grant limited access to objects in your storage account to other clients, without having to expose your account key. You should use the following link for more information


So how much does all this storage cost? Well, all you need to do is go to the Azure Pricing calculator using the following link:

You are billed for Azure Storage usage based on your storage account. Storage costs are based on the following factors: region/location, account type, storage capacity, replication scheme, storage transactions, and data egress.

  • Region refers to the geographical region in which your account is based.
  • Account type refers to whether you are using a general-purpose storage account or a Blob storage account. With a Blob storage account, the access tier also determines the billing model for the account.
  • Storage capacity refers to how much of your storage account allotment you are using to store data.
  • Replication determines how many copies of your data are maintained at one time, and in what locations.
  • Transactions refer to all read and write operations to Azure Storage.
  • Data egress refers to data transferred out of an Azure region. When the data in your storage account is accessed by an application that is not running in the same region, you are charged for data egress. (For Azure services, you can take steps to group your data and services in the same data centers to reduce or eliminate data egress charges.) See

These basic concepts are ok, however there is more to take into consideration when calculating how much storage is going to ACTUALLY cost. Well the answer is look at the Pricing Calculator. What isn’t explained there is what is a Storage Transaction.

Storage Transactions

It’s considered 1 transaction whenever you touch any component of Azure Storage.

  • Touch means any REST calls or operation including read, write, delete, update.
  • Any Component means any entity inside Blobs, Tables, or Queues.

Here’s a good example based on Azure Diagnostics. Azure Diagnostic enabled for a VM collects diagnostic data from your instances and copies it to Azure Storage. Those diagnostic data (such as log) can help you purpose of monitoring performance. Depending on what you monitor.

Let’s do a quick (rough!) calculation on how much this could cost in a worst case scenario:

5 counters X 12 times X 60 min X 24 hours X 30 days X 100 instances = 259,200,000 transactions

    259,200,000 transactions / 100,000 = 2592

    2592 x £0.002 = £5.184

So all in all not that expensive really and that is a pretty excessive and unrealistic calculation.

When it comes to Understanding Azure Storage Billing – Bandwidth, Transactions, and Capacity then I would recommend this article

I hope this helps with some of the Azure Storage basic concepts.