Cutting an AWS bill by 40 percent

EDUCATION · AWS · COST OPTIMISATION

This is a real engagement. The client is an education provider running a learning platform on AWS, and they have asked not to be named, so the architecture is described in full but the company is not.

The symptom

Their daily AWS spend began rising without an obvious trigger. No new environment had been launched, no migration was underway, and the rise was not proportional to anything the team had changed. Left alone for a full billing cycle it would have shown up as a materially larger invoice with no explanation attached to it.

It was picked up because we watch daily cost on the accounts we manage rather than reviewing spend monthly. That distinction is the whole reason this became a small problem instead of a large one. A spike caught on day two costs two days of money. The same spike caught on an invoice costs a month.

What the investigation found

Our cloud engineer worked back from the cost breakdown to the service generating it, and the answer was data transfer rather than compute. The platform's course images were stored in an S3 bucket, and the application running on EC2 referenced them by their public URLs. Every learner loading a page pulled those images out of S3 over the public internet.

That is billed. S3 charges for data transferred out to the internet, per gigabyte, every time an object leaves. There was no caching layer in front, so the same image travelled out of S3 again for every learner and every page view. Nothing was wrong with the application and nothing was misconfigured in the usual sense. The delivery path was simply the most expensive one available, and it had been fine while traffic was small.

The reason it surfaced when it did is that image delivery cost scales with traffic, and traffic had grown. A pattern that is invisible at low volume becomes the largest line on the bill at higher volume.

What we did not do

Two obvious moves were considered and set aside, and the reasoning matters more than the conclusion.

• A VPC gateway endpoint for S3. This is the right fix when it is your own servers inside the VPC pulling from S3, because it keeps that traffic off the public internet and off any NAT gateway. It does nothing here, because the requests were coming from learners' browsers, not from EC2.
• Compressing and resizing the images. Worth doing on its own merits, and it would have reduced the bytes per request. It does not change the fact that every single request was being served from origin, so it treats the symptom and leaves the delivery path intact.

The fix

We put Amazon CloudFront in front of the bucket and pointed image delivery at the distribution instead of at S3 directly.

The saving comes from where requests are answered. Once an image is cached at an edge location, subsequent requests for it are served from that edge and never reach S3 at all. Origin fetches collapse to a small fraction of total requests, and it is those origin fetches that were generating the S3 data transfer charges. AWS also does not bill S3 data transfer out when the destination is CloudFront, so the fetches that do reach origin are cheaper than they were.

CloudFront has its own data transfer and request pricing, so this is not free delivery. It is much cheaper delivery, because you stop paying to send the same file out of origin thousands of times.

The bill did not go up because the client was doing more business. It went up because every learner was paying an origin fetch for an image that had not changed in months.

The result

Cloud cost came down by 40 percent after the change. The spike was removed, and because delivery is now cached rather than repeated, cost grows far more slowly as traffic grows. The client did not have to rewrite the application, reduce image quality, or move any workload.

How to check whether this applies to you

If you run anything image heavy or file heavy on AWS, three questions will tell you quickly.

• Is data transfer a top line in your cost breakdown? Open Cost Explorer and group by usage type rather than by service. Transfer costs hide inside a service total.
• Are any object storage URLs being hit directly by browsers? View source on a page that loads media and look at where the files come from. A bucket hostname in that position is a signal.
• Are you reviewing cost daily or monthly? Monthly review means every cost problem is discovered after it has been paid for.

The same pattern occurs on Azure and Google Cloud. The service names differ, the economics do not.

The 40 percent figure is from this specific engagement. Your own result depends on your traffic profile, how cacheable your files are, and what your current delivery path looks like. We will tell you honestly what to expect before you commit to anything.

More on cloud cost