Function Compute uses Transport Layer Security (TLS) 1.2 or later to encrypt user requests and responses. Proprietary protocols are used for internal communications to prevent data leakage and tampering. This topic describes the safeguards on the data plane in different modules of Function Compute.
Safeguards for the access service
In the internal processes of the data plane, the access service is used to invoke functions.
The access service acts as the handler for function invocations and uses Server Load Balancer (SLB) to balance loads and prevent DDoS attacks. This protects network security.
By default, functions can be accessed only over the Internet. You can specify that functions can be accessed only over specific virtual private clouds (VPCs). A function cannot be accessed over the Internet and VPCs.
Function invocations include synchronous invocations, asynchronous invocations, and asynchronous tasks.
Synchronous invocations
Synchronous invocations use the request-response invocation mode. This indicates that the information about an invocation request is not cached and the system does not retry the request when a function execution error occurs.
Asynchronous invocations
After Function Compute receives invocation requests, the requests are cached to Message Service (MNS). Function Compute caches the requests to MNS, and then returns responses. Then, Function Compute asynchronously obtains the requests from MNS and processes the requests. Function Compute ensures that each request is processed at least once.
MNS queues used by different users are isolated at the account or higher level. For functions with a large number of invocations, the function-level isolation can be used.
By default, Function Compute retries to invoke a function three times if the function fails to be invoked due to function execution errors. If a function fails to be invoked due to other errors such as throttling or system errors, Function Compute retries to invoke the function in binary exponential backoff mode. You can specify the number of retries and maximum time to live (TTL) for messages.
Function Compute allows you to enable the result callback feature for asynchronous invocations. After an asynchronous invocation request is processed, users can use a callback to save function invocation events or verify invocation results.
Safeguards for the scheduling service
In the internal processes of the data plane, the scheduling service manages the lifecycles of compute nodes and function instances and the routing method for function invocations.
Compute nodes
Function Compute uses both Elastic Compute Service (ECS) Bare Metal Instances and ECS instances as compute nodes to implement dynamic migrations.
By default, the scheduling service provides compute nodes with a total of 600 vCPUs and 1200 GB of memory per user. Pooling can be used to provide up to 300 burst vCPUs and 600 GB of burst memory. When the resources in a pool are used up, the scheduling service scales out at a speed of up to 360 vCPUs per minute. When the scale-out speed exceeds the upper limit, a throttling error occurs. If you want to raise the limit on compute nodes, join the DingTalk 11721331 for technical support.
The validity period of a compute node can be up to 120 hours. If the scheduling service detects an error on a compute node, the scheduling service reconstructs the compute node before the validity period ends.
Function instances
Function instances are classified into on-demand instances and provisioned instances. On-demand instances are dynamically generated upon function invocations and are automatically released when they are idle for 5 minutes. Provisioned instances are generated by user configurations and automatic scale-out policies. Provisioned instances are not released when they are idle.
By default, the scheduling service provides 300 burstable function instances for each user. If the number of function instances reach 300, the system performs a scale-out at a speed of no more than 300 function instances per minute. If the scale-out speed exceeds the limit, a throttling error occurs. If you want to raise the limit on burstable function instances, join the DingTalk group 11721331 for technical support.
The maximum validity period of a function instance does not exceed 36 hours. When the function code or the configuration is modified, or an error occurs, such as, the function times out, the memory exceeds the limit, or the client actively terminates the function execution, the scheduling service rebuilds the container instance. Function instances may also be rebuilt in advance due to reasons like load balancing.
Routing method
The scheduling service uses bin-pack to route data. A function instance may respond to multiple function invocation requests, and invocation requests from the same client may be distributed to different function instances for execution. You cannot assume that the resources of function instances, such as global variables or file inputs, are shared or are not shared among different invocations.
The scheduling service limits the time that each function invocation request occupies a function instance based on the function timeout configurations. The scheduling service revokes function instances when a timeout error occurs.
Safeguards for compute nodes
Compute nodes run function code. Function Compute uses two types of compute nodes: ECS bare metal instances and ECS instances. This section describes the safeguards at each layer from the outside to the inside.
Protection capabilities provided by Alibaba Cloud for compute nodes
Alibaba Cloud provides the following protection capabilities for compute nodes. For more information, see Alibaba Cloud Security Whitepaper.
Multi-zone disaster recovery: Compute nodes in a region are distributed across multiple zones to support cross-zone disaster recovery.
Isolated network environment: Compute nodes reside in a VPC, which is an isolated network environment. Other users cannot directly access your compute nodes.
Vulnerability fixing and security updates: Function Compute fixes the vulnerabilities of compute nodes and updates compute nodes to enhance security. The update processes are transparent to users.
User-level and function-level isolation for function instances
Security isolation by using the virtualization technology
Compute nodes with ECS bare metal instances can run function instances of different users. The Alibaba Cloud Sandbox technology is used to provide function-level virtualization and container isolation. ECS instances can run only function instances of the same user. ECS isolation provides user-level virtualization isolation and uses container technologies such as RunC to isolate containers at the function level.
User-controlled network access of function instances
You can configure a private IP address for a function instance. This way, other users cannot directly access the function instance. Function instances are isolated from each other, which is implemented by using Open vSwitch, iptables, and route tables. You can configure one of the following access modes for a function instance to access external networks:
Allow function instances to access only the Internet. This is the default access mode.
Allow function instances to access only the specified VPC, such as the private IP address of an ApsaraDB RDS instance, an Apsara File Storage NAS file system, or an ECS instance.
Allow function instances to access both the Internet and the specified VPC.
Prohibit function instances from accessing the Internet or VPCs.
Limited resources of function instances
The CPU computing capacity of a function instance is proportionally allocated based on the memory size. During a cold start of a function instance, more CPU resources are allocated to the function instance for a duration up to 20 seconds to accelerate the cold start. By default, the file system capacity is 512 MB and the network bandwidth is 1 Gbit/s for a function instance. For a performance instance, the file system capacity can be up to 10 GB and the network bandwidth can be up to 5 Gbit/s.
Freezing of idle function instances
If a function instance does not process requests, the function instance is frozen. You can unfreeze the frozen instance before the next request is processed.
Allowed logon to function instances
Authenticated users can log on to function instances for online troubleshooting.
Vulnerability fixing and security update
Function Compute fixes the vulnerabilities of function instances and updates function instances to enhance security. The update processes are transparent to users.
Security capabilities improved by runtimes
Temporary identity credentials
Function Compute applies for temporary identity credentials for the Resource Access Management (RAM) role that executes functions. The credentials are injected into runtime environments by using environment variables and passed into function code by using input parameters. The temporary identity credentials can be used to access other Alibaba Cloud services.
Collection of information about function execution errors
Runtime environments collect the information about function execution errors and logs to help you identify errors.
Lifecycle hooks and capability extension
Runtime environments provide hooks such as the Initializer hook, PreFreeze hook, and PreStop hook to help you extend security capabilities based on your business requirements.
Non-persistent storage
The file system and memory provided by the runtime environment are released when a function instance is released. The data is not persistently stored in the local file system or memory of the function instance. To configure persistent data storage, use Apsara File Storage NAS or Object Storage Service (OSS).
Immutable code and layers
Modifications to the code directory /code and layer directory /opt take effect only for the current function instance. The modifications do not rewrite the code or libraries of other function instances that process invocation requests for the same function.
Vulnerability fixing and security update
If user compatibility is involved during vulnerability fixing and database update in runtime environments, you are notified in advance by using methods such as internal messages or text messages. For custom runtimes and custom container images, you must ensure the security of runtime environments. For runtime environments compiled by using programming languages such as Java, C#, and Go, you must perform the following operations to fix the security vulnerabilities of Function Compute SDK: update the dependencies, recompile the code, and then upload the code.
Consistent support time for runtime environments of multiple versions with the community
The community supports each runtime environment version in a specific period of time. If a runtime environment version is no longer supported by the community, Function Compute announces the time when the runtime environment version is not supported accordingly. The support gradually stops in the sequence of prohibiting new functions, prohibiting modifications to existing functions, and prohibiting function execution. Function Compute does not ensure that the runtime environment versions that are no longer supported can be used as expected.