Starting this project, I was not as lost as I was with the first one.
If you haven't seen the first one, here it is:
This time I had some familiarity coming in. The first thing I did was explore the Azure portal, clicked around, created a Resource Group, setup an App Service, and it worked.
Then I moved on to the CLI, which is where things started to feel funny.
First Attempt: Azure Cloud Shell
My first attempt was with Azure Cloud Shell. It did not feel natural to me. My main confusion was around shell scripts. I was not sure if I could write and run a deploy script from inside Cloud Shell.
In hindsight, the answer is yes. You can use a text editor like Vim/Emacs right inside Cloud Shell and execute your script from there. But I did not think of that at the time.
So I moved on to installing the Azure CLI locally on my machine.
That took a couple of days on its own, but working on my local machine felt more natural. The first installation method I tried did not work. I eventually got it working, moved into VS Code, and started writing my deploy script properly.
The Goal
Take the same static website I built for Project 1 and deploy it to Azure using the Web App Service, across two different regions.
I wrote a deploy.sh script and a destroy.sh script. The destroy script is the habit that saves you from racking up charges on resources you forgot about.
The script flow followed Azure's hierarchy:
- Create a Resource Group, every resource on Azure must belong to one
- Create an App Service Plan, this is where you choose the OS for your web app
- Create the Web App on top of that plan
- Deploy your files
The App Service Plan is worth understanding properly. It is not just a billing tier. Even though we are working with Platform as a Service, meaning we are not managing the underlying infrastructure ourselves, we still choose the operating system. Azure handles everything below that.
Getting West Europe Working
Getting the West Europe deployment working took some back and forth with the commands. Some flags I used were not recognized by my version of the CLI, and some runtime options that older documentation referenced no
longer exist.
Static site hosting on a Web App Service Plan with a Linux OS, for example, is not supported. The Web App Service Plan works with Windows OS for deploying static sites. Each of these were small walls that required reading error messages carefully, researching, and adjusting.
The Wall: East US Quota Limits
The second half of the challenge was deploying to a second region, East US.
I expected it to work the same way West Europe did. It did not.
The error I kept hitting was about quota. Specifically, the Total VMs limit for East US was set to zero on my subscription. No VMs available meant no App Service Plan could be created, which meant no deployment.
My first instinct was that maybe the SKU was the problem. I was using F1, which is the free tier. I went into the Azure portal and looked through the quota section under the Web App provider. I could see that certain SKUs like P1V4 had limits of 10 or 30 in that region, while F1 was sitting at zero.
I changed the SKU in my script to one of those available tiers, ran the script again, and hit the same wall. The error was not about the SKU specifically. It was about the Total VM quota for the region, and that articular quota had no option to adjust the limit from the portal.
The Rabbit Hole: Resource Providers
Around this time I started paying closer attention to how Azure
organizes its services. I came across Resource Providers, which I had not really thought about before.
Every Azure service belongs to a provider namespace:
-
Microsoft.Webfor App Services -
Microsoft.Computefor Virtual Machines
Before you can use any service, the corresponding provider needs to be registered on your subscription. On a free account, some providers are not registered by default, and quotas are locked.
I went down the rabbit hole of manually registering the Compute
provider, only to discover that the Web provider I actually needed had already been registered automatically.
It was a detour, but it was a useful one.
Upgrading to Pay As You Go
I upgraded from the free tier to Pay As You Go. I still have my $200 free credit for the first 30 days, so the cost risk was manageable.
After upgrading, the provider situation improved and quotas became adjustable.
But the East US Total VM limit was still at zero and still had no adjustment option in the portal. I reached out to Microsoft engineering support and submitted a formal quota increase request for two instances.
That request is still being processed.
Finding a Different Path
While that was still on, I found a different path.
Since what I am deploying is a static website, Azure has a dedicated Static Web Apps service that sits outside the App Service quota system entirely. I deployed to it and it worked without hitting any quota restrictions at all. I was able to deploy to two different regions successfully using that service.
I also went back and tested West Europe with the original Web App Service approach, and it worked there as well. So I now have deployments running across multiple regions through two different methods.
The Unanswered Question
As a Pay As You Go subscriber, I would expect to be able to deploy to any region Azure offers. But right now I am restricted to one region for Web App Service deployments while the quota request gets processed.
If anyone has run into this and know the reason for this, I would genuinely like to know. It is the kind of thing that would matter on a real project with a deadline.
Read the Full Project
You can have a look at the project by clicking the link below:
EmmanuelAjibokun
/
Azure-Web-App
A small web application (a static site is fine; even better, a "Hello, [your name]" Flask app) deployed into Azure App Service in two regions, behind a Resource Group you provisioned entirely from the Azure CLI — no portal clicks for the deployment itself.
Azure Web App
Deploy a Node.js app to Azure using the Azure CLI. This repo contains two deployment scripts:
-
deploy-app.sh — deploys the local Node.js app from the
app/folder usingaz webapp up - deploy-static.sh — provisions a Static Web App (East US 2) and a Web App from GitHub (West Europe)
Prerequisites
Quickstart
1. Clone the repo
git clone https://github.com/EmmanuelAjibokun/cloud-eng.git
cd azure-web-app
2. Log in to Azure
az login
3. (Optional) Set your active subscription
az account list --output table
az account set --subscription "<your-subscription-id>"
Option A — Deploy the local Node.js app
This deploys the app/ folder directly to an Azure Web App using az webapp up.
chmod +x deploy-app.sh
./deploy-app.sh
What it does:
- Checks that you are logged in to the Azure CLI — exits with an error if not
- Checks if
cloud-decision-eastis already…
If you would like to follow along on the learn-by-doing journey,
comment "github" and I will send you the project guide link. Kindly star the project and follow me on GitHub.
EmmanuelAjibokun (Emmanuel Ajibokun ) · GitHub
A computer programming enthusiast, Geologist by field of study and a fast learner - EmmanuelAjibokun
github.com
Top comments (0)