AWS Tagging Best Practices (opens in new tab)

One really useful tool: setup a tag policy in your account / organization and make sure that all of your project teams have the ability to view it so finding non-compliant resources can be self-service without having a human in the loop:

https://docs.aws.amazon.com/organizations/latest/userguide/o...

One thing that I wish I'd known when I first started to use Cost Allocation Tags in AWS as described in the article -- they won't apply to any resources created before the tag was created & activated. Well, you can apply them but they won't return data to your cost reports. For some resources this is not a big deal -- any individual EC2 instance I can respawn pretty easily, or I'm not doing my job right. But there's lots of things in the accounts I administrate that would be far less trivial to re-create, due as much to organizational issues as technical ones. Being able to apply CATs to old resources and start getting cost data back would be a huge improvement for my day-to-day work.

I emphatically agree that tagging should be automated. Terraform, CloudFormation, Pulumi, whatever - make it part of the code. It's way too easy for someone to miss a tag or misspell a tag if it's being done manually.

A couple months ago I released automation in our cloud environment to shutdown/startup resources who have been tagged with cron expressionS. It has been an incredibly flexible solution to manage and reduce the cost of resources which charge per time spent operating.

Not only do tags fit well into already existing work flows (CI/CD, policy), cron expressions give freedom to devs/sysadmins to choose whichever schedule they need. Also, this solution allows a central IT team to easily query and calculate duty cycle of any tagged resource, and relate that calculation to money saved.

I suggest using cron expression tagging for any scheduled resource automation, as it will likely be more flexible and more easily monitored than anything natively offered by the cloud vendor.

One of our teams set up a remediation service that does realtime tag analysis by following the Cloudtrail API logs. Anyone at the company who knows about the remediation service can simply log in, filter by aws resource type, and find a note indicating either a better configuration, or why the resource just got nuked from a high orbit.

We don't have any issues tracking stuff down - if you create something that can't be traced back your department, it explodes. I've never seen anything more effective at directing a user configuration.

Following through on a threat is essentially magic.

This doesn't cover other interesting uses, like tag-based automation. Random examples: Tagging DynamoDB tables to identify which should be backed up and at which frequency (when you don't quite trust the built-in backup); tagging dev RDS databases with a shut-down schedule for nights/week-ends; tagging Elastic IPs and Auto Scaling Groups with a "IP pool ID", and a Lambda that re-assigns EIPs to ASG instances as they are recycled; using a "data flow ID" tag on resources that are in the hot-path of data flows that are subject to high-volume bursts, so you can easily list them and scale them up before known events.

one very useful tool for tagging and tag governance, is https://github.com/cloud-custodian/cloud-custodian you can setup policies to auto tag things with creators, and enforce tag policies, enforce valid vocabularies, and work through remediation and notification workflows. There's even a standalone tool to do retro-active tagging on resource creators via cloud trail querying (c7n_trailcreator).

disclaimer: maintainer on cloud custodian

I can echo what this article recommends for business tags. When we migrated to IaC (terraform) we tagged nearly all of our resources and set up quite a few budgets and budget overrun alerts.

It gives great insight into infrastructure costs, makes budgeting a lot easier, and saved us a decent chunk of change by letting us know where savings would have the most impact or alerting us when we had unintended cost increases.