Lambda Web Function endpoint access control

You can control access to your AWS Lambda Web Function endpoints using the AuthType you set on each endpoint. Depending on the authentication type, you can also attach a resource-based policy to the Web Function to control who can invoke an endpoint.

When you configure an endpoint, you specify one of the following AuthType options:

The IAM action for invoking an endpoint is lambda:InvokeWebFunctionEndpoint.

You set an endpoint's authentication type with the --auth-type parameter when you create the endpoint (create-web-function-endpoint), and you can change it later with update-web-function-endpoint. For the create command, see Creating an endpoint. For the properties that you can change, see Updating an endpoint.

Using the IamAuth authentication type

If you choose the IamAuth authentication type, callers must sign each request with SigV4 (SigV4a for MultiRegion endpoints) and must be permitted to invoke the endpoint. Depending on who makes the request, you grant this permission with a resource-based policy on the Web Function, an identity-based policy on the caller, or both.

If the caller is in the same AWS account as the Web Function, they can be granted lambda:InvokeWebFunctionEndpoint through either an identity-based policy or the function's resource-based policy. If the caller is in a different account, they need both an identity-based policy granting the action and a resource-based policy on the function that allows them.

Resource-based policies are attached to the Web Function, but each statement can scope the Resource to a specific endpoint ARN. The following resource-based policy allows the InvokeRole role in account 222233334444 to invoke the prod endpoint of my-function:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::222233334444:role/InvokeRole"
            },
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod"
        }
    ]
}

To attach the resource-based policy, use put-resource-policy with the function ARN (not an endpoint ARN):

aws lambda-web put-resource-policy \
    --resource-arn "arn:aws:lambda:us-east-1:111122223333:web-function/my-function" \
    --policy file://policy.json \
    --region us-east-1

You can review or remove the policy with get-resource-policy and delete-resource-policy.

A Web Function has one resource-based policy, and put-resource-policy replaces it. To add a statement, such as the CloudFront statement in CloudFront integration, get the current policy with get-resource-policy, add the statement to its Statement array, and pass the returned revisionId with --revision-id. If someone changed the policy after you read it, the request fails with a ConflictException instead of overwriting their change.

To allow invoking all endpoints of a function, use a wildcard in the resource ARN:

"Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/*"

Replace the Region, account ID, and function name with your own values. Keep endpoint/* at the end.

Granting invoke permission to a principal

A caller needs lambda:InvokeWebFunctionEndpoint to invoke an endpoint. For a caller in the same account as the Web Function, granting this action in the caller's identity-based policy is sufficient. No resource-based policy is required. For a caller in a different account, this identity-based policy is required in addition to a resource-based policy on the function that allows them.

Attach the following policy to the IAM role or user that will invoke the endpoint:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod"
        }
    ]
}

Signing requests

Lambda doesn't provide a dedicated SDK for invoking endpoints. You send standard HTTP requests and sign them yourself with SigV4 or SigV4a, using the service name lambda. Note the following:

For more information about signing requests, see Signing AWS API requests.

After Lambda validates the SigV4 or SigV4a signature, it removes the Authorization header before forwarding the request to your function. If you want your function to receive the Authorization header on an IamAuth endpoint, send requests through CloudFront, which signs them on your behalf (see CloudFront integration).

CloudFront integration

You can use Amazon CloudFront origin access control (OAC) to put a CloudFront distribution in front of an IamAuth endpoint. With OAC, CloudFront signs each origin request on the viewer's behalf, so callers don't sign requests themselves. CloudFront doesn't use the Authorization header to sign the origin request, so it can pass your Authorization header through to the function.

Lambda removes any Authorization value that is itself an AWS signature (a value that starts with AWS4-). This lets you keep your application's authentication (for example, JWT or cookies) while CloudFront signs every origin request. To do this, configure the distribution to forward the Authorization header. For more information, see Restricting access to an AWS origin.

The endpoint domain stays reachable on the internet, and Lambda also accepts direct signed requests from any principal that your policies allow.

This requires the endpoint's authentication type to be IamAuth. Create the origin access control with origin type lambda and signing behavior always-amz-auth. CloudFront rejects other signing behaviors for Web Function origins.

To allow CloudFront to invoke the endpoint, attach a resource-based policy to the Web Function that grants the CloudFront service principal (cloudfront.amazonaws.com) the lambda:InvokeWebFunctionEndpoint action. Use an aws:SourceArn condition to allow only your specific distribution:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccess",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<distribution-id>"
                }
            }
        }
    ]
}

Using the ApplicationManaged authentication type

When an endpoint's authentication type is ApplicationManaged, anyone with the endpoint's domain can invoke your function. Lambda performs no authentication or authorization.

Choose ApplicationManaged when you want your endpoint to be publicly reachable, for example, to serve requests directly from a web browser. You can also choose it when you handle authentication in your own code, such as OAuth 2.0, OpenID Connect, or a custom token scheme.

With this authentication type:

Governance and access control

You can control who can configure endpoints.

Lambda supports the following IAM actions for managing endpoints:

To allow or deny an action based on an authentication type, use a condition key. lambda:Request/WebFunctionAuthType applies to CreateWebFunction, CreateWebFunctionEndpoint, and UpdateWebFunctionEndpoint. lambda:Resource/WebFunctionAuthType applies to InvokeWebFunctionEndpoint (on IamAuth endpoints), UpdateWebFunctionEndpoint, GetWebFunctionEndpoint, and DeleteWebFunctionEndpoint. For details, see Condition keys.

Restricting public endpoints in an organization

If you administer an AWS Organization and want to prevent developers from creating public endpoints, use a service control policy (SCP) that denies creating or updating endpoints with the ApplicationManaged authentication type. Use the lambda:Request/WebFunctionAuthType condition key, which reflects the authentication type in the request:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "lambda:CreateWebFunction",
                "lambda:CreateWebFunctionEndpoint",
                "lambda:UpdateWebFunctionEndpoint"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "lambda:Request/WebFunctionAuthType": "ApplicationManaged"
                }
            }
        }
    ]
}

The policy includes lambda:CreateWebFunction because that operation creates the initial endpoint from the request's endpointConfig. With this policy in place, aws lambda-web deploy fails with an access denied error unless the developer adds --auth-type IamAuth. By default, the command creates an ApplicationManaged endpoint.

Condition keys

For fine-grained access control, Lambda supports the following condition context keys:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/*/endpoint/prod",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Environment": "Production"
                }
            }
        }
    ]
}