Running an AWS Lambda Function in Multiple Accounts Simultaneously

Recently I have found myself setting up a very large enterprise with a secure AWS development environment. As part of setting up the multiple accounts, I found a cool trick I wanted to share for deploying code across your multi-account environment.

Recently, AWS released Cloudformation Stacksets. This tools allows you to deploy cloudformation templates in multiple accounts simultaneously. You can find out more about it here

I began using stacksets for everything, enabling AWS Config, deploying my tagging lambda function, all kinds of stuff. One thing frustrated me though, what if I just wanted to run a lambda function once in all my accounts? It's easy enough to deploy a lambda function to run on a schedule or when triggered by an event, but surprisingly tricky if you want to run it just once.

This is where another AWS feature comes in, Cloudformation custom resources, which you can read about here.

By combining these two features and using some sample code I've pulled together from different sources across the net, you can now run a lambda function in hundreds of accounts with a single command!

Now you may be asking, why not just use a cross account role? To be clear, that's exactly how stacksets works. I like the extra tracability and governance stacksets provides. I always suggest my clients use federated identities, and combining federated identities and Cloudtrail with stacksets creates a nice audit trail and a way of rolling things back or modifying things much more easily than doing it the "old fashioned" way.

So, to get into it, first you will need to write your lambda function. For an example of a simple script that tags all the VPN connection in an account, check out this python file.

Note that that file has one modification, a call to lambda_handler("", "") at the end of the file. That lets you test the code locally before uploading to lambda. Just remove that call and it becomes a normal lambda function.

Next, you will need to insert your function into a piece of code that handles the custom resource status reporting. Just replace the TagVPNs function in my sample below with your own code. Note that the way I implemented the code will technically run twice, once when the custom resource is created and again when you delete it. If you really want to make sure it only runs once, add an IF statement on the event field to check for CREATE. Make sure to zip the file up when you are done editing it. Here is the python file.

Next, you need to create a cloudformation template to call your function. I've made a very thin template file you can find here.

Now you have everything you need. Make sure to open up the template and make sure the role that lambda will run as works for your use case. You can find this role defined in the template

I would suggest having an S3 bucket containing all your CF templates and lambda zip files readable only by the accounts in your AWS Organization. Upload the template and zip file, and make sure to remember the URL for the template.

Next, go into your master account, and open up cloudformation stacksets. Select create stackset, specify an S3 template URL, and enter the URL from above. Give your stack a name, and enter the modulename, which is the source code file minus the file extension. Next enter the bucket name you uploaded your code to, and the name of the zip file.

This next screen allows you to select the accounts to deploy to. We use AWS Organization so I can just enter the org names here, but I prefer to use the account numbers. Select your regions, and set the concurrency. I'm only dealing with about 20 accounts right now but as it gets larger I'll definitely use the CSV, and potentially will move to using the org names in the future.

Give your stack some tags, I always tag with a couple billing tags just in case the rest of my governance regimen misses a resource. Review, and deploy!

When I did the VPN tagging (we use a transit VPC which was set up before our billing tag standards) I just went ahead and did a delete after all the stacks finished deploying. I've also played with this a bit, so I felt comfortable setting the concurrency equal to the number of accounts so it just ran in all of them simultaneously.

Hope you enjoy this little trick! Next I plan to write about multi account strategies for large enterprise's implementing a multi cloud strategy.

-Eric