Here’s one obvious scenario. Imagine an operation providing multiple separate applications served through dozens or hundreds of EC2 instances along with the accompanying environment infrastructure.
Just keeping track of your ongoing billing costs can be a headache. Ask yourself these questions: Which AWS resources (instances, volumes, snapshots…) are actually in use and which are currently lying idle or detached? Which Tiers or environments are incurring the highest costs? Should this be changed? Which business unit is exceeding their AWS cost allocations?
Tags can help. Being able to visually or programmatically identify resources by descriptive tags can make it much easier to understand both their purpose and provenance. If you know what a resource is supposed to be doing, then you’re in a much better position to quickly assess and, if necessary, adjust its costs. Tagging is a simple but essential feature that helps us reduce and control costs by improving the way we understand what’s really going on.
Each AWS tag consists of a key and a value, both of which can be defined by the user. Not every AWS service permits customer-defined tags for every service, and some that do can only be tagged only using API Command Line access. The following Screen Shot shows the current tag-status of AWS resources. Resources with tagging restrictions of “None” can be tagged with API actions, the CLI, and the console.
The following diagram illustrates how tagging works:
In this example, I am assigning two tags to each of my EC2 instances, one called Owner and another called Stack. Each of the tags also has an associated value.
Owner = Nitheesh, Stack = Production
You can define AWS tags from the EC2 console by selecting the relevant instance and selecting the “Tags” option. Alternatively, you can select the instance, click “Actions” and select “Add/Edit Tags.”
Currently, AWS Tags have important limitations. For example, a tag associated with a single AWS resource will apply only to that resource and is not automatically propagated to dependent attached resources.
For example, imagine an EC2 instance whose dependent resources include devices like EBS volumes, Security Groups, and Snapshots. A simple RAID configuration could involve as many as eight EBS Volumes and an unmanageable number of snapshots. But none of these dependent devices will automatically inherit their parent’s tags.
Now imagine how this might look if you’re running thousands of EC2 instances. You’ll have to find each EBS volume associated with a particular instance and individually tag it. Managing this is easier said than done, and the slightest typing error can lead to significant cost leakage.
What if there was a tool to automate tagging for dependent AWS resources? It will surely reduce a great deal of manual labor, and help us identify and, if necessary, remove all dependent resources along with a newly redundant EC2 instance. This would avoid leakages and reduce the cost of cloud operations in very dynamic AWS environments.
There is just such a tool. Graffiti Monkey goes around tagging things automatically. By looking at the tags of an EC2 instance, it copies those tags to all attached EBS Volumes and copies those tags to the EBS Snapshots as well. This small automation reduces hours of manual labor on large AWS deployments, helping us efficiently manage our cloud infrastructure and reduce the cost leakages.
graffiti-monkey --region ap-southeast-2 --verbose
This will identify the tags associated with your existing EC2 instance, and apply them to dependent resources like EBS volumes and snapshots, saving hours of manual labor.
It's Flash Sale time! Get 50% off your first year with Cloud Academy: all access to AWS, Azure, and Cloud…
In this blog post, we're going to answer some questions you might have about the new AWS Certified Data Engineer…
This is my 3rd and final post of this series ‘Navigating the Vocabulary of Gen AI’. If you would like…