Hosting Public Website Content with Azure Blob Storage

Source: Dev.to

About this Lab

Microsoft Learn provides a walkthrough for configuring an Azure Storage account to host public‑facing content (images, videos, documents) with high availability, soft delete protection, and blob versioning.

Task 01 – Creating the Storage Account

• Storage account name: publicwebsite[your-unique-id]
• In the Basics tab, set the name, region, and redundancy (e.g., RA‑GRS).

Task 02 – Configuring Public Access (and the error I hit)

Step 1: Enable anonymous blob access at the account level

1. Open the storage account’s Configuration blade.
2. Set Allow blob anonymous access to Enabled.

Note: The setting must be saved before you can modify container‑level access.

Step 2: Set container public access level

1. Navigate to the desired container.
2. Change Public access level to Blob.

What happened:

• Attempting to change the container access level before saving the account‑level setting produced an error.
• After saving the account setting, the container access level changed successfully.

Task 03 – Uploading Content & Testing Public Access

1. Open the container and click Upload.
2. Upload a sample file (e.g., an image).

You can now view the file directly via its public blob URL in a browser.

Task 04 – Enabling Soft Delete

1. Delete the uploaded file from the container.
2. In the Data Protection blade, enable Blob soft delete and set a retention period (e.g., 21 days).

Deleted blobs appear with a strikethrough indicator, and they can be restored within the retention window.

Task 05 – Enabling Blob Versioning

• In the Versioning settings, set Blob versioning to Enabled.
• Azure will now track versions whenever a blob is overwritten.

What I Learned – Key Takeaways

• Account‑level anonymous access must be saved before you can change container‑level access.
• RA‑GRS (Geo‑redundant storage) provides resilience, keeping content available during a primary region outage.
• Two‑level access gates: both account‑level and container‑level anonymous access must be configured independently.
• Soft delete protects against accidental deletions; versioning protects against accidental overwrites. Using both together offers comprehensive data protection.