Setting Up a Highly Available Azure Storage Account with Public Access and Blob Management Features

Recently, I worked on setting up a highly available storage account in Azure to support a public website. My goal was to ensure the storage account had high availability, enabled anonymous public access, and included additional features like soft delete and blob versioning. Here's a breakdown of the steps I followed and some key takeaways from the process.

Step 1: Creating a Highly Available Storage Account
To begin, I created a new storage account that would support the public website. I headed to the Azure portal, searched for "Storage accounts," and selected the "+ Create" option. For organization, I created a new resource group, gave it a name, and set up the storage account with a unique name (publicwebsite followed by an identifier to ensure uniqueness). I took the default settings for most of the configuration and proceeded to deploy the storage account.

Since this setup requires high availability, I needed to prepare for any potential regional outages. In the storage account settings under the "Redundancy" blade, I selected the "Read-access Geo-redundant storage" (RA-GRS) option. This setting not only provides geo-redundancy but also ensures that data can be read from a secondary region if the primary region goes down—a critical aspect for high availability.

Step 2: Enabling Anonymous Public Access
To ensure that information on the public website could be accessed without requiring customer logins, I configured the storage account to allow anonymous access to blobs. In the storage account’s "Configuration" settings, I enabled the "Allow blob anonymous access" option. This setting is essential for a public-facing website where users should be able to view content without barriers.

Step 3: Creating a Blob Storage Container with Anonymous Read Access
Next, I needed to create a blob storage container specifically for the website’s documents, images, and other content. In the "Data storage" section of the storage account, I navigated to the "Containers" blade and added a new container named public. I configured this container to allow anonymous read access by setting the public access level to "Blob (anonymous read access for blobs only)". This setting is perfect for allowing users to view or download content without needing authentication.

To test the setup, I uploaded a small file (like an image or text file) to the public container and grabbed the URL for the file. I pasted the URL into a new browser tab, and it displayed correctly—just what I needed for the public site.

Step 4: Configuring Soft Delete
One of my primary concerns was ensuring that website documents could be restored if accidentally deleted. To address this, I enabled soft delete for blobs. I went to the "Overview" blade of the storage account, located the "Blob service" section under "Properties," and enabled the "Blob soft delete" feature. I set the retention period to 21 days, which provides a decent buffer for accidental deletions.

I also practiced using this feature by deleting a test file from my container and then restoring it. After toggling the "Show deleted blobs" option, I was able to locate the deleted file, use the ellipses to restore it, and confirm the restoration by refreshing the container view. It’s a straightforward process that adds an extra layer of safety for my data.

Step 5: Enabling Blob Versioning
Lastly, I enabled blob versioning to keep track of changes and maintain different versions of the documents. This is particularly useful for a public website where content may need frequent updates. Again, in the "Overview" blade of the storage account, I found the "Versioning" setting under the "Blob service" section and enabled it.

To test versioning, I uploaded a new version of an existing file. As expected, the previous version was accessible through the "Show deleted blobs" feature, and I could easily manage different versions.

Key Takeaways
Setting up this highly available Azure storage account with public access and blob management features was a valuable exercise in understanding Azure’s storage capabilities. The configuration steps were straightforward, but the impact on data management and accessibility is significant. By leveraging RA-GRS, anonymous access, soft delete, and versioning, I created a robust storage solution that meets the needs of a public-facing application while ensuring data availability and recoverability.