CLOUDSEC – Retroactively Tag Assets – Lamba Scripts

Some old PoC content that I lost when porting over my old domain to the new one. Now-adays there are many ways to enforce tags across the Cloud providers since I wrote this code… the cloud providers have come up with additional policy frameworks that can be applied at top level objects and recursively tags assets as well. See below…

These newer approaches comes with their owns pros and cons and can have unintended consequences or simply create duplicate meta-data work depending on the architecture.

But this is a PoC this Lambda Node.JS code was made before all the newer features and iterates through new a security groups and passively adds meta-data that may be needed. Ideally the meta-data would be pulled from something like Service-Now and mapped to primary application-id or BU name of some sort…

lambda aws fix_untagged resources

Retroactively fix and remediate untagged aws resources using lambda and send sns notifications to the guilty parties.


Sometimes your compliance, security or finance team may require you to tag assets in the public cloud. This is great for versioning, knowing which region your asset is located, aggregating assets to calculate spend, planning security efforts and proving audit results.

For example, you may want to tag a group of servers with


Region: East-1

Environment: Dev

Version: v.01

Such a simple idea will allow you to aggregate digital assets and calcualte the $ spend on those assets.

You can also take advantage of this capability to create fine grained access controls to restrict who can make changes to the resources. This is great from a security perspective and even better for preventing accidal outages that can affect sales, project time lines or even avoding costs of your employees unecessarily adding resources that cost real $.

Unfortunately scaling this approach can be hard. If you have thousands of employees and tens or hundreds of accounts then it can be difficult to enforce asset management across all of them. Sure you can enforce a Jenkins build pipeline in production but you will undoubtadly be left with some un accounted inventory.

To address this I’ve written a pretty simple Node.JS lambda script that monitors for new security groups and validated whether they are tagged or not tagged. If the code finds untagged or incorrect tags it then adds a “Owner” and “Environment”.

Although the code is written for security groups it can easilly be applied to almost any other aws resources that need tagging. All you need to do is replicate the logic, construct new objects for the aws service and change the api calls to the Describe. Then use the results from that description to find the tags and validate against your own ruleset.

I have also added SNS code snippet to automatically notify the user who created the untagged users. The function is snsNotify(). So any time you find a non compliant resource you can also send a little note to the user in case something broke or they need an exception for some reason.I’ll be periodically adding new code here for other untagged resource as time permits.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s