AWS EC2 Tagging — An Overview

Just this morning I received my weekly AWS announcements email, and as I usually do, took a peek to see if there was anything useful or interesting. There were yet more features on their intimidating laundry list of 109 offerings, some outdated and maintained for legacy reasons like Simple Workflow, and some hot off the press like MariaDB RDS support. It’s easy to get lost in the sea of AWS services and be tricked into thinking there’s a feature that will solve your problem. But one feature, in particular, that should be a staple for organizations in their efforts to organize and manage their infrastructure, is tags, which we will discuss in this post.

Introduction to EC2 Tags

One case where an AWS-managed solution will be insufficient to the specific workflow needs of an organization deals with tagging your AWS resources. For example: How much does your hoopla widget pipeline cost? Which EC2 instances comprise your streaming service, and are they covered under reserved instances? AWS has no way to know what you’re doing under the hood, so it is the responsibility of your organization to come up with a tagging scheme that allows you to answer questions like these.

But wait, what is a tag? A tag is metadata in the form of a key-value pair that you can place onto most AWS resources, most notably EC2, RDS, and S3. Tags can be queried, used for automation, and logically grouped for functions such as billing.

Exploring EC2 Examples

Consider the following. Let’s say your developer won the lottery and quit their job, and now you have the task of terminating all their test instances. If each instance was tagged with the provisioner, you could just hop onto the AWS UI and query by owner.

Here’s another example. If you tag by creation date, you can have a scheduled Cron/Lambda job automatically terminate test instances older than two weeks.

Or consider this. If you tag each test instance with, say, ‘type:test’, you can gather a lot of data, including exactly how much money your test instances are burning each month.

My personal favorite use for tagging is for optimizing reserved instances. There are companies whose business model is dedicated to optimizing reserved instances, but with a few tags, it’s possible to do most of the optimization yourself. AWS themselves have released a feature in the Cost Explorer that allows you to visualize your reserved instance utilization and coverage by tag. You can upgrade services to new instance types and see where your reserved instances fall short. This helps answer precisely what services are not covered under reserved instances or whether you have reserved instances that are not being utilized. The Cost Explorer has also been upgraded such that it can amortize reserved instances and discounts across AWS accounts. This can help any organization, regardless of size, keep their AWS bill in check.

As you can conclude and as we will explore further, the use cases for tags are endless and can be a powerful means of referencing and managing your infrastructure.

Implementing Tags

Regardless of the size of your organization, we recommend using a standardized approach to implementing and leveraging tags. Important use cases would include:

  • Cost allocation
  • Automation
  • Access control
  • Reserved instance allocation

You can use a tremendous amount of flexibility and originality when creating and assigning tags for your specific organization. However, many companies use tags such as the following:

  • Name: A consistent naming schema that identifies the service.
  • Environment: If you don’t have separate AWS accounts for each environment, you can use tagging to enforce environment-specific rules such as access control and backup/retention policy. It is also useful for writing monitoring checks.
  • Service: Even if you decide to give granular names such as Kafka-1a, Kafka-1c, and Kafka-1d, they should all be part of the same service so they can be logically grouped for billing purposes.
  • Role: Role is similar to Service, but a role should be business specific. For example, you may have ‘service:kafka’ and ‘role:message-broker’ or ‘service:kafka’and ‘role:metric-aggregator’.
  • Owner
  • Customer: Useful for customer-specific deployments

Note: We recommend restricting access control to tag edits and enforcing the use of standardized tags. For comprehensive guidelines on tag governance, see

Tags and the Threat Stack Platform

Given the versatility and usefulness of tags, and the feedback we have received from customers, we at Threat Stack recently introduced and incorporated EC2 tag functionality into our platform. Just as AWS provided the ability to manage your infrastructure with tags, our customers can now tag their EC2 instances and assign them to specific rules in the Threat Stack Cloud Security Platform®.

For example, running netcat in your development environment might not be a high priority concern, but you should definitely look twice to see why anyone would run the Swiss Army Knive of vulnerability tools in your production environment. In this case, tags related to your production environment could be assigned to rules that monitor netcat usage. This means that netcat-related rules would apply to your production servers, but not your dev servers.

Another example might include assigning specific tags to your bastion hosts, such as failed SSH login attempts, while leaving out rules related to databases and other unrelated functionality.

Whether your objective is to improve security and meet compliance or to enhance your automation efforts, tags are a powerful and scalable solution that can make your system administrators — and compliance auditors — happy. The result of a good tagging strategy is a better-managed infrastructure.

Interested in learning how to develop a tagging strategy within the Threat Stack platform? In an upcoming post, we’ll explore ways of addressing your security objectives using our AWS tagging feature. In the meantime, sign up for a demo to learn how the platform uses AWS EC2 tags to help you manage the deployment of Threat Stack IDS and FIM rules in your infrastructure.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Pan Chhum. Read the original post at: