Hosting static websites on Azure Blob Storage with CDN integration
Object storage is one of the cloud's great innovations. Azure Blob Storage, the object storage service on Microsoft’s cloud platform, enables secure file storage and supports HTTP access to storage buckets, turning them into web servers for static pages.
Storage buckets, however, are centralized entities located in one data center. Also, their strength is storage, not delivery. To achieve performant and cost-effective hosting, companies need a content delivery network (CDN).
This article will explain how to deploy a static website on Azure Blob Storage and host it with Azure’s content delivery network, Azure CDN, for fast delivery.
Prerequisites
This guide requires an Azure account and one HTML file at a minimum. For the Azure account, most small- to medium-sized websites should be covered by the free Azure tier. As to the HTML file, if you need to create one, simply place the following code into an index.html file:
<!DOCTYPE html>
<title>My Website</title>
<h1>My Website</h1>
Deploying a static website on Azure
A static website consists of files delivered by a web server, so you need a way to store these files on Azure and send them to your users. Since no server-side rendering is required, you can build a stack with just four Azure resources.
- A storage account to manage your storage containers
- A storage container to store your website
- A CDN profile to manage your CDN endpoints
- A CDN endpoint to deliver your website
Creating an Azure storage account
To deploy a static website on Azure, you will also require a storage account. So, open the Azure Storage Accounts page in your browser, and click the blue “+Create” button on the top right.
Fig. 1: Azure storage account page
Fill out the storage account creation form, as seen in figure 2 below, making sure your storage account name is unique. For this tutorial, select “Basic Subscription,” “Standard” performance, and “Locally-redundant storage (LRS)” so that you do not incur unnecessary costs.
Click on the “Review + create” button, and after Azure validates your inputs, select the “Create” button to start the provisioning process.
Fig. 2: Storage account creation form
Provisioning a new storage account takes half a minute for Azure; after that, you can click the “Go to resource” button to configure the account access settings.
Navigate down to the “Settings” section on the left-hand side, and click the “Configuration” entry. This will open the account settings, where you must set the “Allow Blob anonymous access” to “Enabled” and click the “Save” button at the top.
Fig. 3: Storage account settings
With this storage account, you can create public storage containers.
Creating a storage container
Under “Data storage” on the left side of the page, click on “Containers.” Above the almost empty list of storage containers is a “+Container” button, which you can click to create a new container.
Fig. 4: Storage containers
Next, give your container a name in the “New container” form and select the “Anonymous access level” of “Container” to ensure the CDN can access files in that container. Click the “Create” button, and Azure will provide the new container instantly.
Fig. 5: New container form
Deploying the website to Azure
After the storage container is ready, select it from the list to open the container details and click “Upload.” In the popup that appears, choose the files you want to upload and then “Upload” again.
Fig. 6: Container details
Testing the website on Blob Storage
After you deploy the website, you should check that you can access it. Select one of the uploaded files from the list, copy the URL from the properties, and paste it into a new browser tab to test it.
Fig. 7: File properties
Improving website delivery with Azure CDN
After the above steps, Azure is now hosting your website. Still, Azure Blob Storage is only in one region, which can impact the latency for users far from that region. To resolve this issue, let’s put Azure CDN in front of your container. The CDN will replicate your website to Azure’s edge locations, which are closer to your users, giving them a lower latency when visiting your website.
Creating an Azure CDN profile and endpoint
First, you will need an Azure CDN profile for your website, so go to the Azure Storage Account page and select your storage account from the list. In the navigation bar on the left, scroll down to the “Security + networking” section and select the “Front Door and CDN” entry.
Fig. 8: Storage account navigation bar
In the “New Endpoint” form, select the “Azure CDN” service type and give your CDN profile and endpoint a name. As you are deploying a static website, you can choose “Ignore Query String” for the desired caching behavior.
Fig. 9: New Endpoint form
Click “Create,” wait for Azure to provision your CDN resources, then select “Go to resource.”
Note: Azure CDN takes up to 1 hour to load your website from your container. You must wait longer if you get a “Page not found” error.
Testing the website with Azure CDN
You will have to construct a CDN URL to test your website with Azure CDN.
Select the new endpoint from the list and copy the endpoint's hostname on the right. It should look like this:
https://<CDN_ENDPOINT_NAME>.azureedge.net
To create a CDN URL for your website, add your container name and the name of a file you uploaded to the hostname:
https://<CDN_ENDPOINT_NAME>.azureedge.net/<CONTAINER_NAME>/<FILE_NAME>
Now, open a new browser tab and paste the URL to open your website through Azure CDN.
Advanced deployment strategies
Now that you have learned how to deploy a website with Azure Blob Storage, let’s examine some advanced deployment strategies, how they work, and the benefits they bring to your deployment process.
Blue-green deployments
As the name implies, with blue-green deployments, you always have two servers: blue and green.
You deploy your first release to green and route all traffic to green. For the next release, you deploy to blue, and if the deployment is successful, you route all traffic from green to blue. If a deployment takes a long time or fails, there is always one server online that handles user requests. Also, you always have the current and the previous version deployed, so you can switch back to the previous version if you detect problems with the current one later.
One way to create a blue-green deployment on Azure Blob Storage is to create two storage accounts, each with a container of the same name. Then, you will be alternating deployments between the two containers. If a deployment is complete, you switch the CDN endpoint from the currently active storage account to the inactive one. You can access your new deployment before the switch through the container URL; this way, you can test it before activating it.
Canary deployments
This deployment strategy is similar to the blue-green one. You have two servers in your production environment, but instead of calling them green and blue, you call them current and canary. Current is where you route all users, while canary is where you deploy your next release.
The difference versus blue-green is that you route users gradually to the canary. Starting with 10% of all users, then 20%, and so on, until 100% are on the canary server. After all users are switched over, the canary becomes the new current server and the old current becomes the canary.
As with blue-green, you have two releases deployed and can always switch back to the previous version if you encounter errors later on; however, in contrast to blue-green, you might detect errors before all users see the new release, so only a fraction of them will be affected.
To realize canary deployments with Azure Blob Storage, you need two storage accounts for a canary deployment, as well as containers, CDN profiles, endpoints, and an Azure Traffic Manager. The deployment works the same as a blue-green deployment: You alternate between the two containers when deploying your website.
However, after the deployment is complete, you gradually adjust the Traffic Manager weight to redirect users to the new CDN endpoint. First 1000:1, then 900:100, then 800:200, etc., until 1:1000. If something goes wrong, you switch back instantly to 1000:1 to roll back to the previous deployment.
A/B test deployments
This deployment strategy is like the canary deployment, as you show some users one version of your website and some another version. However, in contrast to canary deployments, where your goal is to move all your users to a new version, you want to test two versions of the same website and see which performs better for various metrics. For example, you could build two landing pages and see which leads to more subscriptions for your service.
The cloud resources required for an A/B-test deployment are the same as those needed for a canary deployment; the difference is that you use a fixed weight in the Traffic Manager. For example, 1000:1000, so 50% of your users see the A version of your page and 50% see the B version. If you are confident one performs better, you can then move 100% of your users to that version and delete the other.
What are the security benefits of using a CDN?
If your website is behind a CDN, it is protected from distributed denial of service (DDoS) attacks because the CDN consists of multiple globally distributed servers and controls the routing from a DNS name to these servers. If someone starts an attack on one of the servers, the network can isolate it and serve users from a different server.
The Azure CDN supports the Azure Web Application Firewall (WAF), which protects your apps from common threats. While direct hacks are not usually an issue with static websites, a WAF can help by filtering access to your website based on geolocation or IP range, for example, if you can’t serve your content in a particular country.
Summary
Hosting a static website on Azure Blob Storage and improving its delivery with Azure CDN is a quick and easy way to get your content online and ensure it’s quickly accessible for your users and not susceptible to DDoS attacks.
With more effort, you can also implement advanced deployment strategies that improve your website's resilience or allow you to test new features in a controlled way.