Lambda Functions Should Not Have Administrative Permissions
Your Amazon Lambda functions should not have administrative permissions in order to promote the Principle of Least Privilege.
Your Amazon Lambda functions should not have administrative permissions in order to promote the Principle of Least Privilege.
Any publicly accessible AWS Lambda functions should be identified and their access policy should be updated in order to protect against unauthorized users that are sending requests to invoke these functions.
You should configure a dead letter queue (DLQ) on AWS Lambda to give you more control over message handling for all asynchronous invocations.
Your AWS Lambda Functions should have default timeout set in order to achieve greater relaibility and availability.
It is reccommended that you should use aliases for your AWS Lambda Functions.
AWS Lambda Functions should not have too many versions. This may led to security lapses and performance degradation.
You should always use the latest version of the execution environment for your Amazon Lambda functions in order to adhere to AWS best practices and receive the newest software features, get the latest security patches and bug fixes, and benefit from better performance and reliability.
You should not use the deprecated versions of the execution environment for your Amazon Lambda functions in order to adhere to AWS best practices.
Tracing should be enabled for your AWS Lambda functions in order to gain visibility into the functions execution and performance.
Amazon Lambda functions should not share the same AWS IAM execution role in order to promote the Principle of Least Privilege (POLP) by providing each individual function the minimal amount of access required to perform its tasks.
CloudTrail captures API calls for AWS Lambda as events. The calls captured include calls from the AWS Lambda console and code calls to the AWS Lambda API operations.
You can tag Lambda functions to organize them by owner, project or department. Tags are freeform key-value pairs that are supported across AWS services for use in filtering resources and adding detail to billing reports.
Your Amazon Lambda functions should be configured to allow access only to trusted AWS accounts in order to protect against unauthorized cross account access.
Your Amazon Lambda functions should have access to VPC-only resources such as AWS Redshift data warehouses, AWS ElastiCache clusters, AWS RDS database instances, and service endpoints that are only accessible from within a particular Virtual Private Cloud (VPC).
If you are not yet convinced to sign up with Cloudanix, that's not a problem. We recommend you use a comprehensive checklist which your team can use to perform a manual assessment of your workload.