Hetzner vs OVH: What It Costs to Start, and to Leave

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.

Most CDN optimization work starts by raising TTLs and stops when the hit-ratio chart looks better. Then the origin egress bill does not move. The cause is almost always the cache key: the CDN is storing dozens of near-identical copies of the same object, and every one of them misses on first request. This piece covers what actually controls origin load — key cardinality, revalidation, and tiering — and the order to fix them in.

Cache hit ratio is the wrong number to run on

Cache hit ratio counts requests. Your origin bill counts bytes. The two diverge the moment object sizes vary, which is every real catalogue.

‍

Fastly draws the distinction explicitly: origin offload is "the ratio of bytes served to end users that were cached inside the CDN (not fetched from the origin), over total bytes served to end users for the service" (Fastly blog, accessed 2026). One large video segment miss outweighs thousands of hits on thumbnails, and hit ratio will not show it. The same write-up documents a customer who disabled shielding: hit ratio stayed in the low 90s while origin load went from under 5 GiB/s to over 20 GiB/s. A metric that can miss a 4× change in origin load is not a control surface.

‍

There is also a scaling effect people get backwards. Moving hit ratio from 90% to 95% is not a 5% improvement — the miss rate goes from 10% to 5%, so origin requests are cut in half. The last few points hold all the money, which is exactly why header changes alone rarely buy them.

‍

What is CDN optimization? CDN optimization is the work of reducing how much traffic reaches your origin without serving stale or incorrect content. It has three levers: shrinking the cache key so fewer duplicate objects exist, setting freshness and revalidation headers so objects survive longer at the edge, and adding a tiered or shield layer so edge misses do not all reach origin.

‍

In our migration work the first thing we ask for is not the hit-ratio dashboard. It is origin egress in bytes per hour, split by content type. That number tells you whether the problem is fragmentation, expiry or catalogue shape, and those have different fixes.

The cache key decides everything TTL cannot

A cache key is the string the CDN hashes to decide whether it already has your object. Anything in it that varies per user, per campaign or per browser multiplies your stored copies and drives every copy through a first-request miss.

‍

Cloudflare's default key is the full URL including query string, plus the Origin header and the method-override and forwarding headers (x-http-method-override, x-forwarded-host, x-original-url and several others) (Cloudflare docs, accessed 2026).

‍

Know which half of the fix is gated. Sort query string, Ignore query string, Cache deception armor and Cache by device type are ordinary Cache Rules settings. What Enterprise buys is the custom cache key: selecting named query parameters to include or exclude, and adding headers, cookies, host or user attributes to the key (Cloudflare docs, accessed 2026). So canonicalising parameter order is a toggle on most plans; surgically keeping ?variant= while dropping ?utm_source= is not, and below Enterprise that job belongs in your application or a Worker.

‍

Here is what fragments a key in production, with the documented behaviour behind each:

‍

That is the specification. The platform you are on may not implement it, and this is the single most consequential divergence in the whole article.

‍

Cloudflare states it plainly: "By default, Cloudflare does not consider vary values in caching decisions." Vary values are respected only "when you configure the Cache Rules Vary setting, when Vary for images is configured, and when the vary header is vary: accept-encoding" (Cloudflare docs, accessed 2026). A response containing Vary: * always bypasses cache regardless of that configuration (Cloudflare docs, accessed 2026).

‍

Read what that means for the common case. If you shipped Vary: Cookie on a cacheable page and assumed it protected per-user content, it did not fragment the cache and it did not disable it — by default the header was ignored and one stored object was served to everyone. That is a cross-user content leak, not a hit-ratio problem, and it fails in the direction that ends up in an incident report. Only Vary: * gives you the bypass. Treat Vary as a correctness control you must explicitly enable per platform, not as something the origin can assert and trust.

TTL and revalidation are a negotiation with the platform

RFC 9111 fixes the precedence. A cache calculates freshness lifetime from s-maxage if it is a shared cache, then max-age, then Expires minus Date, and only then falls back to heuristics (RFC 9111 §4.2.1, 2022). Where heuristics apply and a Last-Modified header exists, the spec encourages "no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%" (RFC 9111 §4.2.2, 2022).

‍

That precedence is the most underused lever on the list. Split the edge lifetime from the browser lifetime: hold an object at the edge for a day while browsers revalidate in five minutes, so a purge on publish reaches every user immediately and the origin still sees almost nothing.

‍

Which header does the splitting depends on the platform, and this is where vendor-agnostic matters. On Varnish-derived stacks, Surrogate-Control takes precedence over everything else: Fastly documents its order of preference as Surrogate-Control: max-age, otherwise Cache-Control: s-maxage, otherwise Cache-Control: max-age, otherwise Expires (Fastly docs, accessed 2026). Surrogate-Control is also stripped before the response reaches the browser, which makes it the cleanest way to say "one hour at the edge, one minute in the browser" without the browser ever seeing the edge value. Use Surrogate-Control where it is honoured and s-maxage where it is not.

‍

Platform defaults then sit on top of the spec, and they differ enough to matter:

That last row is the single most dangerous default in CDN configuration, and it is documented rather than hidden. It is also almost never mentioned in optimization guides, because it is a correctness risk rather than a performance tip.

‍

Freshness expiry then creates a second problem: a synchronised miss. Every edge holding a copy expires at roughly the same second and every one of them fetches. Your origin sees a periodic spike with no traffic change behind it.

‍

RFC 5861 solves that in one directive. stale-while-revalidate "indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds" (RFC 5861 §3, 2010), and stale-if-error allows a stale response when the origin returns 500, 502, 503 or 504 (RFC 5861 §4, 2010). AWS recommends supplementing max-age with both (AWS docs, accessed 2026).

‍

How do you improve CDN cache hit ratio? Reduce the cache key first: strip tracking parameters, normalise query string order and case, forward only named cookies and headers, and keep Vary to the smallest set. Then extend freshness with s-maxage and add stale-while-revalidate so expiry does not force a synchronous origin fetch. Enable a tiered or shield layer last.

‍

stale-if-error also converts a short origin outage into cached-content delivery rather than a 502 page. We treat it as an availability control, not a caching one, and it is the cheapest one available.

‍

Then check that your platform will actually honour it. Cloudflare documents that "the stale-if-error directive is ignored if Always Online is enabled or if an explicit in-protocol directive is passed", and that those directives "include a no-store or no-cache cache directive, a must-revalidate cache-response-directive, or an applicable s-maxage or proxy-revalidate cache-response-directive" (Cloudflare docs, accessed 2026). Read that carefully: on Cloudflare, the s-maxage you just added to extend edge lifetime disables stale-if-error on the same response. The two most commonly recommended directives in CDN optimization advice cancel each other out on one of the largest CDNs, and no guide that treats headers as portable will tell you. Pick one per platform — s-maxage where you want edge/browser split and Always Online is off, stale-if-error where availability during an origin outage matters more — or use Surrogate-Control on stacks that honour it and leave s-maxage off the response entirely.

‍

One more thing the bytes-not-requests thesis demands: a revalidation is not a miss. When an object goes stale and the origin answers a conditional request with 304 Not Modified, you paid one request and almost no bytes. That is why ETag and Last-Modified belong on every cacheable response, not just the ones you plan to soft-purge. A site with aggressive revalidation can show a mediocre hit ratio and an excellent egress bill at the same time, and it will look like a problem on the dashboard your vendor gives you.

Tiering and shielding beat every header change

If edge PoPs each fetch independently, one object costs you as many origin requests as you have caching locations. A tier in front of the origin collapses that.

‍

CloudFront states it directly: "When you use Origin Shield, all requests from all of CloudFront's caching layers to your origin come from a single location. CloudFront can retrieve each object using a single origin request from Origin Shield, and all other layers of the CloudFront cache (edge locations and regional edge caches) can retrieve the object from Origin Shield" (AWS docs, accessed 2026).

‍

Cloudflare's equivalent is Tiered Cache. Smart Tiered Cache, which picks a single closest upper tier per origin, is available on all plans; Generic Global Tiered Cache and Custom Tiered Cache topologies are Enterprise features, as is the Regional Tiered Cache middle layer on the Tiered Cache documentation (Cloudflare docs, accessed 2026). Verify this one against the live docs before you plan around it — Cloudflare is currently moving parts of the tiering stack under the Smart Shield brand, and the availability tables on the two sets of pages do not yet agree.

‍

Most audits get the order wrong here. Teams spend three weeks tuning headers and never turn on the upper tier, when tiering is a toggle with a larger effect than every header change combined. Check one thing first: whether your platform bills the shield layer as its own request tier. Offload that arrives as a new line item is still worth having, but it is not free, and it belongs in the [CDN cost comparison → /blog-posts/cdn-pricing-comparison] before you commit.

Purging is a hit-ratio decision in disguise

Purge-all at deploy time is a self-inflicted origin incident: every edge misses simultaneously on the next request for every object.

‍

Surrogate keys are the alternative — tag responses with keys and purge by tag. Individual keys are capped at 1,024 bytes and the total header at 16,384 bytes; beyond that "the key currently being parsed and all keys following it within the same header will be ignored" (Fastly docs, accessed 2026). Tag a category page with its product identifiers and a price change purges exactly the pages that display it.

‍

Soft purge is the second half. It marks content outdated while keeping it usable — "stale objects remain available to use in some circumstances while Fastly fetches a new version from origin" (Fastly docs, accessed 2026) — and requires either ETag/Last-Modified on origin responses or stale_while_revalidate configured together with stale_if_error. Without that groundwork it does close to nothing.

The optimization sequence, in the order that pays

1. Measure origin egress in bytes per hour, split by content type. Not hit ratio. If bytes are flat and requests are spiky, you have an expiry problem; if both are high, you have a key problem.
2. Dump the actual cache key your platform computes for your top 20 URLs by origin fetches. Most fragmentation is visible in one look.
3. Strip tracking parameters and normalise query string order and case before the key is computed.
4. Reduce Vary to the minimum set, remove Vary: Cookie from anything you intend to cache, and confirm whether your platform honours Vary at all — on Cloudflare it is off by default and must be enabled in Cache Rules. Never rely on Vary alone to keep per-user content out of a shared cache.
5. Split cache behaviours by path so static assets never carry cookies or session headers. This, not Vary, is what actually protects authenticated content.
6. Split edge lifetime from browser lifetime — Surrogate-Control: max-age where it is honoured, otherwise s-maxage long with max-age short — and add stale-while-revalidate. Add stale-if-error only after checking the platform: on Cloudflare an applicable s-maxage or must-revalidate, or Always Online being on, disables it (Cloudflare docs, accessed 2026).
7. Put ETag or Last-Modified on every cacheable response so stale objects revalidate into a 304 instead of a full refetch.
8. Enable tiered caching or origin shield, then re-measure origin bytes — this is the step with the largest single effect.
9. Replace purge-all with tag-based soft purge and wire it into the deploy pipeline.
10. Re-baseline after seven days. Cache fill has to complete across the footprint before any number means anything.

What breaks in production

Logged-in HTML cached at the edge. A minimum TTL above zero overriding no-cache, no-store and private (AWS docs, accessed 2026) is how one user's account page gets served to another. This is the failure that ends careers, and it is a two-field misconfiguration.

‍

Vary trusted as an access control. The same outcome by a different route. Cloudflare does not consider vary values by default (Cloudflare docs, accessed 2026), so a page shipping Vary: Cookie is stored as one object and served to every visitor. The dangerous part is that this looks better on your dashboard — hit ratio goes up — right up to the point someone sees another user's session. Path-based cache separation is the control; Vary is a hint your platform may ignore.

‍

"We raised the TTL and nothing happened." On Cloudflare, HTML and JSON are not cached by default (Cloudflare docs, accessed 2026). The TTL was raised on content the CDN was never storing.

‍

Compression variance removed instead of normalised. "Shrink the cache key" and "drop Accept-Encoding" read as the same advice and are not. Removing the variance without removing the variation ships a Brotli-encoded body to a client that asked for identity, or an uncompressed body to everyone. Normalise the header — CloudFront's cache policy compression settings collapse it to br,gzip (AWS docs, accessed 2026) — and never strip Vary: Accept-Encoding from a response whose body actually varies by encoding.

‍

Soft purge that does nothing. Without ETag/Last-Modified or stale_while_revalidate and stale_if_error configured together, soft purge has nothing to serve from (Fastly docs, accessed 2026).

‍

Header advice copied between platforms. The s-maxage plus stale-if-error pairing is the clearest case — correct on CloudFront, self-cancelling on Cloudflare (Cloudflare docs, accessed 2026). Caching headers are a specification; honouring them is a per-vendor decision. Test the response, do not trust the article, including this one.

‍

Hit ratio improves, bill does not. Almost always fragmentation on large objects: the small files got better and the heavy ones still miss. Check bytes, not requests.

‍

Cache fill measured too early. Any change to the cache key invalidates the entire stored set, so the first day after always looks worse. Judging it on day one is how good changes get reverted.

The ceiling no vendor will mention, and how to decide

Your hit ratio has a ceiling set by your catalogue, not your configuration.

‍

If most of your objects are requested once — a large media library, user-generated storage, a long-tail download archive — edge caching adds a hop and a fill cost and cannot reach a high hit ratio at any TTL. The honest fixes are a tiered topology that concentrates fills, a shorter path between origin and users, or a provider whose pricing model suits long-tail delivery rather than one that prices as if you were a news site.

‍

Every platform's optimization guide is written to make its own cache look effective. None will tell you that your content shape is the binding constraint, because the conclusion is sometimes "this is the wrong CDN for your workload" — see [how to switch CDN providers without downtime → /blog-posts/cdn-shutdown-migration-playbook] for what that migration costs. We say it because we sell across providers rather than one of them.

‍

So take the branch that matches your measurement:

‍

• Origin bytes high, hit ratio high. Fragmentation on large objects. Fix the cache key, starting with query strings and Vary.
• Origin bytes spiky on a fixed interval. Synchronised expiry. Add stale-while-revalidate and stagger TTLs across object classes.
• Origin requests high, bytes moderate. Every PoP fetching independently. Turn on tiering or shield before touching a single header.
• Hit ratio structurally low across everything. Catalogue shape, not configuration. Re-examine topology and provider fit, and read [where egress fees actually land → /blog-posts/cloud-egress-fees-comparison] before you renegotiate.
• Hit ratio fine, bill still wrong. The problem is the rate card, not the cache. Start from [optimizing CDN costs → /blog-posts/optimize-cdn-costs-strategies-and-best-practices].

‍

What is a good cache hit ratio? There is no universal target, because the ceiling depends on how often your objects are re-requested. A media catalogue with long-tail access cannot reach the same ratio as a news site serving the same assets to everyone. Judge a hit ratio against your own baseline and against origin bytes, not against a published benchmark.

‍

We run this sequence across whichever CDNs a client already uses, and the deliverable is the origin-bytes delta, not a hit-ratio chart. Having the cache key on your top-20 origin fetches dumped and read before you change anything is the place to start — and if the answer turns out to be topology rather than headers, a [multi-CDN routing setup → /blog-posts/multi-cdn-strategy] is the next conversation, not another round of TTL edits.

FAQ

Does raising TTL always improve cache hit ratio? No. TTL only matters for objects the CDN is already storing under a stable key. If tracking parameters or Vary headers are fragmenting the key, a longer TTL preserves more duplicate copies rather than fewer, and the first request for each still reaches origin. Fix key cardinality before touching freshness values.

‍

What is the difference between cache hit ratio and origin offload? Cache hit ratio measures the share of requests served from cache. Origin offload measures the share of bytes served to users that did not come from origin (Fastly blog, accessed 2026). Because object sizes vary, the two can move in opposite directions. Origin offload tracks your egress bill; hit ratio does not.

‍

Should I use max-age or s-maxage? Both. s-maxage applies to shared caches and takes precedence over max-age in them (RFC 9111 §4.2.1, 2022). Setting s-maxage long and max-age short holds objects at the edge while keeping browsers honest, so a purge on publish reaches every user without your origin absorbing the expiry.

‍

Is origin shield worth enabling on a small site? Usually yes on request volume, and it should be checked on cost. A shield collapses many independent PoP fetches into a single origin request per object (AWS docs, accessed 2026). The caveat is that some platforms bill the shield layer as its own request tier, so confirm the rate card before assuming the offload arrives free.

‍

Why did our cache hit ratio drop after a configuration change? Any change to the cache key invalidates every stored object, so the entire footprint refills from origin. That refill period looks identical to a regression. Hold the change for at least a full traffic cycle — seven days on most sites — before comparing, and compare origin bytes rather than hit ratio.

‍

Can a CDN cache a page my application marked no-cache? Yes. CloudFront documents that a minimum TTL above zero causes caching "even if the Cache-Control: no-cache, no-store, or private directives are present in the origin headers" (AWS docs, accessed 2026). Audit minimum TTL on every cache behaviour that can serve authenticated paths before you trust your origin headers to protect you.

‍

From 12 January 2027, a cloud provider serving EU customers cannot charge you to leave. Not a reduced fee, not a cost-recovery fee — nothing (Article 29(1), Regulation (EU) 2023/2854). That date is a hard deadline in a phased regime that has already been running since September 2025, and most infrastructure teams are treating it as a legal department problem. It isn't. The EU Data Act switching rules change what you should sign this year, what leverage you have at renewal, and — critically — what they don't touch on your monthly bill.

Sources: LEXIA (July 2026); Turing Law (2025); Garrigues (2025).

‍

As of mid-2026, the full free-of-charge regime is not yet in force (LEXIA, 2026). You are currently in the middle stage: your provider may still charge you to migrate, but only at genuine cost, and only if it was disclosed in your contract before you signed.

What "reduced switching charges" actually permits

This is the part worth reading carefully, because it's where providers have room to manoeuvre until 2027.

‍

Article 29(3) limits interim charges to costs that do not exceed those incurred by the provider and directly linked to the switching process concerned. In practice that means bandwidth to transfer the data, technical assistance time, and use of specific export tools are chargeable — while profit margins, general infrastructure costs, and unrelated penalties are not (Garrigues, 2025). Recital 89 further indicates that certain costs cannot be passed to the customer, such as those arising from services the provider itself outsources.

‍

The practical test: ask your provider to itemise the switching charge. If the line items don't map to bandwidth, engineering hours, and tooling, the charge is likely not compliant with the interim regime — and you can say so in writing before you pay it.

What survives 2027 — and this is the part nobody leads with

The headline is "switching becomes free." Four categories of charge survive that headline, and together they determine whether your bill actually changes.

‍

Early termination penalties remain legal. Article 29(4) preserves proportionate early termination penalties for fixed-duration contracts, and Recital 89 backs this. The Act does not clearly define what degree of penalty is permissible (Lexology, 2025). So a three-year commit with an exit penalty is still a three-year commit with an exit penalty in 2027 — the switching fee goes away, the termination penalty does not. Providers must take care that early termination penalties are not characterised as switching charges, but that is a line drawn case by case, not a bright rule (Penningtons, 2026).

‍

Multi-cloud egress stays chargeable. Article 34(2) permits charging for data egress in in-parallel use — running services across two providers simultaneously — provided the charge does not exceed the actual cost. Recital 99 addresses multi-cloud deployment strategies specifically (Penningtons, 2026). If your architecture runs continuously across two providers, January 2027 does nothing for that line item. This is the single most common misreading of the Act among engineering teams, and it matters because multi-cloud egress is frequently the larger number.

‍

Standard service fees are untouched. The Act regulates the cost of leaving, not the cost of staying.

‍

And the cost will look for somewhere to live. Industry observers expect providers to restructure pricing during the transition window, moving residual switching costs into base subscription fees (Global Law Experts, 2026). A prohibition on a specific charge does not remove the commercial instinct behind it.

‍

The three largest providers moved ahead of the deadline with free-exit programmes — Google on 11 January 2024, AWS on 5 March 2024, Microsoft on 13 March 2024 (UK Competition and Markets Authority, Appendix N). Those programmes are one-time and conditional on actually leaving. They are not a discount you can apply to a running workload.

The contract terms the Act now forces — check yours against these

Chapter VI imposes specific contractual requirements. These are the clauses that should now be in any in-scope contract, and their absence is a flag:

‍

1. Notice period of no more than two months for the customer to initiate a switch (Article 25(2)(d)).
2. A transitional period of 30 days, extendable where technically infeasible.
3. A data retrieval period of at least 30 calendar days, starting after the termination of the transitional period (Penningtons, 2026).
4. Pre-contract disclosure of standard service fees, early termination penalties, and any reduced switching charges — Article 29(4) requires this before you sign, and Article 29(6) requires it to be publicly available on the provider's website or another easily accessible place.
5. Disclosure where switching is highly complex, costly, or impossible without significant interference in your data or service architecture (Article 29(5)).
6. For IaaS: functional equivalence — the provider must supply capacity, documentation, technical support and, where necessary, tools to facilitate the transition (Articles 30 and 34(2)).
7. For SaaS: open interfaces free of charge, equally available to all customers and to the destination provider, plus compatibility with open interoperability specifications or, failing that, a structured, commonly used, machine-readable export format (Article 30(5)).

‍

Point 5 deserves attention. A provider disclosing that switching from its service is "highly complex" is making a compliance statement — and simultaneously handing you a written admission of lock-in that you can use at renewal. It is the first clause INXY reads when reviewing a client's existing provider agreements, because it tells you what the provider already knows about its own portability.

What no vendor will tell you

Your existing contract is probably non-compliant, and that is leverage, not a problem. The majority of Chapter VI obligations already apply, and existing contracts are likely to be non-compliant, with regulatory enforcement and customer scrutiny expected to increase through 2026 (Penningtons, March 2026). Providers are working through contract remediation right now. A customer who arrives at a renewal conversation already knowing which clauses are missing is negotiating from a materially stronger position than one who doesn't — because the provider has to fix those clauses regardless, and would rather do it as a concession than as a correction.

‍

Throttling and performance limitations count as obstacles. Legal analysis of the Act flags that technical and contractual policies which obstruct switching — performance throttling during migration, exclusivity terms, penalties — need to be progressively adapted to the portability framework (Garrigues, 2025). Article 28 requires good faith cooperation and prohibits obstacles to switching. If your provider's export path is technically available but throttled to the point of impracticality, that is a compliance question, not just an engineering annoyance.

‍

Enforcement is national, not centralised. Enforcement is delegated to Member States, which must implement penalties that are effective, proportionate and dissuasive. Customers can lodge complaints with the relevant national supervisory authority, and have a right to judicial remedy if that authority fails to act (Lexology, 2025). This means the practical strength of your position varies by which Member State's authority has jurisdiction — worth knowing before you rely on it.

What breaks in production

Treating the free-exit programme as a migration budget. It covers data transfer out. It does not cover dual-running two environments, engineering time, or the period where you pay both providers. The regulation removes a toll; it does not fund a project.

‍

Assuming the Act covers your provider. The obligations apply to providers of "data processing services." Providers should evaluate whether their offerings fall within scope (Lexology, 2025) — and so should you, before building a switching plan on the assumption that a niche or non-EU-established vendor is captured.

‍

Confusing the 2027 date with your renewal date. The free-switching regime applies from 12 January 2027 including to contracts already in force. But if you sign a three-year fixed term in 2026 with an early termination penalty, that penalty survives 2027 intact. The date that constrains you is your own commit length.

‍

Planning a switch without the 30-day retrieval window. The minimum retrieval period starts after the transitional period ends. Teams that plan the cutover but not the retrieval window discover the data export clock hasn't started when they thought it had.

What to do this quarter

1. Inventory which contracts are in scope and when each renews. The renewal calendar, not the regulatory calendar, is your action timeline.
2. Request itemised switching charges from any provider currently quoting them. If the items don't reduce to bandwidth, engineering hours and tooling, challenge them in writing under Article 29(3).
3. Audit each contract against the seven-point clause list above. Missing clauses are both a compliance gap for the provider and a negotiating lever for you.
4. Separate your exit cost from your run cost. Model them independently — the Act addresses one and not the other, and conflating them produces a business case that won't survive scrutiny.
5. If you run multi-cloud, model that egress separately. Article 34(2) leaves it chargeable. Any savings forecast that assumes 2027 zeroes it out is wrong.
6. Check which Member State authority has jurisdiction over your provider relationship, before you need to rely on it.

The decision framework

The Act changes the cost of leaving, which changes the value of staying — but only if you act on it.

‍

• If you are signing new in the next 12 months: push for short commit terms. The switching fee is disappearing anyway; the early termination penalty is what will actually hold you, so that is the clause to negotiate hardest.
• If you are renewing: arrive with the clause audit. Compliance remediation is work the provider owes you regardless — trade it for terms rather than accepting it as a favour.
• If you are already planning to leave: the interim regime means you may still be charged, but only at cost, and only if disclosed pre-contract. Check both conditions before paying.
• If you run multi-cloud in parallel: none of the above materially reduces your ongoing egress. Treat that as a delivery-architecture problem, covered in our [breakdown of cloud egress pricing → /blog/cloud-egress-fees-comparison].

‍

INXY brokers cloud, dedicated and colocation capacity across multiple providers on a single contract, which means the exit path is a procurement question rather than a legal one — we can move a workload between providers we already hold agreements with, without you running a fresh contract negotiation each time. If you want your current provider contracts checked against the Chapter VI clause list before your next renewal, send them over. [Request an infrastructure audit → /book-a-demo]. To review capacity options: [dedicated and cloud servers → /hosting-solutions].

‍

This article describes regulatory requirements for general information. It is not legal advice — INXY is an infrastructure consultancy, not a law firm, and contract decisions with legal consequence should be reviewed by qualified counsel in the relevant Member State.

FAQ

Does the EU Data Act ban egress fees? It bans switching charges, including egress charged for the purpose of moving to another provider, from 12 January 2027. It does not ban egress charges for ongoing use, and Article 34(2) explicitly permits charging at cost for egress in in-parallel multi-cloud deployments. Your monthly running bill is unaffected.

‍

When do the EU Data Act switching rules take effect? Chapter VI has applied since 12 September 2025, requiring cost transparency. From 12 January 2026, switching penalties are prohibited and migration charges reduced to the strict minimum. From 12 January 2027, switching becomes entirely free, including under contracts already in force.

‍

Can my cloud provider still charge me to leave in 2026? Yes, but only reduced charges not exceeding the provider's own costs directly linked to the switch — bandwidth, technical assistance time, and export tooling. Profit margin and general infrastructure costs are excluded, and the charge must have been disclosed in your contract before signing.

‍

Do early termination penalties survive the 2027 deadline? Yes. Article 29(4) preserves proportionate early termination penalties for fixed-duration contracts, and the Act does not precisely define what level is permissible. A long commit term signed today will still carry its exit penalty after switching fees are abolished, which makes commit length the clause worth negotiating.

‍

What contract terms does the EU Data Act require? A notice period of no more than two months, a 30-day transitional period, a data retrieval period of at least 30 calendar days after that, pre-contract disclosure of fees and penalties published accessibly, functional equivalence for IaaS, and free open interfaces with machine-readable export formats for SaaS.

‍

Who enforces the EU Data Act? Enforcement is delegated to EU Member States, which must implement penalties that are effective, proportionate and dissuasive. Customers can complain to their national supervisory authority and pursue judicial remedy if that authority fails to act, so practical enforcement strength varies by jurisdiction.

‍