AWS vs Hetzner: Managed-service breadth vs raw price-performance in Europe

Everything managed, or everything yours?

Put an AWS architect and a Hetzner veteran in the same room and they will disagree about what a cloud is for. The first sees a platform that absorbs operational work: queues, identity, warehouses, failover, all of it someone else's problem. The second sees a fleet of very capable machines in European data centers, priced so that running your own software on them is a rational choice.

Both positions are coherent. AWS sells leverage, and you pay for it in money and complexity. Hetzner sells hardware and a clean API, and you pay for it in engineering responsibility. The question is not which company is better run, because both are excellent at what they do, but which of those two bills your team is better equipped to settle.

What follows compares the platforms on architecture, developer experience, commercial behavior and physical estate. AllCloudShop supplies an AWS account and a Hetzner account, each operated by the buyer under that provider's own terms.

Two very different menus

The four gaps that matter

Managed services versus software you install

On AWS, a queue is SQS, a cache is ElastiCache, a warehouse is Redshift and a database is RDS. On Hetzner, a queue is RabbitMQ that you installed, a cache is Redis that you installed, and a database is PostgreSQL that you installed and now must back up, patch, monitor and fail over. That is the central trade, and everything else follows from it.

Traffic economics

Outbound data transfer is a headline cost driver on hyperscalers and a rounding error on Hetzner, where each server includes a large monthly traffic allowance. For media-heavy, download-heavy or API-heavy products, this single difference can outweigh every other consideration. The bandwidth allowances article explains how providers structure these allowances.

Resilience is designed, not inherited

AWS gives you availability zones, cross-zone load balancing and managed failover for databases, so a well-built system survives a data center problem without human intervention. Hetzner gives you locations and an API; if you want multi-location redundancy you build it, test it and own the runbook. Teams comfortable with that responsibility get excellent value. Teams that assumed the platform handled it get an outage.

Governance depth

Fine-grained IAM, service control policies, audit trails and a compliance portfolio covering many sectors are a genuine AWS advantage for regulated buyers. Hetzner offers projects, API tokens, two-factor authentication and German and Finnish data centers operating under European law, which satisfies a great many European requirements but does not attempt the same breadth of attestations.

Daily experience for engineers

Hetzner Cloud is refreshingly small. The console shows projects, servers, volumes, networks, firewalls and load balancers, and that is roughly the whole surface. Creating a server with cloud-init, attaching a volume and opening a firewall rule takes minutes, and the hcloud CLI mirrors the API closely enough that scripting is simple. Snapshots and backups are straightforward, and the rescue system saves you when a kernel update goes wrong.

AWS is the opposite kind of tool: enormous, consistent in its own way, and rewarding to learn. Once a team understands IAM, VPC design and CloudFormation or Terraform patterns, it can express very sophisticated systems declaratively. The price is that the same team will spend real time on permissions debugging and service selection that a Hetzner user never thinks about.

1. Provisioning: an EC2 instance inside a subnet with a security group and role, versus a cloud server in a project with a firewall attached.
2. Kubernetes: EKS with managed node groups, versus a self-managed cluster using Hetzner's cloud controller manager and CSI driver.
3. Backups: automated RDS snapshots and point-in-time recovery, versus scheduled server backups plus your own database dumps.
4. Scaling: Auto Scaling groups reacting to metrics, versus API-driven server creation you script yourself.

Anyone new to the Hetzner model should read the cloud servers and projects guide, and teams planning to self-host data stores should weigh the operational load described in the managed versus self-hosted comparison.

What the business side should weigh

Hetzner is a straightforward supplier relationship. You sign up, you consume, you get an invoice, and support arrives by ticket in German or English. There are no account executives shaping a commitment, no marketplace, and no partner tiering. For a European company that wants capable infrastructure without a vendor relationship to manage, that simplicity is the product.

AWS brings apparatus: enterprise agreements, private pricing, professional services, partner networks, training programs and a marketplace for third-party software. Larger organizations need that apparatus, and many enterprise procurement processes are built around it. Smaller teams rarely touch any of it, which is one reason the extra complexity feels unjustified to them.

European data protection is often what brings companies to Hetzner in the first place. Servers in Germany and Finland operated by a German company give a clean answer to questions about where data sits and which law applies. AWS also operates European regions and offers contractual frameworks for the same purpose, but the corporate structure invites more discussion, which the data residency article unpacks.

Where the machines live

Hetzner runs its own data centers in Nuremberg and Falkenstein in Germany and in Helsinki, Finland, alongside locations in the United States and a more recent Asian presence. Owning the buildings and buying hardware in volume is precisely why the platform can offer the specifications it does, and the network between European locations is fast and predictable.

AWS operates regions worldwide, each with multiple availability zones, plus an edge network, Local Zones and direct interconnect options. If your users are spread across several continents, this footprint is not merely convenient; it is the difference between serving them well and apologizing for latency. If your users are all in Europe, much of that reach is capacity you are paying for and not using.

Hardware character differs too. Hetzner leans toward generous core counts, NVMe storage and dedicated-vCPU options for workloads that dislike noisy neighbors, along with dedicated root servers when you want an entire machine. AWS wins on variety: specialized memory sizes, accelerators, network-optimized instances and Arm options all live in one place. The dedicated servers article is useful when deciding whether single-tenant hardware is worth it.

What each does exceptionally well

AWS

Removing operational categories from your backlog. Managed databases with automated failover, serverless compute, global content delivery, queues, identity and observability all exist as first-party services with documented behavior. Multi-account governance and compliance breadth make it acceptable to enterprise and regulated buyers, and the ecosystem means expertise, tooling and integrations are never the constraint.

Hetzner

Raw capability per unit of spend, delivered with an unusually clean API. Generous included traffic, NVMe-backed storage, Arm and AMD options, dedicated-vCPU plans and dedicated root servers give teams room to run demanding workloads without constant cost anxiety. European ownership and European data centers answer sovereignty questions directly, and the platform is small enough to understand completely in an afternoon.

Honest limitations

AWS

Complexity and cost discipline are permanent obligations. Data transfer charges, idle resources and overlapping service choices catch teams repeatedly, and small organizations often spend more time operating the platform than building their product. Getting a human to help requires a paid support plan, which surprises people arriving from providers that include support.

Hetzner

There is no managed Kubernetes, no managed database, no serverless layer and no global edge network, so a large amount of platform work lands on your team. The region list is short compared with a hyperscaler, account verification can take some time for new customers, and the compliance portfolio is narrower than what large enterprise buyers demand. Anyone expecting hyperscaler-style abstractions will be disappointed, because that was never the design goal.

Who belongs on which platform

AWS suits teams that need managed services more than they need spare capacity: startups building event-driven systems, enterprises with audit obligations, products serving users across several continents, and organizations where engineering time is scarcer than infrastructure budget.

Hetzner suits teams with strong Linux skills and European users: bandwidth-heavy applications, self-hosted platforms, CI runners, game servers, data processing that likes lots of cores, and any workload where a predictable machine with a large traffic allowance beats a menu of abstractions.

A hybrid arrangement works surprisingly well in practice. Keep compute-heavy or traffic-heavy workloads on Hetzner and use a hyperscaler for the specific managed services you genuinely need, connected over a secure tunnel. For related reading, see DigitalOcean against Hetzner, Hetzner against Vultr and Scaleway against Hetzner. The hyperscalers versus developer clouds article frames the wider category difference.

Documentation: the AWS documentation and Hetzner docs.

Frequent questions