Skip to main content

The CDK Construct Library for AWS::Lambda

Project description

AWS Lambda Construct Library

---

cfn-resources: Stable

cdk-constructs: Stable


This construct library allows you to define AWS Lambda Functions.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
)

Handler Code

The lambda.Code class includes static convenience methods for various types of runtime code.

  • lambda.Code.fromBucket(bucket, key[, objectVersion]) - specify an S3 object that contains the archive of your runtime code.
  • lambda.Code.fromInline(code) - inline the handle code as a string. This is limited to supported runtimes and the code cannot exceed 4KiB.
  • lambda.Code.fromAsset(path) - specify a directory or a .zip file in the local filesystem which will be zipped and uploaded to S3 before deployment. See also bundling asset code.
  • lambda.Code.fromDockerBuild(path, options) - use the result of a Docker build as code. The runtime code is expected to be located at /asset in the image and will be zipped and uploaded to S3 as an asset.

The following example shows how to define a Python function and deploy the code from the local directory my-lambda-handler to it:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.Function(self, "MyLambda",
    code=lambda_.Code.from_asset(path.join(__dirname, "my-lambda-handler")),
    handler="index.main",
    runtime=lambda_.Runtime.PYTHON_3_6
)

When deploying a stack that contains this code, the directory will be zip archived and then uploaded to an S3 bucket, then the exact location of the S3 objects will be passed when the stack is deployed.

During synthesis, the CDK expects to find a directory on disk at the asset directory specified. Note that we are referencing the asset directory relatively to our CDK project directory. This is especially important when we want to share this construct through a library. Different programming languages will have different techniques for bundling resources into libraries.

Docker Images

Lambda functions allow specifying their handlers within docker images. The docker image can be an image from ECR or a local asset that the CDK will package and load into ECR.

The following DockerImageFunction construct uses a local folder with a Dockerfile as the asset that will be used as the function handler.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.DockerImageFunction(self, "AssetFunction",
    code=lambda_.DockerImageCode.from_image_asset(path.join(__dirname, "docker-handler"))
)

You can also specify an image that already exists in ECR as the function handler.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_ecr as ecr

repo = ecr.Repository(self, "Repository")

lambda_.DockerImageFunction(self, "ECRFunction",
    code=lambda_.DockerImageCode.from_ecr(repo)
)

The props for these docker image resources allow overriding the image's CMD, ENTRYPOINT, and WORKDIR configurations. See their docs for more information.

Execution Role

Lambda functions assume an IAM role during execution. In CDK by default, Lambda functions will use an autogenerated Role if one is not provided.

The autogenerated Role is automatically given permissions to execute the Lambda function. To reference the autogenerated Role:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
)

role = fn.role

You can also provide your own IAM role. Provided IAM roles will not automatically be given permissions to execute the Lambda function. To provide a role and grant it appropriate permissions:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
my_role = iam.Role(self, "My Role",
    assumed_by=iam.ServicePrincipal("sns.amazonaws.com")
)

fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    role=my_role
)

my_role.add_managed_policy(iam.ManagedPolicy.from_aws_managed_policy_name("service-role/AWSLambdaBasicExecutionRole"))
my_role.add_managed_policy(iam.ManagedPolicy.from_aws_managed_policy_name("service-role/AWSLambdaVPCAccessExecutionRole"))

Resource-based Policies

AWS Lambda supports resource-based policies for controlling access to Lambda functions and layers on a per-resource basis. In particular, this allows you to give permission to AWS services and other AWS accounts to modify and invoke your functions. You can also restrict permissions given to AWS services by providing a source account or ARN (representing the account and identifier of the resource that accesses the function or layer).

# Example automatically generated. See https://github.com/aws/jsii/issues/826
# fn is of type Function

principal = iam.ServicePrincipal("my-service")

fn.grant_invoke(principal)

# Equivalent to:
fn.add_permission("my-service Invocation",
    principal=principal
)

For more information, see Resource-based policies in the AWS Lambda Developer Guide.

Providing an unowned principal (such as account principals, generic ARN principals, service principals, and principals in other accounts) to a call to fn.grantInvoke will result in a resource-based policy being created. If the principal in question has conditions limiting the source account or ARN of the operation (see above), these conditions will be automatically added to the resource policy.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
# fn is of type Function

service_principal = iam.ServicePrincipal("my-service")
source_arn = "arn:aws:s3:::my-bucket"
source_account = "111122223333"
service_principal_with_conditions = service_principal.with_conditions({
    "ArnLike": {
        "aws:_source_arn": source_arn
    },
    "StringEquals": {
        "aws:_source_account": source_account
    }
})

fn.grant_invoke(service_principal_with_conditions)

# Equivalent to:
fn.add_permission("my-service Invocation",
    principal=service_principal,
    source_arn=source_arn,
    source_account=source_account
)

Versions

You can use versions to manage the deployment of your AWS Lambda functions. For example, you can publish a new version of a function for beta testing without affecting users of the stable production version.

The function version includes the following information:

  • The function code and all associated dependencies.
  • The Lambda runtime that executes the function.
  • All of the function settings, including the environment variables.
  • A unique Amazon Resource Name (ARN) to identify this version of the function.

You could create a version to your lambda function using the Version construct.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
# fn is of type Function

version = lambda_.Version(self, "MyVersion",
    lambda_=fn
)

The major caveat to know here is that a function version must always point to a specific 'version' of the function. When the function is modified, the version will continue to point to the 'then version' of the function.

One way to ensure that the lambda.Version always points to the latest version of your lambda.Function is to set an environment variable which changes at least as often as your code does. This makes sure the function always has the latest code. For instance -

# Example automatically generated. See https://github.com/aws/jsii/issues/826
code_version = "stringOrMethodToGetCodeVersion"
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    environment={
        "CodeVersionString": code_version
    }
)

The fn.latestVersion property returns a lambda.IVersion which represents the $LATEST pseudo-version.

However, most AWS services require a specific AWS Lambda version, and won't allow you to use $LATEST. Therefore, you would normally want to use lambda.currentVersion.

The fn.currentVersion property can be used to obtain a lambda.Version resource that represents the AWS Lambda function defined in your application. Any change to your function's code or configuration will result in the creation of a new version resource. You can specify options for this version through the currentVersionOptions property.

NOTE: The currentVersion property is only supported when your AWS Lambda function uses either lambda.Code.fromAsset or lambda.Code.fromInline. Other types of code providers (such as lambda.Code.fromBucket) require that you define a lambda.Version resource directly since the CDK is unable to determine if their contents had changed.

currentVersion: Updated hashing logic

To produce a new lambda version each time the lambda function is modified, the currentVersion property under the hood, computes a new logical id based on the properties of the function. This informs CloudFormation that a new AWS::Lambda::Version resource should be created pointing to the updated Lambda function.

However, a bug was introduced in this calculation that caused the logical id to change when it was not required (ex: when the Function's Tags property, or when the DependsOn clause was modified). This caused the deployment to fail since the Lambda service does not allow creating duplicate versions.

This has been fixed in the AWS CDK but existing users need to opt-in via a feature flag. Users who have run cdk init since this fix will be opted in, by default.

Existing users will need to enable the feature flag @aws-cdk/aws-lambda:recognizeVersionProps. Since CloudFormation does not allow duplicate versions, they will also need to make some modification to their function so that a new version can be created. Any trivial change such as a whitespace change in the code or a no-op environment variable will suffice.

When the new logic is in effect, you may rarely come across the following error: The following properties are not recognized as version properties. This will occur, typically when property overrides are used, when a new property introduced in AWS::Lambda::Function is used that CDK is still unaware of.

To overcome this error, use the API Function.classifyVersionProperty() to record whether a new version should be generated when this property is changed. This can be typically determined by checking whether the property can be modified using the UpdateFunctionConfiguration API or not.

Aliases

You can define one or more aliases for your AWS Lambda function. A Lambda alias is like a pointer to a specific Lambda function version. Users can access the function version using the alias ARN.

The version.addAlias() method can be used to define an AWS Lambda alias that points to a specific version.

The following example defines an alias named live which will always point to a version that represents the function as defined in your CDK app. When you change your lambda code or configuration, a new resource will be created. You can specify options for the current version through the currentVersionOptions property.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    current_version_options=VersionOptions(
        removal_policy=RemovalPolicy.RETAIN,  # retain old versions
        retry_attempts=1
    ),
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
)

fn.current_version.add_alias("live")

Layers

The lambda.LayerVersion class can be used to define Lambda layers and manage granting permissions to other AWS accounts or organizations.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
layer = lambda_.LayerVersion(stack, "MyLayer",
    code=lambda_.Code.from_asset(path.join(__dirname, "layer-code")),
    compatible_runtimes=[lambda_.Runtime.NODEJS_10_X],
    license="Apache-2.0",
    description="A layer to test the L2 construct"
)

# To grant usage by other AWS accounts
layer.add_permission("remote-account-grant", account_id=aws_account_id)

# To grant usage to all accounts in some AWS Ogranization
# layer.grantUsage({ accountId: '*', organizationId });

lambda_.Function(stack, "MyLayeredLambda",
    code=lambda_.InlineCode("foo"),
    handler="index.handler",
    runtime=lambda_.Runtime.NODEJS_10_X,
    layers=[layer]
)

By default, updating a layer creates a new layer version, and CloudFormation will delete the old version as part of the stack update.

Alternatively, a removal policy can be used to retain the old version:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.LayerVersion(self, "MyLayer",
    removal_policy=RemovalPolicy.RETAIN,
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
)

Architecture

Lambda functions, by default, run on compute systems that have the 64 bit x86 architecture.

The AWS Lambda service also runs compute on the ARM architecture, which can reduce cost for some workloads.

A lambda function can be configured to be run on one of these platforms:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    architecture=lambda_.Architecture.ARM_64
)

Similarly, lambda layer versions can also be tagged with architectures it is compatible with.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.LayerVersion(self, "MyLayer",
    removal_policy=RemovalPolicy.RETAIN,
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    compatible_architectures=[lambda_.Architecture.X86_64, lambda_.Architecture.ARM_64]
)

Lambda Insights

Lambda functions can be configured to use CloudWatch Lambda Insights which provides low-level runtime metrics for a Lambda functions.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    insights_version=lambda_.LambdaInsightsVersion.VERSION_1_0_98_0
)

If the version of insights is not yet available in the CDK, you can also provide the ARN directly as so -

# Example automatically generated. See https://github.com/aws/jsii/issues/826
layer_arn = "arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:14"
lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    insights_version=lambda_.LambdaInsightsVersion.from_insight_version_arn(layer_arn)
)

Event Rule Target

You can use an AWS Lambda function as a target for an Amazon CloudWatch event rule:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_events as events
import aws_cdk.aws_events_targets as targets

# fn is of type Function

rule = events.Rule(self, "Schedule Rule",
    schedule=events.Schedule.cron(minute="0", hour="4")
)
rule.add_target(targets.LambdaFunction(fn))

Event Sources

AWS Lambda supports a variety of event sources.

In most cases, it is possible to trigger a function as a result of an event by using one of the add<Event>Notification methods on the source construct. For example, the s3.Bucket construct has an onEvent method which can be used to trigger a Lambda when an event, such as PutObject occurs on an S3 bucket.

An alternative way to add event sources to a function is to use function.addEventSource(source). This method accepts an IEventSource object. The module @aws-cdk/aws-lambda-event-sources includes classes for the various event sources supported by AWS Lambda.

For example, the following code adds an SQS queue as an event source for a function:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_lambda_event_sources as eventsources
import aws_cdk.aws_sqs as sqs

# fn is of type Function

queue = sqs.Queue(self, "Queue")
fn.add_event_source(eventsources.SqsEventSource(queue))

The following code adds an S3 bucket notification as an event source:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_lambda_event_sources as eventsources
import aws_cdk.aws_s3 as s3

# fn is of type Function

bucket = s3.Bucket(self, "Bucket")
fn.add_event_source(eventsources.S3EventSource(bucket,
    events=[s3.EventType.OBJECT_CREATED, s3.EventType.OBJECT_REMOVED],
    filters=[NotificationKeyFilter(prefix="subdir/")]
))

See the documentation for the @aws-cdk/aws-lambda-event-sources module for more details.

Lambda with DLQ

A dead-letter queue can be automatically created for a Lambda function by setting the deadLetterQueueEnabled: true configuration.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_inline("exports.handler = function(event, ctx, cb) { return cb(null, \"hi\"); }"),
    dead_letter_queue_enabled=True
)

It is also possible to provide a dead-letter queue instead of getting a new queue created:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_sqs as sqs


dlq = sqs.Queue(self, "DLQ")
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_inline("exports.handler = function(event, ctx, cb) { return cb(null, \"hi\"); }"),
    dead_letter_queue=dlq
)

See the AWS documentation to learn more about AWS Lambdas and DLQs.

Lambda with X-Ray Tracing

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_inline("exports.handler = function(event, ctx, cb) { return cb(null, \"hi\"); }"),
    tracing=lambda_.Tracing.ACTIVE
)

See the AWS documentation to learn more about AWS Lambda's X-Ray support.

Lambda with Profiling

The following code configures the lambda function with CodeGuru profiling. By default, this creates a new CodeGuru profiling group -

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.PYTHON_3_6,
    handler="index.handler",
    code=lambda_.Code.from_asset("lambda-handler"),
    profiling=True
)

The profilingGroup property can be used to configure an existing CodeGuru profiler group.

CodeGuru profiling is supported for all Java runtimes and Python3.6+ runtimes.

See the AWS documentation to learn more about AWS Lambda's Profiling support.

Lambda with Reserved Concurrent Executions

# Example automatically generated. See https://github.com/aws/jsii/issues/826
fn = lambda_.Function(self, "MyFunction",
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_inline("exports.handler = function(event, ctx, cb) { return cb(null, \"hi\"); }"),
    reserved_concurrent_executions=100
)

See the AWS documentation managing concurrency.

AutoScaling

You can use Application AutoScaling to automatically configure the provisioned concurrency for your functions. AutoScaling can be set to track utilization or be based on a schedule. To configure AutoScaling on a function alias:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_autoscaling as autoscaling

# fn is of type Function

alias = lambda_.Alias(self, "Alias",
    alias_name="prod",
    version=fn.latest_version
)

# Create AutoScaling target
as = alias.add_auto_scaling(max_capacity=50)

# Configure Target Tracking
as.scale_on_utilization(
    utilization_target=0.5
)

# Configure Scheduled Scaling
as.scale_on_schedule("ScaleUpInTheMorning",
    schedule=autoscaling.Schedule.cron(hour="8", minute="0"),
    min_capacity=20
)
# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_applicationautoscaling as appscaling
import aws_cdk.core as cdk
import ...lib as lambda_

#
# Stack verification steps:
# aws application-autoscaling describe-scalable-targets --service-namespace lambda --resource-ids function:<function name>:prod
# has a minCapacity of 3 and maxCapacity of 50
#
class TestStack(cdk.Stack):
    def __init__(self, scope, id):
        super().__init__(scope, id)

        fn = lambda_.Function(self, "MyLambda",
            code=lambda_.InlineCode("exports.handler = async () => { console.log('hello world'); };"),
            handler="index.handler",
            runtime=lambda_.Runtime.NODEJS_10_X
        )

        version = fn.add_version("1", undefined, "integ-test")

        alias = lambda_.Alias(self, "Alias",
            alias_name="prod",
            version=version
        )

        scaling_target = alias.add_auto_scaling(min_capacity=3, max_capacity=50)

        scaling_target.scale_on_utilization(
            utilization_target=0.5
        )

        scaling_target.scale_on_schedule("ScaleUpInTheMorning",
            schedule=appscaling.Schedule.cron(hour="8", minute="0"),
            min_capacity=20
        )

        scaling_target.scale_on_schedule("ScaleDownAtNight",
            schedule=appscaling.Schedule.cron(hour="20", minute="0"),
            max_capacity=20
        )

        cdk.CfnOutput(self, "FunctionName",
            value=fn.function_name
        )

app = cdk.App()

TestStack(app, "aws-lambda-autoscaling")

app.synth()

See the AWS documentation on autoscaling lambda functions.

Log Group

Lambda functions automatically create a log group with the name /aws/lambda/<function-name> upon first execution with log data set to never expire.

The logRetention property can be used to set a different expiration period.

It is possible to obtain the function's log group as a logs.ILogGroup by calling the logGroup property of the Function construct.

By default, CDK uses the AWS SDK retry options when creating a log group. The logRetentionRetryOptions property allows you to customize the maximum number of retries and base backoff duration.

Note that, if either logRetention is set or logGroup property is called, a CloudFormation custom resource is added to the stack that pre-creates the log group as part of the stack deployment, if it already doesn't exist, and sets the correct log retention period (never expire, by default).

Further note that, if the log group already exists and the logRetention is not set, the custom resource will reset the log retention to never expire even if it was configured with a different value.

FileSystem Access

You can configure a function to mount an Amazon Elastic File System (Amazon EFS) to a directory in your runtime environment with the filesystem property. To access Amazon EFS from lambda function, the Amazon EFS access point will be required.

The following sample allows the lambda function to mount the Amazon EFS access point to /mnt/msg in the runtime environment and access the filesystem with the POSIX identity defined in posixUser.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_ec2 as ec2
import aws_cdk.aws_efs as efs


# create a new VPC
vpc = ec2.Vpc(self, "VPC")

# create a new Amazon EFS filesystem
file_system = efs.FileSystem(self, "Efs", vpc=vpc)

# create a new access point from the filesystem
access_point = file_system.add_access_point("AccessPoint",
    # set /export/lambda as the root of the access point
    path="/export/lambda",
    # as /export/lambda does not exist in a new efs filesystem, the efs will create the directory with the following createAcl
    create_acl=Acl(
        owner_uid="1001",
        owner_gid="1001",
        permissions="750"
    ),
    # enforce the POSIX identity so lambda function will access with this identity
    posix_user=PosixUser(
        uid="1001",
        gid="1001"
    )
)

fn = lambda_.Function(self, "MyLambda",
    # mount the access point to /mnt/msg in the lambda runtime environment
    filesystem=lambda_.FileSystem.from_efs_access_point(access_point, "/mnt/msg"),
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
    vpc=vpc
)

Singleton Function

The SingletonFunction construct is a way to guarantee that a lambda function will be guaranteed to be part of the stack, once and only once, irrespective of how many times the construct is declared to be part of the stack. This is guaranteed as long as the uuid property and the optional lambdaPurpose property stay the same whenever they're declared into the stack.

A typical use case of this function is when a higher level construct needs to declare a Lambda function as part of it but needs to guarantee that the function is declared once. However, a user of this higher level construct can declare it any number of times and with different properties. Using SingletonFunction here with a fixed uuid will guarantee this.

For example, the LogRetention construct requires only one single lambda function for all different log groups whose retention it seeks to manage.

Bundling Asset Code

When using lambda.Code.fromAsset(path) it is possible to bundle the code by running a command in a Docker container. The asset path will be mounted at /asset-input. The Docker container is responsible for putting content at /asset-output. The content at /asset-output will be zipped and used as Lambda code.

Example with Python:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.Function(self, "Function",
    code=lambda_.Code.from_asset(path.join(__dirname, "my-python-handler"),
        bundling=BundlingOptions(
            image=lambda_.Runtime.PYTHON_3_9.bundling_image,
            command=["bash", "-c", "pip install -r requirements.txt -t /asset-output && cp -au . /asset-output"
            ]
        )
    ),
    runtime=lambda_.Runtime.PYTHON_3_9,
    handler="index.handler"
)

Runtimes expose a bundlingImage property that points to the AWS SAM build image.

Use cdk.DockerImage.fromRegistry(image) to use an existing image or cdk.DockerImage.fromBuild(path) to build a specific image:

# Example automatically generated. See https://github.com/aws/jsii/issues/826
lambda_.Function(self, "Function",
    code=lambda_.Code.from_asset("/path/to/handler",
        bundling=BundlingOptions(
            image=DockerImage.from_build("/path/to/dir/with/DockerFile",
                build_args={
                    "ARG1": "value1"
                }
            ),
            command=["my", "cool", "command"]
        )
    ),
    runtime=lambda_.Runtime.PYTHON_3_9,
    handler="index.handler"
)

Language-specific APIs

Language-specific higher level constructs are provided in separate modules:

Code Signing

Code signing for AWS Lambda helps to ensure that only trusted code runs in your Lambda functions. When enabled, AWS Lambda checks every code deployment and verifies that the code package is signed by a trusted source. For more information, see Configuring code signing for AWS Lambda. The following code configures a function with code signing.

# Example automatically generated. See https://github.com/aws/jsii/issues/826
import aws_cdk.aws_signer as signer


signing_profile = signer.SigningProfile(self, "SigningProfile",
    platform=signer.Platform.AWS_LAMBDA_SHA384_ECDSA
)

code_signing_config = lambda_.CodeSigningConfig(self, "CodeSigningConfig",
    signing_profiles=[signing_profile]
)

lambda_.Function(self, "Function",
    code_signing_config=code_signing_config,
    runtime=lambda_.Runtime.NODEJS_12_X,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
)

Project details


Release history Release notifications | RSS feed

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

aws-cdk.aws-lambda-1.132.0.tar.gz (382.2 kB view hashes)

Uploaded Source

Built Distribution

aws_cdk.aws_lambda-1.132.0-py3-none-any.whl (373.2 kB view hashes)

Uploaded Python 3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page