Stop the “just tag it” nonsense. This guide provides three real-world, battle-tested strategies for cloud resource tagging that actually control costs and prevent governance chaos, straight from an engineer in the trenches.

Beyond “Just Tag It”: A Real-World Guide to Cloud Cost Control

I still remember the Monday morning meeting. The Director of Finance was on the call, which was never a good sign. He held up a chart, and the AWS bill for the previous month had a spike so sharp it looked like a cardiogram during a heart attack. Someone, somewhere, had spun up a fleet of GPU-heavy instances for a “quick test” over the weekend and forgotten about them. The cost? North of $30,000. When we dove into Cost Explorer, all we saw was a sea of untagged, ownerless `p3.16xlarge` instances. The finger-pointing started, and the first thing out of management’s mouth was, “Why aren’t we tagging our resources properly?” It’s a great question. But “just tag it” is the most useless piece of advice in the cloud. It’s like telling a messy roommate to “just be cleaner.” It ignores the root of the problem.

So, Why Is This So Hard?

Let’s be honest. Nobody wakes up in the morning excited to meticulously apply metadata to a dozen EC2 instances. The problem isn’t just laziness; it’s a systemic failure. Resources get created in a dozen different ways: a junior dev clicking around in the console, a data scientist running a one-off script, an automated CI/CD pipeline, and a seasoned engineer deploying with Terraform. Without a central strategy and enforcement, chaos is the default state. You end up with a mess of inconsistent keys, typos (`cost-center` vs `CostCenter`), and, worst of all, completely untagged “mystery meat” infrastructure burning a hole in your budget.

Telling everyone to “do better” is not a strategy. You need to build systems that make doing the right thing easy, and doing the wrong thing difficult—or impossible. Here are three strategies we’ve used, ranging from a quick band-aid to a permanent institutional fix.

The Quick & Dirty Fix: The Tagging Sprint

Sometimes you’re bleeding cash and you just need to stop it. This is not the elegant, long-term solution, but it’s brutally effective in the short term. Declare a “Tagging Sprint.” For one or two weeks, all other feature work takes a backseat to identifying and tagging every single untagged resource in your cloud accounts.

Here’s the game plan:

1. Build the “List of Shame”: Use the AWS Cost and Usage Report (or your cloud’s equivalent) and tools like the AWS Tag Editor to find all resources with missing or malformed mandatory tags (e.g., `owner`, `cost-center`, `project`). Export this to a shared spreadsheet.
2. Assign Detectives: Assign teams or individuals to hunt down the owners of these resources. This involves digging through CloudTrail logs, checking commit histories, and yes, sometimes just asking in the company-wide Slack channel, “Who owns `prod-db-temp-restore-01`? It’s costing us $200 a day.”
3. Standardize Your Schema: Before you start tagging, agree on a simple, mandatory schema. Don’t go crazy. Start with the essentials.

Pro Tip: Create a dashboard showing the percentage of untagged resources over time. Make it visible to everyone, including management. Nothing motivates engineers to tag their stuff like a chart with their team’s name next to a big red bar.

This approach is manual and reactive, but it cleans up the existing mess and forces the organization to confront the scale of the problem.

The Permanent Fix: Policy as Code

Tagging sprints are great for cleanup, but they don’t prevent the mess from happening again. For that, you need to take away the ability to create non-compliant resources in the first place. This is where you put on your architect hat and enforce policy through code.

The core principle is simple: make Infrastructure as Code (IaC) the only way. Discourage or outright ban resource creation through the web console for non-admin users. Then, use your cloud’s native policy engine to enforce tagging at the API level.

• In AWS: Use Service Control Policies (SCPs) applied at the Organization Unit (OU) level.
• In Azure: Use Azure Policy.
• In GCP: Use Organization Policy Constraints.

Here’s an example of an AWS SCP that forces any new EC2 instance to have a `cost-center` tag. If the tag isn’t present in the `RunInstances` API call, the call simply fails. No instance gets created.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2CreationWithoutCostCenterTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "aws:RequestTag/cost-center": "true"
        }
      }
    }
  ]
}

Warning: Roll this out carefully! Apply it to a single dev account first. Announce the change weeks in advance. If you drop this on an organization overnight without warning, you will break every deployment pipeline and make a lot of enemies. The goal is to build guardrails, not roadblocks.

Combine this with pre-built Terraform or CloudFormation modules that include mandatory tag variables. This creates a “golden path” for developers, making it easier for them to do the right thing than the wrong thing.

The ‘Nuclear’ Option: The Janitor Monkey

You’ve tried asking nicely. You’ve implemented policies. But some non-compliant resources still slip through the cracks, or you have a massive brownfield environment that’s too big for a manual sprint. It’s time to unleash the janitor.

Inspired by Netflix’s Chaos Monkey, a “Janitor Monkey” is an automated script or Lambda function that actively seeks and destroys non-compliant resources. It is the ultimate, unapologetic enforcer of your policies.

The process is ruthless and effective:

1. Scan: Every few hours, the script scans all resources in an account for policy violations (e.g., missing an `owner` tag).
2. Warn: When it finds a non-compliant resource, like an EC2 instance, it doesn’t kill it immediately. It applies a `termination-warning` tag with a date and sends a notification to a central Slack channel or the resource creator if found.
3. Re-Scan & Terminate: After a grace period (say, 24 or 48 hours), the janitor runs again. If it finds a resource that still has an active `termination-warning` tag from the previous run, it terminates it. No exceptions. No appeals.

This is not a drill: You absolutely must have executive buy-in before deploying a tool like this. The first time the Janitor Monkey deletes a lead developer’s “critical” but untagged test server, you will be summoned to a meeting. You need to be able to stand your ground and point to the policy. This is not a tool for making friends. It is a tool for enforcing standards and saving the company money, period.

It’s an extreme measure, but I’ve seen it transform an organization’s tagging discipline from a joke to iron-clad in less than a month. The fear of automation is a powerful motivator.

Ultimately, getting tagging right isn’t a single action; it’s a cultural shift. You start with the cleanup sprint to show the value, build the paved road with Policy as Code to make it permanent, and keep the Janitor Monkey in your back pocket to ensure compliance. Stop just saying “tag your resources” and start building a system that makes it a non-negotiable part of your engineering culture.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions