1 Overview
Comparing managed function platforms across two major clouds is less about picking a winner and more about understanding how each one shapes the way you build. After years of running similar workloads on both, the differences that matter rarely show up in a feature checklist. They show up in how quickly you can reason about a failure, how predictable the bill is, and how much of your architecture you end up bending to fit the platform's opinions. Those three pressures tend to surface slowly, often months into a project, and they compound in ways that a quick trial deployment will never reveal.
Both platforms let you deploy a small unit of code that runs in response to an event, scales automatically, and bills by execution time and invocation count. That shared shape makes them feel interchangeable at the start, and for simple workloads they largely are. The divergence appears in the details: how cold starts behave under different runtimes, how concurrency is controlled, how networking is attached, and how much configuration lives outside your code. Those details accumulate into a real operational personality, one that shapes debugging habits, deployment pipelines, and the mental model your team carries from one service to the next.
This article is a practical comparison based on repeated experience rather than benchmarks. It avoids vendor-specific naming because the patterns generalize across providers, and the underlying tradeoffs tend to repeat regardless of which logo sits on the console. The goal is to help you choose a default platform for a given workload, and to know when the choice is close enough that team familiarity should decide it. In practice, that last point resolves more decisions than any performance table ever will.
2 Why this workload pattern matters
Event-driven functions matter because they let a small team operate a surprisingly broad surface area without maintaining servers. A single deployment can serve an API, process background jobs, react to storage changes, and run scheduled tasks. That consolidation reduces the number of moving parts a team must own, which is often the real constraint in small organizations. The operational burden shifts away from patching, scaling, and capacity planning for long-lived hosts and toward the logic of the workload itself. For a team without a dedicated operations function, that shift can be the difference between shipping a feature and postponing it indefinitely, because the same people who write the code are also the ones who would otherwise carry a pager for the infrastructure underneath it.
The pattern also changes the cost conversation. When traffic is spiky or intermittent, paying only for actual execution is a genuine advantage over provisioning capacity that sits idle. When traffic is steady and high, the same model can become more expensive than a reserved instance or a container that stays warm. Knowing which side of that line your workload sits on is more important than any platform-specific optimization. The honest way to answer that question is to look at the shape of your traffic over time, not at a single busy hour, and to accept that the answer may differ between the components of a single system.
There is also a design consequence. Functions push you toward small, stateless units with explicit inputs and outputs. That discipline improves testability and makes it easier to reason about failure boundaries. Teams that embrace it tend to ship faster; teams that fight it by cramming shared state into the runtime tend to accumulate subtle bugs and surprising latency. The platform rewards a particular style of engineering, and the fit between that style and your team matters more than raw feature parity.
3 The architecture in plain terms
At a high level, both platforms work the same way. You package code with a declared entry point and a runtime. An event source invokes that entry point with a payload. The platform finds or creates an execution environment, runs your handler, captures the result or error, and tears the environment down or reuses it for a while. Billing is based on invocations, execution duration, and memory allocation. That basic loop is the shared contract, and it is worth internalizing because everything else is variation on this theme rather than a different model of computing.
The execution environment is the key abstraction. It is not a virtual machine you manage, but it is also not perfectly ephemeral. The platform may reuse a warm environment for subsequent invocations, which is why initialization code placed outside the handler can persist. That reuse is a performance gift and a correctness trap: anything cached in memory may or may not be there on the next call, so handlers must be written to tolerate both cold and warm starts. The practical consequence is that state which matters must live somewhere durable, while state kept in memory is only an optimization that the handler must be prepared to rebuild at any time.
Around that core, each platform layers its own controls. Concurrency limits determine how many invocations run at once. Networking settings determine whether the function can reach private resources. Identity and permission models determine what the function is allowed to touch. These are where the two platforms diverge most, and where migration cost actually lives. The function code is usually portable; the surrounding configuration is not. Understanding this split early keeps expectations realistic, because the effort of moving a workload rarely sits in the handler logic itself but in the wiring that grants it access, scale, and connectivity.
4 Scaling and cost trade-offs
Scaling on both platforms is event-driven and horizontal. As events arrive, the platform adds execution environments up to a concurrency ceiling, then queues or throttles the excess. This is excellent for unpredictable load and dangerous for downstream systems that cannot absorb a sudden burst. A function that scales instantly can overwhelm a database connection pool or a third-party API rate limit just as instantly. The same elasticity that makes the model attractive during quiet periods becomes a liability the moment traffic spikes, because the platform will happily create as many parallel workers as the ceiling allows without any awareness of what sits behind them. The practical consequence is that the scaling control you care about most is rarely the concurrency limit itself, but the backpressure you place between the function and everything it touches.
Cost follows a similar shape. You pay for invocations and for the time each invocation occupies memory. Short, light functions are cheap. Long-running functions with high memory allocations get expensive quickly, and sustained high concurrency can approach or exceed the cost of always-on compute. The break-even point depends on utilization, but the direction is consistent: serverless is a premium for elasticity, and you should only pay that premium when you need the elasticity. Workloads with steady, predictable demand are usually better served by provisioned capacity, while spiky or intermittent workloads are where the model earns its keep. The mistake is treating the pricing model as universally cheaper rather than as a trade of money for responsiveness.
There are secondary cost drivers that surprise people. Data transfer, logging volume, and the cost of the services the function calls often exceed the function bill itself. A function that runs for a few milliseconds but writes verbose logs on every invocation can generate a larger bill than the compute. Watching the whole system, not just the function line item, is the only way to keep costs honest. Attribution matters here: if you cannot trace spend back to the workload that caused it, you cannot tell whether the architecture is efficient or merely quiet.
5 Failure modes and what to watch
The most common failure mode is the timeout. A function that depends on a slow downstream service will fail when that service slows down, and the platform will terminate the invocation at the configured limit. Retries may then amplify the problem by re-invoking the same failing path. Without careful idempotency, retries turn a transient slowdown into duplicated work or corrupted state. The deeper issue is that a timeout is rarely isolated to one invocation. When many callers share the same slow dependency, they tend to fail together, and the retry behavior of each caller compounds the load on the already struggling service. Designing for this means treating timeouts as an expected condition rather than an exception, choosing limits that reflect the real cost of the downstream call, and ensuring that a retried operation produces the same result as a single successful one.
Cold starts are the second recurring issue. When a new execution environment is created, initialization code runs before the handler, adding latency. The effect is worst for runtimes with heavy startup costs and for functions that load large dependencies. The mitigation is to keep initialization minimal, reuse connections where the platform allows it, and avoid pulling large assets at startup. None of these eliminate cold starts; they reduce their impact. It also helps to separate one-time setup from per-invocation work so that the expensive parts happen once and the handler stays lean, and to keep the initialization path free of network calls that can themselves time out.
Concurrency exhaustion is the third. Every platform has a concurrency ceiling, and hitting it causes throttling or queuing. If the function is behind an API, users see errors. If it is processing a queue, messages back up. The fix is usually to set reserved or bounded concurrency so the function cannot consume the entire account's capacity, and to make downstream systems resilient to bursts. Monitoring throttles and queue depth is more useful than monitoring average latency. Average latency hides the shape of the problem, while throttle counts and backlog size show pressure building before users feel it, giving operators time to react.
6 Operating it in practice
Day-to-day operations differ from traditional server work in a subtle way. You spend less time patching and more time tuning configuration. Logs and traces become the primary debugging surface, because you cannot log into a host. That shift rewards teams that invest early in structured logging, correlation identifiers, and distributed tracing. Without them, diagnosing a failure across several functions and services is painful. The reason is that a single request may pass through many short-lived execution contexts, each with its own lifecycle and its own local view of the work. When those contexts emit unstructured text, the operator has to reconstruct the path by hand, guessing at ordering and ownership. Structured events, tied together by a shared identifier, turn that guesswork into a query. Tracing extends the same idea across boundaries, showing where time is spent and where a failure first appears. Teams that build this observability in from the start spend their operational hours tuning behavior rather than hunting for it.
Deployment practices also matter. Because functions are small and independent, it is tempting to deploy them independently and let versions drift. That drift creates environments that are hard to reproduce. Treating infrastructure and configuration as versioned artifacts, and promoting the same artifact through environments, keeps behavior predictable. Blue-green or canary deployments reduce the blast radius of a bad release, which is especially valuable when a function is on a critical path. The discipline here is less about tooling and more about consistency: the thing you tested should be the thing you ship, and the thing you ship should be the thing you can roll back. When each function can change on its own schedule, the combinations multiply quickly, and an environment becomes a unique snowflake that no one can rebuild. Versioned artifacts and staged promotion keep those combinations bounded and reversible.
Finally, decide deliberately where functions belong. They are excellent for glue, event handling, and variable traffic. They are a poor fit for long-running computations, stateful services, and workloads with strict latency floors. A hybrid architecture, where functions handle the edges and containers handle the core, is often the most honest answer. The platform choice matters less than placing each workload where its cost and failure characteristics make sense. Matching the execution model to the workload keeps both the bill and the operational burden aligned with reality.
7 Frequently asked questions
Which platform is better? Neither, in the abstract. Both implement the same event-driven execution model with different configuration surfaces and operational quirks. The better choice is usually the one your team already understands, because operational familiarity reduces incident duration more than any feature difference. Familiarity shapes how quickly an engineer can read a trace, recognize a misconfigured trigger, or reason about retry behavior under pressure. If you have no existing preference, pick one, build a representative workload, and measure cold starts, concurrency behavior, and total cost including logs and downstream calls. Treat that measurement as the beginning of an ongoing comparison rather than a one-time verdict, since the workload itself will keep changing.
How do I control cost? Start by measuring invocation count, duration, and memory allocation separately, then look at logging and data transfer. These dimensions interact, so changing one in isolation can shift cost into another. Reduce memory only if it does not increase duration, since the two interact. Set concurrency limits to prevent runaway scaling, and move steady high-volume workloads to always-on compute when utilization justifies it. Revisit the decision periodically, because traffic patterns change, and a configuration that was efficient last quarter may no longer match current demand.
How do I avoid cold-start pain? Keep initialization light, avoid loading large dependencies at startup, and reuse connections where the runtime permits. For latency-sensitive endpoints, consider provisioned concurrency or a small always-warm tier, but weigh the cost against the benefit. Accept that some cold starts are unavoidable and design clients to tolerate occasional added latency. The goal is not zero cold starts; it is predictable behavior under load, so that occasional slow responses do not cascade into timeouts or user-visible failures.