Azure Storage malware scanning: when I’d use on-upload vs. on-demand

Microsoft made on-demand malware scanning much more useful. You can now target the data you actually care about instead of treating every investigation like a full storage-account scan.

I like security controls that fit naturally into the architecture instead of forcing another appliance, agent, or scanning server into it. Defender for Storage malware scanning is one of those controls.

The distinction between its two scanning modes used to be fairly simple. On-upload scanning handled new blobs. On-demand scanning was something I thought of mostly for data that was already there.

That is still directionally correct, but Microsoft has made on-demand scanning more interesting. You can now target a specific blob or file, a container or file share, or a path prefix. That changes how I would use it during an investigation.

I would start with one question: when does the file become untrusted?

If users, customers, partners, or another application are dropping files into Blob Storage, I generally want scanning as close to that ingestion point as possible.

That is where on-upload scanning makes sense. Defender for Storage automatically scans supported blobs when they are uploaded or modified. Results can feed an automated workflow through Event Grid, Log Analytics, security alerts, or blob index tags.

If the data is already in the storage account, or I am responding to something specific, on-demand scanning becomes the better tool.

Where I’d use on-upload scanning

The obvious use case is a web application that accepts files from the Internet: document portals, customer uploads, claims, resumes, images, or third-party exports.

I would not let the application assume that “upload succeeded” means “file is safe.” I would treat the scan result as another state in the workflow.

• Uploaded: the object exists, but the application should not necessarily trust it yet.
• Scan completed: the result can be consumed by the application or automation.
• Malicious: block access, quarantine, move, or delete according to requirements.
• Scan failed or skipped: do not silently treat that as clean.

The targeted on-demand option is what caught my attention

On-demand scanning can scan an entire storage account, but Microsoft now also supports targeted filters for individual objects and groups of objects. The targeted filtering capability is currently in preview.

You can scope a scan to a single blob or Azure file, an entire container or file share, or objects matching a path prefix.

• Re-scan a file that previously failed scanning.
• Investigate one suspicious object after an alert.
• Scan a customer or application folder represented by a path prefix.
• Baseline existing data before enabling a new workflow.
• Revisit stored content after threat intelligence changes.
• Scan Azure Files content, where on-upload malware scanning is not supported.

Blob Storage and Azure Files are not identical here

On-upload malware scanning does not support Azure Files. On-demand scanning can target files and file shares. On-upload scanning also does not support append blobs or page blobs. Microsoft currently supports scanning files and blobs up to 50 GB.

I would set the scanning cap deliberately

Malware scanning is charged based on data scanned, with possible associated Azure Storage, blob indexing, and Event Grid charges.

For on-upload scanning, Microsoft uses a default monthly cap of 10,000 GB per storage account if you do not define another limit. Once the cap is reached, scanning stops for the rest of the month, subject to a small usage deviation.

I would look at normal upload volume, expected growth, file sizes, and what happens operationally if the cap is reached. Microsoft provides alerts at 75 percent of the cap and when scanning stops.

Do not pay to scan data that obviously does not need it

On-upload scanning supports exclusions based on blob path prefixes, suffixes, and blob size. That can avoid scanning known logs, temporary content, or other paths that do not carry the same malware risk.

I would be careful here. Every exclusion creates a path the scanner intentionally ignores.

The scan result is only useful if something happens next

Enabling malware scanning is not the same as designing a malware-handling workflow. Results can surface through blob index tags, Defender for Cloud alerts, Event Grid, and Log Analytics, and remediation can block, delete, move, or soft-delete malicious content.

For an application receiving untrusted files, I would decide ahead of time which system owns the response. The important part is that malicious results and failed scans both lead somewhere predictable.

What I’d review before turning this on

I would not choose between these features as if one replaces the other

They solve different problems. For an application ingesting untrusted blobs, I would normally start with on-upload scanning. For existing data, Azure Files, investigations, re-scans, and targeted response, on-demand scanning is the more flexible tool.

The newer targeted scanning capability makes that second option much more practical. Instead of scanning an entire account because one object worries you, you can focus the scan where the question actually is.