Azure Defender for Cloud is much slower this week

What is being observed matches documented Defender for Storage malware scanning behavior under load or with complex content.

• SAM259207 means the scan timed out before completion. Scan time depends on blob size, type, complexity, and storage-account load. A smaller blob can still time out if it contains a compressed file with many entries, while a larger blob can finish quickly if only limited analysis is needed.
• Slow scans for even small files can also happen when the service is delayed or when the storage account is busy:
  • SAM259215: the scan was delayed due to system load and will run later.
  • SAM259221: the storage account was busy or not responsive, which can happen under high load, throttling, or blocked network access.
• Defender also documents that large or complex blobs can exceed the scanning timeout window, which ranges from 30 minutes to 3 hours depending on blob size and structure. ZIP files with many nested entries are specifically called out as taking longer.

Practical checks:

1. Check the exact scan result code for the affected blobs.
   • SAM259207 = timeout.
   • SAM259215 = delayed by service load.
   • SAM259221 = storage account busy/not responsive.
2. Review whether the slow files are compressed archives.
   • A 1 GB zipped executable can take much longer than an uncompressed file because archive structure affects scan duration.
3. Check storage-account load and throttling.
   • If the account is under high load, Defender may not be able to access blobs efficiently enough to complete scans.
   • If this is happening, reduce load, distribute workload across multiple storage accounts, or move to a higher performance tier.
4. Retry the same upload.
   • For timeout cases, the documented guidance is that the issue is often temporary and uploading the same blob again usually succeeds.
5. Review unsupported or problematic patterns.
   • Chunked uploads can prevent accurate detection.
   • Client-side encrypted blobs cannot be scanned.
   • Password-protected archives and excessive archive nesting can also cause scan failures.
6. Consider on-demand malware scanning for targeted retests.
   • It can be used to retry a failed scan for a specific blob without rescanning the whole account.

So the most likely explanation is not a permanent product regression, but one of these documented conditions: higher service/system load, storage-account load, or archive/blob complexity causing scans to take much longer and sometimes hit the timeout window.

References:

• Understand malware scanning results
• Introduction to malware scanning
• On-demand malware scanning