Lambda@Edge not logging on cloudfront request

28
votes

As explained in the Docs , I set up Lambda@edge for cloudfront trigger of Viewer Response.

The lambda function code : 

'use strict';

exports.handler = (event, context, callback) => {
    console.log('----EXECUTED------');

    const response = event.Records[0].cf.response;      
    console.log(event.Records[0].cf_response);

    callback(null, response);
};

I have set up trigger appropriately for the Viewer Response event.

Now when I make a request through cloudfront, it must be logged in cloudwatch, but it doesn't.
If I do a simple Test Lambda Function (using Button), it is logged properly.

What might be the issue here ?

3
amazon-web-servicesaws-lambdaamazon-cloudfrontaws-lambda-edge
You should find that it's being logged in the AWS region where the CloudFront edge location you're currently hitting is located, which should be a region near where you are located. Testing always logs to us-east-1 but not real traffic. You could also add response.headers['x-lambda-region'] = [ { key: 'X-Lambda-Region', value: process.env.AWS_REGION } ]; to your code (before the callback) and if your trigger is running successfully, you'll see that an X-Lambda-Region header has been added to the response, telling you which region was involved in processing your request. Your thoughts? – Michael - sqlbot

3 Answers

58
votes

When you deploy Lambda@Edge function, It is deployed to all edge cache regions across the world with their version Replica of the Lambda Edge function. Regional edge caches are a subset of the main AWS regions and edge locations.

When a user requests to the nearest pop/edge, the lambda associated with the edge cache region will get called. All logs of Lambda associated with those regions will in their edge cache region CloudWatch logs.

For example:

If a user is hitting us-east-1 region then its associated logs will be in us-east-1.

To know exactly where (on which region) your function is logging, you can run this AWS CLI script:

FUNCTION_NAME=function_name_without_qualifiers
for region in $(aws --output text  ec2 describe-regions | cut -f 3) 
do
    for loggroup in $(aws --output text  logs describe-log-groups --log-group-name "/aws/lambda/us-east-1.$FUNCTION_NAME" --region $region --query 'logGroups[].logGroupName')
    do
        echo $region $loggroup
    done
done

on which you have to replace "function_name_without_qualifiers" with the name of your lambda@edge. Link

Hope it helps.

15
votes

For those who have also searched for logs and couldn't find them with the script provided by @Kannaiyan.

TL;DR

Use this IAM Role for your Lambda function

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": "logs:CreateLogGroup",
        "Resource": "arn:aws:logs:*:*:*"
    },
    {
        "Effect": "Allow",
        "Action": [
            "logs:CreateLogStream",
            "logs:PutLogEvents"
        ],
        "Resource": [
            "arn:aws:logs:*:*:log-group:*:*"
        ]
    }
  ]
}

====

Make sure you have correct IAM role. If you created a Lambda first and then deployed it to Lambda@Edge, automatically generated IAM Role will only have permissions enough to log data in a single region into the log group named after the Lambda function, whilst using Lambda@Edge means it'll try to log data in different regions into the "/aws/lambda/." log group. Therefore it is necessary to change the IAM Role to allow creation of log group and write access there in different regions. In the TL;DR section, I provided the sample IAM Role, but make sure to narrow down the access to the specific list of log groups in production

9
votes

According to AWS Documentation for Lambda@Edge Functions:

When you check for the log files, be aware that log files are stored in the Region closest to the location where the function is executed. So if you visit a website from, for example, London, you must change the Region to view the CloudWatch Logs for the London Region.