Function Compute encrypts all user requests and returned results using Transport Layer Security (TLS) 1.2 or later. Internal service communications use proprietary protocols to prevent information leakage and tampering.
This topic describes the security protections Function Compute provides across four layers of the data plane: the access service, the scheduling service, compute nodes, and runtime environments.
Shared responsibility
Function Compute secures the underlying infrastructure — compute nodes, network isolation, runtime environments, and internal communications. You are responsible for securing your function code, managing access permissions through Resource Access Management (RAM), and configuring network access modes to match your security requirements.
Security of the access service
The access service handles all function invocations on the data plane. It uses Server Load Balancer (SLB) for load balancing and network security protection.
By default, functions are accessible over the Internet only. To restrict access to specific virtual private clouds (VPCs), configure VPC-only access for the function. Internet access and VPC access are mutually exclusive — a function cannot be accessed over both simultaneously.
Function Compute supports three invocation types:
Synchronous invocations: Use the request-response mode. Invocation request details are not cached, and the system does not retry failed invocations caused by function execution errors.
Asynchronous invocations: After Function Compute receives an invocation request, the request is cached to Simple Message Queue (SMQ, formerly MNS), and a response is returned immediately. Function Compute then retrieves and processes the request asynchronously. Each request is processed at least once.
SMQ queues used by different users are isolated at the account or higher level. For functions with high invocation volumes, isolation can be configured at the function level.
If an invocation fails due to a function execution error, Function Compute retries up to 3 times. For other errors such as throttling or system errors, retries use binary exponential backoff. You can configure the maximum number of retries and the maximum time to live (TTL) for messages.
Enable the result callback feature to save function invocation events to or push function invocation results to downstream services after an asynchronous invocation completes.
Asynchronous tasks: Provide more task control and observability than asynchronous invocations. Terminate a task based on your business requirements. For details, see Asynchronous tasks.
Security of the scheduling service
The scheduling service manages compute node lifecycles, function instance lifecycles, and invocation routing.
Compute nodes
Function Compute uses ECS Bare Metal Instances and ECS instances as compute nodes. Both types support dynamic migration.
Each user is provisioned with 50–600 vCPUs and 100–1,200 GB of memory. Pooled resources provide up to 300 burst vCPUs and 600 GB of burst memory. If the pool is exhausted, the scheduling service scales out at up to 360 vCPUs per minute — requests that exceed this rate trigger a throttling error. For per-account limits by region, see Compute node limits for a single account in each region.
Compute nodes have a maximum validity period of 120 hours. If the scheduling service detects an error on a compute node, the node is reconstructed before the validity period ends.
Function instances
Function instances are either on-demand or provisioned:
On-demand instances: Dynamically created when a function is invoked and automatically released after 5 minutes of idle time.
Provisioned instances: Not automatically released when idle. The actual number is determined by the scaling policies you configure, within the minimum and maximum counts you specify.
Each user supports up to 300 burstable function instances. If this limit is reached, the scheduling service scales out at up to 300 instances per minute — exceeding this rate triggers a throttling error. To raise the burstable instance limit, join the DingTalk group (ID 64970014484) for technical support.
Function instances have a maximum validity period of 36 hours. An instance is reconstructed when:
Function code or instance configuration is modified
The function execution times out
Memory usage exceeds the configured limit
The client terminates the function execution
The scheduling service initiates reconstruction for load balancing
Routing
The scheduling service routes invocations using the bin-pack algorithm. A single function instance may handle multiple invocation requests, and requests from the same client may be dispatched to different instances. Do not assume that global variables or file state are shared — or isolated — across invocations.
The scheduling service enforces the function timeout period you configure. When a timeout expires, the function instance is reclaimed.
Security of compute nodes
Function Compute uses two types of compute nodes — ECS Bare Metal Instances and ECS instances — with security capabilities at each layer from the hardware up.
Alibaba Cloud infrastructure protections
Alibaba Cloud provides the following protections for all compute nodes. For details, see the Alibaba Cloud Security Whitepaper.
Multi-zone disaster recovery: Compute nodes in a region are distributed across multiple zones to support cross-zone failover.
Isolated network environment: Compute nodes run inside a VPC. Other users cannot directly access your compute nodes.
Vulnerability fixing and security updates: Function Compute patches and updates compute nodes automatically. Update processes are transparent to you.
User-level and function-level isolation
Virtualization-based isolation
ECS Bare Metal Instances can host function instances from multiple users. Alibaba Cloud Sandboxed-Container runs each function on an isolated VM. ECS instances host function instances from the same user only, with user-level isolation enforced through virtualization. Functions are isolated using container technologies such as runC.
Network isolation
You can configure a private IP address for a function instance, preventing direct access by other users. Inter-instance isolation is implemented using Open vSwitch, iptables, and route tables.
Configure outbound network access for each function instance using one of the following modes:
| Mode | Description |
|---|---|
| Internet only (default) | Function instances access the Internet but not VPCs |
| VPC only | Function instances access a specified VPC (e.g., ApsaraDB RDS, File Storage NAS, or ECS instances) but not the Internet |
| Internet and VPC | Function instances access both the Internet and a specified VPC |
| No access | Function instances cannot access the Internet or any VPC |
Resource limits
CPU capacity is allocated proportionally to the configured memory size. During a cold start, additional CPU resources are allocated for up to 20 seconds to reduce startup time.
| Resource | Standard instance | Performance instance |
|---|---|---|
| File system capacity | 512 MB | Up to 10 GB |
| Network bandwidth | 1 Gbit/s | Up to 5 Gbit/s |
Idle instance freezing
When a function instance is not processing requests, it is frozen. The instance is unfrozen before the next request is processed.
Instance login for troubleshooting
Authenticated users can log in to function instances for online troubleshooting.
Vulnerability fixing and security updates
Function Compute patches and updates function instances automatically. Update processes are transparent to you.
Security capabilities of runtime environments
Temporary identity credentials
Function Compute requests temporary identity credentials for the RAM role that executes functions. Credentials are injected into the runtime environment via environment variables and passed into function code as input parameters. Use these temporary credentials to access other Alibaba Cloud services from your function code.
Function execution error collection
Runtime environments collect function execution errors and logs to help you diagnose issues.
Lifecycle hooks
Runtime environments provide the Initializer hook and PreStop hook to extend security capabilities based on your requirements.
Non-persistent storage
The file system and memory of a runtime environment are released when the function instance is released. Data is not persisted to local storage. For persistent storage, use NAS or Object Storage Service (OSS).
Immutable code and layers
Changes to the code directory /code and the layer directory /opt apply only to the current function instance. They do not affect the code or libraries of other function instances handling invocations for the same function.
Vulnerability fixing and runtime updates
For managed runtimes, Function Compute handles vulnerability patches automatically, with advance notification via internal messages or SMS when changes affect user compatibility.
For custom runtimes and custom container images, you are responsible for securing the runtime environment.
For runtimes compiled with languages such as Java, C#, or Go, fix SDK vulnerabilities by updating dependencies, recompiling the code, and uploading the updated package.
Runtime version lifecycle
Each runtime version has a community support period. When a version reaches end of community support, Function Compute announces the end-of-support timeline and discontinues support in the following sequence:
New functions cannot use the runtime version.
Existing functions cannot be modified.
Function execution is stopped.
Function Compute does not guarantee that end-of-support runtime versions will behave as expected.