GPU Dedicated Server Hosting: What a Monthly Commitment Actually Buys

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.

‍

For two years, the story of data center expansion was GPU scarcity: hyperscalers and neoclouds fighting over allocation, facilities sitting half-built while silicon shipped late. That constraint has eased — TSMC has doubled its CoWoS advanced packaging capacity multiple times since 2024, and GPU shipment volumes have scaled with it (TrendForce, 2024). What has not eased is the grid. Interconnection queues, transformer manufacturing, and utility capital planning move on cycles measured in years, and none of them accelerated to match electricity demand (Inflect, 2026). In 2026, data center power availability, not chip supply, decides where you can deploy and how fast — and that constraint now reaches standard hosting and colocation buyers who have never touched a GPU.

The numbers behind the bottleneck

Securing grid power for a new data center in 2026 typically takes 24 to 72 months depending on market and load size, with some constrained regions quoted at 5 to 7 years (Inflect, 2026). Northern Virginia, Phoenix, and Dallas specifically run 4 to 7 years (Sightline Climate, cited by Bloomberg, May 2026).

‍

The delivery risk compounds the wait. Goldman Sachs Research estimated in 2026 that only 60% of next year's scheduled capacity will arrive on time, dropping to 50% over the following two years — and Bloomberg separately reported Sightline Climate's estimate that 30–50% of the roughly 16 GW planned for 2026 in the US will be delayed or canceled due to power constraints (both cited May–July 2026).

‍

Texas shows how concentrated the demand has become: ERCOT is managing a 410 GW large-load queue, with data centers comprising 87% of it, while CenterPoint Energy reported a 700% jump in large-load interconnection requests in a single year — from 1 GW to 8 GW (EnkiAI; Hanwha Data Centers, 2026).

What this means if you don't run GPUs

The instinct is to treat this as an AI-infrastructure story. It isn't only that. Power availability, not floor space, is now the binding constraint on new colocation supply in every major US market, according to Cushman & Wakefield's Data Center Power and Lease Pricing Outlook (cited across multiple 2026 industry reports). That constraint prices standard enterprise racks the same way it prices GPU racks, because both are drawing from the same interconnection queue and the same transformer supply chain.

‍

The pricing evidence is consistent across independent sources. US wholesale colocation for 250–500 kW deployments averaged $195.94–$196.25 per kW per month in H2 2025, up roughly 6.5–6.6% year-over-year, with 3–10 MW requirements up 12.5% as competition intensified for large contiguous power blocks (Cushman & Wakefield data, cited across multiple 2026 reports; Brightlio, 2026). Retail — the single-cabinet deployments most hosting buyers actually lease — moved faster still: Lightyear's own platform data showed all-in per-kW pricing rising roughly 17–21% in just the second half of 2025 (Lightyear, 2026).

‍

The market has also split by deal size in a way that matters more than price. Roughly 90% of new colocation capacity under construction is in the 200 MW to 1 GW hyperscale range, not the 2–4 MW halls a typical enterprise needs (Datacenter World, June 2026). North American vacancy sits near record lows — around 1–2% depending on the source — with most capacity under construction already pre-committed before a cabinet is installed (JLL data, cited by Inflect and Datacenter World, 2026). A deployment that once took 6 to 12 months to secure now needs 18 to 24 months of lead time in primary markets.

What no vendor will tell you

The honest version of this story isn't "AI is stealing your power" — it's that the people selling you colocation are caught in the same squeeze you are, and most won't say so directly. Peter Feldman, CEO of QTD Systems, a New York colocation provider focused on traditional enterprise workloads rather than AI, described the position plainly: "Non-AI or hyperscale colocation saw steady sales; pricing for operators held [with] maybe small upticks, but most incremental gains were countered by rapidly rising power costs. Equipment, replacement, and upgrade costs have skyrocketed due to tariffs and AI construction consuming all the equipment for new construction" (Data Center Knowledge, February 2026).

‍

Read that carefully: a provider that isn't chasing AI customers at all is still absorbing rising input costs, because AI buildout is consuming the same transformers, switchgear, and construction capacity that any data center needs — and that cost pressure has to land somewhere eventually, even on a facility that has never hosted a GPU. If your provider's rate hasn't moved yet, that is a timing gap, not evidence the pressure doesn't apply to you.

The efficiency metric that stopped being the main story

Power Usage Effectiveness — the ratio of total facility power to IT equipment power — has been the industry's standard efficiency benchmark for two decades. Global average PUE sat at 1.54 in the Uptime Institute's 2025 survey, essentially flat since around 2020, while leading hyperscale operators have pushed fleet-wide PUE down to 1.09 (Uptime Institute; Google Data Centers, 2025).

‍

PUE still matters for operating cost and compliance — Germany's Energy Efficiency Act requires new data centers commissioned from July 2026 to hit 1.2 or below. But it answers a different question than the one buyers are now asking. A facility with a best-in-class 1.1 PUE cannot open at all without a grid interconnection, and no amount of cooling efficiency shortens a four-year utility queue. Efficiency optimizes the power you can get; it doesn't get you the power in the first place.

The regulatory response, and why it won't fix 2026

On 18 June 2026, FERC issued show-cause orders under Section 206 of the Federal Power Act to all six FERC-jurisdictional regional grid operators, instructing each to justify or revise its large-load interconnection rules — a faster, more targeted move than a standard rulemaking, following an October 2025 DOE directive (White & Case; American Action Forum, June 2026). It may shorten future queues in the regions it touches.

‍

It does not retroactively move anyone already in a queue. Projects with existing applications wait behind whatever framework their grid operator adopts, on whatever timeline that operator sets. For a deployment decision made this quarter, the FERC action is a signal about direction, not a lever that changes your timeline.

What to do with this if you're buying colocation or dedicated capacity now

Ask about grid interconnection status before floor space. A provider quoting available cabinets without confirming power headroom is quoting you half an answer. Confirmed interconnection, not listed vacancy, is the number that determines whether your deployment date is real — it's the first thing INXY verifies with any facility before recommending it to a client.

‍

Lead time is now 18 to 24 months in primary markets, not 6 to 12. If your growth planning still assumes the shorter window, the gap will show up as a missed deployment date, not a budget overrun.

‍

Secondary and tertiary markets carry real tradeoffs, not just lower prices. Power-advantaged regions outside the traditional hubs (Northern Virginia, Silicon Valley, Phoenix) often have shorter interconnection queues precisely because demand hasn't concentrated there yet — but latency, connectivity density, and carrier presence vary accordingly. The right tradeoff depends on whether your workload is latency-sensitive or throughput-oriented.

‍

A workload that doesn't need dedicated colocation power at all sidesteps the queue entirely. Delivery-layer capacity — CDN, managed DNS, cloud compute sized to the actual workload — doesn't carry the multi-year interconnection risk that a dedicated cage does, because you're not the one waiting on the utility.

‍

We broker colocation and dedicated capacity across multiple facilities and markets, which means INXY can tell you which shortlisted sites have confirmed power today rather than a queue position and a promise — a distinction that determines whether your deployment date is real. [Request an infrastructure audit → /book-a-demo] before you commit to a facility on the strength of its floor plan alone. To review capacity options directly: [dedicated servers, colocation and racks → /hosting-solutions].

FAQ

Why is data center power harder to get than GPUs in 2026? GPU supply eased as TSMC scaled advanced packaging capacity multiple times since 2024, easing the earlier allocation crunch. Grid capacity did not scale at the same pace, because interconnection queues, transformer manufacturing, and utility planning all operate on multi-year cycles that chip production improvements don't affect.

‍

How long does it take to get a new data center connected to the grid in 2026? Typically 24 to 72 months depending on market and load size, with 4 to 7 year waits in the most constrained primary markets such as Northern Virginia, Phoenix, and Dallas. Secondary markets with less concentrated demand generally offer shorter queues.

‍

Does the power shortage affect standard hosting, or only AI data centers? It affects both, because standard and AI colocation compete for the same grid interconnection queue and equipment supply chain. Cushman & Wakefield data shows power availability, not floor space, is now the binding constraint on new colocation supply in every major US market, and pricing for standard deployments has risen accordingly.

‍

What is PUE and does it matter for site selection? Power Usage Effectiveness measures total facility power against IT equipment power, with lower numbers indicating less overhead. It remains relevant for operating cost and compliance, but it doesn't address whether a site can secure grid power at all — a highly efficient facility still can't open without an interconnection, so PUE answers a different question than power availability does.

‍

Will the June 2026 FERC orders fix data center interconnection delays? The orders instruct regional grid operators to justify or revise their large-load interconnection rules, which may shorten future queues in the affected regions. They do not retroactively accelerate projects already waiting in a queue, so deployments planned for this year should not assume near-term relief from the ruling.

‍

How far in advance should I secure colocation capacity now? Roughly 18 to 24 months in primary markets, up from the 6 to 12 months that was standard a few years ago. This shift reflects both record-low vacancy and the share of new capacity that is pre-committed before construction completes.

‍

Managing your online presence can lead to hidden expenses, one of which is your Content Delivery Network (CDN) costs. But how can you reduce these costs while maintaining high website speed and reliability? In this guide, you’ll discover proven strategies to lower your CDN expenses without compromising performance or user experience.

1. Understanding CDN Pricing Models

Before you can save money, it’s essential to understand how CDNs charge for their services. Each provider uses unique pricing models that can impact your bottom line.

Key CDN Pricing Structures

• Pay-As-You-Go: Charges are based on the actual bandwidth or data you use.
• Committed Contracts: Pay a fixed monthly fee for predictable costs and potential discounts.
• Tiered Pricing: Costs per GB decrease as your data usage increases.
• Location-Based Pricing: Prices vary by geographic region; regions like Asia and South America often cost more.

Choosing the Best Pricing Model

Analyze your traffic to choose the right model:

• For unpredictable traffic, a pay-as-you-go model offers flexibility.
• If your traffic is stable, a committed contract can lower costs.
• Understand your audience’s geography to estimate costs for high-expense regions.

Pro Tip: Compare providers like Cloudflare, Akamai, and AWS CloudFront. Some offer discounts for large volumes or regional optimizations.

2. Implementing a Multi-CDN Strategy

Using multiple CDNs can improve performance and reliability while optimizing costs.

Benefits of Multi-CDN Strategies

• Global Coverage: Ensure fast delivery for audiences worldwide.
• Improved Reliability: Avoid downtime by balancing traffic across providers.
• Cost Savings: Route traffic to the most cost-effective provider in each region.

How to Set Up Multi-CDN

• Use DNS-based load balancing to distribute traffic efficiently.
• Monitor pricing regularly to ensure you’re using the cheapest options.
• Automate traffic steering during peak times to manage costs and performance.

3. Optimizing Caching Techniques

Caching is one of the simplest ways to reduce CDN costs while speeding up your site. It minimizes requests to the origin server, saving both time and money.

Smart Caching Strategies

• Tiered Caching: Store content at intermediary servers for quicker delivery.
• Set TTLs (Time To Live): Increase how long cached items stay valid to reduce server requests.
• Browser Caching: Save frequently used assets like images or JavaScript files directly on the user’s browser.

Improve Cache Efficiency

• Audit your cached content regularly to ensure static assets are included.
• Use real-time analytics to spot cache misses and adjust settings to improve cache hit ratios.

4. Regional Load Distribution and Geographical Pricing

The cost of delivering content varies by region. Serving users from strategically located servers can significantly reduce expenses.

Regional Pricing Optimization

• Choose CDNs with lower costs for data-heavy regions.
• Route traffic to servers closer to users, reducing cross-regional data transfer costs.

Adjust for Expensive Regions

• For regions with high costs, consider reducing the quality of multimedia (like lower video resolution).
• Implement adaptive bitrate streaming to save bandwidth based on user needs.

5. Integrating CDNs with Cloud Platforms

CDNs and cloud platforms like AWS and Google Cloud can work together to lower your overall expenses.

Avoid Cloud Egress Fees

Cloud providers often charge fees for data leaving their networks. Delivering static files through a CDN instead of directly from the cloud can save you substantial amounts.

Use Edge Caching

Edge caching ensures content is stored closer to your users, reducing latency and cloud server load while lowering costs.

Offload Static Content

Let the CDN handle static file delivery so your origin servers can focus on dynamic tasks. This setup reduces your reliance on expensive cloud compute resources.

6. Leveraging Serverless Computing

Serverless computing can be a cost-effective solution for dynamic content delivery, especially when paired with edge processing.

Why Use Serverless Computing?

• Execute code near users for faster responses and lower latency.
• Reduce your need for full-scale cloud servers.
• Platforms like AWS Lambda@Edge enable personalized content delivery without extra server costs.

7. Content Optimization Techniques

Reducing file sizes through optimization is a proven way to cut CDN costs. Smaller files consume less bandwidth, leading to significant savings over time.

Compress and Minify Files

• Use compression algorithms like Gzip or Brotli to shrink file sizes.
• Optimize images with efficient formats such as WebP for faster loading and lower costs.
• Apply adaptive bitrate streaming for videos, adjusting the quality based on the user’s network conditions.

Streamline Your Code

• Audit your CSS and JavaScript for unused code.
• Minify files to eliminate unnecessary characters and reduce file size.
• Deliver only the necessary assets to users, improving both speed and cost efficiency.

8. Monitoring and Analyzing CDN Usage

Regular monitoring ensures you identify inefficiencies and take corrective action to reduce costs while maintaining performance.

Leverage Real-Time Analytics

• Monitor cache hit/miss ratios to adjust rules for better caching efficiency.
• Track bandwidth usage and identify regions or assets that consume the most data.

Set Alerts and Notifications

• Configure alerts for unusual spikes in bandwidth, allowing for quick troubleshooting.
• Use scheduled reports to gain insights into traffic patterns and cost-saving opportunities.

Use Insights for Optimization

Data from analytics can help:

• Refine your caching strategy.
• Adjust your CDN configuration to better align with your needs.
• Identify underperforming assets that can be optimized further.

9. Utilizing Cloud-Native CDN Solutions

Cloud-native CDNs integrate seamlessly with existing cloud platforms, simplifying management and optimizing pricing.

Advantages of Cloud-Native CDNs

• Unified Billing: Manage costs through a single platform for easier tracking.
• Volume Discounts: Benefit from economies of scale with consolidated usage.
• Enhanced Compatibility: Cloud-native CDNs like AWS CloudFront or Google Cloud CDN work effortlessly with their respective ecosystems, maximizing efficiency.

Scalability and Efficiency

Cloud-native solutions automatically scale with your traffic, ensuring you’re not overpaying during low-demand periods. Additionally, their built-in analytics tools can help you make smarter cost-saving decisions.

10. Best Practices for Continuous Optimization

CDN cost optimization isn’t a one-time effort—it’s a continuous process that requires regular assessment and adaptation.

Review CDN Performance Periodically

• Schedule routine performance and pricing reviews with your CDN providers.
• Test new features like edge computing or advanced caching to see how they affect costs.

Stay Informed on Industry Trends

• Keep up with advancements in CDN technology, such as real-time analytics, improved caching techniques, or cheaper compression methods.
• Follow updates from providers like Cloudflare, Akamai, and AWS to take advantage of new cost-saving tools.

User-Centric Design

Remember, a better user experience (UX) often aligns with cost savings. By reducing load times and optimizing content, you not only lower CDN expenses but also improve your site’s performance and customer satisfaction.

FAQs: Common Questions About CDN Cost Optimization

Q: What are the primary factors affecting CDN costs?

• Data transfer volume, geographical distribution of users, and the pricing structure of your CDN provider are the main drivers.

Q: How does caching reduce expenses?

• By storing frequently requested assets close to users, caching minimizes origin server requests, cutting bandwidth usage and costs.

Q: What is the role of compression in reducing costs?

• Compression reduces file sizes, which decreases the bandwidth required for delivery.

Q: How can a multi-CDN strategy help with cost optimization?

• It allows you to distribute traffic strategically, benefiting from location-specific pricing and avoiding reliance on expensive providers.

Conclusion

Reducing CDN costs while maintaining site performance is achievable with the right strategies. From understanding pricing models and leveraging caching techniques to integrating cloud-native solutions and optimizing content, there are numerous ways to save money without compromising speed or reliability. Regularly monitor your CDN usage, stay updated on industry trends, and refine your approach to keep costs low and performance high.

By following these best practices, you can optimize your CDN costs while providing users with a fast and reliable experience.

‍

‍