Hacker News Reader

Comment by ersii | Hacker News Reader

> * No matter how you do your analysis, tagging will make your life so much easier. Can't emphasize this enough.

Do you have any recommended resources for reading or tips on how and what to tag in what way for making ones AWS Life easier?

View on HN

I'm not the person you responded to, but as far as tagging strategy goes, here's a starting point. https://www.finops.org/blog/finops-tagging-automation-strate...

The entire FinOps foundation is good for cloud finance management - I believe the author of that post has an O'Reilly book coming out this month on the subject also.

Tagging is simple*. The real killer is the things you can't tag, like bandwidth. Be sure to use multiple AWS accounts if you want to split bills (or at least track bills) to sub-groups like per department. Give each of these groups their own account (or set of accounts, preferably, if we're talking a business.. maybe even different accounts for Dev/preprod/prod, if this is a major cost and the project is worth it)

For tags, you can make any tag you want and summarize bills by tags... So anything take can be tagged is trackable.. But things like bandwidth are not.

It's also hard to enforce tagging when you can't automatically destroy non-complaint objects, so again, separate accounts help here.. if the sub-department wants to know their spend better, THEY are more likely to enforce the rule than A top-down policy from a disconnected IT group... And you can't simply apply a gonna "all things must be tagged" enforced in the AWS level because some items can't be tagged, or the tagging has to happen after creation (for instance, by SDK/cli, you can't create an ec2 instance with tags.. you make the instance, then tag it. The GUI does this behind the scenes so it looks like one step)

So again, for major booking boundaries, use different accounts. After that point, it's on the delegated entities to use tags appropriately... And it's often different for each group anyway.

> It's also hard to enforce tagging when you can't automatically destroy non-complaint objects

You can automatically destroy non-compliant (with your tagging policy) objects, by querying objects that exist and examining their tags through the API (heck, you could even script the CLI to do this), and, if you use AWS Organizations, you can prevent noncompliant resources with a combination of service control policies (to require tagging) and tag policies (to specify use of tags).

> (for instance, by SDK/cli, you can't create an ec2 instance with tags.. you make the instance, then tag it.

That's...not true. The runinstances call in the SDK that creates one or more instances from an AMI takes an optional set of tag specifications for tags that can be applied to the instances and/or any of a wide variety of associated resources.

(python) https://boto3.amazonaws.com/v1/documentation/api/latest/refe...

(Java) https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/am...

It's not perfect, but you can tag and track some amount of egress charges now.

> And you can't simply apply a gonna "all things must be tagged" enforced in the AWS level because some items can't be tagged, or the tagging has to happen after creation (for instance, by SDK/cli, you can't create an ec2 instance with tags.. you make the instance, then tag it. The GUI does this behind the scenes so it looks like one step)

The accepted approach is warn then terminate. Give them an hour and then if nothing's done start the slaughter.

Set the standard early, enforce with whatever means necessary. It's a common practice to use tools like CloudCustodian to terminate instances that do not have identified tags (with extreme prejudice). Also, normalize everything, and implement the standards/normalization using your build toolset (Jenkins/Terraform/CI du jour) to enforce this.

Reply on news.ycombinator.com