Skip to main content
Azure Blob Storage is a managed, scalable service for storing large amounts of unstructured data (text or binary) accessible via HTTP/HTTPS. Common uses include serving images and documents to browsers, streaming media, storing logs, and backups or archives. Understanding Blob Storage’s hierarchy, blob types, access controls, and storage tiers helps you design cost-effective and secure storage for cloud applications. Key terms
  • Storage account — The top-level namespace that contains containers and blobs. It defines account-level properties and access keys.
  • Container — A grouping of blobs within a storage account (conceptually like a folder). Containers hold blobs and define access policies.
  • Blob — An individual file of any type (images, PDFs, videos, logs).
Below is an example screenshot of a storage account overview in the Azure portal.
Screenshot of the Microsoft Azure portal showing the Overview page for a storage account named "demoaz0753553," with the left navigation menu and account properties (location, replication, performance, and security settings) displayed. The properties pane also lists Blob/File service and networking configuration details.
Azure supports three blob types optimized for different scenarios. Use the table below to choose the right blob type by access pattern and workload. Real-world example: a website might use a single storage account to hold all assets, with a Documents container for PDFs and a Videos container for MP4s. Each file in those containers is a blob and can be served directly to users.

​
Containers and public access levels

When creating a container you must choose a public access level. Consider security and exposure risk before permitting anonymous access.
Carefully evaluate public access. Enabling Container or Blob access makes objects available to anyone with the URL. Avoid exposing sensitive data unintentionally — prefer SAS or Azure AD-based access for private resources.
By default, many storage accounts block container-level public access. If you want to allow container-level public access, enable the account-level setting first:
  1. Go to the storage account → Configuration.
  2. Turn on Allow Blob public access (label may vary).
  3. Save the configuration.
If access level options are grayed out when creating a container, check the storage account configuration and any subscription or tenant policies that may block public access.

​
Portal walkthrough — create a container and upload blobs

This walkthrough shows the common portal steps to create a container, change access levels, and upload blobs.
  1. From the storage account blade, choose Containers → + Container.
  2. Enter a container name (for example, images) and select the access level (Private, Blob, or Container).
  3. Click Create.
A Microsoft Azure portal screen showing the Containers view for a storage account with an existing $logs container. A "New container" pane is open with the name "images" entered and anonymous access set to Private.
After the container exists you can upload files:
  • Open the container and click Upload.
  • Browse and select files from your device.
  • Start the upload — the portal will show progress and handle name conflicts.
A screenshot of the Microsoft Azure portal showing a storage container named "images" with a list of image files on the left. The right pane displays the blob properties and details for the selected file "City1.jpg" (URL, size, content-type, timestamps).
If the container is set to Container or Blob public access, you can copy a blob’s URL from the portal and paste it into a browser to download or view the file. Changing the container to Private revokes anonymous access immediately.
A screenshot of the Microsoft Azure portal showing a storage container named "images" with a list of image blobs (e.g., City1.jpg, Colour1.jpg) and columns for modified date, access tier, blob type, size, and lease state. A notification in the corner indicates blobs were successfully uploaded.

​
Authentication and secure access options

When containers are private, you can grant controlled access using:
  • Storage account access keys — full control; treat like root credentials.
  • Shared Access Signatures (SAS tokens) — time-bound, scoped permissions for specific operations.
  • Microsoft Entra ID (Azure AD) — role-based access control using Azure RBAC for fine-grained permissions.
Recommended patterns:
  • Use SAS tokens for temporary, delegated access (e.g., upload URLs).
  • Use Azure AD and RBAC for enterprise scenarios requiring centralized identity and least privilege.
  • Avoid embedding account keys in client-side applications.

​
Storage tiers (cost vs latency)

Azure offers access tiers to balance storage cost and retrieval times. You can set a default at the account level and override it at the blob level.
  • Hot — for frequently accessed data (higher storage cost, lower access cost).
  • Cool — for infrequently accessed data (lower storage cost, higher access cost).
  • Archive — for rarely accessed data with long retrieval latency (lowest storage cost, highest retrieval cost).
Use lifecycle management rules to move blobs between tiers automatically based on access patterns.

​
Quick reference tables

​
Conclusion

You should now understand:
  • The storage account → container → blob hierarchy.
  • Blob types (Block, Append, Page) and when to use each.
  • Container public access levels and how to enable or revoke them.
  • How to create containers and upload blobs in the Azure portal.
  • Authentication options (SAS, account keys, Azure AD) and storage tiers (Hot, Cool, Archive).
Links and references

Watch Video

Practice Lab