Hetzner vs AWS: The Real Cost Difference in 2026
- Pratik Kulkarni
- Cloud Architecture , Cost Optimisation
- 21 Aug, 2026
- 08 Mins read
For a standing 8-vCPU, 16 GB server, AWS charges about $212 per month on demand and Hetzner charges €20.99, or roughly $25. That is a factor of nine, and it is not a rounding error. The gap is also not uniform: it depends heavily on which Hetzner line you buy, it narrows sharply once AWS committed-use discounts are applied, and on GPU it disappears entirely. What every price table leaves out is that AWS is not selling CPU and RAM, and the difference between the two invoices is work that has to be done by someone.
This post is a like-for-like comparison of the two, at current list prices: where the gap is widest, where it closes, and which workloads the arithmetic supports moving. For the wider market rather than this pairing, see Cheaper Alternatives to AWS in 2026: What Each One Cuts.
The compute gap, at current prices
All figures are monthly list prices for a Linux instance with 8 vCPU and 16 GB of RAM, the smallest shape most teams run a real service on. Hetzner figures are EU locations excluding VAT; AWS figures are us-east-1, its cheapest major region. Euro conversions below use approximately $1.17 to the euro.
| Provider | Plan | vCPU | Storage | Included traffic | Monthly |
|---|---|---|---|---|---|
| AWS | c7g.2xlarge on demand | 8 Graviton3 | EBS, billed separately | 100 GB free, then metered | ~$212 |
| AWS | c7g.2xlarge, 3-year commit | 8 Graviton3 | EBS, billed separately | 100 GB free, then metered | ~$93 |
| Hetzner | CPX42 | 8 shared AMD | 320 GB NVMe | 20 TB | €69.49 |
| Hetzner | CAX31 | 8 shared Ampere Arm | 160 GB NVMe | 20 TB | €20.99 |
| Hetzner | CX43 | 8 shared x86 | 160 GB NVMe | 20 TB | €15.99 |
Against on-demand pricing the spread runs from about 9x (CAX31) to about 11x (CX43). That is the number most comparison articles quote, and it is not the number to plan against, because almost nobody runs a steady-state fleet on demand.
Against a three-year Graviton commitment at roughly $93 per month, the spread narrows to about 3.8x for the CAX31 and 5x for the CX43. Spot capacity for the same instance has traded at about $0.127 per hour, which is the same as the three-year rate, so spot does not change the ranking, it just removes the commitment in exchange for the risk of reclamation.
One row in that table cuts against the usual story. Hetzner’s CPX42 at €69.49, about $81, is barely below a three-year committed c7g.2xlarge — for the same 8 vCPU and 16 GB that a CAX31 delivers at €20.99. The large gaps are not a property of “not-AWS”. They are a property of two specific Hetzner lines, and picking the wrong one hands most of the saving back.
So the honest framing is: roughly 4–5x against committed AWS pricing, 9–11x against on-demand, and close to nothing if you pick the wrong line.
Hetzner repriced in June 2026, and it changed which line to buy
On 15 June 2026 Hetzner adjusted cloud server prices, and the adjustment was not uniform. The dedicated-vCPU CCX line rose by roughly 2.1x to 2.7x, and the shared-AMD CPX line by roughly 2.4x to 2.75x. The CX and CAX lines rose by about 1.3x to 1.4x.
| Plan | Before | After | Change |
|---|---|---|---|
CX43 | €11.99 | €15.99 | 1.33x |
CAX31 | €15.99 | €20.99 | 1.31x |
CPX42 | €25.49 | €69.49 | 2.73x |
CCX23 | €31.49 | €85.99 | 2.73x |
The practical consequence is that the Arm line is now the value tier by a wide margin. A CAX31 and a CPX42 are the same 8 vCPU and 16 GB, and the CPX costs 3.3x more. Any Hetzner sizing done before June 2026 — including a lot of published reference architectures — was built around CPX and CCX instances and will cost two to three times its original estimate if applied unchanged today.
It also narrows the comparison where dedicated vCPUs are a requirement. CCX23 gives 4 dedicated vCPU and 16 GB for €85.99, about $101, against roughly $93 for a three-year committed c7g.2xlarge with 8 vCPU. For a workload that needs guaranteed CPU — Postgres, most obviously — Hetzner is no longer the cheaper option on compute alone. The large gaps now live specifically in the shared and Arm tiers.
Egress is where the gap is largest
Compute pricing is the headline, but for anything that serves media, exports data, or replicates across regions, egress is the line that decides the invoice.
Hetzner includes 20 TB of outbound traffic per server per month in EU and US locations, with overage at €1 per TB. The same 20 TB at AWS list rates costs roughly $1,740 per month: the first 100 GB is free, the next 9.9 TB is billed at about $0.09 per GB, and the remainder at about $0.085 per GB.
That single line is frequently larger than the entire compute saving. Three CAX31 servers cost about €63 per month, roughly $74; the 60 TB of egress those three servers include between them would cost several thousand dollars a month at AWS list rates. If your workload is egress-heavy, the compute comparison above is close to irrelevant and this is the number to model first.
Two qualifications. AWS egress to CloudFront is free, and CloudFront’s own egress rates are considerably lower than EC2’s, so a properly fronted static or media workload does not pay the raw EC2 rate. And Hetzner’s Singapore location prices traffic at €7.40 per TB rather than €1, so the included-traffic advantage is a European and North American one.
On GPU, the gap disappears
The nine-to-eleven-times figure is a CPU number. It does not carry over to accelerators, and for anyone costing an AI workload that is the more important half of the comparison.
Hetzner’s GPU offering is a dedicated-server line, not a cloud instance type. The current shapes are the GEX130 with an RTX 6000 Ada (48 GB) at €838 per month, and the GEX131 with an RTX PRO 6000 Blackwell Max-Q (96 GB) at €889, both with a one-off setup fee and both billed monthly rather than hourly.
Against a comparable AWS instance — g6e.xlarge, one L40S with 48 GB — the arithmetic lands differently from the CPU case:
| Option | GPU | Monthly, always-on |
|---|---|---|
AWS g6e.xlarge on demand | 1 × L40S 48 GB | ~$1,359 |
Hetzner GEX130 | 1 × RTX 6000 Ada 48 GB | €838, about $980 |
AWS g6e.xlarge, 3-year commit | 1 × L40S 48 GB | ~$587 |
Hetzner sits below AWS on-demand and above a three-year commitment. There is no 9x here, and there is no version of this comparison where GPU is the reason to move.
Three structural differences matter more than the price:
- Billing is monthly, not hourly. A dedicated server has no per-hour elasticity and no spot market. A GPU that is busy eight hours a day costs the same as one that is busy twenty-four, which inverts the usual argument for leaving a hyperscaler.
- The ceiling is a single workstation-class card. No H100, H200 or B200, and no multi-GPU node with NVLink between the cards. Distributed training is not on the table, and neither is anything that needs more than 96 GB of VRAM in one place.
- Availability is not guaranteed. The GPU line goes out of stock in a way cloud capacity generally does not — the smaller
GEX44has been unavailable for stretches — so it is not something to design an autoscaling story around.
The practical conclusion is a split rather than a migration: the platform and the stateless compute can sit on Hetzner while inference stays on Bedrock, SageMaker or EC2 accelerated instances. That is the shape most AI workloads should end up in, and it is worth designing for deliberately rather than arriving at by accident.
What the price difference represents
The difference between the two invoices is the managed layer, priced separately. It is worth reading the comparison as two line items rather than one.
An RDS instance bills for the database plus automated backups, point-in-time recovery, failover, minor-version patching and a restore path AWS maintains. A Hetzner server bills for the machine. The same split applies to the managed Kubernetes control plane, IAM, CloudWatch, Secrets Manager, autoscaling groups and WAF; Hetzner’s permission model is an API token scoped to one project, read-only or read-write. Those capabilities are available on Hetzner, as open-source components you select, deploy and operate.
The full inventory is in Leaving AWS for Hetzner: What You Have to Rebuild. For costing purposes it comes to three line items:
- Platform build. Network segmentation, firewalls, an access plane, a container runtime, CI/CD, observability, secrets, host hardening, database replication and a tested restore. Two to twelve weeks, depending on the redundancy the tier calls for, in your team’s time or a contractor’s.
- Ongoing operations. Patching, upgrades, alert triage, on-call, quarterly restore drills and access reviews, as a standing commitment rather than a one-off.
- Cutover. A timed restore drill before production traffic moves, which is what converts a stated RPO and RTO into a measured one.
Set against those, a $2,000 monthly AWS bill does not clear the platform cost in year one; a $20,000 bill clears it in weeks. That threshold, rather than the price-per-vCPU ratio, is the number the decision turns on.
Which workloads the arithmetic supports
Strongest case for moving:
- Stateless compute. Web servers, API workers, background job runners, build agents. These are the purest form of the comparison, and self-hosted CI runners in particular tend to pay for themselves almost immediately.
- Egress-heavy serving. Anything measured in terabytes out per month, where the included-traffic allowance dominates every other line.
- Predictable, always-on capacity. The saving comes from steady-state load on fixed monthly servers. Spiky workloads are the case where AWS elasticity earns its price.
- Non-production environments. Dev and staging estates carry the same server count as production and none of the availability requirement, which makes them the least risky first move and often the largest single line to cut.
Weaker case, or a rebuild rather than a migration:
- Anything whose value sits in managed services — Aurora, DynamoDB, Bedrock, SQS, Step Functions, EventBridge. Reimplementing those is a build, and should be scoped and priced as one.
- Workloads with multi-region failover requirements. Hetzner placement groups spread servers within a location; surviving the loss of a location is replication you design and pay for.
- Anything where a contractual support response SLA is a compliance requirement.
- Accelerated workloads. Training, fine-tuning and bursty batch inference. Hetzner’s GPU line is monthly-billed, single-card and capacity-constrained, and the price advantage is not there.
The hybrid is the option least often put on the table and frequently the one the numbers favour: managed data and inference stay on AWS, while stateless compute, CI and non-production environments move to Hetzner. That captures most of the saving and leaves the database and the accelerators where they are already operated, in exchange for a cross-provider network path that has to be designed deliberately.
Summary
- On committed compute the realistic gap is about 4–5x, not the 9–11x that on-demand list prices suggest, and Hetzner’s CPX line sits close to a three-year AWS commitment.
- Hetzner’s June 2026 repricing raised CPX and CCX by roughly 2.5x while leaving CX and CAX close to flat. Arm is now the value line, and pre-June sizing is stale.
- Included egress is frequently a larger saving than compute. Twenty terabytes costs about $1,740 per month at AWS list and nothing extra at Hetzner in EU and US locations.
- On GPU there is no gap. Hetzner’s dedicated GPU line sits below AWS on-demand and above a three-year commitment, is billed monthly with no spot market, and tops out at a single 96 GB card. Inference and training stay where the accelerators are.
- The difference is the managed layer, priced separately. Cost the build and the ongoing operations alongside the server saving, and use the resulting threshold, rather than the per-vCPU ratio, to decide.
If the decision goes ahead, the platform work is described in Leaving AWS for Hetzner: What You Have to Rebuild, and we deliver it as a package: the Hetzner landing zone.