The name sounds odd, but the idea is simple. Start with the word, then the problem it solves.

What a blob is

The word blob stands for binary large object. It means one file-like chunk of data, treated as a single unit. A photo is a blob. So is a ten gigabyte video, a compressed backup, or a text file full of log lines. Blob Storage does not look inside. It does not care whether the bytes are a picture or a spreadsheet. It simply stores them under a name and returns them exactly as they were saved.

Object storage versus the storage you already know

Most people know two other kinds of storage. A file system, like the folders on a laptop, organizes data into a tree of directories and lets programs edit files in place. A block device, like the disk inside a server, offers raw numbered chunks that an operating system formats and manages. Object storage is a third kind. You put a whole object in, you get a whole object out, and each object is found by name through a web address. You do not mount it like a disk, and you normally replace an object instead of changing a few bytes in the middle. In return you get enormous size, simple web access, built-in copies and low cost.

What problems it solves

Blob Storage was designed for needs that traditional storage handles badly. It stores huge volumes, from a few megabytes to many petabytes, without you planning disk sizes. It delivers files directly to browsers and apps over HTTPS. It keeps several copies in separate places so a broken disk or even a broken building does not lose data. It offers cheap tiers for rarely used data. And it connects to nearly every other Azure service, from analytics engines to backup tools to batch computing.

What it is typically used for

Common uses include serving images, video and downloads to websites and apps, storing backups and disaster recovery copies, keeping logs and sensor data for later analysis, holding the raw data layer for analytics and machine learning, archiving records for legal reasons, and acting as the input and output store for compute services such as Azure Batch. Whenever you see a pipeline where something produces files and something else later consumes them, Blob Storage is very likely in the middle.

Every design choice in Blob Storage answers a pain that earlier systems felt. A short look back makes the present design easy to remember.

The file server years

For decades, companies kept shared files on file servers. Staff mapped a network drive and saw a familiar tree of folders. This worked well for office documents but struggled with scale. A single server has a limit on disks. When it fills up, someone must buy more, copy data across and hope nothing breaks. If the server fails, everyone stops working until it is repaired. Backing it up meant tapes and long nights.

The web changes the shape of data

When the internet exploded, services began storing millions of user photos, videos and documents. Nobody edited these in place. They were uploaded once and read many times by people all over the world. A different design suited that pattern: store each item as a whole object, spread objects across many cheap servers, and keep several copies so that failures stay invisible. Large cloud providers built exactly this, and Azure’s version became what we now call Blob Storage.

A system designed to be strongly consistent

Microsoft has published a technical paper describing the design of the Azure storage system. One notable choice is that it gives strong consistency inside the primary region. That means that once a write is confirmed, any later read returns the new data. Some older object stores were eventually consistent, so a reader could briefly see old data. Strong consistency makes programs simpler, because developers do not need to invent workarounds for stale reads.

From plain storage to a data platform

Over the years Blob Storage gained features that moved it beyond simple file keeping: access tiers for cost, versioning and soft delete for safety, immutability for compliance, event notifications for automation, and a hierarchical namespace for big data analytics. Today it is the base layer on which several other Azure services are built, including Azure Data Lake Storage Gen2, which is Blob Storage with directory features switched on.

Three layers of naming organize everything you store. Once you know them, any Azure storage address becomes readable.

Reading an address

A blob is reached through a web address built from those three names. The pattern is the account name, then the blob service endpoint, then the container, then the blob name. For example, an account called shopmedia with a container called photos and a blob called 2026/summer/beach.jpg lives at an address that begins with https://shopmedia.blob.core.windows.net/photos/ followed by the blob name. Because every account has its own web name, anyone who knows the address and has permission can fetch the file from anywhere.

Folders that are not really folders

In a standard account, the structure is flat. There is only an account, containers, and blobs. A slash in a blob name is just another character. Tools such as Azure Storage Explorer show slashes as folders because it is convenient, and you can list blobs with a given prefix to imitate a folder listing. But there is no real directory object. Renaming a “folder” means copying and deleting every blob whose name begins with that prefix. Chapter thirteen explains how the hierarchical namespace option changes this.

Three kinds of blob

Metadata and index tags

Each blob can carry metadata, which are small name and value pairs stored with it, such as the camera model of a photo or the department that owns a document. Metadata travels with the blob but cannot be searched across the account by itself. For searching, blob index tags exist: up to ten key and value tags per blob that the service indexes, so you can ask “find every blob in this account tagged project equals apollo and status equals final” without listing everything.

Types of storage account

Most people create a standard general-purpose v2 account. It supports all blob types, all access tiers, all redundancy options and most features, and uses magnetic or mixed media tuned for low cost per gigabyte. A premium block blob account uses solid-state drives for much lower and steadier delay, which suits interactive applications, analytics with many small files and machine learning. Premium page blob and premium file share accounts exist for other services. Choose the account type first, because some of it cannot be changed later without copying data.

You never see the machines behind the web address, but understanding their layers explains the guarantees you receive.

flowchart TD
  C["Client app, browser or AzCopy"] -->|"HTTPS request with credentials"| DNS["Account DNS name resolves to a storage stamp"]
  DNS --> FE["Front end layer: authenticate, authorize, route"]
  FE --> PL["Partition layer: object names, tables, transactions, load balancing"]
  PL --> SL["Stream layer: append-only extents stored across disks"]
  SL --> R1["Replica on fault domain 1"]
  SL --> R2["Replica on fault domain 2"]
  SL --> R3["Replica on fault domain 3"]
  PL -.->|"Async copy to paired region if geo-redundant"| SEC["Secondary region"]

Storage stamps

Azure builds storage out of stamps, which are clusters of racks of servers in a data center, each stamp holding many storage accounts. A stamp contains thousands of disks and is designed so that no single rack, power feed or network switch is critical. Your account lives in one stamp at a time, and the service can move accounts between stamps to balance load.

The front end

The first layer your request meets is the front end. It checks who you are, confirms that you are allowed to do what you ask, and finds the right place to send the request. It is stateless, so there can be very many of them and any one can fail without loss.

The partition layer

The partition layer understands objects. It knows which blobs exist, keeps the index from names to data, enforces ordering and transactions, and decides how to divide the account’s data into ranges of names that different servers manage. The key idea is range partitioning: names are sorted, and each server is responsible for a slice of that sorted list. When a slice becomes hot, the layer can split it and give the pieces to different servers. This is the reason blob naming can affect speed, which we revisit in the performance chapter.

The stream layer

The stream layer sits at the bottom. It stores bytes in append-only files, called streams, made of large chunks called extents. Data is never changed in place. New data is appended and old data is later cleaned up. Each extent is stored several times on servers in different fault domains, that is, groups of hardware that can fail together, such as one rack. A write is only confirmed after the required copies are safely written. This is the source of the durability promise. For some redundancy types, cold extents are also stored using erasure coding, which splits data into fragments plus parity so that the original can be rebuilt after losing some fragments, using less space than full copies.

How a write is confirmed

When you upload a block, the front end passes it to the partition layer, which writes it to the stream layer. The stream layer copies the data to its replicas. Only when enough replicas confirm does a success response travel back. For geo-redundant accounts the copy to the second region happens afterward in the background, so the write is already safe in the primary region when you receive your answer.

Chapter four showed the layers. This chapter shows the rules those layers follow so that what you read is exactly what you wrote, even years later.

Why a read returns the newest write

When you commit a blob, the partition layer records the change in an ordered log and the stream layer confirms that the required copies are stored. Only after both steps does the service answer success. Any later request for that blob goes through the same partition server, which knows the newest committed state. This is how read-after-write consistency is delivered: the server that answers reads is the same one that ordered the writes, and it does not answer until the data is safely stored.

Two writers at the same time

If two programs overwrite the same blob without conditions, the service accepts both in the order they arrive, and the last one wins. This is called last writer wins. It is simple, but it can silently discard someone’s work. When that matters, programs send the ETag they last saw with a condition, so the second writer is refused and must read the new content first. Leases are the heavier tool for the same problem.

Checking that bytes are not damaged

Data can be damaged on the way to storage, on disks, or on the way back. Several checks guard against this. An uploader can send a checksum, such as an MD5 or CRC64 value, with each block, and the service refuses the block if the bytes do not match. Downloads can return the stored checksum so the receiving program can compare. Inside the service, stored data carries its own checks, and the published design describes background scanning that reads stored data to detect silent damage, often called bit rot. When a bad copy is found, the system rebuilds it from healthy copies, so you never notice.

Healing after a failure

When a disk, server or rack fails, the extents it held now have fewer copies than required. The stream layer notices and immediately starts making new copies on healthy servers in other fault domains until the target count is restored. This repair is automatic and continuous. For geo-redundant accounts, the second region repairs itself independently. Because the number of copies is restored quickly, the chance that further failures remove every copy before repair is extremely small, and that is what the durability numbers describe.

Splitting and merging partitions

Remember that the partition layer divides names into sorted ranges. A monitoring component watches the load on each range. A range that receives too many requests is split in two and the halves are placed on different servers. Ranges that go quiet can be merged again. This all happens without downtime. It is why most workloads scale smoothly, and also why a sudden spike on one narrow set of names can see brief slowdowns while the split happens.

Cleaning up

Because the stream layer only appends, deleted or replaced data leaves old bytes behind. A background garbage collection process reclaims that space after the data is no longer referenced by a blob, a version, a snapshot or a soft deleted item. This is also why soft deleted data and versions show up in your bill: they are still referenced, so the space cannot be reclaimed.

Choosing a redundancy option is the most important reliability decision you make for a storage account. Each option answers one question: what failure should my data survive?

Durability and availability are different

Durability is the chance that your data is not lost over time. Availability is the chance that you can reach it right now. A vault buried in a mountain is very durable but not very available. Azure expresses durability with “nines”, such as eleven nines, which means a chance of loss so small that if you stored ten million objects you would expect to lose one roughly every ten thousand years. Availability is described in service level agreements and changes with the redundancy option and the access tier.

The options in the primary region

Locally redundant storage, called LRS, keeps three copies inside one data center. It survives disk and rack failures but not a fire or flood affecting that building. It offers at least eleven nines of durability and is the cheapest choice. Zone-redundant storage, called ZRS, keeps copies in three separate availability zones in the same region. Each zone is a distinct building group with independent power, cooling and networking. ZRS survives the loss of an entire zone and offers at least twelve nines of durability.

The options that reach a second region

Geo-redundant storage, called GRS, writes three copies in the primary region as LRS and then copies the data asynchronously to a paired secondary region hundreds of miles away, where it is again kept three times. Geo-zone-redundant storage, called GZRS, combines the two: zone redundancy in the primary region plus a copy to the secondary region. Both offer at least sixteen nines of durability. The read-access variants, RA-GRS and RA-GZRS, additionally let applications read from the secondary endpoint at any time, not only after a failover.

flowchart LR
  subgraph PR["Primary region"]
    Z1["Zone 1 copy"]
    Z2["Zone 2 copy"]
    Z3["Zone 3 copy"]
  end
  subgraph SR["Secondary paired region"]
    L1["Local copy 1"]
    L2["Local copy 2"]
    L3["Local copy 3"]
  end
  W["Client write"] -->|"Synchronous"| Z1
  W -->|"Synchronous"| Z2
  W -->|"Synchronous"| Z3
  Z1 -.->|"Asynchronous geo replication"| L1
  Z2 -.-> L2
  Z3 -.-> L3

Asynchronous means a small gap

The copy to the second region is not instantaneous. Azure states that it typically completes within about fifteen minutes, but it does not promise a guaranteed time. This gap is called the recovery point objective, the amount of recent data you could lose in a disaster. If the primary region fails and you fail over, writes made in the last few minutes may not have reached the secondary. For data where even that is unacceptable, design the application to keep its own record or to write to two places.

Failover

With geo-redundant options, a customer-initiated failover can promote the secondary region to become the new primary. After the switch the account usually becomes locally redundant in its new location until you re-enable geo-replication. Microsoft may also declare a regional disaster and fail over on its own, but you should not rely on that for your own recovery plans. Test your failover procedure before you need it.

Every blob has a life story: it is created, read, sometimes replaced, moved to cheaper storage, and finally deleted. This chapter follows that story step by step.

How a large upload really works

A small file can be sent in a single request. A large file is cut into blocks. The uploader sends each block with its own identifier, and the service stores them as uncommitted blocks, invisible to readers. When all blocks have arrived, the uploader sends a final commit block list request that names the blocks in the order they should be joined. Only then does the blob appear or change, all at once. If the connection breaks halfway, nothing is visible and the uploader resumes by sending only the missing blocks. A block may be up to about four thousand mebibytes and a block blob may contain up to fifty thousand blocks, which gives the maximum size of roughly 190.7 tebibytes.

sequenceDiagram
  participant App as Uploader
  participant Svc as Blob service
  participant Str as Stream layer replicas
  App->>Svc: Put Block 1 with block ID
  Svc->>Str: Write and replicate
  Str-->>Svc: Copies confirmed
  Svc-->>App: 201 Created
  App->>Svc: Put Block 2 to N in parallel
  Svc-->>App: 201 Created for each block
  App->>Svc: Put Block List commit in order
  Svc-->>App: 201 Created and new ETag
  Note over App,Svc: Readers see the blob only after the commit

Reading

A read is a simple web request. You can ask for the whole blob or for a byte range, such as “bytes 1,000,000 to 1,999,999”, which is how video players seek and how download tools resume. Each blob carries an ETag, a short value that changes every time the blob changes. Programs can send a condition such as “give me this only if it has changed since ETag abc” or “replace this only if the ETag is still abc”. That last form, called an optimistic concurrency check, prevents two programs from silently overwriting each other’s work.

Changing a blob

Block blobs are replaced, not edited. To change the middle of a large file you upload new blocks for the changed region and commit a new block list that reuses the old unchanged blocks. This is efficient because the old blocks are not copied again. Append blobs allow new blocks only at the end. Page blobs allow overwriting any 512-byte page, which is why virtual disks use them.

Leases: a polite lock

A lease temporarily gives one client exclusive write and delete rights over a blob or container. A lease can last fifteen to sixty seconds and be renewed, or be infinite. Distributed programs use leases to elect a single worker for a job, much like putting a “do not disturb” sign on a door. If the holder crashes, a timed lease expires and another worker can take over.

Copy and move

The service can copy a blob from one place to another on its own, without the data passing through your computer, even across accounts. There is no real “move” in a flat namespace: moving means copying then deleting. In accounts with a hierarchical namespace, rename is a single fast operation, as explained later.

Events and automation

Blob Storage can publish events when blobs are created or deleted, using Azure Event Grid. An event can trigger a function that resizes a new image, a scan that checks a new document for malware, or a Batch job that processes a new data file. This turns storage from a passive shelf into the starting point of workflows, without polling.

Not all data is equally valuable at every moment. Access tiers let you match price to how often data is read.

The four tiers

The Hot tier has the highest storage price per gigabyte but the lowest cost to read and write. It suits data in active use. The Cool tier lowers the storage price and raises access costs, and expects data to be kept for at least thirty days. The Cold tier is cheaper again with a ninety day minimum. The Archive tier is the cheapest of all, with a one hundred eighty day minimum, but the data is stored offline. You cannot read an archived blob directly. First you must rehydrate it, which means moving it back to an online tier, and this can take hours.

Early deletion and the minimum stay

If you move or delete a blob before its minimum stay has passed, Azure charges you as if it had stayed the full period. This early deletion charge surprises many teams that move data to Cool or Archive and then delete it a week later. Choose a cold tier only for data that will really stay.

Rehydration

To read an archived blob you either change its tier to an online tier, or copy it to a new blob in an online tier. Standard priority rehydration may take up to fifteen hours. High priority can complete in under an hour for small blobs, at higher cost. While waiting, the blob shows a pending state. Because of this delay, Archive is for data you hope you never need quickly, such as legal records and old backups.

Account default tier and per-blob tier

An account has a default access tier, Hot or Cool, that new blobs inherit. You can also set a tier on individual blobs. A well designed system sets the right tier when it writes the data and then relies on rules to move it later.

Lifecycle management policies

A lifecycle management policy is a set of rules, written once per account, that Azure applies automatically. A rule picks blobs by container, name prefix or index tag, and then acts on age. An example: “move to Cool after thirty days without modification, to Cold after ninety, to Archive after one hundred eighty, and delete after seven years.” The rules run on a daily schedule, so changes are not instant. Rules can be based on creation time, last modified time or, if you enable tracking, last access time, which is useful for data whose age does not predict its use.

flowchart LR
  N["New blob in Hot"] -->|"30 days since change"| CO["Cool"]
  CO -->|"90 days"| CD["Cold"]
  CD -->|"180 days"| AR["Archive offline"]
  AR -->|"7 years"| DEL["Deleted by policy"]
  AR -.->|"Rehydrate on demand"| CO
  CO -.->|"Read again if last access tracking is on"| N

A worked cost example

Prices change by region and over time, so the numbers below are round, made-up values to show the shape of the saving. Suppose a company keeps 100 terabytes of log files. Hot costs 20 dollars per terabyte per month, Cool 10, Cold 4 and Archive 1. If all 100 terabytes sit in Hot, the monthly bill is 2,000 dollars. With a lifecycle policy, the age profile settles into 10 terabytes Hot, 20 Cool, 30 Cold and 40 Archive. The bill becomes 200 plus 200 plus 120 plus 40, which is 560 dollars, a saving of 72 percent. The saving is real only if reads of the colder data are rare, since each read in a cold tier costs more.

Redundancy protects against broken hardware. These features protect against human error, bad code and malicious attackers.

Immutable storage: write once, read many

Some rules say data must not change or disappear for a fixed time, for example financial records or medical images. Immutable storage provides this, sometimes called WORM, short for write once, read many. A time-based retention policy locks blobs against modification and deletion until the period ends. A legal hold locks blobs until the hold is explicitly removed, which suits investigations. After a retention policy is locked, even the account owner cannot shorten it. This also protects against ransomware, because an attacker who steals credentials still cannot delete or encrypt locked data.

Which feature answers which risk?

Costs of protection

Versions, snapshots and soft deleted data are stored data, and you pay for them. A file overwritten every minute with versioning on produces a thousand-plus versions a day. Combine versioning with a lifecycle rule that deletes old versions after a sensible time, and monitor the storage taken by versions.

Blob Storage scales a long way, but it does not scale magically. Speed depends on how you upload, how you name things and where your compute runs.

What limits speed

Three things limit a transfer: the width of the pipe between you and the service, how many requests run at once, and how the service spreads your load. Each account has scalability targets for requests per second and for data in and out per second, and these differ by region and account type. When you exceed a target, the service replies with a “server busy” or timeout message to tell you to slow down. Well written clients react by waiting a little and trying again, using longer pauses each time, which is called exponential backoff. The official client libraries do this for you.

Parallelism is the main lever

One connection never fills a fast link. Upload tools split a file into blocks and send many in parallel. A worked example helps. A one tebibyte file uploaded in blocks of 100 mebibytes needs about 10,486 blocks, well under the limit of 50,000. On a 1 gigabit per second link, which moves about 119 mebibytes per second at best, the transfer needs roughly 8,800 seconds, a little over two and a half hours. No amount of software tricks changes that ceiling. Only a fatter pipe, such as a 10 gigabit connection or a private express route, or sending the data on a physical device, makes it faster.

Naming and partitions

Remember that the partition layer divides names into sorted ranges. If thousands of new blobs per second all begin with the current timestamp, such as 2026-10-30T14-36-01, every write lands in the same latest range and one server does the work. Spreading load is easier when names begin with a short varied prefix, such as a hash of the identifier, before the date. The service also detects hot ranges and splits them automatically, so this matters mostly for very high request rates. For ordinary workloads, a clear naming scheme that helps humans find things is more valuable than clever hashing.

Put compute near data

Distance adds delay and, between regions, costs money. Run processing in the same region as the account. For global readers, put a content delivery network or Azure Front Door in front of public blobs so popular files are cached near users. For workloads that need predictable low delay, a premium block blob account backed by solid-state drives gives faster and steadier responses.

Many small files versus few large files

Every request has overhead, so ten million tiny files are slower and costlier to process than a few thousand big ones. Analytics systems prefer file sizes of tens to hundreds of mebibytes. If your source produces tiny files, merge them with a compaction job.

A storage account is reachable from the internet by design, so security is built in layers. Each layer assumes the one outside it might fail.

Layer 1: who are you? Authentication and authorization

There are three common ways to prove who is calling. The recommended way is Microsoft Entra ID. A person, application or Azure resource signs in, receives a token, and Azure role-based access control decides what they may do. Built-in roles such as Storage Blob Data Reader, Storage Blob Data Contributor and Storage Blob Data Owner grant rights to blob data at a chosen scope: account, container or sometimes narrower. The second way is the shared key, one of two long secrets per account that grant complete control. The third is a shared access signature, covered next.

Shared access signatures

A shared access signature, often called a SAS, is a web address with a signed token attached that grants limited rights for a limited time. For example, “read this one blob until midnight from this network range”. It lets you give a customer a download link without giving them an account. There are three kinds. An account SAS and a service SAS are signed with the account key. A user delegation SAS is signed with Entra ID credentials and is safer, because it does not need the account key and can be revoked by removing the rights of the signer. Keep SAS lifetimes short, give the least rights needed, and tie them to a stored access policy when you may need to cancel them early.

Layer 2: anonymous access

A container can be set to allow public reads without any credentials, which is how some websites serve images. This is dangerous when done by accident. An account-level switch can forbid anonymous access for every container at once, and it is wise to leave it off unless you have a deliberate public hosting need.

Layer 3: encryption

Data is always encrypted at rest with 256-bit AES before it reaches disks, and you cannot turn this off. By default Microsoft manages the keys. You may instead use customer-managed keys stored in Azure Key Vault or a managed hardware module, so you control rotation and can revoke access to the data by disabling the key. Encryption scopes let different containers or blobs use different keys. For very sensitive cases, infrastructure encryption adds a second layer using a different key. Data in motion is protected by TLS, and you can require HTTPS only and set a minimum TLS version for the account.

Layer 4: immutability and locks

As chapter nine explained, retention policies prevent changes. A separate Azure resource lock can stop someone deleting the whole storage account, which would otherwise take every container with it.

Layer 5: detection

Microsoft Defender for Storage can watch for unusual access patterns, such as downloads from an odd location, and can scan uploaded blobs for malware. Alerts feed into your security team’s tools. Detection does not prevent harm by itself, but it shortens the time between an attack and a response.

By default a storage account answers requests from anywhere on the internet that holds valid credentials. Networking features let you narrow that to only the paths you want.

The firewall and virtual network rules

The storage firewall can deny all traffic except from chosen public IP ranges and chosen subnets of your Azure virtual networks. Service endpoints let a subnet reach the account over Azure’s backbone with the subnet’s identity attached, though the account still has a public address. A short list of trusted Azure services, such as backup and monitoring, can be allowed to bypass the firewall when you permit it.

Private endpoints

A private endpoint gives the storage account a private IP address inside your virtual network. Applications reach it by that private address, and the public endpoint can then be turned off entirely. Traffic never crosses the public internet, and on-premises networks connected through a VPN or ExpressRoute can reach it too. Private endpoints are the standard choice for sensitive data. They need matching private DNS settings so that the account name resolves to the private address.

flowchart LR
  subgraph VN["Your virtual network"]
    APP["Application servers"]
    PE["Private endpoint with private IP"]
  end
  ONP["On premises network via VPN or ExpressRoute"] --> PE
  APP --> PE
  PE --> SA["Storage account with public access disabled"]
  INT["Public internet"] -.->|"Blocked by firewall"| SA

Ways to reach blobs

Serving websites and public files

Blob Storage can host a static website, meaning pages, images and scripts that need no server-side code. When you enable this feature, a special container named $web is served from a website address. For HTTPS on your own domain name and for caching near visitors, place Azure Front Door or a content delivery network in front. This combination is cheap, scales without effort and has very little to patch.

Data leaving Azure

Bringing data in is free. Sending data out to the internet, or across regions, is billed per gigabyte. A popular file served directly from storage to millions of visitors can create a large egress bill. A cache in front of storage cuts both the bill and the delay.

Big data tools love folders. Azure’s answer is to add real directories to Blob Storage with one account setting.

The problem with flat names for analytics

An analytics job often writes its results into a temporary folder and then renames that folder to the final name when it succeeds. With a flat namespace, “rename a folder” means copying and deleting every blob under the prefix, which is slow and not atomic. A failure in the middle leaves a mess. Deleting a folder with a million files is as slow as deleting a million objects.

What the hierarchical namespace adds

When you enable the hierarchical namespace on a general-purpose v2 or premium block blob account, the account becomes an Azure Data Lake Storage Gen2 account. Directories become real objects. Renaming or deleting a directory is a single fast, atomic metadata operation, regardless of how many files it holds. You also gain POSIX-style permissions, called access control lists, which allow a folder to be readable by one group and writable by another, down to individual files. The same data is still accessible through Blob endpoints, so many tools work unchanged.

A typical data lake layout

Teams commonly arrange a lake in zones. A raw zone keeps data exactly as received and is never edited. A cleaned zone holds validated, standardized data. A curated zone holds data modeled for reports and machine learning. Access control lists give data engineers write rights on raw and cleaned zones and give analysts only read rights on the curated zone.

A storage account that nobody watches is a risk to the budget and to security. Four sources give a full picture.

Metrics in Azure Monitor

The service publishes numbers about the account with no setup. The most useful ones are the number of transactions, bytes in and out, availability, end-to-end latency and server latency, and the capacity used per tier. Comparing end-to-end latency with server latency tells you whether delay is inside the service or on the network and in your client. You can graph these, put them on dashboards and create alerts, for example when the share of failed requests climbs above one percent.

Diagnostic logs

Resource logs record each read, write and delete request: who called, from which address, with what status code and how long it took. They can be sent to Log Analytics for queries, to a storage account for long retention, or to an event hub for external tools. These logs are essential for security investigations and for answering “who deleted this container?”

Inventory and capacity reports

A blob inventory policy produces scheduled reports listing every blob with its size, tier, last modified time and tags. For an account with billions of blobs, this is far cheaper and faster than listing blobs through the API. Cost teams use it to find forgotten data and to design lifecycle rules.

Events and Defender

Event Grid events tell you in near real time when blobs are created or removed, which is also a lightweight way to count new data. Defender for Storage adds security alerts about suspicious activity and uploaded malware.

The monthly invoice is built from a few separate meters. Knowing them lets you predict and control cost instead of being surprised.

Where surprises come from

Teams usually overspend for one of five reasons. They keep everything in Hot forever. They store tiny files and pay mostly for operations. They leave versions and soft deleted data growing. They read cold data too often and pay retrieval fees. Or they serve large public files directly and pay heavy egress. Each reason has a direct fix: lifecycle rules, combining files, version expiry, better tier choice and caching.

A second worked example: operations

Suppose an app uploads 20 million small log files each month and each upload is one write operation. If writes cost, for illustration, 0.05 dollars per ten thousand, the upload bill is 20,000,000 divided by 10,000, which is 2,000 units, times 0.05, which is 100 dollars. Now batch those logs into hourly bundles of about 1,000 lines. The write count falls to 20,000, a thousand times fewer, and the operations bill drops to about 10 cents. The data volume is the same, but the cost almost vanishes. The lesson is that for small objects, operations can cost more than capacity.

Savings tools

Reserved capacity lets you commit to a fixed amount of storage for one or three years at a discount, suited to steady baseline data. Lifecycle policies reduce cost with no commitment. Choosing locally redundant storage for rebuildable data and zone or geo redundancy only where required also trims the bill. Azure Cost Management can break spending down by account and tag so owners see their own costs.

A balanced view helps you pick Blob Storage for the right jobs and pair it with something else for the wrong ones.

Choosing between Azure storage services

The three main trade-offs

Cost versus access speed. Colder tiers are cheaper to hold and costlier to read. Durability versus price. More redundancy costs more, so match it to how painful loss would be. Simplicity versus control. Public containers and keys are easy but weak; private endpoints, Entra roles and policies take effort but protect you when something goes wrong. Make each choice per dataset, not once for the whole company.

A small set of shapes appears again and again in systems that use Blob Storage well.

Patterns that work

flowchart LR
  U["User browser"] -->|"1 Ask for upload permission"| API["Your web API"]
  API -->|"2 Create short user delegation SAS"| U
  U -->|"3 Upload directly"| BLOB["Blob container: incoming"]
  BLOB -->|"4 BlobCreated event"| EG["Event Grid"]
  EG --> FN["Function: scan and resize"]
  FN -->|"5 Write result"| OUT["Blob container: processed"]
  OUT --> CDN["CDN or Front Door"]
  CDN --> U

Anti-patterns to avoid

These habits are cheap to adopt and prevent most of the painful stories teams tell afterward.

Common mistakes

Storage fails in two ways: the service has a problem, or people and programs cause one. Both need a plan.

Recovery objectives in plain words

Two numbers guide the plan. The recovery point objective says how much recent data you can afford to lose, measured in time. The recovery time objective says how long you can be without the data. Geo-replication usually gives a point objective of minutes and a time objective of hours if you fail over by hand. Soft delete gives a near-zero point objective for accidental deletes. Immutable backups in another account give a long time objective but strong protection against attackers. Write the objectives down for each dataset and choose features that meet them.

A calm routine when something looks wrong

Five common workloads show how the earlier ideas combine. Figures are illustrative.

Short answers to the questions people ask most when they start with Blob Storage.