Organizations should have a documented tag policy that sets out their tagging structure so developers/teams can tag their services and resources in line with policy. Stax Tag Policy is a way of encoding these tagging rules into the Stax app and receiving regular feedback on where they are being broken.
How is this helpful?
Consider the case of a company that wants its various cost centers to have visibility over relevant costs. To achieve this, the company needs to ensure every taggable resource has a cost-center tag key and a value that matches one of the organization's cost centers.
With Tag Policy, an admin can create a matching policy within Stax to help enforce tagging.
Stax will then report on new resources that don't have a cost-center tag, so the issue can be fixed early – within a day – rather than waiting until the next reconciliation.
Who can use it?
This feature is restricted to Stax admins to set up, but any user can see how they are tracking against the tagging rules.
How do I use it?
A Tag Policy consists of one or more tag constraints. Visit the Cost->Tag Policy section of Stax to enter tag constraints.
Tag constraints can be set to accept any value that is entered for a given tag key or only accept a value from a predefined range of tag values. The decision between these two approaches will come down to the purpose of the tagging and how it relates to your business.
For example, an organization could require every AWS resource to have an 'owner' tag. Managing a predefined range of tag values for 'owners' would be difficult, since there could be thousands of tag values – no one wants to regularly negotiate or maintain such a long list.
In that case, we would recommend the customer use a tag constraint that can match any tag value.
But then another organization could require every resource to have an 'environment' tag. Since this organization will only ever use their 'production', 'nonproduction', and 'quality assurance' environments, a tag constraint that allows a selection between these tag values would be a more logical choice.