# Security in AWS Lambda Security, governance, and compliance Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: + **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Lambda, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). + **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations. This documentation helps you understand how to apply the shared responsibility model when using Lambda. The following topics show you how to configure Lambda to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Lambda resources. For more information about applying security principles to Lambda applications, see [Security](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops) in Serverless Land. **Topics** + [ # Data protection in AWS Lambda ](security-dataprotection.md) + [ # Using service-linked roles for Lambda ](using-service-linked-roles.md) + [ # Identity and Access Management for AWS Lambda ](security-iam.md) + [ # Create a governance strategy for Lambda functions and layers ](governance-concepts.md) + [ # Compliance validation for AWS Lambda ](security-compliance.md) + [ # Resilience in AWS Lambda ](security-resilience.md) + [ # Infrastructure security in AWS Lambda ](security-infrastructure.md) + [ # Securing workloads with public endpoints ](security-public-endpoints.md) + [ # Using code signing to verify code integrity with Lambda ](configuration-codesigning.md) # Data protection in AWS Lambda Data protection The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Lambda. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*. + Use AWS encryption solutions, along with all default security controls within AWS services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Lambda or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server. **Topics** + [ ## Encryption in transit ](#security-privacy-intransit) + [ # Data encryption at rest for AWS Lambda ](security-encryption-at-rest.md) ## Encryption in transit Lambda API endpoints only support secure connections over HTTPS. When you manage Lambda resources with the AWS Management Console,AWS SDK, or the Lambda API, all communication is encrypted with Transport Layer Security (TLS). For a full list of API endpoints, see [AWS Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) in the AWS General Reference. When you [connect your function to a file system](configuration-filesystem.md), Lambda uses encryption in transit for all connections. For more information, see [Data encryption in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) in the *Amazon Elastic File System User Guide*. When you use [environment variables](configuration-envvars.md), you can enable console encryption helpers to use client-side encryption to protect the environment variables in transit. For more information, see [Securing Lambda environment variables](configuration-envvars-encryption.md). # Data encryption at rest for AWS Lambda Encryption at rest Lambda always provides at-rest encryption for the following resources using an [AWS owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) or an [AWS managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk): + Environment variables + Files that you upload to Lambda, including deployment packages and layer archives + Event source mapping filter criteria objects You can optionally configure Lambda to use a customer managed key to encrypt your [environment variables](configuration-envvars-encryption.md), [.zip deployment packages](encrypt-zip-package.md), and [filter criteria objects](invocation-eventfiltering.md#filter-criteria-encryption). Amazon CloudWatch Logs and AWS X-Ray also encrypt data by default, and can be configured to use a customer managed key. For details, see [ Encrypt log data in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) and [Data protection in AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html). ## Monitoring your encryption keys for Lambda When you use an AWS KMS customer managed key with Lambda, you can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). The following examples are CloudTrail events for `Decrypt`, `DescribeKey`, and `GenerateDataKey` calls made by Lambda to access data encrypted by your customer managed key. ------ #### [ Decrypt ] If you used a AWS KMS customer managed key to encrypt your [filter criteria](invocation-eventfiltering.md#filter-criteria-encryption) object, Lambda sends a `Decrypt` request on your behalf when you try to access it in plaintext (for example, from a `ListEventSourceMappings` call). The following example event records the `Decrypt` operation: ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:45:23Z", "mfaAuthenticated": "false" } }, "invokedBy": "lambda.amazonaws.com" }, "eventTime": "2024-05-30T01:05:46Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "eu-west-1", "sourceIPAddress": "lambda.amazonaws.com", "userAgent": "lambda.amazonaws.com", "requestParameters": { "keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==", "aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source", "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function" }, "encryptionAlgorithm": "SYMMETRIC_DEFAULT" }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ``` ------ #### [ DescribeKey ] If you used a AWS KMS customer managed key to encrypt your [filter criteria](invocation-eventfiltering.md#filter-criteria-encryption) object, Lambda sends a `DescribeKey` request on your behalf when you try to access it (for example, from a `GetEventSourceMapping` call). The following example event records the `DescribeKey` operation: ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:45:23Z", "mfaAuthenticated": "false" } } }, "eventTime": "2024-05-30T01:09:40Z", "eventSource": "kms.amazonaws.com", "eventName": "DescribeKey", "awsRegion": "eu-west-1", "sourceIPAddress": "54.240.197.238", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { "keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_256_GCM_SHA384", "clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com" }, "sessionCredentialFromConsole": "true" } ``` ------ #### [ GenerateDataKey ] When you use a AWS KMS customer managed key to encrypt your [filter criteria](invocation-eventfiltering.md#filter-criteria-encryption) object in a `CreateEventSourceMapping` or `UpdateEventSourceMapping` call, Lambda sends a `GenerateDataKey` request on your behalf to generate a data key to encrypt the filter criteria ([envelope encryption](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). The following example event records the `GenerateDataKey` operation: ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:06:07Z", "mfaAuthenticated": "false" } }, "invokedBy": "lambda.amazonaws.com" }, "eventTime": "2024-05-30T01:04:18Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKey", "awsRegion": "eu-west-1", "sourceIPAddress": "lambda.amazonaws.com", "userAgent": "lambda.amazonaws.com", "requestParameters": { "numberOfBytes": 32, "keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==", "aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source", "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function" }, }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management" } ``` ------ # Using service-linked roles for Lambda Using service-linked roles Lambda uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Lambda. Service-linked roles are predefined by Lambda and include permissions that the service requires to call other AWS services on your behalf. Lambda defines the permissions of its service-linked roles, and only Lambda can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete a service-linked role only after first deleting their related resources. This protects your Lambda resources because you can't inadvertently remove permission to access the resources. For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. ## Service-linked role permissions for Lambda Lambda uses the service-linked role named **AWSServiceRoleForLambda**. The service-linked role trusts the following services to assume the role: + `lambda.amazonaws.com` The role permissions policy named AWSLambdaServiceRolePolicy allows Lambda to complete the following actions on the specified resources: + Action: `ec2:TerminateInstances` on `arn:aws:ec2:*:*:instance/*` with the condition that `ec2:ManagedResourceOperator` equals `scaler.lambda.amazonaws.com` + Action: `ec2:DescribeInstanceStatus` and `ec2:DescribeInstances` on `*` You must configure permissions to allow your users, groups, or roles to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*. For managed policy updates, see [Lambda managed policies](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates). ## Creating a service-linked role for Lambda You don't need to manually create a service-linked role. When you create a Lambda capacity provider in the AWS Management Console, the AWS CLI, or the AWS API, Lambda creates the service-linked role for you. If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a Lambda capacity provider, Lambda creates the service-linked role for you again. You can also use the IAM console to create a service-linked role with the **AWSServiceRoleForLambda** use case. In the AWS CLI or the AWS API, create a service-linked role with the `lambda.amazonaws.com` service name. For more information, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*. If you delete this service-linked role, you can use this same process to create the role again. ## Editing a service-linked role for Lambda Lambda does not allow you to edit the AWSServiceRoleForLambda service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ## Deleting a service-linked role for Lambda If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for your service-linked role before you can manually delete it. **Note** If the Lambda service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again. **To delete Lambda resources used by the AWSServiceRoleForLambda** 1. Remove all Lambda capacity providers from your account. You can do this using the Lambda console, CLI, or API. 1. Verify that no Lambda capacity providers remain in your account before attempting to delete the service-linked role. **To manually delete the service-linked role using IAM** Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForLambda service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Supported Regions for Lambda service-linked roles Lambda does not support using service-linked roles in every Region where the service is available. AWSServiceRoleForLambda is supported in the following Regions. | Region name | Region identity | Support in Lambda | | --- | --- | --- | | US East (N. Virginia) | us-east-1 | Yes | | US East (Ohio) | us-east-2 | Yes | | US West (N. California) | us-west-1 | Yes | | US West (Oregon) | us-west-2 | Yes | | Africa (Cape Town) | af-south-1 | No | | Asia Pacific (Hong Kong) | ap-east-1 | Yes | | Asia Pacific (Jakarta) | ap-southeast-3 | Yes | | Asia Pacific (Bangkok) | ap-southeast-7 | Yes | | Asia Pacific (Mumbai) | ap-south-1 | Yes | | Asia Pacific (Osaka) | ap-northeast-3 | No | | Asia Pacific (Seoul) | ap-northeast-2 | No | | Asia Pacific (Singapore) | ap-southeast-1 | Yes | | Asia Pacific (Sydney) | ap-southeast-2 | Yes | | Asia Pacific (Tokyo) | ap-northeast-1 | Yes | | Canada (Central) | ca-central-1 | No | | Europe (Frankfurt) | eu-central-1 | Yes | | Europe (Ireland) | eu-west-1 | Yes | | Europe (London) | eu-west-2 | Yes | | Europe (Milan) | eu-south-1 | No | | Europe (Paris) | eu-west-3 | No | | Europe (Stockholm) | eu-north-1 | No | | Middle East (Bahrain) | me-south-1 | No | | Middle East (UAE) | me-central-1 | No | | South America (São Paulo) | sa-east-1 | No | | AWS GovCloud (US-East) | us-gov-east-1 | No | | AWS GovCloud (US-West) | us-gov-west-1 | No | # Identity and Access Management for AWS Lambda Identity and Access Management AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Lambda resources. IAM is an AWS service that you can use with no additional charge. **Topics** + [ ## Audience ](#security_iam_audience) + [ ## Authenticating with identities ](#security_iam_authentication) + [ ## Managing access using policies ](#security_iam_access-manage) + [ # How AWS Lambda works with IAM ](security_iam_service-with-iam.md) + [ # Identity-based policy examples for AWS Lambda ](security_iam_id-based-policy-examples.md) + [ # AWS managed policies for AWS Lambda ](security-iam-awsmanpol.md) + [ # Troubleshooting AWS Lambda identity and access ](security_iam_troubleshoot.md) ## Audience How you use AWS Identity and Access Management (IAM) differs based on your role: + **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting AWS Lambda identity and access](security_iam_troubleshoot.md)) + **Service administrator** - determine user access and submit permission requests (see [How AWS Lambda works with IAM](security_iam_service-with-iam.md)) + **IAM administrator** - write policies to manage access (see [Identity-based policy examples for AWS Lambda](security_iam_id-based-policy-examples.md)) ## Authenticating with identities Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role. You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*. ### AWS account root user When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. ### Federated identity As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials. A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials. For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*. ### IAM users and groups An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*. An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*. ### IAM roles An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*. IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. ## Managing access using policies You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*. Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**. By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation. ### Identity-based policies Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*. ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy. ### Other policy types AWS supports additional policy types that can set the maximum permissions granted by more common policy types: + **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*. + **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*. + **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*. + **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*. ### Multiple policy types When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. # How AWS Lambda works with IAM Before you use IAM to manage access to Lambda, learn what IAM features are available to use with Lambda. | IAM feature | Lambda support | | --- | --- | | [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes | | [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | Yes | | [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes | | [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes | | [Policy condition keys (service-specific)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes | | [ACLs](#security_iam_service-with-iam-acls) | No | | [ABAC (tags in policies)](#security_iam_service-with-iam-tags) | Partial | | [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes | | [Forward access sessions (FAS)](#security_iam_service-with-iam-principal-permissions) | No | | [Service roles](#security_iam_service-with-iam-roles-service) | Yes | | [Service-linked roles](#security_iam_service-with-iam-roles-service-linked) | Partial | To get a high-level view of how Lambda and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Identity-based policies for Lambda Identity-based policies **Supports identity-based policies:** Yes Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*. ### Identity-based policy examples for Lambda To view examples of Lambda identity-based policies, see [Identity-based policy examples for AWS Lambda](security_iam_id-based-policy-examples.md). ## Resource-based policies within Lambda Resource-based policies **Supports resource-based policies:** Yes Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. You can attach a resource-based policy to a Lambda function or layer. This policy defines which principals can perform actions on the function or layer. To learn how to attach a resource-based policy to a function or layer, see [Viewing resource-based IAM policies in Lambda](access-control-resource-based.md). ## Policy actions for Lambda Policy actions **Supports policy actions:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation. To see a list of Lambda actions, see [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) in the *Service Authorization Reference*. Policy actions in Lambda use the following prefix before the action: ``` lambda ``` To specify multiple actions in a single statement, separate them with commas. ``` "Action": [ "lambda:action1", "lambda:action2" ] ``` To view examples of Lambda identity-based policies, see [Identity-based policy examples for AWS Lambda](security_iam_id-based-policy-examples.md). ## Policy resources for Lambda Policy resources **Supports policy resources:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources. ``` "Resource": "*" ``` To see a list of Lambda resource types and their ARNs, see [Resource types defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions). To view examples of Lambda identity-based policies, see [Identity-based policy examples for AWS Lambda](security_iam_id-based-policy-examples.md). ## Policy condition keys for Lambda Policy condition keys **Supports service-specific policy condition keys:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*. To see a list of Lambda condition keys, see [Condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions). To view examples of Lambda identity-based policies, see [Identity-based policy examples for AWS Lambda](security_iam_id-based-policy-examples.md). ## ACLs in Lambda ACLs **Supports ACLs:** No Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. ## ABAC with Lambda ABAC **Supports ABAC (tags in policies):** Partial Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**. For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tagging Lambda resources, see [Using attribute-based access control in Lambda](attribute-based-access-control.md). ## Using temporary credentials with Lambda Temporary credentials **Supports temporary credentials:** Yes Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Forward access sessions for Lambda Forward access sessions **Supports forward access sessions (FAS):** No Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Service roles for Lambda Service roles **Supports service roles:** Yes A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. In Lambda, a service role is known as an [execution role](lambda-intro-execution-role.md). **Warning** Changing the permissions for an execution role might break Lambda functionality. ## Service-linked roles for Lambda Service-linked roles **Supports service-linked roles:** Partial A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. Lambda doesn't have service-linked roles, but Lambda@Edge does. For more information, see [Service-Linked Roles for Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) in the *Amazon CloudFront Developer Guide*. For details about creating or managing service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service. # Identity-based policy examples for AWS Lambda Identity-based policy examples By default, users and roles don't have permission to create or modify Lambda resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*. For details about actions and resource types defined by Lambda, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) in the *Service Authorization Reference*. **Topics** + [ ## Policy best practices ](#security_iam_service-with-iam-policy-best-practices) + [ ## Using the Lambda console ](#security_iam_id-based-policy-examples-console) + [ ## Allow users to view their own permissions ](#security_iam_id-based-policy-examples-view-own-permissions) ## Policy best practices Identity-based policies determine whether someone can create, access, or delete Lambda resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations: + **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. + **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*. + **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*. + **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*. + **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*. For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*. ## Using the Lambda console Using the console To access the AWS Lambda console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Lambda resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy. You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform. For an example policy that grants minimal access for function development, see [Granting users access to a Lambda function](permissions-user-function.md). In addition to Lambda APIs, the Lambda console uses other services to display trigger configuration and let you add new triggers. If your users use Lambda with other services, they need access to those services as well. For details on configuring other services with Lambda, see [Invoking Lambda with events from other AWS services](lambda-services.md). ## Allow users to view their own permissions This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` # AWS managed policies for AWS Lambda AWS managed policies An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. **Topics** + [ ## AWS managed policy: AWSLambda\$1FullAccess ](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess) + [ ## AWS managed policy: AWSLambda\$1ReadOnlyAccess ](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess) + [ ## AWS managed policy: AWSLambdaBasicExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole) + [ ## AWS managed policy: AWSLambdaBasicDurableExecutionRolePolicy ](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy) + [ ## AWS managed policy: AWSLambdaDynamoDBExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole) + [ ## AWS managed policy: AWSLambdaENIManagementAccess ](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess) + [ ## AWS managed policy: AWSLambdaInvocation-DynamoDB ](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB) + [ ## AWS managed policy: AWSLambdaKinesisExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole) + [ ## AWS managed policy: AWSLambdaMSKExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole) + [ ## AWS managed policy: AWSLambdaRole ](#lambda-security-iam-awsmanpol-AWSLambdaRole) + [ ## AWS managed policy: AWSLambdaSQSQueueExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole) + [ ## AWS managed policy: AWSLambdaVPCAccessExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole) + [ ## AWS managed policy: AWSLambdaManagedEC2ResourceOperator ](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator) + [ ## AWS managed policy: AWSLambdaServiceRolePolicy ](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy) + [ ## Lambda updates to AWS managed policies ](#lambda-security-iam-awsmanpol-updates) ## AWS managed policy: AWSLambda\$1FullAccess AWSLambda\$1FullAccess This policy grants full access to Lambda actions. It also grants permissions to other AWS services that are used to develop and maintain Lambda resources. You can attach the `AWSLambda_FullAccess` policy to your users, groups, and roles. **Permissions details** This policy includes the following permissions: + `lambda` – Allows principals full access to Lambda. + `cloudformation` – Allows principals to describe AWS CloudFormation stacks and list the resources in those stacks. + `cloudwatch` – Allows principals to list Amazon CloudWatch metrics and get metric data. + `ec2` – Allows principals to describe security groups, subnets, and VPCs. + `iam` – Allows principals to get policies, policy versions, roles, role policies, attached role policies, and the list of roles. This policy also allows principals to pass roles to Lambda. The `PassRole` permission is used when you assign an execution role to a function. The `CreateServiceLinkedRole` permission is used when creating a service-linked role. + `kms` – Allows principals to list aliases and describe key for volume encryption. + `logs` – Allows principals to describe log streams, get log events, filter log events, and to start and stop Live Tail sessions. + `states` – Allows principals to describe and list AWS Step Functions state machines. + `tag` – Allows principals to get resources based on their tags. + `xray` – Allows principals to get AWS X-Ray trace summaries and retrieve a list of traces specified by ID. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambda\$1ReadOnlyAccess AWSLambda\$1ReadOnlyAccess This policy grants read-only access to Lambda resources and to other AWS services that are used to develop and maintain Lambda resources. You can attach the `AWSLambda_ReadOnlyAccess` policy to your users, groups, and roles. **Permissions details** This policy includes the following permissions: + `lambda` – Allows principals to get and list all resources. + `cloudformation` – Allows principals to describe and list AWS CloudFormation stacks and list the resources in those stacks. + `cloudwatch` – Allows principals to list Amazon CloudWatch metrics and get metric data. + `ec2` – Allows principals to describe security groups, subnets, and VPCs. + `iam` – Allows principals to get policies, policy versions, roles, role policies, attached role policies, and the list of roles. + `kms` – Allows principals to list aliases. + `logs` – Allows principals to describe log streams, get log events, filter log events, and to start and stop Live Tail sessions. + `states` – Allows principals to describe and list AWS Step Functions state machines. + `tag` – Allows principals to get resources based on their tags. + `xray` – Allows principals to get AWS X-Ray trace summaries and retrieve a list of traces specified by ID. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaBasicExecutionRole AWSLambdaBasicExecutionRole This policy grants permissions to upload logs to CloudWatch Logs. You can attach the `AWSLambdaBasicExecutionRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaBasicDurableExecutionRolePolicy AWSLambdaBasicDurableExecutionRolePolicy This policy provides write permissions to CloudWatch Logs and read/write permissions to durable execution APIs used by Lambda durable functions. This policy provides the essential permissions required for Lambda durable functions, which use durable execution APIs to persist progress and maintain state across function invocations. You can attach the `AWSLambdaBasicDurableExecutionRolePolicy` policy to your users, groups, and roles. **Permissions details** This policy includes the following permissions: + `logs` – Allows principals to create log groups and log streams, and write log events to CloudWatch Logs. + `lambda` – Allows principals to checkpoint durable execution state and retrieve durable execution state for Lambda durable functions. To view more details about the policy, including the latest version of the JSON policy document, see [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaDynamoDBExecutionRole AWSLambdaDynamoDBExecutionRole This policy grants permissions to read records from an Amazon DynamoDB stream and write to CloudWatch Logs. You can attach the `AWSLambdaDynamoDBExecutionRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaENIManagementAccess AWSLambdaENIManagementAccess This policy grants permissions to create, describe, and delete elastic network interfaces used by a VPC-enabled Lambda function. You can attach the `AWSLambdaENIManagementAccess` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaInvocation-DynamoDB AWSLambdaInvocation-DynamoDB This policy grants read access to Amazon DynamoDB Streams. You can attach the `AWSLambdaInvocation-DynamoDB` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaKinesisExecutionRole AWSLambdaKinesisExecutionRole This policy grants permissions to read events from an Amazon Kinesis data stream and write to CloudWatch Logs. You can attach the `AWSLambdaKinesisExecutionRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaMSKExecutionRole AWSLambdaMSKExecutionRole This policy grants permissions to read and access records from an Amazon Managed Streaming for Apache Kafka cluster, manage elastic network interfaces, and write to CloudWatch Logs. You can attach the `AWSLambdaMSKExecutionRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaRole AWSLambdaRole This policy grants permissions to invoke Lambda functions. You can attach the `AWSLambdaRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaSQSQueueExecutionRole AWSLambdaSQSQueueExecutionRole This policy grants permissions to read and delete messages from an Amazon Simple Queue Service queue, and grants write permissions to CloudWatch Logs. You can attach the `AWSLambdaSQSQueueExecutionRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaVPCAccessExecutionRole AWSLambdaVPCAccessExecutionRole This policy grants permissions to manage elastic network interfaces within an Amazon Virtual Private Cloud and write to CloudWatch Logs. You can attach the `AWSLambdaVPCAccessExecutionRole` policy to your users, groups, and roles. For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaManagedEC2ResourceOperator AWSLambdaManagedEC2ResourceOperator This policy enables automated Amazon Elastic Compute Cloud instance management for Lambda capacity providers. It grants permissions to the Lambda scaler service to perform instance lifecycle operations on your behalf. You can attach the `AWSLambdaManagedEC2ResourceOperator` policy to your users, groups, and roles. **Permissions details** This policy includes the following permissions: + `ec2:RunInstances` – Allows Lambda to launch new Amazon EC2 instances with the condition that ec2:ManagedResourceOperator equals scaler.lambda.amazonaws.com and restricts AMI usage to Amazon-owned images only. + `ec2:DescribeInstances` and `ec2:DescribeInstanceStatus` – Allows Lambda to monitor instance status and retrieve instance information. + `ec2:CreateTags` – Allows Lambda to tag Amazon EC2 resources for management and identification purposes. + `ec2:DescribeAvailabilityZones` – Allows Lambda to view available zones for instance placement decisions. + `ec2:DescribeCapacityReservations` – Allows Lambda to check capacity reservations for optimal instance placement. + `ec2:DescribeInstanceTypes` and `ec2:DescribeInstanceTypeOfferings` – Allows Lambda to review available instance types and their offerings. + `ec2:DescribeSubnets` – Allows Lambda to examine subnet configurations for network planning. + `ec2:DescribeSecurityGroups` – Allows Lambda to retrieve security group information for network interface configuration. + `ec2:CreateNetworkInterface` – Allows Lambda to create network interfaces and manage subnet and security group associations. + `ec2:AttachNetworkInterface` – Allows Lambda to attach network interfaces to Amazon EC2 instances with the condition that `ec2:ManagedResourceOperator` equals [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/). For more information about this policy, including the JSON policy document and policy versions, see [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSLambdaServiceRolePolicy AWSLambdaServiceRolePolicy This policy is attached to the service-linked role named AWSServiceRoleForLambda to allow Lambda to terminate instances managed as part of Lambda capacity providers. **Permissions details** This policy includes the following permissions: + `ec2:TerminateInstances` – Allows Lambda to terminate EC2 instances with the condition that ec2:ManagedResourceOperator equals scaler.lambda.amazonaws.com. + `ec2:DescribeInstanceStatus` and `ec2:DescribeInstances` – Allows Lambda to describe EC2 instances. For more information about this policy, see [Using service-linked roles for Lambda](using-service-linked-roles.md). ## Lambda updates to AWS managed policies Policy updates | Change | Description | Date | | --- | --- | --- | | [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) – New policy | Lambda added a new managed policy to enable automated Amazon EC2 instance management for Lambda capacity providers, allowing the scaler service to perform instance lifecycle operations. | November 30, 2025 | | [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) – New policy | Lambda added a new managed policy for the service-linked role to allow Lambda to terminate instances managed as part of Lambda capacity providers. | November 30, 2025 | | [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – Change | Lambda updated the `AWSLambda_FullAccess` policy to allow the `kms:DescribeKey` and `iam:CreateServiceLinkedRole` actions. | November 30, 2025 | | [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) – New managed policy | Lambda released a new managed policy `AWSLambdaBasicDurableExecutionRolePolicy` that provides write permissions to CloudWatch Logs and read/write permissions to durable execution APIs used by Lambda durable functions. | December 1, 2025 | | [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) and [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – Change | Lambda updated the `AWSLambda_ReadOnlyAccess` and `AWSLambda_FullAccess` policies to allow the `logs:StartLiveTail` and `logs:StopLiveTail` actions. | March 17, 2025 | | [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) – Change | Lambda updated the `AWSLambdaVPCAccessExecutionRole` policy to allow the action `ec2:DescribeSubnets`. | January 5, 2024 | | [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) – Change | Lambda updated the `AWSLambda_ReadOnlyAccess` policy to allow principals to list CloudFormation stacks. | July 27, 2023 | | AWS Lambda started tracking changes | AWS Lambda started tracking changes for its AWS managed policies. | July 27, 2023 | # Troubleshooting AWS Lambda identity and access Troubleshooting Use the following information to help you diagnose and fix common issues that you might encounter when working with Lambda and IAM. **Topics** + [ ## I am not authorized to perform an action in Lambda ](#security_iam_troubleshoot-no-permissions) + [ ## I am not authorized to perform iam:PassRole ](#security_iam_troubleshoot-passrole) + [ ## I want to allow people outside of my AWS account to access my Lambda resources ](#security_iam_troubleshoot-cross-account-access) ## I am not authorized to perform an action in Lambda If you receive an error that you're not authorized to perform an action, your policies must be updated to allow you to perform the action. The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a fictional `my-example-widget` resource but doesn't have the fictional `lambda:GetWidget` permissions. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget ``` In this case, the policy for the `mateojackson` user must be updated to allow access to the `my-example-widget` resource by using the `lambda:GetWidget` action. If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials. ## I am not authorized to perform iam:PassRole If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Lambda. Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service. The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Lambda. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action. If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials. ## I want to allow people outside of my AWS account to access my Lambda resources You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources. To learn more, consult the following: + To learn whether Lambda supports these features, see [How AWS Lambda works with IAM](security_iam_service-with-iam.md). + To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*. + To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*. + To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*. + To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. # Create a governance strategy for Lambda functions and layers Governance To build and deploy serverless, cloud-native applications, you must allow for agility and speed to market with appropriate governance and guardrails. You set business-level priorities, maybe emphasizing agility as the top priority, or alternatively emphasizing risk aversion via governance, guardrails, and controls. Realistically, you won't have an "either/or" strategy but an "and" strategy that balances both agility and guardrails in your software development lifecycle. No matter where these requirements fall in your company's lifecycle, governance capabilities are likely to become an implementation requirement in your processes and toolchains. Here are a few examples of governance controls that an organization might implement for Lambda: + Lambda functions must not be publicly accessible. + Lambda functions must be attached to a VPC. + Lambda functions should not use deprecated runtimes. + Lambda functions must be tagged with a set of required tags. + Lambda layers must not be accessible outside of the organization. + Lambda functions with an attached security group must have matching tags between the function and security group. + Lambda functions with an attached layer must use an approved version + Lambda environment variables must be encrypted at rest with a customer managed key. The following diagram is an example of an in-depth governance strategy that implements controls and policy throughout the software development and deployment process: ![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-concepts.png) The following topics explain how to implement controls for developing and deploying Lambda functions in your organization, both for the startup and the enterprise. Your organization might already have tools in place. The following topics take a modular approach to these controls, so that you can pick and choose the components you actually need. **Topics** + [ # Proactive controls for Lambda with AWS CloudFormation Guard ](governance-cloudformation-guard.md) + [ # Implement preventative controls for Lambda with AWS Config ](governance-config.md) + [ # Detect non-compliant Lambda deployments and configurations with AWS Config ](governance-config-detection.md) + [ # Lambda code signing with AWS Signer ](governance-code-signing.md) + [ # Automate security assessments for Lambda with Amazon Inspector ](governance-code-scanning.md) + [ # Implement observability for Lambda security and compliance ](governance-observability.md) # Proactive controls for Lambda with AWS CloudFormation Guard Proactive controls with Guard [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) is an open-source, general-purpose, policy-as-code evaluation tool. This can be used for preventative governance and compliance by validating Infrastructure as Code (IaC) templates and service compositions against policy rules. These rules can be customized based on your team or organizational requirements. For Lambda functions, the Guard rules can be used to control resource creation and configuration updates by defining the required property settings needed while creating or updating a Lambda function. Compliance administrators define the list of controls and governance policies that are required for deploying and updating Lambda functions. Platform administrators implement the controls in CI/CD pipelines, as pre-commit validation webhooks with code repositories, and provide developers with command line tools for validating templates and code on local workstations. Developers author code, validate templates with command line tools, and then commit code to repositories, which are then automatically validated via the CI/CD pipelines prior to deployment into an AWS environment. Guard allows you to [write your rules](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) and implement your controls with a domain-specific language as follows. ![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-cloudformation-guard.png) For example, suppose you want to ensure that developers choose only the latest runtimes. You could specify two different policies, one to identify [runtimes](lambda-runtimes.md) that are already deprecated and another to identify runtimes that are to be deprecated soon. To do this, you might write the following `etc/rules.guard` file: ``` let lambda_functions = Resources.*[ Type == "AWS::Lambda::Function" ] rule lambda_already_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <> } } } } rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <> } } } } ``` Now suppose you write the following `iac/lambda.yaml` CloudFormation template that defines a Lambda function: ``` Fn: Type: AWS::Lambda::Function Properties: Runtime: python3.7 CodeUri: src Handler: fn.handler Role: !GetAtt FnRole.Arn Layers: - arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35 ``` After [installing](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) the Guard utility, validate your template: ``` cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml ``` The output looks like this: ``` lambda.yaml Status = FAIL FAILED rules rules.guard/lambda_soon_to_be_deprecated_runtime --- Evaluating data lambda.yaml against rules rules.guard Number of non-compliant resources 1 Resource = Fn { Type = AWS::Lambda::Function Rule = lambda_soon_to_be_deprecated_runtime { ALL { Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] { ComparisonError { Message = Lambda function is using a runtime that is targeted for deprecation. Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])] } PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15] Operator = NOT IN Value = "python3.7" ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]] Code: 86. Fn: 87. Type: AWS::Lambda::Function 88. Properties: 89. Runtime: python3.7 90. CodeUri: src 91. Handler: fn.handler } } } } ``` Guard allows your developers to see from their local developer workstations that they need to update the template to use a runtime that is allowed by the organization. This happens prior to committing to a code repository and subsequently failing checks within a CI/CD pipeline. As a result, your developers get this feedback on how to develop compliant templates and shift their time to writing code that delivers business value. This control can be applied on the local developer workstation, in a pre-commit validation webhook, and/or in the CI/CD pipeline prior to deployment. ## Caveats If you're using AWS Serverless Application Model (AWS SAM) templates to define Lambda functions, be aware that you need to update the Guard rule to search for the `AWS::Serverless::Function` resource type as follows. ``` let lambda_functions = Resources.*[ Type == "AWS::Serverless::Function" ] ``` Guard also expects the properties to be included within the resource definition. Meanwhile, AWS SAM templates allow for properties to be specified in a separate [Globals](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) section. Properties that are defined in the Globals section are not validated with your Guard rules. As outlined in the Guard troubleshooting [documentation](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html), be aware that Guard doesn't support short-form intrinsics like `!GetAtt` or `!Sub` and instead requires using the expanded forms: `Fn::GetAtt` and `Fn::Sub`. (The [earlier example](#guard-iac-yaml) doesn't evaluate the Role property, so the short-form intrinsic was used for simplicity.) # Implement preventative controls for Lambda with AWS Config Proactive controls with AWS Config It is essential to ensure compliance in your serverless applications as early in the development process as possible. In this topic, we cover how to implement preventative controls using [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). This allows you to implement compliance checks earlier in the development process and enables you to implement the same controls in your CI/CD pipelines. This also standardizes your controls in a centrally managed repository of rules so that you can apply your controls consistently across your AWS accounts. For example, suppose your compliance administrators defined a requirement to ensure that all Lambda functions include AWS X-Ray tracing. With AWS Config's proactive mode, you can run compliance checks on your Lambda function resources before deployment, reducing the risk of deploying improperly configured Lambda functions and saving developers time by giving them faster feedback on infrastructure as code templates. The following is a visualization of the flow for preventative controls with AWS Config: ![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-1.png) Consider a requirement that all Lambda functions must have tracing enabled. In response, the platform team identifies the need for a specific AWS Config rule to run proactively across all accounts. This rule flags any Lambda function that lacks a configured X-Ray tracing configuration as a non-compliant resource. The team develops a rule, packages it in a [conformance pack](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html), and deploys the conformance pack across all AWS accounts to ensure that all accounts in the organization uniformly apply these controls. You can write the rule in AWS CloudFormation Guard 2.x.x syntax, which takes the following form: ``` rule name when condition { assertion } ``` The following is a sample Guard rule that checks to ensure Lambda functions has tracing enabled: ``` rule lambda_tracing_check { when configuration.tracingConfig exists { configuration.tracingConfig.mode == "Active" } } ``` The platform team takes further action by mandating that every AWS CloudFormation deployment invokes a pre-create/update [hook](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html). They assume full responsibility for developing this hook and configuring the pipeline, strengthening the centralized control of compliance rules and sustaining their consistent application across all deployments. To develop, package, and register a hook, see [Developing AWS CloudFormation Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html) in the CloudFormation Command Line Interface (CFN-CLI) documentation. You can use the [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) to create the hook project: ``` cfn init ``` This command asks you for some basic information about your hook project and creates a project with following files in it: ``` README.md .json rpdk.log src/handler.py template.yml hook-role.yaml ``` As a hook developer, you need to add the desired target resource type in the `.json` configuration file. In the configuration below, a hook is configured to execute before any Lambda function is created using CloudFormation. You can add similar handlers for `preUpdate` and `preDelete` actions as well. ``` "handlers": { "preCreate": { "targetNames": [ "AWS::Lambda::Function" ], "permissions": [] } } ``` You also need to ensure that the CloudFormation hook has appropriate permissions to call the AWS Config APIs. You can do that by updating the role definition file named `hook-role.yaml`. The role definition file has the following trust policy by default, which allows CloudFormation to assume the role. ``` AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - hooks.cloudformation.amazonaws.com - resources.cloudformation.amazonaws.com ``` To allow this hook to call config APIs, you must add following permissions to the Policy statement. Then you submit the hook project using the `cfn submit` command, where CloudFormation creates a role for you with the required permissions. ``` Policies: - PolicyName: HookTypePolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - "config:Describe*" - "config:Get*" - "config:List*" - "config:SelectResourceConfig" Resource: "* ``` Next, you need to write a Lambda function in a `src/handler.py` file. Within this file, you find methods named `preCreate`, `preUpdate`, and `preDelete` already created when you initiated the project. You aim to write a common, reusable function that calls the AWS Config `StartResourceEvaluation` API in proactive mode using the AWS SDK for Python (Boto3). This API call takes resource properties as input and evaluates the resource against the rule definition. ``` def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent: LOG.info("Fetching proactive data") config_client = boto3.client('config') resource_specs = { 'ResourceId': 'MyFunction', 'ResourceType': resource_type, 'ResourceConfiguration': json.dumps(function_properties), 'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA' } LOG.info("Resource Specifications:", resource_specs) eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60) ResourceEvaluationId = eval_response.ResourceEvaluationId compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId) LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType) if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType: return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant) else: return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.") ``` Now you can call the common function from the handler for the pre-create hook. Here's an example of the handler: ``` @hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION) def pre_create_handler( session: Optional[SessionProxy], request: HookHandlerRequest, callback_context: MutableMapping[str, Any], type_configuration: TypeConfigurationModel ) -> ProgressEvent: LOG.info("Starting execution of the hook") target_name = request.hookContext.targetName LOG.info("Target Name:", target_name) if "AWS::Lambda::Function" == target_name: return validate_lambda_tracing_config(target_name, request.hookContext.targetModel.get("resourceProperties") ) else: raise exceptions.InvalidRequest(f"Unknown target type: {target_name}") ``` After this step you can register the hook and configure it to listen to all AWS Lambda function creation events. A developer prepares the infrastructure as code (IaC) template for a serverless microservice using Lambda. This preparation includes adherence to internal standards, followed by locally testing and committing the template to the repository. Here's an example IaC template: ``` MyLambdaFunction: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: MyLambdaFunction Code: ZipFile: | import json def handler(event, context): return { 'statusCode': 200, 'body': json.dumps('Hello World!') } Runtime: python3.14 TracingConfig: Mode: PassThrough MemorySize: 256 Timeout: 10 ``` As part of the CI/CD process, when the CloudFormation template is deployed, the CloudFormation service invokes the pre-create/update hook right before provisioning `AWS::Lambda::Function` resource type. The hook utilizes AWS Config rules running in proactive mode to verify that the Lambda function configuration includes the mandated tracing configuration. The response from the hook determines the next step. If compliant, the hook signals success, and CloudFormation proceeds to provision the resources. If not, the CloudFormation stack deployment fails, the pipeline comes to an immediate halt, and the system records the details for subsequent review. Compliance notifications are sent to the relevant stakeholders. You can find the hook success/fail information in the CloudFormation console: ![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-2.png) If you have logs enabled for your CloudFormation hook, you can capture the hook evaluation result. Here is a sample log for a hook with a failed status, indicating that the Lambda function does not have X-Ray enabled: ![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-3.png) If the developer chooses to change the IaC to update `TracingConfig Mode` value to `Active` and redeploy, the hook executes successfully and the stack proceeds with creating the Lambda resource. ![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-4.png) In this way, you can implement preventative controls with AWS Config in proactive mode when developing and deploying serverless resources in your AWS accounts. By integrating AWS Config rules into the CI/CD pipeline, you can identify and optionally block non-compliant resource deployments, such as Lambda functions that lack an active tracing configuration. This ensures that only resources that comply with the latest governance policies are deployed into your AWS environments. # Detect non-compliant Lambda deployments and configurations with AWS Config Detective controls with AWS Config In addition to [proactive evaluation](governance-config.md), AWS Config can also reactively detect resource deployments and configurations that do not comply with your governance policies. This is important because governance policies evolve as your organization learns and implements new best practices. Consider a scenario where you set a brand new policy when deploying or updating Lambda functions: All Lambda functions must always use a specific, approved Lambda layer version. You can configure AWS Config to monitor new or updated functions for layer configurations. If AWS Config detects a function that is not using an approved layer version, it flags the function as a non-compliant resource. You can optionally configure AWS Config to automatically remediate the resource by specifying a remediation action using an AWS Systems Manager automation document. For example, you could write an automation document in Python using the AWS SDK for Python (Boto3), which updates the non-compliant function to point to the approved layer version. Thus, AWS Config serves as both a detective and corrective control, automating compliance management. Let's break down this process into three important implementation phases: ![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-detective-1.png) ## Phase 1: Identify access resources Start by activating AWS Config across your accounts and configuring it to record AWS Lambda functions. This allows AWS Config to observe when Lambda functions are created or updated. You can then configure [custom policy rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) to check for specific policy violations, which use AWS CloudFormation Guard syntax. Guard rules take the following general form: ``` rule name when condition { assertion } ``` Below is a sample rule that checks to ensure that a layer is not set to an old layer version: ``` rule desiredlayer when configuration.layers !empty { some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn } ``` Let's understand the rule syntax and structure: + **Rule name:** The name of the rule in the provided example is `desiredlayer`. + **Condition:** This clause specifies the condition under which the rule should be checked. In the provided example, the condition is `configuration.layers !empty`. This means the resource should be evaluated only when the `layers` property in the configuration isn't empty. + **Assertion:** After the `when` clause, an assertion determines what the rule checks. The assertion `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` checks if any of the Lambda layer ARNs do not match the `OldLayerArn` value. If they do not match, the assertion is true and the rule passes; otherwise, it fails. `CONFIG_RULE_PARAMETERS` is a special set of parameters that is configured with the AWS Config rule. In this case, `OldLayerArn` is a parameter inside `CONFIG_RULE_PARAMETERS`. This allows users to provide a specific ARN value that they consider old or deprecated, and then the rule checks if any Lambda functions are using this old ARN. ## Phase 2: Visualize and design AWS Config gathers configuration data and stores that data in Amazon Simple Storage Service (Amazon S3) buckets. You can use [Amazon Athena](https://aws.amazon.com/athena/) to query this data directly from your S3 buckets. With Athena, you can aggregate this data at the organizational level, generating a holistic view of your resource configurations across all your accounts. To set up aggregation of resource configuration data, see [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) on the AWS Cloud Operations and Management blog. The following is a sample Athena query to identify all Lambda functions using a particular layer ARN: ``` WITH unnested AS ( SELECT item.awsaccountid AS account_id, item.awsregion AS region, item.configuration AS lambda_configuration, item.resourceid AS resourceid, item.resourcename AS resourcename, item.configuration AS configuration, json_parse(item.configuration) AS lambda_json FROM default.aws_config_configuration_snapshot, UNNEST(configurationitems) as t(item) WHERE "dt" = 'latest' AND item.resourcetype = 'AWS::Lambda::Function' ) SELECT DISTINCT region as Region, resourcename as FunctionName, json_extract_scalar(lambda_json, '$.memorySize') AS memory_size, json_extract_scalar(lambda_json, '$.timeout') AS timeout, json_extract_scalar(lambda_json, '$.version') AS version FROM unnested WHERE lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%' ``` Here are results from the query: ![\[Query results in Athena console.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-detective-2.png) With the AWS Config data aggregated across the organization, you can then create a dashboard using [Amazon Quick](https://aws.amazon.com/quicksight/). By importing your Athena results into Quick, you can visualize how well your Lambda functions adhere to the layer version rule. This dashboard can highlight compliant and non-compliant resources, which helps you to determine your enforcement policy, as outlined in the [next section](#governance-config-detective-implement). The following image is an example dashboard that reports on the distribution of layer versions applied to functions within the organization. ![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-config-detective-3.png) ## Phase 3: Implement and enforce You can now optionally pair your layer version rule that you created in [phase 1](#governance-config-detective-identify) with a remediation action via a Systems Manager automation document, which you author as a Python script written with AWS SDK for Python (Boto3). The script calls the [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API action for each Lambda function, updating the function configuration with the new layer ARN. Alternatively, you could have the script submit a pull request to the code repository to update the layer ARN. This way future code deployments are also updated with the correct layer ARN. # Lambda code signing with AWS Signer Code signing [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) is a fully managed code-signing service that allows you to validate your code against a digital signature to confirm that code is unaltered and from a trusted publisher. AWS Signer can be used in conjunction with AWS Lambda to verify that functions and layers are unaltered prior to deployment into your AWS environments. This protects your organization from malicious actors who might have gained credentials to create new or update existing functions. To set up code signing for your Lambda functions, start by creating an S3 bucket with versioning enabled. After that, create a signing profile with AWS Signer, specify Lambda as the platform and then specify a period of days in which the signing profile is valid. Example: ``` Signer: Type: AWS::Signer::SigningProfile Properties: PlatformId: AWSLambda-SHA384-ECDSA SignatureValidityPeriod: Type: DAYS Value: !Ref pValidDays ``` Then use the signing profile and create a signing configuration with Lambda. You have to specify what to do when the signing configuration sees an artifact that does not match a digital signature that it expected: warn (but allow the deployment) or enforce (and block the deployment). The example below is configured to enforce and block deployments. ``` SigningConfig: Type: AWS::Lambda::CodeSigningConfig Properties: AllowedPublishers: SigningProfileVersionArns: - !GetAtt Signer.ProfileVersionArn CodeSigningPolicies: UntrustedArtifactOnDeployment: Enforce ``` You now have AWS Signer configured with Lambda to block untrusted deployments. Let's assume you've finished coding a feature request and are now ready to deploy the function. The first step is to zip the code up with the appropriate dependencies and then sign the artifact using the signing profile that you created. You can do this by uploading the zip artifact to the S3 bucket and then starting a signing job. ``` aws signer start-signing-job \ --source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \ --destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \ --profile-name your-signer-id ``` You get an output as follows, where the `jobId` is the object that is created in the destination bucket and prefix and `jobOwner` is the 12-digit AWS account ID where the job was run. ``` { "jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388", "jobOwner": "111122223333" } ``` And now you can deploy your function using the signed S3 object and the code signing configuration that you created. ``` Fn: Type: AWS::Serverless::Function Properties: CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip Handler: fn.handler Role: !GetAtt FnRole.Arn CodeSigningConfigArn: !Ref pSigningConfigArn ``` You can alternatively test a function deployment with the original unsigned source zip artifact. The deployment should fail with the following message: ``` Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned. ``` If you are building and deploying your functions using the AWS Serverless Application Model (AWS SAM), the package command handles uploading the zip artifact to S3 and also starts the signing job and gets the signed artifact. You can do this with the following command and parameters: ``` sam package -t your-template.yaml \ --output-template-file your-output.yaml \ --s3-bucket your-versioned-bucket \ --s3-prefix your-prefix \ --signing-profiles your-signer-id ``` AWS Signer helps you verify that zip artifacts that are deployed into your accounts are trusted for deployment. You can include the process above in your CI/CD pipelines and require that all functions have a code signing configuration attached using the techniques outlined in previous topics. By using code signing with your Lambda function deployments, you prevent malicious actors who might have gotten credentials to create or update functions from injecting malicious code in your functions. # Automate security assessments for Lambda with Amazon Inspector Code scanning [Amazon Inspector](https://aws.amazon.com/inspector/) is a vulnerability management service that continually scans workloads for known software vulnerabilities and unintended network exposure. Amazon Inspector creates a finding that describes the vulnerability, identifies the affected resource, rates the severity of the vulnerability, and provides remediation guidance. Amazon Inspector support provides continuous, automated security vulnerability assessments for Lambda functions and layers. Amazon Inspector provides two scan types for Lambda: + **Lambda standard scanning (default):** Scans application dependencies within a Lambda function and its layers for [package vulnerabilities](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package). + **Lambda code scanning**: Scans the custom application code in your functions and layers for [code vulnerabilities](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code). You can either activate Lambda standard scanning or activate Lambda standard scanning together with Lambda code scanning. To enable Amazon Inspector, navigate to the [Amazon Inspector console](https://console.aws.amazon.com/inspector/), expand the **Settings** section, and choose **Account Management**. On the **Accounts** tab, choose **Activate**, and then select one of the scan options. You can enable Amazon Inspector for multiple accounts and delegate permissions to manage Amazon Inspector for the organization to specific accounts while setting up Amazon Inspector. While enabling, you need to grant Amazon Inspector permissions by creating the role: `AWSServiceRoleForAmazonInspector2`. The Amazon Inspector console allows you to create this role using a one-click option. For Lambda standard scanning, Amazon Inspector initiates vulnerability scans of Lambda functions in the following situations: + As soon as Amazon Inspector discovers an existing Lambda function. + When you deploy a new Lambda function. + When you deploy an update to the application code or dependencies of an existing Lambda function or its layers. + Whenever Amazon Inspector adds a new common vulnerabilities and exposures (CVE) item to its database, and that CVE is relevant to your function. For Lambda code scanning, Amazon Inspector evaluates your Lambda function application code using automated reasoning and machine learning that analyzes your application code for overall security compliance. If Amazon Inspector detects a vulnerability in your Lambda function application code, Amazon Inspector produces a detailed **Code Vulnerability** finding. For a list of possible detections, see the [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/). To view the findings, go to the [Amazon Inspector console](https://console.aws.amazon.com/inspector/). On the **Findings** menu, choose **By Lambda function** to display the security scan results that were performed on Lambda functions. To exclude a Lambda function from standard scanning, tag the function with the following key-value pair: + `Key:InspectorExclusion` + `Value:LambdaStandardScanning` To exclude a Lambda function from code scans, tag the function with the following key-value pair: + `Key:InspectorCodeExclusion` + `Value:``LambdaCodeScanning` For example, as shown in following image, Amazon Inspector automatically detects vulnerabilities and categorizes the findings of type **Code Vulnerability**, which indicates that the vulnerability is in the code of the function, and not in one of the code-dependent libraries. You can check these details for a specific function or multiple functions at once. ![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-code-scanning-1.png) You can dive further into each of these findings and learn how to remediate the issue. ![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-code-scanning-2.png) While working with your Lambda functions, ensure that you comply with the naming conventions for your Lambda functions. For more information, see [Working with Lambda environment variables](configuration-envvars.md). You are responsible for the remediation suggestions that you accept. Always review remediation suggestions before accepting them. You might need to make edits to remediation suggestions to ensure that your code does what you intended. # Implement observability for Lambda security and compliance Observability AWS Config is a useful tool to find and fix non-compliant AWS Serverless resources. Every change you make to your serverless resources is recorded in AWS Config. Additionally, AWS Config allows you to store configuration snapshot data on S3. You can use Amazon Athena and Amazon Quick to make dashboards and see AWS Config data. In [Detect non-compliant Lambda deployments and configurations with AWS Config](governance-config-detection.md), we discussed how we can visualize a certain configuration like Lambda layers. This topic expands on these concepts. ## Visibility into Lambda configurations Configuration visibility You can use queries to pull important configurations like AWS account ID, Region, AWS X-Ray tracing configuration, VPC configuration, memory size, runtime, and tags. Here is a sample query you can use to pull this information from Athena: ``` WITH unnested AS ( SELECT item.awsaccountid AS account_id, item.awsregion AS region, item.configuration AS lambda_configuration, item.resourceid AS resourceid, item.resourcename AS resourcename, item.configuration AS configuration, json_parse(item.configuration) AS lambda_json FROM default.aws_config_configuration_snapshot, UNNEST(configurationitems) as t(item) WHERE "dt" = 'latest' AND item.resourcetype = 'AWS::Lambda::Function' ) SELECT DISTINCT account_id, tags, region as Region, resourcename as FunctionName, json_extract_scalar(lambda_json, '$.memorySize') AS memory_size, json_extract_scalar(lambda_json, '$.timeout') AS timeout, json_extract_scalar(lambda_json, '$.runtime') AS version json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig FROM unnested ``` You can use the query to build an Quick dashboard and visualize the data. To aggregate AWS resource configuration data, create tables in Athena, and build Quick dashboards on the data from Athena, see [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) on the AWS Cloud Operations and Management blog. Notably, this query also retrieves tag information for the functions. This allows for deeper insights into your workloads and environments, especially if you employ custom tags. ![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-observability-1.png) For more information on actions that you can take, see the [Addressing the observability findings](#governance-observability-addressing) section later in this topic. ## Visibility into Lambda compliance Compliance visibility With the data generated by AWS Config, you can create organization-level dashboards to monitor compliance. This allows for consistent tracking and monitoring of: + Compliance packs by compliance score + Rules by non-compliant resources + Compliance status ![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-observability-2.png) Check each rule to identify non-compliant resources for that rule. For example, if your organization mandates that all Lambda functions must be associated with a VPC and if you have deployed an AWS Config rule to identify compliance, you can select the `lambda-inside-vpc` rule in the list above. ![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-observability-3.png) For more information on actions that you can take, see the [Addressing the observability findings](#governance-observability-addressing) section below. ## Visibility into Lambda function boundaries using Security Hub CSPM Boundaries ![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-observability-4.png) To ensure that AWS services including Lambda are used securely, AWS introduced the Foundational Security Best Practices v1.0.0. This set of best practices provides clear guidelines for securing resources and data in the AWS environment, emphasizing the importance of maintaining a strong security posture. The AWS Security Hub CSPM complements this by offering a unified security and compliance center. It aggregates, organizes, and prioritizes security findings from multiple AWS services like Amazon Inspector, AWS Identity and Access Management Access Analyzer, and Amazon GuardDuty. If you have Security Hub CSPM, Amazon Inspector, IAM Access Analyzer, and GuardDuty enabled within your AWS organization, Security Hub CSPM automatically aggregates findings from these services. For instance, let's consider Amazon Inspector. Using Security Hub CSPM, you can efficiently identify code and package vulnerabilities in Lambda functions. In the Security Hub CSPM console, navigate to the bottom section labeled **Latest findings from AWS integrations**. Here, you can view and analyze findings sourced from various integrated AWS services. ![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-observability-5.png) To see details, choose the **See findings** link in the second column. This displays a list of findings filtered by product, such as Amazon Inspector. To limit your search to Lambda functions, set `ResourceType` to `AwsLambdaFunction`. This displays findings from Amazon Inspector related to Lambda functions. ![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/lambda/latest/dg/images/governance-observability-6.png) For GuardDuty, you can identify suspicious network traffic patterns. Such anomalies might suggest the existence of potentially malicious code within your Lambda function. With IAM Access Analyzer, you can check policies, especially those with condition statements that grant function access to external entities. Moreover, IAM Access Analyzer evaluates permissions set when using the [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) operation in the Lambda API alongside an `EventSourceToken`. ## Addressing the observability findings Address findings Given the wide-ranging configurations possible for Lambda functions and their distinct requirements, a standardized automation solution for remediation might not suit every situation. Additionally, changes are implemented differently across various environments. If you encounter any configuration that seems non-compliant, consider the following guidelines: 1. **Tagging strategy** We recommend implementing a comprehensive tagging strategy. Each Lambda function should be tagged with key information such as: + **Owner:** The person or team responsible for the function. + **Environment:** Production, staging, development, or sandbox. + **Application:** The broader context to which this function belongs, if applicable. 1. **Owner outreach** Instead of automating the breaking changes (like VPC configuration adjustment), proactively contact the owners of non-compliant functions (identified by the owner tag) providing them sufficient time to either: + Adjust non-compliant configurations on Lambda functions. + Provide an explanation and request an exception, or refine the compliance standards. 1. **Maintain a configuration management database (CMDB)** While tags can provide immediate context, maintaining a centralized CMDB can provide deeper insights. It can hold more granular information about each Lambda function, its dependencies, and other critical metadata. A CMDB is an invaluable resource for auditing, compliance checks, and identifying function owners. As the landscape of serverless infrastructure continually evolves, it's essential to adopt a proactive stance towards monitoring. With tools like AWS Config, Security Hub CSPM, and Amazon Inspector, potential anomalies or non-compliant configurations can be swiftly identified. However, tools alone cannot ensure total compliance or optimal configurations. It's crucial to pair these tools with well-documented processes and best practices. + **Feedback loop:** Once remediation steps are undertaken, ensure there's a feedback loop. This means periodically revisiting non-compliant resources to confirm if they've been updated or are still running with the same issues. + **Documentation:** Always document the observations, actions taken, and any exceptions granted. Proper documentation not only helps during audits but also aids in enhancing the process for better compliance and security in the future. + **Training and awareness:** Ensure that all stakeholders, especially Lambda function owners, are regularly trained and made aware of best practices, organizational policies, and compliance mandates. Regular workshops, webinars, or training sessions can go a long way in ensuring everyone is on the same page when it comes to security and compliance. In conclusion, while tools and technologies provide robust capabilities to detect and flag potential issues, the human element—understanding, communication, training, and documentation— remains pivotal. Together, they form a potent combination to ensure that your Lambda functions and broader infrastructure remain compliant, secure, and optimized for your business needs. # Compliance validation for AWS Lambda Compliance validation Third-party auditors assess the security and compliance of AWS Lambda as part of multiple AWS compliance programs. These include SOC, PCI, FedRAMP, HIPAA, and others. For a list of AWS services in scope of specific compliance programs, see [AWS services in scope by compliance program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS compliance programs](https://aws.amazon.com/compliance/programs/). You can download third-party audit reports using AWS Artifact. For more information, see [Downloading reports in AWS artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Your compliance responsibility when using Lambda is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. You can implement governance controls to ensure that your company's Lambda functions meet your compliance requirements. For more information, see [Create a governance strategy for Lambda functions and layers](governance-concepts.md). # Resilience in AWS Lambda Resilience The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and Availability Zones, see [AWS global infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). In addition to the AWS global infrastructure, Lambda offers several features to help support your data resiliency and backup needs. + **Versioning** – You can use versioning in Lambda to save your function's code and configuration as you develop it. Together with aliases, you can use versioning to perform blue/green and rolling deployments. For details, see [Manage Lambda function versions](configuration-versions.md). + **Scaling** – When your function receives a request while it's processing a previous request, Lambda launches another instance of your function to handle the increased load. Lambda automatically scales to handle 1,000 concurrent executions per Region, a [quota](gettingstarted-limits.md) that can be increased if needed. For details, see [Understanding Lambda function scaling](lambda-concurrency.md). + **High availability** – Lambda runs your function in multiple Availability Zones to ensure that it is available to process events in case of a service interruption in a single zone. If you configure your function to connect to a virtual private cloud (VPC) in your account, specify subnets in multiple Availability Zones to ensure high availability. For details, see [Giving Lambda functions access to resources in an Amazon VPC](configuration-vpc.md). + **Reserved concurrency** – To make sure that your function can always scale to handle additional requests, you can reserve concurrency for it. Setting reserved concurrency for a function ensures that it can scale to, but not exceed, a specified number of concurrent invocations. This ensures that you don't lose requests due to other functions consuming all of the available concurrency. For details, see [Configuring reserved concurrency for a function](configuration-concurrency.md). + **Retries** – For asynchronous invocations and a subset of invocations triggered by other services, Lambda automatically retries on error with delays between retries. Other clients and AWS services that invoke functions synchronously are responsible for performing retries. For details, see [Understanding retry behavior in Lambda](invocation-retries.md). + **Dead-letter queue** – For asynchronous invocations, you can configure Lambda to send requests to a dead-letter queue if all retries fail. A dead-letter queue is an Amazon SNS topic or Amazon SQS queue that receives events for troubleshooting or reprocessing. For details, see [Adding a dead-letter queue](invocation-async-retain-records.md#invocation-dlq). # Infrastructure security in AWS Lambda Infrastructure security As a managed service, AWS Lambda is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*. You use AWS published API calls to access Lambda through the network. Clients must support the following: + Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3. + Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes. # Securing workloads with public endpoints For workloads that are accessible publicly, AWS provides a number of features and services that can help mitigate certain risks. This section covers authentication and authorization of application users and protecting API endpoints. ## Authentication and authorization Authentication relates to identity and authorization refers to actions. Use authentication to control who can invoke a Lambda function, and then use authorization to control what they can do. For many applications, IAM is sufficient for managing both control mechanisms. For applications with external users, such as web or mobile applications, it is common to use [JSON Web Tokens](https://jwt.io/introduction/) (JWTs) to manage authentication and authorization. Unlike traditional, server-based password management, JWTs are passed from the client on every request. They are a cryptographically secure way to verify identity and claims using data passed from the client. For Lambda-based applications, this allows you to secure every call to each API endpoint without relying on a central server for authentication. You can [ implement JWTs with Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), a user directory service that can handle registration, authentication, account recovery, and other common account management operations. [Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) provides libraries to simplify integrating this service into your frontend application. You can also consider third-party partner services like [Auth0](https://auth0.com/). Given the critical security role of an identity provider service, it’s important to use professional tooling to safeguard your application. It’s not recommended that you write your own services to handle authentication or authorization. Any vulnerabilities in custom libraries may have significant implications for the security of your workload and its data. ## Protecting API endpoints For serverless applications, the preferred way to serve a backend application publicly is to use Amazon API Gateway. This can help you protect an API from malicious users or spikes in traffic. API Gateway offers two endpoint types for serverless developers: [REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) and [HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). Both support [ authorization using AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), IAM, or Amazon Cognito. When using IAM or Amazon Cognito, incoming requests are evaluated and if they are missing a required token or contain invalid authentication, the request is rejected. You are not charged for these requests and they do not count towards any throttling quotas. Unauthenticated API routes may be accessed by anyone on the public internet so it’s recommended that you limit the use of unauthenticated APIs. If you must use unauthenticated APIs, it’s important to protect these against common risks, such as [ denial-of-service](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS) attacks. [ Applying AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) to these APIs can help protect your application from SQL injection and cross-site scripting (XSS) attacks. API Gateway also implements [ throttling](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) at the AWS account-level and per-client level when API keys are used. In many cases, the functionality provided by unauthenticated API can be achieved with an alternative approach. For example, a web application may provide a list of customer retail stores from a DynamoDB table to users who are not logged in. This request may originate from a frontend web application or from any other source that calls the URL endpoint. This diagram compares three solutions: ![\[security ops figure 5\]](http://docs.aws.amazon.com/lambda/latest/dg/images/security-ops-figure-5.png) 1. This unauthenticated API can be called by anyone on the internet. In a denial of service attack, it’s possible to exhaust API throttling limits, Lambda concurrency, or DynamoDB provisioned read capacity on an underlying table. 1. A CloudFront distribution in front of the API endpoint with an appropriate [ time-to-live](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) configuration would absorb most of the traffic in a DoS attack, without changing the underlying solution for fetching the data. 1. Alternatively, for static data that rarely changes, the CloudFront distribution could serve the data' from an Amazon S3 bucket. # Using code signing to verify code integrity with Lambda Code signing Code signing helps ensure that only trusted code is deployed to your Lambda functions. Using AWS Signer, you can create digitally signed code packages for your functions. When you [add a code signing configuration to a function](configuration-codesigning-create.md), Lambda verifies that all new code deployments are signed by a trusted source. Because code signing validation checks run at deployment time, there is no impact on function execution. **Important** Code signing configurations only prevent new deployments of unsigned code. If you add a code signing configuration to an existing function that has unsigned code, that code keeps running until you deploy a new code package. When you enable code signing for a function, any [layers](chapter-layers.md) that you add to the function must also be signed by an allowed signing profile. There is no additional charge for using AWS Signer or code signing for AWS Lambda. ## Signature validation Lambda performs the following validation checks when you deploy a signed code package to your function: 1. **Integrity**: Validates that the code package has not been modified since it was signed. Lambda compares the hash of the package with the hash from the signature. 1. **Expiry**: Validates that the signature of the code package has not expired. 1. **Mismatch**: Validates that the code package is signed with an allowed signing profile 1. **Revocation**: Validates that the signature of the code package has not been revoked. When you create a code signing configuration, you can use the [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) parameter to specify how Lambda should respond if the expiry, mismatch, or revocation checks fail. You can choose one of these actions: + `Warn`: This is the default setting. Lambda allows the deployment of the code package, but issues a warning. Lambda issues a new Amazon CloudWatch metric (`SignatureValidationErrors`) and also stores the warning in the CloudTrail log. + `Enforce` Lambda issues a warning (the same as for the `Warn` action) and blocks the deployment of the code package. **Topics** + [ ## Signature validation ](#config-codesigning-valid) + [ # Creating code signing configurations for Lambda ](configuration-codesigning-create.md) + [ # Configuring IAM policies for Lambda code signing configurations ](config-codesigning-policies.md) + [ # Using tags on code signing configurations ](tags-csc.md) # Creating code signing configurations for Lambda Create configuration To enable code signing for a function, you create a *code signing configuration* and attach it to the function. A code signing configuration defines a list of allowed signing profiles and the policy action to take if any of the validation checks fail. **Note** Functions defined as container images do not support code signing. **Topics** + [ ## Configuration prerequisites ](#config-codesigning-prereqs) + [ ## Creating code signing configurations ](#config-codesigning-config-console) + [ ## Enabling code signing for a function ](#config-codesigning-function-console) ## Configuration prerequisites Before you can configure code signing for a Lambda function, use AWS Signer to do the following: + Create one or more [signing profiles](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html). + Use a signing profile to [create a signed code package for your function](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html). ## Creating code signing configurations A code signing configuration defines a list of allowed signing profiles and the signature validation policy. **To create a code signing configuration (console)** 1. Open the [Code signing configurations page](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) of the Lambda console. 1. Choose **Create configuration**. 1. For **Description**, enter a descriptive name for the configuration. 1. Under **Signing profiles**, add up to 20 signing profiles to the configuration. 1. For **Signing profile version ARN**, choose a profile version's Amazon Resource Name (ARN), or enter the ARN. 1. To add an additional signing profile, choose **Add signing profiles**. 1. Under **Signature validation policy**, choose **Warn** or **Enforce**. 1. Choose **Create configuration**. ## Enabling code signing for a function To enable code signing for a function, add a code signing configuration to the function. **Important** Code signing configurations only prevent new deployments of unsigned code. If you add a code signing configuration to an existing function that has unsigned code, that code keeps running until you deploy a new code package. **To associate a code signing configuration with a function (console)** 1. Open the [Functions page](https://console.aws.amazon.com/lambda/home#/functions) of the Lambda console. 1. Choose the function for which you want to enable code signing. 1. Open the **Configuration** tab. 1. Scroll down and choose **Code signing**. 1. Choose **Edit**. 1. In **Edit code signing**, choose a code signing configuration for this function. 1. Choose **Save**. # Configuring IAM policies for Lambda code signing configurations Permissions To grant permission for a user to access Lambda code signing API operations, attach one or more policy statements to the user policy. For more information about user policies, see [Identity-based IAM policies for Lambda](access-control-identity-based.md). The following example policy statement grants permission to create, update, and retrieve code signing configurations. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:CreateCodeSigningConfig", "lambda:UpdateCodeSigningConfig", "lambda:GetCodeSigningConfig" ], "Resource": "*" } ] } ``` ------ Administrators can use the `CodeSigningConfigArn` condition key to specify the code signing configurations that developers must use to create or update your functions. The following example policy statement grants permission to create a function. The policy statement includes a `lambda:CodeSigningConfigArn` condition to specify the allowed code signing configuration. Lambda blocks `CreateFunction` API requests if the [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) parameter is missing or does not match the value in the condition. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowReferencingCodeSigningConfig", "Effect": "Allow", "Action": [ "lambda:CreateFunction" ], "Resource": "*", "Condition": { "StringEquals": { "lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6" } } } ] } ``` ------ # Using tags on code signing configurations Code signing configuration tags You can tag code signing configurations to organize and manage your resources. Tags are free-form key-value pairs associated with your resources that are supported across AWS services. For more information about use cases for tags, see [Common tagging strategies](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) in the *Tagging AWS Resources and Tag Editor Guide*. You can use the AWS Lambda API to view and update tags. You can also view and update tags while managing a specific code signing configuration in the Lambda console. **Topics** + [ ## Permissions required for working with tags ](#csc-tags-required-permissions) + [ ## Using tags with the Lambda console ](#tags-csc-console) + [ ## Using tags with the AWS CLI ](#tags-csc-cli) ## Permissions required for working with tags To allow an AWS Identity and Access Management (IAM) identity (user, group, or role) to read or set tags on a resource, grant it the corresponding permissions: + **lambda:ListTags**–When a resource has tags, grant this permission to anyone who needs to call `ListTags` on it. For tagged functions, this permission is also necessary for `GetFunction`. + **lambda:TagResource**–Grant this permission to anyone who needs to call `TagResource` or perform a tag on create. Optionally, consider granting the **lambda:UntagResource** permission as well to allow `UntagResource` calls to the resource. For more information, see [Identity-based IAM policies for Lambda](access-control-identity-based.md). ## Using tags with the Lambda console Using tags with the console You can use the Lambda console to create code signing configurations that have tags, add tags to existing code signing configurations, and filter code signing configurations by tag. **To add a tag when you create a code signing configuration** 1. Open [Code signing configurations](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) in the Lambda console. 1. From the header of the content pane, Choose **Create configuration**. 1. In the section at the top of the content pane, set up your code signing configuration. For more information about configuring code signing configurations, see [Using code signing to verify code integrity with Lambda](configuration-codesigning.md). 1. In the **Tags** section, choose **Add new tag**. 1. In the **Key** field, enter your tag key. For information about tagging restrictions, see [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) in the *Tagging AWS Resources and Tag Editor Guide*. 1. Choose **Create configuration**. **To add a tag to an existing code signing configuration** 1. Open [Code signing configurations](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) in the Lambda console. 1. Choose the name of your code signing configuration. 1. In the tabs below the **Detail** pane, choose **Tags**. 1. Choose **Manage tags**. 1. Choose **Add new tag**. 1. In the **Key** field, enter your tag key. For information about tagging restrictions, see [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) in the *Tagging AWS Resources and Tag Editor Guide*. 1. Choose **Save**. **To filter code signing configurations by tag** 1. Open [Code signing configurations](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) in the Lambda console. 1. Choose the search box. 1. From the dropdown list, select your tag from below the **Tags** subheading. 1. Select **Use: "tag-name"** to see all code signing configurations tagged with this key, or choose an **Operator** to further filter by value. 1. Select your tag value to filter by a combination of tag key and value. The search box also supports searching for tag keys. Enter the name of a key to find it in the list. ## Using tags with the AWS CLI You can add and remove tags on existing Lambda resources, including code signing configurations, with the Lambda API. You can also add tags when creating an code signing configuration, which allows you to keep a resource tagged through its entire lifecycle. ### Updating tags with the Lambda tag APIs You can add and remove tags for supported Lambda resources through the [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) and [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API operations. You can call these operations using the AWS CLI. To add tags to an existing resource, use the `tag-resource` command. This example adds two tags, one with the key *Department* and one with the key *CostCenter*. ``` aws lambda tag-resource \ --resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \ --tags Department=Marketing,CostCenter=1234ABCD ``` To remove tags, use the `untag-resource` command. This example removes the tag with the key *Department*. ``` aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \ --tag-keys Department ``` ### Adding tags when creating a code signing configuration To create a new Lambda code signing configuration with tags, use the [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html) API operation. Specify the `Tags` parameter. You can call this operation with the `create-code-signing-config` AWS CLI command and the `--tags` option. For more information about the CLI command, see [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html) in the *AWS CLI Command Reference*. Before using the `Tags` parameter with `CreateCodeSigningConfig`, ensure that your role has permission to tag resources alongside the usual permissions needed for this operation. For more information about permissions for tagging, see [Permissions required for working with tags](#csc-tags-required-permissions). ### Viewing tags with the Lambda tag APIs To view the tags that are applied to a specific Lambda resource, use the `ListTags` API operation. For more information, see [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html). You can call this operation with the `list-tags` AWS CLI command by providing an ARN (Amazon Resource Name). ``` aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier ``` ### Filtering resources by tag You can use the AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API operation to filter your resources by tags. The `GetResources` operation receives up to 10 filters, with each filter containing a tag key and up to 10 tag values. You provide `GetResources` with a `ResourceType` to filter by specific resource types. You can call this operation using the `get-resources` AWS CLI command. For examples of using `get-resources`, see [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) in the *AWS CLI Command Reference*.