Azure API Management v2 tiers
APPLIES TO: Basic v2 | Standard v2 | Premium v2
The API Management v2 tiers (SKUs) are built on a new, more reliable and scalable platform and are designed to make API Management accessible to a broader set of customers and offer flexible options for a wider variety of scenarios. The v2 tiers are in addition to the existing classic tiers (Developer, Basic, Standard, and Premium) and the Consumption tier. See detailed comparison of API Management tiers.
The following v2 tiers are generally available:
Basic v2 - The Basic v2 tier is designed for development and testing scenarios, and is supported with an SLA.
Standard v2 - Standard v2 is a production-ready tier with support for network-isolated backends.
The following v2 tier is in preview:
Premium v2 - Premium v2 offers enterprise features including full virtual network isolation and scaling for high volume workloads.
Note
The Premium v2 tier is currently in limited preview. To sign up, fill this form.
Key capabilities
Faster deployment, configuration, and scaling - Deploy a production-ready API Management instance in minutes. Quickly apply configurations such as certificate and hostname updates. Scale a Basic v2 or Standard v2 instance quickly to up to 10 units to meet the needs of your API management workloads. Scale a Premium v2 instance to up to 30 units.
Simplified networking - The Standard v2 and Premium v2 tiers provide networking options to isolate API Management's inbound and outbound traffic.
More options for production workloads - The v2 tiers are all supported with an SLA.
Developer portal options - Enable the developer portal when you're ready to let API consumers discover your APIs.
Features
API version
The latest capabilities of the v2 tiers are supported in API Management API version 2024-05-01 or later.
Networking options
Standard v2 and Premium v2 support virtual network integration to allow your API Management instance to reach API backends that are isolated in a single connected virtual network. The API Management gateway, management plane, and developer portal remain publicly accessible from the internet. The virtual network must be in the same region and subscription as the API Management instance. Learn more.
Premium v2 also supports simplified virtual network injection for complete isolation of inbound and outbound gateway traffic without requiring network security group rules, route tables, or service endpoints. The virtual network must be in the same region and subscription as the API Management instance. Learn more.
Supported regions
For a current list of regions where the v2 tiers are available, see Availability of v2 tiers and workspace gateways.
Classic feature availability
Most capabilities of the classic API Management tiers are supported in the v2 tiers. However, the following capabilities aren't supported in the v2 tiers:
- API Management service configuration using Git
- Back up and restore of API Management instance
- Enabling Azure DDoS Protection
- Direct Management API access
Limitations
The following API Management capabilities are currently unavailable in the v2 tiers.
Infrastructure and networking
- Multi-region deployment
- Multiple custom domain names
- Capacity metric - replaced by CPU Percentage of Gateway and Memory Percentage of Gateway metrics
- Built-in analytics - replaced by Azure Monitor-based dashboard
- Autoscaling
- Inbound connection using a private endpoint
- Upgrade to v2 tiers from classic tiers
- CA Certificates
Developer portal
- Reports
- Custom HTML code widget and custom widget
- Self-hosted developer portal
Gateway
- Self-hosted gateway
- Quota by key policy
- Cipher configuration
- Client certificate renegotiation
- Free, managed TLS certificate
- Requests to the gateway over localhost
Resource limits
The following resource limits apply to the v2 tiers.
To request a limit increase, create a support request from the Azure portal. For more information, see Azure support plans.
| Resource | Basic v2 | Standard v2 | Premium v2 |
|---|---|---|---|
| Maximum number of scale units | 10 | 10 | 30 |
| Maximum cache size per service instance | 250 MB | 1 GB | 5 GB |
| Maximum number of APIs per service instance | 150 | 500 | 2,500 |
| Maximum number of API operations per service instance | 3,000 | 10,000 | 20,000 |
| Maximum number of subscriptions per service instance | 500 | 2,000 | 4,000 |
| Maximum number of products per service instance | 50 | 200 | 400 |
| Maximum number of users per service instance | 300 | 2,000 | 4,000 |
| Maximum number of groups per service instance | 20 | 100 | 200 |
| Maximum number of authorization servers per service instance | 10 | 500 | 500 |
| Maximum number of policy fragments per service instance | 50 | 50 | 100 |
| Maximum number of OpenID Connect providers per service instance | 10 | 10 | 20 |
| Maximum number of certificates per service instance | 100 | 100 | 100 |
| Maximum number of backends per service instance | 100 | 100 | 100 |
| Maximum number of caches per service instance | 100 | 100 | 100 |
| Maximum number of named values per service instance | 100 | 100 | 100 |
| Maximum number of loggers per service instance | 100 | 100 | 100 |
| Maximum number of schemas per service instance | 100 | 100 | 100 |
| Maximum number of schemas per API | 100 | 100 | 100 |
| Maximum number of tags per service instance | 100 | 100 | 100 |
| Maximum number of tags per API | 100 | 100 | 100 |
| Maximum number of version sets per service instance | 100 | 100 | 100 |
| Maximum number of releases per API | 100 | 100 | 100 |
| Maximum number of operations per API | 100 | 100 | 100 |
| Maximum number of GraphQL resolvers per service instance | 100 | 100 | 100 |
| Maximum number of GraphQL resolvers per API | 100 | 100 | 100 |
| Maximum number of APIs per product | 100 | 100 | 100 |
| Maximum number of APIs per subscription | 100 | 100 | 100 |
| Maximum number of products per subscription | 100 | 100 | 100 |
| Maximum number of groups per product | 100 | 100 | 100 |
| Maximum number of tags per product | 100 | 100 | 100 |
| Concurrent back-end connections1 per HTTP authority | 2,048 | 2,048 | 2,048 |
| Maximum cached response size | 2 MiB | 2 MiB | 2 MiB |
| Maximum policy document size | 256 KiB | 256 KiB | 256 KiB |
| Maximum request payload size | 1 GiB | 1 GiB | 1 GiB |
| Maximum buffered payload size | 2 MiB | 2 MiB | 2 MiB |
| Maximum request/response payload size in diagnostic logs | 8,192 bytes | 8,192 bytes | 8,192 bytes |
| Maximum request URL size2 | 16,384 bytes | 16,384 bytes | 16,384 bytes |
| Maximum length of URL path segment | 1,024 characters | 1,024 characters | 1,024 characters |
| Maximum character length of named value | 4,096 characters | 4,096 characters | 4,096 characters |
| Maximum size of request or response body in validate-content policy | 100 KiB | 100 KiB | 100 KiB |
| Maximum size of API schema used by validation policy | 4 MB | 4 MB | 4 MB |
| Maximum number of active WebSocket connections per unit3 | 5,000 | 5,000 | 5,000 |
1 Connections are pooled and reused unless explicitly closed by the backend.
2 Includes an up to 2048-bytes long query string.
3 Up to a maximum of 60,000 connections per service instance.
Developer portal limits
The following limits apply to the developer portal in the v2 tiers.
| Item | Basic v2 | Standard v2 | Premium v2 |
|---|---|---|---|
| Maximum number of media files to upload | 15 | 15 | 15 |
| Maximum size of a media file | 500 KB | 500 KB | 500 KB |
| Maximum number of pages | 30 | 50 | 50 |
| Maximum number of widgets1 | 30 | 50 | 50 |
| Maximum size of metadata per page | 350 KB | 350 KB | 350 KB |
| Maximum size of metadata per widget1 | 350 KB | 350 KB | 350 KB |
| Maximum number of client requests per minute | 200 | 200 | 200 |
1 Limit for built-in widgets such as text, images, or APIs list. Currently, custom widgets and custom HTML code widgets aren't supported in the v2 tiers.
Deployment
Deploy a v2 tier instance using the Azure portal or using tools such as the Azure REST API, Azure Resource Manager, Bicep template, or Terraform.
Frequently asked questions
Q: Can I migrate from my existing API Management instance to a new v2 tier instance?
A: No. Currently you can't migrate an existing API Management instance (in the Consumption, Developer, Basic, Standard, or Premium tier) to a new v2 tier instance. Currently the v2 tiers are available for newly created service instances only.
Q: What's the relationship between the stv2 compute platform and the v2 tiers?
A: They're not related. stv2 is a compute platform version of the Developer, Basic, Standard, and Premium tier service instances. stv2 is a successor to the stv1 compute platform that retired in 2024.
Q: Will I still be able to provision Developer, Basic, Standard, or Premium tier services?
A: Yes, there are no changes to the classic Developer, Basic, Standard, or Premium tiers.
Q: What is the difference between virtual network integration in Standard v2 tier and virtual network injection in the Premium and Premium v2 tiers?
A: A Standard v2 service instance can be integrated with a virtual network to provide secure access to the backends residing there. A Standard v2 service instance integrated with a virtual network has a public IP address for inbound access.
The Premium tier and Premium v2 tier support full network isolation by deployment (injection) into a virtual network without exposing a public IP address. Learn more about networking options in API Management.
Q: Can I deploy an instance of the Basic v2 or Standard v2 tier entirely in my virtual network?
A: No, such a deployment is only supported in the Premium and Premium v2 tiers.
Related content
- Compare the API Management tiers.
- Learn more about the API Management gateways
- Learn about API Management pricing.