Controlling CloudWatch Log Retention Period When Using Serverless Framework on AWS

Sorry if my stuff isn't well structured, mostly just writing notes.
Search for a command to run...

Sorry if my stuff isn't well structured, mostly just writing notes.
No comments yet. Be the first to comment.
To use Postgres with your wsl rails application, you'll have to download Postgres for windows and connect to it through linux: https://www.postgresql.org/download/windows/ Remember the username(default is Postgres) and password you chose during the P...

Installation instructions for wsl: https://docs.microsoft.com/en-us/windows/wsl/install-win10 Assuming wsl is already installed and the terminal is up and running. First install some dependecies sudo apt-get update sudo apt-get install git-core curl ...

If you have multiple GitHub accounts, and end up making a bunch of commits under the wrong account, what do you do? Reset your branch and start working all over again with the right account in credentials? Maybe that's the more honorable method, but ...

This is my first hashnode post, I'm primarily going to be writing these for myself and editing when I have enough time, so they probably won't be coherent or helpful. I'll refrain from using tags so as not to confuse others with my posts. This post i...

When creating Lambda functions with the serverless framework, CloudWatch logs are created and have a log retention period of "never expire" by default. This can get very expensive as the months go by, and you are paying to store these CloudWatch logs. The price is about $0.03 per GB. For more details on CloudWatch pricing, please consult the documentation https://aws.amazon.com/cloudwatch/pricing/.
This can get very expensive for functions that receive a lot of traffic, and do you actually need gigabytes of lambda function log data from the last year? Depending on your use case, you probably do not.
Some solutions to reduce the amount of money you're spending on logs are:
If your Lambda function has a bunch of unnecessary logging statements used for debugging, those are log entries that do not need to exist in production. You do not need console.log/print statements all over your function code to track execution. Only log when necessary
If this is a log group for something created outside the serverless framework or CloudFormation, this can be done manually in the AWS console by navigating to CloudWatch

Go to logs, select log groups:

Click on the desired log group, then click on actions, and edit retention settings:

Then you can select from a list of different dates:

If you are using Serverless Framework, it becomes slightly less obvious because these are logs being created for your function automatically. They are not defined in your Serverless.yml file. Let's run through an example using a simple HTTP serverless function source code: https://github.com/serverless/examples/tree/v3/aws-node-http-api.
Run serverless deploy

A hidden serverless folder is created, and if you check the cloudformation-template-update-stack.json file, you will notice there is a log group created for the function automatically.

It will always be the camelcase name of your function with LogGroup at the end

You can add a log retention period by adding a resources section to your serverless.yml file:
service: aws-node-rest-api
frameworkVersion: "2"
provider:
name: aws
runtime: nodejs12.x
lambdaHashingVersion: "20201221"
functions:
hello:
handler: handler.hello
events:
- http:
path: /
method: get
resources:
Resources:
HelloLogGroup:
Type: "AWS::Logs::LogGroup"
Properties:
RetentionInDays: "7"
After rerunning serverless deploy, you will notice a log retention period is added to the CloudFormation template.

You can confirm it on the AWS console as well.

Do not forget to delete the resources created if you deployed the serverless application sls remove

You can also use this pattern to edit other properties as you desire.