Introducing AWS Lambda

Andreas Wittig – 12 Feb 2018

You don’t need a virtual machine to run your own source code any more as AWS Lambda offers execution environments for Java, JavaScript (Node.js), C#, Go, and Python. All you need to do is to implement a function, upload your source code and configure the execution environment. Afterwards, your source code is executed within a fully-managed computing environment. Your new tool enables you to automate operations tasks within your infrastructure with ease. This is because AWS Lambda is well-integrated with all parts of AWS. We use AWS to automate our infrastructure regularly. For example, to add and remove instances to a container cluster, based on a custom algorithm, or to process and analyze log files.

Introducing AWS Lambda

AWS Lambda offers a maintenance-free and highly-available computing environment. You no longer need to install security updates, replace failed virtual machines, or manage remote access (SSH or RDP) for administrators. On top of that, AWS Lambda isn’t billed by the second but per execution. Therefore, you don’t need to pay for idling resources which are waiting for work (e.g. a task triggered once a day).

AWS Lambda is a powerful tool in different scenarios: a REST API for a web or mobile application, an event-driven system to process data, or even an IoT backend. We are also big fans of using AWS Lambda to automate operational tasks within our cloud infrastructure. For example, using a Lambda function to perform periodic health checks of a website. Or to add tags to newly launched EC2 instances automatically.

But what is AWS Lambda? We’ll start with a short introduction.

This article, excerpted from chapter 7 of Amazon Web Services in Action, Second Edition, is about adding a new tool to your toolbox. The tool we’re talking about is as flexible as a Swiss army knife, and it’s called AWS Lambda.

Amazon Web Services in Action, Second Edition

Save 37% off [Amazon Web Services in Action, Second Edition]( with code `fccwittig` at [](

Executing your code with AWS Lambda

Compute capacity is available at different layers of abstraction on AWS: virtual machines, containers, and functions. Containers offer another layer of abstraction on top of virtual machines. Unfortunately, we don’t cover containers in this article. AWS Lambda provides computing power as well but in a fine-granular manner: an execution environment for small functions, not a full-blown operating system or container.

What is Serverless?

When reading about AWS Lambda you might have stumbled upon the term serverless already. The following quote summarizes the confusion created by a catchy and provocative phrase:

[… ] the word serverless is a bit of a misnomer. Whether you use a computer service such as AWS Lambda to execute your code, or interact with an API, there are still servers running in the background. The difference is that these servers are hidden from you. No infrastructure exists for you to think about and there’s no way to tweak the underlying operating system. Someone else takes care of the nitty-gritty details of infrastructure management, freeing your time for other things.
Peter Sbarski, Serverless Architectures on AWS, Manning (2017)

We define the following the following criteria for a serverless system:

  • No need to manage and maintain virtual machines.
  • Fully managed service offering scalability and high availability.
  • Billed per request and its resource consumption.

AWS isn’t the only provider offering a serverless platform. Google (Cloud Functions) and Microsoft (Azure Functions) are competing with AWS in this area, for example.

Looking for a new challenge?


    Senior Lead Full Stack Developer

    DEMICON • AWS Advanced Consulting Partner • Remote (Europe)
    AWS JavaScript/TypeScript Angular React
  • tecRacer

    Cloud Consultant • Machine Learning & Data Analytics

    tecRacer • Premier AWS Consulting Partner • Germany, Austria, Portugal, and Switzerland
    SageMaker Airflow Athena Redshift

Running your code on AWS Lambda

As shown in the following figure, to execute your code with AWS Lambda the following four steps are needed:

  1. Writing the source code.
  2. Uploading your code and its dependencies (e.g. libraries or modules).
  3. Creating a function determining the runtime environment and configuration.
  4. Executing the function.

Running your code on AWS Lambda

You don’t need to launch any virtual machines. AWS executes your code in a fully-managed compute environment.

Currently, AWS Lambda offers runtime environments for the following languages:

  • Java
  • JavaScript (Node.js)
  • C#
  • Go
  • Python

Next, you’ll learn more about AWS Lambda by comparing its concepts with virtual machines offered by EC2.

Comparing AWS Lambda with virtual machines (Amazon EC2)

What’s the difference between AWS Lambda and virtual machines? First off, the granularity of virtualization. On the one hand, a virtual machine provides a full operating system which is used to run one or multiple applications. On the other hand, AWS Lambda offers an execution environment for a function, a small part of an application.

Furthermore, Amazon EC2 offers virtual machines as a service. But you’re still responsible for operating these virtual machines in a secure, scalable and highly available way. Doing this generates a bunch of operating tasks resulting in substantial maintenance effort. By contrast, AWS Lambda offers a fully-managed execution environment. AWS is managing the underlying infrastructure for you and provides a production-ready infrastructure to you.

Otherwise AWS Lambda is billed per execution, not per second that a virtual machine is running. You don’t need to pay for unused resource waiting for requests or tasks any longer. For example, running a script to check the health of a website every five minutes on a virtual machine costs you a minimum of USD 4. Executing the same health check with AWS Lambda is free as you don’t even exceed the never-ending monthly free tier.

The following table compares AWS Lambda and virtual machines in detail.

AWS Lambda Amazon EC2
Granularity of virtualization Small piece of source code aka function. A whole operating system.
Scalability Scales automatically. Throttling limit prevents you from creating unwanted costs accidentally and can be increased by AWS support if needed. Auto Scaling Group allows you to scale the number of EC2 instances serving requests automatically. But configuring and monitoring the scaling activities are your responsibility.
High Availability Fault tolerant by default. Compute infrastructure spans multiple machines and data centers. A virtual machine isn't highly available by default. Nevertheless it's possible to setup a highly available infrastructure based on EC2 instances as well.
Maintenance effort Almost zero. You need to configure your function. You're responsible for maintaining all layers between the operating system of your virtual machine and the runtime environment of your application.
Deployment effort Almost zero due to a well-defined API. Rolling out your application among a fleet of virtual machines is a challenge requiring tools and know-how.
Pricing model Pay per request as well as execution time and memory. Pay for operating hours of virtual machine billed per second.

Learn more

Do you want to learn more? Check out chapter 7 of our book Amazon Web Services in Action, Second Edition including two real-world examples: website health check and automatically tagging a newly launched EC2 instance with it’s owner.

Also, this slide deck introduces the rest our our book in more detail.

Become a cloudonaut supporter

Andreas Wittig

Andreas Wittig ( Email Twitter LinkedIn Mastodon )

We launched the cloudonaut blog in 2015. Since then, we have published 366 articles, 60 podcast episodes, and 58 videos. It's all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.

Please support us

Have you learned something new by reading, listening, or watching our content? With your help, we can spend enough time to keep publishing great content in the future. Learn more

Amount must be a multriply of 5. E.g, 5, 10, 15.

Thanks to Alan Leech, Alex DeBrie, ANTHONY RAITI, Christopher Hipwell, e9e4e5f0faef, Jason Yorty, Jeff Finley, jhoadley, Johannes Grumböck, Johannes Konings, John Culkin, Jonas Mellquist, Jonathan Deamer, Juraj Martinka, Ken Snyder, Markus Ellers, Oriol Rodriguez, Ross Mohan, Ross Mohan, sam onaga, Satyendra Sharma, Simon Devlin, Thorsten Hoeger, Todd Valentine, Victor Grenu, waldensystems, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt.