Quotas & Limits: Transfer & Storage
The concrete byte sizes, key lengths, and thresholds that govern how a file moves from its source, through encryption and compression, into your own Azure or AWS storage account.
| Limit | Value | Note |
|---|---|---|
| AES key length | 32 bytes (256-bit) | All file content is encrypted with AES-256-GCM. |
| Encryption IV length | 16 bytes | Generated fresh from a cryptographically random source for every chunk, never reused. |
| BYOK File Key size | 32 bytes (256-bit) | A genuinely random AES key generated fresh per file, wrapped under the tenant’s own KMS key. Never derived from any shared secret. |
| KMS calls per file (BYOK) | 1 wrap + 1 unwrap | The file’s key is wrapped exactly once per file, immediately after that file’s chunks are encrypted — never once per chunk. This keeps call volume proportional to file count rather than chunk count against your KMS provider’s own request-rate quotas. The same one-call-per-file pattern is used for unwrap at restore time. |
| Compression algorithm | zlib, level 6 | Content is compressed with zlib (RFC 1950 format) at level 6 before encryption, on both the Microsoft 365 and file-server paths. This is explicitly not gzip, which is a different, incompatible format. |
| Graph API download chunk size | 4 MB | Drive and mailbox content is streamed from Microsoft Graph in 4 MB reads. |
| Graph API simple-upload limit | 4 MB | Microsoft Graph’s own hard ceiling on the single-PUT upload endpoint, used during in-place restore. Files at or under this size are restored with one PUT. Larger files fall back to an upload session. |
| Graph API upload-session chunk size | ~3.1 MB | A multiple of the 320 KiB alignment Microsoft Graph requires for upload-session byte ranges. |
| Azure block blob block size | 4 MB max | Each chunk sourced from Graph is staged as one block as-is. Azure block blobs have no minimum block size, so the 4 MB chunks are used directly with no re-buffering. |
| S3 minimum multipart part size | 5 MB (except the final part) | An S3 constraint, not a BYOVault choice. Because Graph yields 4 MB chunks, BYOVault buffers two source chunks (8 MB) before uploading each S3 part. The final part may be any size, including under 5 MB. |
| Azure blob metadata cap before sidecar manifest | 8 KB total | A large multi-block file’s per-block integrity data can exceed Azure’s 8 KB blob-metadata limit. For any multi-block file, that data is written to a separate manifest blobalongside the file, leaving only a small flag and block count in the blob’s own metadata. |
| S3 object metadata cap before sidecar manifest | 2 KB total | Tighter than Azure’s cap. The same sidecar-manifest approach applies: a multi-part S3 object stores its per-block integrity data in a companion object rather than in S3 user-metadata. |
| Agent chunked-upload threshold | 50 MB | Files at or above this size are split into chunks and uploaded across multiple requests, rather than as a single body, so that each individual upload request stays within a safe request-size envelope. |
| Agent chunk size | 50 MB | Equal to the chunk threshold above. Up to 4 chunks are uploaded concurrently per file. |
Implementation values, not contractual guarantees
These are implementation details, not commitments in any customer agreement, and may change between releases without a corresponding change to this page’s surrounding prose. Treat this table as a snapshot of current behavior, not a specification to build external tooling against without re-verifying.
For how these constants interact with request timeouts and retry behavior, see Quotas & Limits: Timing & Retry.