Blob Storage is Azure’s object storage service for huge amounts of unstructured data such as images, videos, documents, logs, backups and data lake files.

The problem it solves

Applications create enormous amounts of data that does not fit neatly into tables. A photo sharing site stores millions of pictures. A hospital stores scans. A factory writes endless log files. A company keeps years of backups. This kind of data is called unstructured because it has no fixed rows and columns. It just needs to be stored cheaply, found quickly when needed, protected from loss and shared safely with the right people.

Buying and running your own disks and file servers for this is painful. You must guess how much space you will need, replace failed drives, copy data to a second building in case of fire, and rebuild everything when you outgrow the machines. Blob Storage removes those chores. You put objects in, you get objects back out, and Azure handles the shelves, the spare copies and the repairs.

What Blob Storage actually is

The word blob stands for binary large object. It simply means a file of any kind: text, picture, video, database backup or anything else. Blob Storage is reached over the web using standard HTTP and HTTPS, through client libraries, command-line tools or the Azure portal. It can also be reached through the SFTP protocol and, for some account setups, mounted as a file system using NFS 3.0. Applications anywhere in the world can read and write objects as long as they have permission.

Where Blob Storage fits among Azure storage choices

Who looks after what

Good fits and weaker fits

Blob Storage has a short vocabulary, and everything else in this guide is built from it.

The three-level hierarchy

Everything in Blob Storage sits inside three levels. At the top is the storage account, which gives you a unique name and web address. Inside the account are containers, which group blobs together. Inside containers are the blobs themselves. An address to a single object therefore reads as account name, then container name, then blob name.

The vocabulary

Flat storage with folder illusions

Blob Storage is essentially flat. A container holds a long list of blobs, and a name such as a path with slashes only looks like folders. This matters because renaming a folder in this model means copying and deleting every blob underneath it. The hierarchical namespace option, used by Data Lake Storage, adds real directories so renames and permissions on folders are quick and natural.

Access methods

Behind a simple web address sits a layered system built to stay consistent, durable and fast at huge scale.

The layers in plain words

When you read or write a blob, your request passes through three conceptual layers. A front-end layer receives the request, checks who you are, and decides which part of the system should handle it. A partition layer keeps track of which objects live where, spreads the load evenly and enforces rules such as ordering and consistency. A stream layer, at the bottom, writes the actual bytes to disks across many servers and keeps the required number of copies in the right places.

flowchart TD
  C["Your application or user"] --> DNS["Account endpoint name"]
  DNS --> FE["Front-end layer: authentication, authorization, routing"]
  FE --> PL["Partition layer: object index, load balancing, consistency"]
  PL --> SL["Stream layer: stores bytes on many disks and servers"]
  SL --> R1["Copy in required location 1"]
  SL --> R2["Copy in required location 2"]
  SL --> R3["Copy in required location 3"]
  PL -.->|"asynchronous geo copy when enabled"| SEC["Secondary region"]
        

Strong consistency

Blob Storage is strongly consistent. After a write is acknowledged as successful, any later read sees that data. You will not read a stale older version just because a replica was slow to update. This makes it far easier to build correct applications, because you can trust that a completed upload is really there.

Partitions and why they matter

The partition layer divides the namespace into ranges of blob names, so different servers can serve different ranges in parallel. If a lot of traffic hits a narrow range of names, one server becomes busy while others sit idle. When a range is overloaded the service may reply that it is busy, and it automatically rebalances over time. Naming patterns that spread traffic across ranges perform better, which we revisit in the performance chapter.

Components you will meet

Management plane versus data plane

This distinction trips up many teams. Being allowed to create or delete a storage account is a management right. Being allowed to read or write blobs is a data right. A person can hold one without the other. A secure design grants data rights narrowly and keeps management rights to the small team that really needs them.

Blob Storage offers three kinds of blobs, each designed for a different way of writing data.

Block blobs: the everyday choice

A block blob is made of blocks that are uploaded separately and then committed together as one object. This design lets large files be uploaded in parallel pieces, retried piece by piece, and assembled at the end. A single block blob can reach about 190.7 tebibytes, built from up to 50,000 blocks of up to 4,000 mebibytes each. Block blobs are the right choice for documents, images, videos, backups and nearly all analytics data.

Append blobs: built for logs

An append blob is block-based but only allows adding new blocks to the end. You cannot change earlier blocks. Each appended block can be up to 4 mebibytes, and an append blob can hold up to 50,000 blocks, which is about 195 gibibytes. This makes append blobs perfect for log files and audit trails, where records are only ever added and never edited.

Page blobs: random access for disks

A page blob is a collection of fixed-size pages that can be read and written at any position, up to 8 tebibytes. Page blobs underpin virtual hard disk files and disks for virtual machines. Most application teams never create page blobs directly. They are also not supported when the hierarchical namespace option is enabled.

Naming and addressing facts

Some choices are made when you create a storage account and are hard to change later, so they deserve early attention.

Account types

Standard or premium

Hierarchical namespace: turning Blob Storage into a data lake

Enabling the hierarchical namespace gives the account real directories. Renaming or deleting a directory becomes a single fast operation instead of one operation per blob, and you can set permissions on folders and files using familiar access control lists. This is the foundation of Azure Data Lake Storage, and it suits analytics platforms that treat the store like a big file system. The choice is made when the account is created, and it changes what features are available. Features such as blob versioning, snapshots and point-in-time restore are not available on such accounts, while soft delete and object replication are.

SFTP and NFS options

Two more options are chosen at account setup. SFTP support lets partners and older tools upload using the secure file transfer protocol, with local users and permissions. NFS 3.0 lets Linux clients mount a container as a file system. Both bring extra requirements, such as the hierarchical namespace and particular networking rules, and both can increase cost, so enable them only for a clear reason.

One account or many

A single storage account has shared limits for total capacity, request rates and bandwidth, plus shared settings for networking and redundancy. Teams often use separate accounts for different environments, for data with different compliance or network rules, and for workloads with very different performance needs. Too many accounts add management work, while too few mix concerns and create noisy-neighbor problems.

Not all data is used equally, and tiers let you pay less for data you touch rarely.

The idea behind tiers

Most data has a life story. A new photo is viewed constantly for a few days, occasionally for a few months, and almost never after a year. Paying the highest storage price for it forever is wasteful. Blob Storage lets you move data between four tiers. The cooler the tier, the lower the cost to store data and the higher the cost to read it.

The four tiers

flowchart LR
  N["New data arrives"] --> H["Hot tier: frequent use"]
  H -->|"not touched for a while"| CO["Cool tier"]
  CO -->|"rarely touched"| CD["Cold tier"]
  CD -->|"kept only for retention"| AR["Archive tier: offline"]
  AR -->|"needed again: rehydrate, takes hours"| H
  AR -->|"retention ends"| DEL["Delete"]
        

Cost behavior in one sentence each

Early deletion made concrete

Suppose a blob sits in the cool tier and is deleted after twenty-one days. You are still billed for the nine days that remain of the thirty-day minimum. Suppose a blob sits in archive and is moved to hot after forty-five days. You are billed for the remaining one hundred thirty-five days of the one hundred eighty. Rewriting a blob also counts as removing the old one, so frequent overwrites in cool or archive tiers are an expensive habit. If soft delete is enabled, the early-deletion charge waits until the soft delete retention period has expired.

The archive tier: cheap but offline

Archived blobs cannot be read or modified. Only their metadata and tags remain accessible. To use the data you must rehydrate it, which means moving it back to hot, cool or cold. Rehydration can take up to about fifteen hours, and you can choose a standard or a high priority option to trade waiting time against cost. Archive is not available for every redundancy option, and snapshots are not supported on archived blobs. Lifecycle policies can move data into archive but cannot rehydrate it.

Account default tier and blob-level tier

The storage account has a default tier of hot, cool or cold, and general-purpose v2 accounts start with hot. Archive cannot be the account default. A blob with no tier of its own simply inherits the account default and appears as an inferred tier. You can also set a tier on each blob, at upload or later. Changing the account default to a cooler tier causes write charges for the blobs that inherit it, and changing to a warmer tier causes read and retrieval charges. Treat a default change as a bulk operation with a bill attached.

Azure always keeps multiple copies of your data. You choose how far apart those copies live.

Why redundancy exists

Disks fail, racks lose power, buildings flood and sometimes whole regions have trouble. To survive each kind of event, Azure keeps several copies of every object. The more widely the copies are spread, the more events you survive, and the more you pay. Redundancy is a chosen level of protection, not a feature that is simply on or off.

The options

flowchart TD
  APP["Application"] --> P["Primary region"]
  subgraph PR["Primary region"]
    Z1["Zone 1 copy"]
    Z2["Zone 2 copy"]
    Z3["Zone 3 copy"]
  end
  P --> Z1
  P --> Z2
  P --> Z3
  PR -.->|"asynchronous geo replication"| SR["Secondary region copy"]
  APP -.->|"read-only secondary endpoint with RA options"| SR
        

Synchronous and asynchronous copies

Copies inside the primary region are written synchronously, meaning a write is only confirmed after the required copies exist. Copies to the secondary region are asynchronous, meaning they follow a little later. That delay is called the recovery point gap. If the primary region fails suddenly, the latest writes that had not yet reached the secondary may be lost. A premium feature called geo priority replication targets a recovery point gap of fifteen minutes or less for block blobs. Always compare this gap with how much data loss your business can tolerate.

Failover is a decision, not an automatic switch

With geo redundancy, a regional outage does not automatically redirect writes. You must start an account failover, after which the secondary becomes the new primary. During the failover, reads and writes are briefly unavailable, and afterwards writes resume on the new primary. With the read-access options, your application can keep reading from the secondary address while the primary is down, but writes still need failover.

Choosing a level

Availability targets are different from durability

Durability is the chance your data survives. Availability is the chance you can reach it right now. Hot tier standard accounts target at least 99.9 percent availability for reads and writes, and cooler tiers target 99 percent. Read-access geo options raise the read target. A system can be extremely durable yet briefly unreachable, so applications must retry and handle temporary errors.

Lifecycle rules move and delete data automatically, so cost control does not depend on someone remembering.

What a lifecycle policy is

A lifecycle management policy is a set of rules that Azure runs for you. Each rule describes which blobs it applies to, under what conditions, and what action to take. Typical actions are moving blobs to a cooler tier, moving them back to hot when they are accessed, and deleting them at the end of their useful life. The policy itself costs nothing. You pay normal charges for the tier-change operations, while deletions are free.

The parts of a rule

flowchart TD
  A["Policy rules defined once"] --> B["Policy runs periodically in the background"]
  B --> C{"Does a blob match the filter"}
  C -->|"No"| D["Leave blob unchanged"]
  C -->|"Yes"| E{"Which condition is met"}
  E -->|"Idle for first period"| F["Move to cool"]
  E -->|"Idle for second period"| G["Move to cold or archive"]
  E -->|"Past retention period"| H["Delete"]
  F --> I["Billing for tier-change operations only"]
  G --> I
        

Timing and behavior you should know

Limits and caveats

Useful policy ideas

Redundancy protects against broken hardware. Data protection features protect against broken humans.

The threats

Most real data loss in the cloud is not caused by failed disks. It is caused by an administrator deleting the wrong container, an application bug overwriting good files with bad ones, a script run in the wrong environment, or ransomware and malicious insiders. Each of these needs a different defense, and the defenses can be combined.

The protective tools

A sensible baseline

Immutability in plain words

An immutability policy makes data write once, read many. Once a time-based retention policy is locked, nobody, including administrators, can delete or change protected data until the period ends. A legal hold works similarly but lasts until it is removed. This is how organizations meet rules that require records to be kept in an unalterable form. Because it is deliberately hard to undo, test policies on non-critical data before locking them.

Recovery windows to remember

Storage accounts are reachable from the internet by design, so access control must be deliberate and layered.

Defense in depth

No single wall protects a castle. It has a moat, thick walls, guards and a locked treasury. Storage security follows the same idea. You control who may authenticate, what they may do, from where they may connect, how data is encrypted, and how activity is recorded. If one layer is misconfigured, the others limit the damage.

The layers

Three ways to authorize, ranked

The shared access signature, step by step

A shared access signature is like a valet key for your data. It opens only specific doors, for a limited time, and can be given to someone without handing over the master key. The safest version is built from an Entra identity, so Azure can check both the token and the identity behind it.

sequenceDiagram
  participant Client as Client or browser
  participant App as Your token service
  participant Entra as Microsoft Entra ID
  participant Blob as Blob Storage
  Client->>App: Ask to upload a file
  App->>App: Check the user is allowed
  App->>Entra: Request a user delegation key
  Entra->>App: Return the delegation key
  App->>App: Create short-lived token with minimal permissions
  App->>Client: Return the token link
  Client->>Blob: Upload using the token link
  Blob->>Blob: Validate token, permissions and expiry
  Blob->>Client: Accept or reject the request
        

Encryption and keys

All data in Blob Storage is encrypted at rest by default using keys managed by Microsoft. Organizations with stricter rules can use their own keys held in Azure Key Vault, which lets them rotate, disable or revoke the key. Remember that if you lose or delete a customer-managed key, the data becomes unreadable, so protect keys with soft delete and purge protection and plan access carefully. Client-side encryption, where your application encrypts data before upload, gives the strongest control but adds responsibility for key handling.

Hardening checklist

Where a request comes from matters as much as who is making it.

Public by default, restricted by choice

A new storage account has a public endpoint that anyone on the internet can try to reach. They still need valid credentials, but the door exists. Many organizations prefer that the door not exist at all for outsiders. Networking settings let you shrink or remove the public door so that only approved networks can even attempt a connection.

The ways to connect

flowchart LR
  U["Users on the internet"] --> CDN["Content delivery network or front door"]
  CDN --> ORIG["Storage origin: restricted access"]
  subgraph VNET["Your virtual network"]
    APP["Applications and services"]
    PE["Private endpoint with private address"]
  end
  APP --> PE
  PE --> ORIG
  ONP["On-premises network via private link or VPN"] --> PE
  PUB["Public internet directly"] -.->|"blocked by firewall"| ORIG
        

What a private endpoint really needs

Traffic and cost across networks

Reading from storage inside the same region is usually cheap or free of transfer charges, while data leaving Azure or crossing regions adds cost and time. Keep compute and storage in the same region wherever possible. For global audiences, a delivery network caches popular content near users, reducing both latency and the number of billable reads from the origin.

Following one large upload from start to finish explains many behaviors, from parallel speed to overwrite surprises.

The story of a large upload

Suppose you upload a very large video file. A good client does not send it in one long stream. It cuts the file into blocks, gives each block an identifier, sends many blocks in parallel, and finally sends a list telling Blob Storage which blocks, in which order, make up the finished object. Only that final step makes the blob visible. Until then, the uploaded blocks are staged but not part of any readable blob.

sequenceDiagram
  participant Client as Client
  participant FE as Front end
  participant PL as Partition layer
  participant SL as Stream layer
  Client->>FE: Send block 1 with identifier
  FE->>FE: Check identity and permissions
  FE->>PL: Route to the right partition
  PL->>SL: Store block bytes with required copies
  SL->>PL: Confirm copies written
  PL->>Client: Block accepted
  Client->>FE: Send more blocks in parallel
  Client->>FE: Send final list of block identifiers
  FE->>PL: Commit the blob from the listed blocks
  PL->>Client: Success and new version tag
        

Step by step in words

Unfinished uploads

Blocks staged but never committed are not part of any blob. They are discarded by the service after a period of roughly a week. If your client crashes midway, no broken blob appears, but you may briefly pay for staged blocks. Clients that resume uploads should reuse the same block identifiers so they can skip pieces already staged.

Concurrency: two writers, one blob

Because blob updates replace whole objects or add blocks, two clients writing at the same moment could overwrite each other. Blob Storage supports optimistic concurrency using the entity tag. A client says, “write this only if the blob still has the tag I saw earlier.” If someone else changed it meanwhile, the write is rejected and the client can reload and try again. For stronger exclusion, a lease works like a short-term lock that only the lease holder can break or use.

Reading data

Reads can fetch an entire blob or just a byte range, which is how video players jump to a position and how analytics engines read only the columns they need from a large file. Because the service is strongly consistent, a read after a successful write returns the new content. Range reads reduce transfer and cost when you need only part of a large object.

Data does not just sit in Blob Storage. It arrives from somewhere, is used by something and eventually leaves.

The life of data in a typical platform

Imagine a company that collects device readings, files from partners and exports from business systems. Everything lands in a landing area of the storage account. Processing jobs read the raw files, clean and enrich them, and write results to a curated area. Reports and applications read from the curated area. Old raw data is moved to cheaper tiers and later deleted. Each step reads from and writes to Blob Storage, which acts as the shared backbone.

flowchart LR
  SRC["Sources: devices, partners, apps"] --> ING["Ingestion: SFTP, copy tools, pipelines, streaming"]
  ING --> RAW["Raw zone in Blob Storage"]
  RAW --> EVT["Blob events trigger processing"]
  EVT --> PROC["Processing jobs and analytics engines"]
  PROC --> CUR["Curated zone in Blob Storage"]
  CUR --> USE["Reports, applications, machine learning"]
  RAW -->|"lifecycle rules"| ARC["Cooler tiers and archive"]
  CUR -->|"lifecycle rules"| ARC
        

Ways to move data in and out

Event-driven processing

Blob Storage can emit events when blobs are created or deleted, and policy runs can emit completion events. Other services listen for these events and react, such as starting a processing job when a file arrives or generating a thumbnail for each new image. This removes the need to constantly poll for new files and keeps pipelines responsive and cheap. Because events can occasionally be delivered more than once, handlers should be safe to run twice.

The request lifecycle of a read

A user clicks a picture on a site. The browser asks a delivery network, which returns a cached copy if it has one. If not, the network fetches the picture from the storage origin, checking the token or permission, and then caches it. The storage service reads the bytes from the nearest healthy copy and returns them. Every hop can add speed, protection or delay, and each hop has its own settings for timeouts, caching and authentication.

Where time and money go

Blob Storage scales enormously, but the way you name, size and send requests decides whether you see that scale.

The published targets

Microsoft publishes scalability targets that describe what a single object or account can achieve. They are described as high-end but achievable targets, and real results depend on object size, access pattern and workload type, so you should test your own workload. A few numbers are worth remembering.

Partitions, names and hot spots

Because storage divides the namespace into ranges of names, names that are all similar and increase steadily, such as timestamps at the start, push all traffic into one range. That range’s server becomes busy and starts to push back before the account reaches its overall limits. The service rebalances automatically over time, but sudden bursts can still hit throttling. Spreading names, for example by putting a short varied prefix before the date, spreads traffic across many ranges.

Habits that make uploads and downloads fast

Many small files versus fewer large files

When to consider premium

If your workload makes huge numbers of small requests and needs steady low latency, such as an interactive application or a machine learning pipeline reading many small objects, a premium block blob account may be justified. For capacity-heavy, rarely touched data, standard accounts with cooler tiers are far cheaper. Measure before deciding.

Storage problems tend to be quiet: a slow leak of cost, a gradual rise in errors or an unexpected visitor. Monitoring makes them loud.

The signals

The Azure toolbox

Azure Monitor collects storage metrics automatically. You can send resource logs to a Log Analytics workspace to search them and build alerts. Storage insights offers ready-made dashboards for capacity, performance and failures. Blob inventory produces scheduled reports listing every blob and its properties, which is a cheap way to analyze huge containers without listing them yourself. Event delivery services carry blob events to your automation.

flowchart LR
  SA["Storage account"] --> M["Azure Monitor metrics"]
  SA --> L["Resource logs"]
  SA --> E["Blob and lifecycle events"]
  SA --> INV["Blob inventory reports"]
  M --> AL["Alert rules"]
  L --> LA["Log Analytics workspace"]
  LA --> AL
  E --> AUTO["Automation and notifications"]
  INV --> ANA["Cost and usage analysis"]
  AL --> ON["On-call people and runbooks"]
        

Questions your dashboard should answer

Alerts people can live with

Alert on outcomes and anomalies: a sharp rise in error rate, a sudden jump in deletes, a big increase in data leaving the account, new anonymous access attempts, or capacity growing faster than expected. Attach a short runbook to each alert explaining what it means and the first checks. Too many noisy alerts teach people to ignore all of them.

Storage looks cheap per gigabyte, but with enough data and enough requests the bill becomes a real project.

The cost dimensions

The bill for Blob Storage has several parts. You pay for the capacity you store, which depends on tier and redundancy. You pay for operations such as reads, writes and lists. You pay for data retrieval in cooler tiers and for early deletion. You pay for replication and for data that leaves Azure. Protection features such as soft delete, versions and snapshots add stored capacity. Extras such as access time tracking, private endpoints and monitoring add smaller lines.

The levers

The tiering trap

Cooler tiers lower storage cost, but they charge more per operation and per gigabyte read, and they enforce minimum stays. Data that looks old but is still scanned by reports or machine learning jobs can cost more in a cooler tier than in hot. Before tiering a dataset, measure how often it is actually read, and prefer rules based on last access rather than age alone when reads are unpredictable.

Make cost visible

Tag accounts by team, project and environment, and review spending by tag each month. Use blob inventory reports to see capacity by tier, age and prefix, which reveals the few folders that account for most of the bill. Share the view with owners, because people tidy what they can see.

Teams that run Blob Storage well keep reusing a handful of proven shapes.

Layout patterns

Access patterns

Processing patterns

Resilience patterns

These habits look harmless on day one and become expensive or dangerous later.

A compact checklist in plain words, grouped by the topics you have just learned.

Best practices by area

Common mistakes

These are typical patterns of use. They are illustrative scenarios, not descriptions of particular companies.

What the examples have in common

In every scenario, access uses identities instead of keys, data is organized into zones with clear rules, lifecycle policies move data as it ages, protection features guard against mistakes, and monitoring keeps cost and security visible. The industries differ, but the habits are strikingly alike, and those habits are what you should copy.

Plain answers to questions that newcomers and experienced engineers often ask when they first use Azure Blob Storage.

Blob Storage is object storage reached mainly through web requests and libraries, ideal for huge amounts of unstructured data. Azure Files provides managed network file shares that behave like a traditional shared drive. Choose by how your applications expect to access the data.

A blob is a single stored object of any kind, such as a picture, document, video or backup. Blobs live in containers, and containers live in a storage account.

Use block blobs for almost everything, including files, media, backups and data lake data. Use append blobs for logs where you only add to the end. Use page blobs only for disk-like random access, which most teams never need directly.

Hot for frequently used data, cool and cold for data used occasionally or rarely but needed instantly, and archive for long-term retention you can wait hours to retrieve. Choose based on how often data is actually read, and let lifecycle rules move data as it ages.

Archived blobs must be rehydrated to an online tier first, which can take up to around fifteen hours depending on the priority you choose. During that time the blob cannot be read.

No. Geo redundancy protects against loss of a data center or region, but deletions and overwrites are copied too. A backup is a separate, protected, restorable copy. Use soft delete, versioning and vaulted backup for protection against mistakes and attacks.

For geo-redundant accounts, yes, you start an account failover, and the secondary becomes the new primary. Read-access options let applications keep reading from the secondary meanwhile. Recent writes that had not yet replicated may be lost, so rehearse and plan for it.

It is a time-limited token or link that grants specific permissions to specific data without sharing your account key. The safest form is a user delegation signature created with Entra credentials, with minimal permissions and a short expiry.

Create private endpoints in your virtual network, make sure private name resolution works, and then disable public network access. As a first step you can use firewall rules to allow only specific networks.

Yes. Data is encrypted at rest by default with Microsoft-managed keys, and you can use your own keys in Azure Key Vault if your rules require it. Require HTTPS and a minimum TLS version so data is also protected in transit.

A part of the namespace or the account is receiving more traffic than it can handle at that moment, often because many blob names fall in a narrow range or traffic spiked suddenly. Spread names, ramp traffic up gradually, and retry with growing delays.

Only with the hierarchical namespace enabled. Without it, folders are just parts of blob names, so renaming means copying and deleting every blob under that name.

Use lifecycle rules, pick tiers based on real access patterns, prune versions and snapshots, avoid repeated listing, store fewer larger files, keep compute in the same region and tag resources so you can see who spends what.

The official Azure Storage documentation, the scalability targets page, the pricing pages and the Azure updates feed are the best sources. Limits, features and prices change over time, so treat any article, including this one, as a guide to understanding rather than a replacement for those pages.

Azure Blob Storage gives you effectively unlimited, durable and affordable space for unstructured data. You organize it into accounts, containers and blobs, choose block, append or page blobs by write pattern, and decide up front on account type and namespace. You then choose a redundancy level for the risks you face, use tiers and lifecycle rules to match cost to usage, and add protection features to survive human error and attack. Access should rely on identity, with narrow roles, short-lived tokens, restricted networks and encryption. Good performance comes from parallel, well-named, well-sized requests with sensible retries. Teams that follow these habits keep storage safe, fast and economical. Teams that skip them often discover the gaps only during an incident or a surprising invoice.