Leaving the hyperscalers: what a .NET SaaS really saves moving from AWS/Azure to Hetzner
A line-by-line look at what AWS and Azure actually cost a SaaS in 2026, why the bill scales with your success, and the honest economics of moving to Hetzner.
The cloud was supposed to be the part of the business you never had to think about. For a lot of SaaS companies in 2026 it has become the opposite: a bill that grows faster than revenue, dominated by line items nobody chose and few can explain. This post is the one we wish more teams read before their infrastructure spend crossed six figures a year — what AWS and Azure actually cost, why the bill scales with your success rather than your usage, and what moving to Hetzner really saves once you account for what you give up.
We migrate companies off the hyperscalers, so we have a side. We also did it to ourselves first — and the honest tradeoffs are in here alongside the savings, because a cost post that only shows the wins isn’t worth reading.
The bill nobody audits
Most cloud bills are set once, early, when the product is small and the numbers are rounding errors, and then they’re never revisited. The instance types get bigger, the managed services accumulate, the traffic grows — and because each increment is small, the total drifts upward without anyone making a decision. By the time it’s your second-biggest cost after payroll, it feels load-bearing and untouchable.
It usually isn’t. When we tear down a hyperscaler bill, the same three culprits dominate almost every time: egress, managed-service premiums, and HA multipliers. None of them is the compute you actually reason about when you pick an instance size — and all three are far cheaper, or free, elsewhere.
Egress: the cost that scales with your success
Here is the number that matters most and that nobody quotes when they sell you the cloud: the price of sending data to your own users.
- AWS: $0.09/GB after the first 100 GB — about $90 per terabyte.
- Azure: $0.087/GB — about $87 per terabyte.
- Hetzner: 20 TB/month included on every cloud server, then €1/TB; on a dedicated server, unlimited.
That’s an 80–90× difference. Read it again, because it’s the whole ballgame. A product serving 5 TB of API responses, file downloads, and data exports a month pays roughly $440/month in egress on AWS and €0 on a Hetzner dedicated box. At 20 TB — a product with media, reports, or a real API — that’s ~$1,800/month on AWS versus still nothing on Hetzner.
The cruelty of egress pricing is that it scales with the thing you want: more users, more usage, more data delivered. Your infrastructure cost is highest exactly when the product is working. That’s a terrible incentive structure to build a business on, and it’s the single line that most often makes a migration pay for itself.
The costs that don’t appear on the sticker
Egress is the headline, but the hyperscaler bill has a supporting cast of charges that never show up in the instance price you compared:
- AWS NAT Gateway bills $32.85/month per gateway plus $0.045/GB for everything routed through it — separate from, and on top of, egress. You want one per availability zone for HA, so that’s two or three.
- Inter-AZ traffic is $0.01/GB in each direction. Your multi-AZ database replica quietly meters its own replication, forever.
- Azure zone-redundant HA doesn’t add a modest premium — it doubles your database compute and duplicates its storage, because you’re paying for a full hot standby.
- Provisioned disks and managed-service floors bill whether you use them or not — a Premium SSD charges its full tier on an empty volume; a managed Postgres with HA is two instances before it serves a single query.
None of these are scandals. They’re the documented defaults. But they’re why the real invoice is reliably higher than the estimate you built in the pricing calculator — and why “we’ll just optimize our AWS bill” so rarely closes the gap.
What the move actually saves — and costs
We modeled a representative mid-size B2B SaaS — two app servers, HA Postgres, Redis, a load balancer, some storage, and 5 TB of monthly egress — against all three providers’ 2026 pricing. The full line-by-line breakdown lives on our AWS/Azure vs Hetzner comparison page, but the bottom line:
- AWS: ~$1,350/month
- Azure: ~$1,120/month
- Hetzner: ~$225/month
An ~83% reduction — and it’s not instance cherry-picking; the compute lines are close. The gap is egress and the absence of a managed-service premium.
Now the honest half, because this is where most “move to Hetzner” posts go quiet. Hetzner has no managed data services — no RDS, no ElastiCache, no Aurora, no managed Kubernetes. The reason the compute is a fraction of the price is that you’re renting metal, not a platform. Someone has to run PostgreSQL, Redis, high availability, backups, and monitoring — and that someone is now you. There’s no serverless, the footprint is EU-centric (US and Singapore locations exist but with far less included traffic), support is ticket-based rather than enterprise-SLA, the compliance certification list is narrower, and — worth saying plainly — Hetzner itself raised prices several times in 2026. The gap is still enormous; it’s just no longer the never-changes bargain of folklore.
So the real trade is legible: egress and managed-premium savings on one side, operational ownership on the other. Whether it’s worth it depends entirely on whether your bill is dominated by the former and whether you can take on the latter.
We did it to ourselves first
The most honest number we can give you is our own. When we moved Code Majesty’s internal SaaS template off a cloud-native scaffold to Hetzner, its infrastructure cost dropped 94% — from about $2,000/month to $120/month. Across client migrations (workload shapes we can describe, clients we don’t name without permission), the range we see is 60–90%, and where a project lands in that range is almost entirely a function of how much of the old bill was egress and managed-service premium.
But the number that made those migrations safe wasn’t the savings — it was the hand-off. The thing that rightly scares teams about “cheaper metal” is the operational burden, and that’s exactly what a migration has to solve, not create. When we move a client, the self-managed data layer gets stood up properly — HA Postgres, backups that are actually restore-tested, monitoring, infrastructure-as-code so it’s reproducible — and we leave the runbooks and guardrails behind so the client’s own team can operate it without us. The savings are the reason you call; the fact that your team can still sleep afterward is the reason it works. It’s the same principle as everything else we build: you own the system, not just the outcome.
Should you move?
Be honest with yourself about which side of the trade you’re on.
Stay on AWS or Azure if your bill is still small, or your product genuinely needs global edge presence, deep compliance attestations (HIPAA, FedRAMP, PCI-at-scale), the full serverless/managed catalog, or spiky event-driven workloads that bill to near-zero. For a real class of companies that’s the right answer, and we’ll say so.
Look hard at moving if your workload is a steady SaaS footprint, your egress is meaningful and growing, ISO 27001 / GDPR satisfies your compliance needs, and you either have the ops capability or are willing to have it handed to you. That describes most product SaaS companies past a certain scale — and most of them are overpaying by a multiple, not a margin.
The cheapest way to find out which you are is to stop guessing. Bring a recent bill to an $80 cost-teardown call — we’ll model your actual workload on Hetzner, including the ops you’d take on, and tell you honestly whether the move is worth it. If it is, that’s a Sprint Zero migration. If it isn’t, you’ve spent $80 to stop wondering about the biggest line in your budget.
Related Posts
AI coding guardrails for regulated industries: what we ship for fintech, govtech and assurance clients
How the twelve-layer system maps to GDPR, DORA, NIS2, and SOC2 — with the audit artifacts each layer produces as a side effect of normal development.
Azure DevOps Deployment Best Practices for .NET and .NET Core Applications
Learn essential Azure DevOps deployment best practices for .NET and .NET Core applications, including build pipelines, release pipelines, automated testing, and configuration management.
How we run Claude Code on a 5-developer .NET team — with our actual CLAUDE.md, hooks, and skills
Our real production setup, published: the hook roster, five subagents with model tiers, eight MCP servers, and the machinery that makes agent output shippable.