Update September 2010: AWS has added support for tagging instances, volumes, snapshots, and many other EC2 resource types via the API and the AWS Management Console. The techniques described here are no longer necessary.
So you have a bunch of instances running in Amazon EC2 and you want to be able to tell them apart easily. The way to do this is to “tag” each instance with a descriptive tag, such as “database”, “web server”, “memcached”, etc. The easy, human-friendly way to tag your instances is to use ElasticFox, and the robust, programming-friendly way is to use Security Groups.
Tagging Instances in ElasticFox
The ElasticFox Firefox extension is a great UI for managing your EC2 resources. ElasticFox supports adding tags for instances (as well as tagging EBS volumes, AMIs, and Elastic IPs). These tags are stored in internal Firefox preferences.
Let’s tag an instance in ElasticFox:
1. Here is the ElasticFox extension. Note how it shows that I am running one EC2 instance.
Notice the “Tag” column, which is empty.
2. Right-click on the entry for the instance we want to tag:
Now, add the tag in the dialog that pops up:
And the result:
Tagging instances in ElasticFox is great if you are the only person managing EC2 instances, and if you only use ElasticFox from a single machine. Because the tags are stored in your local browser, they are only visible to you. But, if you need your tags to be visible to other people, or on multiple browsers/computers, tagging in ElasticFox will not help because the tags are not stored in the cloud, only in the local browser. Other browsers / users / computers will not see the tags that you supply using ElasticFox. And, if you need programmatic access (via the EC2 API or command-line tools) to the tags, ElasticFox tags will not help.
Update 15 July 2009: Check out my article about how to copy ElasticFox settings (including tags) between browsers.
Tagging Instances Using Security Groups
Amazon Security Groups can also be used as a tagging mechanism for EC2 instances. The basic idea is to create a custom security group named, for example, “#database” or “#web server”, and launch the instance(s) in that custom security group in addition to the other security groups you want. The custom security group is defined without any permissions so it will have no effect on any instances in the group. This works without affecting the “real” security because the effective security permissions for an instance are the union (the sum) of all the permissions on the security groups the instance belongs to, and the “tag” security group grants zero permissions:
x + 0 = x.
Using security groups to tag instances is slightly more cumbersome because you must create the custom-named security group in a separate step before launching instances in it. However, tagging via security groups is a more robust solution for the following reasons:
- Security groups are stored inside the cloud. When you add an instance to a security group, you do not need to “remember” anything on the client-side: you can change browsers or change computers and your assigned security groups will still be visible every time you look.
- Security groups are visible via the API and the command-line tools. This mean you can write code, in bash/PHP/Java/python/etc., that reads and manipulates the instance “tags” (really security groups). In fact, if you choose a convention for naming your security groups that are really tags, you can programmatically distinguish between the “real” security group (such as “default”) and the “tag” security group. I use the prefix “# ” for naming the security groups that function as tags.
However, all this extra flexibility comes with a price: you cannot add an instance to a security group after it is running; you can only specify an instance’s security groups at launch time. If you use security groups to tag instances, your must specify all your security group tags when you launch your instance(s).
You can use ElasticFox to create tag security groups and to specify the security groups when you launch instances. There is one gotcha: when creating the tag security group, make sure you choose “I will authorize protocols for this group as needed” – this creates the group without adding any permissions.
Instead of walking through that process in ElasticFox, here is an example of using the command-line tools to manage tag security groups.
Managing Tag Security Groups from the Command-Line
To create a security group on the command-line, use the ec2-add-group command:
ec2-add-group "#web server" -d "tag web server"
GROUP #web server tag web server
This creates a security group called
#web server with the description
tag web server.
To launch an instance with this tag, use the
ec2-run-instances ami-12345678 --instance-type m1.small --key gsg-keypair --group default --group "#web server"
RESERVATION r-27e29b4e 614123456789 #web server,default
INSTANCE i-031b376a ami-12345678 pending gsg-keypair 0 m1.small 2009-06-30T11:36:30+0000 us-east-1c aki-a71cf9ce ari-a51cf9cc monitoring-disabled
This launches a single instance of ami-12345678, in any availability zone in the US region (I got us-east-1c), using the gsg-keypair, and having the security groups
#web server. In practice, you will substitute the AMI id you want to use and the name of your keypair. You may also want to add other arguments, so check out the docs or try
ec2-run-instances --help for more command-line options. You can see in the output above that the security groups are
Once the instance starts running, you can use the
ec2-describe-instances command to see all your running instances and the security groups they belong to:
RESERVATION r-27e29b4e 614123456789 #web server,default
INSTANCE i-031b376a ami-12345678 ec2-75-101-177-214.compute-1.amazonaws.com ip-10-250-18-244.ec2.internal running gsg-keypair 0 m1.small 2009-06-30T11:36:30+0000 us-east-1c aki-a71cf9ce ari-a51cf9cc monitoring-disabled
#web server security group in the output. This is the tag security group for this instance.
You can parse the output of the above command using shell utilities (
cut, etc.) if you want to programmatically discover what instances belong to which groups.
Update 24 September 2009: AWS now supports the ability to add a long description to EBS snapshots.
12 replies on “Tagging EC2 Instances Using Security Groups”
This is great for smaller setups, but doesn't work if you have several instances that need to be in the same security group. In our case, we have a number of application servers in the AppServer security group. If we setup security groups like AppServer1, AppServer2, etc. we lose the "group" aspect of security groups.
It would be great if there were a facility to share tags in an XML structure that could be configured to load either from a URL or file path.
No problem: just create the tag security groups #AppServer1 and #AppServer2 without any permissions. Then launch app server 1 in the groups AppServer and #AppServer1, and launch app server 2 in the groups AppServer and #AppServer2. As explained above, the net effect will be the same as the permissions of the AppServer group, since the tag groups grant nothing.
Very useful, thanks.
Extremely useful! This just gave me a great way to correctly account for multiple clusters in StarCluster (http://web.mit.edu/starcluster)
[…] article about Tagging EC2 Instances Using Security Groups shows a brief walkthrough of using ElasticFox to tag instances. Under the hood, ElasticFox stores […]
Good tip, thanks!!
[…] Existing posts about How-are-admins-managing-their-ec2-ebss-and-snapshots and answers like Tagging-ec2-instances-using-security. […]
[…] running on a regular schedule.The central repository can be S3 or SimpleDB, or a database, or security group tags . If you’re concerned about storing your AWS access credentials on each client (and if these […]
[…] a clear instance nomenclature, forcing you to implement a vague approach using security groups. Since there is also a full API surrounding tags, they can be put to work in many useful […]
[…] DENY policy" kind of way: only what traffic you ALLOW will access your instances (1|2|3) so for now you could confine access to them from only your management IP range (but watch […]
As of June 2013, this is still very helpful and the only way to do it in case you create your own load balancer. It is still not possible to tag an instance before it becomes alive (this means that, before it has ‘running’ state). In this case, if you want to count instances, without security group “hack” you will not be able to.
Really great information, I have found it on my own, I was just looking to see if things have improved in anyway and .. nope … they didn’t
Thanks for the heads-up – via the command-line and the API it appears that instance tags cannot be specified at launch time. However, the AWS Management Console provides a way to specify instance tags at launch time.
One possible alternative to using security groups and tags is to use the client-token parameter, which is usually used to ensure idempotency in launch requests. Just be careful with this, as the client-token should be unique, and you’ll need to be creative to create unique yet useful client-token values.