Pick a workload you already run — resizing uploaded images, checking a JWT before a request reaches your origin, streaming a WebSocket feed to a dashboard. Now ask a blunt question: does it need to be a request that runs somewhere fast, or does it need to be a service that stays alive? That single distinction decides more than any benchmark table. Serverless edge functions and containerized edge services are not competing answers to the same question; they are answers to different ones.
Two execution models, one edge
A serverless edge function is a single-purpose handler deployed to a global network of points of presence. You upload code, the platform routes each request to the nearest node, and an isolated runtime spins up to answer it. Nothing stays warm between requests unless the platform decides to keep it that way. You pay per request and per unit of CPU time consumed. Runtimes are usually JavaScript, TypeScript or WebAssembly, with a deliberately restricted API surface.
A containerized edge service is a real container image — the same one you would run in a regional cluster — scheduled onto edge nodes near users. The process starts, keeps running, and handles as many requests as you send it until you scale it down or it moves. You get a filesystem, native binaries, background threads, persistent connections, and any language you like. You also pay for the running time whether or not traffic shows up.
Everything downstream — latency, cost, architecture — follows from that difference.
Cold starts: the latency you don't control
Edge functions built on lightweight isolates typically start in single-digit to low tens of milliseconds. That is fast enough that most users never notice, and it is the main reason teams move request-shaping logic to the edge in the first place. A redirect rule, a geo-based header, a signed-cookie check: all of it feels local because it is.
Containers are heavier. Booting an image, mounting a filesystem and starting a language runtime usually takes hundreds of milliseconds, sometimes seconds for large images or slow dependency loading. On a busy service this cost is paid once and amortized across thousands of requests. On a service that receives a handful of requests per minute per region, you pay it constantly.
Two practical consequences:
- Spiky traffic punishes containers. Autoscaling to zero looks efficient until every scale-up event hands a slow first request to a real user.
- Long-tail regions punish nothing equally. A function that runs in 300 locations costs you the same per request everywhere. Running containers in 300 locations is an operational problem you probably don't want.
If your service-level objective is measured in tens of milliseconds, and your logic fits in an isolate, serverless is the shorter path. If a 400 ms start on a cold instance is acceptable because the work afterwards takes two seconds anyway, containers are fine.
Cost follows traffic shape, not traffic volume
People often compare these models by asking which is cheaper. The honest answer is that the model should be chosen from the shape of the traffic graph, then the bill follows.
Per-request pricing rewards idle time. If your edge layer sees a steep daily curve — quiet at 04:00, ten times the volume at 18:00 — serverless charges you for the curve, not for the capacity to survive its peak. Containers charge you for capacity, so a service running at 5% utilization most of the day is paying for the other 95%.
Flip the graph. A steady stream of requests, sustained near the capacity you provisioned, is usually cheaper per unit of work on containers, because there is no per-request premium and no repeated startup cost. High-volume fan-out, log ingestion, or anything that moves large payloads through the edge tends to look better containerized.
A useful exercise: take one week of request logs, count requests per minute in the busiest and quietest hours, and divide. If the ratio is above roughly five to one, serverless almost always wins on cost and on operational simplicity. Below two to one, run the numbers properly — you may be paying a premium for elasticity you never use.
Control, state, and the limits of a sandbox
This is where most real projects make their decision, and it rarely has anything to do with price.
Edge function sandboxes give you a narrow, predictable environment. That is a feature. It also means no FFmpeg, no ImageMagick, no native database driver, no custom TLS handling, no writing to disk you can rely on later. If your workload needs a system call the platform hasn't exposed, you are done — no amount of clever engineering recovers it.
Containers at the edge give you the machine. Need to run a queue worker, hold an in-memory cache across requests, or keep a gRPC connection open to a regional database? That is a container-shaped problem. The trade is that you now own upgrades, health checks, log shipping and the question of what happens when a node disappears mid-request.
State deserves particular care. Neither model is a great home for durable data. Design so that edge code is stateless where possible, and reach for platform-provided key-value or durable-object primitives when you genuinely need short-lived coordination. If you find yourself wanting a long-lived in-process cache to make the workload viable, that is a signal to use containers — or to reconsider whether the workload belongs at the edge at all.
A decision checklist
Run your candidate workload through these questions in order. The first one that produces a hard no tells you where the workload belongs.
- Does it fit a supported runtime? If it needs native modules, unusual binaries or a specific OS, choose containers.
- Is it request-shaped? One input, one output, short duration — serverless. Long-running processes, background jobs or streaming — containers.
- Does it need state between requests? Persistent filesystem, sticky sessions or in-memory caching point to containers.
- How spiky is the traffic? Sharp peaks favour serverless; flat, steady load favours containers.
- What is your cold-start budget? Compare it to the startup time you actually measure, not the one in the marketing page.
- How many regions? Dozens or hundreds — serverless. A handful of well-chosen locations — containers are manageable.
Hybrid patterns that hold up in production
Most mature architectures end up using both, and the split is usually the same. Keep authentication checks, redirects, A/B assignment, header manipulation, bot filtering and small personalization decisions in edge functions — they are cheap, they run everywhere, and they protect the origin. Keep the heavy lifting in containerized services behind them: rendering, media processing, search, anything with a database connection pool or a queue.
Two rules keep the split clean. First, never duplicate business logic across the boundary; if the edge needs a rule, it should fetch it from a single source. Second, measure the hop between the two tiers, because a fast function calling a slow service produces a slow response.
Test before you commit
Write the smallest version of the workload twice — once as a function, once as a container — and deploy both to the regions you actually serve. Log start duration, p95 response time and cost per thousand requests for a week. Deliberately test a cold path: deploy to a quiet region and hit it after a long idle period.
That week of real numbers settles the argument faster than any comparison chart, and it tells you something a chart can't: which model your team can operate on a Friday afternoon. Pick the one you can debug at 2 a.m., because that is the constraint that outlives every other.
Photo: geralt / Pixabay
