Lambda is a serverless compute service that allows to run your application code in AWS without provisioning any servers. Lambda takes care of everything required to run your code, including the runtime environment. It provides typical AWS features like auto-scaling and high availability and it’s supported languages are:
Basically you just need to upload your code and it is ready to run!
There are three different sections where you get charged. One is the amount of requests of your Lambda functions, the second one is its runtime duration, so how long it runs and the third is the allocated memory which is needed to execute the functions. Furthermore, there are some details to consider:
- First 1 million requests per month are free.
- 0.20 USD per month per 1 million requests afterwards.
- You are charged in 1 millisecond increments.
- The price depends on the amount of memory you allocate to your Lambda function (0.000001667 USD per GB-second).
- First 400000 GB-seconds per month are free.
The main point to take away here is that running your code in Lambda functions is significant cheaper than EC2 instances!
Lambda functions are event driven, which means they will get triggered by other AWS services or called directly from any web or mobile application. These events could be changes made to data in a S3 bucket or DynamoDB table. You can also use API Gateway to configure an HTTP endpoint allowing you to trigger the function at any time using an HTTP request.
If you are interested in all AWS services which can trigger a Lambda function, have a look at the official documentation:
Lambda functions are limited by concurrent actions. Default is 1,000 concurrent executions per region. If they are reached, you will receive an error “TooManyRequests” with the HTTP Status Code: 429.
To increase the limit you have to reach out to the AWS Support Center. It is also possible to reserve a set of number of executions for a critical Lambda function with the reserved concurrency option, this will be added to your limit.
Creating a Lambda Function
Now you are going to create your first own Lambda function and add an API Gateway as trigger. To start with it open your AWS Console and navigate to the Lambda service. On the top right corner you see an orange button called “Create function”, click on it! Just insert a name and choose Python 3.8 as Runtime, then click on “Create function”.
You will be navigated to an overview of your new lambda function where you see a logical visualization and the code source below. Inside the code is a simple script which prints “Hello from Lambda!” as it got called successfully, you can leave it like this.
Okay, so far so good, but how do you call the function? The easiest way is to add an API Gateway as trigger, to do so click on the top of the overview page at the visualization on the bottom left button called “Add trigger”. Then search for API Gateway as the source and toggle “Create a new API”. As API type select REST API and on Security make it open and click on “Add”.
You have created an API Gateway as trigger for your Lambda function! You will be navigated to the trigger overview page, where you can see the API endpoint section with a link which you can copy and execute in a browser tab.
If you have copied the link and run it in your browser, you should see now the output “Hello from Lambda!” or whatever you have written in the body section of your function.
Congratulations, you have created your first Lambda function including a trigger!
The use of AWS Lambda versioning and Aliases are the safest way to manage and deploy Lambda functions. You can split your production and development environment easily. You won’t affecting users of the stable production version. The default version thereby is always called $LATEST. The workflow is as follows:
- You make changes to your existing Lambda function and deploy it, all changes will be deployed on version $LATEST.
- Afterwards you can publish a new version.
- If you are using an Alias you can point it to the new version.
Let’s give it a try!
First of all delete the previously created API Gateway trigger by selecting it on the overview visualization and click on delete after checking it’s box. Then go back to your Lambda function and make some changes in the code, you can just change the output inside the body attribute. Click on deploy to update version $LATEST.
On the top right corner is a drop down button called “Actions”, click it and hit “Publish new version”! A description is optional, just make sure to click on “Publish”.
You have created a new version! You can see it in the path on top where it says “Version: 1” in your case. Now go back to version $LATEST by selecting samplefunction in the top path.
You can now create an Alias by selecting the tab Aliases in the navigation bar below the visualization overview.
Hit on “Create alias”, give it a name, add a description and select your newly created version to it in the drop down and submit it.
This time you are inside of your alias which is pointing to a specific version. As you want also to test the lambda function, go ahead and create an API Gateway trigger inside of the alias as before. If done so, test the function by pasting the API endpoint into a browser tab, you should see the new output.
Okay, lets make another change to the lambda function! First, go back to version $LATEST and edit for example the body text again. Deploy the changes and publish another version. Go back to version $LATEST and navigate to the tab Aliases. Select your alias and click on edit, then point it to the newly created version.
If you execute the API endpoint again, you should see the latest output of your code.
And that’s how versioning with aliases works! I hope you got a sense of it. It is quite handy to maintain separate aliases for example for a development, testing and production environment, to avoid failures on freshly published updates.
If the article was helpful, I’m glad for some likes and also consider follow my blog for further upcoming articles. Cheers!