Lambda is a serverless service offering on AWS that lets you run your code without worrying about provisioning and maintaining the backend infrastructure.
Simply select your runtime (Node.js, python, Ruby, Java,…), select your instruction set architecture (x86_64 or arm64), and start writing your code.
Additional configuration options such as memory and execution timeout are available. Keep in mind that these parameters affect billing since you are billed on execution duration (per ms) in Lambda. More memory allocated will result in a higher execution duration price per millisecond.
You can also configure your Lambda function from a container image or a blueprint.
Event-based triggers can easily be configured with Lambda triggers. Triggers can be tailored based on your event-driven architecture and requirements.
Some trigger examples:
- CRON or rate expressions with an EventBridge trigger.
- API Trigger with API Gateway triggers.
- S3 Object upload with S3 triggers. (See application below)
A function can also have destinations:
- SNS Topic to notify end users.
- SQS queue. Good for decoupling applications in microservices architectures.
- Another Lambda function.
In my most recent use case, I implemented an optimization script to improve a set of KPIs (unattached EBS volumes, unreleased EIPs, …) for our large AWS environment. The findings are aggregated, and then exported to a S3 bucket ready to be ingested by BI teams for Data Visualization and Reporting.
An EventBridge trigger with a CRON expression to schedule the execution of my script is suitable for my use case. CRON expressions follow the following format:
cron(Minutes Hours Day-of-month Month Day-of-week Year)
Rate expressions are also valid for this trigger type:
rate(5 minutes)
rate(1 hour)
rate(7 days)
Every Lambda function should have a “lambda_handler” defined that is responsible to process events and run code upon function invocation.
Top comments (0)