Cost-effective caching: swapping ElastiCache for managed Redis on Hetzner

Redis is the default caching layer for most web applications, and on AWS the default way to run it is ElastiCache. It works well, it sits inside your VPC, and it delivers sub-millisecond latency. It also charges a premium that grows quietly as your workload does. If your caching needs are stable and EU-bound, running managed Redis on Hetzner can cut that line item by 60 to 90 percent while keeping the same functionality.

This is the kind of trade-off we work through with clients every week. As an AWS certified managed cloud hosting company, we don’t move workloads off AWS for the sake of it. We move the parts where the savings are real and the risk is manageable, and caching is often one of those parts. Here’s how the two options compare and what a clean migration looks like.

What ElastiCache actually costs

ElastiCache pricing is straightforward on paper. In us-east-1, an on-demand cache.t4g.small (1.37 GB RAM) runs about $0.032 per hour, which is roughly $23.36 per month. A cache.t4g.medium (3.09 GB RAM) is about $47.45 per month. Those numbers are fine on their own. The cost creeps in through the surrounding pieces.

• High availability doubles it. Add a replica node with Multi-AZ and you pay for two nodes. That t4g.small becomes about $46.72 per month for the same 1 GB of usable cache.
• Cross-AZ data transfer. Traffic within one Availability Zone is free, but when your app servers and Redis node sit in different AZs, you pay $0.01 per GB. On a busy cache that adds up.
• The VPC boundary. ElastiCache is only reachable from inside your VPC. Connecting from a CI runner, a laptop, or a service outside AWS means provisioning a NAT Gateway (around $32.40 per month for the gateway alone) or a VPN. That cost never shows up on the ElastiCache line, but it’s real.
• The free tier trap. If you built a project on the old ElastiCache free tier, it expires 12 months in with no warning email. Accounts created after July 15, 2025 get no dedicated free hours at all. A lot of “surprise” Redis bills are just an expired free tier.

None of this makes ElastiCache a bad product. It’s the right call when your app needs the absolute lowest latency to Redis inside a VPC and you’re already committed to AWS. The problem is choosing it out of inertia rather than need.

What Hetzner changes

Hetzner sells plain compute at prices that are hard to argue with. A CPX21 instance (2 vCPU, 4 GB RAM) is around 5.83 EUR per month, and it includes generous egress (20 TB) with no per-GB transfer charges within that allowance. You can run Redis on that instance directly, or dedicate a small server to it, and the cost sits far below the equivalent ElastiCache node.

The catch is in the word “managed.” ElastiCache handles failover, backups, patching, and monitoring for you. On a raw Hetzner VPS, those are your responsibility. That’s exactly the gap our managed service fills. We run Redis on Hetzner as a managed layer: configured, monitored, backed up, and set up for failover, so you get the price of self-hosting with the operational safety of a managed product.

To put the difference in context, independent cost breakdowns of EU SaaS workloads under 100k monthly active users consistently show Hetzner landing 70 to 90 percent cheaper than the AWS equivalent across compute, database, and cache combined. Caching is one of the cleaner wins inside that total because Redis is stateless enough to move without touching your application logic.

Where the savings are real, and where they aren’t

Be honest about your workload before you move anything. The swap pays off clearly in a few cases:

• Your traffic is predictable and mostly EU-based, so you don’t need 30 AWS regions.
• Your cache is a genuine cache – losing it briefly degrades performance but doesn’t corrupt data.
• Your Redis bill has grown past the point where a fixed monthly server price would obviously be cheaper.

It pays off less, or not at all, when your setup leans on AWS-native behaviour. If your app depends on tight cross-service latency inside a single VPC, if you have compliance requirements that AWS certifications already satisfy, or if you handle unpredictable 100x traffic spikes that need instant auto-scaling, staying on ElastiCache may be the cheaper choice once you count engineering time. A hybrid setup – compute and cache on Hetzner, specific managed services on AWS – is often the pragmatic middle ground.

How we run the migration

Caching migrations fail on surrounding assumptions, not on Redis itself. The data is easy to move. The connection handling, the failover behaviour, and the observability are where problems hide. We test compatibility and performance rather than assume it. A typical migration runs like this:

1. Baseline the current cache. We measure your real command volume, hit rate, peak memory, and latency on ElastiCache so we have numbers to compare against, not guesses.
2. Size the Hetzner target. Match RAM to your peak working set with headroom, then pick the instance. There’s no point paying for a larger AWS-style node if your working set is 800 MB.
3. Provision and harden. We stand up Redis on a private network, lock it down (no public exposure, TLS in transit, authentication), and configure persistence and eviction policy to match how you actually use the cache.
4. Set up failover and backups. A replica and automated backups replace what Multi-AZ gave you on AWS. If it can be automated, we automate it – provisioning, failover, and recovery included.
5. Wire up observability first. Dashboards, logs, alerts, and a tested rollback path go in before the cutover, not after. You should be able to see memory pressure and eviction rates in real time.
6. Cut over gradually. Dual-write or warm the new cache, shift read traffic, watch the metrics, and keep ElastiCache running until the Hetzner layer has proven itself under real load. Then decommission.

Because a cache can be rebuilt from its source of truth, the cutover carries far less risk than a database migration. That’s what makes caching a good first candidate when a team wants to test whether moving off AWS is worth it before committing to anything larger.

The number that matters

For a single 1 GB cache node, the monthly difference between ElastiCache and managed Redis on Hetzner might be twenty or thirty euros – easy to ignore. Multiply that across replicas, environments (dev, staging, production), and NAT Gateway charges, then run it for a year, and it turns into thousands. On mid-tier SaaS workloads the caching and transfer savings alone often cover the cost of the managed service several times over.

If you’re paying ElastiCache prices for a stable, EU-bound cache, it’s worth putting real numbers next to a Hetzner alternative. We can baseline your current setup, model the savings, and run the migration end to end – and if the math says stay on AWS, we’ll tell you that too. Talk to our team to see what your caching layer would cost on Hetzner.