DEV Community: folarin oyenuga

I built a tool to find every AWS resource you can't tag

folarin oyenuga — Tue, 01 Sep 2026 17:14:46 +0000

AWS doesn't publish a list of untaggable resources. can-i-tag-aws scrapes the IAM docs so you can write SCP tagging policies that don't break prod.

Tagging is the backbone of AWS cost allocation, compliance, and access control. Every well-run organization eventually writes an SCP that says "you cannot create a resource without a CostCenter tag."

And then someone's deployment breaks, because they tried to create a resource that cannot be tagged.

So I built can-i-tag-aws, an open source tool that automatically detects every AWS resource that cannot be tagged.

This isn't a hypothetical problem. I work on a multi-tenant, cloud-native Kubernetes platform that hosts thousands of team workloads in namespaces, and I've watched SCP tag-enforcement policies block legitimate deployments because they targeted resources that cannot physically carry tags. In one incident, enforcement policies had to be disabled org-wide to unblock every team on the platform while the root cause was found. In another stretch, four separate SCP enforcement failures surfaced in quick succession, one of them during a full deployment halt. Every time, the failure had the same shape: the policy assumed every resource could be tagged.

The problem nobody talks about

Not all AWS resources support tagging. That's not controversial. What's surprising is that AWS does not publish a single, consolidated list of what can't be tagged.

The information exists, but it's scattered across 400+ pages of the IAM Service Authorization Reference, one page per service. To build an SCP tagging policy that actually works, you need three kinds of exclusions:

Service-level: entire services with no tagging API at all
Resource-level: specific resource types inside otherwise-taggable services
Instance-level: AWS-managed default instances of taggable types (like default.redis7 ElastiCache parameter groups, which reject tags because AWS owns them, not your account) Without all three, your policy either blocks legitimate API calls or leaves compliance holes. And the list changes as AWS ships new services.

What AWS gives you (and where it falls short)

AWS has pieces of the puzzle, but none of them answer "what can't I tag?" proactively:

Resource Groups Tagging API: only sees resources that already exist in your account. It can't tell you about a service before you deploy it.
AWS Config rules: reactive. They flag non-compliant resources after creation, and they still assume the resource is taggable.
Per-service documentation: accurate but scattered. Nobody is going to read 400+ pages by hand, and the answers go stale as AWS updates services.
Cost Allocation Reports: silently omit untaggable resources, which makes FinOps teams chase attribution gaps that can never be closed.
The gap: there is no proactive, consolidated, machine-readable answer to "which AWS resources cannot be tagged?" That's what this tool fills.

What can-i-tag-aws does

It parses the IAM Service Authorization Reference and classifies every resource type across all AWS services. A resource is considered taggable if it has the aws:ResourceTag/${TagKey} condition key or is in scope of a tagging action (TagResource, CreateTags, AddTags). Anything with neither is untaggable.

The output is a single JSON file with:

Every untaggable resource, grouped by service, with the reason
Conditionally taggable types (taggable in general, but AWS-managed default instances reject tags), with

the exact ARN patterns to exclude from SCPs
Mixed-support services broken down per resource type

{
"summary": {
"total_services": 475,
"services_without_tagging_api": 124,
"total_untaggable_resources": 511,
"conditionally_taggable_resource_types": 7
}
}

(Numbers from the latest weekly run at the time of writing. The whole point is that they drift, so run it rather than trusting a blog post.)

No AWS credentials needed. It works offline against the docs. If you want account-specific confirmation, an optional --live flag validates findings against your account via boto3.

Fastest way to try it:

docker run --rm -v $(pwd)/output:/app/output ghcr.io/olu-folarin/can-i-tag-aws

The design decision that matters most

Instance-level detection, spotting AWS-managed defaults like default.redis7 that reject tags despite their type being taggable, can't be looked up anywhere, because AWS doesn't publish a registry of managed default instances. So the tool infers them by naming convention.
Inference means occasional false positives, which forced an explicit choice about which way to fail. The tool errs toward inclusion, and the reasoning is asymmetric:
An unnecessary exclusion in your SCP is harmless. You've exempted a resource that would have passed anyway. A missing exclusion blocks a real deployment at create time, in production, for a team that has no idea why.
One failure mode costs nothing, the other pages someone. So the bias goes toward the harmless one. If you take nothing else from this post: when your detection is heuristic, decide deliberately which direction it fails, and write that decision down (you might just be saving yourself the stress of trying to figure out what informed the operating design decision months/years down the line).

Keeping it true over time

A point-in-time list of untaggable resources starts rotting the day you generate it, so the repo maintains itself:

A weekly scheduled run re-scrapes the reference and regenerates the dataset
A pre-flight canary checks the docs' structure first and fails loudly if AWS has restructured the pages, so the run aborts rather than parsing garbage
A post-scrape invariant gate sanity-checks the results (counts within plausible bounds) before anything is committed
Graduated auto-merge: small drifts merge automatically, anything changing more than 25% of the dataset is held for human review, because a swing that large is more likely a parsing problem than AWS reinventing itself overnight
A dead-man's-switch opens a GitHub issue (deduplicated) when a run fails, so a silent breakage can't quietly become a stale dataset The tool also keeps timestamped history with a diff command, so you can see exactly when AWS added or dropped tagging support for anything, and update your policies on evidence rather than on rumour.

Who it's for (and uses beyond the README)

The obvious audience: platform engineers writing SCP tagging policies, and security teams auditing tag enforcement. But the output is just structured data, so it plugs into more workflows:

FinOps: identify which resources will never appear in cost allocation reports, so you stop investigating attribution gaps that are structurally impossible to close.
Policy-as-code (OPA, Conftest, Checkov): skip mandatory-tag checks on resource types that can never pass them, cutting false positives from CI.
Landing zone rollouts: run it as a pre-flight check before enabling tag-enforcement SCPs on new OUs or acquired accounts.
CMDB and asset inventory: don't design workflows that depend on tags for resources that can't carry them.
Drift monitoring: track when AWS adds or drops tagging support, and update policies accordingly.

Honest limitations

It scrapes HTML docs, so if AWS restructures the IAM reference, parsing can break. The canary catches this and opens an issue rather than publishing bad data. It's a point-in-time snapshot, which is why the weekly re-run matters. And instance-level detection is convention-based, with the fail-safe bias described above.

Wrapping up

If you've ever had a tagging SCP break a deployment, or a FinOps report with unexplainable gaps, this is the reference list you previously had to build by hand. It's MIT licensed, runs in Docker with zero credentials, and the output is plain JSON you can feed into whatever governance pipeline you already have.

Repo: can-i-tag-aws
Docker Image: can-i-tag-aws
Issues and PRs welcome, especially reports of AWS-managed resources that reject tags despite their type showing as taggable.

[Boost]

folarin oyenuga — Mon, 01 Jun 2026 08:06:10 +0000

folarin oyenuga

Feb 1

How Systematic EBS Optimization Delivered Significant Annual Savings

#aws #finops #devops #kubernetes

4 min read

How Systematic EBS Optimization Delivered Significant Annual Savings

folarin oyenuga — Sun, 01 Feb 2026 23:10:57 +0000

## Definitions & Scope

Orphaned volume (in this context): An EBS volume that is unattached, not referenced by any PersistentVolume/PersistentVolumeClaim, not part of backup/DR workflows, not snapshot-dependent for active AMI pipelines, and confirmed deletable by volume owners.

Scope: Production EKS cluster spanning multiple AWS regions, supporting 1000+ namespaces.

The Problem

In cloud environments, EBS volumes accumulate silently. Engineers spin up instances for testing, experiments are abandoned, services are decommissioned—and volumes are left behind. Still attached to your AWS bill.

While investigating resources lacking mandatory tags for a compliance initiative, I found over a thousand unattached EBS volumes consuming 60 TB of storage. The original goal was to add tags to untagged resources. But I saw an opportunity: many of these volumes appeared genuinely orphaned. If I could safely identify and remove them, the cost savings would be significant.

The naive approach "delete all unattached volumes" often causes incidents. Volumes might be referenced by automation, support disaster recovery, or be temporarily detached during deployments. I'd seen rushed cleanup campaigns end in emergency snapshot restores, lost engineering hours and damaged engineering trust.

I needed a systematic way to determine which volumes could be safely deleted, when, and how.

The Solution: 7-Step Verification Methodology

Every volume passed through 7 independent checks before deletion.

Step 1: Volume Age & IOPS Analysis (Triage)

Check: How old is the volume? What's the IOPS configuration?

Volume age correlates with orphan likelihood. Volumes untouched for 6+ months are strong candidates. But age alone isn't enough. IOPS analysis surfaces cost outliers that deserve priority attention.

During triage, I discovered a 750GB io1 volume provisioned at 15,000 IOPS. Annual cost: quite significant for a single volume. It's easy to simply focus on storage (GB) and nothing more. The real cost driver for io1/io2 volumes is provisioned IOPS.

Lesson: IOPS analysis should not be excluded from your verification, especially for io1/io2 volumes.

Step 2: Attachment State Verification

Check: Is this volume currently attached to any EC2 instance?

aws ec2 describe-volumes --filters Name=status,Values=available

Status available means unattached. But unattached ≠ deletable. I move to further verification.

Step 3: Kubernetes PV/PVC Cross-Reference

Check: Is this volume referenced by any PersistentVolume or PersistentVolumeClaim?

kubectl get pv -o json | jq '.items[] | select(.spec.awsElasticBlockStore.volumeID)'

A volume might be unattached at the EC2 level but still referenced by Kubernetes. Deleting it would break the next pod that tries to mount it.

Step 4: CloudTrail Activity Analysis

Check: When was this volume last accessed? By whom?

CloudTrail reveals the last AttachVolume, DetachVolume, or CreateSnapshot events. Volumes with no activity for 6+ months are strong deletion candidates. Recent activity means someone's still using it, even if it's currently detached.

Step 5: Snapshot & AMI Pipeline Check

Check: Is this volume part of an active snapshot workflow or AMI build process?

Snapshots and AMIs indicate the volume is referenced by automation, launch templates, or image build pipelines. Even if the volume itself isn't directly backing an AMI (snapshots do that), its existence in an active workflow means deletion could break restore processes or future builds.

Step 6: Tag & Naming Convention Analysis

Check: Do tags or naming patterns indicate purpose?

Tags like kubernetes.io/created-for/pvc/name or naming patterns like prometheus-data-* reveal original purpose. Cross-reference with current cluster state to determine if that workload still exists.

Step 7: Senior Team Validation for High-Value Volumes

Check: For volumes >1TB or with significant cost impact, get senior team sign-off.

After successfully deleting 725 volumes across earlier phases (small and medium-value batches), I had 4 remaining high-value volumes including the expensive io1 volume from Step 1.

I scheduled a live review session with senior engineers. I walked through my 7-step verification for each volume. They applied their own independent verification methods. Both approaches confirmed: all 4 volumes were safe to delete.

All 4 were deleted during the call. Zero incidents.

Phased Execution

I didn't delete 729 volumes on day one. Phased approach:

Phase 1: 10 oldest, smallest volumes. 48-hour monitoring. Zero issues.

Phase 2: Incremental batches (15 → 20 → 30 → 50 volumes), 24-48 hour monitoring windows between each.

Phase 3: 281 medium-value Prometheus volumes from decommissioned workloads.

Phase 4: 4 high-value volumes with senior team validation.

This was done under change control with documented approvals and audit-friendly evidence.

Total timeline: 5 weeks | Success rate: 100% (729/729) | Production incidents: 0

Results

Metric	Value
Volumes investigated	1000+
Volumes deleted	732 (729 by me, 3 via methodology adoption)
Storage reclaimed	60 TB
Annual savings	Significant
Production incidents	0

The team appreciated the systematic approach. A colleague subsequently adopted the methodology on another cluster, identifying 3 additional high-value volumes, demonstrating that reusable frameworks multiply impact beyond direct execution.

Key Takeaways

Systematic beats aggressive. I could have deleted everything in a day. The 5-week phased approach with monitoring windows meant zero incidents and built enough trust that the methodology was adopted elsewhere.

IOPS costs dominate io1/io2 volumes. It's important to reiterate that it's often easier to focus on storage (GB). Whereas a single io1 volume can cost more annually than twenty gp3 volumes combined.

Dual verification builds trust. For high-impact deletions, having senior engineers independently confirm your methodology eliminates doubt, enables organizational adoption and also provides an opportunity to see things through fresh perspectives.

Look for adjacent opportunities. The original task was tagging compliance. The cost savings emerged from noticing that many untagged volumes were also unused. Sometimes the bigger win is next to the assigned work.

Automate what you've validated. Once you trust the methodology, bake it into your processes. Manual verification doesn't scale; time is invaluable.

Resources

aws-ebs-optimization-methodology - Reusable 7-step framework

Have you tackled similar cloud cost challenges? What worked for you?