An Azure managed PostgreSQL database service for app development and deployment.
Hi Navneesh Garg (Elevated) & thx for join me at Q&A platform,
the fact that provisioning fails both through IaC and the Azure portal suggests this isn't just a deployment template issue. SkuNotAvailable can mean the requested compute size isn't offered in East US 2, or that it's temporarily unavailable for ur subscription. It doesn't necessarily mean the whole region is blocked.
I'd start by running this against the affected subscription:
az postgres flexible-server list-skus --location eastus2 --subscription <subscription-id>
Check whether Standard_B2ms appears in the Burstable tier. Also, double-check the SKU naming in ur IaC configuration. For PostgreSQL Flexible Server, the usual ARM SKU name is Standard_B2ms, with Burstable specified separately as the tier, rather than B_Standard_B2ms.
Next, verify that Microsoft.DBforPostgreSQL is registered. If the SKU is listed but deployment still fails, try another Burstable size or availability zone, with HA disabled, to see whether the restriction is specific to B2ms.
For a dev environment, Standard_B1ms or Standard_B2s could be reasonable alternatives if they're available. If no Burstable SKU works, testing a small General Purpose SKU can help distinguish a tier-specific restriction from broader regional provisioning problems.
If the problem persists, I'd open a Service and subscription limits (quotas) support request for Azure Database for PostgreSQL Flexible Server. Ask Microsoft to check SKU eligibility, regional capacity, and any subscription-level provisioning restrictions in East US 2. Include the failed deployment's correlation ID and exact error response.
One thing worth mentioning: a quota increase won't necessarily fix SkuNotAvailable. Microsoft needs to confirm whether this is a quota issue, a region access restriction, or unavailable capacity. The public SKU list alone can't confirm live capacity for ur subscription.
rgds,
Alex