Blob Storage is Azure’s service for keeping huge amounts of unstructured data in the cloud.

The word “blob” stands for Binary Large Object. It simply means “a file-like chunk of data” such as a photo, a video, a PDF, a backup file, a log file or a spreadsheet. Computers do not need to understand what is inside the blob. They just store the bytes and give them back when asked.

Azure Blob Storage is a managed service. “Managed” means Microsoft owns the hardware, replaces broken disks, applies updates and keeps the whole system running. You only decide what to store, who may see it and how long to keep it. This is very different from buying your own servers, where you must plan capacity, fix failures and pay for unused disks.

The data it stores is called unstructured data. Unstructured means the data does not fit neatly into rows and columns like a database table. A holiday photo has no columns. A security camera video has no rows. Blob Storage was built for exactly this kind of content, and it can hold from a few kilobytes to many terabytes in a single file.

The six words you will hear everywhere

To understand a tool, first understand the pain it removes.

Before cloud storage, a company that wanted to keep customer documents bought a file server. Someone had to guess how much space would be needed in three years, order the disks, install them, back them up and replace them when they broke. If the guess was too small, the server filled up and applications crashed. If the guess was too large, money sat idle in empty disks.

The internet made the problem bigger. Websites now serve millions of images. Phones upload videos every second. Machines write logs around the clock. Companies keep years of data to train machine learning models. No single server can hold or serve this much content reliably, and a normal file system slows down when it holds billions of files.

Blob Storage solves this by spreading data across a huge pool of machines, copying it for safety and exposing it through a simple web interface. You send a request over HTTPS to put a file or get a file. Applications written in any language can do this, and so can people using a web portal or command-line tools.

The problems it solves

Nothing can be stored until a storage account exists, so it is the first building block to understand.

A storage account is like the plot of land on which you build your warehouse. It is the boundary that holds your settings, your keys, your billing and your data. Azure gives each account a globally unique name that is between 3 and 24 characters long and uses only lowercase letters and numbers. Because the name becomes part of a web address, nobody else in the world can use the same name.

When you create an account you make a few important choices. These choices are hard or impossible to change later, so they deserve a little thought.

One account, several services

A general-purpose storage account can offer more than blobs. Each service gets its own web address under the same account name. This is why one account name can appear in several different addresses.

Inside the account, data follows a simple three-level pattern: account, container, blob.

A container is a named group of blobs. You might have one container called “profile-photos”, another called “invoices” and another called “nightly-backups”. Containers are useful because you can apply rules, such as who may read, at the container level. A storage account can hold an unlimited number of containers, and a container can hold an unlimited number of blobs, within the account’s total capacity limit.

Each blob has a name, and the full address of a blob combines the account, the container and the blob name. If your account is called “shopdata”, your container is “images” and your blob is “summer/shoes.jpg”, the web address ends up looking like the account’s blob endpoint followed by the container name and then the blob name.

Folders that are not really folders

Standard blob storage has a flat structure. There are no true folders inside a container. When you name a blob “summer/shoes.jpg”, the slash is just a character in the name. Tools and the Azure portal cleverly show these names as if they were folders, which makes browsing friendly. These are called virtual directories.

If you want real folders with real rename and permission behaviour, you can switch on a feature called hierarchical namespace. This turns the account into the foundation for Azure Data Lake Storage Gen2. In that mode, folders are real objects, renaming a folder is a single fast operation, and permissions can be set on folders. Big data tools love this feature, but it must be chosen when the account is created.

Extra information attached to blobs

Not every file is used in the same way, so Azure offers three blob types, each tuned for a different job.

The blob type is chosen when the blob is first created and cannot be changed afterwards. Choosing correctly matters, but for most beginners the answer is simply “block blob”.

How a block blob is really built

When you upload a large file, the client does not push it as one gigantic piece. It cuts the file into blocks, uploads the blocks in parallel, and then sends a final instruction called a block list that says “these blocks, in this order, make my blob”. Only after this commit step does the blob become visible to readers.

Data gets colder with age, and the storage price should follow.

Think about your own belongings. The keys you use daily sit by the door. Winter clothes sit in a cupboard. Old school certificates sit in a box in the attic. Keeping everything by the door would be expensive in space, and keeping your keys in the attic would be painful. Azure access tiers apply the same idea to data.

Each tier balances two costs. Storing data costs money every month, and reading data costs money every time. A hot tier has a higher monthly storage price but cheap reads. Colder tiers have lower monthly storage prices but more expensive reads and a minimum time you are expected to keep the data.

The Archive tier works differently

Hot, cool and cold blobs can be read immediately. An archive blob cannot. Before you can read it you must rehydrate it, which means moving it back to an online tier. This can take hours. A standard rehydration may take up to around fifteen hours, while a high-priority request can finish faster for smaller blobs but costs more.

The account has a default tier of hot or cool, and individual blobs can be set to any tier on their own. Premium accounts are a separate case. They keep data on solid-state drives, have no tiers, and are designed for workloads that need very fast, steady response times.

Hardware breaks, power fails and sometimes whole buildings go offline, so Azure keeps several copies of everything.

Redundancy means keeping extra copies of your data so that one failure does not cause a loss. Durability is how unlikely it is that data is lost over a year. Azure describes durability in “nines”. Eleven nines means a loss chance of about one in a hundred billion per object per year. You pick the redundancy level when creating the account, and more protection costs more money.

flowchart LR
  A["Your Application"] --> B["Primary Region"]
  B --> C["Zone 1 Copy"]
  B --> D["Zone 2 Copy"]
  B --> E["Zone 3 Copy"]
  B -. "asynchronous copy" .-> F["Secondary Region"]
  F --> G["Three local copies"]
        

Read access to the second region

With plain geo-redundant options the second region is only a safety net and is used after Microsoft or you trigger a failover. Read-access variants, called RA-GRS and RA-GZRS, let your application read from the secondary region at any time. This helps with availability, but remember that the copy to the secondary region is asynchronous. It may lag slightly behind, so recent writes might not be there yet.

You never see it, but a carefully layered system sits behind every upload and download.

Behind the friendly web address, Azure Storage is built in layers. Each layer has one job, and splitting jobs like this lets the system grow enormously without becoming confusing. Microsoft has published research about this design, and the key ideas are easy to grasp.

flowchart TD
  U["Client Request over HTTPS"] --> F["Front-end Layer: authenticate and route"]
  F --> P["Partition Layer: index and balance"]
  P --> S["Stream Layer: write and replicate bytes"]
  S --> D1["Disk Copy 1"]
  S --> D2["Disk Copy 2"]
  S --> D3["Disk Copy 3"]
        

Strong consistency

A request is only reported as successful after the data has been safely stored in all the required copies. Because of this, Blob Storage offers strong consistency within the primary region. Once your upload says “done”, any reader who asks for the blob afterwards sees the new version. You do not need to wait and hope that the change has spread.

Why name matters for speed

The partition layer divides the namespace into ranges based on the full path of the blob. Blobs with names that are close together alphabetically tend to be handled by the same server. This is the reason that naming patterns affect performance, a topic we revisit later when we discuss scaling.

Follow one photo from the moment it is uploaded until it is finally deleted.

sequenceDiagram
  participant App as Application
  participant Auth as Microsoft Entra ID
  participant Blob as Blob Service
  participant Disks as Storage Copies
  App->>Auth: Ask for an access token
  Auth-->>App: Token granted
  App->>Blob: Upload blocks with token
  Blob->>Disks: Write and replicate blocks
  Disks-->>Blob: All copies confirmed
  App->>Blob: Commit block list
  Blob-->>App: Success with ETag
        

Reading data back

A read request travels through the same front-end layer, which verifies permission. The blob is then located and streamed back. A client can ask for only part of a blob, called a range request. This is how video players jump to the middle of a movie without downloading everything first.

Security in Blob Storage works in layers, so that a single mistake does not expose everything.

Who are you? Authentication choices

What may you do? Authorisation

Role-based access control, called RBAC, assigns roles such as Reader or Contributor to identities. Roles for blob data include one that can read, one that can write and one that can own. Roles can be attached to the whole account, a single container or an individual resource, which lets you follow the rule of least privilege: give each person or app only the access it truly needs.

Protecting the data itself

All data is encrypted at rest automatically with strong 256-bit AES encryption, and this cannot be turned off. By default Microsoft manages the keys, but you can bring your own keys stored in Azure Key Vault if your rules demand it. Data in transit is protected by requiring HTTPS, and you can insist on a modern minimum version of TLS.

Controlling the network door

Firewall rules can limit access to chosen internet addresses or virtual networks. Private endpoints go further by giving the storage account a private address inside your own network, so traffic never crosses the public internet. Many organisations combine a private endpoint with a firewall that denies everything else.

Redundancy protects against hardware failure, but it does not protect against human mistakes, because a deleted blob is deleted in every copy.

Imagine an employee runs a clean-up and accidentally removes a container of customer contracts. All three copies disappear together, because the system faithfully obeyed the request. To guard against this, Azure offers several features that act like an undo button, a time machine or a locked glass case.

Cloud storage is cheap per gigabyte, but large volumes and bad habits can still produce surprising bills.

What you are billed for

Lifecycle management rules

Instead of moving blobs by hand, you write rules that Azure applies automatically. A rule says things like “if a blob has not been modified for 30 days, move it to cool; after 180 days move it to archive; after seven years delete it”. Rules can match blobs by container, name prefix or index tag. The platform evaluates them roughly once a day, so changes are not instant.

flowchart LR
  N["New blob: Hot"] -->|"30 days unused"| C["Cool"]
  C -->|"90 days unused"| K["Cold"]
  K -->|"180 days unused"| A["Archive"]
  A -->|"7 years passed"| X["Deleted"]
        

Other money-saving habits

• Reserved capacity — commit to a fixed amount of storage for one or three years in return for a discount.
• Compression — compress logs and text before upload to shrink both storage and transfer cost.
• Clean-up — delete abandoned test containers, old snapshots and uncommitted blocks.
• Right redundancy — do not pay for geo copies of data that can easily be recreated.

You cannot fix or protect what you cannot see.

Azure Monitor collects information about your storage account without extra setup. This information falls into three groups, and together they answer three questions: “how is it performing?”, “who did what?” and “what is inside?”

Helpful extras

Blob Storage scales to enormous sizes, but a few habits help you get its full speed.

Each storage account has targets for how many requests and how much data per second it can handle. These targets are very high, yet they are not infinite. When an application sends more work than a partition can handle, Azure replies with a “server busy” message. This is called throttling, and it is a polite way of saying “slow down for a moment”.

Hot spots and naming

Remember that blobs with similar names are grouped together. If every blob name begins with a timestamp, such as the date and time, then all the new traffic lands on the same small range, like everyone rushing through a single door of a stadium. Adding a short random or hashed prefix to names spreads the work over many doors and keeps performance smooth.

Experienced engineers keep returning to a handful of proven ways of using blobs.

flowchart LR
  U["User Browser"] -->|"1 asks for permission"| W["Web Application"]
  W -->|"2 returns short-lived link"| U
  U -->|"3 uploads file directly"| B["Blob Storage"]
  B -->|"4 blob created event"| E["Event Service"]
  E -->|"5 triggers"| F["Processing Function"]
  F -->|"6 saves result"| B
        

Blob Storage quietly powers many things you use every day.

These are tempting shortcuts that regularly cause leaks, outages or surprise bills.

A short checklist you can follow when setting up a new account.

No. A database is built to search and combine structured records quickly. Blob Storage is built to hold whole objects cheaply and durably. Many systems use both: files in blobs, and a database holding the details and the file addresses.

Azure Files presents a shared network drive that computers can open like a normal folder. Blob Storage is accessed through web requests and is better for massive, cloud-native workloads. Choose Files when software expects a classic file share.

You can replace a blob entirely, change selected blocks of a block blob, or change its properties and tier. You cannot open it and edit a few bytes inside like a text file on your laptop. Immutable storage can also forbid any change.

With zone-redundant storage, copies sit in other independent buildings in the same region and the service keeps running. With geo options, a copy also exists in a distant region for a regional disaster.

Rehydration takes hours. Standard priority may take up to roughly fifteen hours, and high priority can be faster for small blobs at an extra price. Plan ahead if you will need that data.

Yes. Data is encrypted at rest automatically and sent over encrypted connections. You can choose to manage your own encryption keys if your organisation requires it.

Common causes are lots of small operations, large downloads leaving Azure, many old versions or snapshots, early deletion charges and geo replication. Check the cost analysis report and the blob inventory to find the biggest contributors.

Yes. Create a signed link with only read permission and a short expiry. Prefer the user delegation type, which does not depend on the account key.

Not in the usual sense. Capacity grows on demand. Accounts do have large upper limits, which can be raised through a request if you reach them, so very large organisations simply spread data across accounts.

Data Lake Storage Gen2 is Blob Storage with hierarchical namespace turned on. It adds real folders, fast folder operations and folder-level permissions, which analytics tools find very useful.

Azure Blob Storage is the cloud’s answer to a simple need: keep any amount of file-like data safely, cheaply and within reach. You create a storage account, organise data into containers, choose a blob type and tier, and pick how many copies to keep. Behind the scenes, layered machinery spreads and replicates your bytes, while security, protection, lifecycle and monitoring features let you run the service responsibly. Learn these building blocks, avoid the common traps, and you can confidently design storage for everything from a small website to a global data platform.