One of the key features of AWS is that any business owner will only be charged for the hours that the application/web server has been online and active. Lets say you have an internal application that is used by the staff only during business hours (9am – 5pm Monday to Friday). If there is no usage outside business hours, why pay for the application hosting during weekends?
Previously, in traditional infrastructure approach, whether you like it or not, the application will be hosted on physical servers and available 24 x 7 to the staff once installed. But AWS has completely turned this concept on its head. Now you only pay for the period you use the infrastructure/service for your application. Not a single cent more.
In such situations, the AWS infrastructure for your organisation will be configured such that the EC2 instances hosting the application (web, app and DB server) are stopped at a pre-defined time (say 5pm on a Friday) and started again at pre-defined time (say 9am the next business day which is Monday).
This is where Lambda function comes in to play. Lambda function uses IAM policy and IAM role to create the triggers on target EC2 instances. You then use the Cloudwatch to call the lambda function based on cron schedule.
To create and setup Lambda function and Cloudwatch, please refer to below step by step guide.
Once the Lambda functions are setup, you can test it out. You will need one lambda function for stopping the EC2 instances and you will need another lambda function to start the EC2 instances.
In this example, I have two EC2 instances setup in a VPC (refer to AWS Hybrid Cloud Testing – Part 1 – 2 Tier application on EC2 instance and RDS on how to create EC2 instances in a custom vpc).
- WebServer-1 – mapped to http://learntheartofsoftwaretesting.com
- WebServer-2 – mapped to http://mobile.learntheartofosoftwaretesting.com
As you can see, the EC2 instances are running.
The Lambda functions are as below:
- EC2StopStartLambdaScheduler – this stops all target EC2 instances (you can name the lambda functions whatever you want)
- EC2StartLambdaScheduler – this starts all target EC2 instances (you can name the lambda functions whatever you want)
You can test the lambda functions before configuring CloudWatch rules for events (that call lambda function).
Here is the test outcome for calling lambda function to stop EC2 instances.
All EC2 instances are stopped.
Here is the outcome for calling lambda function to start EC2 instances.
All EC2 instances started again.
Now that you have tested the lambda functions, you can configure the Cloudwatch rules to trigger lambda functions based on a schedule. This schedule is configured as a cron job. In this example, I have configured the cron job to run at 10am GMT time. Since I am based in Sydney Australia, I am 11 hours ahead of GMT. So when the cron job kicks in to stop the running EC2 instances at 10am GMT, it is actually 9am in Sydney.
Here is the proof that the cron stopped the EC2 instances at exactly 10am GMT.
The cron job will stop the EC2 instances every Sunday at 10am GMT. I could have easily configured this to be 5pm Sydney time on Friday (6am GMT on Friday).
Similarly, another cron job will start the EC2 instances at 10am GMT every Sunday. I could have easily configured this to be 9am Sydney time on Monday (10pm GMT on Sunday).
So as a Test Analyst, what can you test for this specific scenario? Consider the following test cases:
- Verify that the cron job kicks off at the correct time; use the Cloudwatch log insights to verify the lambda invocation at the correct time as below
- In the event that there is daylight savings, configure the cron jobs to match the change in difference with GMT time
- If you are scheduling stop/start of web server, app server and DB server EC2 instances, ensure that after starting, the application still continues to work
- Ensure that after stop/start of EC2 instance, the urls still work and there has been no change to the public IP addresses (here I assume Elastic IP Address)
- Verify that the cron jobs still executes even when IAM user with read only access is logged into the AWS console (lambda function and Cloudwatch rules have been setup by IAM user admin access)