Skip to content

Bandwidth overages: my CDN origin pull got expensive fast

Dedicated Servers Locked by Joy 25 replies 2.4K views
This thread is locked — new replies are not accepted. (Necro-bump on a two-year-old thread)
#11

I dealt with this exact pattern at my last gig. We had "dynamic" content that changed every 30 minutes but TTL was 0 because "real-time." Cost was 40 lakh INR in overages before we fixed headers.

Joy, use surrogate-control for the shield layer, cache-control for the edge. Different directives per tier. S-maxage=300 for shield, max-age=30 for edge, stale-while-revalidate=86400. Layered caching, not layered missing.

Also: OVHcloud Singapore to Gravelines would hurt. But Gravelines to Gravelines should not. Verify your shield zone location.

#12
kate3 said:
OpenVZ containers would make this worse

Who runs OpenVZ in 2026 though seriously but yeah the yo-yo thing is real I seen bills where shield-origin was charged as external because the shield was in a different region even same provider check your invoice line items Joy thats where the truth lives

Also hettner storage boxes are cheap for origin offload if you need to rearchitect later just saying

#13

Following this thread. I am check my own OVHcloud cache header tonight lah. Very scary to think I am maybe same mistake.

6 #14
priya said:
Surrogate-control for the shield layer

This. The shield speaks a different dialect than the edge. You are shouting "no cache" into a megaphone pointed at your own ear.

| surrogate-control: max-age=600
| cache-control: no-cache

The edge sees no-cache. The shield sees 600. Harmony. Instead you have cacophony. Your origin weeps. Your wallet weeps. EOF

/dev/null: full of good ideas
#15

From Geneva: check if your OVHcloud contract includes the "vRack" internal bandwidth option. Without it, even same-datacenter traffic can bill at standard egress rates. The 3x multiplier sounds like missing vRack, not just bad headers.

Swiss accounting brain: always map the billing model before the architecture.

#16
Paul10 said:
Missing vRack

I am check the bill now. The line item say "Outbound traffic - Public Cloud" for shield and "Outbound traffic - vRack" for origin. But the vRack is small amount, public cloud is BIG amount xixixi.

So the shield is billing as public cloud egress? I am think shield is internal but no. The shield is classify as public cloud instance. Very clever billing OVHcloud.

I am change the architecture. Remove shield, edge direct to origin with proper cache header. Or keep shield but fix header so it actually cache. Which is better?

#17
Joy said:
Remove shield, edge direct to origin

If you white-label this for clients later, direct origin exposes your infrastructure. Shield has value for origin IP protection, not just caching.

Fix the headers. Keep the shield. The vRack billing is a configuration issue, not architectural. Contact OVHcloud support, reference your public cloud egress line item. Sometimes they migrate the shield to vRack-eligible instance types retroactively.

I have done this for three clients. The billing code matters more than the server specs.

#18

Three become one
One becomes zero
When the header is wrong

#19
Joy said:
Remove shield, edge direct to origin

For 12TB/month? Direct origin is fine if your origin can handle the connection count. Shield is for cache hit ratio improvement, not connection hiding. Cloudflare and others don't require shield for basic DDoS protection.

Benchmark your origin connection capacity. If it's over 10k concurrent, drop the shield. If under, keep shield but fix headers. The Seoul way: measure, then decide. No religion.

#20
jihoonred86 said:
Shield is for cache hit ratio improvement

Partially true. Shield also reduces origin connection churn for range requests and large objects. Joy's 12TB suggests video or archive content. For large objects, shield matters even with good headers.

But only if it caches. Current configuration: shield adds two hops, zero benefit. Fix or remove. No middle ground with TTL 0.

virsh list --all | wc -l: 47

Thread closed

Replies are closed on this thread. Necro-bump on a two-year-old thread.