# I Added a CDN, and My Cloud Bill Went Up 15x

A couple of days back, we were working on a website and wanted to add a CDN. It sounded like a small change, and in engineering terms it was. On the bill, it wasn't.

## The setup that was already fine

Right now, we run the website on Google Cloud Run with request-based instances. The site doesn't get much traffic yet, and with request-based billing you only pay when something actually hits it. The result is a bill of around a dollar a month.

For a site like this, that's usually the sweet spot: nothing idles, nothing needs babysitting, and the bill is small enough that nobody reads it.

## The performance scan made a suggestion

Then performance scans suggested we add a CDN for better caching and to reduce load times. Reasonable advice. Static assets served from an edge location load faster than assets served from a single region.

I thought, why not? How much would it cost?

I didn't actually answer that second question before acting.

## What a CDN on Google Cloud actually involves

So we set up Google Cloud CDN, with a load balancer and everything. Cloud CDN doesn't sit directly in front of Cloud Run. It hangs off an external HTTP(S) load balancer, and the load balancer is the part with a fixed monthly cost whether you get ten requests or ten million.

The setup looked roughly like this:

1. Cloud Run service, unchanged.
2. A serverless network endpoint group pointing at that service.
3. A backend service with Cloud CDN enabled.
4. An external load balancer with forwarding rules, a URL map and a certificate.

None of those steps is especially difficult. The problem is that one of them comes with a meter that never stops running.

## The number

It’s estimated at around $30 a month.

For context, last month’s bill was about $2. This month it will probably reach $30. That’s a 15x jump.

The cost itself isn’t a problem. What intrigued me was the jump in the bill. Thirty dollars won't break anything. But going from "rounding error" to "a line item" in one change, for a site with very little traffic, is the kind of thing I'd like to know before I click deploy, not after.

## Was the latency worth it?

For this site, at this traffic level, the CDN is solving a problem we barely have. Without it, some visitors far from the region wait a bit longer for a page.

I’m okay with 200ms of extra latency there, right?

If I had seen both numbers side by side up front, 200ms on one side and a 15x bill on the other, I could have decided that I don't want a 15x jump in my cloud bill just for adding a CDN.

## So I built the thing I wanted

What I wanted was a place where I could put these pieces together, an instance here, a load balancer there, a CDN, and see what they would cost me before provisioning anything. Not after the first invoice.

So I thought, let’s build that.

That's Cloud Cost Compute. Whatever you add to it, the cost is calculated across Google Cloud, AWS and Azure. So while you're checking what your setup costs on the provider you already use, you can also see what the same setup would cost on a different one.

## The limitations, stated plainly

It’s open source.

The prices are static, picked up from publicly available sources, with no live API calls yet. That means they can drift as providers change their pricing.

So don’t take them as absolute, but you can use it to get a general idea of your future cloud costs before making a decision.

## Lessons learned

1. "Small change" in architecture and "small change" on the bill are different measurements. Check both.
2. Fixed-cost components, like a load balancer, hurt most on low-traffic setups, because there's no traffic to spread the cost over.
3. A performance scan tells you what's faster. It doesn't tell you whether faster is worth it.
4. Price the setup first. Then decide whether 200ms matters to you.

You can find Cloud Cost Compute at [nandan.dev/cloud-cost-compute](https://nandan.dev/cloud-cost-compute).