Retrieving Lambda@Edge CloudWatch Logs
What is Lambda@Edge
AWS Lambda@Edge is an extension of the traditional AWS Lambda service, but with a crucial twist – it brings serverless computing capabilities closer to the end-users.
In essence, Lambda@Edge empowers developers to run custom code in response to specific CloudFront events. Whether it's tailoring content based on user location, device type, or handling real-time data processing at the edge, Lambda@Edge functions open up a world of possibilities for optimizing content delivery.
Lambda@Edge functions have the following features:
They can access public internet
They can be run before or after your cache
They allow developers to view and modify not only the client request/response but also the origin request/response
They can read the body of the request
They can use a much bigger package size for code compared to CloudFront Functions (1MB for a client request/response trigger and 50MB for an origin request/response trigger)
They allow up to 5 seconds for a client request/response trigger and up to 30 seconds for an origin request/response trigger.
How can you retrieve the Lambda@Edge logs?
Due to the fact that Lambda@Edge functions run in the CloudFront Regional Edge Caches, the CloudWatch logs cannot only be found in
us-east-1, but potentially in all other AWS regions that support Regional Edge Caches.
The Lambda@Edge testing and debugging guide states
When you review CloudWatch log files or metrics when you're troubleshooting errors, be aware that they are displayed or stored in the Region closest to the location where the function executed. So, if you have a website or web application with users in the United Kingdom, and you have a Lambda function associated with your distribution, for example, you must change the Region to view the CloudWatch metrics or log files for the London AWS Region.
So, one simple solution to automatically get the logs from all regions would be to write a script that searches for relevant CloudWatch Logs groups in each region, and displays their respective LogStream entries.
This script could look like this
for region in $(aws --output text ec2 describe-regions | cut -f 4)
echo "Checking $region"
for loggroup in $(aws --output text logs describe-log-groups --log-group-prefix "/aws/lambda/us-east-1.$FUNCTION_NAME" --region $region --query 'logGroups.logGroupName')
echo "Found '$loggroup' in region $region"
for logstream in $(aws --output text logs describe-log-streams --log-group-name $loggroup --region $region --query 'logStreams.logStreamName')
aws --output text logs get-log-events --log-group-name $loggroup --region $region --log-stream-name $logstream | cat
If you save this script as
cf-logs.sh, after giving it execution rights with
chmod +x cf-logs.sh, can then be started with
./cf-logs.sh YOUR_FUNCTION_NAME, where
YOUR_FUNCTION_NAME is the real Lambda@Edge function name.
This solution is great for quick log viewing while you're still developing your edge-enabled application, but surely is not a sustainable one when running in production.
Aggregating Lambda@Edge logs with Kinesis
For a production setup, you'd probably want to be able to aggregate and store the individual logs coming from the different regions in one place. A possible solution is to stream them to a Kinesis Firehose Delivery Stream, which then stores the logs in S3.
An example implementation can be found at https://gist.github.com/heitorlessa/5d2295655f9d76483969d215986e53b0
Please be aware that this will incur additional fixed and variable costs, so please review AWS' pricing of the used services.