The Shared Responsibility Model

Security and Compliance is a shared responsibility between AWS and the customer. This shared responsibility model can help relieve your operational burden, as AWS operates, manages, and controls the components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operates.

For AWS Lambda, AWS manages the underlying infrastructure and foundation services, the operating system, and the application platform. You are responsible for the security of your code and AWS IAM to the Lambda service and within your function.

The following figure shows the shared responsibility model as it applies to the common and distinct components of AWS Lambda. AWS responsibilities appear below the dotted line in orange, and customer responsibilities appear above the dotted line in blue.

Shared responsibility model for AWS Lambda

Data privacy

Lambda follows strict policies to protect customer privacy and confidentiality. Our customer data handling policies restrict AWS employees from accessing customer content for any reason except those authorized by the customer to support their investigation or to comply with a valid and binding law enforcement request. Encryption at rest, customer managed AWS Key Management Service (AWS KMS) key, encryption in transit, access control, General Data Protection Regulation (GDPR) compliance and human access prevention are some examples of mechanisms employed by Lambda to protect customer content.

Security at rest

Databases and storage systems used by Lambda are encrypted following the AWS best practices guidelines. When applicable, Lambda-managed AWS KMS keys (KMS keys) in the customer account are used to offer better traceability. The option to use customer-managed KMS keys is also provided for sensitive customer content. Refer to Customer keys and AWS keys for information about different key management schemes provided by AWS KMS. For example, function runtime environment variables are secured by encryption using a Lambda-managed KMS key (named aws/lambda) in the customer’s account. You can optionally provide a per-function KMS key to Lambda for encrypting those variables. This customer managed KMS key can be configured using the CreateFunction API during function creation time, or later using UpdateFunctionConfiguration API. For more information, refer to Securing environment variables.

Lambda functions deployed as container images are encrypted using an AWS Lambda-managed KMS key. If a customer-managed KMS key is provided through the CreateFunction or UpdateFunctionConfiguration APIs, that key is used instead of a Lambda-managed KMS key. When the function container images are stored in Amazon Elastic Container Registry (Amazon ECR), customers are responsible for protecting their images in ECR.

AWS X-Ray also encrypts data by default, and can be configured to use a customer-managed key. For details, refer to Encrypt log data in CloudWatch Logs using AWS Key Management Service and Data protection in AWS X-Ray.

Customer content, both ongoing and historical, is deleted by Lambda after account closure based on the AWS data retention and deletion policy. Customers can also delete their data (including backups). To delete the Lambda function, use DeleteFunction. To delete Lambda event source mappings that invoke a function, use DeleteEventSourceMapping.

Security in transit

Lambda uses Transport Layer Security (TLS) 1.2+ for all public APIs. All communications are protected by TLS 1.2+ when you manage Lambda resources through the AWS Management Console, the AWS SDK, or the Lambda API. Internal communications are also secured by TLS unless the payload is already encrypted. Customers can connect their functions to file systems; Lambda uses encryption in transit for all connections. For more information, refer to Configuring file system access for Lambda functions.

Operational security

The Lambda service platform runs on Amazon Elastic Compute Cloud (Amazon EC2) instances based on AWS Nitro System, which provides enhanced security by continuous monitoring and a reduced attack surface by offloading virtualization and security functions to dedicated hardware and software. For customer privacy, human access is disabled on hosts running customers’ Lambda functions. Access to hosts running Lambda services for operational purposes is controlled by multi-layer access controls, logging, monitoring, and audit.

Vulnerability management

Code releases go through security review and penetration testing. All technology stacks are regularly scanned for vulnerabilities. An annual red team security testing and assessment is performed as an additional security validation step.

Trusted code execution

Lambda provides a code signing feature to ensure only trusted code is run in your Lambda function. When you enable code signing for a function, Lambda verifies (during every code deployment) that the code package is signed by a trusted source, the code has not been altered, and the signature has not expired or been revoked. For information about how to use code signing, refer to Configuring code signing for AWS Lambda.