What is the best practice for defining regions for resources with creating a marketplace managed application?

Jason Hazelton 20 Reputation points
2025-10-03T13:29:07.1533333+00:00

The end-user will choose the region in which to create the managed resource group when purchasing a marketplace offer.

As a publisher, I can control what regions are available to select via the createUiDefinition file, but I ran across an interesting problem in my testing of PostgresDB Flexible Servers. The resource may be generally available in a region, but there may be quotas or capacity limitation, all of which are dynamic and change over time. Similarly, Ai Foundry models are limited to a subset of regions.

My commercial managed application is to include both AI Foundry models and PostgresDB Flexible server. The regions where both are currently available are limited and none of those regions are in Canada, for example.

I have created virtual networks in my template, across several regions, and peered them together. I have used nested templates to be able to specify the regions needed and avoid the validation errors that fail if a region is hardcoded in the main template.

None of this seems sustainable. It is foreseeable that my template will fail to deploy in the future if the capacity to deploy the database in the region I have specified goes down to zero.

Is there a mechanism to dynamically search, identity, and filter (by country ideally) regional resource availability within the ARM template and assign regions dynamically within my nested templates?

Azure Managed Applications
Azure Managed Applications
An Azure service that enables managed service providers, independent software vendors, and enterprise IT teams to deliver turnkey solutions through the Azure Marketplace or service catalog.
0 comments No comments
{count} votes

Answer accepted by question author
  1. Michele Ariis 6,260 Reputation points MVP
    2025-10-03T15:30:15.83+00:00

    Hi, ARM/Bicep can’t dynamically discover live regional capacity or auto-pick regions at deploy time, so the best practice is to

    1-restrict selectable regions via createUiDefinition + Offer/Plan targeting and, if needed, Azure Policy;

    2-architect for mixed-region deployments, keep the managed resource group in the customer’s chosen region but pin AI Foundry/OpenAI and other region-limited services to your supported regions and connect via Private Link/peering;

    3-run an early deploymentScripts preflight (or a prereq job in your SaaS/landing page) that calls each RP’s capabilities endpoints (e.g., Postgres Flexible Server “locations/capabilities”) and SKU/feature listings to validate support, then fail fast with a clear, actionable message if the chosen region can’t host all components;

    4-document quota prerequisites and surface graceful retry/instructions to request quota increases, because transient capacity/quotas aren’t queryable or enforceable from ARM templates.

    0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.