This topic introduces the new VPC integration instance for API Gateway, its use cases, and purchasing considerations.
Use cases
A VPC integration instance is a new type of dedicated instance for API Gateway that optimizes the network architecture between API Gateway and your VPC. Common use cases include:
-
Your APIs, hosted on API Gateway, need to access multiple backend services, such as ECS and SLB, within the same VPC. This is common in microservices architectures or when using service discovery tools like Nacos.
-
You need to connect to a hybrid cloud environment where a backend service requires API requests from API Gateway to come from a private IP address within your 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 compares VPC integration instances and conventional dedicated instances.
|
VPC integration instance |
Conventional dedicated instance |
|
|
Egress IP address of the gateway instance* |
A private IP address from the VPC that you specified when creating the instance. |
An IP address in the 100.*.*.* range. |
|
Forwarding API requests to multiple resources in the same VPC |
Recommended. This is ideal for scenarios like service registration and discovery. |
Supported. However, you must configure a VPC access authorization for each backend resource. Dynamic configuration is not supported. |
|
Forwarding API requests to resources in multiple VPCs |
Not supported. You must manually connect the VPCs. |
Recommended. You can configure multiple VPC access authorizations. |
|
Configuration process |
Specify the target VPC during instance creation. No further configuration is needed. |
You must configure a VPC access authorization. |
-
The egress IP address of a gateway instance is the TCP source IP address received by a backend service when API Gateway forwards a request.
-
VPC access authorization: Required for a conventional dedicated instance to access resources within a VPC. For more information, see Use a resource in a VPC as the backend service of an API.
-
Due to network architecture limitations, VPC integration instances cannot integrate with DataWorks. Use a conventional dedicated instance instead.
Purchasing
This section describes the purchase page for API Gateway dedicated instances. After you select VPC integration instance as the instance type, you can configure the VPC integration instance.
The purchase page also includes the following general configurations: region and availability zone (for example, China (Hangzhou)), instance type (for example, api.s1.small, which displays parameters such as maximum requests per second, SLA, maximum concurrent requests, and outbound bandwidth), HTTPS security policy (for example, HTTPS2_TLS1_0), network billing type (for example, pay-by-traffic), and instance name.
To create a VPC integration instance, configure the following:
-
User VPC ID: Specify the user VPC to connect with API Gateway. This setting cannot be changed after the instance is created.
-
API Gateway instance CIDR block: Specify the CIDR block for the API Gateway instance. API Gateway checks whether its resources conflict with the CIDR block of your specified vSwitch. If a conflict exists, the instance cannot be created.
-
Availability zone and security group: API Gateway creates an elastic network interface in the vSwitch and security group of your specified availability zone and attaches it to the new API Gateway instance. Ensure that the resources in your user VPC are within the CIDR block of the specified vSwitch and in the same security group. The outbound rules of the security group must allow traffic to the destination IP range so that the API Gateway instance can access your services.
ImportantAPI Gateway reserves an internal resource CIDR block. The CIDR block of the vSwitch you specify must not overlap with this internal CIDR block. For a list of the CIDR blocks that VPC integration instances reserve in each region, see VPC integration instance reserved CIDR blocks by region.
-
Service-linked role: API Gateway requires a service-linked role to manage elastic network interface resources in your user VPC during instance creation. For more information about this role, see Service-linked role for connecting API Gateway to a user VPC.
Notes on the elastic network interface (ENI) that API Gateway creates in your user VPC:
-
The ENI is created in your user VPC and is subject to the security rules and network configurations, such as security groups, of the user VPC.
-
If the backend is an ECS instance that is in the same security group as the ENI and intra-group communication is enabled for the security group, you do not need to configure separate outbound rules.
-
If the backend 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 Gateway in your user VPC does not incur additional charges.
Usage
Add accessible CIDR blocks
By default, a newly created VPC integration instance can only access services within the CIDR block of the vSwitch specified during creation. You can view the default accessible CIDR block in the VPC Network Access section on the instance details page in the API Gateway console. To allow API Gateway to access services in other CIDR blocks, add them manually. Follow these steps:
-
Log on to the API Gateway console. In the left-side navigation pane, select Instances.
-
Find the target VPC integration dedicated instance and in the VPC Accessible CIDR Blocks column, click Add.
-
You can add a CIDR block by using one of two methods: Select from list or Enter manually.
NoteIf you manually enter a CIDR block, ensure it is within the VPC specified during instance creation or is connected to that VPC.
Compatibility with VPC access authorization
VPC access authorization as a backend service
A VPC integration instance can use a VPC access authorization as a backend service. The instance uses the ENI created in your VPC to directly access the service defined in the VPC access authorization.
Before you configure a VPC access authorization for an API or plug-in on a VPC integration instance, ensure the following:
-
The VPC ID specified in the VPC access authorization is the same as the ID of the VPC connected to the instance.
-
The private IP address of the service in the VPC access authorization is included in the accessible CIDR block of the VPC integration instance.
NoteIf API Gateway returns an error such as "instance cannot connect to the backend xxx.xxx.xxx.xxx." when you publish an API or modify a plug-in, verify that the private IP address in the error message is included in the instance's accessible CIDR block.
Changing the API Group instance
To simplify migration, you can directly change the instance type for an API Group from a Serverless instance or conventional dedicated instance to a VPC integration instance.
-
Log on to the API Gateway console. In the left-side navigation pane, choose API Groups.
-
Find the API Group that you want to modify and click its name to go to the details page.
-
Click Change Instance for API Group and select your VPC integration instance.
-
API Gateway validates the VPC access authorizations used by the APIs and associated plug-ins in the API Group. If the validation succeeds, the change is complete. If it fails, API Gateway rolls back the change and displays a failure reason.
Important-
Before migration, the system validates the following for VPC-based services, such as APIs and plug-ins:
-
The VPC ID specified in the VPC access authorization is the same as the ID of the VPC connected to the instance.
-
The private IP address of the service in the VPC access authorization is included in the accessible CIDR block of the VPC integration instance.
-
-
Before migration, if your API Group uses a VPC access authorization, ensure that the security group of the ECS or SLB service in the authorization matches the security group specified for the VPC integration instance.
-
After migration, the egress private IP address changes to that of the target instance. If your backend service has an allowlist, add the new IP address to it before migrating to prevent access failures.
-
Reserved CIDR blocks for VPC Integration by region
Hangzhou
|
Availability 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 |
Shanghai
|
Availability zone |
Reserved CIDR block |
|
cn-shanghai-a |
192.168.0.0/20, 172.19.0.0/20, 172.20.0.0/16 |
|
cn-shanghai-b |
192.168.16.0/20, 172.19.16.0/20, 172.20.0.0/16 |
|
cn-shanghai-c |
192.168.32.0/20, 172.19.32.0/20, 172.20.0.0/16 |
|
cn-shanghai-d |
192.168.48.0/20, 172.19.48.0/20, 172.20.0.0/16 |
|
cn-shanghai-e |
192.168.64.0/20, 172.19.64.0/20, 172.20.0.0/16 |
|
cn-shanghai-f |
192.168.80.0/20, 172.19.80.0/20, 172.20.0.0/16 |
|
cn-shanghai-g |
192.168.96.0/20, 172.19.96.0/20, 172.20.0.0/16 |
|
cn-shanghai-k |
192.168.112.0/20, 172.19.112.0/20, 172.20.0.0/16 |
|
cn-shanghai-l |
192.168.128.0/20, 172.19.128.0/20, 172.20.0.0/16 |
|
cn-shanghai-m |
192.168.144.0/20, 172.19.144.0/20, 172.20.0.0/16 |
|
cn-shanghai-n |
192.168.160.0/20, 172.19.160.0/20, 172.20.0.0/16 |
Shanghai Finance
|
Availability zone |
Reserved CIDR blocks |
|
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 |
Beijing
|
Availability 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 |
Beijing finance cloud
|
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 |
Shenzhen
|
Availability 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 (Shenzhen) Finance Cloud
|
Availability 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 |
Automotive compliance for Heyuan dedicated region
|
Zone |
Reserved CIDR blocks |
|
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)
|
Availability zone |
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 |
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 |
Qingdao
|
Zone |
Reserved CIDR block |
|
cn-qingdao-b |
192.168.0.0/20, 172.19.0.0/20, 172.20.0.0/16 |
|
cn-qingdao-c |
192.168.16.0/20, 172.19.16.0/20, 172.20.0.0/16 |
Hong Kong
|
Zone |
Reserved CIDR block |
|
cn-hongkong-b |
192.168.0.0/20, 172.19.0.0/20, 172.21.0.0/16 |
|
cn-hongkong-c |
192.168.16.0/20, 172.19.16.0/20, 172.21.0.0/16 |
|
cn-hongkong-d |
192.168.32.0/20, 172.19.32.0/20, 172.21.0.0/16 |
Singapore
|
Zone |
Reserved CIDR block |
|
ap-southeast-1a |
192.168.0.0/20, 172.19.0.0/20, 172.21.0.0/16 |
|
ap-southeast-1b |
192.168.16.0/20, 172.19.16.0/20, 172.21.0.0/16 |
|
ap-southeast-1c |
192.168.32.0/20, 172.19.32.0/20, 172.21.0.0/16 |
Indonesia (Jakarta)
|
Availability zone |
Reserved CIDR block |
|
ap-southeast-5a |
192.168.0.0/20, 172.19.0.0/20, 172.20.0.0/16 |
|
ap-southeast-5b |
192.168.16.0/20, 172.19.16.0/20, 172.20.0.0/16 |
|
ap-southeast-5c |
192.168.32.0/20, 172.19.32.0/20, 172.20.0.0/16 |
Malaysia (Kuala Lumpur)
|
Availability zone |
Reserved CIDR block |
|
ap-southeast-3a |
192.168.0.0/20, 172.19.0.0/20, 172.20.0.0/16 |
|
ap-southeast-3b |
192.168.16.0/20, 172.19.16.0/20, 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 |
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, 172.20.0.0/16 |
Saudi Arabia (Riyadh)
|
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 |