PAI-EAS provides multiple access methods and two communication protocols that you can combine to meet your network and performance requirements.
Scenario guide
After a service is deployed, it can be invoked through a shared gateway over HTTP by default with no extra configuration. Use the following guide to quickly find the information you need based on your scenario:
Get started quickly: If your service is already deployed and you want to invoke it by using the default shared gateway, see Invoke a service through a gateway.
Use other access methods: If the shared gateway does not meet your needs, learn about other options and their configurations, such as the dedicated gateway, VPC direct connection, Network Load Balancer (NLB), or service discovery (Nacos). For more information, see Choose an access method below.
Use the gRPC protocol: To use the gRPC binary protocol for lower network overhead and improved inference performance, see Invoke a PAI-EAS inference service over gRPC.
How it works
The general data flow for a PAI-EAS service invocation is as follows:
The client sends a request: Your application sends an inference request to the PAI-EAS service endpoint, which can be a gateway or a direct connection address.
Endpoint routing: The request is routed to a backend service instance through your chosen method: shared gateway, dedicated gateway, VPC direct connection, NLB, or Nacos. If you use a gateway, the gateway layer handles load balancing and routing. If you use a direct connection, the client selects the target instance.
Service instance processing: When the request reaches a PAI-EAS service instance, the model service process performs the inference calculation and returns the result serialized in the specified format, such as JSON or Protobuf.
The client receives the response: After receiving the inference result, the client parses the data and continues with its business logic.
Access methods
Select an access method based on your use case.
Scenario | Recommended method | Network path | Configuration cost |
Quick validation, low-traffic services | Internet or VPC through a shared gateway | Free, simple configuration | |
High security, high stability, high traffic | Internet or VPC through a dedicated gateway | Requires gateway creation and configuration. Additional fees apply. | |
Low-latency, high-concurrency scenarios where the client and the PAI-EAS service are in the same VPC | Direct connection to service instances in the same VPC, bypassing the gateway | Requires VPC configuration | |
High traffic with load balancing | Forwarded through an NLB (The NLB and the PAI-EAS service must be in the same VPC) | Requires creating or associating an NLB | |
Existing Nacos-based service governance system | Registered and discovered through Nacos (The Nacos instance and the PAI-EAS service must be in the same VPC) | Requires you to provide a Nacos instance. |
After you configure a VPC, vSwitch, and security group for a PAI-EAS service:
Not restricted by security group rules: When you access PAI-EAS through a shared gateway or a dedicated gateway, security group rules do not apply. For dedicated gateways, you can configure allowlists to control access.
Restricted by security group rules: When you access PAI-EAS through an NLB, Nacos, or a VPC direct connection, all traffic, including all outbound traffic from PAI-EAS, is subject to security group rules.
Communication protocols
PAI-EAS supports two communication protocols. The available protocol depends on the type of service you deploy:
HTTP/JSON (Default): Enabled automatically after deployment. Suitable for most use cases.
gRPC: A high-performance binary protocol for performance-sensitive or streaming inference scenarios. You must manually enable it during deployment.
FAQ
Cross-region access and billing
Q: How can I access a service from a different region over a private network (using a gateway's VPC endpoint)?
When the PAI-EAS service and the client are in different VPCs across regions, the approach varies based on the gateway type:
Application Dedicated Gateway: You only need to establish cross-VPC network connectivity by using a service such as CEN or a VPC Peering Connection. For more information, see VPC interconnection.
Fully Managed Dedicated Gateway: In addition to establishing cross-VPC network connectivity, you must associate the client's VPC with the dedicated gateway. For more information, see Access a fully managed dedicated gateway from another VPC.
Q: Do I need to pay for cross-region traffic over a private VPC connection? What are the advantages compared to using the Internet?
Yes. When you establish a cross-region connection over a private network, you still incur charges for the cross-region traffic. The specific cost depends on the interconnection method you use. A private VPC connection offers the following advantages over access through the Internet:
Enhanced security: The service is not exposed to the Internet, which reduces security risks.
Higher speed and lower latency: The private network provides stable link quality.
Lower traffic costs: Private network traffic fees are typically lower than Internet traffic fees.
For production environments, we recommend using private VPC endpoints for cross-region access.
Service-to-service invocation
If your application is deployed in a PAI-EAS container and needs to invoke other PAI-EAS services, note the following:
Authentication requirements: All requests must include a valid Authorization Token in the header, regardless of whether you use a public or private VPC endpoint.
Common reasons for failure: By default, PAI-EAS services cannot access the Internet. Attempts to invoke other PAI-EAS services using their public endpoints will fail. To resolve this, see Configure network access for PAI-EAS services. If you encounter 401, 502, or other error codes, see Appendix: Service status codes and common errors for troubleshooting.
Recommended practice: Use private VPC endpoints for service-to-service invocation within PAI-EAS to ensure network connectivity and security.