How to Audit Your Cloud Storage Bill — A Step-by-Step Guide for Engineering Teams

For engineering leads, DevOps engineers, and CTOs responsible for cloud infrastructure costs at Indian businesses.

The Cloud Storage Bill Nobody Reads

Cloud storage bills are paid monthly, logged in a spreadsheet as "infrastructure," and never examined at line-item level. The total grows slowly — a few percent each month as data accumulates and user traffic increases — and no single month's growth is alarming enough to trigger an investigation.

The problem is that cloud storage bills accumulate waste in ways that are invisible at the total level but obvious at the line-item level. Orphaned buckets from deprecated projects. Log data retained indefinitely when retention requirements specify 90 days. Egress costs from serving data to Indian users at Rs.9/GB when a cheaper provider would serve the same data at Rs.2/GB. Unnecessary data transfer fees from buckets in the wrong region.

A one-hour structured audit of a cloud storage bill typically surfaces 20–40% in identifiable waste. This guide is that audit, step by step.

Step 1 — Get the Cost Breakdown by Service Dimension

Cloud provider billing dashboards show total costs but hide the dimension-level breakdown that reveals where money is going. The first step is to get the bill broken down by the dimensions that matter for storage.

On AWS, use Cost Explorer with the following configuration: service = S3, group by "Usage Type." This shows you the individual components of the S3 bill — Standard Storage, Requests-Tier1, Requests-Tier2, DataTransfer-Out-Bytes, DataTransfer-Regional-Bytes, and so on.

Write down the top five line items by cost. These are where the investigation focuses.

The most common pattern for Indian businesses: DataTransfer-Out-Bytes (internet egress) is the largest single line item, often larger than storage cost itself. If your egress line exceeds your storage line, the audit has already identified the primary savings opportunity.

Step 2 — Inventory Every Bucket

List all S3 buckets in your account:

aws s3api list-buckets \

--query 'Buckets[].{Name:Name,Created:CreationDate}' \

--output table

For each bucket, check size and object count:

aws cloudwatch get-metric-statistics \

--namespace AWS/S3 \

--metric-name BucketSizeBytes \

--dimensions Name=BucketName,Value=your-bucket Name=StorageType,Value=StandardStorage \

--start-time 2024-01-01T00:00:00 \

--end-time 2024-01-02T00:00:00 \

--period 86400 \

--statistics Average \

--output text

Or use S3 Storage Lens (AWS) for a dashboard view of size by bucket. The goal is a list: every bucket, its size, and its last-write date. Buckets that have not been written to in over a year are candidates for archival or deletion.

Step 3 — Identify Orphaned Buckets

Orphaned buckets are buckets that continue to accumulate storage costs for data that no longer serves any active purpose. Common sources:

Deprecated project buckets — a project was discontinued 18 months ago but the S3 bucket holding its data was never deleted. The data is paying storage costs every month with zero utilisation.

Old backup destinations — the backup tool was changed but the old bucket was not decommissioned. It contains backups that are now superseded by a new backup system.

Feature flag buckets — created during an A/B test or feature development, never removed when the feature shipped or was rolled back.

For each bucket identified as potentially orphaned: check when it was last accessed (use S3 server access logs or S3 Storage Lens access metrics), verify with the engineering team that owns the project whether the data is still needed, and either tag it for retention with an explicit owner or delete it.

Step 4 — Audit Lifecycle Policies

Lifecycle policies automate the transition of objects to cheaper storage classes and the deletion of objects past their retention period. Missing or misconfigured lifecycle policies are a common source of avoidable storage cost.

Check existing lifecycle policies on every bucket:

aws s3api get-bucket-lifecycle-configuration --bucket your-bucket-name

For buckets that should have lifecycle policies but do not, the waste calculation is: objects that should have been deleted six months ago are still paying full storage cost.

Common missing policies: application logs retained indefinitely when the business requirement is 90 days. Build artifacts from CI/CD pipelines accumulating without expiry. Multipart upload fragments from incomplete uploads (a common source of hidden costs — incomplete multipart uploads accumulate storage charges until explicitly cleaned up with an AbortIncompleteMultipartUpload lifecycle rule).

Add an AbortIncompleteMultipartUpload lifecycle rule with DaysAfterInitiation: 7 to every bucket that accepts uploads. This alone often reduces storage bills by several percent.

Step 5 — Analyse Egress by Destination

Internet egress is the highest-unit-cost line item on most Indian cloud storage bills. AWS charges Rs.6.75/GB for the first 10 TB of internet egress from S3 Mumbai. If your bill shows significant egress, the next question is: where is the data going?

AWS S3 access logs record the requester IP, the request size, and the response size for every operation. Enable access logging on high-egress buckets and analyse the logs to determine whether the egress is serving legitimate user requests or is the result of misconfigured clients, public buckets being indexed by crawlers, or data being served from the wrong region.

For legitimate user egress — data being served to Indian users as part of the product — the egress rate comparison between AWS S3 Mumbai (Rs.6.75+/GB) and IBEE (Rs.2/GB) determines whether provider migration should be on the action list.

Step 6 — Check for Inter-Region Transfer Costs

Data transfer between AWS regions is billed separately from internet egress. If your architecture has buckets in multiple regions and data flows between them — replication, cross-region Lambda processing, data copied from a Mumbai bucket to a Singapore bucket for analytics — each transfer is billed at the inter-region rate.

In Cost Explorer, the DataTransfer-Regional-Bytes line item captures this. If it is significant, trace which buckets are generating it and whether the cross-region architecture is still necessary.

Step 7 — Prioritise Actions

After the audit, you will have a list of findings. Prioritise by savings potential:

Highest impact, immediate action: Delete confirmed orphaned buckets after data verification. Add missing lifecycle policies, especially AbortIncompleteMultipartUpload rules. Fix any misconfigured public buckets being accessed by crawlers.

Medium impact, requires planning: Migrate user-serving egress-heavy workloads from AWS S3 Mumbai to IBEE if the egress rate difference is material. Implement lifecycle transitions to cheaper storage classes for data with known access patterns.

Lower impact, ongoing: Tagging strategy for cost attribution. Storage Lens dashboards for ongoing visibility. Quarterly bill reviews as a standing agenda item.

What IBEE Changes About the Egress Line

For most Indian businesses, the storage audit ends at the same conclusion: the egress line is the largest cost driver, and the difference between AWS S3 Mumbai's Rs.6.75+/GB and IBEE's Rs.2/GB is not a marginal saving — it is a 3–5x reduction on the bill's biggest component.

The migration is an endpoint change. The audit is the first step to knowing whether it is worth doing.