Azure Data Box limits

Consider these limits as you deploy and operate your Microsoft Azure Data Box. The following table describes these limits for the Data Box.

Data Box service limits

  • If you use multiple storage accounts with the Data Box service, all the storage accounts should belong to the same Azure region.
  • We recommend that you use no more than three storage accounts. Using more storage accounts could potentially affect the performance.

Data Box limits

  • Data Box can store a maximum of 500 million files.
  • Data Box supports a maximum of 512 containers or shares in the cloud. The top-level directories within the user share become containers or Azure file shares in the cloud.

Azure storage limits

This section describes the limits for Azure Storage service, and the required naming conventions for Azure Files, Azure block blobs, and Azure page blobs, as applicable to the Data Box service. Review the storage limits carefully and follow all the recommendations.

For the latest information on Azure storage service limits and best practices for naming shares, containers, and files, go to:


If there are any files or directories that exceed the Azure Storage service limits, or don't conform to Azure Files/Blob naming conventions, then these files or directories aren't ingested into the Azure Storage via the Data Box service.

Data upload caveats

  • Don't copy files directly to any of the precreated shares. You need to create a folder under the share and then copy files to that folder.
  • A folder under the StorageAccount_BlockBlob and StorageAccount_PageBlob is a container. For instance, containers are created as StorageAccount_BlockBlob/container and StorageAccount_PageBlob/container.
  • Each folder created directly under StorageAccount_AzureFiles is translated into an Azure File Share.
  • If you have an existing Azure object (such as a blob or a file) in the cloud with the same name as the object that is being copied, Data Box will overwrite the file in the cloud.
  • Every file written into StorageAccount_BlockBlob and StorageAccount_PageBlob shares is uploaded as a block blob and page blob respectively.
  • Azure blob storage doesn't support directories. If you create a folder under the StorageAccount_BlockBlob folder, then virtual folders are created in the blob name. For Azure Files, the actual directory structure is maintained.
  • Any empty directory hierarchy (without any files) created under StorageAccount_BlockBlob and StorageAccount_PageBlob folders isn't uploaded.
  • If there are any errors when uploading data to Azure, an error log is created in the target storage account. The path to this error log is available when the upload is complete and you can review the log to take corrective action. Don't delete data from the source without verifying the uploaded data.
  • File metadata and NTFS permissions are not preserved when the data is uploaded to Azure Files. For example, the Last modified attribute of the files will not be kept when the data is copied.

Azure storage account size limits

Here are the limits on the size of the data that is copied into storage account. Make sure that the data you upload conforms to these limits. For the most up-to-date information on these limits, see Scalability and performance targets for Blob storage and Azure Files scalability and performance targets.

Size of data copied into Azure storage account Default limit
Block blob and page blob 2 PB for US and Europe.
500 TB for all other regions, which includes the UK.
This includes data from all the sources including Data Box.
Azure Files 5 TB per share.
All folders under StorageAccount_AzureFiles must follow this limit.

Azure object size limits

Here are the sizes of the Azure objects that can be written. Make sure that all the files that are uploaded conform to these limits.

Azure object type Default limit
Block blob ~ 4.75 TiB
Page blob 8 TiB
Every file uploaded in page blob format must be 512 bytes aligned (an integral multiple), else the upload fails.
VHD and VHDX are 512 bytes aligned.
Azure Files 1 TiB
Managed disks 4 TiB
For more information on size and limits, see:
  • Scalability targets of Standard SSDs
  • Scalability targets of Premium SSDs
  • Scalability targets of Standard HDDs
  • Pricing and billing of managed disks
  • Azure block blob, page blob, and file naming conventions

    Entity Conventions
    Container names for block blob and page blob Must be a valid DNS name that is 3 to 63 characters long.
    Must start with a letter or number.
    Can contain only lowercase letters, numbers, and the hyphen (-).
    Every hyphen (-) must be immediately preceded and followed by a letter or number.
    Consecutive hyphens aren't permitted in names.
    Share names for Azure files Same as above
    Directory and file names for Azure files
  • Case-preserving, case-insensitive and must not exceed 255 characters in length.
  • Cannot end with the forward slash (/).
  • If provided, it will be automatically removed.
  • Following characters aren't allowed: " \ / : | < > * ?
  • Reserved URL characters must be properly escaped.
  • Illegal URL path characters aren't allowed. Code points like \uE000 aren't valid Unicode characters. Some ASCII or Unicode characters, like control characters (0x00 to 0x1F, \u0081, etc.), are also not allowed. For rules governing Unicode strings in HTTP/1.1 see RFC 2616, Section 2.2: Basic Rules and RFC 3987.
  • Following file names aren't allowed: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, dot character (.), and two dot characters (..).
  • Blob names for block blob and page blob
  • Blob names are case-sensitive and can contain any combination of characters.
  • A blob name must be between 1 to 1,024 characters long.
  • Reserved URL characters must be properly escaped.
  • The number of path segments comprising the blob name cannot exceed 254. A path segment is the string between consecutive delimiter characters (for example, the forward slash '/') that correspond to the name of a virtual directory.