Having worked in the Azure cloud space the past few years, sometimes things just don’t seem to make sense. Take the below situation for example:
A few weeks ago, I was setting up Azure Bastion for an isolated proof of concept network. For those who don’t know, Bastion is a PaaS resource you can setup on an Azure virtual network to provide RDP/SSH connectivity to VMs through the Azure portal. This allows you to access your Azure VMs without having to expose them publicly, while allowing access from any machine via a web browser (ideally you would have MFA enabled for any Azure portal login attempts). Read more from the documentation here.
So, I was trying to set up this Bastion resource in Azure. Not much is required to set it up; you only need a virtual network with an empty /27 (or larger) subnet called “AzureBastionSubnet”. However, every deployment attempt would fail with the below error.
I started looking into why I kept getting this relatively vague error, reading through documentation and other requirements, wondering…
- Is this a region issue?
- Is the name I’m using causing issues?
- Is it a vnet issue?
- What am I missing here?
I deleted/re-deployed Bastion multiple times in various configurations and on different days/times and still got the same error message. Eventually, I opened a case with Azure Support to see if something was going on in the backend or if there’s some hidden configuration I need to set in order for Bastion to work. The engineer asked me to check the resource quotas for our subscription to make sure I had not surpassed the limit on public IP resources.
“There’s no way that could be the issue,” I thought. “We only have 20 public IPs in this subscription!”
And that’s when I learned the initial quota for public IP resources in an Azure subscription is 20.
I submitted a quota increase request for Public IP Addresses and once that was processed I was able to deploy Bastion without issue.
So, if you are trying to deploy an Azure resource and keep getting a failed deployment with an unusual error message, check your subscription quotas. Even better, check them on a routine basis. In this instance the impact was minor, so annoyance and hair-pulling only impacted yours truly. However, had this been a production instance, deployment, configuration…this minor annoyance could have become a significant annoyance for many people.
You can find your current usage information by going to your subscription in the Azure portal and looking for Usage + quotas under the Settings section.
Here you can view all maximums on your subscription as well as a method to Request Increase (which lets you open an Azure support case to request the quota increase). The list can be filtered by Provider, Location, all items or only items with usage, as well as a search field to look for specific resource types. Note the Providers list indicating that only Azure Compute (i.e. VMs), Networking, and Storage resources will have quotas that can be modified.
You may ask yourself, “What’s the point of having quotas if we can just increase them anytime without cost?” The reasoning is, to prevent users from over-deploying resources. You need specific permissions at the subscription level to be able to view/modify resource quotas. So, someone with Reader access granted on the subscription would be able to see the resource usages, but would not be able to submit the support case to request an increase. Or someone who only had access to one or more resource groups would not even be able to view the quota information. This makes it so that a user (or a user compromised by a malicious entity) would not be able to deploy ungodly numbers/sizes for resources like virtual machines.
Thanks for reading! I hope you found this information helpful. If you have any questions related to all things Azure: Azure Site Recovery, Azure cost optimizations, etc., please don’t hesitate to reach out to us. We’d love to talk.