Most people using the cloud are interested in being ‘event driven’, but what does it mean? AWS provide a nice summary here and in my line of work at an AWS MSP event driven to me means discovering that something has happened within AWS accounts we’re responsible for and reacting to it.
A recent example of an event driven requirement was a customer that wanted us to react when they tagged EC2 instances to install some management components, or remove them if the EC2 instance is untagged. Whilst the customer requirement was more elaborate that what I provide here I hope this is a useful overview how event driven architectures can be used in AWS to install software on EC2 instances.
The event driven architecture I’ve created for a proof of concept comprises of EventBridge with filtered rules to capture EC2 tagging events. This rule then invokes a Lambda function which takes the payload from EventBridge and compares it for a specific tag key and value pair (configurable in my sample code). If key and value match the logic for installation then an SSM document is used to install the application, however if the key exists but isn’t the expected value, or if the tag is removed, then an SSM document is invoked to uninstall the application. In my example I’m doing a simple install / uninstall of Apache on Linux, but you get the idea, you could make it as elaborate as you wanted.
I’ve written the code to deploy the architecture in Terraform and shared the repository here, please feel free to make it more elaborate for your use cases. The rest of the article shows how it works….
An EventBridge rule is set-up to capture the EC2 tag change. In my proof of concept I’m using a single account with the default EventBridge, however in a customer environment you’d perhaps use a central EventBridge in a management account to respond to events in all accounts under management: -
The EventBridge rule targets a Lambda function which uses the event payload to determine whether to take any action, and if so whether to install or uninstall the application. The lambda function has IAM permissions for basic execution (for all important troubleshooting via the CloudWatch logs), as well as invoking the SSM documents: -
The Lambda function’s payload is written in Python. My Python skills are fairly basic so no doubts it could be significantly improved, but it does the job for the proof of concept I’ve created. In a customer environment I’d expect his Lambda function perhaps to be hosted centrally within the same management account as the EventBridge rule and capable of cross account assume role to execute the SSM documents, or perhaps even orchestrated via a step function for more elaborate logic. I’d also suggest some additional logic would be required to handle powered off machines (power them on, install and then power back off perhaps), as well as work out what operating system is running on the tagged installed to work out the appropriate SSM document to run (e.g. RHEL, Windows, Ubuntu etc.): -
CloudWatch Logs are configured for the Lambda function and provides some useful information. The EventBridge payload is provided, along with print outs of tag key and value, instance ID and which SSM document is being executed: -
If the logic matches for application installation a simple SSM Document to install and start Apache is invoked: -
…and the logs showing from Systems Manager showing a successful installation: -
Of it the logic matches the requirements for uninstall then there’s an SSM document to stop and uninstall Apache: -
…and the logs showing from Systems Manager showing a successful uninstall: -
Hopefully a useful, easy to follow, guide to EC2 event driven application installations via tags. If you struggle to use the code from the repo I’d recommend Hashicorp’s guide to getting started with Terraform.
