How to Fix Azure Region Access Issues
Why Azure Region Access Issues Happen
You log into the Azure portal, pick a region to deploy your resources, and it's just... not there. Or it's greyed out. Or you can see it, but every attempt to spin up a VM throws an error about quota limits and restricted access. I've seen this exact situation trip up engineers at every experience level , from developers standing up their first cloud workload to seasoned Azure architects trying to expand into new geographies for a global rollout.
Here's the truth: not all Azure regions are open to everyone by default. Microsoft restricts access to certain regions for a few very specific reasons , capacity management, compliance requirements, and sovereign data regulations being the big three. Some regions, like those in politically sensitive geographies or newly launched datacenters, go through what Microsoft calls a "reserved access" process. You don't just get in by signing up. You have to ask.
Then there's the separate, but equally confusing, problem of Azure dependency availability. This one catches a lot of people off guard. Certain Microsoft features and compliance tools, like Insider Risk Management, Microsoft Purview Information Protection, autolabeling for sensitivity labels, and communication compliance, depend on Azure infrastructure that is only available in specific primary countries and regions. If your tenant's primary country isn't on the supported list, those features simply won't work, and Microsoft doesn't always make that obvious in the UI.
As of October 2024, the countries where Azure dependencies for these advanced features are available include Australia, Brazil, Canada, France, Germany, Italy, Israel, India, Japan, Norway, Poland, Qatar, Singapore, South Africa, South Korea, Sweden, Switzerland, the United Arab Emirates, the United Kingdom, and the United States. If your organization's primary country is Taiwan or New Zealand, you're in the pipeline, those regions are listed as coming soon, but check the Microsoft Message Center for the actual timeline.
The frustrating part is that the Azure portal error messages in these situations are almost never clear about why something is blocked. You get quota errors that look like billing problems, access errors that look like permission issues, and feature absences that look like bugs. It's a mess, and I know how much time that ambiguity wastes. Let's break it down properly and get you unblocked. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're trying to access an Azure region that isn't appearing in your subscription's deployment dropdown, or you're getting a "region not available" error on VM creation, the fastest way to resolve this is to file a support request through the Azure portal itself. You do not need to call Microsoft or email anyone. The entire Azure region access request process lives inside the portal, and when you do it correctly, it routes directly to the Azure Engineering team for review.
Here's the condensed version for those of you in a hurry:
- Log into portal.azure.com and go to Help + support in the left-side navigation menu.
- Click Create a new support request.
- Set Issue Type to Service and subscription limits (quotas).
- Choose the subscription you want to enable the region for.
- Set Quota type to Compute-VM (core-vCPUs) subscription limit increases.
- Hit Next, then Enter details in the Problem details section.
- Select your deployment mode, pick the target region or regions, choose your VM series, and set a vCPU limit that reflects your actual planned usage.
- Save, enter your contact information, set a severity level, and submit.
If the region you need isn't even showing up in the region picker during step 7, that means you're dealing with a reserved access region. Scroll down to Step 4 in this guide, that process is slightly different and requires a free-text description in the Other Requests quota type.
One thing to be aware of: this is not an instant approval. Microsoft routes the ticket through their Azure Engineering team for validation. Make sure your contact details are current in the support ticket, they will reach out if they need more information about your intended workload.
Start by logging into the Azure portal at portal.azure.com. Once you're in, look at the left-side navigation bar and scroll down to find Help + support, it's usually near the bottom of the sidebar. If you don't see it pinned there, you can search for it using the search bar at the top of the portal (the one that says "Search resources, services, and docs").
Inside Help + support, click the blue Create a new support request button. This opens the support request wizard, which is a multi-step form. Don't close this tab during the process, the portal doesn't autosave between sessions.
On the first screen, you'll see a field labeled Issue Type. This is where most people make their first mistake, they choose "Technical" thinking that region access is a technical problem. It's not. You need to select Service and subscription limits (quotas). This routes your ticket to the right team internally and unlocks the correct quota-type fields you'll need in the next step.
Next, in the Subscription field, select the specific Azure subscription you want region access enabled for. If you manage multiple subscriptions, common in enterprise environments, pick the primary one here. You can include additional subscription IDs in the description section later without filing separate requests.
Click Next to move forward. If everything is filled in correctly, you should see a new page asking for quota type. If that page doesn't appear and you get an error, double-check that the subscription you selected is in an active billing state, suspended subscriptions can't generate quota requests.
This step is where the Azure region access request process branches depending on what you're trying to do. There are two scenarios, and mixing them up will send your ticket to the wrong team.
Scenario A, Standard region access (region exists in the picker but you can't deploy): Set the Quota type field to Compute-VM (core-vCPUs) subscription limit increases. This is the standard path for most region access requests. It tells Microsoft that you want to increase your compute quota in a specific geography, which effectively grants access to spin up resources there.
Scenario B, Reserved access region (region doesn't appear at all in the portal): Set the Quota type field to Other Requests. Reserved access regions require a different internal review process through Azure Engineering, and the "Other Requests" quota type routes the ticket correctly. See Step 4 for the specific description format required for these requests.
Once you've selected the right quota type, click Next. The portal will take you to the Problem details section. Here, you'll see an Enter details link, click it. This opens a side panel where you configure the actual region, VM types, and quota numbers. Don't skip this panel; without it, your request will be incomplete and Microsoft will bounce it back for more information.
If the Enter details link doesn't appear, try refreshing the page and re-selecting your quota type. This is a known minor UI quirk in the support portal that occasionally requires a re-selection to trigger properly.
Inside the Enter details side panel, you'll work through three key fields that determine exactly what access you're requesting. Take your time here, accuracy speeds up approval significantly.
First, select your deployment mode. For almost all modern Azure deployments, this should be ARM (Azure Resource Manager). Classic deployments are legacy and largely deprecated. If your organization is still on Classic, talk to your Azure administrator before proceeding, because the migration path is a separate workstream.
Next, select the region or regions you want access to. You can select multiple regions in a single request, this is recommended if you're planning a multi-region architecture, since it avoids filing separate tickets. After selecting your regions, the panel will ask you to specify the VM series you plan to deploy. Be specific. If you know you'll need Dv3, Ev4, and Fsv2 series, list all of them. Vague requests get follow-up questions from the engineering team, which adds days to your approval timeline.
Finally, set the new vCPU limit you're requesting. Microsoft's recommended starting baseline for organizations unsure of their exact needs is 25 cores for compute, plus 10TB storage and a standard SQL SKU like S0 with up to 20 databases per SKU. These numbers aren't binding, you can always request increases later, but starting with a realistic estimate means you can begin deploying immediately after approval rather than hitting limits on day one.
Click Save and continue when done. The side panel closes and you'll return to the main form. You should now see a summary of your details, verify them before moving to the next step.
If you're requesting access to a reserved access region, the kind that simply doesn't appear in your Azure portal's region picker, you need to follow a different description format. Microsoft is explicit about this: use Other Requests as the quota type, and the description text must follow a specific template for the ticket to be routed and processed correctly.
In the description field, use this exact format:
Request access for the Azure [Region Name] Region for [Your Organization Name].
Deployment Model: ARM
Planned VM types: [e.g., Dv3 Series, Ev4 Series]
Planned Compute usage in Cores: [number]
Planned Storage usage in TB: [number]
Planned SQL Database SKU: [e.g., S0]
Planned No. of Databases per DB SKU: [number, max 20 per SKU]If you also need Reserved Instances enabled in the new region, include that in the same ticket rather than filing separately. Add a section like this:
Reserved Instance Region Enablement:
Subscription ID: [your subscription ID]
Region: [region name]
VM Series: [e.g., Dv2]
Planned usage in Cores: [number]Similarly, if you need SQL Data Warehouse access, include:
SQL Data Warehouse:
Subscription GUID: [your GUID]
Region: [region name]If you're requesting access for multiple subscription IDs, list all additional subscription IDs in the description here. Microsoft will combine them into a single review rather than making you file one ticket per subscription. This is a significant time-saver in enterprise environments with 10, 20, or 50+ subscriptions. Once compute access is approved, associated services like App Services and Azure Functions are automatically unlocked in that region as well, you won't need to file separate requests for those.
To find which regions require this reserved access process, check the official Azure paired regions documentation directly on Microsoft's site.
You're almost done. The final step before submission is setting the severity level and entering your contact information. Don't treat these fields as formalities, they directly affect how quickly your ticket moves through the queue.
For severity, be honest about your urgency. If this region access is blocking a production deployment or a time-sensitive client project, set it accordingly. Overstating severity on a non-urgent request can work against you over time, Microsoft support teams track these patterns. That said, if you genuinely are blocked and there's a business impact, don't downplay it either.
For contact details, use an email address and phone number that is actively monitored. I cannot stress this enough: the Azure Engineering team may reach out during the review process to ask about your intended workload, and if they can't reach you, the ticket stalls. I've seen requests sit in limbo for two weeks simply because the email address on file was a generic team inbox that nobody checked. Use your direct contact.
Click Create to submit. You'll get a ticket number immediately, and an email confirmation should arrive within a few minutes at the address you provided.
Once submitted, the ticket enters Microsoft's standard support routing workflow, with a stop at the Azure Engineering team for validation. This is not a rubber-stamp process, they genuinely review the request and may ask follow-up questions. After approval, the Azure region will appear in your portal's region picker, and you can begin deploying resources exactly as you would in any other region. Monitor your support ticket status through the Help + support > All support requests view in the Azure portal.
Advanced Troubleshooting for Azure Region Access
Multiple subscriptions in an enterprise tenant, This is the most common complexity I see in large organizations. If you're managing an EA (Enterprise Agreement) or MCA (Microsoft Customer Agreement) with dozens of subscriptions, you don't need a separate support ticket per subscription. Include all additional subscription IDs in the description field of a single request. Microsoft support will consolidate them during review. The exception is if your subscriptions are under fundamentally different billing profiles or management groups with different owners, in that case, separate tickets may actually move faster.
Azure dependency features not appearing even after region access is granted, This is a different problem from the region access request process. Features like Insider Risk Management, Microsoft Purview Information Protection, and communication compliance have a hard dependency on Azure infrastructure that is tied to your tenant's primary country/region, not just which region you deploy into. If your tenant's primary country is not on the approved list (Australia, Brazil, Canada, France, Germany, Italy, Israel, India, Japan, Norway, Poland, Qatar, Singapore, South Africa, South Korea, Sweden, Switzerland, UAE, UK, or USA as of October 2024), these features won't work regardless of which region you deploy resources into.
The fix here is not a support request for region access. It's either waiting for your country's enablement (check the Microsoft Message Center for timelines, Taiwan and New Zealand are confirmed as coming soon) or, for organizations with compliance requirements that can't wait, working with your Microsoft account team to evaluate tenant migration options.
Support ticket stuck in "In Progress" for more than 5 business days, This usually means the engineering team has questions and either couldn't reach the contact on file or the email went to spam. Check your junk folder first. Then log back into the portal, navigate to Help + support, and open the ticket. Use the Add a note or Reply function to proactively confirm your contact details and re-state your request. This almost always unsticks the ticket within 24–48 hours.
VM deployment fails with "QuotaExceeded" error after region access is approved, Region access approval and quota approval are sometimes processed separately. If you're seeing a QuotaExceeded or OperationNotAllowed error after your region was supposedly enabled, file a follow-up ticket specifically for quota increases in that region. Reference your original ticket number in the description.
Tracking region enablement timelines for your country, The Microsoft Message Center inside the Microsoft 365 admin center is the authoritative place for this. Filter by "Azure" service category and look for posts tagged with your region name. The Message Center posts timelines before they appear in any public documentation.
Prevention & Best Practices for Azure Region Access
The best time to request Azure region access is before you need it, ideally during your architecture planning phase, not the week before a go-live. I've watched more than a few project timelines slip because region access requests were treated as a five-minute formality and got filed the day before deployment, only for the team to discover they were dealing with a reserved access region that needed engineering review.
Build region access requests into your project intake checklist. Any project targeting a new Azure geography should have "file region access request" as a task in the first sprint, not the last. This gives you two to four weeks of buffer, which is generally more than enough for standard requests. Reserved regions can take longer, so for those geographies, push the request even earlier.
When planning your vCPU quota, think 12 months ahead, not just for the initial deployment. Azure quota increases are not automatic as you scale, you'll need to request them. A common pattern is to request 2–3x your initial deployment size upfront, so that scaling up doesn't require another approval cycle at the worst possible moment (usually during a traffic spike or a client demo).
For organizations managing Azure dependency features like Insider Risk Management or Microsoft Purview, verify your tenant's primary country/region setting before building any compliance workflow that depends on those features. This setting is set at tenant creation and is not trivially changed. Knowing your tenant's primary country early prevents you from designing security architectures around features you can't actually access yet.
Finally, maintain a living document of all open and approved quota requests across your subscriptions. The Azure portal doesn't give you a great consolidated view of your quota state across multiple subscriptions without using Azure Monitor or the Quotas blade (search "Quotas" in the portal search bar). Set a calendar reminder to review your quota headroom quarterly, running into a hard limit in production is entirely avoidable.
- File Azure region access requests during project planning, not the week before launch, standard approvals typically take 2–5 business days
- Include all subscription IDs in a single support request to avoid filing duplicate tickets and to get consolidated approval
- Monitor the Microsoft Message Center for region enablement timelines, it's updated before public documentation and gives you the most accurate rollout dates
- Use the Quotas blade in the Azure portal to get a current snapshot of vCPU headroom across your subscriptions before planning any large-scale deployment
Frequently Asked Questions
Why is a specific Azure region not showing up in my deployment dropdown at all?
If a region is completely absent from your region picker, you're most likely dealing with a reserved access region. These are regions that Microsoft restricts by default and requires customers to request access through a formal support process. The fix is to file a support request using the Other Requests quota type, not the standard Compute-VM quota type. In the description, explicitly state "Request access for the Azure [Region Name] Region for [Your Organization Name]" and include your planned deployment specs. Check the Azure paired regions documentation to confirm whether your target region is on the restricted list before filing.
How long does it take for an Azure region access request to get approved?
Standard region access requests (using the Compute-VM quota type) typically resolve within 2–5 business days. Reserved access regions take longer because they require a validation stop with the Azure Engineering team, which can run 5–10 business days or more depending on the complexity of the request and how quickly the engineering team can reach your contact. If your ticket has been sitting for more than 10 business days with no updates, log back into the portal and add a note to the ticket re-confirming your availability, this usually restarts the review within 24–48 hours.
I have 30 Azure subscriptions, do I need to file 30 separate region access requests?
No, and you really shouldn't. Microsoft explicitly supports multi-subscription requests in a single ticket. File one support request for your primary subscription, then list all additional subscription IDs in the description field. Microsoft support will combine them on their end and process the access grant for all listed subscriptions at once. This is faster and avoids the coordination overhead of managing 30 separate ticket threads. If your subscriptions span different billing profiles or EA enrollments, check with your Microsoft account team first, there may be nuances to how access grants propagate in those cases.
Why are features like Insider Risk Management and Microsoft Purview not working even though my region access was approved?
Azure region access and Azure dependency availability are two separate things. Features like Insider Risk Management, Microsoft Purview Information Protection, communication compliance, and autolabeling for sensitivity labels depend on infrastructure tied to your tenant's primary country/region, not just the region you deploy into. As of October 2024, these features are only available in tenants whose primary country is one of 20 supported countries (Australia, Brazil, Canada, France, Germany, India, Israel, Italy, Japan, Norway, Poland, Qatar, Singapore, South Africa, South Korea, Sweden, Switzerland, UAE, UK, or USA). If your tenant's primary country isn't on that list, the features will be unavailable regardless of region access. Monitor the Microsoft Message Center for when your country gets added.
My Azure region access request was approved but VMs still fail to deploy, what do I do?
Region access approval and vCPU quota approval can sometimes be processed as separate items, even when submitted in the same ticket. If you're seeing a QuotaExceeded or OperationNotAllowed error after your region was enabled, the quota increase for that specific VM series may not have gone through. Open a follow-up support request, use the Compute-VM quota type again, reference your original ticket number in the description, and explicitly request the vCPU quota for the region and VM series that's failing. This is usually resolved quickly once you identify the specific bottleneck.
Where can I find out when Azure dependency features will be available in my country?
The most reliable source for this is the Microsoft Message Center, accessible from the Microsoft 365 admin center at admin.microsoft.com. Filter posts by the Azure or compliance service area and search for your country or region name. Microsoft posts enablement timelines there before they appear in public-facing documentation. As of the latest official guidance, Taiwan and New Zealand are confirmed as upcoming additions to the Azure dependency availability list, but the Message Center will have the precise dates. Do not rely on the main Azure documentation pages for timeline accuracy; they lag behind the Message Center by weeks or months.