1. API Gateway instance types
An API Gateway instance is a group of resources used to access and process your APIs. The resources include public IP addresses, internal IP addresses, outbound public IP addresses, SLB instances, servers, and storage resources. API groups can only run on valid instances. API Gateway provides the following instance types: shared instance (classic network), shared instance (VPC), and dedicated instance (VPC).
1.1. Instance type description
-
Shared instance (classic network): If you select a shared instance, you are billed based on the number of API calls and traffic generated on the Internet. However, resources such as the server resource pool, IP addresses, and bandwidth are shared by a group of users in a region. By default, a maximum of 500 requests per second (RPS) is allowed for API groups under a shared instance. If you want to increase the RPS value, you can directly purchase dedicated instances. Shared instances (classic network) are provided in the earliest version of API Gateway. This instance type supports access over the Internet or VPC. It also supports backend service addresses in a VPC, the Internet, or the classic network. This instance type does not support the newly released plug-in system.
-
Shared instance (VPC): The billing methods and RPS management rules are the same for both shared instances of the VPC and classic network types. Instances of the VPC type are newly introduced for technical reconstruction. Such instances support the entire plug-in system, covering JSON Web Token (JWT) authentication, throttling, IP access control, backend signature, cross-origin resource sharing (CORS), caching, and routing. They also support access over the Internet or a VPC and backend service addresses in a VPC and on the Internet. However, they do not support backend service addresses of the classic network. Instances of the VPC and classic network types have differences in technical implementation.
-
Dedicated instance (VPC): The technical specifications of dedicated instances (VPC) and shared instances (VPC) are the same. To obtain a higher SLA guarantee, you can purchase a higher RPS to obtain dedicated resources. The resources include inbound public IP addresses, IP addresses of VPCs, outbound Internet bandwidth, and isolated server clusters. For more information about the specifications and pricing of dedicated instances, seePricing of dedicated instances
1.2. Technical specifications and limits
| Item | Shared instance (classic network) | Shared instance (VPC) | Dedicated instance (VPC) |
|---|---|---|---|
| Scenarios and suggestions | Shared instances (classic network) are provided in the earliest version of API Gateway and have feature limits. We do not recommend that you use this instance type unless you configure a backend service address of the classic network for API Gateway. | R&D and test environments. | Production environments. |
| Activation fee | No fee. | No fee. | Instance type fee. |
| SLA | 99.9% | 99.9% | 99.95% ~ 99.99% |
| Billing method | Number of API calls + Internet traffic fee. | Number of API calls + Internet traffic fee. | Instance type fee + Internet traffic fee. |
| Inbound public IP address | Multi-tenant sharing. | Multi-tenant sharing. | Exclusive. |
| Inbound IP address in a VPC | Multi-tenant sharing. | Multi-tenant sharing. | Exclusive (only accessible from the specified VPC). |
| Outbound Internet bandwidth | Outbound IP address and bandwidth shared by multiple tenants. | Outbound IP address and bandwidth shared by multiple tenants. | Exclusive outbound IP address and bandwidth. |
| Management of hybrid cloud APIs | Not supported. | Not supported. | Supported. For more information, seeCentralized management of hybrid cloud APIs. |
| Request body length | 8M Bytes | 8M Bytes | 32M Bytes |
| Circuit breaker plug-in | Not supported. | It is configured by default and cannot be customized. | It can be customized. |
| Caching | Not supported. | 30 MB per user. | Based on the instance type. |
| Dashboard | Not supported. | Not supported. | *Supported. |
| Custom log content | Not supported. | Not supported. | *Supported. |
Note: * indicates that the feature has been published recently.
2. Technical differences between shared and dedicated instances
The following table lists important technical differences between shared and dedicated instances. If you have any questions, submit a ticket.
| Item | Shared instance (classic network) | Shared instance (VPC) and dedicated instance (VPC) |
|---|---|---|
| Plug-in system | Not supported. | Supported. |
| Backend service address | The backend service address of the classic network is supported. | The backend service address of the classic network is not supported. The backend service address in a VPC and public address are supported. |
| Function Compute | It accesses API Gateway over the internal network in the same region. | It accesses API Gateway over the internal network in the same region. If Function Compute is deployed in the China (Beijing), China (Hangzhou), China (Shenzhen), or China (Shanghai) region, you must switch Function Compute to a VPC. |
| HTTPS TLS version | TLS1.0 | TLS 1.0, TLS 1.1, or TLS 1.2 |
| CORS | All domain names and headers are allowed by default. | You can customize the configuration by using the CORS plug-in. |
| Cross-domain flash | The crossdomain.xml file is preconfigured. | Not supported. You can set the backend service type to Mock to achieve cross-domain flash. |
3. Instances supported in each region
| RegionId | Region name | Shared instance (classic network) | Shared instance (VPC) and dedicated instance (VPC) |
|---|---|---|---|
| cn-qingdao | China (Qingdao) | Supported | Supported |
| cn-beijing | China (Beijing) | Supported | Supported |
| cn-zhangjiakou | China (Zhangjiakou-Beijing Winter Olympics) | N/A | Supported |
| cn-huhehaote | China (Hohhot) | N/A | Supported |
| cn-hangzhou | China (Hangzhou) | Supported | Supported |
| cn-shanghai | China (Shanghai) | Supported | Supported |
| cn-shenzhen | China (Shenzhen) | Supported | Supported |
| cn-heyuan | China (Heyuan) | N/A | Supported |
| cn-hongkong | China (Hong Kong) | Supported | Supported |
| ap-northeast-1 | Japan (Tokyo) | N/A* | Supported |
| ap-southeast-1 | Singapore | Supported | Supported |
| ap-southeast-2 | Australia (Sydney) | N/A | Supported |
| ap-southeast-3 | Malaysia (Kuala Lumpur) | N/A | Supported |
| ap-southeast-5 | Indonesia (Jakarta) | N/A* | Supported |
| ap-south-1 | India (Mumbai) | N/A | Supported |
| 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 |
Instances of the classic network type in the Japan (Tokyo) and Indonesia (Jakarta) regions are no longer supported.
4. Migrate an API group between instances
You can migrate an API group between instances in the API Gateway console. It takes
about 1 to 10 minutes for the migration to take effect on the API group based on the
cache expiration time of DNS servers. The following sections describe the migration
procedure and precautions when you migrate an API group between instances.
4.1. Migrate an API group to a shared instance (VPC)
You can migrate API groups between instances. To migrate an API group, follow these
steps: Log on to the API Gateway console. In the left-side navigation pane, choose
Publish APIs > API Groups. On the Group List page, click the target API group. On
the Group Details page, click Modify API Group's Instance and migrate the API group. The migration takes effect immediately on the DNS servers
of the second-level domain names of API Gateway. If you want to migrate an API group
for which you have changed the value of RPS, submit a ticket. Instances of the VPC
and classic network types have differences in technical implementation. We recommend
that you understand all the following technical details before you migrate API groups.
- API Gateway of a VPC does not support backend service addresses of the classic network. If your backend service address belongs to the classic network, API operations cannot be called after you migrate an API group. Change the backend configuration by using VPC access authorization before you migrate an API group.
- If the outbound IP address of API Gateway changes, go to the Instances page to check the outbound IP address. Make sure that the outbound IP address of API Gateway is included in the list of IP addresses that are allowed to access the backend service.
- API Gateway of a VPC does not provide a preconfigured
crossdomain.xmlfile. If you want to use the file, configure an API in mock mode. - The throttling, IP access control, and backend signature policies that have been configured are still valid. After the plug-ins of throttling, IP access control, and backend signature policies are used, these configured policies will become invalid.
- The APIs for which you have configured the OpenID Connect access policy are still valid. After the JWTAuth plug-in is used, the related configuration on APIs will become invalid.
- If you use Function Compute as a backend service that is deployed in the China (Beijing), China (Shanghai), China (Hangzhou), or China (Shenzhen) region and you have not migrated Function Compute to a VPC, API Gateway will temporarily access your Function Compute over the Internet.
4.2. Migrate an API group to a dedicated instance (VPC)
You can purchase a dedicated instance to obtain a higher RPS and SLA. To migrate an
API group to a dedicated instance (VPC), follow these steps: Log on to the API Gateway
console. In the left-side navigation pane, choose Publish APIs > API Groups. On the
Group List page, click the target API group. On the Group Details page, click Modify API Group's Instance and migrate the API group. The migration takes effect immediately on the DNS servers
of the second-level domain names of API Gateway. After you migrate the API group to
a dedicated instance, the maximum RPS and HTTPS security policies of the API group
will be replaced with those of the target instance. If you want to migrate an API
group from a shared instance (classic network) to a dedicated instance (VPC), understand
the following technical details before the migration. We recommend that you conduct
a test before the migration.
- API Gateway of the VPC type does not support backend service addresses of the classic network. If your backend service address belongs to the classic network, API operations cannot be called after you migrate an API group. Change the backend configuration by using VPC access authorization before you migrate an API group.
- If the outbound IP address of API Gateway changes, go to the Instances page to check the outbound IP address. Make sure that the outbound IP address of API Gateway is included in the list of IP addresses that are allowed to access the backend service.
- API Gateway of the VPC type does not provide a preconfigured
crossdomain.xmlfile. If you want to use the file, configure an API in mock mode. - The throttling, IP access control, and backend signature policies that have been configured are still valid. After the plug-ins of throttling, IP access control, and backend signature policies are used, these configured policies will become invalid.
- The APIs for which you have configured the OpenID Connect access policy are still valid. After the JWTAuth plug-in is used, the related configuration on APIs will become invalid.
- If you use Function Compute as a backend service that is deployed in the China (Beijing), China (Shanghai), China (Hangzhou), or China (Shenzhen) region and you have not migrated Function Compute to a VPC, API Gateway will temporarily access your Function Compute over the Internet.
4.3. Migrate an API group back to a shared instance (classic network)
You can migrate an API group back to a shared instance (classic network). To migrate
an API group, follow these steps: Log on to the API Gateway console. In the left-side
navigation pane, choose Publish APIs > API Groups. On the Group List page, click the
target API group. On the Group Details page, click Modify API Group's Instance and migrate the API group. Understand the following technical details before you
migrate an API group.
- For instances of the VPC type, the backend service can use the TLS 1.2 protocol. For instances of the classic network type, the backend service can only use the TLS 1.0 protocol.
- All plug-in configurations become invalid. The throttling, IP access control, and backend signature policies for instances of the classic network type must be reconfigured.
- If the outbound IP address of API Gateway changes, go to the Instances page to check the outbound IP address. Make sure that the outbound IP address of API Gateway is included in the list of IP addresses that are allowed to access the backend service.
- Some new features may not be supported. Pay attention to the prompt displayed in the API Gateway console.