Are dead projects and under-utilized servers lingering in your AWS environment? These resources are costing you money and leave open vulnerabilities or attack vectors that can create nightmare scenarios for your company. Cleaning them up saves not only time and money, it also closes the window on ransomware attacks and data exfiltration. "Argh!!" that is a monster project. Fortunately, public cloud has evolved an answer…
Tags are simply a key-value pair. In other words, a custom attribute you can create. Amazon Web Services allows you to create up to 50 custom user tags for each resource in your AWS environment.
Above is an example of a unique custom tag that creates a friendly name for your resource - in this case, probably an EC2 instance. But tags can be useful attributes that help you identify groups of resources. For example:
Once created, these tags can then be used to apply policies or actions to every resource that matches that key-value pair(s). For example, upon completion of the marketing team's "rebrand" project we can create an action to STOP all resources tagged for the project as above by using a condition that matches the tags we defined for those resources.
Hold on - we will get to an example of how to do that soon.
Before we do so, let's look at why tagging is critical and why everyone should be doing it.
Table of Contents:
1. Why tagging is important.
2. Tagging best practices.
3. Example light weight tagging strategy.
4. Automate using tags to schedule resources.
Part 1: Why tagging?
"Gosh Nick, this seems like a lot of extra work."
This is one-time work initially and can be automated for new resources. (Automatic AWS EC2 tagging example). But believe me, I feel your pain.
The benefits may not be entirely obvious at first glance. There are several core use cases.
AWS Cost Allocation: both AWS Cost Explorer and Cost and Usage Report support tags for breaking down AWS costs to better understand your AWS bill.
AWS automation activities: AWS pricing is based heavily on utilization. Tags can be used to opt in or opt out of automated tasks such as start/stop scripts for turning off non-essential resources during off hours. (This can save as much a 70% off your AWS costs alone.)
Backup and system patching: Use tags to support these processes and ensure resources are not left out of the patch cycle, creating a security nightmare.
AWS Identity and Access Management: AWS IAM polices support the use of tags to limit user and role permissions based on specific tags and their values.
Security and Compliance: use tags to identify resources requiring specific compliance-based activities and then created automated checks to ensure that the controls are in place and working.
The Well Managed Cloud: tags are also at the core of additional tools such as Cloud Custodian or Tenacity Cloud's CTRL platform that create a much more robust and customizable framework for driving automated compliance, security, cost optimization, and governance at scale.
Part 2: Tagging Best Practice
First: DON'T TAG IN A VACUUM!
Employ a cross functional team, preferably your Cloud Center of Excellence (CCoE).
Tags are cAsE sEnSiTiVe. This applies to both Keys and Values.
Or bring your own, the point is to be consistent.
Avoid Multi-value Tags
For AWS cost management and charge-backs, consider using a combination of Linked Accounts and Cost Allocation tags. This can simplify overly complex cost allocation tags and avoid trying to create multi-value tags that require post-processing support. Example of what NOT to do:
Trust me. This becomes a mess to manage. You don't like messes. Neither do I. Don't do it.
Less is More
Start only with what you need. Don't design an aircraft carrier when what you need right now is a row boat. Start rowing sooner.
AWS console can be overwhelming even for administrators. It can be frustrating to actually locate and see all of your AWS resources in one place or understand the full scope of your environment. Tagging makes this much easier.
Once tagging is implemented, you can use Resource Groups to create and view groups of resources based on the tags you have created.
Leveraging a tool like Tenacity's Cloud CTRL platform will further eliminate the frustration and can make the initial tagging activity and ongoing tagging compliance audits easy.
Use Automation to Proactively Tag Resources
Do this early. (Automatic AWS EC2 tagging example)
That should get your started on AWS Tagging Best Practices. For an in depth look, go here.
Part 3: Example AWS Tagging Implementation
For our example we will imagine a software company that offers both a SaaS product and a retail product suite with downloadable modules. Their first tagging strategy might look like this:
They will also leverage a Key: "name" tag to create a friendly name for each of the resources in their environment.
With the tagging strategy outlined, they will log into the AWS console and begin deploying the first tags.
Then it's time to set up their monthly cost allocation report through AWS Billing and Cost Management.
Part 4: Automate using tags to schedule resources AND reduce AWS costs
Now that our AWS tagging strategy is implemented, it's finally time for some automation. Here is an easy example to tackle right away.
AWS Resource Scheduling
There are several ways to tackle this problem. For our purposes we are going to use an AWS Lambda function triggered by an AWS CloudWatch event. Let's set up our test environment first:
Launch AWS console and log in. Navigate to EC2 and Launch 4 new free tier instances. Navigate to EC2 -> Instances and add some sample tags as outlined in the table above.
Give two of your test instances the schedule:office-hours tag
Now the test environment is ready.
First we create an IAM policy using the JSON policy editor.
Paste this JSON policy into the policy editor:
Now it's time to create a Lambda function to stop and start our instances. In this example we will limit ourselves to a specific region.
Test Your Lambda Functions
Create an AWS CloudWatch Event
Now it's time to put it all together and trigger the lambda function with an Event.
Be sure to select the Lambda Function for stopping your instances.
You are now all set. You can adjust your rules or create new test rules with different cron expressions to test your events immediately.
There are several other options for implementing scheduled instances, with additional capability and increasing complexity, including the AWS Instance Scheduler solution, event driven API calls, and Cloud Custodian. We will cover off on those in a future post.
More importantly, there is near limitless potential to automate within your AWS environment to both save you money and remove the headache of maintenance; the lack of which leads to inevitable waste, cost, downtime, confusion, and worst of all, vulnerability.
There are solutions to making complex policy sets insanely easy, check out Tenacity Cloud's CTRL platform and join our beta program.