The Tagging Problem Nobody Wants to Own

Here's a scene that plays out at almost every healthcareorganization moving to the cloud, usually around month four or five of themigration.

Finance asks IT why the AWS or Azure bill jumped 18% lastmonth. IT pulls up the cost explorer. It shows a wall of resources: EC2instances, storage buckets, databases, most of them named something likei-0a3f8b2c1d or vm-prod-04. Nobody can say with confidence which applicationany of them belong to, who owns them, or whether they're even still in use. Thehonest answer to Finance's question is: we don't know. We'd have to go findout.

You can't manage what you can't see, and right now, mosthealthcare IT organizations can't see their cloud spend at the level thatmatters: by application, by environment, by team.

Why On-Prem Never Forced the Issue

On-premises infrastructure gave healthcare IT a lot of roomto be sloppy about labeling, and nobody paid for it. There was no monthlyconsumption bill tallying up every server, every disk, every hour of compute.Hardware doesn't provision itself. Someone has to buy a rack, rack it, andcable it, so there was never a surprise. If a server showed up in the datacenter, someone had signed off on the capital expense to put it there, and itwould sit there, known and accounted for, until someone physically pulled it.

That constraint acted as a forcing function foraccountability, even when nobody was labeling anything on purpose. The cloudremoves it entirely. A developer with the right IAM role can spin up a databasecluster at 11 p.m. on a Friday with a few clicks and no purchase order, noprocurement review, no capital committee. It shows up on next month's billwhether or not anyone remembers it exists. Multiply that by every team touchingthe environment, over months and years, and you get exactly the wall ofunlabeled resources Finance is staring at.

This is the part organizations moving to the cloudconsistently underestimate: the discipline that on-prem let slip, the cloud requires.

Most Organizations Aren't Ready for Advanced FinOps, AndThat's Fine

There's a version of FinOps that gets talked aboutconstantly in conference talks and vendor decks: unit economics, sharedinfrastructure cost allocation, showback and chargeback models tied to businessoutcomes. That's real, mature FinOps practice, and eventually it's worthbuilding toward.

But most healthcare organizations aren't there, and tryingto get there first is exactly backwards. You cannot allocate sharedinfrastructure cost across applications you haven't identified. You cannotcalculate unit economics for a service whose resources aren't grouped togetherin the first place. Advanced FinOps is built on top of a foundation, and thatfoundation is simply this: every resource is labeled with what it's for.

Most organizations are still building that habit. That's nota criticism. It's an accurate description of where the industry is, and it'sthe right place to start.

Three Tags Cover Most of What You Need

Start simple and resist the urge to make this complicatedbefore it needs to be.

Application. What is this resource actually part of?Not the team that manages it, not the vendor it came from, the specificapplication or service it serves. This is the tag that turns "we spent$340,000 on cloud last month" into "we spent $22,000 on the patientportal, $41,000 on the data warehouse, and $8,000 on something nobody's claimedyet."

Environment. Production, staging, development, test.This single tag lets you automate cost advisory automation to detect theexpensive mistake of a dev environment running production-grade compute aroundthe clock when it could be a cheaper version, and powered down after hours.

Cost center. In most cases, this should simply followthe application. If you've already tagged the application correctly, costcenter attribution is close to automatic. It's not a separate judgment call forevery resource, just a lookup. This is key for any cost showback or billbackdashboards.

That's it. Three tags, consistently applied, will answer theoverwhelming majority of "where is our money going" questions thatcome up in a typical month. You don't need more than that to start seeing yourenvironment clearly.

Don't Duplicate Your CMDB

The instinct once you start tagging is to tag everything:owner, department, project code, support tier, you name it. Resist it.

If your CMDB already records an application's owner, youdon't need an owner tag in the cloud. You need the application tag, correctlyapplied, so the two systems can be joined. Adding an owner tag anyway meansmaintaining the same fact in two places, and the moment those two placesdisagree, which they will, you've created a data quality problem instead ofsolving one.

The right test for any tag is simple: does this tell yourautomation or your cost systems something they need to know that they can't getanywhere else? If not, it's overhead. Tag for what the systems need, not forwhat feels thorough.

The Part That Actually Makes It Stick

Here's where most tagging initiatives run outof steam:a policy gets written, a kickoff email goes out, and six months later thetagging compliance rate has drifted back down to wherever it started. Policywithout enforcement fails by attrition.

Two things make tagging stick, and neither is optional.

The first is alerting. Set up automated detection that flagsany new resource created without its required tags, the moment it's created,not in a quarterly audit, not in next month's report, but immediately, whilethe context of why it was created is still fresh in someone's head.

The second is ownership. Someone's job needs to explicitlyinclude chasing down those flagged resources. Not "the team should keep aneye on this." A named person, with tag remediation as a stated part ofwhat they're accountable for. The organizations that maintain high taggingcompliance over multiple years, without exception, have both pieces in place.The ones that don't, don't.

If You Don't Tag, You Can't See

Strip away everything else and the logic is unavoidable: ifyou don't tag, you can't see where your cost is going. And if you can't seewhere your cost is going, your cost is going up, not because cloud isexpensive, but because unmanaged is expensive. Idle resources don't get shutdown because nobody can attribute them to a team who'd notice. Oversizedinstances don't get right-sized because nobody can connect them to anapplication owner who'd care. Waste doesn't announce itself. It hides inexactly the ambiguity that unlabeled resources create.

Get that right before you go anywhere near unit economics.The advanced stuff can wait. The visibility can't.

‍