Function Compute provides instance isolation to support independent runtime environments for AI sandboxes. This feature ensures that an instance handles only one request or all requests within a single session before the instance is released. This creates a secure, reliable, elastic, and low-cost sandbox runtime environment.
Instance isolation patterns
No isolation
By default, Function Compute does not isolate instances. It reuses instances to handle multiple requests. A single instance can process one or more requests concurrently or over time.
Request isolation
A single user request exclusively uses one function instance.
Session isolation
A single user session exclusively uses one function instance.
Scenarios
Multi-tenant isolation: Provides separate environments for different tenants to prevent data leaks when instances are reused. This is common in AI agent scenarios.
Security isolation: Completely isolates states, such as memory and temporary files, to prevent leftover data between requests. For example, when processing sensitive data such as encryption keys or private user information, the environment must be thoroughly cleaned after each execution. This is useful for tasks such as pipeline builds and text-to-image generation.
Short-running tasks with low concurrency: The task runs for a very short time, such as in milliseconds, and concurrency is very low. In this case, the benefit of reusing an instance is less than the overhead of creating a new one. An example is a one-time trigger to clean up temporary files.
Resource release and cleanup: Ensures that external resources, such as database connections and GPU devices, are completely released after each execution.
Avoiding cross-request side effects: This pattern is useful when code contains global variables that depend on external resources, such as database connections or GPU devices. It ensures these resources are completely released after each execution.
How it works
Background and challenges
Function Compute was originally designed to be request-triggered and to release idle instances to reduce costs. As a result, its runtime instances typically have short lifecycles. This design does not support the long-lived instance keepalive required in session isolation scenarios.
Session persistence mechanism
To solve this problem, Function Compute allows elastic instances to automatically switch to an idle state after a request is complete. This provides low-cost instance keepalive. During the idle period, vCPU usage is not billed. Memory is billed at 1/10 of the standard rate. GPU resources are billed at 1/8 to 1/5 of the standard rate, depending on the card type. When the session TTL or session idle timeout is reached, the session lifecycle ends. The instance is then released, and the system scales in to the minimum number of instances. This process is transparent to the user, except for the billing.
If the minimum number of instances is set to 1 or more, an instance quickly wakes up when a request or background task is triggered. It performs a hot start and becomes an active elastic instance. When the request or background task finishes, the active elastic instance automatically switches to an idle state. It remains idle until the session TTL or session idle timeout is reached. Then, the instance is released, and the system scales in to the minimum number of instances.
Isolation guarantee mechanism
Function Compute automatically sets the concurrency per instance to 1 for request isolation scenarios. It also automatically sets the session concurrency per instance to 1 for session isolation scenarios. This ensures that a Function Compute instance handles only one request or session at a time.
Lifecycle mapping and binding
The lifecycle of a request or session is mapped one-to-one to the lifecycle of an instance. The session lifecycle ends based on the session idle and session TTL timeouts. When the request or session lifecycle ends, the corresponding instance lifecycle also ends, and the instance is immediately released.
Limits
Instance type limit: Only instance types with two cores or more support the instance isolation feature. This limit applies when you create or update functions.
Request-level isolation: This feature is only for single-instance, single-concurrency scenarios. After this feature is enabled, Function Compute sets the concurrency per instance to 1. This setting cannot be changed.
Session isolation: The session affinity feature must be configured first. After this feature is enabled, Function Compute sets the session concurrency per instance to 1. This setting cannot be changed.
Built-in runtimes: Built-in runtimes do not support MCP SSE session isolation.
Function type limit: All function types support instance isolation, except for task functions.
Billing
Request isolation
You are charged for the function instance during the request.
Session isolation
You are charged for the function instance during the session lifecycle.
For more information about the billing rules for idle and active elastic instances, see Billing overview.