How to Stop, Start, Reboot or Recover an EC2 Instance with a CloudWatch Alarm

By Ravindra Bagale, trainer · LinkedIn · Last updated: 21 October 2026

1. A story: the forgotten test server

A developer in Pune starts a c5.2xlarge to test a Java build on Friday. He forgets it. On Monday the bill shows 60+ hours of a large server doing nothing.

A second story: a payroll server runs every night from 1 AM to 3 AM, then sits idle. The team wants it off in the day and on again at 1 AM.

Both problems are solved with alarms and schedules. No human needs to remember anything.

2. The four EC2 alarm actions

Why do we need this?

An email still needs a person to log in and click. For simple, safe fixes we want the alarm to act at once, even at 3 AM.

What is it?

An EC2 alarm action is a button the alarm can press on one instance. It works on alarms that watch a per-instance metric (one with the InstanceId dimension).

3. Lab 1: stop an idle instance automatically

Rule: if average CPU stays below 5% for 1 hour, stop the instance.

Why these values: a real idle Linux server sits at 0-2% CPU. 5% leaves room for small background jobs. 1 hour (12 periods of 5 minutes) avoids stopping a server during a short coffee break.

1. Open EC2 → Instances, select the test instance and copy its Instance ID.
2. Open the Monitoring tab. Click the ⋮ on the CPU graph or the + next to Alarm status. (Or go to CloudWatch → Alarms → Create alarm.)
3. Metric: EC2 → Per-Instance Metrics → CPUUtilization for your instance.
4. Statistic Average, period 5 minutes.
5. Condition: Lower than 5.
6. Datapoints to alarm: 12 out of 12. Why: all 12 boxes of the hour must be quiet.
7. Missing data: Treat missing data as ignore. Why: after the stop no CPU arrives; "ignore" keeps the last state and does not flip back and forth.
8. Next. In EC2 action click Add EC2 action. Alarm state trigger: In alarm. Action: Stop this instance.
9. Also add a notification to the ops-alerts SNS topic, so a person knows why the server went down.
10. Name: dev1-idle-stop. Create alarm.
11. Verify (fast test): for the lab, edit the alarm to 1 out of 1 and threshold 50. Leave the server idle. In 5-10 minutes the alarm fires and the instance state shows Stopping → Stopped.

The same alarm with the CLI (region ap-south-1). The action is an ARN:

aws cloudwatch put-metric-alarm --alarm-name dev1-idle-stop \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc1234567890def \
  --statistic Average --period 300 --threshold 5 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 12 --datapoints-to-alarm 12 \
  --treat-missing-data ignore \
  --alarm-actions arn:aws:automate:ap-south-1:ec2:stop
# other actions: arn:aws:automate:ap-south-1:ec2:terminate
#                arn:aws:automate:ap-south-1:ec2:reboot
#                arn:aws:automate:ap-south-1:ec2:recover

4. Can an alarm start a stopped instance?

Why do we need this?

Our payroll server must come back on at 1 AM. People look for a "Start this instance" alarm action. It is not there.

What is it?

The plain answer: CloudWatch alarm EC2 actions are only stop, terminate, reboot and recover. There is no start action. The reason is simple: a stopped instance sends no metrics, so an alarm on its own metrics has nothing to watch.

5. Lab 2: start an instance every day with EventBridge Scheduler

1. Open Amazon EventBridge → Scheduler → Schedules → Create schedule.
2. Name: payroll-start-1am.
3. Schedule pattern: Recurring schedule → Cron-based. Cron: 0 1 * * ? *.
4. Time zone: Asia/Calcutta. Why: otherwise it runs in UTC, 5.5 hours off.
5. Flexible time window: Off. Next.
6. Target: All APIs → search EC2 → StartInstances.
7. Input: {"InstanceIds": ["i-0abc1234567890def"]}. Next.
8. Permissions: Create new role for this schedule. Why: Scheduler needs permission to call ec2:StartInstances.
9. Next → Create schedule.
10. Make a second schedule payroll-stop-4am with cron 0 4 * * ? * and target EC2 StopInstances.
11. Verify quickly: create a one-time schedule 3 minutes from now. At that minute the instance state goes Pending → Running.

CLI version (the role must trust scheduler.amazonaws.com and allow ec2:StartInstances):

aws scheduler create-schedule --name payroll-start-1am \
  --schedule-expression "cron(0 1 * * ? *)" \
  --schedule-expression-timezone "Asia/Calcutta" \
  --flexible-time-window Mode=OFF \
  --target '{"Arn":"arn:aws:scheduler:::aws-sdk:ec2:startInstances",
             "RoleArn":"arn:aws:iam::111122223333:role/SchedulerEc2StartStop",
             "Input":"{\"InstanceIds\":[\"i-0abc1234567890def\"]}"}' 

6. Lab 3: start a standby server from an alarm with Lambda

Story: the main web server fails its health check. You keep a stopped standby server. When the alarm on the main server fires, start the standby. (In real production an Auto Scaling group does this better; this lab teaches the pattern.)

1. Open IAM → Roles → Create role. Trusted entity: AWS service → Lambda.
2. Attach AWSLambdaBasicExecutionRole. Name: lambda-start-standby. Create.
3. Open the role → Add permissions → Create inline policy → JSON:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "ec2:StartInstances",
    "Resource": "arn:aws:ec2:ap-south-1:111122223333:instance/i-0standby000000001"
  }]
}

4. Name the policy start-standby-only. Why only one instance: the function can never start anything else.
5. Open Lambda → Create function. Name start-standby, runtime Python 3.12, existing role lambda-start-standby.
6. Paste this code and click Deploy:

import boto3, json
ec2 = boto3.client("ec2")
STANDBY = "i-0standby000000001"

def lambda_handler(event, context):
    # works for a direct alarm action and for SNS
    print(json.dumps(event)[:2000])
    r = ec2.start_instances(InstanceIds=[STANDBY])
    state = r["StartingInstances"][0]["CurrentState"]["Name"]
    print("standby state:", state)
    return state

7. Give CloudWatch permission to call the function (CLI):

aws lambda add-permission --function-name start-standby \
  --statement-id cw-alarm --action lambda:InvokeFunction \
  --principal lambda.alarms.cloudwatch.amazonaws.com \
  --source-arn arn:aws:cloudwatch:ap-south-1:111122223333:alarm:main-web-down

8. Create the alarm main-web-down on the main server: metric StatusCheckFailed, statistic Maximum, period 1 minute, threshold >= 1, 2 out of 2.
9. In actions choose Lambda action → In alarm → function start-standby.
10. Other route: send the alarm to an SNS topic and subscribe the Lambda function to that topic. Use it when many things must react to one alarm.
11. Test: aws cloudwatch set-alarm-state --alarm-name main-web-down --state-value ALARM --state-reason test.
12. Verify: Lambda → Monitor → View CloudWatch logs shows standby state: pending, and the standby instance becomes Running.

7. Cleanup

1. Delete alarms dev1-idle-stop and main-web-down.
2. Delete the schedules payroll-start-1am, payroll-stop-4am and the test one-time schedule.
3. Delete the Lambda function and the role lambda-start-standby and the scheduler role.
4. Stop or terminate both test instances.

8. Which action for which stack?

9. Interview questions

Revision, comparison and interview cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

More cards: Ravi Sir's Cards.