Hetzner billing surprises: what AWS, Azure, and GCP habits get wrong

Migrating to Hetzner usually comes as a positive surprise — it's hard to argue with the price-to-performance ratio. However, billing surprises can arise later when habits from AWS, Azure or GCP produce results that do not align with expectations.

On AWS, costs broadly follow activity: Stop an EC2 instance and the compute charge stops. Take an EBS snapshot and you only pay for the changes made. If you attach an Elastic IP to a running instance, you don't pay anything for the IP itself. With Hetzner, however, cost follows existence. If a resource is included in your project, a charge accrues, regardless of whether it is running, attached or performing any useful function.

This is not a flaw in Hetzner's design. It reflects a deliberate infrastructure philosophy: when you create a resource, Hetzner allocates real hardware. This allocation persists until you release it explicitly. Understanding this distinction is key to ensuring that your Hetzner bills are predictable. Following the price adjustment on 1 April 2026, each of these patterns now costs significantly more than in Q1.

Powered-off servers are billed at the full server rate

The AWS assumption: stopping an EC2 instance stops the compute charge. You only pay for EBS storage while the instance is switched off; you don't pay for vCPUs or RAM.

Hetzner reality: powering off a server does not affect your invoice. The server, its disk and its allocated IP address remain reserved. You are billed at the full server rate until you delete the server — not just stop it.

Hetzner's billing FAQ is unambiguous: "Until you, the customer, delete your servers, we will bill you for them, regardless of their state. This is because, internally, we allocate full resources to servers regardless of their power state."

A common failure mode is for an engineering team in Nuremberg or Helsinki to snapshot a server before a risky deployment, power it off "temporarily" during a sprint, and then forget about it for six weeks. At the CCX13 rate of €15.99 per month, that forgotten instance costs €192 per year without processing a single request.

Stopping a server is a valid operational step, but it doesn't mean you're paying less. If a server is no longer needed, delete it. Take a snapshot first if you think you might need to restore it; you can create a new server from that snapshot when the time comes.

IPv4 addresses are billed per address, per hour — even when nothing is attached

Since February 2024, Hetzner has billed primary IPv4 addresses separately from the servers to which they belong. Every primary IPv4 address costs approximately €0.50 per month, regardless of whether it is assigned to a running server.

The first trap: IP addresses that outlive their servers. When you delete a server, Hetzner does not automatically delete its IP address. If you keep the address "just in case", and never return to it, you will continue to pay €0.50 per month indefinitely for each unused address. In infrastructure that regularly cycles servers, such as CI/CD pipelines, staging environments and short-lived test instances, unattached IP addresses can accumulate without drawing much attention until the invoice arrives.

The second trap: floating IPs. Floating IPv4 addresses cost €3.00 per month and are billed whether or not they are attached to a server. AWS started charging for all public IPv4 addresses in February 2024 ($0.005 per hour, or $3.65 per month per address), so per-IP billing regardless of attachment is no longer unique to Hetzner. However, the failure mode differs: a Hetzner floating IP reserved as a high-availability failover address that is never actually triggered costs €36 per year.

With 50 servers, each with one primary IPv4 address, that equates to €25 per month in IP charges before any computing is performed. Add two unattached floating IPs and the bill increases further, despite these addresses not delivering any value.

Backups cost 20% of the server price, regardless of how much data is on the disk

The AWS assumption: backup costs correlate with storage consumed. AWS EBS snapshots are incremental and charged per GB of stored data.

Hetzner reality: enabling automatic backups incurs a flat 20% surcharge on the server's price. A CCX13 server costing €15.99 per month would cost an additional €3.20 per month for backups, whether the disk is 2% or 95% full. For this price, seven backup slots are retained on a rolling schedule.

This model affects teams that enable backups by default on all servers as an organisational policy. A fleet of ten CCX13 development servers incurs compute charges of €159.90/month and an additional €31.98/month in backup charges, even though environments like these usually don't require nightly backups.

The 20% surcharge is now applied to a higher base price: backups on a CCX13 now cost €3.20 per month, up from €2.40 per month. This difference compounds across a fleet where backups were enabled and never reviewed. The April 2026 price increase post covered this in the context of general cost increases; the underlying issue is a misunderstanding of the billing model, not just a price change.

Snapshots capture the full disk state, not just what changed

The AWS assumption: EBS snapshots are incremental by design, so each one only stores the blocks that have changed since the previous snapshot. For example, a 100 GB disk containing 8 GB of data produces a snapshot sized closer to 8 GB, and taking a second snapshot of an idle server costs almost nothing.

Hetzner reality: Hetzner snapshots are full images of the disk, not incremental deltas. Each snapshot captures the complete state of the disk at that point in time and is compressed. A second snapshot of the same server is approximately the same size as the first, as there is no deduplication across snapshot versions.

Pricing is €0.0143/GB (up from €0.0110/GB) and is charged on the actual compressed image size. For example, a 160 GB disk with 40 GB of data would produce a 40–50 GB snapshot, costing around €0.57–0.72 per month. This figure may seem manageable, but consider three months of deployment snapshots with no retention policy: ten snapshots at €0.65 each would cost €6.50 per month for disk images that would almost certainly no longer reflect a useful point in time.

The practical rule: take snapshots intentionally and delete them on a schedule. Unlike AWS, there is no incremental cost reduction for keeping fewer recent snapshots. Each snapshot is sized independently.

Cloud servers cannot be scaled down to a size smaller than that initially provisioned

The AWS/Azure/GCP/OCI assumption: compute and storage scale independently. On EC2, for example, EBS volumes are separate resources, so changing from a t3.large to a t3.medium leaves your root volume untouched. Azure's VM resize documentation explicitly states that "the OS and data disks are not affected". On GCP, the machine type and persistent disk are managed via different commands. On OCI, changes to the shape affect OCPUs and memory, while "volume attachments remain the same". Boot disk size is fully decoupled from the compute tier across all of them.

Hetzner reality: CPU and RAM rescaling is reversible on Hetzner. The disk is not. Hetzner's own documentation is direct: "Rescaling to a plan with a smaller disk is not possible, regardless of how much storage you are actually using."

If you resize from a CCX23 (80 GB disk) to a CCX33 (160 GB disk) to handle a temporary traffic spike, you cannot later scale back down to the CCX23 because the disk is now too large. There is no automated solution. Hetzner will not restore a snapshot to a server whose disk is smaller than the source disk of the snapshot — the restore process fails at creation, regardless of how little data was actually on the disk. The only solution is to perform a manual migration: provision a new, smaller server; copy your data across using rsync or an equivalent tool; and then decommission the old server. This method only works if your actual data fits within the target disk and requires planned downtime.

Hetzner provides a "CPU and RAM only" resize option that keeps the disk at its current size and preserves the downgrade path. This option is easy to overlook when the default includes a disk upgrade. If you are resizing for a temporary workload and expect to scale back down, select this option explicitly.

The compounding effect: a larger disk means a larger snapshot. Upsizing from an 80 GB disk to a 160 GB disk doubles the snapshot cost indefinitely, for every snapshot taken from that point onwards, even if the extra disk space is never used.

Dedicated servers ordered through Robot incur a one-time setup fee

Hetzner has two separate ordering systems that work differently: the Cloud Console (console.hetzner.cloud) and Robot (robot.hetzner.com). Cloud servers have no setup fee; you pay hourly from the moment the server is provisioned, and it is ready within seconds. Dedicated servers ordered through Robot are different.

Robot dedicated servers are physical machines allocated specifically to you. They are billed hourly (Hetzner introduced hourly billing for dedicated servers in 2024), but most incur a one-time setup fee charged at the time of provisioning. This fee will appear on your first invoice before any monthly usage accrues. In February 2026, Hetzner raised setup fees, citing hardware acquisition costs.

This fee is most significant for GPU machines, with the costs being relatively high compared to the monthly rate. The GEX44 — Hetzner's entry-level GPU dedicated server — costs €252.64 per month. Its setup fee is €314.16 — 124% of the monthly cost. If you order a GEX44, run it for one hour and then cancel, you will receive an invoice for €314.56. This is the minimum amount, regardless of how briefly it is used.

The AWS/GCP habit that breaks here: spinning up a GPU instance on AWS (g5.xlarge or p3.2xlarge) incurs no setup charge. You pay by the hour, from the first second, and can terminate after an hour, having only paid that hour's rate. With Hetzner Robot, the hardware is dedicated to you and configured according to your specifications, and the one-time provisioning cost applies whether you keep the machine for an hour or a year.

This pattern becomes expensive when the AWS approach is repeated. For example, a team that provisions a GEX44, runs a training job and then terminates it to avoid paying for idle time before provisioning it again the following week will have paid two setup fees totalling €628.32 before a full month of usage has accrued. The setup fee applies with each new provisioning.

The visibility problem worsens the situation. Charges for the Robot dedicated server do not appear in the Hetzner Cloud Console's usage preview, which only covers cloud resources. The actual invoice is sent on the assigned billing date, which may be in the middle of the following month. A team cycling through multiple create-and-terminate runs has no in-console indication of the accumulating setup fees until the invoice arrives.

Two things can reduce the risk of setup fees. Hetzner's Server Auction (Serverbörse at robot.hetzner.com/order/market) lists pre-provisioned dedicated servers without setup fees — the GEX44 appears there occasionally, and ordering through the auction avoids the setup charge. Availability is not guaranteed, and configurations may not match your exact requirements. Secondly, all dedicated servers provisioned through Robot include unlimited traffic on a 1 Gbit uplink, which is a significant advantage over cloud servers, which have monthly traffic quotas per server.

The provisioning time is also different: dedicated Robot servers take 1–3 business days, whereas cloud servers are ready in seconds.

There is no managed NAT gateway; a server with a public IP is open to the internet by default

The AWS/GCP assumption: VMs in private subnets reach the internet through a managed NAT gateway — a cloud service that provides outbound-only connectivity without assigning a public IP to each VM. The VM itself is never directly reachable from the internet, even when making outbound requests.

Hetzner reality: Hetzner has no managed NAT gateway. Servers can be created without public IP addresses and placed on a private cloud network. However, a server with only private access has no outbound internet access by default. To enable outbound internet access for a server, either assign it a public IPv4 address or build your own NAT setup using a separate server with a public IP address to route traffic for the private servers behind it. This requires the configuration of IP forwarding and IPTables MASQUERADE rules. Most teams new to Hetzner skip the NAT architecture and assign public IPs.

The monthly billing cost of a public IP address is €0.50. The security implications are less obvious: a Hetzner server with a public IP address has all ports open to the internet unless a cloud firewall is explicitly attached. Cloud Firewalls are opt-in and are not applied by default when a server is created.

A server with no firewall, or one where a container runtime bypasses host-level firewall rules by writing directly to iptables, can be compromised and used as part of a botnet without the owner noticing. This would show up as a traffic overage on the bill. EU cloud servers include 20 TB of outbound traffic per month, and overages are billed at €1 per TB per server. Recently, a CX32 server running personal projects generated an invoice of €188 for 176 TB of outgoing traffic over a single month — 560 Mbit/s sustained for 30 days — entirely from a compromised server. Hetzner sent warning emails when the server reached 75% and 100% of the included traffic quota. They went unread.

For context: 176 TB from AWS to the internet costs approximately $12,050 at standard pricing. Hetzner's per-TB rate is forgiving; an unsecured, idle server is not.

The correct setup for a server with a public IP address is to attach a cloud firewall when creating the server, allowing only the ports that are actually needed and restricting SSH access to known IP ranges. For architectures where application servers should not be directly reachable via the internet, the pattern is to use private-network-only servers with no public IP. If these servers require outbound internet access, this should be routed through a dedicated egress host — a server with a public IP address configured for NAT. Admin SSH access goes through a separate bastion host using ProxyJump. In small environments, the egress host and the bastion host can be the same VM, but it is better to separate them: the bastion host should be kept minimal and hardened, without extra routing responsibilities. Hetzner's tutorial How to set up NAT gateway for private Cloud Networks covers the NAT setup in full.

Running hcloud server list against hcloud firewall list shows which servers have public IPs and no firewall assigned.

What to do with this

None of these billing behaviours are hidden. Hetzner documents each one. The surprise comes from the mismatch with habits built on other platforms, a gap that widens the more AWS, Azure or GCP infrastructure you have used.

The underlying habit is an existence audit, not a usage review. What is in your project that you did not consciously choose to keep? Powered-off servers, unassigned IPs, orphaned volumes, stale snapshots — none of them announce themselves. Running hcloud server list, hcloud volume list, hcloud primary-ip list, and hcloud snapshot list takes two minutes. The decision about what to keep is usually faster than that.

Two settings are worth establishing as team defaults before the infrastructure grows: automatic backups should be turned off for non-production servers (but enabled explicitly for databases and stateful workloads), and Cloud Firewalls should be attached at creation with a minimal ruleset. Neither is difficult to implement as a policy, but both are difficult to retrofit across an existing fleet.

These patterns are individually minor. However, if left unaddressed across a team that is actively deploying and scaling infrastructure, they can have a significant impact. CloudTally surfaces Hetzner spend broken down by resource type, such as idle servers, orphaned IPs, snapshot accumulation and detached volumes, so these patterns become visible before the invoice, not after.