S3 Storage Lens groups make storage cost conversations less generic

Emiliano Montesdeoca — Fri, 26 Jun 2026 00:00:00 +0000

Storage optimization advice often starts too broadly: reduce old data, review access patterns, apply lifecycle policies. That is true, but it is not specific enough for a team to act.

The AWS Storage Blog post on S3 Storage Lens groups is useful because it shows how to group storage by workload-specific criteria instead of looking only at account or bucket totals.

What changed

S3 Storage Lens groups let builders define custom groupings and analyze metrics for targeted slices of S3 data. The source article uses examples such as older application logs and aging image files across multiple buckets and accounts.

That matters because the useful unit of storage ownership is rarely just a bucket. It may be an application, dataset, tenant, media type, compliance class, or product feature.

Why builders should care

S3 cost and hygiene problems are usually ownership problems.

A central cloud team can see that storage is growing. They may not know which logs are safe to expire, which images are user-generated content, which datasets are legally retained, or which prefixes belong to an old migration. Application teams know the context, but they often lack cross-account visibility.

Storage Lens groups can bridge that gap. They help create a view that says, “this workload has 40 TB of logs older than 180 days,” not just “this account has 400 TB in S3.”

That turns a generic optimization request into a practical backlog item.

The trade-offs

Custom groups are only useful if the grouping logic reflects real ownership and lifecycle rules. If tags, prefixes, naming conventions, or account boundaries are inconsistent, the dashboard can give false confidence.

Teams should avoid building too many groups at once. Start with questions that lead to action:

Which data can move to a colder tier?
Which prefixes have no recent access?
Which workloads are growing faster than expected?
Which buckets contain small-object patterns that inflate request costs?
Which teams own the largest retained datasets?

Also remember that visibility is not enforcement. Storage Lens can show the opportunity, but lifecycle rules, retention policies, and application changes implement the fix.

What to do next

Pick one high-cost storage area and define a group around the way the business thinks about it. For example: production application logs older than 90 days, media originals by product, or export datasets by tenant.

Then review the metrics with the owning team and decide on one action: lifecycle transition, deletion after retention, object compaction, prefix redesign, or access pattern review.

The practical value of Storage Lens groups is not better charts. It is better conversations between platform, finance, security, and application teams about the specific data that is driving cost and risk.

Before downsizing EC2, simulate the EBS burst budget

Emiliano Montesdeoca — Wed, 17 Jun 2026 00:00:00 +0000

Rightsizing EC2 usually starts with CPU and memory. That is necessary, but it is not enough.

The AWS Compute Blog post on simulating Amazon EC2 EBS burst credits before downsizing an instance is a good reminder that storage performance can be the hidden reason a “safe” downsize becomes a production incident.

What changed

The article walks through a simulation approach for burstable EBS-optimized instance performance. Instead of looking only at average utilization, it pulls EBS read and write metrics from CloudWatch, compares them with the baseline and burst ceiling of a target instance type, and simulates whether IOPS or throughput credits would run out after downsizing.

The important metrics include:

EBS read and write bytes,
EBS read and write operations,
EBS I/O and byte balance percentages,
instance EBS IOPS and throughput exceeded checks.

The outcome is more useful than a simple utilization chart: it tells you whether the target instance can absorb the actual I/O pattern without draining credits and throttling.

Why builders should care

Cost optimization often fails when it optimizes one dimension in isolation. A smaller instance can look perfect from a CPU perspective but have lower EBS baseline performance. If the workload depends on burst credits during business hours, the downsize may save compute cost while increasing latency, queue depth, or database wait time.

This matters especially for databases, analytics workers, search nodes, and file-heavy applications. It also matters when downsizing reduces memory. Less memory can mean less cache, which can increase disk I/O after the move.

The practical lesson: do not approve a downsize until the storage path has been modeled.

The trade-offs

The simulation described by AWS is intentionally conservative when using maximum statistics over five-minute periods. That is useful for safety, but it can overstate credit drain. If the conservative simulation passes, confidence is high. If it fails, the answer is not automatically “do nothing.” It may mean you need higher-resolution data, a different target instance, gp3 tuning, or application-level changes.

Also, burst credits are not a performance strategy. They are a buffer. If normal business traffic depends on sustained bursting, the workload is under-provisioned for its real behavior.

What to do next

For each EC2 rightsizing candidate, add a storage check to the decision process:

Pull at least two weeks of CloudWatch EBS metrics, four if the workload has monthly cycles.
Check whether the current instance already hits EBS exceeded metrics.
Compare peak and sustained I/O against the target instance baseline and burst ceiling.
Simulate credit balance for both IOPS and throughput.
Monitor EBSByteBalance%, EBSIOBalance%, and exceeded checks after the change.

This is the kind of small operational habit that prevents cost work from damaging reliability. A good rightsizing recommendation should say not only “CPU is low,” but also “storage credits survive the target shape.”

Cost-Optimization | The AWS Blog

S3 Storage Lens groups make storage cost conversations less generic

What changed

Why builders should care

The trade-offs

What to do next

Before downsizing EC2, simulate the EBS burst budget

What changed

Why builders should care

The trade-offs

What to do next