TL;DR: Most organizations don't struggle to define cloud governance standards. They struggle to make those standards stick. Whether it's tagging, backup policies, security controls, or cost optimization, the hardest problems are usually organizational rather than technical. Successful cloud governance depends on communication, ownership, prioritization, and change management as much as automation and policy enforcement.

Much earlier in my career, I found AWS tags slightly strange.

I worked within a single application team. We knew which resources belonged to our application, which environment they supported, and who was responsible for them. The answers were usually visible in the repository, the deployment pipeline, the resource name, or simply sitting inside someone's head.

Why did I need to add an Application tag? I knew which application it was.

Why did I need an Owner tag? I knew who owned it.

Why add Environment when the account or resource name already made that obvious?

From inside one application team, tags looked like administrative metadata added for someone else's benefit. They felt like extra work rather than something that helped us build or run the application.

That view was understandable.

It was also incomplete.

My perspective changed when I began working across multiple environments, AWS accounts, applications, and teams. Suddenly, I was looking at resources without the context of the people who created them.

The questions changed too:

• Who owns this resource?

• Which application depends on it?

• Is it still needed?

• Can it be stopped outside working hours?

• Which cost centre should pay for it?

• What backup policy applies?

• Who should receive the ticket when something is misconfigured?

The resource name rarely contained enough reliable information. Documentation was often incomplete or outdated. The engineer who created the resource might have moved to another team, or left the organization entirely.

I had misunderstood who the tags were for.

They were not primarily for the engineer creating the resource. They were for everybody, and every system, that would later encounter it without the original context.

That realization taught me something broader than the value of tagging:

Cloud governance does not usually fail because organizations cannot define standards. It fails because standards must travel through imperfect organizations.

They cross team boundaries, ownership models, product backlogs, communication channels, legacy systems, and competing priorities.

That makes cloud governance a change management problem as much as a technical one.

Context Stops Scaling Before Infrastructure Does

Within a single application team, context is cheap.

People know what is being deployed and why. They understand naming conventions, architectural decisions, and the history behind unusual resources. Much of that knowledge is informal, but still readily available.

At organizational scale, context becomes distributed.

A FinOps team examining costs may not know the application architecture. A security team investigating a finding may not know which developers to contact. A platform team identifying an unattached volume may not know whether it is abandoned or deliberately retained for recovery.

Tags and other forms of metadata help preserve that context.

AWS positions tagging as a mechanism for categorizing resources and supporting activities such as cost monitoring, operations, incident management, backup, access control, and resource management. AWS also distinguishes between reactive governance, finding resources that do not comply, and proactive governance, where controls prevent noncompliant resources from being created.

But adding metadata is not the same as creating useful context.

A resource carrying this tag is not necessarily well governed:

Owner=Platform

What does Platform mean?

Is that a technical owner, business owner, support team, or cost owner? Is it still accurate? Is there an authoritative list of valid values? Does Platform map to a team that still exists?

Governance depends on shared meaning, not merely the presence of key-value pairs.

And shared meaning is an organizational problem.

Setting the Standard Is the Easy Part

Most cloud standards begin reasonably.

An organization wants better cost reporting, so it introduces the CostCenter tag.

It wants to route operational findings, so it introduces Owner.

It wants to automate stopping development resources, so it introduces CronSchedule.

The standards may look something like this:

• Application

• Environment

• Owner

• CostCenter

• DataClassification

A platform, security, FinOps, or governance team documents the requirements. The proposal is reviewed. Stakeholders agree that the information is useful.

The standard is approved.

That is often treated as the end of the decision.

In reality, it is the beginning of the difficult part.

The standard now has to leave the meeting in which it was defined and reach the people who must implement it. More importantly, those people must understand what has changed, why it matters, what action is expected, and where the work fits among everything else they are responsible for.

This is where governance can quickly become the Wild West.

One team receives a detailed explanation during a meeting. Another receives a link to a wiki page. Another gets a spreadsheet listing noncompliant resources. A fourth discovers the requirement when a deployment pipeline starts failing.

New engineers join after the original communication and inherit the implementation without its rationale.

Eventually, multiple versions of the truth emerge:

• The standard that was originally approved

• The standard described in the documentation

• The standard application teams remember

• The standard implemented by reusable infrastructure components

• The standard enforced by pipelines

• The standard expected by reporting

• The unofficial collection of known exceptions

This does not necessarily happen because anyone is careless.

Communication naturally decays as information moves through an organization. Standards evolve, teams reorganize, documentation becomes stale, and local interpretations appear.

The technical control may still work perfectly while the governance system around it becomes increasingly unreliable.

The Team Defining the Standard Often Does Not Own the Change

Cloud governance usually involves distributed ownership.

The responsibilities may look like this:

• Platform or governance team -> Defines the desired outcome

• Application team -> Owns the infrastructure code

• Product owner -> Prioritizes the work

• Security, FinOps, or Operations -> Depends on the resulting metadata

The platform team can identify hundreds of resources with missing tags, but it may not be able to safely change every application repository.

The application team can update the infrastructure code, but it may not understand how the metadata is used by central reporting or automation.

The product owner decides whether that work is prioritized over feature development, operational incidents, security remediation, or technical debt.

Everyone Owns a Part of the Problem

Nobody necessarily owns the complete outcome.

This is why a request to "remediate missing tags" can remain open for months even when everyone agrees that the tags should exist.

It is tempting for a central team to conclude that application teams simply do not care about governance. From the application team's perspective, however, the request may appear as an unexplained internal task with no customer impact, deadline, or visible consequence.

Both perspectives can be rational.

The failure is in the system connecting them.

Technically, adding a tag may be a one-line change. Organizationally, it may require considerably more.

An application team may need to:

1. Find the correct repository

2. Determine where tags are currently applied

3. Establish the authoritative value

4. Update CDK, Terraform, or another deployment mechanism

5. Test inheritance and propagation behaviour

6. Roll the change through multiple environments

7. Handle manually created or legacy resources

8. Verify that central reporting recognizes the value

9. Coordinate with another team that owns the source data

The work then competes with:

• Customer-facing features

• Production incidents

• Security vulnerabilities

• Reliability improvements

• Regulatory deadlines

• Technical debt

• Other governance findings

The Idealistic View

Every approved standard is important, so teams should implement it promptly.

The Realistic View

Engineering capacity is limited. Work is prioritized according to perceived risk, business impact, urgency, and leadership attention.

This does not mean governance should always lose to feature development. It means a platform team needs to explain more than the technical requirement.

It should be able to answer:

• What problem does this standard solve?

• What happens if a team does nothing?

• How urgent is the change?

• Which resources matter most?

• How much work is expected?

• Can part of the remediation be automated?

• What support is available?

• When will enforcement begin?

A technically small change is not automatically an organizationally small change.

Communication Is Part of the Platform

The obvious answer is to communicate better.

Unfortunately, that often translates into another email, meeting, Teams announcement, or wiki page.

Those things can help, but none of them provides a complete solution.

People miss announcements. Meetings do not scale. Documentation becomes stale. Dashboards do not create ownership. Tickets do not create priority. Pipeline failures do not explain why a standard exists.

A realistic governance communication model needs several layers.

1. Maintain One Canonical Source of Truth

Every standard should have one authoritative location.

For each control, that source should explain:

• The requirement

• The purpose

• The scope

• The standard owner

• The affected teams

• The effective date

• The expected values

• The enforcement mechanism

• The remediation path

• The exception process

• The review date

• The change history

A canonical page does not guarantee that people will read it.

But without one, every conversation begins with a different version of the truth.

2. Communicate the Change, Not Just the Document

An announcement like this is rarely enough:

The cloud governance policy has been updated. Please review the documentation.

A useful announcement should explain:

• What changed

• Why it changed

• Who is affected

• What action is required

• When action is required

• How compliance will be measured

• Whether enforcement is changing

• Where questions can be raised

The documentation remains the source of truth.

The communication explains the change.

3. Introduce Standards in Stages

A new standard should not normally move directly from a meeting into a blocking pipeline control.

A more realistic rollout looks like this:

1. Define and document

2. Measure existing compliance

3. Communicate the impact

4. Warn on new noncompliance

5. Provide a supported remediation path

6. Enforce the standard for new resources

7. Prioritize legacy remediation

The exact stages depend on the risk.

4. Put Guidance Close to the Work

A standard becomes easier to adopt when engineers encounter it inside their normal workflow.

Examples include:

• Reusable CDK constructs or Terraform modules

• Pull request validation

• Pipeline warnings

• Deployment-time checks

• Actionable compliance findings

• Clear examples in preferred tooling

• Automated remediation where safe and deterministic

Instead of:

Missing required tag

Provide:

Resource: AWS::EC2::Instance
Missing tag: Application

Purpose:
Used for resource ownership and cost allocation.

Expected value:
Registered application identifier.

Remediation guidance:
https://example.internal/standards/tags/application

Automation should reduce the need to remember standards.

It should not remove the need to understand them.

5. Create a Feedback Loop

Standards are often designed centrally but implemented locally.

That means application teams will encounter realities that the standard authors did not anticipate.

Examples include:

• Required values unavailable during provisioning

• Resources that do not support expected tagging behaviour

• Conflicting controls

• Automated remediations creating deployment risk

• Missing authoritative data sources

A governance standard needs authority, but it should not be immune to feedback.

Exceptions Are Expensive Because Context Expires

Not every exception is bad.

Legacy workloads, migrations, vendor-managed systems, short-lived experiments, regulatory differences, and technical limitations can all justify deviations from a standard.

The problem is not the existence of exceptions.

The problem is losing the reason they exist.

Every exception should have:

• A documented reason

• A clear scope

• An owner

• An approver

• An expiry date

• A review mechanism

An exception without an owner and expiry date is not really an exception.

It is a second standard that nobody has documented properly.

That is governance debt.

Detection Is Easier Than Prioritisation

Cloud environments can produce enormous lists of findings:

• Missing tags

• Incorrect retention periods

• Oversized compute

• Unattached storage

• Configuration drift

• Missing backups

• Outdated runtimes

• Public exposure

Detecting these conditions is increasingly straightforward.

Deciding what should be fixed first is much harder.

Findings should be evaluated using factors such as:

• Risk

• Financial impact

• Environment

• Blast radius

• Confidence

• Effort

• Ownership

• Urgency

Governance requires judgment.

Automation can detect, classify, and sometimes remediate.

It cannot eliminate the need to agree on risk, ownership, and priority.

The Platform Architect Is a Facilitator, Not Merely an Enforcer

A weak model of cloud governance looks like this:

A central team defines the rules, and application teams comply.

A more effective model recognizes platform architecture as a facilitation role.

The platform architect helps:

• Bring stakeholders together

• Translate organizational risk into technical standards

• Explain the purpose behind requirements

• Challenge standards with no clear consumer

• Establish safe defaults

• Make standards discoverable

• Clarify remediation ownership

• Prioritize findings

• Automate repetitive work

• Keep exceptions visible and temporary

• Listen when controls create friction

• Measure whether the organization is actually improving

The objective is not maximum enforcement.

It is the right level of governance for the risk, implemented in a way that teams can understand and sustain.

Final Thoughts

I used to think tags existed to help engineers identify resources they had created themselves.

From that perspective, they did feel pointless. I already knew what everything was.

What I had not yet experienced (all those years ago) was an environment where the person investigating a resource might belong to another team, work in another part of the organization, or arrive several years after the resource was created.

Tags preserve some of the context that organizations otherwise lose.

But writing Owner=TeamA is still the easy part.

The difficult part is agreeing on what ownership means, maintaining the source of truth, communicating changes, deciding who must remediate existing resources, managing legitimate exceptions, and determining where the work belongs among everything else competing for attention.

That lesson extends far beyond tagging.

A cloud standard can be technically correct, thoroughly documented, and perfectly automated, and still fail if the organization does not understand it, trust it, own it, or prioritize it.

That is why cloud governance is not merely a configuration problem.

It is a change management problem.

And helping an organization navigate that change is part of platform architecture.

A team builds something sensible. They separate environments properly - Development, Acceptance, Production.
They follow best practices: tagging, scaling, monitoring… the works.

And then, a few months later, someone opens the bill and asks:

“Why is this still costing so much when nothing’s really happening?”

That’s the interesting part.

Because in most cases, nothing is happening.

At least not in the way the system was originally designed.

The workloads are quiet. The deployments are stable.
The traffic is predictable.

But the infrastructure?

That’s still behaving like it’s launch day.

This article looks at three places where AWS defaults quietly keep things running (and billing), even when your workload has moved on:

• Compute that doesn’t know when to rest

• Logs that remember more than anyone reads

• Storage that outlives its purpose

And more importantly - what it looks like when you design with intent instead.

1) Compute That Never Learned When to Stop

Let’s start with compute, because it’s the easiest to reason about (and the easiest to ignore).

The Shape of a Real Environment

In most modern AWS setups we have something like:

Development

• A few small EC2 instances

• Created and destroyed somewhat unpredictably

• Often left running longer than intended

Acceptance

• Auto Scaling groups

• Lower baseline than production

• Scales up during testing, then… doesn’t always scale back down

Production

• Auto Scaling done properly (usually)

• But includes non-customer-facing components that don’t need 24/7 uptime

So the problem isn’t just “instances running too long.”

It’s:

Parts of the system behaving like they’re always needed, even when they’re not.

On a side note: one could also do this with RDS, but for the purposes of this blog I will stick to EC2.

Where Scheduling Still Matters (Even with Auto Scaling)

There’s a common assumption:

“We use Auto Scaling, so we’re already optimized.”

That’s only partially true.

Auto Scaling optimises for load.
It does not optimise (by default) for:

• Time-of-day usage patterns

• Human working hours

• Internal systems that nobody uses at night

So you still end up with:

• Baseline capacity that never drops to zero

• Dev instances quietly running overnight

• Acceptance environments idling between test cycles

The Pattern: Scheduled Intent

The solution is not replacing Auto Scaling.

It’s complementing it.

• Dev EC2 → scheduled stop/start

• Acceptance ASG → scheduled min capacity = 0 off-hours

• Prod (select workloads) → scheduled scale-down or shutdown

Using:

• EventBridge schedules

• Lambda functions

• Tag-driven targeting

Pricing Context (eu-west-1)

• c7g.large: ~$0.078/hour

• c7g.xlarge: ~$0.155/hour

Monthly saving per instance (~510 hours avoided):

• Dev-sized: ~$40/month

• Prod-sized: ~$79/month

What This Looks Like

Small environment

• Dev: 3 instances

• Acc: baseline 2

• Prod: 1 schedulable internal workload

Savings:

• Dev: $120

• Acc: $80

• Prod: $79

→ ~$280/month

Medium environment

• Dev: ~10 instances

• Acc: baseline ~6

• Prod: internal workloads

→ ~$1,100/month

Large environment

• Dev: dozens of instances

• Acc: multiple ASGs

• Prod: internal services at scale

→ ~\(3,500–\)4,000/month

The Subtle Realisation

Auto Scaling optimises for demand.
Scheduling optimises for the absence of demand.

You need both.

2) CloudWatch Logs: The Cost of Remembering Everything

Logs are comforting.

They make us feel prepared, responsible, and mildly in control.

They also quietly accumulate into something nobody explicitly designed.

CloudWatch Logs defaults to never expire.

Which is great - right up until you realise you’re paying to remember things nobody reads anymore.

The Pattern: Make Retention Explicit

Instead of relying on good intentions:

• Dev → 7 days

• Acc → 30 days

• Prod → 90 days

And enforce it using:

• AWS Config custom rule

• SSM auto-remediation (or Lambda function if you need custom logic)

This turns retention into a system, not a habit.

The Important Bit Most People Miss

CloudWatch Logs has two separate cost drivers:

1. Ingestion (writing logs)

2. Storage (keeping them)

Retention only affects storage.

Which means:

You don’t reduce logging cost by deleting logs.
You reduce storage cost.

That distinction matters more than it should.

A Note on Compression (Because This Gets Confusing)

CloudWatch Logs stores data in a compressed format, but AWS does not publish a fixed compression ratio.

In their pricing examples, log data is often shown compressing to roughly 15–20% of its original size (roughly 5:1 to 6:1).

Actual compression depends heavily on:

• log format (JSON vs text)

• repetition

• structure

For the purposes of these examples, we’ll assume ~5:1 compression.

Not because it’s exact — but because it’s a reasonable approximation for comparative analysis.

Pricing Assumptions (eu-west-1)

• Ingestion: $0.57/GB

• Storage: $0.03/GB-month

• Free tier: 5 GB

• Compression ratio of 5:1

Small Environment

Log volume

• Dev: 5 GB/day

• Acc: 10 GB/day

• Prod: 30 GB/day

Total: 45 GB/day → 1,350 GB/month

Ingestion cost (unchanged by retention)

(1,350 - 5) * USD 0.57 = USD 766.65/month

This is the baseline reality.

Retention won’t fix it.

Storage with retention (7/30/90)

We compress and store:

• Dev: (5 * 7) ÷ 5 = 7 GB

• Acc: (10 * 30) ÷ 5 = 60 GB

• Prod: (30 * 90) ÷ 5 = 540 GB

Total: 607 GB

(607 - 5) * USD 0.03 = USD 18.06/month

Storage without retention (~1 year)

Total stored:

• 3,285 GB

(3,285 - 5) * USD 0.03 = USD 98.40/month

Savings

USD 98.40 - USD 18.06 = USD 80.34/month

Cost of enforcing it

Assume ~40 log groups/month:

• Config: $0.12

• Rule eval: $0.04

→ $0.16/month

Net

→ ~$80/month saved

Medium Environment

• 225 GB/day → 6,750 GB/month

Storage:

• With retention: $90.90

• Without: $492.60

Savings:

→ ~$401/month

Governance cost:

→ ~$0.80

Net:

→ ~$400/month

Large Environment

• 900 GB/day → 27,000 GB/month

Storage:

• With retention: $364.05

• Without: $1,970.85

Savings:

→ ~$1,606/month

Governance:

→ ~$4/month

Net:

→ ~$1,602/month

What the Numbers Are Actually Saying

Two things become clear:

1. **Retention is still worth it
   **Even though it doesn’t touch ingestion

2. Ingestion is the real problem at scale

Which leads to the natural next step:

The Better Pattern

Split responsibilities:

• CloudWatch → recent, searchable logs

• S3 → long-term storage

This gives you:

• Fast debugging

• Cheap retention

Without paying CloudWatch rates forever.

3) Storage That Doesn’t Leave

Storage is different.

It doesn’t spike.
It doesn’t scale dynamically.
It doesn’t politely disappear when the workload that created it has moved on.

It just stays.

That’s part of why storage waste is so persistent. Compute waste tends to at least look busy. Storage waste just sits there quietly, billing with excellent emotional discipline.

There are two recurring offenders here:

• Unattached EBS volumes

• Snapshots with no lifecycle

They look different on the bill, but the root cause is usually the same: nobody came back to decide what should happen after the original workload stopped mattering.

3a) Unattached EBS Volumes: Paying for “Maybe We Still Need It”

Unattached EBS volumes are one of the simplest forms of waste in AWS.

They usually come from very ordinary events:

• an EC2 instance was terminated, but the volume was retained

• someone detached a volume during troubleshooting

• a migration got halfway through and then became “tomorrow’s problem”

• a test environment was cleaned up, except for the storage, which apparently was granted diplomatic immunity

The volume state in EBS for these is available, which is AWS’s way of saying: “This is attached to nothing, but still very much attached to your bill.”

The pattern

The cleanup pattern here is straightforward:

1. Run a daily Lambda

2. Find volumes in state available

3. Tag newly found volumes with:

   • CleanupCandidate=true

   • FirstSeenAvailable=

   • DeleteAfter=<date+7d>

4. On subsequent runs, if the volume is still available and not exempt, delete it

That 7-day grace period matters. It keeps the automation practical rather than reckless. You want to clean up forgotten storage, not turn someone’s live troubleshooting session into a memorable learning experience.

The underlying EBS pricing model is simple: you pay for provisioned storage until you release it. AWS’s public EBS pricing examples use $0.08/GB-month for gp3 volume storage in a region that charges that rate.

The cost model

For the purposes of calculation, I’ll use:

Monthly unattached volume cost = Provisioned GB * USD 0.08

That gives us a clean, conservative baseline using AWS’s own public gp3 example rate.

Small environment

A small estate might not look dramatic at all:

• Development: 1.0 TB of detached test volumes spread across a few teams

• Acceptance: 0.5 TB left behind from refreshes and release validation

• Production: 0.5 TB of retained-but-unused storage from old hosts or cutovers

That’s 2.0 TB total, or 2,048 GB.

Calculation:

2,048 GB * USD 0.08/GB-month = USD 163.84/month

So even in a fairly small environment, you’re at:

→ $163.84/month

Not catastrophic. Just pointless.

That’s usually the theme with unattached volumes: not one bad decision, but a pile of harmless-looking ones.

Medium environment

Now move to a more typical multi-team setup:

• Development: 4 TB of ad hoc test storage and abandoned instance volumes

• Acceptance: 3 TB from repeated environment refreshes and short-lived testing cycles

• Production: 3 TB from older migrations, retained rollbacks, and “leave it there for now” volumes

That’s 10 TB total, or 10,240 GB.

Calculation:

10,240 GB * USD 0.08/GB-month = USD 819.20/month

So the monthly waste becomes:

→ $819.20/month

This is usually where the conversation changes.

At small scale, unattached storage is an annoyance.
At medium scale, it becomes a recurring bill for infrastructure that is literally helping nobody.

Large environment

At larger scale, unattached storage becomes less of an exception and more of a background condition:

• Development: 20 TB across many teams, ephemeral workloads, and inconsistent clean-up

• Acceptance: 15 TB across multiple shared services and test refreshes

• Production: 15 TB of retained volumes from migrations, replacements, and rollback caution

That’s 50 TB total, or 51,200 GB.

Calculation:

51,200 GB * USD 0.08/GB-month = USD 4,096.00/month

So now the cost is:

→ $4,096/month

At that point, unattached EBS is no longer a housekeeping issue.
It’s a line item.

And the unpleasant thing is that the fix is still not complicated. It’s the same daily scan, just applied consistently.

What this is really saying

The important detail with unattached volumes is that the cost is wonderfully boring.

It doesn’t depend on CPU.
It doesn’t depend on traffic.
It doesn’t depend on whether the application is doing anything useful.

You are simply paying for storage that exists.

That makes it one of the cleanest cost-optimisation targets you’ll find in AWS, because there’s very little ambiguity about whether the spend is justified. If the volume is unattached for a week and no one objected, the answer is probably no.

3b) Snapshots: The Slow Archive Nobody Meant to Build

Snapshots start with good intentions.

They are created for safety.
For rollback.
For recovery.
For “just in case.”

All reasonable things.

The problem is that snapshots are usually very easy to create and much less often given a proper lifecycle afterward. So they accumulate. Quietly. Incrementally. With a sort of patient confidence that deserves respect, if not continued funding.

Two details matter here

First, EBS snapshots in the standard tier are incremental. AWS stores only the blocks that have changed, not a full copy every time. That means snapshot cost should be based on actual billed snapshot data, not the raw size of the source volumes.

Second, if you don’t set lifecycle intentionally, you tend to keep:

• too many daily restore points

• too many monthly “for safety” snapshots

• too much old data in the standard tier

And that is where Data Lifecycle Manager helps.

The pattern: Amazon Data Lifecycle Manager (DLM)

Amazon Data Lifecycle Manager lets you automate the creation, retention, and deletion of EBS snapshots based on tags. AWS documents DLM as a complete backup solution for EC2 instances and EBS volumes at no additional cost.

A practical configuration looks like this:

Tag strategy

Apply tags such as:

• SnapshotPolicy=dev

• SnapshotPolicy=acc

• SnapshotPolicy=prod

This is important because it lets policy follow the resource rather than relying on manual selection, which tends to age poorly.

Retention strategy

Use different schedules by environment:

• Development: daily snapshots, retain 7–14 days

• Acceptance: daily snapshots, retain 30 days

• Production: daily snapshots, retain 90 days, plus monthly snapshots retained longer

DLM supports custom policies for EBS snapshots and can automate retention and deletion.

Archive strategy

For older snapshots that are rarely restored, use EBS Snapshot Archive.

AWS documents:

• Standard snapshot storage: $0.05/GB-month

• Archive storage: $0.0125/GB-month

• Archive retrieval: $0.03/GB

• Minimum archive period: 90 days

So the simplest cost model becomes:

Current monthly snapshot cost = Standard-tier GB * USD 0.05

If you move older snapshots to archive and keep only a smaller working set in standard:

New monthly cost = (Standard-tier GB kept hot * USD 0.05) + (Archived GB * USD 0.0125)

For the examples below, I’ll use a pragmatic split:

• 25% kept in standard tier

• 75% moved to archive

That is not universal, but it is easy to explain and fairly realistic for environments where recent snapshots matter more than old ones.

Small environment

Assume the actual billed snapshot footprint across the three accounts is:

• Development: 0.5 TB

• Acceptance: 1.0 TB

• Production: 2.5 TB

That’s 4 TB total, or 4,096 GB.

Without lifecycle

Everything stays in standard tier:

4,096 GB * USD 0.05 = USD 204.80/month

With DLM + archive

Keep 25% hot:

1,024 GB * USD 0.05 = USD 51.20

Archive 75%:

3,072 GB * USD 0.0125 = USD 38.40

Total:

USD 51.20 + USD 38.40 = USD 89.60/month

Savings:

USD 204.80 - USD 89.60 = USD 115.20/month

So even in a small environment:

→ $115.20/month saved

Again, not dramatic. But also not nothing. And unlike a lot of “optimisation” work, this doesn’t require a philosophical debate about whether the resource is really needed.

Medium environment

Now assume a more typical billed snapshot footprint:

• Development: 2 TB

• Acceptance: 6 TB

• Production: 12 TB

That’s 20 TB total, or 20,480 GB.

Without lifecycle

20,480 GB * USD 0.05 = USD 1,024.00/month

With DLM + archive

Keep 25% in standard:

5,120 GB * USD 0.05 = USD 256.00

Archive 75%:

15,360 GB * USD 0.0125 = USD 192.00

Total:

USD 256.00 + USD 192.00 = USD 448.00/month

Savings:

USD 1,024.00 - USD 448.00 = USD 576.00/month

So the medium environment saves:

→ $576/month

This is where snapshot lifecycle starts to become one of those unusually polite cost controls: low drama, predictable outcome, very little downside if you configure it sensibly.

Large environment

At larger scale, snapshot history becomes a storage system in its own right.

Assume:

• Development: 10 TB

• Acceptance: 30 TB

• Production: 60 TB

That’s 100 TB total, or 102,400 GB.

Without lifecycle

102,400 GB * USD 0.05 = USD 5,120.00/month

With DLM + archive

Keep 25% hot:

25,600 GB * USD 0.05 = USD 1,280.00

Archive 75%:

76,800 GB * USD 0.0125 = USD 960.00

Total:

USD 1,280.00 + USD 960.00 = USD 2,240.00/month

Savings:

USD 5,120.00 - USD 2,240.00 = USD 2,880.00/month

So the large environment saves:

→ $2,880/month

And the key point is that this is not the result of aggressive deletion. It is simply the result of matching storage tier to restore likelihood.

That is usually the whole game in cloud cost work: not removing value, just stopping the most expensive version of value from being the default.

What the storage numbers are really saying

There are two different stories here.

Unattached volumes

This is straightforward waste.
If a volume is detached, untouched, and no one claims it during a grace period, there is very little strategic ambiguity.

Snapshot lifecycle

This is not usually waste in the same way. It is more often good intent with poor follow-through.

The snapshots were created for valid reasons.
They just weren’t moved, expired, or tiered afterward.

That distinction matters. One is clean-up. The other is lifecycle design.

Storage section summary

These are not exotic savings. They are the result of asking two fairly plain questions:

• Should this volume still exist?

• Should this snapshot still live in the expensive tier?

Those questions are not glamorous, but they do tend to produce results.

Final Thought

Nothing here is particularly clever.

There’s no trick.

Just intent.

• Compute learns when it’s not needed

• Logs learn when to expire

• Storage learns when to leave

Defaults don’t do that.

They can’t.

Because defaults are designed for safety, not specificity.

And the longer you rely on them, the more your infrastructure behaves like it’s still day one.

Even when your workload clearly isn’t.

If you want to take this further, the next step isn’t more automation.

It’s making these behaviours your platform defaults so that nobody has to remember them in the first place.

Which, in the end, is the only kind of optimisation that really scales.

It’s the builder’s high - and honestly, it’s one of the best parts of being an engineer.

It Always Starts With an Annoyance

Every small tool I’ve ever built started the same way:

• “Why am I doing this manually again?”

• “This is stupid!”

• “Surely there’s a better way!?”

That’s the spark. Not inspiration. Not a grand vision. Just irritation - and irritation is underrated. If something annoys you repeatedly, it’s probably annoying someone else, too.

Small Tools Matter More Than We Admit

We love to talk about big systems in tech. Architectures. Platforms. Multi‑region deployments. All the impressive stuff.

But the things that actually improve your day? They’re tiny.

A script that cleans up a folder on a schedule. A wrapper that formats logs properly. A shortcut that saves you 10 seconds but feels like magic.

Small tools matter because they reduce friction, create leverage, and compound over time. One improvement leads to another. Your workflow gets smoother. Your brain gets quieter. Your work gets better.

And honestly? They’re fun. There’s something deeply satisfying about building something simple and elegant that just works.

That Moment When It Works

You run the tool. It does exactly what you wanted. And you get that quiet internal “yes”.

It’s not dramatic. It’s not something you’d brag about. But it’s real - that moment where the world becomes slightly more orderly because of something you made.

That’s the builder’s high.

Small Tools Become Ecosystems (Without Trying)

This is the part I love.

You build one tool. Then another. Then a third. Patterns start to form:

• consistent naming

• reusable structures

• shared conventions

• a sense of identity

Suddenly you’re not just building tools - you’re building a toolkit. A personal ecosystem. A set of tiny superpowers that make everything else easier.

Not because you planned it. But because small tools naturally gravitate toward each other.

The Freedom of Building for Yourself

Small tools are the purest form of engineering because you build them for yourself first.

No stakeholders. No deadlines. No Jira tickets. No approval process.

Just curiosity, craftsmanship, and the desire to make your own life easier. It’s engineering without politics. Without ceremony. Without overhead.

Just you and the problem.

And Then, Unexpectedly, They Help Others

Here’s the funny thing: if a tool solves a problem for you, it almost always solves it for someone else, too.

That’s how the best open‑source tools start. Not with a business plan. Not with a roadmap. But with someone scratching their own itch.

Sharing small tools creates a connection. It helps others remove friction. It spreads the builder’s high.

Why I’m Leaning Into Small Tools Right Now

Lately, I’ve been building a lot of small, clean, reusable tools - the kind that make AWS workflows smoother and developer experience better.

Not because I’m chasing a big launch. Not because I’m trying to build a platform. But because these small tools feel good to build. They make my work better. They make me a better engineer.

And over time, they’re forming a consistent ecosystem. And what’s more, I’m enjoying the process. The clarity. The craft. The builder’s high.

Start Small. Start Now.

If you’re feeling stuck or uninspired, don’t wait for a big idea.

Fix an annoyance. Automate a step. Build something tiny that makes your day better.

You’ll be surprised how far those small wins can take you.

And even if nothing big comes from it, you’ll still get that moment - that quiet, satisfying “yes”.

And that’s worth chasing.

And that’s only the work part. Add friends, family, hobbies, health, rest, and the general chaos of being a functioning adult, and suddenly you’re carrying far more than two hands were ever designed for.

Over the last year, I’ve been trying to understand my limits - not in a defeatist way, but in a “what actually matters?” way. I’ve learned that I’m excellent at pushing myself, and equally amazing at exhausting myself. So I needed a way to make sense of everything I was holding.

That’s when the spheres analogy clicked for me. It’s simple, visual, and brutally honest.

The Spheres Analogy

Imagine every part of your life is a sphere you’re trying to hold and balance in your hands. Work. Health. Relationships. Learning. Hobbies. Admin. All of it.

But here’s the critical part:

Not all spheres are made of the same material.

Some are fragile. Some are sturdy - some bounce. And the material matters more than the number of spheres you’re holding.

Let’s break them down. This breakdown is different for everyone, but here are mine:

Glass Spheres - The Irreplaceables

These are the parts of your life that shatter if dropped.

They don’t bounce. They don’t dent. They don’t “wait until next quarter.”

• Your health

• Your closest relationships

• Your mental well‑being

• Your core values

If a glass sphere hits the floor, it doesn’t come back in the same form. These are the things you protect first, even when everything else is on fire.

Ceramic Spheres - The Important, But Survivable

Ceramic spheres matter. They’re meaningful. They’re part of the life you want to build. But if you drop one, it doesn’t explode - it chips. It cracks. It becomes harder to pick up later, but not impossible.

• Career development

• Long‑term goals

• Personal growth

• Learning that enriches your future

Ceramic spheres require care, but they don’t demand perfection.

Rubber Spheres - The Bounce‑Backs

Rubber spheres are the things you love, but that won’t collapse your life if you put them down for a while.

• Hobbies

• Optional learning

• Side projects

• Creative experiments

They bounce. They wait. They return when you’re ready.

The Real Magic: Spheres Within Spheres

Here’s where the analogy becomes genuinely helpful.

Every “big” sphere contains smaller spheres inside it - and those inner spheres can be made of different materials.

Let’s take my “work” sphere, for example. I consider it to be ceramic overall - important, meaningful, but not life‑ending if I need to slow down.

But inside that sphere, I have:

• A glass sphere: my relationship with my client

• A ceramic sphere: learning Dutch to support more clients

• A rubber sphere: exploring Kubernetes because it’s interesting

This matters because the material of the inner sphere determines how I spend my time and energy, not the material of the outer one.

Why this matters

If my client relationship is a glass sphere inside the ceramic work sphere, then:

• I protect that relationship

• I prioritise communication, delivery, and trust

• I don’t let that one drop

But learning Dutch - also inside the work sphere - might be ceramic:

• Important

• Valuable

• But not catastrophic if delayed

So if life gets busy, I can safely extend my Dutch‑learning timeline without guilt, because I’m not dropping a glass sphere - I’m adjusting a ceramic one.

This is the nuance most productivity frameworks miss.

It’s not about “work vs life.”

It’s about what within work (or within life) actually matters.

My Spheres for 2026

A bit of context: I moved to the Netherlands in 2022 and am working toward naturalisation. I love my job, I love my clients, and I’m surrounded by wonderful people (including two cats who believe they are the centre of the universe). I also have… let’s call it an enthusiastic number of hobbies.

So here’s how I’m structuring my spheres for the year.

Glass Spheres - Non‑Negotiables

• Health - sleep, rest, exercise, mental well‑being

• Relationships - partner, friends, family

If these fall, everything else becomes irrelevant.

Ceramic Spheres - Important, But Flexible

• Career - I genuinely enjoy what I do and who I work with

• Naturalisation - learning Dutch, preparing for exams

These spheres matter deeply, but they can be paced.

Rubber Sphere - Joyful Extras

• Hobbies - gaming, pool, Warhammer, model building

They enrich my life, but they’ll bounce back whenever I’m ready.

Zooming In: The Work Sphere Example

Revisiting my ceramic work sphere example, here is how I would personally break it down:

Glass sphere: my client relationship

I genuinely enjoy working with my current client. They’re engaged, collaborative, and the work is fulfilling. This is something I want to protect.

Ceramic sphere: learning Dutch

Learning Dutch helps me support more clients and aligns with my naturalisation goals. It’s important, but there’s no hard deadline. If I need to slow down, that’s okay.

Rubber sphere: Kubernetes certifications

I find Kubernetes fascinating, but I don’t actively use it right now. Preparing for certifications stresses me out, and stress impacts my glass spheres (health and relationships). So Kubernetes goes into the “later” pile.

This structure lets me make decisions without guilt or chaos.

It gives me permission to adjust timelines without feeling like I’m failing.

What This Looks Like in Practice

At work, I’m fortunate to be in an environment that values learning and knowledge‑sharing. That means I can align my ceramic spheres: using my study budget to learn Dutch helps both my personal goal and my ability to support Dutch‑speaking clients.

I’ll also renew my AWS certifications - partly because they’re expiring, partly because they help me stay sharp for the work I already do.

But I’m not adding extra pressure by stacking more ceramic spheres than I can realistically hold. That’s how burnout happens.

This plan gives me clarity. It lets me focus on the AWSome work I’m doing with my current client, pursue personal goals, and stay healthy without overextending myself.

Your Turn

Here’s my challenge to you:

Map out your spheres.

Not just the big ones - the inner ones too.

• What are you holding?

• What are they made of?

• Which ones must stay in your hands?

• Which ones can you safely put down?

• Which ones are only glass because you assumed they were?

You don’t need to juggle everything.

You just need to know what’s glass, what’s ceramic, and what’s rubber - both on the outside and on the inside.

Once you see it clearly, life gets a whole lot lighter, and juggling becomes a whole lot easier.