Cloud & DevOps

Fargate, Cloud Run, Azure Container Apps: which one bills you least?

Amazon, Google and Microsoft rent you the same thing three different ways. The billing meter, not the feature list, decides your monthly bill.

Editorial Team / /8 min read
An engineer working on a laptop in a server room

Two teams can run the same small application in the cloud and receive monthly bills that differ tenfold. Same code, same visitors, same result on screen. The gap comes from one decision most comparisons bury under a long feature checklist: which meter the cloud provider runs your app on.

Amazon, Google and Microsoft each sell a version of the same convenience. You hand them your app packaged as a container, a sealed box that holds your program and everything it needs to run, and they run it for you so you never have to rent and babysit a server yourself. Amazon’s version is called Fargate, Google’s is Cloud Run, Microsoft’s is Azure Container Apps. On the brochure they look almost interchangeable. On the invoice they are not, because each one counts what you owe in a different unit.

That difference in counting is the whole story, and it is the part that lasts. Prices drift every year, but the way each platform meters you barely moves. Match the meter to how your app is actually used, and the bill more or less takes care of itself.

Three meters, not three features

Picture renting a car. One company charges you by the day, whether the car ever leaves the driveway. Another charges by the minute and stops the meter the moment you park. The cars are identical. The meter decides what you pay. Cloud platforms work the same way.

Fargate charges by the hour. You tell Amazon how much computing power your app needs, and it bills that reservation for every hour the app is switched on, busy or idle. The meter does not care whether your app served one visitor that hour or a million. You pay for the reservation, not the work.

AWS Fargate product page — serverless compute for containers

Cloud Run charges by the second, and drops to nothing when no one is using your app. A request arrives, the app wakes, serves it, and you pay only for those seconds. When the app sits quiet, it costs you nothing. This automatic shrink-to-nothing is the feature the other two do not give you for free.

Google Cloud Run product page — per-second billing, you pay only while your code is runnin

Azure Container Apps charges by the event. It can sit idle and wake the instant a task lands in a waiting line of jobs, then bill only while it works through them. Like Cloud Run, it can also fall back to nothing between bursts. It is built for work that arrives as a queue rather than as web visitors.

Azure Container Apps product page — run modern apps and agents using serverless containers

The only question that picks a winner

The useful question is not which platform is best in the abstract. It is what shape your traffic has, because each meter rewards a different shape.

  • Steady traffic, busy all day: the by-the-hour reservation is cheapest, because there is no idle time to waste. This is Fargate’s home ground.
  • Spiky traffic, quiet most of the day with sudden bursts: the by-the-second meter that drops to nothing wins, because you stop paying the moment the rush ends. This is where Cloud Run prints money.
  • Work that arrives as a queue of jobs rather than live visitors: the by-the-event meter wins, because it wakes on the queue itself without you building the trigger. This is Azure Container Apps’ advantage.

Notice that none of those calls turned on a feature comparison. The traffic shape and the meter decided it.

What the gap looks like in real money

Take one modest app and run it flat, twenty-four hours a day. On the by-the-hour meter it costs a steady, predictable amount, a few tens of dollars a month. On the by-the-second meters, with no idle gaps to skip, the seconds pile up to roughly the same place. For an app that never rests, the three meters basically tie, and the by-the-hour one wins on predictability, which finance teams value more than a saving that never shows up.

Now run the same app so it is genuinely busy only about one hour in twenty, and idle the rest. The by-the-hour meter still charges the full reservation, because the app stayed switched on the whole time. The by-the-second meters that drop to nothing bill only the active slice, roughly a tenth of the cost, and sometimes nothing at all once each platform’s free monthly allowance is counted. Same app, same code, an order-of-magnitude difference, decided entirely by which meter met the traffic. That single inversion, not graphics power or boot speed, is where the money actually is. The same habit of watching the per-use cost is what our guide to cutting AWS Lambda costs applies one layer further down.

Which one to pick, at a glance Which one to pick, at a glance

The catch: you rarely pick the meter freely

In theory all three run the very same container, so you could move your app between them like swapping one rental for another. In practice you almost never do, and that is the part worth understanding before you choose.

The cheap meter is bolted to the rest of its cloud. Fargate’s value only appears once your app already lives among Amazon’s other services; Cloud Run’s once it lives among Google’s; Container Apps’ once it lives among Microsoft’s. If your company keeps its data and tools at Amazon, running one piece over at Google means paying to shuttle data between two clouds and rewiring the connections that made the cheap option pleasant in the first place. So the honest version of the decision is this: pick the meter that matches your traffic, inside the cloud you already live in. Match those two and the choice makes itself.

Which one, in one line each

Choose Fargate for an app that runs flat all day inside Amazon’s cloud. It pays its by-the-hour reservation once, the bill is predictable to the dollar, and it slots in beside the rest of your Amazon setup with no new plumbing.

Choose Cloud Run for an app that sits quiet and wakes in bursts inside Google’s cloud. The drop-to-nothing meter is automatic, a small service can run for the price of a coffee or for free, and an app busy a twentieth of the day pays for a twentieth of the day.

Choose Azure Container Apps for work that arrives as a queue of jobs inside Microsoft’s cloud. It wakes on the queue on its own, which spares you the extra wiring the other two make you build for the same behaviour.

The decision was never which platform is objectively best. It is which billing meter matches your traffic, inside the cloud you already run. Settle those two questions and everything else is detail.

Frequently asked questions

Is Cloud Run cheaper than Fargate?

It depends entirely on traffic shape. For an app that is busy only part of the day, Cloud Run is often cheaper by roughly ten times, because it stops charging when no one is using the app while Fargate keeps billing its reservation. For an app that runs flat all day the two roughly tie, and Fargate’s predictable by-the-hour bill often wins. There is no single cheaper platform, only a cheaper meter for a given pattern.

Does Fargate ever stop charging while my app is idle?

Not on its own. Once you switch a Fargate app on, it stays on and keeps billing until you switch it off, even at three in the morning with no visitors. You can build an automatic shut-down yourself, but it is wiring you have to assemble. Cloud Run and Azure Container Apps drop to nothing automatically, which is the core reason they win on quiet, bursty traffic.

Which one is best for jobs that arrive in a queue?

Azure Container Apps, when you are already on Microsoft’s cloud. It can wake the moment a job lands in the queue and go back to sleep when the queue empties, without you building the trigger. Fargate and Cloud Run can do similar work, but you have to wire up the wake-on-queue behaviour yourself rather than getting it out of the box.

Can I avoid being locked into one cloud?

The app itself is portable, since all three run the same standard container, so the program is not the trap. The lock-in is the surrounding wiring, the connections to each cloud’s own data stores, identity and event sources. Run any of the three outside its home cloud and you pay to move data across the boundary and lose the integrations that justified the choice. Portability of the box is real; portability of the savings is not.

What is a “cold start,” and does it matter?

A cold start is the short wait while an app that had dropped to nothing wakes back up to serve the first request after a quiet spell. Cloud Run wakes fastest, often in under a second; Azure Container Apps takes a few seconds; Fargate is slowest, tens of seconds, because it builds a fresh isolated machine each time. For most apps this is invisible. It only matters for sudden, infrequent bursts where the very first visitor must not be kept waiting, and there Cloud Run’s quick wake-up is the reason to prefer it.


Photo: Christina Morillo / Pexels

#cloud#containers#serverless#finops#aws