Premium or Standard API Management Tiers on Non-Production Instances

Dedicated tiers are charged per unit regardless of how much traffic the instance serves, so a lower environment that handles a few test calls a day costs the same as a busy production gateway of the same size.

Microsoft positions the Developer tier for non-production use and evaluation (it has no SLA and a single unit) and the Basic v2 tier for development and testing with an SLA. The Well-Architected guidance for API Management tells teams to use the least expensive tier that meets requirements, to use nonproduction tiers in lower environments and to scale in when demand drops. Premium features such as multi-region deployment, availability zones, virtual network injection and self-hosted gateways are often justified in production but rarely needed in a dev instance.

The API Management cost model is mainly driven by the service tier, the number of units and the number of gateways.

Dedicated tier unit

Each unit of a Developer, Basic, Standard, Premium or v2 tier instance carries a fixed per-unit price whether or not the instance serves traffic

Included requests

Basic v2 and Standard v2 include a monthly allocation of API requests and charge per million requests beyond it

Developer tier

Intended for non-production use cases and evaluations, with no SLA and no ability to add units

Basic v2 tier

Designed for development and testing scenarios and comes with an SLA

• List API Management instances by SKU name and capacity (units) with Azure Resource Graph (type microsoft.apimanagement/service) and join with environment tags or subscription names to find Standard, Premium, Standard v2 or Premium v2 instances in dev, test or sandbox scopes
• Flag non-production instances with more than one unit, or production instances whose Capacity metric (classic tiers) or CPU Percentage of Gateway and Memory Percentage of Gateway metrics (v2 tiers) stay low while unit count stays constant
• For Premium instances, check whether additional regions, availability zones, virtual network injection or self-hosted gateways are actually configured; if none are, the Premium tier is not buying anything the lower tiers lack
• Check whether autoscale rules exist on instances in tiers that support autoscaling

• Move non-production classic-tier instances to the Developer tier from the Pricing tier blade; tier changes among classic tiers are supported in place, but scaling from or to Developer causes downtime and Developer has no SLA
• For teams that need an SLA or v2 features in lower environments, use Basic v2. There is no automated migration from classic tiers to v2, so this means creating a new instance and redeploying APIs, for example through an APIOps pipeline
• Reduce units on non-production instances to the minimum, and configure autoscale rules on production instances so units scale in when capacity drops
• Where isolation requirements allow, serve several teams or environments from shared instances using workspaces instead of one dedicated instance each
• Review downgrade side effects before changing tier: moving from Premium to Standard or Basic removes virtual network and multi-region configuration

• Architecture Best Practices for Azure API Managementlearn.microsoft.com
• Feature-based comparison of Azure API Management tierslearn.microsoft.com
• Azure API Management - V2 Tierslearn.microsoft.com
• Upgrade and scale an Azure API Management instancelearn.microsoft.com
• API Management pricingazure.microsoft.com