Notes and Constraints

Permissions

• You must be assigned both the APIG Administrator and VPC Administrator roles so that you can create gateways.
• Alternatively, you must be attached the APIG FullAccess policy.
• For details about how to use custom policies, see APIG Custom Policies.

Network

• If you use 192.x.x.x or 10.x.x.x, APIG uses 172.31.32.0/19 as the internal subnet.
• If you use 172.x.x.x, APIG uses 192.168.32.0/19 as the internal subnet.

Number of available private IP addresses in the subnet

The basic, professional, enterprise, and platinum editions of APIG require 3, 5, 6, and 7 private IP addresses. Check that the subnet you choose has sufficient private IP addresses on the VPC console.

Load

• VPCs (workloads) where gateways have been deployed cannot be changed.

Specifications

• During the specification change, the persistent connection is intermittently disconnected and needs to be re-established. You are advised to change the specification during off-peak hours.
• Specifications can be upgraded but cannot be downgraded.
• Changing the gateway edition will also change the private network access IP addresses. Modify your firewall or whitelist configuration if necessary for service continuity. Do not perform any other operations on the gateway. After the change is complete, adjust the firewall or whitelist configuration based on service requirements.

API group

Each API can belong to only one group.

SSL Certificate

• Only SSL certificates in PEM format are supported.
• SSL certificates support only the RSA and ECDSA encryption algorithms.

Domain name

• By default, the debugging domain name of an API group can only be resolved to a server in the same VPC as the gateway. If you want to resolve the domain name to a public network, bind an EIP to the gateway.
• The debugging domain name cannot be used for production services and can be used only for application debugging.
• Groups under the same gateway cannot be bound with a same independent domain name.
• If a domain name is already bound to a port, it cannot be bound to the same port again.
• If different ports are used for the same domain name, all ports take effect no matter whether any of them are bound to, modified, or unbound from the SSL certificate or whether client authentication is enabled or disabled.
• If you access backend services through a load balance channel, the port bound to the independent domain name must be the same as the access port of the backend server in the load balance channel.
• After an independent domain name is bound to a port, if you use an IP address to access an API in a custom group, you need to add the header parameter host to the request. The host value should include the port number for access, unless you are using the default ports 80 or 443, in which case the host value is not necessary.
• Accessing APIs by IP address is not advised, it requires IP certificates for SSL. Otherwise, the connection may be insecure.
• HTTP-to-HTTPS redirection is only suitable for GET and HEAD requests. Redirecting other requests may cause data loss due to browser restrictions. Redirection takes effect only when the API request protocol is HTTPS or HTTP&HTTPS and an SSL certificate has been bound to the independent domain name.

API policies

• An API can be bound with only one policy of the same type (request throttling, proxy cache, or third-party authorizer) for a given environment, but each policy can be bound to multiple APIs.
• Policies are independent of APIs. A policy takes effect for an API only after they are bound to each other. When binding a policy to an API, you must specify an environment where the API has been published. The policy takes effect for the API only in the specified environment.
• After you bind a policy to an API, unbind the policy from the API, or update the policy, you do not need to publish the API again.
• Taking an API offline does not affect the policies bound to it. The policies are still bound to the API if the API is published again.
• Policies that have been bound to APIs cannot be deleted.

Credential

• A credential can be bound to a maximum of 1,000 APIs.
• You can create a maximum of five AppCodes for each credential.

Gateways

5

√

API groups

1500

√

APIs

Number of APIs for each gateway edition:

• Basic: 250
• Professional: 800
• Enterprise: 2000
• Platinum: 8000

√

APIs

1000 for each group

x

Backend policies

5

√

Credentials

50. The credential quota includes the apps you have created.

√

Request throttling policies

• You can create a maximum of 300 request throttling policies for each gateway.
• The call limit for a single user cannot exceed that for the target API.
• The call limit for a single app (credential) cannot exceed that for a single user.
• The call limit for a single IP address cannot exceed that for the target API.

√

Environments

10

√

Signature keys

200

√

Access control policies

100

√

VPC channels (load balance channels)

200

√

Variables

You can create a maximum of 50 variables for an API group in each environment.

√

Independent domain names

A maximum of five independent domain names can be bound to an API group.

√

ECSs

A maximum of 10 ECSs can be added to a VPC channel.

√

Parameters

A maximum of 50 parameters can be created for an API.

√

API publication records

A maximum of 10 publication records of an API can be retained for each environment.

√

API access rate

Up to 6000 times per second

√

Excluded applications (Credentials)

A maximum of 30 excluded apps can be added to a request throttling policy.

√

Excluded tenants

A maximum of 30 excluded tenants can be added to a request throttling policy.

√

Access to a subdomain name (debugging domain name)

A subdomain name can be accessed up to 1000 times a day.

x

Maximum size of an API request package

12 MB

√

TLS protocol

TLS 1.1 and TLS 1.2 are supported. TLS 1.2 is recommended.

√

Custom authorizers

50

x

Plug-ins

500

√

HTTP protocol

When the HTTP protocol is used, the maximum size of URL+Header is 32 KB.

x