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 the network security.
By default, functions can be accessed only over the Internet. You can configure that functions can be accessed only over specific virtual private clouds (VPCs). A function cannot be accessed over the Internet and VPCs at the same time.
Function invocations include synchronous invocations, asynchronous invocations, and asynchronous tasks.
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
After Function Compute receives invocation requests, the requests are cached to Message Service (MNS). After the requests are cached, responses are returned. 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 by account or another metric. For frequently invoked functions, MNS queues can be isolated by function.
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.
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, function instances, and invocation routes.
Compute nodes
Function Compute uses Elastic Compute Service (ECS) bare metal instances and ECS instances as compute nodes to implement dynamic migrations at the user level.
By default, the scheduling service provides compute nodes with 600 vCPUs and 1200 GB of memory for a user. Pooling can be used to provide up to 300 burstable vCPUs and 600 GB of burstable memory. When the resources in a pool are used up, the scheduling service increases resources at a speed of up to 360 vCPUs per minute. When the speed exceeds the upper limit, throttling occurs. If the existing compute nodes cannot meet your business requirements, you can join the DingTalk group (ID: 11721331) for 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, the service 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 the instances are idle for 5 minutes. Provisioned instances are generated based on your configurations and auto scaling policies. Provisioned instances are not released even when the instances are idle.
By default, the scheduling service provides 300 burstable function instances for each user. If the number of function instances reaches 300, the system performs a scale-out at a speed of up to 300 function instances per minute. If the scale-out speed exceeds the limit, throttling occurs. If you want to increase the quota on burstable function instances, join the DingTalk group (ID: 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 function timeout, insufficient memory, or active termination of function execution on the client, the scheduling service rebuilds the container instance. Function instances may also be rebuilt in advance due to reasons such as load balancing.
Invocation routes
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 amount of 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 comprehensively describes the safeguards at each layer.
Alibaba Cloud standard protection capabilities provided by compute nodes
Compute nodes provide the following standard protection capabilities. For more information, see Alibaba Cloud Security Whitepaper.
Multi-zone disaster recovery (DR): Compute nodes in a region are distributed across multiple zones. Cross-zone DR is supported.
Isolated VPC environment: Compute nodes are deployed in an isolated VPC environment. Users cannot directly access compute nodes.
Vulnerability fixing and security updates: Function Compute fixes the vulnerabilities of compute nodes and updates compute nodes to enhance security. Update processes are transparent to users.
Function isolation at the user level or function level
Virtualization-based security isolation
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 permissions on network access to function instances
A private IP address is configured for a function instance, and users cannot directly access the private IP address. Instances are isolated, and networks are also isolated between the instances by using Open vSwitch, iptables, and routing tables. You can configure the following access modes for a function instance to access external networks:
Internet: Function instances can access only the Internet. This is the default setting.
VPC: Function instances can access only a specific VPC, such as a private IP address of an ApsaraDB RDS instance, Apsara File Storage NAS (NAS) file system, or Elastic Compute Service (ECS) instance.
Internet and VPC: Function instances can access the Internet and a specified VPC.
None: Function instances do not have the permissions to access external networks.
Restricted instance resources
The CPU computing power of a function instance is proportionally allocated based on its memory size. During a cold start of a function instance, a duration of up to 20s can be extended to accelerate the cold start. By default, a function instance is configured with a file system of 512 MB and 1 Gbit/s bandwidth. If you use a performance instance, up to 10 GB file system and 5 Gbit/s 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 troubleshooting.
Vulnerability fixing and security updates
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 runtime environments
Temporary identity credentials
Function Compute applies for temporary identity credentials for your Resource Access Management (RAM) role that executes functions. The credentials are injected into runtimes by using environment variables and passed into function code by inputting parameters. You can use the temporary identity credentials to access other Alibaba Cloud services.
Collection of information about function execution errors
Runtimes collect information about function execution errors and logs for you to check whether errors occur.
Lifecycle hooks and extension capabilities
Runtimes 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 runtimes 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 NAS or Object Storage Service (OSS).
Immutable code and layers
Modifications to the code directory /code and the layer directory /opt take effect only on the function instance. The modification does not rewrite the code or libraries of other instances of the same function.
Vulnerability fixing and security updates
If user compatibility is involved in vulnerability fixing and database updates in runtimes, you are notified in advance by internal message or text message. For custom runtimes and custom container images, you must ensure runtime security. For runtimes compiled by using programming languages such as Java, C#, and Go, you must update dependencies, recompile code, and then upload the code to fix the security vulnerabilities of Function Compute SDK.
Consistent support time for runtimes of multiple versions with a community
If a community no longer supports a runtime version at a point in time, Function Compute stops to support the runtime version accordingly. End of support of runtimes includes several phases, in which you can no longer create functions, modify existing functions, and run existing functions as specified by the deprecation policy. Function Compute does not guarantee that functions running in a deprecated runtime version can always be invoked as expected.