This topic describes the new VPC integration instance for API Gateway, its use cases, and key purchasing considerations.
Use cases
The VPC integration instance is a new dedicated instance for API Gateway that optimizes the network architecture between API Gateway and your virtual private clouds (VPCs). It is suitable for the following scenarios:
Accessing multiple backend resources within a single VPC. This is a common requirement for microservices or service discovery architectures (for example, using Nacos), where APIs hosted on the gateway need to connect to various services, such as Elastic Compute Serive (ECS) and Server Load Balancer (SLB), within the same VPC.
Hybrid cloud connectivity. When
API Gatewayforwards requests to backend services in a hybrid cloud setup, those services often expect the request to originate from a private IP address within their VPC. For more information, see Scenario 3: API Gateway accesses a backend service in an on-premises data center over an internal network.
Differences from conventional dedicated instances
The following table summarizes their advantages and limitations.
Type | VPC integration instance | Conventional dedicated instance |
Egress IP address* of the gateway instance | A private IP address from the VPC to which the instance is connected. | An IP address in the 100.*.*.* range. |
An instance forwarding API requests to multiple resources within the same VPC | Recommended. Example: service registration and discovery. | Supported, but requires configuring a |
An instance forwarding API requests to resources in multiple VPCs | Not supported. You must manually establish network connectivity between the VPCs. | Recommended. You can configure multiple |
Configuration process | Specify the target VPC during instance creation. No additional API configuration is required. | Requires configuring a |
The Egress IP address of the gateway instance is the source TCP IP address that a backend service sees when receiving a request from
API Gateway.VPC access authorization: In the conventional approach, you must first create a
VPC access authorizationto access resources in a VPC. For more information, see Use a resource in a VPC as the backend service of an API.Due to network architecture limitations, only conventional dedicated instances support DataWorks integration. DataWorks does not currently support VPC integration instances.
Purchase a VPC integration instance
The following image shows the purchase page for an API Gateway dedicated instance. After you set Type to VPC integration instance, you can configure the instance.

To create a VPC integration instance, specify the following settings:
VPC ID: Specify the VPC to which the instance will connect. You cannot change this setting after the instance is created.
CIDR Block: Specify a CIDR block for the
API Gatewayinstance. The system validates that this CIDR block does not conflict with the one used by your selectedvSwitch. If a conflict is found, instance creation fails.Zone and security group:
API Gatewaycreates an Elastic Network Interface (ENI) in thevSwitchandSecurity Groupof the specified zone and binds it to the newAPI Gatewayinstance. Ensure that your VPC resources are within the CIDR block of the specifiedvSwitchand in the same security group. To prevent request failures, the outbound rules of the security group must allow traffic to the destination IP range.ImportantAPI Gatewayuses an internal resource CIDR block. ThevSwitchyou specify must not overlap with this internal CIDR block. For a list of CIDR blocks reserved byVPC integration instancesin each region, see CIDR blocks reserved by VPC integration instances in each region.Service-linked role:
API Gatewayrequires a service-linked role to manage ENI resources in your VPC. For more details about this role, see AliyunServiceRoleForApiGatewayConnectUserVpc.
Notes on the Elastic Network Interface (ENI) created by API Gateway in your VPC:
The ENI instance resides in your VPC and is subject to your VPC's network configurations and security rules, such as security groups.
If the backend service is an ECS instance in the same security group as the ENI, and intra-group communication is enabled for that security group, you do not need to configure specific outbound rules.
If the backend service is a CLB instance, you must ensure that the outbound rules of the security group allow traffic to the destination IP range, regardless of whether the CLB instance is in the same
vSwitch.
The ENI created by
API Gatewayin your VPC does not incur additional charges.
How to use
Add accessible CIDR blocks
By default, a new VPC integration instance can only access services within the CIDR block of the vSwitch specified at creation. You can view the default accessible CIDR block in the VPC network access section of the instance details page in the API Gateway console. To allow the instance to access services in other CIDR blocks, you must add those blocks manually. Follow these steps:
Log on to the
API Gatewayconsole. In the left-side navigation pane, click Instances.Find the target
VPC integration instanceand click Add in the Access Allowed From column.Add a CIDR block in two ways: Select a CIDR block from the drop-down list or manually specify a CIDR block.
NoteIf you enter a CIDR block manually, ensure that it is within the VPC you specified when creating the instance or is connected to that VPC.
Compatibility with VPC access authorization
Use VPC access authorization as a backend service
VPC integration instances can use existing VPC access authorizations as backend services. The instance uses the ENI in your VPC to directly connect to the service defined in the VPC access authorization.
Ensure the following conditions are met before you configure a VPC access authorization for an API or a plug-in on a VPC integration instance:
The VPC ID in the
VPC access authorizationdefinition is the same as the ID of the VPC connected to the instance.The private IP address of the service in the
VPC access authorizationfalls within the accessible CIDR block of the VPC integration instance.NoteWhen you publish an API or modify a
plug-in, if you receive an error message such asinstance cannot connect to the backend xxx.xxx.xxx.xxx., check whether the instance's accessible CIDR block includes the private IP address mentioned in the error.
Change the instance for an API group
To help you migrate your services to a VPC integration instance, you can directly change the instance for an API Group from a Serverless or conventional dedicated instance to a VPC integration instance.
Log on to the API Gateway console. In the left-side navigation pane, choose Manage APIs > API Groups.
Find the group that you want to migrate and click its name to go to the group details page.
Click Modify Instance for API Group Deployment and select the VPC integration instance that you created.
API Gatewayvalidates theVPC access authorizationsused by the APIs and their associatedplug-insin the originalAPI Group. If the validation succeeds, the change is successful. If it fails, the system rolls back the change and displays the reason for the failure.ImportantBefore migration, the system validates the following for VPC-based services (APIs and
plug-ins):The VPC ID in the
VPC access authorizationdefinition is the same as the ID of the VPC connected to the instance.The private IP address of the service in the
VPC access authorizationfalls within the accessible CIDR block of the VPC integration instance.
If your
API Groupuses aVPC access authorization, ensure that the security group of the corresponding ECS/SLB service is the same as the security group specified when you created theVPC integration instance.After migration, the egress IP address changes to that of the target instance. If your backend service uses an allowlist, add the new egress IP address to the allowlist before migrating to prevent connectivity failures.
CIDR blocks reserved by VPC integration instances in each region
China (Hangzhou)
Zone | Reserved CIDR block |
cn-hangzhou-b | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-hangzhou-d | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
cn-hangzhou-e | 192.168.32.0/20, 172.19.32.0/20, and 172.20.0.0/16 |
cn-hangzhou-f | 192.168.48.0/20, 172.19.48.0/20, and 172.20.0.0/16 |
cn-hangzhou-g | 192.168.64.0/20, 172.19.64.0/20, and 172.20.0.0/16 |
cn-hangzhou-h | 192.168.80.0/20, 172.19.80.0/20, and 172.20.0.0/16 |
cn-hangzhou-i | 192.168.96.0/20, 172.19.96.0/20, and 172.20.0.0/16 |
cn-hangzhou-j | 192.168.112.0/20, 172.19.112.0/20, and 172.20.0.0/16 |
cn-hangzhou-k | 192.168.128.0/20, 172.19.128.0/20, and 172.20.0.0/16 |
China (Shanghai)
Zone | Reserved CIDR block |
cn-shanghai-a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-shanghai-b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
cn-shanghai-c | 192.168.32.0/20, 172.19.32.0/20, and 172.20.0.0/16 |
cn-shanghai-d | 192.168.48.0/20, 172.19.48.0/20, and 172.20.0.0/16 |
cn-shanghai-e | 192.168.64.0/20, 172.19.64.0/20, and 172.20.0.0/16 |
cn-shanghai-f | 192.168.80.0/20, 172.19.80.0/20, and 172.20.0.0/16 |
cn-shanghai-g | 192.168.96.0/20, 172.19.96.0/20, and 172.20.0.0/16 |
cn-shanghai-k | 192.168.112.0/20, 172.19.112.0/20, and 172.20.0.0/16 |
cn-shanghai-l | 192.168.128.0/20, 172.19.128.0/20, and 172.20.0.0/16 |
cn-shanghai-m | 192.168.144.0/20, 172.19.144.0/20, and 172.20.0.0/16 |
cn-shanghai-n | 192.168.160.0/20, 172.19.160.0/20, and 172.20.0.0/16 |
China East 2 Finance
Zone | Reserved CIDR block |
cn-shanghai-finance-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.21.0.0/16 |
cn-shanghai-finance-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.21.0.0/16 |
cn-shanghai-finance-1f | 192.168.32.0/20, 172.19.32.0/20, and 172.21.0.0/16 |
cn-shanghai-finance-1g | 192.168.48.0/20, 172.19.48.0/20, and 172.21.0.0/16 |
cn-shanghai-finance-1k | 192.168.64.0/20, 172.19.64.0/20, and 172.21.0.0/16 |
cn-shanghai-finance-1z | 192.168.80.0/20, 172.19.80.0/20, and 172.21.0.0/16 |
China (Beijing)
Zone | Reserved CIDR block |
cn-beijing-a | 192.168.0.0/20, 172.19.0.0/20, and 172.22.0.0/16 |
cn-beijing-b | 192.168.16.0/20, 172.19.16.0/20, and 172.22.0.0/16 |
cn-beijing-c | 192.168.32.0/20, 172.19.32.0/20, and 172.22.0.0/16 |
cn-beijing-d | 192.168.48.0/20, 172.19.48.0/20, and 172.22.0.0/16 |
cn-beijing-e | 192.168.64.0/20, 172.19.64.0/20, and 172.22.0.0/16 |
cn-beijing-f | 192.168.80.0/20, 172.19.80.0/20, and 172.22.0.0/16 |
cn-beijing-g | 192.168.96.0/20, 172.19.96.0/20, and 172.22.0.0/16 |
cn-beijing-h | 192.168.112.0/20, 172.19.112.0/20, and 172.22.0.0/16 |
cn-beijing-i | 192.168.128.0/20, 172.19.128.0/20, and 172.22.0.0/16 |
cn-beijing-j | 192.168.144.0/20, 172.19.144.0/20, and 172.22.0.0/16 |
cn-beijing-k | 192.168.160.0/20, 172.19.160.0/20, and 172.22.0.0/16 |
cn-beijing-l | 192.168.176.0/20, 172.19.176.0/20, and 172.22.0.0/16 |
China North 2 Finance
Zone | Reserved CIDR block |
cn-beijing-finance-1k | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-beijing-finance-1l | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
China (Shenzhen)
Zone | Reserved CIDR block |
cn-shenzhen-a | 192.168.0.0/20, 172.19.0.0/20, and 172.23.0.0/16 |
cn-shenzhen-b | 192.168.16.0/20, 172.19.16.0/20, and 172.23.0.0/16 |
cn-shenzhen-c | 192.168.32.0/20, 172.19.32.0/20, and 172.23.0.0/16 |
cn-shenzhen-d | 192.168.48.0/20, 172.19.48.0/20, and 172.23.0.0/16 |
cn-shenzhen-e | 192.168.64.0/20, 172.19.64.0/20, and 172.23.0.0/16 |
cn-shenzhen-f | 192.168.80.0/20, 172.19.80.0/20, and 172.23.0.0/16 |
China South 1 Finance
Zone | Reserved CIDR block |
cn-shenzhen-finance-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-shenzhen-finance-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
cn-shenzhen-finance-1d | 192.168.32.0/20, 172.19.32.0/20, and 172.20.0.0/16 |
cn-shenzhen-finance-1e | 192.168.48.0/20, 172.19.48.0/20, and 172.20.0.0/16 |
Heyuan ACDR Auto
Zone | Reserved CIDR block |
cn-heyuan-acdr-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-heyuan-acdr-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
China (Zhangjiakou)
Zone | Reserved CIDR block |
cn-zhangjiakou-a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-zhangjiakou-b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
cn-zhangjiakou-c | 192.168.32.0/20, 172.19.32.0/20, and 172.20.0.0/16 |
China (Chengdu)
Zone | Reserved CIDR block |
cn-chengdu-a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-chengdu-b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
China (Qingdao)
Zone | Reserved CIDR block |
cn-qingdao-b | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
cn-qingdao-c | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
China (Hong Kong)
Zone | Reserved CIDR block |
cn-hongkong-b | 192.168.0.0/20, 172.19.0.0/20, and 172.21.0.0/16 |
cn-hongkong-c | 192.168.16.0/20, 172.19.16.0/20, and 172.21.0.0/16 |
cn-hongkong-d | 192.168.32.0/20, 172.19.32.0/20, and 172.21.0.0/16 |
Singapore
Zone | Reserved CIDR block |
ap-southeast-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.21.0.0/16 |
ap-southeast-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.21.0.0/16 |
ap-southeast-1c | 192.168.32.0/20, 172.19.32.0/20, and 172.21.0.0/16 |
Indonesia (Jakarta)
Zone | Reserved CIDR block |
ap-southeast-5a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
ap-southeast-5b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
ap-southeast-5c | 192.168.32.0/20, 172.19.32.0/20, and 172.20.0.0/16 |
Malaysia (Kuala Lumpur)
Zone | Reserved CIDR block |
ap-southeast-3a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
ap-southeast-3b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
Japan (Tokyo)
Zone | Reserved CIDR block |
ap-northeast-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.21.0.0/16 |
ap-northeast-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.21.0.0/16 |
ap-northeast-1c | 192.168.32.0/20, 172.19.32.0/20, and 172.21.0.0/16 |
South Korea (Seoul)
Zone | Reserved CIDR block |
ap-northeast-2a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
Germany (Frankfurt)
Zone | Reserved CIDR block |
eu-central-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
eu-central-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
eu-central-1c | 192.168.32.0/20, 172.19.32.0/20, and 172.20.0.0/16 |
UK (London)
Zone | Reserved CIDR block |
eu-west-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
eu-west-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
US (Silicon Valley)
Zone | Reserved CIDR block |
us-west-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
us-west-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
US (Virginia)
Zone | Reserved CIDR block |
us-east-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
us-east-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.20.0.0/16 |
UAE (Dubai)
Zone | Reserved CIDR block |
me-east-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.20.0.0/16 |
SAU (Riyadh - Partner Region)
Zone | Reserved CIDR block |
me-central-1a | 192.168.0.0/20, 172.19.0.0/20, and 172.16.20.0/24 |
me-central-1b | 192.168.16.0/20, 172.19.16.0/20, and 172.16.20.0/24 |