Four tags that every cloud instance should have
For as long as we’ve been a source of cloud cost management strategies and tips, we’ve preached the gospel of tags. They’re a vital tool for enabling cost allocation, chargeback, and in-depth understanding of how the cloud is being leveraged across your company.
Which tags you choose to apply to your instances will vary based on the cost and usage metrics relevant to your business—but there are some tags that provide information beneficial to just about any org. These are four tags that every cloud instance should have:
Knowing how your usage breaks out across dev, test, qa and prod can not only provide insight into how your spending breaks out across your environments (should you really be spending that much on test?), but can be vital for optimizing your spending.
As we learned ourselves when we drilled into our own usage across environments, dev and test instances often go unused outside of business hours and can be safely downsized or turned off during nights and weekends. Make it easy to identify which of your instances fall into this category by tagging them by environment, and you can save significant dough by optimizing your usage accordingly.
The ability to quickly identify what an instance is being used for can go a long way. Should this instance really be running as frequently as it has been? Should we be spending as much as we are to keep this instance running? Is it a crisis if this instance goes down? Identifying how an instance is being used can help you determine its impact on your bottom line, which is key information going into a usage optimization audit.
A little accountability goes a long way. Encourage (or mandate) employees to tag any instance that they spin up with their own name, and efficiency might just magically increase. And if it doesn’t… you can point fingers with confidence.
The “name” tag is set by default when an instance is launched, for good reason. The ability to uniquely identify any given instance allows you to allocate spending all the way down to specific instances, associate bandwidth to a tagged resource, and let you use concatenated tags.
You can tag EBS volumes with instance name or ID to get total compute and storage cost per instance, or roll up the box usage and EBS costs into a single line item by applying that exact same tag to the instances themselves.
Download our free guide to cost allocation using tags and linked accounts to learn more about AWS cost visibility
Ensuring they’re always applied
When we say that these are four tags that every instance should have, we really do mean every instance. Tags are only useful if they’re applied consistently—otherwise, they’ll only provide a partial representation of your spending. While there are some types of resources that are untaggable, everything that can be tagged should be tagged.
As a first step, agree on a common tagging nomenclature to ensure that you’re not just tagging instances, but that everyone’s tagging them according to the same parameters—are there any additional metrics that you’d like to keep tabs on in addition to those listed in this post?
Once you’ve got that settled, instituting a tag-on-deploy policy can be highly effective in driving tagging adherence. Some Cloudability users have even gone so far as introducing a script that will automatically terminate untagged instances after a grace period (also known as a tag-or-terminate policy).
Applying these tags to all of your resources from this point on will be a big win—but don’t forget about the resources you’ve already got up and running. An Untagged Instances Report can help you identify which of your existing cloud resources are lacking on the tag front, so that you can ensure comprehensive cost reporting from here on out.