When to use API Gateway vs. Lambda Function URLs

Don’t reinvent the patterns. Catalyst gives you consistent APIs for messaging, data, and workflow with key microservice patterns like circuit-breakers and retries for free.

Try the Catalyst beta

“Lambdalith” is a monolithic approach to building serverless applications in which a single Lambda function serves an entire API instead of having one function per endpoint. It’s an increasingly popular approach with API Gateway and Lambda Function URLs.

It provides portability between Lambda functions and container applications. You can lift and shift an existing application into Lambda without rewriting it. You can use web frameworks you already knkow and lean on the existing ecosystems of tools, ORMs and middleware. It also makes testing easier because you can apply familiar testing methodologies.

Tools like the AWS Lambda Web Adapter [1] have made this approach more accessible. This approach also works well with Lambda Function URLs (read this post [2] first if you don’t know how it works).

Which brings up a good question.

“In 2024, if you want to build a REST API using serverless technologies. Should you use Lambda Function URLs or API Gateway?”

Here are some trade-offs you should consider when making this decision.

Lambda Function URLs pros

It works naturally with Lambdaliths.
No latency overhead from API Gateway.
No API Gateway-related costs.
It supports response streaming [3]. This is useful for returning large payloads in the HTTP response.
There are fewer things to configure.
Your API can run for up to 15 mins.

Lambda Function URLs cons

You have to use Lambdaliths and deal with all the shortcomings that come with that.
There are no per-endpoint metrics. However, this can be compensated by implementing custom metrics with embedded metric format (EMF) [4].
There is no direct integration with WAF. However, this is still possible through CloudFront, and you can use CloudFront OAC to ensure users can only access your API through the CloudFront URL [8]. However, there are some caveats around PUT and POST methods (see this post [9] by David Behroozi)
It only supports AWS_IAM auth.
You cannot configure different auth methods per endpoint.

Where Function URLs make sense

Function URLs make perfect sense if you want to build a Lambdalith (i.e. not forced into it by the choice to use Function URLs), and you don’t need the additional features that API Gateway offers. It’s cheaper, faster and has fewer moving parts.

Similarly, if you need to return a large payload (> 10MB) or to run for more than 29s, then Function URLs can also make sense. That is if you can’t refactor the client-server interaction. It’s possible to raise the 29s limit with API Gateway REST APIs [10] nowadays, but it’s unclear how far you can raise it. It might also require reducing your account-level throttle quota limit, reducing the maximum throughput across API Gateway APIs.

Given the limited support for authentication & authorization, it’s less suitable for user-facing APIs. These APIs often require a Cognito authorizer or a custom Lambda authorizer. It’s possible to verify Cognito tokens [11] in the Lambda function with minimal performance impact [12]. But you leave yourself open to denial-of-wallet attacks with invalid tokens. When API Gateway rejects an unauthorized request, you don’t pay for the request.

This leaves function URLs as best suited for public APIs or internal APIs inside a microservices architecture.

By “internal API”, I refer to APIs that are used by other services but not by the frontend application directly. These APIs usually require AWS_IAM auth because the caller is another AWS resource – a Lambda function, an EC2 instance, an ECS task, etc.

API Gateway pros

It’s more flexible. It works with both Lambdaliths and the one function per endpoint approach.
It has direct integration with most AWS services. So in many cases, you don’t even need a Lambda function. If you’re curious about when and why you should consider this, check out this video [5] where I explain the rationale behind service proxies.
It can proxy requests to any HTTP APIs. This is very useful for integrating with 3rd party APIs.
It offers lots more features, including (but limited to) the following:

- cognito authorizer
- usage plans (great for SAAS applications that offer tiered pricing)
- built-in request validation with request models
- detailed per-endpoint metrics
- mock endpoints (useful for endpoints that return static data)
- request and response transformation (also useful for integrating with 3rd party APIs)
- WebSockets support
- and lots more…

API Gateway cons

Additional latency overhead.
Additional cost.
No response streaming.
29s integration limit. It’s possible to raise this limit, but it’s unclear how far you can raise it, and it might also require reducing your account-level throttle quota limit.
10MB response limit.

When API Gateway makes sense

Given the vast array of features that API Gateway offers, it makes sense in most cases if you’re OK with the additional cost associated with the convenience.

The 29s and 10MB response limits can be problematic in some cases.

But they can be mitigated with patterns such as Decoupled Invocations [6] and S3 presigned URLs [7]. However, these workarounds require you to refactor the client-server interaction, so they are not always viable.

Summary

Because of its flexibility, I prefer API Gateway over Function URLs or ALBs. But Function URLs is a useful tool, especially when cost and performance are your primary concerns.

It’s also an important lift-and-shift option for people migrating from an existing EC2 or container-based application. It lets them enjoy the benefits of Lambda without rewriting their application.

Finally, as Ben eloquently puts it, this tradeoff represents a deeper choice we often face.

What’s easier at author time might mean more ownership at runtime. For example, we don’t get per-endpoint metrics from function URLs so we have to bring that capability to the table ourselves and be responsible for them.

Something for you to think about ;-)