Function Compute uses TLS 1.2 or later to encrypt the transmitted invocation requests and return packets when it communicates with users. Private protocols are used for internal communications to prevent information from being leaked or tampered with. This topic describes the safeguards on the data plane in different modules for 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 entry for function invocations and uses Server Load Balancer (SLB) to implement load balancing and anti-DDoS.
By default, functions can be accessed only over the Internet. You can specify that functions can be accessed only over specific virtual private cloud (VPC). A function cannot be accessed over both the Internet and VPCs.
- Synchronous invocations
The request-response invocation mode is used for synchronous invocations. The request information is not cached and the function is not retried when errors occur.
- Asynchronous invocations
The invocation requests are cached to Message Service (MNS) after they are received by Function Compute. Responses are returned immediately after the requests are cached. Then, Function Compute asynchronously obtains the requests from MNS for execution. Function Compute ensures that the requests are executed 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 an invocation three times if the invocation fails due to a function execution error. For other errors, such as throttling and system errors, Function Compute retries the invocation in binary backoff mode. You can specify the number of retries and the maximum time to live (TTL) for messages.
- You can configure Result callback in Function Compute for asynchronous invocations. Callbacks can be used to save the invocation events and verify the invocation results.
- Asynchronous tasks
Compared with asynchronous invocations, asynchronous tasks provide more task control and observability capabilities. The execution of asynchronous tasks can be terminated. For more information, see Overview.
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 calls routes.
Compute nodes
Both ECS Bare Metal Instances and ECS instances are used in Function Compute to implement dynamic migration.
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 increase the upper limit on compute nodes, join the DingTalk group 11721331 to contact Function Compute technical support.
The maximum validity period of a compute node does not exceed 120 hours. When the scheduling service detects an error on a compute node, it rebuilds the compute node in advance.
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 can generate up to 300 burst function instances for each user. When this limit is reached, the scaling is performed at a speed of up to 300 instances per minute. When the scale-out speed reaches the limit, a throttling error occurs. If you want to increase the upper limit on burst function instances, join the DingTalk group 11721331 to contact Function Compute 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.
Call routes
The scheduling service uses the bin-pack algorithm to call routes. A function instance may be reused by multiple function invocations. The invocation requests from the same client may be distributed to different function instances for execution. You cannot assume that the function instance resources, such as global variables and 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
The compute node layer provides standard Alibaba Cloud safeguards
- Multi-zone disaster recovery: Compute nodes in a region are distributed across multiple zones. Cross-zone disaster recovery is supported.
- Isolated VPC environment: Compute nodes are located in an isolated VPC environment. Users cannot directly access compute nodes.
- Vulnerability fixing or security upgrade: Function Compute is responsible for vulnerability fixing and security upgrade of compute nodes. The upgrade processes are transparent to users.
User-level and function-level isolation are supported for instances
- Virtualization-level security isolation
Compute nodes with ECS Bare Metal Instances can run function instances from different users. Alibaba Cloud Sandboxed-Containers are 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 implement function-level container isolation.
- Network access of function instances can be configured and controlled by users
A function instance is configured with a private IP address, and users cannot directly access the private IP address. Instances are isolated with each other. Network isolation is implemented by using Open vSwitch, iptables, and routing tables. The following external network access modes can be configured:
- Allow functions to access only the Internet: Function instances can access only the Internet. This is the default mode.
- Allow functions to access only a specified VPC: Function instances can access only the specified VPC, such as a private IP address of ApsaraDB RDS, Apsara File Storage NAS (NAS), or Elastic Compute Service (ECS).
- Allow functions to access both the Internet and a specified VPC: Function instances can access both the Internet and a specified VPC.
- Prohibit functions from accessing the Internet or VPCs: Function instances do not have the permissions to access external networks.
- Restricted instance resources
The CPU computing power is proportionally allocated based on the memory size configurations. During a cold start of a function instance, the limits can be temporarily exceeded for 20s to accelerate the cold start. By default, a function instance is configured with a 512 MB file system and 1 Gbit/s network bandwidth. If you use performance instances, a maximum of 10 GB file system and 5 Gbit/s network bandwidth can be provided.
- Freezing of idle function instances
When a function instance does not process requests, the function instance is frozen. The frozen instance is unfrozen before the next request is executed.
- Allowed logon to function instances
Authenticated users can log on to function instances for online problem locating.
- Vulnerability fixing and security upgrade
Function Compute is responsible for vulnerability fixing and security upgrades for sandboxed containers of function instances, and the upgrade processes are transparent to you.
Runtime environments assist in improving security capabilities
- Temporary identity credentials
Function Compute applies for temporary identity credentials for the execution role that you configured. The credentials are injected into the runtime environments through environment variables and passed to your code through input parameters when the invocation is made. The temporary identity credentials can be used to access other Alibaba Cloud services.
- Collection of information about function execution errors
The runtime environments collect the information about function execution errors and logs for you to check whether errors occur.
- Lifecycle hooks and extension capabilities
The 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 environments
The file system and memory provided by the runtime environment are released when a function instance is released. You cannot use the local file system or memory of the function instance to persist data. If you want to persist data, you can configure 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 on the instance. The modification does not rewrite the code or libraries of other instances of the same function.
- Vulnerability fixing and security upgrade
If user compatibility is involved in vulnerability fixing and database upgrade in the runtime environments, users are notified in advance by means such as internal messages or text messages. For custom runtimes and custom container images, you must ensure the security of the runtime environment. For compiled languages, such as Java, C#, and Golang, you must update the dependencies and recompile and upload the code to incorporate the SDK vulnerability fixings that are provided by Function Compute.
- Support time for runtime environments of different versions are the same as that in the community
Communities support versions of runtime environments in a specified period of time. For the versions that are no longer supported by the communities, Function Compute gives the deadline for support accordingly. The support gradually stops in the sequence of prohibiting new functions, prohibiting modification of existing functions, and prohibiting function execution. Function Compute does not ensure that the runtime versions that are no longer supported can be executed as expected.