Blog

Buy a 4 GiB node on GKE or AKS, declare 110 pod slots on it, and only about 72.5% of its memory is schedulable. The rest is reserved before a single pod lands, and rightsizing never gets it back. That is why Kubernetes cost optimization that stops at pod requests often changes less than expected: requests drive scheduling, while invoices are written in node-hours — and several layers sit between the two. This piece covers those layers, the arithmetic that shows which one holds your money, and the discounts that apply whichever it is.

Rightsizing changes a request, not an invoice

A resource request is an input to placement, not to billing. Cluster Autoscaler adds a node when pods cannot be scheduled, and decides whether a node can be removed because “CA simulates kube-scheduler behavior” against the remaining nodes (Kubernetes Autoscaler FAQ). Requests drive both decisions. Neither is a price.

On a node-billed cluster, the billing event is a node appearing, disappearing or changing size. A rightsizing pass that cuts requests by 30% changes the bill only when that changes the node count or, with autoscalers that pick instance types from pending requests, the node size.

Cluster Autoscaler’s removal rule is narrower than most teams assume. “A node is considered for removal when all below conditions hold”: the summed CPU and memory requests of its pods are “smaller than 50% of the node’s allocatable” (DaemonSet and mirror pods “are included by default”, configurable by flag); every pod on it can be moved to another node; and the node has no scale-down-disabled annotation. A node unneeded “for more than 10 minutes” is terminated. The 50% is configurable with --scale-down-utilization-threshold.

For Cluster Autoscaler, read the threshold as a cliff, not a gradient: cutting a node’s requests from 95% to 55% of allocatable frees nothing; from 55% to 45% can free a whole node. Karpenter works differently. Its consolidation has no utilization threshold — under the WhenEmptyOrUnderutilized policy it considers “any node that can be removed or replaced to reduce cost,” deleting a node when “all of its pods can run on free capacity of other nodes” or replacing it with a cheaper one. Which autoscaler you run changes where rightsizing pays.

The slice every node reserves before a pod lands

The number the scheduler can fill is allocatable, not capacity. GKE: “GKE reserves a predefined quantity of resources for system functionality and node reliability. The remaining resources that are available for your workloads are called allocatable resources” (Google Cloud documentation, updated 13 October 2026).

Both platforms publish the formula, and both are regressive — the reserved share falls as the node grows. On GKE node pools created on 1.37 or later, “MemoryReserved = Min(EarlierMemoryReservation, (15 MiB * MaxPodsPerNode) + BaseOverhead)”, with a 500 MiB base overhead on Container-Optimized OS, and “An additional 100 MiB of memory is reserved for Pod eviction thresholds.” AKS reserves “the lesser value of: 20 MB * Max Pods supported on the Node + 50 MB or 25% of the total system memory resources,” plus a memory.available < 100 Mi eviction rule (Microsoft Learn, updated 20 October 2026).

Applied at 110 max pods (Container-Optimized OS on GKE). GKE states reservations in MiB/GiB and AKS in MB/GB, so each column is computed in its vendor’s units; compare the percentages.

Memory only. The GKE column adds the 100 MiB eviction threshold on top of the Min(...) result, as the page presents it; the AKS column follows the page’s own worked examples, which subtract 0.1 GB. 110 max pods is an assumption, not a documented default.

The consequence has nothing to do with your workloads. Buy 16 GiB as four 4 GiB GKE nodes and 11.61 GiB is schedulable; buy it as one 16 GiB node and 13.80 GiB is — 2.19 GiB less for the same memory, lost to node shape alone. On small nodes both vendors cap kube-reserved at about a quarter of memory, which is why the 4-unit row lands at 72.6% and 72.5% from two different formulas.

CPU matters far less: GKE caps CPU reservation at “1 vCPU (1000 mCPU) or less for standard, non-fractional compute instances,” which comes to 80 mCPU on a 4 vCPU node; AKS publishes a table from 60 millicores at 1 core to 740 at 64.

Pod density is paid for in memory

Both formulas contain a term rarely treated as a cost lever: max pods per node. GKE reserves 15 MiB per pod slot, AKS 20 MB — for slots you declare, not pods you run. On a 16 GB AKS node:

Raising max pods from 30 to 110 to improve bin-packing costs 1,600 MB per node — 10% of a 16 GB node. On GKE the same change costs 1,200 MiB, 7.3% of a 16 GiB node. Packing more pods per node is often the right call, but it is a memory purchase at a published rate, and it never shows up as a line item — it shows up as a node you would not otherwise have needed.

Requests-billed or node-billed: the variable that reorders everything

One variable reorders every item on a Kubernetes cost list: whether the platform charges for pod requests or for node-hours. Everything above applies to node-billed clusters. On a requests-billed platform there is no allocatable slice to lose and no bin-packing remainder; rightsizing is most of the game.

Google publishes both prices. GKE Autopilot charges “for the CPU, memory, and ephemeral storage resources that your running Pods request” — general-purpose Autopilot pods at $0.0445 per vCPU-hour and $0.0049225 per GiB-hour in Iowa (us-central1), on demand. A general-purpose n4-standard-4 node — 4 vCPU, 16 GiB — is $0.1814 per hour on demand (Google Cloud pricing pages, read 22 October 2026).

That node’s allocatable envelope is 3.92 vCPU and 13.80 GiB. Bought as Autopilot requests it costs $0.2424 per hour — 33.6% more than the node. So, at list prices, pod-billing is cheaper whenever your requests would fill less than about 75% of the node:

us-central1 on-demand list prices. Autopilot runs on its own container-optimized platform, not on n4 machines, so this compares the same requests priced two ways rather than identical products. Recompute for your region, machine family and discounts.

Two qualifiers move the break-even against Autopilot. First, Autopilot “increases values that don’t meet the required minimums or CPU-to-memory ratios,” so small or unusually shaped pods are billed for more than they request. Second, the $0.10 per cluster per hour fee applies “irrespective of the mode of operation,” so it cancels out here — but GKE’s free tier gives $74.40 a month per billing account, enough for one zonal Standard or Autopilot cluster.

Put the break-even next to Cluster Autoscaler’s default criterion and a band appears that neither vendor prints: below 50% fill the autoscaler can consolidate; above about 75% node-billing wins outright; between the two, a Cluster Autoscaler cluster will not remove the node and pod-billing would have been cheaper at list price. That 60%-ish fill is exactly what many teams choose for failover headroom. With Karpenter or a more aggressive autoscaling profile, the band narrows.

AWS has the same shape with less published detail. EKS Auto Mode keeps node-billing and adds a management fee per instance: the pricing page states no percentage, but in its Example 4 every instance’s fee — $0.03672 against a $0.306 c6a.2xlarge, $0.17208 against a $1.434 total — works out to exactly 12%.

Discounts apply on top of all of this

Spot capacity and committed-use discounts are usually the largest single levers on a Kubernetes bill, and they apply to both billing models: GKE lists Spot and committed-use rates for Autopilot pods as well as for nodes. They change the absolute numbers above, not the logic — run the break-even with the rates you actually pay, and keep interruption-tolerant workloads on Spot only where eviction is acceptable.

The line items with no pod attached

Per-pod cost tools cannot see these, which is why they survive rightsizing.

• The cluster fee. $0.10 per cluster per hour on both GKE and EKS — $73 a month, $876 a year, $8,760 a year for ten clusters, before a node boots (GKE’s free tier offsets one zonal or Autopilot cluster per billing account). Namespaces are free.

• Version drift. EKS extended support is $0.60 per cluster per hour against $0.10 standard; GKE’s Extended channel past standard support is also $0.60. That is $365 a month per cluster for an upgrade you did not do.

• Cross-zone chatter. On AWS, a topology-unaware service mesh generates cross-zone traffic in proportion to pod count rather than business value, and transfer between Availability Zones in the same region is charged at $0.01 per GB in each direction — every cross-zone gigabyte is billed twice.

• Egress through a NAT gateway. The AWS VPC pricing example for US East (Ohio) charges $0.045 per hour and $0.045 per GB processed — roughly $32.85 plus $45 for a 1 TB month. Private node pools pay processing on image pulls at every scale-out; see the cloud egress fees comparison.

• The tier chosen at creation. AKS Free gives “best-effort uptime (no financially backed SLA)”; Standard carries “99.95% availability of the Kubernetes API server” with availability zones. A reliability purchase, sometimes made by accident.

What to measure first

1. Run kubectl describe node for one node of every shape you own and record allocatable against capacity. That ratio is your floor.

2. Per node, sum pod requests and divide by allocatable. Keep the distribution, not the average.

3. Count the nodes in the 50–75% band (with Cluster Autoscaler defaults). That count times the hourly node rate is what the requests-versus-nodes decision is worth to you.

4. Record max pods per pool and multiply the gap between declared and actual peak pod count by 15 MiB (GKE) or 20 MB (AKS).

5. Split the bill into node-hours, cluster fees, data transfer and storage. Rightsizing addresses only the first.

6. Re-run the break-even with your own region, machine family, Spot and committed-use rates, for your three largest pools.

7. Change one pool, wait a billing cycle, compare node-hours rather than requests. If node-hours did not move, the saving was not real yet.

What breaks in production

• A pod with no controller pins its node. Cluster Autoscaler will not remove a node running “Pods that are not backed by a controller object.” One debugging pod started with kubectl run can hold a node for months.

• Local storage does the same. Pods with local storage — hostPath or non-memory emptyDir volumes — block removal unless annotated, which makes scratch space a cost decision.

• A restrictive PodDisruptionBudget stops consolidation. Karpenter is direct about it: “Pods with blocking PDBs will not be evicted by the Termination Controller or be considered for voluntary disruption actions.” A single-replica deployment with minAvailable: 1 is an undrainable node.

• kube-system pods without a PDB, and safe-to-evict: "false" left over from an incident, block scale-down too. Grep for both.

• Trimming limits is a runtime change, not an accounting one. Google’s guidance: “For CPU, configure requests to meet your service-level objectives (SLOs) but leave limits unrestricted,” while “For memory, ensure that the requested allocation matches the memory limit.” A tool that trims CPU limits alongside requests works against that advice.

• Autoscalers can fight. A horizontal autoscaler adding replicas against a vertical one shrinking requests can settle somewhere dearer than either alone.

Which layer is yours

Are you billed for requests or for nodes? If requests, rightsizing and discounts are the programme. If nodes, continue.

What is your fill distribution? Mostly above 75%: node shapes are right and the money is in discounts and the no-pod line items. Mostly below 50%: the autoscaler should already be consolidating, so find what blocks it before touching a request. Clustered in 50–75%: you are paying node prices for request-shaped usage — consider a more aggressive autoscaler or a billing-model change.

Is your node shape wrong? If small nodes dominate, a quarter of their memory goes to kube-reserved. Larger nodes recover allocatable share — and enlarge the blast radius of one node failure.

Kubernetes on infrastructure you choose

If the arithmetic says the platform itself is the line item, the alternative is node-billed Kubernetes on dedicated or bare-metal servers, where there is no per-cluster fee and no managed-platform margin on top of the hardware. INXY.hosting’s DevOps and managed infrastructure team builds and runs Kubernetes clusters on the infrastructure that fits the workload.

Send us the output of steps 1 to 4 and we will show which layer your money is in. For bare-metal economics see the dedicated server pricing guide; if the platform is the problem, cloud repatriation is the next read.

FAQ

Does rightsizing reduce Kubernetes costs?

On a requests-billed platform such as GKE Autopilot, directly. On a node-billed cluster, only when it lets the autoscaler remove or shrink a node. With Cluster Autoscaler that means a node’s requests falling below the scale-down threshold — 50% of allocatable unless configured otherwise — and nothing on the node blocking eviction.

What is node allocatable in Kubernetes?

Allocatable is the portion of a node’s capacity the scheduler may fill. Managed platforms subtract a reservation for the kubelet and system daemons plus an eviction threshold. The share is regressive: about 27% of a 4 GiB node and under 2% of a 128 GiB node at 110 max pods, by GKE’s formula.

Is GKE Autopilot cheaper than a Standard cluster?

It depends on fill. At us-central1 on-demand list prices, buying a 4 vCPU / 16 GiB node’s full allocatable as Autopilot requests costs 33.6% more than the node, so Autopilot is cheaper when requests would fill less than about 75% of each node. Autopilot’s minimum requests and CPU-to-memory ratios push that break-even lower.

Why does max pods per node affect cost?

Both platforms reserve memory per pod slot, not per running pod: 15 MiB on GKE 1.37 and later, 20 MB on AKS. Declaring 110 slots instead of 30 on a 16 GB AKS node removes 1,600 MB — 10% of it — whether those pods exist or not.

What Kubernetes costs do per-pod cost tools miss?

Anything without a pod attached: the per-cluster management fee, extended-support premiums for clusters left on old versions, cross-zone traffic between chatty services, NAT gateway hourly and per-GB processing, idle volumes and load balancers, and the reliability tier chosen at cluster creation.

In measurements of four root DNS anycast networks taken in 2015 and 2016 from RIPE Atlas probes, the 8-site network sent 16% of the probes it measured to a site other than their lowest-latency option; the 144-site network sent 76% (Schmidt, Heidemann and Kuipers, PAM 2017). Median latency was about 30 ms across the range. The bigger network missed its best site far more often and was no faster in the median. Site count is the easiest number to compare between DNS providers — and the measurements say it is not the number that sets your latency.

What anycast DNS actually is

Anycast DNS announces one nameserver IP address from many separate locations, so a query sent to that address is answered by whichever location the Internet’s routing system delivers it to. RFC 4786 defines anycast as “the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations.”

There is no load balancer and no geography in that decision: “The routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates.” The region whose queries land on one node is its catchment: “the topological region of a network within which packets directed at an Anycast Address are routed to one particular node.”

“Nearest” is a routing claim, not a distance claim

BGP does not measure latency; it selects paths by policy and AS path. RFC 4786 adds that “the population of clients using individual anycast nodes is neither static, nor reliably deterministic.”

The PAM 2017 authors call the gap a mishit: “We define mishits as the cases when VPs are sent to sites other than the lowest latency.” Their explanation is structural: “Anycast relies on BGP to map users to sites, but BGP only approximates shortest-path routing.”

A 2023 census of DNS, CDN and cloud anycast measured the severe version, which its authors call polarization: “when an anycast client is served by a distant site for some specific prefix,” even though a nearer site could serve it faster. Of 7,986 known anycast prefixes, the authors flagged potential polarization in “at least 2273 (28.5%).” Polarization “can add 100 ms or more to the round-trip time if traffic goes to a different continent” (Rizvi, Huang, Esrefoglu and Heidemann, PAM 2024). The causes they name — incomplete connectivity to Tier-1 providers and route leakage by regional networks — are properties of a provider’s transit and peering, not of its site count.

More sites do not buy lower latency

Source: Schmidt, Heidemann and Kuipers, “Anycast Latency: How Many Sites Are Enough?”, PAM 2017, Table 1. Between 5,351 and 6,464 RIPE Atlas probes per root, measured September 2015 to April 2016. The penalty is the extra latency of a mishit compared with the best available site.

L-Root missed its best site most often and paid most per miss — a median 24 ms, with a quarter of misses costing 82 ms or more — while C-Root paid a median 5 ms. Yet median latency was about the same: “Our data shows similar median performance (about 30 ms) from 8 to 144 sites,” suggesting that “as few as twelve sites” can provide reasonable latency if they are well distributed and well connected. The paper’s abstract states the general finding: “geographic location and good connectivity have a far stronger effect on latency than having many sites.”

Two cautions. The data is ten years old and all four networks have changed since. And these are root servers, not commercial managed DNS. The mechanism transfers; the percentages do not — which is why step 3 below measures your own.

Anycast routes the resolver; steering needs the user

An authoritative nameserver never sees your user, only the recursive resolver: “the source address is that of the Recursive Resolver rather than of the query originator” (RFC 7871). For the lookup itself that is fine. The problem appears when the answer is a routing decision: geo and latency policies — the ones priced at a premium below — choose an answer from the location they can see, which is the resolver’s.

EDNS Client Subnet (ECS) lets a resolver pass a truncated client prefix so the authoritative server can tailor its answer. It changes the answer, not which anycast site receives the query. And it comes with a warning label: RFC 7871 is Informational, not Standards Track, describes the option as “not for general purpose deployment,” and states: “Due to the high cache pressure introduced by ECS, the feature SHOULD be disabled in all default configurations.” Resolver support varies: Cloudflare’s 1.1.1.1 does not send ECS, while Google Public DNS sends it to authoritative servers that implement it correctly.

So geo steering is only as accurate as your users’ resolvers allow. Ask a provider which resolvers it actually receives ECS from — not whether it “supports ECS”.

What anycast DNS costs

Published rates, read 22 October 2026.

Route 53 and Google Cloud DNS charge the same standard rate — $0.40 per million to one billion queries a month, $0.20 above — and the same $0.70 for geo-style steering. They differ on latency-based routing, which Route 53 prices at $0.60, on zones, and on free queries: Google states “There is no free tier for Cloud DNS,” while Route 53 provides alias queries to AWS resources such as CloudFront and load balancers at no additional cost.

The steering line varies more than the query line. No price list here has a line item for anycast itself. Steering carries a 50–75% premium at the hyperscalers, is a separate add-on at Cloudflare, and is listed free at Bunny.

At 100 million standard queries a month on one zone: about $40.50 at Route 53, $40.20 at Google Cloud DNS, nothing at Cloudflare and $1 at Bunny. At one billion geo-steered queries: about $700 at either hyperscaler, nothing listed at Bunny, and no published per-query figure at Cloudflare. A spread from zero to $700 with no published performance basis has to be settled by measurement.

What breaks in production

1. Instability that is invisible in aggregate. In 2015–16 root DNS measurements, anycast route flipping occurred “in about 1% of (VP, service) pairs,” and “80% of unstable pairs of VP and anycast services are unstable for more than a week”; for the rest, “routes are stable for hours, days, or longer” (Wei and Heidemann, IEEE TNSM, 2018). Aggregate dashboards show the stable majority.

2. TCP queries get cut. Responses too large for UDP, such as large DNSSEC-signed answers, are retried over TCP, which needs the whole exchange to reach one node. TCP flipping “does occur in about 0.15% (VP, letter) combinations,” and when it occurs, “more than 20% of DNS queries over TCP do not complete.”

3. Health-triggered withdrawal moves a whole catchment. RFC 4786 describes coupling the route to the service, so that “availability of the service triggers the route advertisement, and non-availability of the service triggers a route withdrawal.” A flapping health check does not drop one node’s queries; it moves a whole catchment, twice.

4. Record-level failover waits on TTLs. Withdrawing a nameserver route fails over at BGP speed. A health-checked record that changes its answer fails over only as fast as resolvers expire the old one — and a share of resolvers hold records longer than instructed. See our multi-CDN strategy piece for the measurements.

5. Measuring from the wrong place. Querying your nameservers from your own monitoring region tells you about one catchment. Mishits and polarization are properties of specific client networks, so a check that passes everywhere you look is the expected result.

Before you buy: seven measurements

1. Pull 30 days of resolver source addresses from your current authoritative logs. Rank by query volume.

2. Map the top 20 resolver networks to the regions your users are actually in. The gap between those two lists is the error ceiling on any geo or latency steering.

3. Measure resolution latency from inside those networks, not from your own infrastructure or a synthetic monitoring region.

4. Ask each shortlisted provider about its transit and peering in each region you care about. Polarization’s named causes are transit gaps and route leaks, so this question predicts your tail latency.

5. Ask which resolvers it receives ECS from, and what prefix length it honours.

6. Price your actual monthly query count against the per-million rate and the steering premium separately, and check which of your queries are free.

7. Run both providers in parallel on a delegated subdomain for a full billing cycle before cutting over — sequencing is in our CDN migration playbook.

Deciding

Is DNS resolution a measurable share of your page-load time? Because resolvers cache answers, often it is not. Measure it before buying on latency. If it is small, buy anycast DNS for availability and DDoS absorption, and judge providers on catchment stability and transit rather than site count.

Does your DNS answer depend on where the user is? If you use geo or latency steering, its accuracy is capped by your users’ resolvers, and ECS coverage matters more than site count. If every user gets the same answer, the steering premium is money you do not need to spend.

Does your failover plan depend on DNS, or on something faster? If your recovery objective is shorter than your TTL plus resolver drift, DNS is the wrong layer for it. Anycast DNS makes the lookup resilient; it does not make the application resilient.

Authoritative DNS from INXY.hosting

INXY.hosting sources authoritative DNS from multiple providers on one invoice, so the steering premium can be priced across vendors and the choice made on catchment quality rather than site count.

Send us 30 days of resolver logs and the regions that matter, and we will run steps 1 to 3 against your own traffic first — see authoritative DNS and protection services. The same anycast mechanics underpin content delivery, covered in what is a CDN.

FAQ

What is anycast DNS?

Anycast DNS announces one nameserver IP address from many separate locations, so each query is answered by whichever location the Internet’s routing system delivers it to. RFC 4786 defines it as making one service address available in multiple discrete, autonomous locations. BGP, not geography, decides which location answers.

Does anycast DNS send queries to the nearest server?

Not reliably. BGP approximates shortest-path routing rather than measuring latency. In 2015–16 measurements of four root DNS networks, the share of probes sent to a site other than their lowest-latency one ranged from 16% at 8 sites to 76% at 144, with median penalties of 5 to 24 ms (PAM 2017).

How much does anycast DNS cost?

Published rates differ more on steering than on plain queries. Cloudflare’s Free, Pro and Business plans and Bunny charge nothing for standard queries. Amazon Route 53 and Google Cloud DNS both charge $0.40 per million, halving above one billion a month, and $0.60–$0.70 per million for latency or geo routing.

Are more anycast sites always better?

No. In the PAM 2017 study, median latency was about 30 ms whether a root DNS network had 8 sites or 144, while the larger networks sent more clients to a site other than their best one. The authors found geographic distribution and good connectivity mattered far more than raw site count.

Does anycast DNS break TCP queries?

Rarely, but badly where it happens. In 2015–16 root DNS measurements, TCP route flipping occurred in about 0.15% of vantage-point/root-server combinations, and where it occurred more than 20% of DNS queries over TCP did not complete (IEEE TNSM, 2018). TCP matters for responses too large for UDP, such as large DNSSEC-signed answers.

What is EDNS Client Subnet and do I need it?

ECS passes a truncated client prefix to the authoritative server so it can tailor the answer to the user’s network rather than the resolver’s; it does not change which anycast site receives the query. RFC 7871 is Informational and recommends disabling it by default. Support varies by resolver — Cloudflare’s 1.1.1.1 does not send it.

A second CDN looks like insurance until the first invoice arrives. Priced band by band on Bunny's published Volume ladder, 2 PB a month costs at least 20% more split evenly across two accounts than on one — 38.5% more if you take the 1–2 PB rate from Bunny's marketing page rather than its documentation. The ratio you send to the second provider sets your bill, your cache hit ratio and your real failover time at once. This article settles how to pick it.

What a multi-CDN strategy actually is

A multi-CDN strategy delivers the same content through two or more CDN providers, with a steering layer deciding which one serves each request. It is built three ways: DNS-based steering, client-side selection inside the player or application, and manual failover by changing a record when something breaks. They differ in how fast they react and in what they can measure.

DNS steering is the common choice because it needs no application change; Cloudflare's Load Balancing documentation, for example, lists five global steering policies — Standard, Geo, Dynamic, Proximity and Least Outstanding Requests (Cloudflare, 2026). Client-side selection reflects real delivery performance, because the player measures what the user got, but it requires you to own the client.

The decision most teams skip is not which mechanism, but what share of traffic the second provider carries in steady state. That number reorders every other answer below.

The split ratio sets the bill, and the worst ratio is 50/50

CDN volume pricing is a descending ladder. Where it is applied band by band to one monthly total — which is how the published labels read ("First 500 TB", "Next 10 TB"), although neither Bunny page states the method — splitting the traffic restarts each provider's meter at the top band. Because the marginal rate falls as volume rises, the penalty on two identical ladders is largest at the even split, the configuration that looks most redundant.

The table isolates the effect by pricing one published ladder against itself, one account against two. A real second vendor has a different ladder, so read it as the mechanism, not a quote.

Rates: bunny.net/pricing/cdn, bunny.net/docs/cdn/pricing and fastly.com/pricing, all read 15 October 2026. Bunny's two pages disagree on the 1–2 PB band, so both rows are shown. Fastly bills "per GB per Region per month"; its free first 100 GB is included.

Three things fall out of that table no single provider will say.

Below the first band boundary, splitting is free. At 500 TB both halves stay inside Bunny's first Volume band, so the split costs nothing. Tier dilution only exists once your single-provider volume has crossed a discount boundary — so below that point the cost argument against a second CDN does not apply.

The cheapest split is the one that protects you least. At 2 PB, moving from 50/50 to 90/10 cuts the premium from 20.0% to 5.3% on the documentation rate (38.5% to 9.2% on the marketing rate), and 95/5 cuts it to 2.7% (4.6%). Every point saved there comes from traffic taken away from the provider you are paying to keep warm.

Above a certain volume the comparison stops being possible. Fastly's public rate card ends after the "Next 10 TB" band, with "Contact us for high-volume pricing" above the table; Bunny's Volume ladder ends at "2 PB+" with "Contact us". A multi-CDN plan at real scale is a negotiation, and the published cards are only your opening anchor. Before assuming the split is cheap, see how to cut CDN costs before you add a second provider.

Failover is slower than your TTL, and lowering the TTL makes it worse

DNS-based CDN failover is not instant. Detection takes the health-check interval multiplied by the retry count — Cloudflare's own monitor documentation works an example in which five retries at a 20-second timeout mark an endpoint unhealthy "after approximately 120 s (6 × 20 s)" — and the record change then has to outlive every resolver cache still holding the old answer.

The instinct is to cut the TTL to 30 or 60 seconds. Measurement data says that makes the tail worse rather than better. Bhowmick et al. measured 27,131 resolvers across 9,514 autonomous systems. At a 60-minute TTL, 0.31% of the resolvers tested extended it; as the test TTL was lowered step by step to one minute, the share rose to 8.74% of the resolvers measurable from at least five vantage points. The authors estimate the effect reaches "at least 38% of the popular websites that use CDNs" (Bhowmick et al., PAM 2023).

So the shortest TTL you set is not the longest wait you get. Close to one in eleven of the resolvers measured extended a short TTL, which keeps their users on a CDN you have already pulled from rotation. Plan the failover window as detection plus TTL plus a non-compliant tail.

The standby cache is the cost nobody quotes

Each CDN maintains its own cache. A provider carrying 5% of your traffic sees 5% of your request volume, which means the long tail of your catalogue is never resident in it. When you fail over, you do not move traffic onto a warm CDN. You move it onto a cold one, and every miss becomes an origin fetch.

The arithmetic is unforgiving because miss rate, not hit rate, is what the origin feels. Fastly's engineering team puts it plainly: "If your CHR increases from 90% to 95%, it's not merely a 5% improvement; it actually halves your origin load" (Fastly, 2024). Run that backwards. A standby whose hit ratio starts at 50% instead of a steady-state 95% delivers ten times the origin fetch volume of the provider it just replaced — at the exact moment you are already in an incident.

Fastly's shielding case study shows the scale in production: with shielding, one customer's origin load was "capped well below 5GiB/s"; without it, at a similar hit ratio, it settled "in the low 20GiBs range," which Fastly describes as 4x the shielded load (Fastly, 2024). Shielding suppresses that, and shielding is per-vendor — provider B's shield cannot read provider A's cache. Two CDNs means two independent fill paths against one origin.

That is the hidden cost of a multi-CDN strategy: it appears on neither CDN invoice. It lands on your origin egress bill. If your origin sits in a hyperscaler, see cloud egress fees comparison for what those fetches cost per GB.

What breaks in production

• The cold standby turns a CDN incident into an origin incident. The failure mode is not that the second CDN is slow. It is that your origin saturates while it fills. Load-test the failover at real traffic, not at 1%.

• Shielding inflates the miss count you monitor on. Fastly documents that "a request that does reach your origin server will be counted as two misses, one at the edge, and one at the shield." Fastly adds that this "will result in a cache hit ratio (CHR) that may be lower than you expect" — enabling shielding can make the reported hit ratio look worse while origin load falls. Judge it on origin bytes, not on CHR.

• Anycast routing can move you into a more expensive billing region. Fastly's billing documentation states that Anycast IPs "will route a request to the nearest POP located in a billing region that may charge a higher rate." Two providers means two independent region maps, and traffic you believed was European can be billed otherwise at one of them.

• Package terms can carry geographic caps. Fastly's Deliver packages carry the footnote "No more than 10% of traffic may originate in the African, Indian, or South Korean billing regions." A steering policy that shifts traffic by latency can walk a contract into breach without anyone reading the clause.

• You cannot attribute a failure without a per-response identifier. When a user reports a broken session, nothing in a standard response says which CDN served it. CTA-5006, Common Media Server Data, defines response headers that give "a uniform method for media servers and services to communicate data about media objects," and AWS Elemental MediaPackage uses its n key for "The identifier for the MediaPackage origin endpoint of this object" (AWS, 2026). Without an equivalent header or log field at every provider, a multi-CDN incident review is guesswork.

Measure these seven things before you split traffic

1. Your single-provider monthly volume against your current ladder. Find the next band boundary. Below it, tier dilution is zero and the cost objection does not apply to you.

2. Origin egress over 30 days, in bytes, not requests — the number a second cache will increase.

3. Cache hit ratio by content class — hot catalogue versus long tail. The long-tail ratio is what the standby will actually deliver on day one.

4. Health-check detection time end to end: interval × retries, measured, not assumed. Then add your TTL.

5. Resolver behaviour on your own zone. Change a record, then watch the decay curve of requests to the old target. That tail is your real failover window.

6. A parallel run. Serve a sampled share of live traffic through the candidate provider for a full week including a weekend peak, and compare delivered performance from the client rather than from either vendor's dashboard. CDN optimization: cache hit ratio, TTL and origin load covers the measurement setup.

7. Your contracts. Minimums, commitments, region caps and the overage rate above the published card — for both providers, in writing, before the split.

Choosing the ratio

Three questions decide it, in order.

Is your volume past a discount boundary? If not, choose the split on resilience grounds alone. If it is, price 50/50, 90/10 and 95/5 against your actual ladder first — at 2 PB on Bunny's ladder, the gap between 50/50 and 95/5 is 17 to 34 percentage points.

Can your origin survive the standby filling at full traffic? If not, give the second provider a higher steady-state share, paid for as cache warmth, not redundancy. A 5% standby is a 5% guarantee.

Can you attribute a failure to a provider within one incident? If not, build that before the second CDN, not after. A multi-CDN setup you cannot debug is two vendors blaming each other.

Read together, the three sections above point one way: a single well-chosen provider with shielding beats a badly-split pair, and a share chosen deliberately — priced against your ladder and tested against your origin — beats both a default 50/50 and a reflexive 95/5. We buy across providers rather than for one, so the split ratio is a configuration choice here, and one invoice covers every provider in the test. Bring us 30 days of volume, origin egress and hit-ratio figures and we will price the split three ways before you commit to either vendor — see how our data delivery service handles multi-provider sourcing. If you are splitting because one provider is exiting, the CDN shutdown migration playbook sequence applies first.

FAQ

Does a multi-CDN strategy always cost more?

Not always. Below your provider's first discount boundary, splitting traffic costs nothing extra, because both halves stay in the same band. Above it, the penalty grows with volume and peaks at an even split — on Bunny's published Volume ladder, 11.1% at 1 PB a month and 20% to 38.5% at 2 PB, depending on which Bunny page you price from.

How fast is multi-CDN failover in practice?

Slower than the TTL suggests. Detection takes the health-check interval times the retry count, and Cloudflare's documentation gives roughly 120 seconds for six 20-second attempts. The record change then has to expire in every resolver cache, and measurement data shows a minority of resolvers extend short TTLs beyond their stated value.

Should I lower my DNS TTL to speed up failover?

Within limits. A 2023 study of 27,131 resolvers found 0.31% extending a 60-minute TTL, rising to 8.74% as the test TTL was lowered to one minute, so very short TTLs increase the share of resolvers that hold your record longer than instructed. A short TTL shortens the median failover and lengthens the tail.

What traffic share should the second CDN carry?

Enough to keep its cache representative of your catalogue, which for most workloads is more than the 5% a hot-standby design implies. Measure your long-tail hit ratio at the candidate share during a parallel run; if it is far below your primary's steady state, the standby is not yet a standby.

Does multi-CDN increase origin load?

Yes. Each provider fills its own cache independently and each vendor's shield is private to that vendor, so the same object can be fetched from origin twice. The effect is largest on long-tail content and shows up on your origin egress bill rather than on either CDN invoice.

Can I run multi-CDN without changing my application?

Yes, with DNS-based steering, which is why most teams start there. The tradeoff is measurement: DNS steering decides from health checks and routing data rather than from what the user actually received. Client-side selection reacts to real delivery performance but requires you to control the player or application.

Most Hetzner vs OVH comparisons line the two up on monthly price. That leaves out the line that hits first: the setup fee. Since Hetzner’s 15 June 2026 price adjustment, its dedicated setup fee works out to about half of one month’s rate — €49.00 on a €97.30 AX42-1, €799.00 on a €1,597.30 AX162-3 (Hetzner Docs). OVHcloud charges a full month: Advance-3 is €199.99 a month with a €199.99 installation fee on its European site, and $255 with $255 on its US site — where, and only where, the fee is included on a twelve-month commitment (OVHcloud). For anyone who will not keep a server for a year, that difference reorders the comparison.

The fee as a share of the rate

Both providers publish a monthly rate and a one-time fee. Neither publishes the number that compares across them: the fee as a share of the rate.

On Hetzner’s price-adjustment page, the standard dedicated configurations carry setup fees between 47.4% (SX65-2) and 50.4% (AX42-1) of the monthly rate. On OVHcloud, every Advance and Scale listing we could read — European and US — shows an installation fee equal to one full month.

Spread over the time you keep the server, the fee becomes a premium on the monthly rate, and it shrinks as 1/N:

Premium = setup fee ÷ (monthly rate × months). Hetzner AX42-1: €97.30/month + €49.00 setup. OVHcloud Advance-3 2024: €199.99 + €199.99 (EU, excl. VAT) or $255 + $255 (US). The machines are not equivalent hardware, so only the fee structure is compared here. INXY.hosting charges no setup fee and has no minimum term.

Two things follow. Below twelve months, Hetzner’s entry cost is about half of OVHcloud’s. At twelve months and beyond, the setup fee shrinks to a few percent of the bill on either provider — at which point the monthly rate, not the fee, decides the comparison. So tenancy length decides the entry cost; it does not decide which provider is cheaper overall.

One caveat on OVHcloud’s waiver. The US Advance FAQ states: “The setup fees for your dedicated server are included for any commitment period of 12 months or longer.” The European Advance page lists the same one-month fee and says nothing about commitment. If you are buying in Europe — where Hetzner’s dedicated servers are — do not assume the waiver applies; get it on the order form before signing the term that is supposed to buy it.

Which is cheaper to set up, Hetzner or OVHcloud? Hetzner’s dedicated setup fee is about half of one month’s rate. OVHcloud’s installation fee equals one full month; its US site includes it on commitments of twelve months or longer, while its European site does not mention a waiver. Below twelve months, Hetzner costs less to start.

What each one charges to start

Hetzner sells from three inventory pools with three fee structures — not three tiers of one product.

Hetzner: price-adjustment page (created 15 June 2026, last changed 8 July 2026) and Server Auction FAQ. OVHcloud: European and US Advance pages and US price page. Prices excl. VAT. All read 12 October 2026.

The -LTD setup fee is nearly flat. €39.00 applies across most of the pool — 50.5% of a month on the €77.30 AX42-1-LTD, 12.3% on the €317.30 AX162-1-LTD. Two models (AX41-1-LTD and EX44-1-LTD) carry €0.00, and three step up: EX131-2-LTD to €49.00, DX182-1-LTD to €51.00 and SX295-1-LTD to €59.00. Hetzner sells the pool while supply lasts, so repeat orders are not assured — but on a one-off order the larger server has the smaller relative entry cost.

The Server Auction has no setup fee at all. Hetzner’s FAQ: “There are no setup fees for these servers,” and “The cancellation period for these servers is usually immediately.” These are “old” servers re-listed after a previous customer cancelled, “designed for people who already have experience in server administration.” For a short load test it is the zero-entry-cost option on either vendor.

Bandwidth: both say unlimited, and they mean different things

Hetzner meters only the faster port. Its traffic documentation: “All root servers have a dedicated 1 GBit uplink by default and with it unlimited traffic,” while “Inclusive monthly traffic for servers with 10Gbit uplink is 20TB,” charged at “€ 1 ($1.20)/TB for overusage.” Only outbound traffic counts: “We do not count incoming and internal traffic.” The AX42 product page confirms it: traffic “is unlimited and free of charge,” except on servers with the 10G uplink add-on. The upgrade turns an unmetered service into a metered one — see metered vs unmetered bandwidth.

OVHcloud does not meter, with one regional exception. Its US bandwidth page says “Our bandwidth is unlimited and unmetered across all dedicated servers,” with no exception on that page. The US Advance FAQ adds one: unmetered traffic applies “with the exception of solutions and services hosted in our Asia-Pacific data centers.” For a server in Singapore, Mumbai or Sydney, ask for the traffic terms in the quote.

Guaranteed throughput differs by range, not just by vendor. OVHcloud’s European Advance page lists “3Gbps unmetered and guaranteed public bandwidth”; its US Advance page lists 1 Gbps unlimited public bandwidth, upgradable to 5 Gbps. Hetzner’s AX42 lists a 1 Gbit/s port with 1 Gbit/s guaranteed. On the Advance range, OVHcloud guarantees more.

For ingest-heavy work — backup targets, log sinks, replication receivers — Hetzner’s outbound-only rule keeps inbound free even on a metered 10G uplink, and OVHcloud counts nothing outside Asia-Pacific. Both work; the dedicated server pricing line items decide more than port speed.

Where each one physically is

Location rules providers out rather than reordering them, so it is where the comparison should start.

Hetzner: location labels from the price-adjustment page (US and Singapore appear only under cloud servers); SLA from Hetzner’s Cloud SLA document. OVHcloud: sites from the global availability page; commitments from the US Dedicated Server SLA (effective 6 January 2025). Read 12 October 2026.

A two-country footprint suits one buyer and rules out another. For EU data residency it is simple and defensible. For a latency target in North America or Asia it ends the conversation.

The SLAs are not symmetric. OVHcloud’s US SLA pays service credits of 10%, 30% or 100% of the monthly fee as availability drops below the commitment, below 99.00% and below 95.00%, excluding one-time fees and capped at 100% of the month. Hetzner’s published SLA covers Cloud servers and vServers at 99.9%; we found no dedicated-server equivalent. Treat it as unpublished rather than absent, and ask for it in writing.

For Asia-Pacific, confirm in the quote. OVHcloud’s global availability page marks Rise, Advance and Scale at all three APAC sites, while the APAC traffic exception above applies there. Confirm range, site and traffic terms before ordering.

Contracts, generations and repricing

Hetzner’s commercial shape is short. The AX42 page states “No minimum contract term” and “Cancellation period: immediately.” You pay about half a month to start and can leave the same day, which makes it a natural home for anything exploratory.

OVHcloud’s shape is the mirror image — on its US site. There the commitment buys the fee waiver, so the cheapest entry is also the longest lock-in. For a workload already sized for years, that is a fair trade; for one still being measured, it turns an experiment into a term contract.

Hetzner reprices on change, not on renewal. “For orders placed before 15 June 2026, but delivered after 15 June 2026, the previous prices will apply,” and “certain changes to servers with legacy pricing may trigger a switch to the current pricing.” Your cheapest server is your oldest one, and a consolidation that touches it can move that capacity onto current rates. Model fleet changes at today’s prices.

OVHcloud model names outlive their hardware. The US price page lists 2024 and 2026 Advance ranges under the same names, on different processors:

OVHcloud US price page, read 12 October 2026; the 2026 listings are marked “Coming Soon”. The European page shows the same pattern: Advance-1 2024 at €114.99, 2026 at €159.99 (+39.1%).

These are different machines, not a price rise on the same one — Advance-5 even changes CPU vendor. A quote for “Advance-5” without a generation year could describe either server. Put the generation and CPU model on the order.

A third option: no setup fee, no minimum term

The trade-off above — a cheap, flexible entry or a committed, waived one — is a feature of these two providers’ pricing, not of dedicated hosting. INXY.hosting dedicated servers have no setup fee and no minimum term, so the entry premium in the first table stays at 0% whatever the tenancy.

• No setup fee — the entry premium is 0% at every tenancy length

• No minimum term — leave when the workload ends

• Matched-spec quotes on request, priced next to the published Hetzner and OVHcloud rates

• Pay in fiat or crypto

What breaks in production

1. The commitment was meant to buy the waiver, and the order form did not say so. The fee sits on the price card unconditionally; the waiver lives in an FAQ — and only on OVHcloud’s US site. Reconcile them before signing.

2. The 10G uplink was ordered for headroom and arrived with a meter. A 1 Gbit Hetzner port is unlimited; the 10 Gbit add-on is 20 TB, then €1/TB.

3. Backup and replication were sized against the wrong direction. Hetzner counts outgoing traffic only, so a replication target receiving 40 TB and serving 2 TB bills on the 2 TB. Check the direction rule per product.

4. The APAC server inherited European terms in the plan but not in the contract. Unmetered on the bandwidth page, excluded in the Advance FAQ.

5. The short-tenancy server was bought from the standard range. A six-week load test there pays a ~50% setup premium that the Server Auction or a zero-fee -LTD model would not.

6. The fleet consolidation repriced the survivors. Changes to grandfathered Hetzner servers can move that capacity onto current pricing.

Seven steps before you order

1. Write down the tenancy in months. If the honest answer is “we do not know”, treat it as under twelve.

2. Decide the region first. Hetzner’s dedicated range is Germany and Finland only.

3. Divide the one-time fee by the monthly rate, then by your tenancy. That is the entry premium, comparable across vendors and currencies.

4. Compare monthly rates on matched hardware. Above twelve months, this decides the bill.

5. Measure traffic in both directions for 30 days before choosing an uplink.

6. Get three things in writing: the installation-fee condition, the per-TB rate above any allowance, and the uptime commitment with its credit mechanism.

7. Write the exit before the entry. Immediate cancellation and a committed term cost very different amounts for the same change of mind.

Which one when

Is Hetzner cheaper than OVHcloud? Published monthly rates do not settle it, because the two vendors’ configurations are not like-for-like. Entry cost can be compared: Hetzner’s setup fee is about half a month, while OVHcloud’s is a full month, included on twelve-month commitments only on its US site.

The decision, framed

Can you name the region? If the workload needs a dedicated server in North America or Asia-Pacific, Hetzner is out.

Can you name the tenancy? Under twelve months, Hetzner’s entry cost is about half of OVHcloud’s, and the Server Auction or a zero-fee -LTD model takes it to zero. Above twelve months, the setup fee fades and the monthly rate on matched hardware decides.

Can you sign for it? A commitment on hardware you have not sized is the most expensive line in this article. If the tenancy question has no number, choose an option you can leave without paying for the entry twice.

Most buyers asking this are choosing between a flexible entry and a committed one, and these two providers sit at opposite ends of that trade. If you would rather not choose, INXY.hosting dedicated and bare-metal servers have no setup fee and no minimum term. Send us your target configuration and an honest tenancy estimate, and we will price it side by side with the published Hetzner and OVHcloud rates. Leaving a hyperscaler? Start with what cloud egress actually costs.

FAQ

Does Hetzner charge a setup fee?

Yes, on the standard dedicated range. Since the 15 June 2026 price adjustment it is about half of one month’s rate — €49.00 on a €97.30 AX42-1, €799.00 on a €1,597.30 AX162-3. Server Auction servers carry no setup fee, and two -LTD models, AX41-1-LTD and EX44-1-LTD, are listed at €0.00.

Is OVHcloud’s installation fee avoidable?

On OVHcloud’s US site, yes: its Advance FAQ states the setup fees are included on any commitment of twelve months or longer. Its European Advance page lists a one-month installation fee without mentioning a waiver. Confirm the condition on your order form either way.

Is Hetzner traffic really unlimited?

On the default 1 Gbit uplink, yes — unlimited, counted outbound only. Servers with the 10 Gbit uplink add-on include 20 TB per month, then €1 ($1.20) per TB. The faster port is the metered one.

Does OVHcloud meter bandwidth?

Outside Asia-Pacific, no. Its bandwidth page describes traffic as unlimited and unmetered across all dedicated servers, while its US Advance FAQ excludes services hosted in Asia-Pacific data centres. For Singapore, Mumbai or Sydney, ask for the applicable terms.

Which has better uptime guarantees, Hetzner or OVHcloud?

OVHcloud’s US dedicated-server SLA commits 99.95% for Advance, 99.99% for Scale and 99.90% for Rise and Game, with credits of 10%, 30% or 100% of the monthly fee. Hetzner’s published SLA covers Cloud servers and vServers at 99.9%; we found no dedicated-server figure.

Is there an alternative without setup fees or minimum terms?

Yes. Hetzner’s Server Auction and two -LTD models have no setup fee but limited stock. INXY.hosting dedicated servers have no setup fee and no minimum term.

Two teams store 100 TB of the same video library on Storj’s Regional Workflows tier, at the same published $10/TB rate. One pays $1,000 a month, the other $5,000. The only difference is how much they read back. Most comparisons of S3 alternatives sort vendors by storage price per terabyte — and for many workloads that column decides the smaller part of the bill. This article shows which number actually decides it, and how to measure yours before you sign.

The number that decides this is a ratio, not a rate

Divide your monthly egress volume by your stored volume. A 100 TB archive serving 10 TB a month is a 0.1× workload. The same 100 TB feeding a video player at 500 TB a month is a 5× workload. Nothing else about the two workloads differs, yet almost every vendor in this market prices them differently.

The reason is structural. Storage per terabyte is close to a commodity, so object storage vendors compete on how much read traffic they will absorb at that price. “No egress fees” is a real differentiator — and also a bet on your ratio, which each vendor has placed at a different number.

What is an egress ratio in object storage? The egress ratio is your monthly download volume divided by your stored volume. A 100 TB bucket serving 300 TB a month has a 3× ratio. Many “free egress” offers are capped at a multiple of stored data — commonly 1× or 3× — while a few have no cap at all, so the ratio, not the storage rate per terabyte, decides which provider is cheapest for a given workload.

Four offers, four definitions of “free egress”

Wasabi charges nothing for egress, and its pricing FAQ draws the line at a ratio of one: the free-egress policy fits workloads whose monthly egress is “less than or equal to your active storage volume”. There is no overage rate. If usage regularly exceeds the policy, Wasabi says it may “limit or suspend your service” (Wasabi pricing FAQ).

Cloudflare R2 states: “There are no charges for egress bandwidth for any storage class.” There is no ratio; R2 earns on operations instead, at $4.50 per million Class A and $0.36 per million Class B requests on Standard storage (Cloudflare R2 pricing).

Storj includes 1× egress on its Global Collaboration and Regional Workflows tiers and charges $0.02/GB and $0.01/GB above it. Its cheapest tier, Active Archive at $6/TB, includes no free egress and charges $0.02/GB from the first byte (Storj pricing, updated 15 July 2026).

INXY.hosting S3 includes egress up to 3× your average stored data each month and charges $0.015/GB above it. Egress to our CDN partners CacheFly and Gcore is free and unlimited.

Read side by side, these offers implement four different rules — 1×, 3×, unlimited, and no free egress at all on the cheapest archive tier — and one of them enforces its limit through an account-level right to limit or suspend service rather than an overage price. A commercial term you cannot convert into a line item is not a price; it is a risk, and it belongs in your vendor review as well as your cost model.

Published rates, side by side

All rates from each vendor’s own published page, read 9 October 2026; currencies as published, prices before tax, no FX applied. Hetzner’s included quota is defined in TB-hours and scales with month length, which is why its included traffic runs from 1.008 TB (28 days) to 1.116 TB (31 days). Hetzner’s rates are taken from its price list as of October 2026. DigitalOcean prices in GiB, so its per-TB figure is about 7% lower than the same number in decimal units.

The worked example: same 100 TB, two ratios, different winners

Take 100 TB stored. First at a 0.1× ratio — 10 TB egress a month, a backup target or a compliance archive — then at 5×, an ordinary month for a media library or a dataset read by training jobs.

Arithmetic from the published rates above at 1 TB = 1,000 GB, 30-day month, storage and egress only. Amazon S3 uses the standard us-east-1 internet egress tiers ($0.09/GB first 10 TB, $0.085 next 40 TB, $0.07 next 100 TB, $0.05 above 150 TB). R2 read requests add $0.36 per million GETs — tens of dollars a month for a typical video library. The CacheFly / Gcore row covers storage and storage egress only; delivery from the CDN to viewers is billed under the CDN plan.

Four things follow from the table.

Against Amazon S3, every alternative wins — by a margin that depends on the ratio. At 0.1× the alternatives cost roughly a fifth to two-thirds of the S3 bill. At 5×, where S3’s metered egress dominates, the cheapest alternatives cost about a twentieth of it. The ratio decides not only which alternative wins, but how much moving off S3 is worth.

Between a 3× plan and an unlimited one, the ranking inverts. At 0.1×, INXY.hosting S3 is cheaper and R2 costs 1.5× as much ($1,500 against $999). At 5× served directly from storage, R2 is cheaper and the 3× plan costs 2.7× as much. The crossover is calculable: $9.99/TB with 3× free egress and $15/TB above it equals R2 at $15/TB when egress reaches 3.33× stored volume. Below that ratio the 3× plan is cheaper; above it unlimited egress is — unless delivery runs through a CDN whose egress from storage is free, which removes the overage line altogether.

The lowest storage rate does not guarantee the lowest bill. Storj Active Archive has the lowest storage rate in the table, $6/TB, but at 0.1× it only ties with Wasabi ($800 against $799) because every byte of egress is billed, and at 5× it is the second most expensive option after S3.

The cheapest number on the list comes with the tightest ceilings. On Hetzner’s current price list, both scenarios are the lowest direct-from-storage prices in the table even after converting euros to dollars (about €636 and €1,126). But Hetzner caps a bucket at 100 TB and 750 requests per second, and bills small objects as 64 kB. The 100 TB in this example fills one bucket exactly. Cheap and constrained is a valid choice; it is a different choice from cheap and elastic.

Wasabi needs its own sentence. Its storage line is among the cheapest at 0.1×, and at 5× there is no number to put in the table: a 5× workload sits outside the policy the product is sold under. That is not a criticism — the fit is clearly stated — but it means comparing a published price with an absent one. Treat any “no egress fees” claim as a question: free up to what multiple, and above it, a rate or a conversation?

Minimum billable object size: the second bill nobody models

Storage rates assume your objects are large. Three providers above publish a minimum billable object size, and the numbers differ by a factor of 25: Wasabi bills a minimum of 4 KB per object, Hetzner 64 kB, and Storj 50 kB on its Global and Regional tiers and 100 kB on Active Archive. INXY.hosting S3 has no minimum billable object size.

Take 100 million objects averaging 10 KB — thumbnails, map tiles, log shards, feature vectors, small JSON documents. That is 1 TB of real data.

The cheapest archive rate in the market produces the most expensive bill for this workload. Storj Active Archive at $6/TB bills 7.5× what Wasabi charges at $7.99/TB for the identical byte count, because a 10 KB object is billed as 100 kB. Storj Regional at $10/TB bills five times what INXY.hosting S3 charges at $9.99/TB, for the same reason. All of these numbers sit on the vendors’ own public pages, one click from the headline rate.

Request pricing compounds in the same direction. Writing those 100 million objects once costs about $445 in Class A operations on R2 after its 1 million free monthly requests, against nothing on INXY.hosting S3, Hetzner and Scaleway, where those calls are free or included. On an ingest-heavy, small-object workload the request line can exceed the first month of storage — then fall to near zero, which is why it rarely appears in an estimate built from a steady-state month.

“S3-compatible” is a spectrum — and the gaps are in the vendors’ own docs

Every provider here speaks the S3 API. None implements all of it, and the gaps are documented plainly enough that there is no reason to discover them during a cutover.

Cloudflare R2. The compatibility page states “Feature implementation is currently in progress” and marks as not implemented: bucket versioning, object tagging, bucket policies, replication, public access blocks, website configuration and object lock. ACL headers and SSE-KMS headers are unsupported; only the STANDARD and STANDARD_IA storage classes are implemented. On multipart uploads, if a retry to the same part number fails, the earlier part is lost and must be re-uploaded (Cloudflare R2 S3 API compatibility). The missing object lock matters for anyone using object storage as an immutable backup target.

Hetzner publishes hard ceilings: up to 100 TB and 50,000,000 objects per bucket, 750 requests per second and 10 Gbit/s per bucket, and 100 buckets per account (Hetzner Object Storage docs). Amazon’s performance guidance is at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per prefix, with no limit on the number of prefixes in a bucket (AWS S3 performance guidelines). These are different units — per bucket versus per prefix — but that is the point: on S3 you scale request rate by adding prefixes; on a per-bucket ceiling, you can only add buckets, up to the account cap.

That is the migration risk the price tables never carry. A storage rate is reversible in a month. An architecture that assumed versioning, object tags, object lock, bucket policies or prefix-level scaling is not.

Is S3-compatible object storage the same as Amazon S3? No. S3 compatibility means a provider implements the S3 API, not all of it. Cloudflare R2, for example, documents bucket versioning, object tagging, object lock and replication as not implemented. Check each provider’s compatibility page against the specific operations your application calls.

What breaks in production

• Minimum storage duration on short-lived objects. Wasabi Pay as You Go has a 90-day minimum: an object stored on day 1 and deleted on day 16 is billed 15 days of active storage and 75 days of deleted storage (Wasabi, updated 14 September 2026). Storj Active Archive has a 30-day minimum; R2 Infrequent Access has a 30-day minimum plus $0.01/GB retrieval. A job that writes and expires temporary objects daily pays for each of them for a month or a quarter.

• The minimum can depend on your contract. Wasabi publishes 90 days for Pay as You Go, but says other pricing models have different minimums and directs customers to sales or support for the figure. If you buy on a contract, get the number in writing before signing.

• Included quotas do not accumulate. Hetzner: “Unused included quota expires at the end of each month and cannot be carried over to the next month.” A quarterly restore is three months of unused allowance followed by one month of overage.

• GiB and GB are mixed across the market. DigitalOcean prices in GiB; most of the market prices in decimal TB. The 7.4% gap lands on both the storage and the egress line.

• Egress policies are enforced against sustained behaviour, not peaks. A one-off restore is unlikely to matter; a permanent change in read pattern after you point a CDN at the bucket is a different conversation. With a CDN in front, the ratio the storage vendor sees is your cache-miss volume — which makes cache hit ratio a storage cost input, not only a performance metric.

• Self-hosting an S3 API needs an owner. In December 2025 MinIO put its open-source community edition into maintenance mode — no new features or pull requests, security fixes assessed case by case — and pointed users towards MinIO Enterprise (InfoQ, 2025), after earlier removing admin features from the community web console. Whatever comes next, a self-hosted comparison row needs a named owner, a patch process and a maintenance budget.

Measure these seven things before you shortlist anything

1. Pull 90 days of egress and stored volume from your current provider’s billing export, not a monitoring dashboard. Compute egress ÷ stored for each month and take the highest, not the average.

2. Count objects and get the size distribution — specifically the share below 4 KB, 50 kB, 64 kB and 100 kB, the published minimum billable sizes in this market.

3. Count write operations separately from reads. On R2, PutObject, CreateMultipartUpload, UploadPart, CopyObject and ListObjects are Class A — a listing-heavy application is priced like a write-heavy one.

4. List every S3 operation your code and tooling actually call, including backup agents and SDK defaults, and check each candidate’s compatibility page. Versioning, tagging, object lock, ACLs, bucket policies, SSE-KMS and POST pre-signed uploads are the usual casualties.

5. Measure peak request rate and throughput per bucket and check them against each candidate’s per-bucket ceiling and per-account bucket cap.

6. Price the exit as well as the entry. Moving data in is an egress event at your current provider; moving it out later is one at the new provider. See the cloud egress fees comparison for the regulatory changes now starting to waive exit charges.

7. Run a parallel write for two weeks against the top two candidates before cutting over reads. That bill is the only estimate not built on assumptions.

How to decide

Three questions, in this order.

What is your peak monthly egress ratio? Below about 1×, the storage rate dominates and most providers in the table are viable — sort on price, limits and compatibility. Between 1× and about 3.3×, a 3×-included plan is usually cheapest, and 1× models are either metered or outside their policy. Above about 3.3×, unlimited egress beats a 3× plan served directly from storage — or put a CDN with free storage egress in front of the 3× plan. Either way, request pricing becomes your next question.

What is your median object size? Under about 100 kB, minimum billable object size can outweigh everything else in the storage column and reorder the table. Above about 1 MB it is irrelevant. Check it rather than assume it: object counts are usually dominated by small objects even when bytes are not.

What does your application assume the API will do? If the answer includes versioning, object lock, object tags, bucket policies or prefix-level request scaling, the compatibility matrix — not the price — is your shortlist.

The three answers often point at two providers rather than one, and that is a useful outcome: an archive tier priced for low egress and a delivery tier priced for high egress can beat a single compromise on both lines.

Where INXY.hosting S3 storage fits

INXY.hosting S3-compatible object storage costs $9.99 per TB a month. Egress up to 3× your average stored data is included; above that it is $0.015/GB. Egress to our CDN partners CacheFly and Gcore is free and unlimited. There is no minimum billable object size, API requests are included, and you can pay in fiat or crypto.

On the egress-ratio curve, that fits most workloads up to about 3× — backups, archives, datasets and application storage — and, with delivery through CacheFly or Gcore, high-ratio media and download workloads where the storage-side egress line would otherwise dominate the bill.

If you want the arithmetic run against your own numbers, send us 90 days of stored volume, egress volume, object count and request counts. We will show you what the same workload costs on INXY.hosting S3-compatible object storage next to the published rates above — including the cases where another option fits better.

Related reading: 95th percentile vs metered bandwidth billing on when backup ingest is billable at all; GPU server hosting on why moving a training corpus is an egress event priced by the storage side; and the CDN migration playbook for the cutover sequence when delivery moves with the data.

FAQ

What is the cheapest alternative to Amazon S3?

It depends on your egress ratio. At 100 TB stored and 10 TB monthly egress, a 3×-included plan such as INXY.hosting S3 costs $999 a month and Cloudflare R2 $1,500. At 500 TB monthly egress served directly from storage, R2 stays at $1,500 while the 3× plan reaches $3,999 — unless delivery runs through a CDN partner with free storage egress. Hetzner’s list price is lower at both ratios but comes with 100 TB and 750 requests-per-second limits per bucket. Compute your own ratio first.

Does “no egress fees” mean unlimited downloads?

Not always. Wasabi’s policy covers egress up to your active storage volume and reserves the right to limit or suspend accounts that regularly exceed it. 3×-included plans such as INXY.hosting S3 meter egress above three times stored volume. Cloudflare R2 charges no egress at any volume but meters requests instead.

Is S3-compatible storage a drop-in replacement for S3?

Not without checking. Cloudflare R2 documents bucket versioning, object tagging, object lock, bucket policies and replication as not implemented, and every provider publishes its own list of gaps. List the S3 operations your application calls, then verify each one against the provider’s compatibility page.

Why is my object storage bill higher than the per-terabyte rate suggested?

Usually minimum billable object size or minimum storage duration. Storj bills at least 50 kB per object on its Regional tier and 100 kB on Active Archive, Hetzner 64 kB, Wasabi 4 KB — so 10 KB objects can bill as 5 to 10 times their real volume. Wasabi Pay as You Go also has a 90-day minimum storage duration, and Storj Active Archive a 30-day one.

Should we self-host object storage instead?

It can make sense for high-ratio workloads, but it is now a staffed option. MinIO’s community edition moved to maintenance mode in December 2025, so the assumptions behind the most common default have changed. Budget an owner, a patch process and a tested restore before comparing it on price.

How many object storage providers should we use?

Two is common and often cheaper than one. An archive tier priced for low egress and a delivery tier priced for high egress can beat a single compromise provider on both lines, provided the application can address two endpoints. The overhead is one more set of credentials and one more compatibility matrix.

Latitude.sh prices a bare-metal NVIDIA H100 80 GB at $1.68 an hour or $1,230 a month. Multiply the hourly rate by the 730 hours in an average month and you get $1,226.40 — the monthly plan costs $3.60 more than running the same server by the hour all month. Cherry Servers, meanwhile, takes about 19% off an A40 if you commit to the month.

Both are honest rate cards, and the difference between them is the most useful thing to understand before you sign for GPU capacity: the higher you go up the GPU range, the less a commitment buys you in price — and the more it buys you in access. This piece works through the published numbers and what they mean in practice.

What a GPU dedicated server costs, from published rate cards

Every figure below comes from the provider’s own public page, read on 5 October 2026; the Latitude.sh, Hetzner and OVHcloud figures were re-checked on 7 October 2026. Currencies are as published, Hetzner prices exclude VAT, and no FX has been applied. “Break-even hours” is the monthly price divided by the hourly price — the number of hours a month above which the monthly plan becomes cheaper than paying by the hour.

Sources: Hetzner pressroom (GEX131), Cherry Servers dedicated GPU servers page, Latitude.sh pricing, OVHcloud GPU dedicated server page, Atlantic.Net dedicated GPU hosting. Only the Hetzner announcement carries a date.

Two things follow from the table.

The commitment discount narrows as the hardware gets more in demand. About 19% on an A40, 14.5% on Hetzner’s workstation-class RTX PRO 6000 Max-Q, about 4% on an A100, and nothing on Latitude.sh’s H100, RTX PRO 6000 and B300 nodes. It is not a clean rule — Hetzner still discounts a current-generation Blackwell card — but the direction is consistent.

Headline prices for the “same” GPU are not comparable until you normalise the service. $1,230 and $4,729.44 are both “H100-class” servers, but one is a self-managed H100 80 GB billed by the month and the other is a managed H100 NVL on a 12-month term with a security stack and support included. The gap is management, support and contract terms, not silicon.

Why the monthly discount shrinks on top-tier GPUs

On Cherry Servers’ own card, the mid-range accelerators (P4, A2, A10, A16) and the A40 all break even at 583–590 hours — a consistent 19–20% discount for a monthly commitment. The A100 breaks even at 702 hours, 96% of the month, for a 3.9% discount. On Latitude.sh’s 8x RTX PRO 6000 and 8x B300 nodes the monthly price is the hourly rate multiplied by exactly 730, to the dollar: there is no monthly discount, only a monthly-sized invoice.

A monthly discount is the provider paying you to take idle-capacity risk off its hands. Where cards can sit unrented, that is worth paying for. Where every unit is allocated as soon as it comes online, the provider carries no idle risk and has no reason to discount. That matches what we see in our own inventory: H200 and B300 capacity is taken as fast as it is installed, while workstation-class cards such as the RTX A4000, RTX A5000 and the RTX PRO series are where availability — and room on price — still exist.

One practical check before you treat any monthly figure as a discount: ask how it is applied. On some offers the monthly price is a separate term with a minimum commitment; on others it works more like a ceiling on hourly billing. The break-even arithmetic is the same either way; the cost of leaving early is not.

Is it cheaper to rent a GPU server monthly or hourly? It depends on the GPU and on how many hours a month the server is allocated to you. On published 2026 rate cards, a monthly commitment saves roughly 19–20% on mid-range cards such as the A40, about 4% on an A100, and nothing on some providers’ H100, RTX PRO 6000 and B300 nodes, where the monthly price equals the hourly rate times 730.

Long-term contracts: read what is being reserved

Multi-year contracts follow the same logic as monthly ones, only more visibly.

Vultr publishes per-GPU on-demand rates next to prepaid contract rates. On the NVIDIA L40S, on-demand is $1.671/GPU/hr and 36-month prepaid “starts at $0.848/GPU/hr” — a 49.3% discount. On the AMD MI300X, $1.850 against a 24-month prepaid rate from $1.750 — 5.4%. On HGX H100, 36-month prepaid starts at $1.490/GPU/hr, so a long enough term still buys a lower rate there. But on AMD’s newest parts the published numbers point the other way: MI325X is $2.000 on demand and from $2.100 on 24-month prepaid; MI355X is $2.590 on demand and from $2.650 on 48-month prepaid. Vultr’s page quotes prepaid rates as “starts at” and does not say the configurations are identical, so read this as a signal — long-term pricing on the newest accelerators is not built around discounting — rather than proof that prepaying costs more for the same server.

Lambda shows the same shape on a different product line. Its on-demand NVIDIA B200 SXM6 instance is $6.69/GPU/hr. Its 1-Click Clusters on HGX B200, sold on commitments of two weeks to one year, are $9.86/GPU/hr at 16 GPUs, $9.36 at 64 and $8.87 at 256+ — 33–47% above the on-demand rate (Lambda pricing page, checked 7 October 2026). These are different products: a cluster is interconnected multi-node capacity, an instance is a single server. Lambda reserves its “lowest prices” for terms over a year, which go through sales. The published commitment price, in other words, buys guaranteed interconnected capacity — not a discount.

The operational consequence: if you are quoted a long-term contract on top-tier GPUs at or near the on-demand rate, do not evaluate it as a discount. Evaluate it as the price of having the hardware at all, for a stated term. That is a different decision from a volume commitment on dedicated server pricing, where committing usually lowers the unit rate.

The line items the GPU price card does not show

Setup fees. On all four of OVHcloud’s GPU dedicated server configurations, the public page lists an installation fee equal to one month’s price: $1,145 on Scale-GPU-1, $1,180 on Scale-GPU-2, $1,216 on Scale-GPU-3 and $4,355 on HGR-AI-2. Without any adjustment, a twelve-month first year is a thirteen-month invoice — $56,615 rather than $52,260 on the HGR-AI-2, 8.3% above the headline. The page does not say whether a 12- or 24-month term changes the fee, so ask: the setup fee is one of the most negotiable lines in a bare-metal quote. Hetzner, for comparison, removed the GEX131 setup fee from 16 December 2025.

Egress. GPU workloads are usually described as ingest-heavy, which makes traffic allowances look generous. Inference is the opposite. Latitude.sh includes 20 TB out with inbound unmetered; Atlantic.Net includes 10 TB a month; Cherry Servers includes 30–100 TB depending on plan; Hetzner’s GEX45 page states traffic is “unlimited and free of charge”, though the GEX131 announcement does not state terms — confirm per model. A serving endpoint that returns images or audio will hit a 10 TB allowance much sooner than a training job. The rules are the same as for any bare-metal fleet — see metered vs unmetered bandwidth.

Power, if you own. The RTX PRO 6000 Blackwell Max-Q has a maximum power draw of 300 W (NVIDIA). At full load for 730 hours that is 219 kWh. At the EU average non-household electricity price of EUR 18.37 per 100 kWh in the second half of 2025 (Eurostat, 8 May 2026), the card alone costs EUR 40.23 a month — from EUR 16.38 in Finland (EUR 7.48/100 kWh) to EUR 55.89 in Ireland (EUR 25.52/100 kWh). That is the card only. A whole GPU server — CPUs, hundreds of GB of RAM, NVMe, fans, network — typically draws two to three times the card’s figure, and the facility adds its PUE on top. At 2.5 times the card and a PUE of 1.5, the bill is roughly EUR 150 a month, about 17% of the GEX131 rental price. Meaningful, but not what decides rent versus own. The capital does — and so does memory.

Memory, if you buy in 2026. TrendForce expects server DRAM contract prices to rise 13–18% quarter-over-quarter in 3Q26, noting that several US cloud providers have multi-year long-term agreements “which restrict suppliers from raising prices for these clients”, and that “the primary source of server DRAM price increases will shift toward customers without LTAs” (TrendForce, 9 July 2026). A GPU server carries hundreds of gigabytes of system DRAM. If you are buying one this year, you are most likely a customer without an LTA — the part of the market absorbing the increase. The provider renting you the same server may not be.

How to run the rent-or-own calculation

1. Measure allocated hours, not busy hours. Hourly billing on dedicated hardware runs from the moment a server is provisioned until it is released — not only while the GPU is computing. Busy hours lower your bill only if you actually release the server between jobs, and on top-tier cards you may not get it back. Track both over 30 days: allocated hours drive the bill; GPU-busy hours tell you whether you are oversized. Leaseweb’s guidance on sizing is blunt: “Below 50% means you are paying for capacity that sits idle” (Leaseweb, 2026).
2. Compare allocated hours with the break-even for your own quoted rates. Below it, hourly billing wins.
3. Price the full first year, not the monthly rate: setup fees, IP addresses, remote hands and any support tier that is mandatory for production.
4. Price egress at your real inference volume, not your training ingest.
5. Compare ownership over the hardware’s service life, typically three to five years: hardware, rack space and power, remote hands, spares and the engineering time to keep drivers and CUDA current. Twelve months of rent is a useful sanity check — EUR 10,668 for a GEX131, $14,760 for Latitude.sh’s single H100. If the hardware costs several times that, owning only pays off if you will run it hard for years — the same test behind most cloud repatriation decisions.
6. Check whether the GPU is available on demand at all. If it is not, you are in the capacity market and the comparison is access versus waiting, not price versus price.
7. Re-price at renewal. Every pattern above depends on current supply, and supply moves.

How many hours a month justify a monthly GPU server? Divide the quoted monthly price by the quoted hourly price. On the 2026 rate cards checked, break-even lands between 583 and 732 hours of a 730-hour month — roughly 80% to 100%, counted in hours the server is allocated to you, not hours the GPU is busy.

What breaks in production

The same spec sheet, two different GPUs. The RTX PRO 6000 Blackwell family ships in three variants with identical 96 GB GDDR7 ECC memory and maximum power of 600 W (Workstation Edition), up to 600 W configurable (Server Edition) and 300 W (Max-Q) (NVIDIA). Two providers can both list “96 GB RTX PRO 6000” and deliver materially different sustained throughput. Ask which variant, in writing, before benchmarking.

Reserved capacity left idle. A server reserved to guarantee availability costs the same whether or not the job is running. Reserved scarce capacity punishes idling harder than on-demand does.

Training-data egress discovered at cutover. Moving a training corpus out of object storage to a new GPU provider is an egress event priced by the storage side. Budget it from the cloud egress fees comparison before scheduling the move, and keep the corpus close to the accelerators — the argument for co-locating S3-compatible object storage with compute.

Driver and CUDA pinning on bare metal. A dedicated GPU server is yours to maintain, including the kernel-module, driver and framework chain. A working image on one hardware generation is not portable to the next without a rebuild.

Provisioning time treated as zero. Cloud GPUs appear in minutes. Dedicated servers with in-demand cards are often pre-order or waitlisted — Cherry Servers lists its A40 and A100 as pre-order and several other cards as waiting-list only. A plan that assumes same-day delivery of eight current-generation accelerators will slip.

One utilisation number for a mixed fleet. Averaging a training cluster at 95% with an inference fleet at 20% hides the fact that they need opposite billing models.

GPU servers at INXY.hosting

We split our GPU line the same way the market does. Every configuration below is a single-tenant bare-metal server — no virtualisation, no shared card.

Netherlands

Monthly starting prices for a single-GPU configuration in our Netherlands location.

NVIDIA H200 and B300. All GPUs are currently in use. Reserve your spot to get access as soon as one frees up. For large projects, please contact us directly.

North America

Bare-metal GPU servers are also available in North America. Contact our team for current configurations and pricing.

Order a GPU server, reserve an H200 / B300 or talk to our team

The decision, framed

Three questions, in this order.

Is the GPU you need available on demand, in the quantity you need? If not, you are buying capacity. A price at or above the on-demand rate is the cost of certainty; evaluate it as insurance with a stated term, and get the renewal rate in writing.

Are your allocated hours above the break-even on your own quote? If not, stay hourly. If they are, a monthly or longer commitment is defensible — worth around 19–20% on mid-range cards, often little or nothing on top-tier accelerators, and the difference is visible on the provider’s own page in two minutes of arithmetic.

Does owning beat renting over the hardware’s service life? If yes — and you have somewhere to rack it and someone to maintain it — owning can win over several years. But you are buying system memory in a market where, on TrendForce’s reading, buyers without long-term agreements absorb the price rises, so use this quarter’s component prices, not last year’s.

Most teams end up with a split: committed capacity for the steady baseline, hourly for the spikes. That works best when baseline and burst do not have to come from the same rate card. If you have 30 days of allocated-hours data and a target configuration, that is enough to run the break-even against current quotes — see our dedicated and bare-metal hosting.

FAQ

Is a monthly GPU dedicated server cheaper than paying by the hour?

Only above the break-even hours. On published 2026 rate cards, a monthly plan saves about 19–20% on mid-range cards such as the A40, 14.5% on Hetzner’s RTX PRO 6000 Max-Q server, about 4% on an A100, and nothing on some providers’ H100, RTX PRO 6000 and B300 nodes. Below roughly 80% of the month in allocated hours, hourly billing is usually cheaper.

What is the minimum utilisation that justifies a dedicated GPU server?

Divide the quoted monthly price by the quoted hourly price. Across the providers checked, break-even is 583 to 732 hours of a 730-hour month — roughly 80% to 100%. Count hours the server is allocated to you, not hours the GPU is busy: hourly billing runs until you release the server.

Why don’t long-term contracts on H100, H200 or B300 come with a big discount?

Because the hardware is in short supply. Providers discount commitments when they carry idle-capacity risk; on top-tier accelerators they rarely do. Some long terms still lower the rate — Vultr’s 36-month prepaid HGX H100 starts at $1.490/GPU/hr — but on the newest parts published commitment prices often sit at or above on-demand, as with Lambda’s B200 clusters at $8.87–9.86/GPU/hr against $6.69 for an on-demand instance. What the commitment buys is guaranteed access.

What is included in the price of a GPU dedicated server?

It varies sharply. Among the plans compared, included traffic ranged from 10 TB to unlimited, setup fees from zero to a full month’s price, and management from none to a full managed security stack — which is most of why one H100-class server costs $1,230 a month and another $4,729.44.

Does owning GPUs beat renting them?

Only if you will run the hardware hard over its three-to-five-year life and have somewhere to host and maintain it. Electricity matters but does not decide it — roughly EUR 150 a month for a single-GPU server at EU average prices. The capital cost and today’s memory prices are what decide it.

How much bandwidth does a GPU server need?

Training is ingest-heavy and usually fits within included allowances; inference that returns images, audio or video is egress-heavy and often does not. Size the allowance against serving volume, not training volume, and check whether the provider meters inbound traffic as well as outbound.