Azure Container Apps' Per-Second Meter vs a €4 Hetzner Box: Where Serverless Containers Win, and Where They Cost 8x

Azure prices a running container at $0.000024 per vCPU-second. Hetzner prices a whole virtual server at roughly €4 a month. Both numbers are real, both are current, and they imply completely opposite answers to the same question: what should an app that never sleeps cost?

Azure Container Apps splits its answer in two. The Consumption plan meters every vCPU-second, GiB-second, and request — with a free grant generous enough that a genuinely spiky side project can live inside it for $0. The Dedicated plan flips the model: provisioned workload profiles billed whether your code is executing or not, plus an hourly management fee, in exchange for single tenancy and specialized hardware. The two-tier split reflects one honest insight: per-second billing is a wonderful deal for workloads that stop, and a quietly brutal one for workloads that don't.

So here is the verdict up front, with the receipts below. All figures recomputed from the published rates for a 0.5-vCPU, 1 GiB app:

And the bigger steady shape — 2 vCPU, 4 GiB, 10M requests, always on — lands at ~$155/mo on Consumption and ~$171/mo on Dedicated, against a CX43-class box at roughly $14/mo. The headline is a number with a hinge: below about a quarter of the month running, the meter wins; above it, the flat box wins by roughly an order of magnitude. The rest of this post is the line-by-line math behind each cell, what the Dedicated tier actually changes, and the case Azure's own pricing page wins fair and square.

How the Consumption meter actually works​

The Consumption plan bills four things, all per second, all with published rates on the Azure Container Apps pricing page:

• vCPU, active: $0.000024 per vCPU-second ($0.0864 per vCPU-hour). This is the headline number — the meter running while your code is executing.
• vCPU, idle: $0.000003 per vCPU-second ($0.0108 per vCPU-hour). A replica that exists but isn't processing requests still ticks, at one-eighth the active rate.
• Memory: $0.000003 per GiB-second ($0.0108 per GiB-hour), active or idle — allocation is allocation.
• Requests: $0.40 per million beyond the free allowance.

Against that meter sits a monthly free grant per subscription: 180,000 vCPU-seconds (50 vCPU-hours), 360,000 GiB-seconds (100 GiB-hours), and 2 million requests. There is also a floor on replica size — 0.25 vCPU / 0.5 GiB is the smallest Consumption container — so you cannot shrink your way below a minimum tick rate while running.

The feature that makes this shape work is scale-to-zero. A Consumption app with minimum replicas set to zero costs exactly nothing when idle — no active seconds, no idle seconds, no memory seconds. The meter only runs while a replica exists. Every comparison below turns on this one mechanism: the question is never "how big is the app" but "how many seconds a month does at least one replica exist."

The worked recompute: a duty-cycle sweep​

Take a small production-shaped app — 0.5 vCPU, 1 GiB, under a million requests a month (so requests stay inside the free grant) — and vary only the fraction of the month it actually runs, scaling to zero the rest of the time. A month is 730 hours, or 2,628,000 seconds:

Read the hinge in the table: the breakeven sits at roughly a quarter of the month running — about 180 hours. An app awake more than ~6 hours a day costs more on the meter than on the flat box; an app awake less slides into the free grant and costs nothing at all. There is almost no middle ground, because the two models are shaped opposites: one charges for existence by the second, the other charges a flat fee for the right to exist at all.

Now scale the steady case up. A 2-vCPU, 4 GiB service with 10M monthly requests, always on: vCPU burns 5,076,000 billable seconds ($121.82), memory 10,152,000 billable GiB-seconds ($30.46), requests 8M billable millions ($3.20) — $155.48/mo total. The same footprint fits comfortably on a CX43-class box at roughly $14/mo with 20 TB of included traffic. That is an 11x multiple, and it exposes the meter's real character: at full utilization you are renting the same silicon by the sip instead of buying the glass, and the per-sip markup compounds across every dimension at once.

One line item is deliberately absent from the table: egress. Hetzner's CX line includes 20 TB of monthly traffic in the flat price; Azure meters bandwidth separately outside the Container Apps bill. Leaving it out flatters Azure — every gigabyte past the allowance widens the gap further, and for anything serving real traffic it is the line that turns an 8x multiple into something worse. If your app pushes serious bytes, redo this math with your transfer bill included before you conclude anything.

What the Dedicated tier actually changes​

The Dedicated plan exists for the workloads Consumption fits poorly: tenants that need single-tenancy guarantees, specialized hardware (including GPU profiles), and predictable per-hour pricing instead of a per-second meter. Billing follows the workload profile you provision — vCPU and memory reserved per second each instance runs — plus a base management fee for the plan itself. The published Dedicated meters run $0.10 per hour for plan management, $0.0571 per vCPU-hour, and $0.0050 per GiB-hour (visible on Azure's Spring Apps pricing for the same Dedicated meters, corroborated by independent ACA-vs-AKS cost breakdowns).

Run the same 2-vCPU, 4 GiB always-on workload through those meters: management $0.10 × 730 ($73.00), vCPU 2 × $0.0571 × 730 ($83.37), memory 4 × $0.0050 × 730 ($14.60) — $170.97/mo. More than Consumption's $155, not less. The $73-a-month management fee is a fixed floor no utilization level can amortize away at small scale, and there is no free grant to soften it.

That inversion is the honest story of the two-tier split, and it is worth stating plainly: Dedicated is not the discount tier for steady workloads — it is the isolation tier. It buys single tenancy, workload-profile control, and hardware Consumption cannot offer. What it does not buy is relief from the meter for a small always-on app; at that scale the management fee alone costs five CX43-class boxes. Dedicated starts making sense when the workload is large enough that profile-level packing plus savings plans outweigh the fee, or when compliance or GPU requirements take Consumption off the table entirely. If you came to Dedicated hoping it would rescue a $155 steady-state bill, the recompute says it adds $16 to it.

Where Azure honestly wins (and the Hetzner caveats)​

The spiky row in the sweep table is not a trick — it is the case Azure's own pricing page wins without qualification. A side project, a webhook receiver, a preview environment, a nightly batch job: anything that genuinely runs a few hours a day inside 50 vCPU-hours and 100 GiB-hours a month costs literally $0 in compute on Consumption, requests included up to 2M. No flat box can beat free, and the mechanism is real scale-to-zero, not a trial credit. This is the workload Consumption pricing was built for, and begrudging it would be dishonest — per-second billing with a free grant is the best deal in hosting for code that mostly doesn't run.

But price the Hetzner side with current numbers, not remembered ones. Three caveats:

• The catalog moved. Hetzner's June 15, 2026 repricing restructured the cloud lineup around hardware generations, and the old CX22 is deprecated — deployment tooling that still provisions cx22 gets rejected by the API. The current cost-optimized entry point is the CX23 (2 vCPU, 4 GB, 40 GB) at roughly €3.79–3.99/mo, still with 20 TB of included traffic. The repricing hit the CPX/CCX performance lines hardest (some more than doubling); the CX line this comparison uses was largely spared — which is convenient for the argument, so verify it rather than trusting it.
• You operate the box. The flat fee covers hardware, power, network, and 20 TB of transfer. It does not cover patching, backups, incident response, or the 3 a.m. page. Azure's multiple is partly an operations team you don't have to hire — discount the 8x by whatever your on-call time is worth before treating it as pure savings.
• The database question is untouched. Neither side of this comparison includes managed Postgres, and that is deliberate: folding the data layer into the platform bill is a lock-in decision disguised as a convenience, and it deserves its own math, not a footnote here.

The decision rule​

Plot your workload on one axis: seconds per month with at least one replica running. Below ~180 hours, the Consumption meter — and especially its free grant — is the cheapest correct answer, and often a free one. Above it, the per-second meter compounds against you in every dimension simultaneously, and a flat box at single-digit euros collapses a $34–$155 bill into one number that never moves.

The deeper lesson is about what each model rewards. Per-second billing rewards code that stops: scale-to-zero architectures, event-driven shapes, workloads with genuine idle. Flat hardware rewards code that runs: steady APIs, always-on workers, anything whose utilization you can predict. Most real estates contain both, which is why the two-tier vendors keep building both tiers — and why owning the flat side of that split, on machines you control, is the part no vendor's pricing page will ever offer you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.