Azure API Management v2 tiers
APPLIES TO: Basic v2 | Standard v2
We're introducing a new set of pricing tiers (SKUs) for Azure API Management: the v2 tiers. The new tiers 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. Learn more.
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.
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.
Simplified networking - The Standard v2 tier supports outbound connections to network-isolated backends.
More options for production workloads - The v2 tiers are all supported with an SLA. Upgrade from Basic v2 to Standard v2 to add more production options.
Developer portal options - Enable the developer portal when you're ready to let API consumers discover your APIs.
Networking options
The Standard v2 tier supports VNet integration to allow your API Management instance to reach API backends that are isolated in a single connected VNet. The API Management gateway, management plane, and developer portal remain publicly accessible from the internet. The VNet must be in the same region as the API Management instance. Learn more.
Features
API version
The v2 tiers are supported in API Management API version 2023-05-01-preview or later.
Supported regions
The v2 tiers are available in the following regions:
- East US
- East US 2
- South Central US
- North Central US
- West US
- West US 2
- France Central
- Germany West Central
- North Europe
- Norway East
- West Europe
- Switzerland North
- UK South
- UK West
- South Africa North
- Central India
- South India
- Brazil South
- Australia Central
- Australia East
- Australia Southeast
- East Asia
- Japan East
- Southeast Asia
- Korea Central
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
- Built-in analytics (replaced with Azure Monitor-based dashboard)
Limitations
The following API Management capabilities are currently unavailable in the v2 tiers.
Infrastructure and networking
- Zone redundancy
- Multi-region deployment
- Multiple custom domain names
- Capacity metric - replaced by CPU Percentage of Gateway and Memory Percentage of Gateway metrics
- Autoscaling
- Inbound connection using a private endpoint
- Injection in a VNet in external mode or internal mode
- Upgrade to v2 tiers from v1 tiers
- Workspaces
- 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 |
|---|---|---|
| Maximum number of scale units | 10 | 10 |
| Maximum cache size per service instance | 250 MB | 1 GB |
| Maximum number of APIs per service instance | 150 | 500 |
| Maximum number of API operations per service instance | 3,000 | 10,000 |
| Maximum number of subscriptions per service instance | 500 | 2,000 |
| Maximum number of products per service instance | 50 | 200 |
| Maximum number of users per service instance | 300 | 2,000 |
| Maximum number of groups per service instance | 20 | 100 |
| Maximum number of authorization servers per service instance | 10 | 500 |
| Maximum number of policy fragments per service instance | 50 | 50 |
| Maximum number of OpenID Connect providers per service instance | 10 | 10 |
| Maximum number of certificates per service instance | 100 | 100 |
| Maximum number of backends per service instance | 100 | 100 |
| Maximum number of caches per service instance | 100 | 100 |
| Maximum number of named values per service instance | 100 | 100 |
| Maximum number of loggers per service instance | 100 | 100 |
| Maximum number of schemas per service instance | 100 | 100 |
| Maximum number of schemas per API | 100 | 100 |
| Maximum number of tags per service instance | 100 | 100 |
| Maximum number of tags per API | 100 | 100 |
| Maximum number of version sets per service instance | 100 | 100 |
| Maximum number of releases per API | 100 | 100 |
| Maximum number of operations per API | 100 | 100 |
| Maximum number of GraphQL resolvers per service instance | 100 | 100 |
| Maximum number of GraphQL resolvers per API | 100 | 100 |
| Maximum number of APIs per product | 100 | 100 |
| Maximum number of APIs per subscription | 100 | 100 |
| Maximum number of products per subscription | 100 | 100 |
| Maximum number of groups per product | 100 | 100 |
| Maximum number of tags per product | 100 | 100 |
| Concurrent back-end connections1 per HTTP authority | 2,048 | 2,048 |
| Maximum cached response size | 2 MiB | 2 MiB |
| Maximum policy document size | 256 KiB | 256 KiB |
| Maximum request payload size | 1 GiB | 1 GiB |
| Maximum buffered payload size | 2 MiB | 2 MiB |
| Maximum request/response payload size in diagnostic logs | 8,192 bytes | 8,192 bytes |
| Maximum request URL size2 | 16,384 bytes | 16,384 bytes |
| Maximum length of URL path segment | 1,024 characters | 1,024 characters |
| Maximum character length of named value | 4,096 characters | 4,096 characters |
| Maximum size of request or response body in validate-content policy | 100 KiB | 100 KiB |
| Maximum size of API schema used by validation policy | 4 MB | 4 MB |
| Maximum number of active WebSocket connections per unit3 | 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 |
|---|---|---|
| Maximum number of media files to upload | 15 | 15 |
| Maximum size of a media file | 500 KB | 500 KB |
| Maximum number of pages | 30 | 50 |
| Maximum number of widgets1 | 30 | 50 |
| Maximum size of metadata per page | 350 KB | 350 KB |
| Maximum size of metadata per widget1 | 350 KB | 350 KB |
| Maximum number of client requests per minute | 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 an instance of the Basic v2 or Standard v2 tier using the Azure portal, Azure REST API, or Azure Resource Manager or Bicep template.
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 platform scheduled for retirement in 2024.
Q: Will I still be able to provision Basic or Standard tier services?
A: Yes, there are no changes to the Basic or Standard tiers.
Q: What is the difference between VNet integration in Standard v2 tier and VNet support in the Premium tier?
A: A Standard v2 service instance can be integrated with a VNet to provide secure access to the backends residing there. A Standard v2 service instance integrated with a VNet will have a public IP address. The Premium tier supports a fully private integration with a VNet (often referred to as injection into VNet) without exposing a public IP address.
Q: Can I deploy an instance of the Basic v2 or Standard v2 tier entirely in my VNet?
A: No, such a deployment is only supported in the Premium tier.
Q: Is a Premium v2 tier planned?
A: Yes, a Premium v2 preview is planned and will be announced separately.
Related content
- Compare the API Management tiers.
- Learn more about the API Management gateways
- Learn about API Management pricing.