S3 Storage Lens: interpret storage metrics before changing data

Amazon S3 Storage Lens brings together storage and activity metrics so you can find buckets worth investigating. Start with the report date and scope, then compare the relevant byte categories. A high percentage of noncurrent versions or incomplete uploads is a reason to inspect the workload, not permission to delete data.

This guide explains the current free and advanced metric options and uses an invented bucket dataset to test the arithmetic. We ran 18 local checks on the example. No AWS account, live dashboard, report delivery, or lifecycle change was tested.

Start with the date and scope

In the Amazon S3 console, open Storage Lens and choose a dashboard. AWS provides default-account-dashboard for the account. Its scope cannot be edited; use a separately configured dashboard when you need a different scope. The dashboard opens on the latest date with available metrics, which may differ from today. These steps follow the AWS dashboard guide.

Before comparing two numbers, record the dashboard configuration, report date, account or organization scope, Region filters, and selected bucket or storage class. A total for one bucket and a total for the account answer different questions. A changed filter can look like storage growth even when the underlying data has not changed.

Storage Lens provides daily aggregated analytics for S3 general purpose buckets. Treat its charts as periodic observations. They do not confirm that a deletion, upload, or permissions change has just completed.

Choose free or advanced metrics for a specific question

The metrics selection documentation distinguishes these options:

• Free metrics: usage and configuration measures, including the byte metrics used below. The console query window is 14 days.
• Advanced metrics: additional categories such as request activity and detailed status codes, contextual recommendations, and optional CloudWatch publishing. The query window extends to 15 months; additional charges apply.

Start with the question you cannot answer from the current view. A daily noncurrent-byte comparison does not require request-activity metrics. Before upgrading, check the dashboard’s selected features and current S3 pricing. Advanced metrics carry object-monitoring charges for each dashboard; exporting data or querying it can introduce separate service costs. This guide does not assume that every reporting option is free.

Read the metric definitions before calculating percentages

The Storage Lens glossary gives the export names and definitions. Four names used in this exercise are:

• StorageBytes: total storage, including incomplete uploads, object metadata, and delete markers.
• NonCurrentVersionStorageBytes: bytes belonging to noncurrent object versions.
• IncompleteMultipartUploadStorageBytes: bytes in incomplete multipart uploads.
• IncompleteMPUStorageBytesOlderThan7Days: the portion in incomplete uploads older than seven days.

Current-version bytes describe the current versions. Delete-marker bytes are another metric; a delete marker is not proof that all earlier version data is gone. Use the metric that matches the question rather than treating every stored byte as a current application file.

Work through a synthetic bucket example

The following values are invented, already normalized to one report date and configuration, and aggregated across storage classes within each bucket. They are not a native AWS export or customer measurements. Here, GiB means 2 to the power of 30 bytes.

• Bucket A: 100 GiB total, 30 GiB noncurrent, 5 GiB incomplete uploads, including 3 GiB older than seven days.
• Bucket B: 900 GiB total, 90 GiB noncurrent, 45 GiB incomplete uploads, including 9 GiB older than seven days.
• Empty bucket: zero for all four measures.

The selected scope contains 1,000 GiB total and 120 GiB noncurrent. Its noncurrent share is therefore 12%. Bucket A’s share is 30% and Bucket B’s is 10%; their simple average is 20%. That average gives the small bucket the same weight as the large one and answers the wrong question about the combined storage.

Calculate the share from the summed byte values. This standalone Python example reproduces the arithmetic:

# Invented bucket-level values, already normalized to one date and scope.
# Each tuple is: total GiB, noncurrent GiB, incomplete-upload GiB,
# incomplete-upload GiB older than seven days.
buckets = [(100, 30, 5, 3), (900, 90, 45, 9), (0, 0, 0, 0)]
total, noncurrent, incomplete, older = (
    sum(row[column] for row in buckets) for column in range(4)
)

def percentage(part, whole):
    return None if whole == 0 else round(100 * part / whole, 2)

print('Noncurrent / total:', percentage(noncurrent, total))
print('Incomplete / total:', percentage(incomplete, total))
print('Older uploads / total:', percentage(older, total))
print('Older uploads / incomplete:', percentage(older, incomplete))
print('Empty bucket:', percentage(0, 0))

The observed output is:

Noncurrent / total: 12.0
Incomplete / total: 5.0
Older uploads / total: 1.2
Older uploads / incomplete: 24.0
Empty bucket: None

The 12 GiB of older incomplete uploads is 1.2% of all selected storage, but 24% of incomplete-upload storage. Both calculations are valid when their denominators are named. They do not express the same metric.

Older uploads are already included in the 50 GiB incomplete-upload total. Adding 12 to 50 would double-count them. Likewise, an empty bucket has an undefined percentage; reporting zero would imply that a ratio was measured. The example returns None instead.

Keep export rows at one consistent level

A real export needs preparation before using that calculation. The AWS export schema includes dimensions such as configuration, date, account, Region, storage class, and record type. Bucket rows, account totals, and prefix rows can describe overlapping data. Do not add them all together.

Choose a single date and configuration, retain the dimensions needed to define the scope, and aggregate only nonoverlapping rows. If storage-class rows are combined into bucket totals, establish their completeness first. Do not mix those totals with the rows used to build them. A missing metric is not automatically zero.

For general purpose bucket exports, use the daily manifest to identify the report schema and every listed report file. Reading one file from a multi-file report can produce plausible but incomplete results. Match the report date and configuration before merging data.

Our separate local fixture uses a simplified six-column CSV. The validator excludes account, prefix, other-date, and other-configuration rows; it rejects duplicates, missing values, invalid byte values, and impossible subset relationships. It does not ingest native AWS CSV or Parquet, interpret a real manifest, or verify delivery. Adapting it requires a separately checked normalization step.

AWS supports CSV and Parquet exports to general purpose buckets. It also supports S3 Tables exports, with different schemas and service costs. Choose a destination for the analysis you intend to run; the existence of another format does not make the local example compatible with it.

Turn a finding into a scoped investigation

In the example, Bucket B has the larger absolute amount of noncurrent data even though Bucket A has the higher percentage. The useful first candidate depends on whether you are investigating absolute retained capacity, a sudden growth pattern, or a particular application’s behavior.

• Noncurrent versions: review recovery needs, retention requirements, and version-specific rules. Our S3 Versioning guide explains why a normal delete can leave earlier versions. A high retained-byte count is not evidence that those versions are unnecessary.
• Incomplete uploads: inspect the application’s completion, retry, and abort behavior. Use the multipart-upload guide to review that workflow before choosing a cleanup interval.
• Lifecycle changes: inspect the existing configuration and intended prefix before preparing an amendment. The lifecycle policy guide separates transitions, current-version expiration, and noncurrent-version actions.

Ordinary object expiration does not remove incomplete uploads. AWS documents a separate AbortIncompleteMultipartUpload action. Select its age threshold from the application’s legitimate upload behavior; the seven-day metric boundary is not an automatic policy recommendation.

When you need object or version records for an investigation, use an appropriately configured S3 Inventory report. Storage Lens aggregates do not identify which particular object should be removed. Inventory is a different report and still needs interpretation against retention and application requirements.

Verify the result without promising savings

After an approved change, verify its actual configuration and behavior, then compare later Storage Lens reports using the same scope. Record concurrent uploads, deletes, and retention changes that could explain the movement. A falling percentage alone can be caused by growth in the denominator.

A 12% noncurrent-byte share does not mean a 12% reduction in the bill is available. Storage classes, requests, retrieval, minimum charges, and required retention affect the result. Use billing evidence and the applicable rates for a cost estimate; this example measures byte ratios only.

Storage Lens is an AWS analytics feature. For Hivenet or another provider, verify the available monitoring and export features separately. S3 API compatibility alone does not establish support for the Storage Lens dashboard or its paid options.

The 18 checks ran locally with Python 3.12.14 and synthetic data. They validate filtering, arithmetic, error handling, and the displayed code. No AWS authentication, live metrics, report delivery, CloudWatch integration, billing reconciliation, or data change was tested.