Other 3rd party products offer more intricate ways of identifying resources beyond tagging, including leveraging Amazon Resource Name (ARN) path-based hierarchies that can achieve a more flexible and less limited structure. While it’s a much more flexible means of building out a cost structure hierarchy, it also requires both a prescriptive or automated approach. Using both approaches is key in launching resources. To ensure paths are set properly, also incorporating a 3rd party tool to aggregate billing and utilization data or to simply extract and present the data (more on this in a bit) is critical.
To learn more about these points, here are a few readings on specific strategies and techniques:
- Tag vs Resource-Based Cost Allocation – Joe Kinsella @ CloudHealth Technologies
- Tagging ARN Path Strategy – Rich Uhl, CEO @ 1Strategy
- AWS Tags : three simple rules for cost management – J.R. Storment @ CloudAbility
- Scenario: Implementing a New Tagging Strategy (AWS Console Help Docs)
Make it easy to do the right thing
Most organizations rely heavily on this billing-level data for accounting and chargeback purposes. In working to ensure that you have a high level of accuracy in the application of tags or a resource-based allocation strategy, you have to both define a standard and then provide the means to apply it properly. When you’re allowing multiple people to launch instances or create resources in AWS, keeping this level of standardization can be tricky. This leads to a decision on whether resources outside of the segmentation model should be summarily deleted or not.
The key to compliance with a cost accounting resource segmentation structure isn’t really the carrot or the stick, it’s all about a comfortable pair of shoes. By this I mean that if you want resources to be deployed in a manner that requires significant attention to detail, you don’t necessarily need to give people positive reinforcement (a party for the team with the best compliance) or negative reinforcement (deletion of untagged resources). You do, however, need to carve out the best path possible for moving forward. Solving this problem lies in building out templates that represent the units of work that your organization needs to deploy—from instances to workloads—within the Infrastructure as Code solution of your choice.
If you’re on AWS, AWS Service Catalog allows you to build custom AWS CloudFormation templates. These templates apply tags or set paths desired based on input parameters that enable the desired setup with the right amount of variability. If you’ve embraced Infrastructure as Code fully, there are other options, including managing deployment through Chef, Puppet or Terraform. These platforms make it possible to further integrate deployment templates with other backend governance or even external cost management tools.
Sign up for Computerworld eNewsletters.