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 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.