I remember staring at the AWS Lambda console for the first time and feeling overwhelmed. There were so many things happening: qualifiers, actions, triggers, permissions. It’s like the cockpit of a fighter jet in there. And with new features the Lambda interface has only become more complicated.
But when you understand the different parts of the AWS Lambda console and everything you can achieve with Lambda it opens up your perspective and builds your confidence. When you know what all the parts do you can then focus your attention only on the features that matter for you.
By the end of this article you will be more confident using AWS Lambda after we explore and understand the AWS Lambda console.
Let’s take things from the top (quite literally) and start with the designer…
The Lambda Designer
The first thing you’ll come into contact with when opening up the Lambda console is the designer panel which shows us three main things: Lambda Triggers, Layers and Destinations.
Let’s break each of these down…
- Lambda Triggers (left) — Lambda Triggers are input sources that tell the Lambda to start running (invocation). Without an explicit definition the Lambda will not be invoked from that source even if called. You can invoke a Lambda from all sorts of events like: a user request to an ALB or API gateway, a scheduled event (CloudWatch) or an upload to an S3 bucket.
- Lambda Layers (middle) — Lambda Layers allow extra code to be pulled into the Lambda environment. The two big reasons to use Layers are: ensuring your Lambda package is small enough to use the Lambda file editor, and to share code between functions. But Layers can get complicated to manage so use them only if you really need to.
- Lambda Destinations (right) — Lambda Destinations allow you to do store the result of your asynchronous events and to invoke other AWS services once the Lambda is complete. You could push a message onto another SQS queue, or you could trigger a notification that the Lambda has failed.
Configure Lambda Test Events
Now if you look at the top of the console you’ll see a dropdown for test events. Test events allow you to manually emulate event triggers to your Lambda. Different event triggers (i.e SQS, ALB’s etc) have different object structures and you can manually emulate these different invocations using test events.
AWS provide you with some handy event templates, which give you the basic event structure for the different AWS services. You can easily create events that emulate a Lambda invocation from SQS, Kinesis etc. Test events are useful for verifying your Lambda works as expected.
Lambda Environment Variables
Further down the lambda console you’ll see the environment variables settings. Environment variables allow you to configure your Lambda to work differently in different environments such as testing vs production. Environment variables can also act as a way of toggling on and off behaviours without re-deploying.
You might have noticed from the image the part at the bottom of the panel about KMS. But what is KMS and how does it relate to Lambda? KMS is a key management service which stores encryption keys for encrypting and decrypting sensitive information such as passwords, access keys etc.
We can use KMS to encrypt our environment variables in Lambda which ensures that they are kept private and are not stored in plain text where they can be easily stolen, intercepted or logged by accident.
AWS Lambda Execution Role
Also on the Lambda console you’ll see a panel for an execution role. Every Lambda function must be assigned an IAM role. IAM roles are entities which are granted permissions either directly, or through association with separate permission policies.
It’s important to understand how IAM roles work for using Lambda because almost everything you do within Lambda requires modifying IAM roles. Integrating any other AWS service requires you to set IAM permissions. So it’s useful if you’re comfortable with using IAM roles and policies.
AWS Lambda Basic Settings
Also on the Lambda console are the more straight-forward basic settings. With the basic settings you are given two configurations to modify: memory allocation and timeouts.
- Lambda Memory — Every Lambda has an allocated amount of resources, dictated by the memory allocation. All other resource characteristics such as CPU are changed in tandem with the Lambda memory allocation. That means if you want more power (of any kind) you’ll need to increase the memory allocation configuration.
- Lambda Timeout — The Lambda timeout is the cutoff time that the Lambda function will respond as failed if it does not complete in the specified time period. It’s a good practice to set a timeout to ensure hanging requests are terminated quickly for any users who are waiting for those requests.
AWS Lambda Database Proxies
Next up: the cryptically named database proxies.
In a typical server to relational database world, the server would open a database connection on start-up and uses the connection throughout the lifetime of the server. Generally speaking the number of connections in this setup are quite low, as each server only requires a single connection.
But, in a Lambda world every time a new Lambda instance is launched (under the hood by AWS) a new connection must be made to the database. When handling many concurrent connections it can be possible that your Lambda will exhaust the connection pool to your database.
To combat the problem of connections getting exhausted AWS introduced RDS proxy. Now, rather than the Lambda talking directly to the database the Lambda function goes via a database proxy. The database proxy then manages the provisioning of the connections and reduces the burden on your database.
AWS Lambda Concurrency
Also on the first page of the Lambda console is your provisioned concurrency settings. Provisioned concurrency allows you to mitigate the downsides of the infamous Lambda cold start. But what is a cold start?
When a Lambda receives new requests it launches resources under the hood to manage the requests. However, when these new resources are launched AWS has to initialise the code and it’s dependencies. This loading incurs a time penalty which is often referred to as a cold start.
To mitigate cold starts AWS released the feature of provisioned concurrency. With provisioned concurrency you can set your Lambda function to keep X instances of your Lambda running. By running Lambda’s on standby you can get around the cold start issue — but of course not without a (financial) cost.
AWS Lambda X-Ray
Next on our list to explore is the X-Ray integration. AWS X-Ray is a tracing service that allows you record request traces throughout your system. X-Ray can be very useful for understanding what’s going on in a large distributed system with many services calling each other.
You can enable X-Ray in two main ways: with active tracing (which checks if the calling service invoked your Lambda with X-Ray) or you can manually instrument your application by installing the AWS SDK and calling X-Ray for different parts of your application.
AWS Lambda VPC
And now a little bit of networking!
If you’re not familiar with VPCs, VPC stands for Virtual Private Cloud. A Virtual Private Cloud allows you to isolate cloud resources into a single privately networked solution. VPC’s are good for security and can help to logically break up AWS infrastructure.
When a Lambda needs to access privately networked resources it will need a connection into the private network to reach them, and that’s what the Lambda VPC settings help with. Attaching a Lambda in a VPC allows it to get access to these privately networked resources.
AWS Lambda Versions & Qualifiers
At the top of the Lambda console you’ll also see a dropdown called qualifiers (I really wish that button was just called “versioning”).
At any point when you invoke a Lambda you’re referring to the Lambda latest code, an alias or a version. All of these methods allow you to have different running versions of a Lambda for the purposes of managing environments, etc.
- Versions — Allow you to snapshot your Lambda at a point in time, preserving it for future use such as when rolling back a change.
- Aliases — Create a namespace link between a version and an arbitrary name, e.g. “production”, “beta”, “feature-x-testing”.
AWS Lambda Permissions Tab
Now that we’ve been through the first page of configuration, let’s take a look at the two tabs up at the top of the UI.
The first tab, for permissions tab is a in-depth breakdown of the permissions that you’ve given to your Lambda. The permissions tab is useful for debugging if your Lambda is not being invoked, or invoking other services as you expect.
You can view the permissions either by resource or action, and with the drop down you can toggle the type of service that the permissions apply to.
Lambda Monitoring Tab
Next along in the Lambda console is the monitoring tab.
On the monitoring tab you get a basic overview of the different metrics for your Lambda such as how long the lambda took to invoke, and whether it was successful. Lambda provides you out-of-the-box with many different metrics that you can explore.
If you want a more in-depth view of what’s happening in your Lambda you can attach a log group to emit log entries to. You can then view these log values in CloudWatch, parse the logs and visualise the logs to get a better understanding of what’s going on within your Lambda.
For more information on Lambda logging check out the article: How To Get AWS Lambda Logs Into CloudWatch
And on that note we conclude today’s run through of the AWS Lambda UI. But before you dash off I do have one more thing you need to know…
Whilst today we’ve talked through the console of AWS Lambda I must stress that working with the console for production is a terrible idea.
The Lambda console is great for experimenting but not when you need to make reliable and repeatable changes.
To ensure that your changes are tracked, reviewed and reversible it makes sense to make changes via infrastructure as code.
For more information on infrastructure as code, check out the article: Infrastructure As Code: A Quick And Simple Explanation.
We did run through those features pretty fast, so be sure to go back to the areas that are of interest and dig into them more. There is a lot going on with Lambda, and it’s definitely not as simple as you might be lead to think.
But hopefully now now that we’ve ran through everything you should have more of a complete understanding about what each of the features do.
Now you should be opening up the AWS Lambda console with more confidence than before and start digging around to get the right Lambda setup for your team and business.
Speak soon Cloud Native friend!
The post Master the AWS Lambda Console: A Comprehensive Walkthrough. appeared first on The Dev Coach.
Lou is the editor of The Cloud Native Software Engineering Newsletter a Newsletter dedicated to making Cloud Software Engineering more accessible and easy to understand. Every 2 weeks you’ll get a digest of the best content for Cloud Native Software Engineers right in your inbox.