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"
Output:
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 command:
ec2-run-instances ami-12345678 --instance-type m1.small --key gsg-keypair --group default --group "#web server"
Output:
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 default and #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 default and #web server.
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:
ec2-describe-instances
Output:
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
Note the #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 (awk, perl, 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.