Getting started with Lambda on AWS in 2018, using Python.

Lambda. Geddit?

Maybe you’ve read about new cloud software that doesn’t require provisioning servers? Maybe you’ve heard of Serverless Computing, or even FaaS? Maybe you’ve seen AWS Lambda, and been itching to find out what that’s all about?

In this article we’ll get a simple Lambda running in Amazon Web Services, and scratch that itch.

What’s a Lambda

A Lambda is a function written in your favourite language (there are many to choose from), and run on AWS’s Lambda service. It’s a very simple take on getting your code and putting it in the cloud.

Pricing

When you run a Lambda it theoretically costs money. In practice, the tinkering we do in this article will probably cost you nothing, or a minuscule amount.

It’s tiny money time.

At the time of writing (October 2018), Lambdas cost $0.0000002 per request (ie: per function call), and $0.00001667 per GB-Second (ie: per second that a 1 GB Lambda runs for).

Below, we’ll be making a Lambda that we’ll configure to use 1GB of memory (overkill, but compute power is scaled to this, so it tends to be a good size), and running it could conceivably take a couple of seconds. Let’s say the average run time is 1 second for ease of calculation.

interestingly, the run time cost is almost 100 times higher than the per-request cost. This means you shouldn’t worry too much about how many calls are made to your lambdas, but you should worry about the total run time of your lambdas.

You’ll most likely call this function around 10 times if you’re really keen. So the cost of this will be trivial.

But even better, Amazon gives you 1 million Lambda requests per month for free, and 400,000 GB-Seconds of run time per month for free (which is a 1 GB Lambda running continuously for 4.6 days). That means you should be able to do everything in this article for free, whether or not you use a free account.

So either free, or probably far less than 1 cent. See if you can stretch the budget to this somehow, and we’ll proceed.

notice that you don’t have to provision any resources ahead of time, and you’re not paying anything to just have your lambdas deployed and ready to be used. If they’re never used, you’re never billed.

The Easiest Way: Directly in the Console

Note: You’ll see at the top right I’m using the N. Virginia region. AWS splits almost everything into regions; your Lambdas always exist in the specific region that you choose. If you don’t know about regions, or don’t care, then it’s a good idea to just always choose N. Virginia. If you don’t know and do care, go have a read about regions. If you both know and care, then hey, you do you.

Let’s create a function (ie: a Lambda). Click the big orange button at the top right.

You’ll see this:

First, we can choose from Author from scratch, Blueprints, and AWS Serverless Application Repository. We’ll choose Author from scratch because we are super hard core.

you could explore the other options later, particularly if you feel that writing code is really a bit too hard.

If you’re some kind of dark master of AWS IAM, you’ll know what this is. Do your thing, and jump past this bit.

Otherwise, let’s talk about Roles.

To help you understand roles, I want you to think about AWS not as a simple service that you are using in your browser, but as a terrifyingly overcomplicated universe of its own, with complex networking and security and provisioning metaphors, carefully constructed in all its bewildering magnificence to plunge simple developers into a deep pit of despair at ever accomplishing anything.

gah!

Ok. Are you upset? You should be. Have a little cry now, and we’ll kick on.

Here you go darling

A Role is something you set up in AWS IAM (Identity and Access Management). It lets you specify what someone with the Role can do. It can then be added to user accounts to allow them to interact with bits of AWS, and it can be applied to services to allow them to interact with other bits of AWS.

That seems pretty simple, doesn’t it? Just pretend that’s true! We’ll go set up a role now, and we’ll pretend it is simple, and hopefully we wont stumble into an abyss with spikes and snakes and so forth if you think happy thoughts and don’t look down.

Think of the Bunny of Not Failing at AWS Stuff. Do it now.

Right. In your Lambda, change the Role selection to Create Custom Role. A new browser tab will appear, and ask you for … you know … stuff.

It’s ok, don’t panic. Think of the bunny.

The default values above (create a new IAM Role, with role name lamba_basic_execution) will do nicely.

Don’t click on View Policy Document, you wont like it.

Do click on “Allow”.

Your tab will close, and you will find yourself beside a highway in the desert. Or looking at an irrelevant browser tab, anyway. Hitch a ride back to your original Lambda tab.

It’ll look like this:

Cool! Click “Create Function”.

Alright, that’s good news!

Now, that message seems to say you’ve created a function, but you haven’t written any code?

What you’ve actually created is what AWS calls a function, but everyone else calls a Lambda. The Lambda is the thing (abstraction? too abstract) that hosts your python function and includes metadata for running it and so forth.

First you’ll see this Designer thing. This is boring. It shows you what is set up to trigger your Lambda, and what your Lambda can do. You can see that nothing is set up to trigger your Lambda, and it can write to CloudWatch Logs (ie: Amazon’s logging). We’ll care about this later maybe, but just now, meh.

Let’s add some code, that’s fun.

It’s already done. Aw man…

Hmm, well we can make it a little more interesting. Let’s change it to the following:

This code gets a name from event (the main input to the function, a dictionary) and returns a string using that name.

context is some environmental stuff which we can usually ignore

So let’s run the function!

Scroll back up to the top, press “Save” if you need to (at top right), then hit “Test”. You’ll see this:

A Test Event is really a saved test that you can run by hitting Test. Fill it out as follows…

… and hit Create.

Hey, did you notice that the big text box is a dictionary with name=fred? This will be the value of event when your Lambda is run.

You’ll be back to your Lambda. At the top right, choose your new fred test event, then hit Test. You’ll see it think a bit (running), then you’ll see a green box (yay! green!) saying Execution result: succeeded. Click on details and you’ll see this:

See the Hello Fred! result? That’s the output of your Lambda. And, you get a lot of other fun information.

Try running the test a few times, get a feel for how long it takes to run. You’ll notice that it’s pretty immediate every time you run it after the first. The first time it had to do a cold start, which involves allocating a new context (container) to the lambda and putting your code on it. Subsequent runs could reuse that context (warm start). If you leave it for a while (maybe 30 mins?) you should see another cold start.

Anyway, that’s it

It’s as simple as that. Go to the console, make a Lambda, add some code, run it with the Test button.

You can just leave the Lambda there; it’s not callable outside your account. That is, no one else can call it and spend your money.

There’s so much I haven’t covered: deploying without using the console, getting Python libraries in there, actually using the Lambda to do something useful.