Date: 2022-10-05
✅ Accepted
As part of the platform's sustainability goals, we want to shut down non production instances outside of working hours to save money and energy.
We want the scheduling to work across multiple accounts, and to be flexible enough to allow user to opt out, or use schedule times by tagging.
We completed a spike and came up with several options on how to achieve this.
We looked at a 3rd party Lambda written in Python and Terraform - https://github.com/diodonfrost/terraform-aws-lambda-scheduler-stop-start
| Pros | Cons |
|---|---|
| It does roughly what we want | Modifications will still be needed for multi account use and to adjust schedules |
| Works with older instances | We have limited Python skills and it's not one of our core languages |
| Security risk of using a third party Lambda |
Use the AWS Instance Scheduler solution.
| Pros | Cons |
|---|---|
| It does what we want | It is in CloudFormation |
| Wouldn't work for older instances without the SSM Agent installed |
In order to use it we would either have to start supporting CloudFormation stacks, or rewrite the CloudFormation stack to Terraform. We started to rewrite the the stack, but soon realised this would be very hard to do, and hard to maintain going forward.
Platform users had already started to use AWS Systems Manager for their local scheduling of EC2s.
| Pros | Cons |
|---|---|
| It does what we want | Wouldn't work for older instances without the SSM Agent installed |
| Doesn't scale well over multiple accounts |
| Pros | Cons |
|---|---|
| It does what we want | New challenges with working with and deploying Lambda |
| Works with older instances | Additional code to maintain |
| Go is a core language | |
| Flexibility to change as needed |
Option 4, we will create a new custom Lambda using Go.
- Need to up-skill team members in Go (already underway)
- Need to figure out strategies for running Lambda locally
- Need to figure out strategies for testing Lambda
- Need to figure out strategies for deploying Lambda