1. API Gateway instance types
An API Gateway instance is a group of resources that is used to host and manage your APIs. The resources include Internet IP addresses, internal network IP addresses, workloads, servers, and storage resources. API Gateway allows you to host and manage APIs by grouping them. An API group must be attached to a valid API Gateway instance. Currently, API Gateway has the following instance types for you to choose from:
- Shared instances in the classic network
If you choose a shared instance, you are billed according to the number of successful API calls and the public network traffic generated. However, for this instance type, server resource pools, IP addresses, bandwidth, and other resources are shared by a group of users in the current region. The default RPS limit for the API group attached to a shared instance in the classic network is 500. You can open a ticket to request for a larger value. We will make a decision depending on your use case and our resource availability after receiving your ticket. Shared instances in the classic network are the earliest instance type of API Gateway. This instance type can support backend addresses of the classic network, but currently does not support the latest plug-in feature.
- Shared instances in a VPC network
The billing, allocation, and RPS management rules of a shared instance in a VPC network are the same as those of a shared instance in the classic network. Shared instances in a VPC network are a new instance type provided by API Gateway. This instance type provides a plug-in feature, allowing you to configure policies for JSON Web Token (JWT) authorization, throttling, IP access control, backend signature, Cross-Origin Resource Sharing (CORS), caching, and routing. However, they do not support backend addresses of the classic network and are slightly different from instances in the classic network in terms of some details in their technical implementation.
- Exclusive instances in a VPC network — coming soon
An exclusive instance in a VPC network has the same technical specifications as a shared instance in a VPC network. However, you can use exclusive resources, including Internet IP addresses, internal network IP addresses, bandwidth, and isolated server clusters. In addition, you can pay fees by hour to obtain a larger RPS. This provides higher SLA guarantees.
2. Differences in technical specifications between instance types
The following table lists some important differences between instances in the classic network and those in a VPC network. You can open a ticket or contact us in the DingTalk group for help. The DingTalk group number is 11747055.
| Technical specifications | Instances in the classic network | Instances in a VPC network |
|---|---|---|
| Plug-in system | Not supported | Supported |
| Backend addresses | Backend addresses of the classic network are supported. | Only backend addresses of VPC networks are supported, and those of the classic network are not supported. |
| Function Compute | API Gateway instances can access your Function Compute service in the same region over the internal network. | In China (Beijing), China (Hangzhou), China (Shenzhen), and China (Shanghai), API Gateway instances can access your Function Compute service over the internal network only when it is deployed in the same VPC. |
| Backend TLS version for HTTPS connections | TLS1.0 | TLS1.0, TLS1.1, TLS1.2 |
| CORS | All cross-origin requests are allowed. | Custom configurations through the CORS plug-in are supported. |
| Flash CORS | A built-in crossdomain.xml file is provided. | Not supported. Use backend Mock configuration for implementation. |
3. Instance-supported regions
| Region ID | Region name | Instances in the classic network | Instances in a VPC network |
|---|---|---|---|
| cn-qingdao | China (Qingdao) | Supported | Supported |
| cn-beijing | China (Beijing) | Supported | Supported |
| cn-zhangjiakou | China (Zhangjiakou) | N/A | Supported |
| cn-huhehaote | China (Hohhot) | N/A | Supported |
| cn-hangzhou-b | China (Hangzhou) | Supported | Supported |
| cn-shanghai | China (Shanghai) | Supported | Supported |
| cn-shenzhen | China (Shenzhen) | Supported | Coming soon |
| cn-hongkong | Hong Kong | Supported | Coming soon |
| ap-northeast-1 | Japan (Tokyo) | Supported | Planned |
| ap-southeast-1 | Singapore | Supported | Supported |
| ap-southeast-2 | Australia (Sydney) | Supported | Planned |
| ap-southeast-3 | Malaysia (Kuala Lumpur) | Supported | Planned |
| ap-southeast-5 | Indonesia (Jakarta) | Supported | Planned |
| ap-south-1 | India (Mumbai) | Supported | Planned |
| us-east-1 | US (Virginia) | N/A | Supported |
| us-west-1 | US (Silicon Valley) | N/A | Supported |
| eu-west-1 | UK (London) | N/A | Supported |
| me-east-1 | UAE (Dubai) | N/A | Supported |
| eu-central-1 | Germany (Frankfurt) | Supported | Supported |
4. Migrate an API group from one instance to another
You can migrate your API group between an instance in the classic network and an instance in a VPC network. In the API Gateway console, choose Publish APIs > API Groups from the left-side navigation pane. On the API Groups page, click the name of your API group. On the Group Details page, click Migrate to VPC Shared Instance or Migrate to Classic Shared Instance. The API group migration takes effect on the DNS server of the second-level domain name in real time. If the RPS of your API group has been adjusted and you want to perform migration, open a ticket to seek help from Customer Services. Some differences in the details of implementation exist between instances in a VPC network and instances in the classic network. You need to confirm the following technical details individually before migrating your API group from an instance in the classic network to an instance in a VPC network:
- The VPC gateway does not support backend addresses of the classic network. If your backend addresses belong to the classic network, the APIs in the API group are no longer usable after migration. Instead, you need to perform VPC authorization and then API group migration.
- The egress address of API Gateway may be changed after migration. Check the egress address on the Instances page to ensure that the egress IP address of API Gateway is in the whitelist.
- The VPC gateway no longer provides the built-in file
crossdomain.xml. If you have to use it, configure the MOCK API instead. - The bound throttling, IP access control, and backend signature policies continue to take effect after migration. If you bind a plug-in of the same policy after migration, the original policy is overwritten.
- An API configured with the OpenId Connect policy still takes effect after migration. If you bind the JWTAuth plug-in after migration, the original OpenId Connect settings on the API are overwritten.
- In China (Beijing), China (Hangzhou), China (Shenzhen), and China (Shanghai), if you used the backend services of Function Compute before migration but you do not migrate them to the VPC as well, API Gateway temporarily accesses your Function Compute service over the Internet after migration.
4.1. Migrate an API group back to an instance in the classic network
You can also migrate your API group from an instance in a VPC network back to an instance in the classic network. You need to confirm the following technical differences individually before performing group migration:
- Instances in a VPC network support backend TLS1.2 for HTTP connections, but instances in the classic network support only TLS1.0.
- All plug-in configurations become invalid after migration, so the throttling, IP access control, and backend signature policies need to be reconfigured on the instance in the classic network after migration.
- The egress address of API Gateway may be changed after migration. You need to check the egress address on the Instances page to ensure that the egress address of API Gateway is in the whitelist.
- Some new features are no longer supported after migration. Pay attention to the prompts in the console.