Serverless power cycling for AWS EC2, RDS instances, Auto Scaling Groups, and Fargate based on a schedule.
According to AWS RDS User Guide the following are the limitations to stopping and starting RDS instances:
One can't stop a DB instance that has a Read Replica, or that is a Read Replica. One can't stop a DB instance that is in a Multi-AZ deployment. One can't stop a DB instance that uses Microsoft SQL Server Mirroring.
Hammertime will automatically filter out RDS instances with the above conditions.
Edit serverless.yml where you can adjust
- scheduled run time,
- deployment s3 bucket (can be set as
DEPLOY_BUCKET
env var), - AWS region,
- stage between dev/test/production/other (can be set as
SLICE
env var), - anything else which takes your fancy.
stop-hammertime
will stop all EC2 instances that are not in an ASG, it will also set the desired instance count of all ASGs to 0; unless the mentioned assets are tagged with one of the following supported hammertime tags:
hammertime:canttouchthis
: Will prevent hammertime from starting or stopping this asset in all cases.hammertime:canttouchthisbetween
: Will prevent hammertime from starting or stopping the asset between a given time range specified in the value of the tag. The expected format for the value is{datetime} and {datetime}
For example: A value of2017-05-06 and 2017-06-06
prevents hammertime from affecting this asset between the mentioned dates. The datetimes should be a valid ISO-8601 string.hammertime:canttouchthisbefore
: Will prevent hammertime from affecting the asset before a specific datetime represented in the value field of the tag. The datetime should be a valid ISO-8601 string. For example: A value of2017-05-06
will ensure the given asset is not touched before the given date.
start-hammertime
will query the tags left by stop-hammertime
and return the instances and ASGs to their previous status.
Hammertime is intended to be run in response to a Lambda scheduled event, e.g
stop-hammertime
: run Monday-Sunday at 6PM (UTC timezone by default, see here on how to customise this)
start-hammertime
: run Monday-Sunday at 6AM (UTC timezone by default, see here on how to customise this)
You can enable/disable hammertime using the environment variable HAMMERTIME_ENABLED
at the time of deployment. 'true' enables hammertime.
Hammertime has a dry-run feature for when you are not quite ready to unleash the hammer pants on your entire fleet of EC2s just yet.
By setting HAMMERTIME_DRY_RUN
to 'true', you enable dry-run in which hammertime does not touch your EC2s but will still log what it would have touched.
Hammertime can run against assets that require a different uptime schedule due to the timezone that they might operate in. Have teams that work in different timezones on their owns assets, then this festure is for you!
When deploying hammertime, set the environment variable HAMMERTIME_OPERATING_TIMEZONES
, list any amount of valid IANA timezones, deliminated by a ,
that you would like hammertime to support, for example Australia/Sydney,Pacific/Auckland
. A list of these can be found on wikipedia. Hammertime will now deploy with START
and STOP
crons in each of the listed timezones.
Once you have hammertime configured to run with multiple CRONS, tag your assets with hammertime:operatingtimezone
, with a value that is one of the IANA timezone strings, for the example above that would either be Australia/Sydney
or Pacific/Auckland
. For untagged assets, hammertime will use a default operating timezone (UTC by default, see )
By default, hammertime deploys with the default start hour and stop hour set to 6
and 19
respectively to start and stop instances at 6am
and stop at 6pm
.
To change these, set the environment variables HAMMERTIME_START_HOUR
and HAMMERTIME_STOP_HOUR
when deploying to change the hours that hammertime will start/stop assets.
By default, hammertime deploys with the default operating timezone UTC
, this can be overidden by setting the HAMMERTIME_DEFAULT_OPERATING_TIMEZONE
environment variable when deploying. Set this to a valid IANA timezone, for example Australia/Sydney
.
Due to scheduling hammertime using AWS crons, we are unable to dynamically adjust the cron to take into account timezones that shift offsets, for example timezones that implement daylight savings time (DST). To remedy this, re-deploy hammertime when your timezone offset shifts to recreate the crons to have the updated shift in offset.
Refer to the serverless framework for detailed instructions, but should be as simple as
- Install dependencies
npm i
- Transpile the code
npm run build
-
Authenticate with AWS via your favourite CLI
-
then deploy
npm run deploy
- serverless framework
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
We use SemVer for versioning. For the versions available, see the releases on this repository.
- Ian Donaldson - Initial work - Ian Donaldson
- Hailey Martin - Made it work - Hailey Martin
- Kurt Gardiner - Busy work - Kurt Gardiner
- Matthew Turner - Timezone support - Matthew Turner
See also the list of contributors who participated in this project.
This project is licensed under the MIT License - see the LICENSE.md file for details