When a new client asks me to check out their AWS estate and make recommendations for improvement, one of the most common is that tags should be implemented. It’s something that most of us don’t give enough thought to when we’re busy deploying exciting new projects in our cloud environments, but here’s why you should.
So much stuff!
When you deploy some cloud resources in particular, you get more than you perhaps bargained for. When deploying a new RDS instance, we’ll obviously get the instance itself, but we also get;
- a security group
- a network interface
- a subnet group
- a parameter group
- an options group
- and so many snapshots!
And that’s all brilliant. They’re AWS constructs that help to organise, connect, and secure everything to do with your shiny new database, all done by magic, and we pressed like 4 buttons.
That’s great when it’s your first database, but what about when it’s the fifth? How about when you need to remove just one database of the many you now have? For which client? Which project? And maybe worst of all – is it production or not? Tags help you with this problem, and so many more!
Control – let’s get some
You might have a development team who need access to all of the resources which aren’t live in production yet. They’re always rolling back databases, changing interconnectivity between pieces of infrastructure, and bringing new services online. AWS is an amazing place for these kinds of people to be working in, but that comes at the risk of those same people accidentally bringing down production. But what if we could stop that?
Let’s say you tagged everything when it was deployed, so you know about all the production resources, and everything else that’s needed to run the live environment. Let’s now say all that is visible to your developers, so they can easily see what they’re working towards, or building upon, safe in the knowledge that no mistake they make could delete that precious customer data, or harm your unblemished uptime stats. All this is totally achievable because you laid the foundations right at the start.
Tags + policy = good times
IAM policies are really cool. Pretty much anything you can see or touch in AWS can be controlled by policy, and that means we can control the above developer’s access to things tagged as production – awesome! We can also do things like making sure that anyone who does have access to production also has multi-factor authentication enabled for their AWS account. But all of this starts with knowing your assets, and tagging.
