2018 was a big year for serverless, and 2019 shows no signs of slowing down. For the second year running, serverless was the most talked about topic at re:Invent 2018. AWS continues to innovate on the serverless front, and the AWS Lambda platform is constantly getting stronger.

In this article, we’ll discuss the differences between serverless and Function-as-a-Service (FaaS) and why serverless is more than just functions. We’ll also look at a few examples of fully serverless applications that don’t require functions.

Serverless !== FaaS

The terms “serverless” and “FaaS” are often used interchangeably. But for the purpose of this post, let’s make a clear distinction between the two.


After much debate, the serverless community seems to have finally reached a consensus that technology should be considered “serverless” if:

  • It’s pay-per-use.
  • Developers don’t need to worry about scaling the number of servers.
  • Developers don’t need to worry about managing and provisioning the servers (i.e., configuring machine images, applying OS patches, etc.)

FaaS, on the other hand, describes technologies that enable a new programming paradigm (in which applications are constructed out of small), independently deployable functions. This is where managed services such as AWS Lambda, Azure Functions, and Google Cloud Functions come into play. Other services, such as Google Knative and Kubeless (which allows developers to deploy functions onto their Kubernetes cluster) can also be considered as FaaS.

Compared to the other as-a-service paradigms out there — Infrastructure-as-a-Service (IaaS), Container-as-a-Service (CaaS), and Platform-as-a-Service (PaaS) — FaaS is the closest to PaaS. In both FaaS and PaaS models, cloud providers are responsible for everything up to the language runtime. FaaS and PaaS differ though in their unit of deployment and scaling.

With PaaS, developers deploy applications, and the provider scales the number of running instances of those applications based on load. With FaaS, the unit of deployment and scaling are the individual functions that make up the application.

FaaS and PaaS are very similar. The main difference is the unit of scaling.

Using these definitions, storage services (e.g., Amazon S3) or BI services (e.g., Google BigQuery), should also be considered serverless. In both cases, you are charged based on usage, and the services automatically scale the number of underlying servers to meet your needs. Managed FaaS solutions, such as AWS Lambda, would also fall into this category.

FaaS but Not Serverless

However, other FaaS solutions, such as Knative and Kubeless, should not be considered serverless because:

  • Developers have to pay for the Kubernetes cluster, even when no one is using it.
  • Developers are responsible for scaling the Kubernetes cluster itself, even if the functions are scaled automatically in the cluster.
  • Developers are responsible for managing and provisioning the nodes in the Kubernetes cluster, including patching the host OS.

FaaS is, therefore, not a subset of serverless. Instead, they are two closely related paradigms that have a large overlap.

Serverless and FaaS are two closely related paradigms with large overlaps, but they should not be considered interchangeable.

Going Full Serverless

AWS Lambda is by far the most well-known example of serverless technologies. However, there are plenty of things you can do with “other” serverless technologies without a Lambda function.

Here are a few common examples for you to consider:

Static Site Hosting

Simple Storage Service, or S3, was the first service on AWS, shortly followed by SQS. S3 was initially designed as a simple storage service (hence the name!), but many capabilities have been added to the service over the years — object lifecycle managementintelligent tieringbatch operations, and many more.

Way back in 2011, S3 announced the ability to host static sites. A common setup to host static sites would involve several AWS services:

  • S3 hosts the contents of the site. Once configured, you will have an endpoint for your site such as http://examplebucket.s3-website-us-west-2.amazonaws.com
  • CloudFront provides CDN and edge caching for the site. You can also register a custom domain name (e.g. example.com) for the CloudFront distribution.
  • Route 53 manages the DNS record for your custom domain name and makes sure requests to example.com are routed to your site hosted in S3.

All of these services are serverless and show how you can build a globally distributed, static website without managing any infrastructure or running Lambda functions!


You can also create REST APIs without functions. API Gateway and Lambda are often used together to build REST APIs, but API Gateway can also plug directly into other AWS services.

For example, this article from Alex Debrie demonstrates how to connect API Gateway to SNS without going through a Lambda function. API Gateway lets you transform the request and response to and from the origin. In this way, it can be used to integrate with any service that exposes an HTTP interface. You can then implement cross-cutting concerns such as authentication, caching, and rate-limiting at the API Gateway layer.

Also, AWS recently announced WAF support for API Gateway, which further enhances the capabilities you can leverage from the service.


GraphQL has been gaining traction over the last few years.

Source: Google Trends

It’s a powerful way to build applications quickly, as it gives front-end engineers a lot of autonomy. They can work with data however they like and be able to iterate independently and quickly. GraphQL makes it easy to consume data from different back-end services using a unified query language and front-end engineers no longer have to wait for the service teams to make changes for them.

AWS offers GraphQL as a service through AppSync. Out of the box, AppSync integrates with DynamoDB and Amazon Elasticsearch. So if you have data in DynamoDB tables, then you can surface them through AppSync without needing to use Lambda functions. And this gives you a serverless GraphQL API without functions!

Where needed, you can also further extend the integration options through Lambda. For example, at the time of this writing, AppSync does not integrate directly with RDS. So you will need to use a Lambda function to resolve RDS resources for AppSync.

Analytics Pipeline

As we discussed in an earlier post, we can build an entire analytics pipeline using only serverless technologies (Lambda included).

However, the Lambda function in the original post is only required to perform a transformation on the events in Kinesis. It’s not required for the pipeline itself. In fact, if you control the incoming events into the Kinesis stream, then the events are likely already in the format you intend to work with. In this case, you just need the following:

  • Kinesis Stream as the sink to collect all analytics events.
  • Kinesis Firehose to collate events from the Kinesis Stream and write them to S3 in batches.
  • S3 as the data lake.
  • AWS Glue to analyze the schema of the data in S3 and catalog them as tables for Athena.
  • Athena as the query engine that performs ad-hoc queries against the data in S3.
  • QuickSight to visualize the result of Athena queries on a dashboard.


So there you have it. In this post, we defined what we mean by serverless:

  • It’s pay-per-use.
  • Developers don’t need to worry about scaling the number of servers.
  • Developers don’t need to worry about managing and provisioning the servers.

We explained how the term “serverless” differs from Function-as-a-Service (FaaS). While many FaaS platforms are serverless, serverless itself is much more than just functions. Serverless incorporates storage services, databases, queues, and many other services where you don’t have to worry about the “servers” yourself and don’t pay for uptime.

We also looked at a number of common use cases that can be implemented in a serverless way without even needing to use Lambda functions!

  • Static site hosting.
  • REST APIs.
  • GraphQL APIs.
  • Analytics pipelines.

Check out these related articles on AWS serverless services:

AWS CloudWatch Metrics and Dashboards (Part 3)

The Importance and Impact of APIs in Serverless

The Hitchhiker’s Guide to Serverless

How to Effectively Monitor AWS Lambda

The Right Way to Distribute Messages in Serverless Applications