If you’ve researched serverless architecture, you’ve read the warnings. Cold starts add latency. Functions have hard execution and memory limits. Debugging is harder. And vendor lock-in traps you on one cloud. These critiques usually end with a list of workloads where serverless is supposedly a bad fit: long-running jobs, high-performance computing, and regulated systems governed by HIPAA, PCI DSS, or GDPR.
Most of that analysis is aimed at general-purpose serverless functions — where you rewrite your whole application as ephemeral Lambda handlers. It doesn’t map cleanly onto a purpose-built, serverless, edge-deployed API gateway. A gateway has a narrow, well-defined job: authenticate, rate limit, transform, and route requests. That workload profile changes which “limitations” actually apply.
This article walks through each common objection to serverless, explains why most of them don’t hold for an edge-native gateway, and — because being honest matters more than winning an argument — points out the cases where the concern is real and a different deployment model is the right call.
The Serverless “Limitations” Story
The standard case against serverless goes something like this:
- Cold starts: When a function hasn’t run recently, the platform has to spin up a new execution environment before it can handle the request, adding latency. Heavier runtimes are worse — Datadog’s research found Java functions cold-start nearly three times as long as Python functions.
- Execution and resource limits: Serverless functions cap out. AWS Lambda has a 15-minute maximum execution time, Google Cloud Functions limits compressed source deployments to 100MB, and Azure Functions constrain memory per plan.
- Debugging and observability: Ephemeral, distributed functions are harder to inspect than a long-lived server you can attach a debugger to.
- Vendor lock-in: Proprietary function APIs, triggers, and tooling make migrating between clouds painful.
These are legitimate concerns for the workloads they describe. The mistake is assuming they transfer automatically to every serverless system — including an API gateway. They don’t. Let’s take them one at a time.
Myth 1: Cold Starts Make Serverless Gateways Slow
The cold-start critique is built around container- and VM-based function runtimes that boot a language environment (sometimes a whole JVM) before your code runs. That startup cost is what Datadog measured.
Edge-native gateways don’t work that way. Instead of containers, they run on lightweight V8 isolates — the same isolation primitive that lets a browser tab run untrusted JavaScript. Isolates share a single, already-running engine and spin up in microseconds rather than seconds, so the multi-hundred-millisecond cold-start penalty that dominates the container discussion largely disappears.
Just as important, the gateway runs at 300+ edge locations close to your users rather than in one distant cloud region. A traditional region-locked gateway can add 50–300ms of pure network latency for a user on the other side of the world before it does any work at all. An edge-native gateway processes authentication, rate limiting, and validation within milliseconds of the user. In practice, that means gateway operations complete within roughly 50ms for most users worldwide.
So the “serverless is slow because of cold starts” objection inverts for an edge gateway: the architecture is both warmer (microsecond isolate startup) and closer (edge distribution) than the region-bound alternative it’s being compared to. For a deeper look at why proximity matters, see our guide to edge computing for API performance.
Myth 2: Execution and Size Limits Break Gateway Workloads
The 15-minute execution cap and package-size limits are real constraints — for applications that need them. A batch job crunching a large dataset, a video transcode, or a long-running ETL pipeline can absolutely bump into those ceilings.
But that’s not what an API gateway does. A gateway’s job is to handle a request and return a response in milliseconds. Authentication, JWT verification, schema validation, header transformation, and routing are all short-lived operations measured in single-digit-to-tens of milliseconds. A gateway that took 15 minutes to process a request would be broken regardless of how it was hosted.
In other words, the execution-limit objection is a category error when applied to a gateway. The workloads that actually hit those limits — long-running, compute-heavy batch processing — were never a gateway’s responsibility in the first place. They belong on your backend, and the gateway’s role is simply to route to them.
Myth 3: Serverless Locks You Into One Cloud
This is the objection worth taking most seriously, because lock-in is a genuine risk — but the direction of the risk is often backwards from how it’s framed.
When people say “serverless means vendor lock-in,” they usually mean function-level lock-in: your code is written against one provider’s proprietary runtime, triggers, and event formats, so moving to another cloud means a rewrite.
An API gateway sits at a different layer. A cloud-neutral edge gateway is designed to front backends regardless of where they run — AWS, Azure, GCP, a VPS, or on-prem. Your routing config, policies, and custom logic live in the gateway, not welded to a single cloud’s function service. That’s the opposite of lock-in: the gateway becomes the portable abstraction layer that lets you move, split, or multi-home your backends without rewriting your API surface.
There’s a second angle here. A self-hosted or single-cloud gateway ties your API management layer to whatever infrastructure you chose to run it on. If you later need to operate across clouds, you inherit that coupling. A managed, cloud-neutral edge gateway avoids pinning your control layer to any one provider in the first place. For teams whose whole strategy is avoiding a single point of dependency, see our overview of hosted API gateway advantages.
Regulated and Compliance-Sensitive Workloads
The strongest version of the anti-serverless argument is about compliance: if you’re subject to HIPAA, PCI DSS, or GDPR, can you really run on a multi-tenant, geographically-distributed edge platform where you don’t control where a given request is processed?
This is a fair question, and the honest answer is: it depends on your requirements, and a good platform gives you more than one deployment model to meet them.
What the default edge model provides
Zuplo’s managed edge deployment is SOC 2 Type II audited annually, processes data in line with GDPR expectations, and provides audit logs across the control plane. Third-party penetration test results are available under NDA. For a large share of security reviews, that posture is sufficient.
When you need to control where data lives
The genuine tension with a pure edge model is data residency. By default, edge routing sends each request to the nearest point of presence, which means you don’t pin processing to a specific country. For organizations where that’s a hard requirement, Zuplo offers Managed Dedicated: single-tenant instances deployed to the cloud provider and regions you choose — AWS, Azure, GCP, Akamai, Equinix, and others — with support for private networking and custom isolation.
Dedicated deployment lets you pin processing to a specific geography to satisfy data-sovereignty rules, use private connectivity instead of the public internet, and run an isolated instance for regulatory reasons — while keeping the same gateway, policies, and developer workflow.
A quick note on terminology: being SOC 2 Type II audited is not the same as being “HIPAA certified” or “PCI certified” (there is no such thing as a HIPAA certification, and PCI compliance is scoped to your whole cardholder-data environment, not a single vendor). What a flexible deployment model gives you is the control to keep regulated data where your compliance program requires it. Confirm specifics with the current trust documentation and your own auditors.
When Self-Hosting Genuinely Matters
Sometimes “process it near the user” isn’t good enough — the data legally or contractually cannot leave your infrastructure at all. Air-gapped environments, strict data-sovereignty mandates, and integration with private internal systems all point toward keeping traffic entirely in your own network.
This is a real limitation of any pure managed-edge model, and it’s worth being upfront about. It’s also solvable. Zuplo’s self-hosted deployment runs the gateway on your own Kubernetes cluster via a single Helm chart. In the standard hybrid setup, all API traffic stays within your infrastructure while a small set of Zuplo cloud services handles supporting functions like deployment configuration; accommodations exist for strict egress-restricted environments on request.
The trade-off is real and cuts both ways: self-hosting gives you maximum control and data locality, but you take on Kubernetes operations, cluster upgrades, and capacity planning — the very operational burden that managed edge removes. That’s a deliberate choice, not a limitation to paper over.
A Decision Framework: Match the Deployment Model to the Workload
Rather than asking “is serverless good or bad,” ask which deployment model fits the workload in front of you.
Choose managed edge when you’re serving a global or public API, latency matters, and your compliance requirements are satisfied by SOC 2 Type II and GDPR-aligned processing. This is the default for a reason: no infrastructure to run, automatic global scale, and the lowest latency for distributed users.
Choose managed dedicated when you have data-residency or region-pinning requirements, need a specific cloud provider or private networking, or your security review demands a single-tenant, isolated instance. You get most of the managed experience with control over where it runs.
Choose self-hosted when data legally cannot leave your infrastructure, you’re operating in an air-gapped or heavily egress-restricted environment, or you need to integrate deeply with private internal systems. You accept the operational overhead in exchange for total control.
Keep it off the gateway entirely when the work is genuinely long-running or compute-heavy — batch ETL, media processing, model training. That’s backend work. The gateway’s job is to authenticate and route to it, not to run it.
The point is that “serverless has limitations” is only useful advice if you match the limitation to the workload. For a gateway, cold starts and execution caps are mostly non-issues; lock-in inverts into portability; and the one legitimate constraint — data residency — is addressed by choosing the right deployment tier. If you’re still deciding, our guide to choosing an API gateway walks through the broader evaluation.
Wrapping Up
The generic serverless-limitations narrative was written about general-purpose functions, and it’s largely accurate for those. But an edge-native API gateway is a different animal: microsecond isolate startup instead of container cold starts, millisecond request handling instead of long-running jobs, and a cloud-neutral position that reduces lock-in rather than creating it. The one concern that does carry over — controlling where regulated data is processed — is exactly what dedicated and self-hosted deployment options exist to solve.
Ready to see it for yourself? Sign up for Zuplo and deploy an API to 300+ edge locations in minutes, or read the hosting options overview to compare managed edge, dedicated, and self-hosted deployments for your workload.