AWS Lambdas are incredible! They’re functions that are hosted on Amazon Web Services that can be triggered in a load of ways.
One of the bests part is that you only pay for the time the lambda is running. Got something that only runs once an hour and only takes 2 seconds? You’ll only be charged for 48 seconds a day! That’s insane compared to running a 24/7 ec2 or your own private server.
Today we’ll create a lambda and then look at the three best ways to work with the code.
Creating a Lambda
Once you’ve got your AWS account set up there are a few ways to create a new lambda. For the first Lambda we’re going to be using the AWS Console.
The easiest way to create your first lambda is to create it in the AWS Console. You can find Lambda under Services which takes you to the Lambda console.
This is what you’ll see if this is your first Lambda. Click that Create a function button to start setting up your first function.
You’ll end up on the setup page where you configure some of the function. You can create a Lambda from Blueprints or Serverless Application Repos but for this we’ll Author from scratch.
Enter the name for your function (this must be unique to your user or sub-account), choose your Runtime (We’ll use Node.js 8.10), and select a role.
You’ll have to create a new role if you don’t already have one. Create one from template and you can leave Policy templates blank.
Writing Your Lambda Code
One of the big advantages with Lambdas is that you can choose how you write and edit them. There are three main ways to do so: in Lambda Console, in Cloud9, and on your local machine. I’m going to cover all three and discuss advantages and disadvantages to them.
This is the screen you got sent to when you created the function. You’ll see that there is a lot of stuff going on. The bit that we care about fro now is the Function code section, about half way down
In here we have a basic editor. I believe it’s based on the Cloud 9 IDE and works pretty damn well for simple Lambdas. You can see below that the handler is an async function because I chose to use Node 8.10. If you prefer callbacks then Node 6.10 is the runtime for you.
- It’s a decent editor.
- You can access it from any computer through your AWS console.
- It doesn’t seem to be 100% stable. Sometimes it doesn’t let you save so you have to copy all of your work to local file, reload the page and copy your work back. I hope that this gets fixed soon!
- It doesn’t have a terminal. This means that you can install packages using NPM using this method alone.
Cloud 9 Editor
Amazon recently bought out Cloud 9, an online development platform. It seems to run a very basic version of Ubuntu that is integrated with the rest of the AWS platform.
Search for Cloud 9 in the console, go to the page and select Create environment. From here you give your environment a name and go to the next step.
Here you get to choose what you want to run this environment on. The great thing is that t2.micro is Free-tier eligible so you can use this method without getting charged anything if you’re on the free tier. I’ve never needed anything more powerful than a t2.micro.
Continue on from here and you’ll end up in your new cloud 9 environment!
The cool thing about this is that you have access to all of your Lambdas from inside your environment. Click AWS Resources then under Remote Functions you’ll find all of your functions. Click on the Lambda you want to edit and then hit the download button above to import it into your environment.
Once that’s done, it’ll be just like you’re working on it locally.
Once you’re finished, just select the function you’ve been working on from the local list and hit the upload button. Within a few seconds it’ll be live with all your changes.
- Again, this is all remote so you don’t need to worry about forgetting to commit your work or save it to a memory stick if you work on multiple machines.
- Getting your functions and uploading them is super easy. This is by far the best bit about this method.
- You now have an integrated terminal, allowing you to install npm packages and do everything else you want to do using the terminal.
- It still has the same stability issues that the Lambda editor has. I’ve had multiple occasions where I’ve tried to save couldn’t, having to copy to local, refresh and recopy to Cloud 9. After a few times, I gave up and moved to local editing.
I’m going to do this one a bit differently, I’ll list the advantages and disadvantages then show you how to make it so much better.
- Local editing is how most developers will work, we can use our favourite IDE, extensions and colour schemes.
- It’s stable (as long as your computer is).
- There’s no fancy button to get and upload your work to AWS.
- Your work is local, so multiple users or just working on multiple devices is more complex.
Local Editing Tricks
Because the advantages for this method are so appealing (or the other methods’ disadvantages are so appalling) we’re going to utilise some basic workarounds. It should take about 15 minutes to set up everything we need!
To upload our work to AWS we can use the AWS CLI. This allows us to upload a zip file to our AWS account that populates a given Lambda.
To do this we first need to setup AWS CLI. You can install it usingthis tutorialor by typing npm install -g aws-cli into your terminal. Now we need to set up a user for our CLI to log in as.
In IAM Management, click Add User, give the user a name and select Programmatic Access. This will allow us to act as the user remotely.
In the permissions screen, choose to Attach existing policies directly and select AdministatorAccess. This will let you do whatever you want through your CLI. You can set stricter policies on this user if you want, or this is for another person to access.
There’s another screen before you end up being show your access key. Copy your access key and open a terminal. Run the command aws configure which will ask you for 4 things.
AWS Access Key ID [None]: "Your Access Key ID" AWS Secret Access Key [None]: "Your Secret Access Key" Default region name [eu-west-1]: Default output format [json]:
The first two are found on the last page of the user creation and the next two can be left as default or changed to whatever you want.
Using the AWS CLI
Now that we’ve got the CLI set up, we can use it to make our lives so much easier. If you have a folder with a lambda function in then we can run a few simple commands to upload it.
cd MyLambdaFunction rm index.zip zip –X –r ./index.zip \* aws lambda update-function-code --function-name MyLambdaFunction --zip-file fileb://index.zip cd ..
AWS CLI Build Script
This is great but typing this all out every time you want to upload a new lambda version would become tiresome. So we’re going to use a build script.
For this exact script to work, you need to have a folder structure like this. Each lambda has a folder with the relevant files and a region.txt file.
This script not only runs the basic AWS CLI commands, but it also does extra checks, runs npm install and echos out details about the progress.
This may look like a complex script but it can be easy broken down. The first 32 lines are moving into the lambda folder, running npm install, and checking that AWS CLI is installed. Line 38 is zipping the folder, except from certain files, and line 42 is uploading the zip file.
Now all you need to do is to navigate to the main lambdas folder and run
This script could be modified and expanded to include region specific uploading, batch uploading multiple lambdas or Git integration.
Most people reading this will use git on a daily basis. There’s a reason for that — it makes life simpler.
Having a git repository for all of your lambdas is a great way to work with teams of developers or by yourself on multiple machines.
There are three common ways to edit Lambdas: in the Lambda console, in Cloud 9, and locally.
There are advantages and disadvantages to all three methods, but I think the best choice is to write function locally and deploy them using a deployment script.
If you found this useful then give it some claps and follow me for more AWS tutorials and developer articles!