Function Compute provides security mechanisms to help you reduce the workload on security protections. Securing your application code, credentials, and configurations is your responsibility.
This page covers the security practices that are your responsibility when running functions on Function Compute.
Credential security
Leaked credentials are the most common cause of account compromise. Use Resource Access ManagementResource Access Management (RAM) to grant RAM users only the permissions their workloads actually need. For time-limited access, issue Security Token Service (STS) tokens instead of long-lived access keys — STS tokens expire automatically, which limits the blast radius of a leak.
Function code and layers
Keep credentials out of code
Never hardcode identity credentials in function code or layers. If credentials appear in source code, they propagate to every environment the code reaches — version control, CI/CD pipelines, and anyone who can download the deployment package.
Protect temporary download URLs
Function Compute generates temporary, authenticated download URLs for code packages and layers. Treat these URLs as secrets — anyone with the URL can download the package until it expires.
Keep code and layer size minimal
Oversized code packages and layers increase cold start duration and can prevent function instances from starting. Keep your deployment artifact as small as possible by excluding development dependencies, test fixtures, and generated build artifacts.
Write idempotent functions
For asynchronous invocations and asynchronous tasks, Function Compute retries execution when errors occur — an event can be processed at least once, so the same event may trigger more than one invocation. Design functions to produce the same result when processing duplicate events — check whether an operation has already succeeded before repeating it.
Understand execution environment reuse
Function Compute may reuse a function instance across multiple invocations, or may not — there is no guarantee either way. Because of this:
Reuse is possible: global variables, environment variables, and file system state modified by one invocation may persist into the next. Never store per-request user data or sensitive information in global scope.
Reuse is not guaranteed: do not depend on state from a previous invocation being present. Initialize what each invocation needs within the handler itself.
Account for instance-level concurrency limits
A single function instance can process multiple invocation requests concurrently, but the actual concurrency depends on the runtime:
Node.js: single-threaded only. Concurrent requests are handled through the event loop, not parallel execution.
Python: the global interpreter lock (GIL) prevents true parallel execution for CPU-intensive work.
Set per-instance concurrency to a value appropriate for your workload and runtime constraints.
Handle freezing after invocation
When a function returns its result, Function Compute freezes the instance. Any background threads, coroutines, or asynchronous log writes that have not completed are suspended. Do not rely on background work finishing after the handler returns.
Resource limits
| Resource | Limit |
|---|---|
Request or response headers | 4 KB |
| Environment variables | 4 KB |
Request body | 16 MB |
These limits are subject to change. Check the official documentation for current values. If a limit is exceeded, the function may not behave as expected.
Keep runtimes up to date
Function Compute aligns runtime environment support with the upstream community lifecycle. When a runtime version reaches end-of-life in the community, Function Compute stops providing services — including function execution — for that version. Migrate to a supported runtime before this happens, and patch vulnerabilities in your code and dependencies promptly.
Function configuration
Set resource quotas carefully
Misconfigured resource quotas have two failure modes: too high, and errors generate excessive costs; too low, and the service becomes unavailable or slow.
| Setting | Too high | Too low |
|---|---|---|
| Maximum execution duration | Higher costs if a runaway function keeps running | Timeouts on legitimate requests |
| Memory size | Higher costs per invocation | Out-of-memory errors, degraded performance |
| Per-instance concurrency | Degraded performance or errors under concurrent load | Underutilized instances |
| Resource quota | Runaway costs if bugs cause unexpected invocation volume | Legitimate traffic gets throttled |
Control who can invoke functions
Use RAM to grant each RAM user the minimum set of permissions needed to access Function Compute.
Restrict function access by VPC: configure each function to accept invocations only from specific virtual private clouds (VPCs).
Configure trigger permissions precisely to prevent functions from being invoked by unintended sources.
Control how functions access external networks
Restrict outbound network access to the VPCs and endpoints your function needs. Allowing unrestricted outbound access increases the risk of sensitive data exfiltration.
Scope the function's RAM role
Grant the RAM role attached to your functions only the permissions required to access the Alibaba Cloud services they use — for example, Object Storage Service (OSS) or Tablestore. Overly permissive roles amplify the impact of any code vulnerability.
Encrypt NAS data in transit
For File Storage NAS file systems mounted on Function Compute, data is transmitted over VPCs to ensure data security. You can enable the transmission encryption feature based on your business requirements. See Encryption in transit for NFS file systems.