AWS Public Sector Blog

Nonprofits save time and money with AWS Lambda: How to set up a function

Nonprofits face many of the same challenges as for-profit organizations with tighter budgets and fewer full time staff. Solutions that support a nonprofit to focus on its core mission while spending less money and time on IT infrastructure help to further core goals. To accomplish these goals, you can use AWS Lambda to power compute needs. Read on to discover how AWS Lambda can reduce IT management burden and walk through an example Lambda function that can help nonprofits cut down their Amazon Web Services (AWS) spend.

What is Lambda?

Lambda is a compute service that lets you run code without provisioning or managing servers. It can scale continuously based on usage (within limits you can define), allowing your application to scale from zero users to thousands of concurrent users, with Lambda service managing the resources for you. That way, if your application goes viral, Lambda can automatically scale up with you so you don’t lose out on potential users or donors. With AWS Lambda, you pay only when your code is invoked, and the cost depends on how long that invocation lasts—down to millisecond granularity—so you’re never paying for over-provisioned infrastructure, which allows your limited IT budget to go further.

It’s vital for nonprofits to get as much out of their IT dollars as possible, since they often have limited budgets and every dollar they save on their IT costs can be redirected toward their primary mission. Lambda has a free tier that provides one million no-cost invocations, or times the Lambda function code is run, per month. This also includes 400,000 GB-seconds, or amount of time the function is running adjusted for the specific memory configuration of the Lambda function, of compute time per month. The free tier allows a nonprofit to get started with Lambda, and even run significant workloads, without paying for compute. Additionally, if you build a tool or service on Lambda but don’t end up using it, you don’t pay for idle compute.

Costs on Lambda are tied very closely to usage. It’s very common for a new project or initiative to not have much funding until it can prove its value. With Lambda, the initial costs of compute can be very low, making it simple to launch projects on a tight budget. And if a new tool you build on Lambda becomes popular or otherwise successful, you can take advantage of Savings Plans to further optimize your costs.

Lambda is a fully managed service, meaning there are no servers that need to be provisioned, managed, scaled, or patched. AWS takes care of that for you. It’s also serverless, meaning you don’t have to think in terms of how many servers you need to run each day for this project. You can focus on how many people need to use this at once, a much simpler metric to estimate. Also, you only pay when your function is actually in use. When your Lambda function is triggered, the service loads your code onto compute hardware in an isolated environment, executes the code, and then spins down, unless your function is triggered again. This allows AWS to take on the undifferentiated heavy lifting of patching and managing servers to power the compute component of your application. Then, nonprofit IT teams can spend more of their limited budget and time on the unique work they do.

“Coupled with the AWS Promotional Credit from the AWS Nonprofit Credit Program, going serverless gave us the confidence that we could scale our product to meet any foreseeable growth while keeping our funds focused where they should be: on our community and users,” said Adam Bard, founder of

Lambda also makes it simpler to get started with new ideas quickly and increase the pace of innovation. Since Lambda allows you to write code, upload it to the service, and immediately start running it, nonprofits can rapidly move from the brainstorming phase to a prototype to a production version of a new idea or system that will assist in mission achievement.

Example of Lambda function setup

Many nonprofits use Amazon Elastic Compute Cloud (Amazon EC2) for compute in their AWS environments, often with a production instance that needs to be running 24/7 and a developer instance that only needs to be running during business hours. Even so, development servers can often be left on, incurring additional, unnecessary costs. You can use a scheduled Lambda function to automatically shut off development servers at a fixed time every day. These development servers can then be brought back up the next day or whenever needed.

Select the Launch Stack button to set up your environment using AWS CloudFormation.



The AWS CloudFormation stack uses an AWS Serverless Application Model (AWS SAM) template. It launches a few key components: the Lambda function, two AWS Identity and Access Management (IAM) policies, and an IAM role. The IAM policies are attached to the role, which is attached to the function, giving it permission to access the methods of the Amazon EC2 API that are needed for the function to properly execute. The AWS Lambda function—called ShutdownInstances—has a python script for the function defined inline. When the function is triggered, the function’s handler:

  1. Retrieves a list of the Amazon EC2 instances running in your account and Region
  2. Iterates over the list to match tags and generate a list of instances to shutdown
  3. Returns the list (with or without executing the shutdowns, depending on the DRY_RUN environmental variable)

The DRY_RUN environmental variable allows you to test the function without shutting down instances. You can change it to true in the AWS Lambda Console by editing the environmental variable to switch the function out of dry run mode. Additionally, this is where you can change the tag that is checked on your Amazon EC2 instances to determine whether they should be shut down. See Figure 1.

Figure 1. Environmental variables in the Lambda console, including the ShutDownStatus argument that corresponds to the tags on the Amazon EC2 instances.

To prevent a particular Amazon EC2 instance from being shutdown by this Lambda function, you can tag it in the Amazon EC2 console with the tag name of ShutDownStatus and value of False. See Figure 2.

Figure 2. The tags section of the Amazon EC2 instance Server that has the ShutDownStatus tag set to False to prevent it from being shutdown by our Lambda function.

The Lambda function, in normal operation, triggers on an EventBridge scheduled rule. It’s disabled by default, as a safety measure for experimenting with this function. But you can enable it from the Lambda console. The schedule triggers the Lambda function at 5:30 PM everyday (PDT). You can edit this by changing the Schedule property (a cron expression) under Events in the ShutdownInstances resource.

Waiting on the schedule is inconvenient for testing, though, so we use the Lambda console built-in testing function. In the Lambda console, you can create a test event and pass a JSON payload to the function with simulated data. We can pass an empty JSON document since the Lambda function needs no additional data to know what instances to shutdown. Using the hello-world template, we can create a test event like the one below. See Figure 3.

Figure 3. The test function panel in the Lambda console with an example test event to invoke the function.

Before we click the big orange Test button, we can look at the Amazon EC2 instances running in the account. See Figure 4.

Figure 4. Currently running Amazon EC2 instances.

This is a selection of instances, with 32 instances running in the account and only one, labeled Server at the top, has the ShutDownStatus: False tag on it. After clicking the Test button, the other 31 instances will shut down. See Figure 5.

Figure 5. The instances stopped and still running after invoking the function.

Now, you can see that the instances, other than Server, are either Stopped or Stopping so you are no longer paying hourly for their usage but still can be restarted whenever needed.

Getting started with Lambda

Lambda is simple to get started with since it is designed around existing, popular programming languages, such as Python, Node.js, Java, Go, and .Net. This allows your developers to work in a familiar environment while still getting the advantages of Lambda.

The examples in this blog post can be done using Lambda’s free tier. If your workload falls outside of the free tier, you pay only for what you use. Lambda charges based on a combination of the number of requests and the duration of each of those requests. For more information, see the Lambda pricing page.

If you would like to know more, you can reach out to the AWS nonprofits team or learn more about AWS for nonprofits and non-governmental organization (NGOs). For more information on Lambda and tutorials on how to get started, check out our serverless Hello World tutorial or read more about the AWS SAM.

Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox or contact us.