Why Egress Is the Cloud Cost Problem Worth Solving
Cloud providers charge when data leaves their infrastructure. Storage costs are easy to understand and plan for, but egress costs grow with your product. The more users you serve and the more data they download, the higher this cost becomes.
For Amazon S3 in the Mumbai region, the first 100 GB per month is free. After that, pricing is around $0.09 per GB, roughly ₹7.5 per GB for the initial usage tier. If a product serves 500,000 users and each downloads about 2 GB per month, total data transfer reaches around 1,000,000 GB. That translates to an egress bill of roughly ₹70–75 lakh per month, even before considering other infrastructure costs.
Most teams only realise this when they see the bill. Everything looks fine, the product is growing, and then suddenly a large part of the cost comes from one line item called data transfer out. It is not a mistake in setup, it is just something that was not planned for early on.
The strategies that follow focus on tackling this from different angles, reducing how much data is transferred, lowering the cost per GB, and avoiding unnecessary transfers altogether.
Three of the five strategies reduce egress volume. One reduces egress price. The fifth does both when combined with the others.
Strategy 1: CDN Caching — Serve Most Requests Without Hitting the Origin
A CDN sits between your users and your storage. When someone requests a file, the CDN first checks if it already has a cached copy. If yes, it serves it directly from the edge with no origin egress. If not, it fetches it once from storage and caches it for future requests.
CDN traffic is much cheaper than origin egress. In India, CDN rates are usually around ₹0.50 to ₹1.50 per GB, compared to ₹7+ per GB from AWS S3. Also, cached content only hits the origin once, and then gets reused across multiple users.
The key metric here is cache hit rate. If your CDN hits 90%, only 10% of traffic goes back to origin. That means most of your data is served at CDN rates, bringing down the overall cost significantly.
You can improve this by caching static assets for longer, keeping cache keys simple, and avoiding unnecessary query parameters that break caching.
IBEE works easily with any CDN that supports S3-compatible origins. You just point the CDN to your IBEE bucket, and it handles delivery while the origin only sees cache misses.
We have seen teams still face high costs even with a CDN, mainly due to poor cache configuration. Fixing something as simple as cache keys has reduced origin egress by over 80% in real cases.
Strategy 2: Asset Compression — Serve Fewer Bytes Per Request
Compression is one of the simplest ways to cut down how much data you send per request. For text-based files like HTML, JavaScript, CSS, JSON, and SVG, using gzip or Brotli can reduce file size by around 60 to 80%.
For static assets, you can generate pre-compressed .gz and .br versions during the build process and upload them along with the original files. When a browser or CDN requests data with compression support, it gets the smaller version and decompresses it locally.
For APIs, enabling gzip on your server helps a lot. A JSON response that is 500 KB can drop to around 80 to 100 KB. When this happens across thousands of requests, the savings add up quickly.
Images also make a big difference. Formats like WebP can reduce size by 25 to 35% compared to JPEG, and AVIF can go even lower. Serving modern formats where supported, with fallback options, improves efficiency without affecting quality.
If you bring down your average page size from 3 MB to 1.5 MB, you effectively cut your egress cost in half, without changing anything for the user.
Strategy 3: Lazy Loading and Request Batching — Avoid Transferring Data Not Used
Egress is charged for every byte that leaves the cloud, even if the user never actually uses it. Loading all images on a page at once, including ones the user never scrolls to, wastes data. The same goes for APIs that return full responses when only a few fields are needed.
Lazy loading helps avoid this. Images are loaded only when they come into view, using simple browser support like the loading="lazy" attribute. So if a page has 50 images but the user only sees 10, only those 10 should be downloaded.
APIs can also be optimised by returning only the required data. For example, if a mobile app only needs a product name and thumbnail, it should not fetch the entire object with many unused fields.
Another common issue is fetching all data at once when pagination would work. Exporting or loading full datasets on every request increases unnecessary data transfer. Fixing pagination is often one of the quickest and most effective ways to reduce egress costs.
Strategy 4: Format Optimisation for Large Files
Media files like video, audio, and images usually make up most of the egress in content-heavy products. The formats and delivery methods you choose directly affect how much data you end up paying for.
For video, adaptive bitrate streaming helps a lot. Instead of sending one high-quality file, you provide multiple versions using HLS or DASH. The user automatically gets the right quality based on their network. So someone on 4G might get 720p instead of 4K, which reduces data usage per view.
For images, it is important to serve the right size for the device. Sending a very large image to a small mobile screen wastes data. Using techniques like srcset or CDN-based resizing ensures users only download what they actually need. For audio, using very high-quality formats where they are not needed also increases cost. In many cases, users cannot tell the difference between formats like FLAC and compressed audio, but the data usage is much higher.
Optimising media delivery like this can significantly reduce egress without affecting user experience.
Strategy 5: Provider Migration — Change the Rate Per GB
Strategies 1 to 4 reduce egress volume. Strategy 5 reduces egress price. For most Indian businesses serving Indian users on AWS S3 Mumbai, migrating user-serving storage to IBEE at Rs.2/GB egress reduces the effective egress rate by 3 to 5 times regardless of volume.
The combination of strategies is most powerful. CDN caching reduces origin egress volume, and IBEE's lower rate reduces the cost of the origin egress that remains. A team achieving 85% CDN cache hit rate and migrating origin storage to IBEE at Rs.2/GB pays origin egress rates on 15% of traffic at a 3 to 5 times lower rate than before: a combined reduction of 15 to 25 times on the egress bill component that was previously the largest single cost.
The migration is an endpoint URL change. IBEE's full S3-compatible API means your existing CLI scripts, SDK code, and application configurations work without modification. The savings are permanent.
One engineering lead we spoke to described their migration process: they changed the endpoint URL on a Friday afternoon, ran their integration tests, and were done by 5 PM. The following month's bill was the confirmation. They had been putting it off for six months because they assumed it would be a project. It was an afternoon.
Measuring the Impact
Before you apply any of these strategies, first get a clear baseline. Check your current monthly egress volume from the billing dashboard, your cost per GB, and the total amount you are spending on egress.
After making changes, track what actually improved. Look at CDN cache hit rate, compare response sizes before and after compression, and measure how much your monthly egress volume has reduced. Convert this into monthly savings in rupees, that is what really matters for reporting and decision-making.
Teams that do this properly often realise that egress optimisation gives one of the highest returns for the effort involved. Spending a couple of days to save a few lakhs every month is usually an easy decision once the numbers are clear.