Build an AWS FIS CPU Incident Lab

Simulate an EC2 CPU incident with CloudWatch alerts and AWS FIS guardrails.

Introduction

30 Second Summary

Operational alerts can look reassuring until a real failure tests them. A dashboard that stays green cannot prove that anyone gets warned when pressure rises.

In this project, you will run a controlled CPU incident against a disposable Amazon EC2 instance with AWS Fault Injection Service (AWS FIS). An Amazon CloudWatch guardrail detects the spike before stopping the experiment automatically.

What You'll Build

You will watch a healthy CPU graph spike trigger an email alert before your guardrail halts the experiment.

By the end of this project, you'll have:

A healthy CPU baseline you can compare with the incident spike on the same graph.
A proactive incident alert that sends a real email through Amazon Simple Notification Service (Amazon SNS) when CPU crosses 50 percent.
Controlled containment that shows AWS FIS reach Stopped with Experiment halted by stop condition.
Secret Mission: Add an EC2 reboot action so the alarm automatically remediates the disposable instance after containment.

Are there any prerequisites?

You need an AWS account with permission to create the lab resources in this project. You also need access to an email inbox for alert confirmation.

Before We Start

This checkpoint commits you to a disposable game-day environment before any fault injection begins. You will simulate controlled CPU stress on one disposable EC2 instance with a 50 percent CPUUtilization CloudWatch guardrail that stops the experiment at an observable threshold.

Launch a Managed Test Instance

A controlled CPU incident needs a target that is safe to discard. Later, AWS Fault Injection Service (AWS FIS) will stress one Amazon EC2 instance.

AWS Systems Manager Fleet Manager provides browser-based management without inbound administration ports. Detailed Amazon CloudWatch monitoring gives the later CPU experiment metric data in 1-minute periods.

In this step, get ready to:

Create the instance role that grants Systems Manager access.
Launch one disposable instance with the required security settings.
Verify that the instance passes its status checks and appears online in Fleet Manager.

Create the Systems Manager role

An AWS Identity and Access Management (IAM) role lets an AWS service use specific permissions. The managed policy in this role gives the instance access to Systems Manager.

Use the AWS Management Console search bar to go to IAM.
Select Roles in the left navigation.
Choose Create role.

You'll see the role wizard ask which trusted entity needs permission to use the role.

Select AWS service as the trusted entity type.
Select EC2 as the use case.

The trust configuration now identifies EC2 as the service that can assume this role.

Continue to the permissions policy list.
Select AmazonSSMManagedInstanceCore.

The selected policy supplies the permissions required for the instance to register with Systems Manager.

Continue to the role details page.
Enter SSMInstanceProfile as the role name.

The role details now identify the access layer that you will attach to the disposable instance.

Choose Create role.

Good progress. The SSMInstanceProfile role now exists for your lab target.

Confirm that the role's Permissions tab lists AmazonSSMManagedInstanceCore.

Why Does the Instance Profile Matter?

Creating an EC2 role through the IAM console also creates an instance profile with the same name. EC2 attaches that profile to the instance.

The profile delivers the role permissions to the operating system without placing long-lived credentials on the server.

Launch the disposable instance

The launch wizard defines the operating system and compute size for one instance. A security group controls which network traffic can reach that target.

Know the Lab Costs

Launching the instance starts billable usage. You can keep the full project under its estimated $1 total by deleting the resources when you finish.

A Linux/Unix t3.micro costs $0.0104 per hour in US East (Northern Virginia). Regional pricing and Free Tier eligibility vary.

T3 instances start in Unlimited mode by default. Sustained CPU can create CPU-credit charges.

Detailed monitoring has separate CloudWatch pricing. Available CloudWatch Free Tier allowances can cover eligible usage.

Use the AWS Management Console search bar to go to Amazon EC2.
Choose Launch instance from the EC2 dashboard.

You'll see the launch wizard with sections for the image, instance type, network, storage, and advanced settings.

Enter fis-cpu-lab in the Name field.
Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2.

The wizard now identifies the disposable lab instance and its supported operating system.

Under Instance type, select t3.micro.
Under Key pair (login), select Proceed without a key pair (Not recommended).

The instance now uses the required compute size. Systems Manager provides the management path, so this lab does not need an SSH key pair.

Expand Network settings.
Select Create security group.

Why Use No Inbound Rules?

Inbound rules create paths from the network to the instance. This lab does not host an application or use SSH.

Systems Manager manages the instance through its agent and IAM permissions. An empty inbound rule list keeps the target isolated.

Clear every option that adds inbound traffic.
Confirm that the inbound security group rules area contains no rules.

The new security group now exposes no inbound administration port or application port.

Expand Advanced details.
Set IAM instance profile to SSMInstanceProfile.

The wizard now shows the instance profile that carries Systems Manager permissions.

Set the instance metadata option to IMDSv2 only (token required).
Set Detailed CloudWatch monitoring to Enable.

Metadata requests now require a token. Detailed monitoring is enabled for 1-minute metric periods.

Choose Launch instance in the summary panel.

You'll see a success confirmation with the new instance ID. The disposable incident target now exists.

Launch Blocked?

Review the launch wizard for a section marked as incomplete.
Confirm that SSMInstanceProfile is selected under IAM instance profile.
Confirm that the security group has no inbound rules.

Ask for help with my EC2 launch configuration.

Verify the managed node

EC2 status checks and Systems Manager registration can take several minutes. That wait is normal while AWS starts the instance and registers its management agent.

Choose View all instances from the launch confirmation.
Select fis-cpu-lab on the Instances page.

The instance begins in a pending state while EC2 prepares its operating system.

Wait until the instance state shows running.
Wait until the EC2 status checks show that they passed.

EC2 now confirms that the instance is running and has passed its platform checks.

Before you verify Systems Manager, do you expect a node with no inbound rules to appear online?

Use the AWS Management Console search bar to go to Systems Manager.
Select Fleet Manager in the left navigation.

You'll see the managed nodes that Systems Manager can reach in this AWS account and Region.

Find fis-cpu-lab in the managed nodes list.

You'll see fis-cpu-lab online as a managed node. That online state proves Systems Manager can manage it without an inbound administration rule.

That's the foundation in place. Your disposable target is running under browser-based management with no exposed administration port.

Instance Missing from Fleet Manager?

Confirm that EC2 shows the instance state as running.
Confirm that the EC2 status checks have passed.
Confirm that SSMInstanceProfile has AmazonSSMManagedInstanceCore attached.

Help me find why fis-cpu-lab is missing from Fleet Manager.

Your managed test instance is ready. Next, you'll capture its healthy CPU baseline before adding any proactive alerting.

Establish the Healthy Baseline

Your managed Amazon EC2 instance has passed its status checks. It is also online in Fleet Manager.

A steady-state baseline captures normal CPU behavior before the planned incident. Amazon CloudWatch already receives CPUUtilization data from detailed monitoring at 1-minute granularity.

In this step, get ready to:

Inspect CPUUtilization at 1-minute granularity.
Record a below-50-percent CPU sample with its timestamp.
Test what happens while nobody watches the graph.

Inspect one-minute CPU behavior

The CPUUtilization metric shows how much CPU capacity the instance uses over time. The one-minute view makes short changes easier to compare against normal behavior.

Use the search bar in the AWS Management Console to find Amazon EC2.
Select Amazon EC2 from the search results.
Select fis-cpu-lab from the instance list.
Select the Monitoring tab.
Find the CPUUtilization graph.
Use the graph period control to select 1 Minute.

You will see the recent CPU history for fis-cpu-lab as one-minute data points.

Graph Empty or CPU Too High?

Confirm that fis-cpu-lab remains selected.
Refresh the Monitoring tab to request the latest data.
Wait for another data point if the graph is still populating or the latest value is 50 percent or higher.

Help me diagnose a missing or unexpectedly high CPUUtilization baseline.

Record a healthy reference point

A useful baseline pairs the CPU percentage with the moment it was measured. The timestamp lets you locate the same healthy point when you compare it with the later incident.

Choose the latest completed data point below 50 percent.
Record its CPU percentage here: your baseline CPU percentage.
Record its timestamp here: your baseline timestamp.

You have captured the healthy reference point for your experiment. The later CPU spike now has a concrete before value.

Test the limits of observation

Before you step away from the graph, predict what AWS will do if CPU behavior changes while nobody is watching.

Leave the Monitoring tab unwatched until the next one-minute data point becomes available.
Return to the Monitoring tab from earlier.
Check the latest CPUUtilization point.
Check your email inbox for a CPU notification.
Return to the Amazon EC2 instance list.
Confirm that fis-cpu-lab remains running.

The latest CPU value should remain below 50 percent. No CPU notification arrives.

The instance remains running with no automatic response. This intended shortfall proves that the metric still depends on an operator returning to the console.

Your timestamped healthy baseline is locked in as the control point for the incident. Next, you will turn the passive graph into a threshold that can notify you.

Add the Alerting Guardrail

Your healthy baseline proves that fis-cpu-lab normally stays below the planned 50 percent threshold. The metric still depends on someone watching the graph.

An Amazon CloudWatch metric alarm turns that threshold into an active guardrail. Amazon Simple Notification Service (Amazon SNS) carries the alarm notification to a confirmed email inbox.

In this step, get ready to:

Create a confirmed Amazon SNS email channel.
Publish a test message to prove that the channel works.
Connect a 50 percent CPU alarm to the alert channel.

Create and test the alert channel

A Standard SNS topic acts as the delivery hub for an alert. Its email subscription determines which inbox receives each published notification.

Return to Amazon SNS in the AWS Management Console from earlier.
Choose Create Topic.
Select Standard.
Enter ops-incident-alerts as the topic name.
Choose Create Topic.

Good progress. Your ops-incident-alerts topic now exists as the delivery hub for the guardrail.

Create a subscription for ops-incident-alerts.
Select Email as the protocol.
Enter an email inbox you can access as the subscription endpoint.
Create the subscription.

The confirmation email can take a moment to arrive. A short delay is normal.

Check the email inbox you entered.
Open the subscription confirmation message.
Use the confirmation link to confirm the subscription.

Why does confirmation matter?

An email subscription accepts notifications after the recipient confirms it. This protects inboxes from unwanted subscriptions.

Before you publish the test, do you expect the confirmed subscription to deliver the message to your inbox?

Return to the ops-incident-alerts topic in the AWS Management Console.
Choose Publish to topic.
Enter fis-cpu-guardrail test as the subject.
Enter This message confirms ops-incident-alerts can reach the operator inbox. as the message.
Choose Publish Message.
Return to your email inbox.
Open the test message from Amazon SNS.

That delivery path works. You will see the fis-cpu-guardrail test message in your inbox.

Didn't receive the test email?

Return to the subscription in Amazon SNS to verify that confirmation completed.
Check your spam folder for the confirmation message or test message.
Help me diagnose why my confirmed Amazon SNS email subscription did not receive a published test message.
Share a redacted screenshot with the NextWork community if the message still does not arrive.

Create the CPU guardrail

The alarm converts the observed CPU metric into a state change. Its notification action publishes that change through the channel you just tested.

Switch back to Amazon EC2 in the AWS Management Console.
Select the fis-cpu-lab instance.
Choose Actions.
Choose Monitor and troubleshoot.
Choose Manage CloudWatch alarms.

The alarm flow is now scoped to the CPU metric for fis-cpu-lab.

Enter fis-cpu-guardrail as the alarm name.
Set Group samples by to Maximum.
Set Type to CPU utilization.
Set Percent to 50.
Require one consecutive period.
Set Period to 1 Minute.
Set the ALARM notification topic to ops-incident-alerts.
Create the alarm.

The main protection is now assembled. The alarm links the instance metric to the tested notification channel.

How does the guardrail work?

The Maximum statistic evaluates the highest CPUUtilization sample in each period.
The 50 percent threshold moves the alarm into ALARM after one consecutive period breaches it.
The ALARM notification publishes to ops-incident-alerts.

Verify the active guardrail

CloudWatch needs a fresh metric period before the alarm settles into its current state. A brief delay is normal.

Before you check the alarm, which state should match the healthy baseline you recorded?

Switch back to Amazon CloudWatch in the AWS Management Console.
Choose Alarms.
Choose All Alarms.
Open fis-cpu-guardrail.
Wait for the current state evaluation to complete.

You did it. fis-cpu-guardrail now shows OK because the current CPU level remains below the guardrail threshold.

Alarm not reaching OK?

Compare the current CPUUtilization value with the 50 percent threshold.
Confirm that the alarm uses the metric from fis-cpu-lab.
Help me diagnose why my CloudWatch CPU alarm is not reaching the OK state.
Share a redacted screenshot with the NextWork community if the alarm still does not settle.

Your guardrail can now detect a CPU breach without manual observation. Next, you will build the controlled fault injection experiment that tests it.

Build the Fault Injection Experiment

Your CloudWatch guardrail now covers detection. This step turns the planned CPU incident into a repeatable experiment.

Ad hoc load commands are hard to repeat. They are easy to leave running.

AWS Fault Injection Service (AWS FIS) packages the stress action into a named experiment. A stop condition connects that experiment to your existing alarm.

In this step, get ready to:

Create a service role that AWS FIS can assume.
Configure a repeatable CPU stress action for the managed test instance.
Protect the experiment with the existing CPU alarm.

Create the AWS FIS service role

An IAM service role lets AWS FIS send the stress action through AWS Systems Manager. Its trust policy controls which service can assume the role.

Granting a fault-injection service permissions can feel risky. This policy limits trust to AWS FIS experiments from your account.

Choose the account menu in the AWS console header.
Record the displayed account ID here: your 12-digit AWS account ID.
Choose the Region selector in the AWS console header.
Record the code beside your current Region here: your AWS region code.
Press the Windows key to open Windows search.
Type Notepad and press Enter.
Paste this trust policy into the blank Notepad document:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "fis.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "your-account-id"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:fis:your-region:your-account-id:experiment/*"
        }
      }
    }
  ]
}

What Does This Policy Allow?

The fis.amazonaws.com principal identifies AWS FIS as the trusted service.
The sts:AssumeRole action lets that service use the role.
The aws:SourceAccount condition restricts trust to your AWS account.
The aws:SourceArn condition restricts trust to AWS FIS experiments in your Region.

Press Ctrl+Shift+S to open the save dialog.
Select Desktop as the save location.
Enter fis-role-trust-policy.json as the file name.
Choose All files as the file type.
Choose Save.
Check the Notepad title bar.

You should see fis-role-trust-policy.json in the title bar. Your reusable source policy still contains the two placeholder values.

File Name Ends in .txt?

Open the save dialog again. Choose All files before saving the file as fis-role-trust-policy.json.

Ask for help if Windows keeps adding another extension: Why does Notepad keep saving my JSON file with a .txt extension?

✔️ Awesome, I've got everything!

Great. Keep fis-role-trust-policy.json open because you will copy it into IAM next.

ⓧ I'd like to double check the full code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "fis.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "your-account-id"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:fis:your-region:your-account-id:experiment/*"
        }
      }
    }
  ]
}

What Should Match?

Compare every key with your saved file. Keep your-account-id in both locations inside the source file.

Keep your-region in the source file. You will replace these placeholders only in the IAM editor.

Return to the AWS Management Console.
Enter IAM in the console search bar.
Select IAM from the search results.
Choose Roles in the navigation pane.
Choose Create role.
Choose the Custom trust policy role type.

The custom policy editor is now ready for a copy of your source file. The saved file remains unchanged for future reference.

Copy the complete JSON from fis-role-trust-policy.json in Notepad.
Paste the JSON into the Custom trust policy editor.
Replace both occurrences of your-account-id with your 12-digit AWS account ID.
Replace your-region with your AWS region code.

Why Restrict the Source?

The source account condition ties the role to your account. The source ARN condition narrows that trust to AWS FIS experiments.

These conditions reduce the chance that another AWS resource can use the role unexpectedly.

Choose Next.
Search for AWSFaultInjectionSimulatorSSMAccess under Permissions policies.
Select the checkbox beside AWSFaultInjectionSimulatorSSMAccess.
Choose Next.
Enter FISSSMExperimentRole in the Role name field.
Choose Create role.

Open the Permissions tab on the new role page.
Confirm that AWSFaultInjectionSimulatorSSMAccess appears under attached policies.
Open the Trust relationships tab.
Confirm that the policy contains the AWS FIS principal plus your account and Region restrictions.

That is the sensitive permissions work complete. AWS FIS now has a dedicated role for sending the controlled stress action.

Can't Create the Role?

Check that every placeholder was replaced in the IAM editor. Confirm that the trust policy still contains matching quotation marks and braces.

Ask for help with the policy structure: Why is IAM rejecting my AWS FIS trust policy?

Configure the CPU stress action

An AWS FIS action defines the fault that the experiment applies. This action uses a preconfigured Systems Manager document to drive CPU load for 120 seconds.

Why AWS FIS Instead of a Manual Command?

A manual stress command depends on someone remembering the exact command and stopping it safely. That makes repeated incident drills inconsistent.

AWS FIS stores the action in an experiment template. The template preserves the target and guardrail for the next run.

Enter AWS Fault Injection Service in the AWS console search bar.
Select AWS Fault Injection Service from the search results.
Choose Experiment templates in the navigation pane.
Choose Create experiment template.
Enter Test CPU stress predefined SSM document under Description and name.
Choose Next.
Choose Add action.
Enter runCpuStress as the action name.

The action editor now needs the exact stress document and its runtime settings.

Choose aws:ssm:send-command/AWSFIS-Run-CPU-Stress as the Action type.
Keep the target that AWS FIS creates for the action.
Enter {"DurationSeconds":"120"} under Document parameters.
Enter PT5M under Duration.
Choose Save.

You should see runCpuStress in the Actions section. Its action type should show the preconfigured CPU stress document.

Action Won't Save?

Check that the document parameters contain double quotes around both the key and value. Confirm that the duration is exactly PT5M.

Ask for help with the action settings: Why won't my AWS FIS CPU stress action save?

Target the instance and add the stop condition

The target limits the experiment to your disposable Amazon EC2 instance. The stop condition connects the experiment to the active CPU guardrail.

Choose Edit for the automatically created target.
Confirm that Resource type shows aws:ec2:instance.
Choose Resource IDs as the target method.
Select the instance named fis-cpu-lab.
Choose All as the selection mode.
Choose Save.
Choose Next to move to service access.
Choose Use an existing IAM role.

The experiment now points to one disposable instance. The service role and alarm complete its safety boundary.

Select FISSSMExperimentRole as the service access role.
Choose Next to move to optional settings.
Select fis-cpu-guardrail under Stop conditions.
Choose Next to reach the review page.

Before you inspect the review page, which action, target, and guardrail do you expect the template to contain?

Review the Actions section.
Review the Targets section.
Review the Stop conditions section.
Choose Create experiment template.
Enter create in the confirmation field.
Choose Create experiment template.

You now have a repeatable CPU incident with a defined target and a CloudWatch stop condition. The experiment remains idle until you deliberately start it.

Before your final check, do you expect the template to include any target besides fis-cpu-lab?

Inspect the template's action details to identify the configured action type.
Inspect the template's target details to identify every selected instance.
Inspect the template's stop conditions to identify the connected alarm.

You should see only fis-cpu-lab as the target. You should also see aws:ssm:send-command/AWSFIS-Run-CPU-Stress as the action type and fis-cpu-guardrail as the stop condition.

Template Details Don't Match?

Edit the template before running it. Confirm that the target contains only the instance named fis-cpu-lab.

Ask for help comparing the template settings: Which AWS FIS experiment template setting is incorrect?

Your controlled incident is fully defined. Next up, you will start the experiment and watch the alerting guardrail stop it.

Run and Investigate the Incident

Your experiment template now links a disposable Amazon EC2 target to an Amazon CloudWatch stop condition. The monitoring design still needs proof under a real metric breach.

AWS Fault Injection Service (AWS FIS) now runs the controlled fault injection against your test instance. This produces the evidence needed to validate the guardrail.

Amazon Simple Notification Service (Amazon SNS) provides the operator notification. The CloudWatch guardrail provides automatic containment.

In this step, get ready to:

Start the controlled AWS FIS experiment.
Trace the incident across every service.
Confirm that the target returns to a healthy state.

Start the controlled experiment

An experiment run turns your template into a live test. Its existing controls keep the blast radius focused on the disposable instance.

Paid Run Starts Here

Starting this experiment begins paid AWS FIS action time. A full 120-second run costs up to $0.20.

EC2 usage can add charges. CloudWatch usage can also add charges.

Sustained T3 Unlimited CPU can create CPU-credit charges.

Your existing stop condition keeps the experiment focused on fis-cpu-lab.

Return to the AWS FIS experiment template you created earlier.
Choose Start experiment.

Before you confirm the run, consider which incident signal will react first.

Enter start in the confirmation field.
Choose Start experiment to launch the run.
Keep the experiment details page visible.
Select the Stop conditions tab.

You will see the experiment details update to show an active run. The Stop conditions tab keeps the configured guardrail visible during the test.

Experiment Not Starting?

Confirm that fis-cpu-lab is still online in Fleet Manager.
Confirm that FISSSMExperimentRole remains selected for service access.

Ask for help with the template configuration through this experiment troubleshooting prompt.

Watch the guardrail contain the incident

A useful incident investigation follows the complete control loop. Each service supplies one piece of evidence.

Expect the CPU graph to take a few minutes to reflect the experiment because detailed monitoring publishes data in one-minute periods.

Switch back to the EC2 console from earlier.
Select fis-cpu-lab.
Select the Monitoring tab.
Locate the CPUUtilization graph.
Watch the graph until a new datapoint appears.

You will see CPUUtilization climb above 50 percent. That datapoint is the incident your guardrail was built to catch.

How Does the Guardrail React?

CloudWatch evaluates the maximum CPU value from each one-minute period. One datapoint above 50 percent changes fis-cpu-guardrail to ALARM.

AWS FIS watches that alarm as a stop condition. The alarm breach tells AWS FIS to halt the active experiment.

Return to the CloudWatch alarm from earlier.
Select fis-cpu-guardrail.
Inspect the current alarm state.
Inspect the reason for the state change.
Check your inbox for a new message from ops-incident-alerts.
Return to the AWS FIS experiment details.
Inspect the experiment state plus its displayed reason.

You will see fis-cpu-guardrail in ALARM. Its reason identifies a CPUUtilization value above 50 percent.

Your inbox contains a new SNS alert for the alarm state change.

AWS FIS shows Stopped with the reason Experiment halted by stop condition. That is the control loop working from detection through containment.

Incident Evidence Still Missing?

Wait for one more one-minute period if the alarm has not changed.
Confirm that the email subscription remains confirmed in Amazon SNS.
Confirm that the alarm notification still uses ops-incident-alerts.

Use this incident evidence troubleshooting prompt to trace the missing signal.

Confirm recovery and instance health

Stopping the fault injection contains the incident. Recovery requires a healthy CPU metric.

The alarm must reset to OK. Systems Manager Fleet Manager must still show the instance online.

Recovery can take a few minutes because the graph and alarm update in one-minute periods.

Before the final check, consider which recovery signal will settle last.

Return to the EC2 Monitoring tab.
Watch CPUUtilization until the newest data falls below 50 percent.
Return to the CloudWatch alarm.
Wait for fis-cpu-guardrail to return to OK.
Switch back to Fleet Manager from earlier.
Locate fis-cpu-lab in the managed-node list.
Check its current connection status.

You will see CPUUtilization fall below 50 percent. The fis-cpu-guardrail alarm returns to OK.

Fleet Manager continues to show fis-cpu-lab online. You have now proved that the incident was detected without losing management access to the target.

Recovery Taking Longer?

Refresh the CPU graph after the newest one-minute datapoint arrives.
Wait for one more evaluation period if the alarm remains in ALARM.
Confirm that the EC2 instance still shows a running state if Fleet Manager reports it offline.

Use this recovery troubleshooting prompt to investigate a delayed signal.

Secret mission

Add Automatic Reboot Remediation

Your existing guardrail detects the CPU incident. It also stops the fault injection. Add a reboot action so the disposable instance begins recovery automatically.

Clean Up Your Resources

Your AWS game-day lab can continue generating charges after the experiment ends. Choose whether to keep the demo available, pause its compute, or delete the environment.

Cost warning

A running Amazon EC2 t3.micro costs $0.0104 per hour for Linux or Unix in US East (N. Virginia). Regional pricing can differ.

Amazon EBS storage can continue billing after compute stops. Detailed monitoring can incur separate Amazon CloudWatch charges.

Amazon SNS usage remains subject to regional pricing. New AWS Fault Injection Service (AWS FIS) experiments cost $0.10 per action-minute outside AWS GovCloud.

Choose the Pause or Delete option if you no longer need the live demonstration.

Resources you used:

One Amazon Linux 2 EC2 instance named fis-cpu-lab with its EBS root volume.
One AWS Identity and Access Management (IAM) role named SSMInstanceProfile for AWS Systems Manager access.
One Standard SNS topic named ops-incident-alerts with its confirmed email subscription.
One CloudWatch alarm named fis-cpu-guardrail with notification and reboot actions.
One IAM experiment role named FISSSMExperimentRole.
One AWS FIS experiment template containing the runCpuStress action.

Keep everything running

No action needed. Choose this if you plan to demonstrate the complete detection, containment, notification, and remediation workflow again.

Keep fis-cpu-lab running only while you actively use the demonstration.
Retain fis-cpu-guardrail to preserve the CPU guardrail and reboot action.
Retain ops-incident-alerts to preserve email delivery.
Retain the AWS FIS experiment template to preserve the repeatable incident simulation.
Avoid starting another experiment unless you intend to incur another fault-injection charge.

Pause - I'll come back to this later

Shut down the running EC2 instance to reduce compute usage. Keep the remaining configuration so you can restart the lab later.

Use the AWS Management Console search bar to return to Amazon EC2.
Choose Instances in the left navigation panel.
Select fis-cpu-lab.
Choose Instance state.
Choose Stop instance.
Confirm the stop request.
Wait until the instance state shows Stopped.
Avoid starting new AWS FIS experiments while the lab is paused.

The instance no longer consumes running compute while stopped. Its EBS volume and the other retained AWS resources can still incur charges.

Delete - I don't want to use this again

Remove all disposable lab resources to prevent future workload charges. This option also removes the live demonstration configuration.

Deletion is permanent

Deleting these resources is safe because fis-cpu-lab was created for this game day. Choose Keep if you want to demonstrate the incident workflow again.

Terminate the Test Instance

Use the AWS Management Console search bar to return to Amazon EC2.
Choose Instances in the left navigation panel.
Select fis-cpu-lab.
Choose the Storage tab.
Record the root volume ID shown on the Storage tab: your root volume ID.
Choose Instance state.
Choose Terminate (delete) instance.
Confirm with Terminate (delete).

The instance enters its termination process. Its Systems Manager connection disappears after termination completes.

Wait until fis-cpu-lab reaches the terminated state.
Choose Volumes under Elastic Block Store.
Search for your root volume ID.

Root volume already gone

If the search returns no volume, the root volume was removed with the instance. Skip the remaining volume deletion bullets.

Select your root volume ID if the search still shows the volume.
Choose Actions.
Choose Delete volume.
Confirm the volume deletion.

Delete the Experiment Template

Use the AWS Management Console search bar to switch to AWS FIS.
Choose Experiment templates in the left navigation panel.
Select the template containing the runCpuStress action.
Choose Actions.
Choose Delete experiment template.
Enter delete in the confirmation field.
Choose Delete experiment template to confirm.

The repeatable CPU-stress template is now removed. Existing experiment history remains as a record of the completed runs.

Delete the CloudWatch Alarm

Use the AWS Management Console search bar to switch to Amazon CloudWatch.
Choose Alarms in the left navigation panel.
Choose All Alarms.
Select fis-cpu-guardrail.
Choose Actions.
Choose Delete.
Confirm the alarm deletion.

The CPU threshold no longer sends notifications or triggers an EC2 reboot.

Delete the SNS Subscription

Use the AWS Management Console search bar to switch to Amazon SNS.
Choose Subscriptions in the left navigation panel.
Select the email subscription associated with ops-incident-alerts.
Choose Delete.
Confirm the subscription deletion.

Delete the SNS Topic

Choose Topics in the Amazon SNS navigation panel.
Select ops-incident-alerts.
Choose Delete.
Confirm the topic deletion.

The lab no longer has an email delivery channel.

Delete the IAM Roles

The instance must finish terminating before you remove its service role. This prevents the role from remaining attached to a live lab resource.

Use the AWS Management Console search bar to switch to IAM.
Choose Roles in the left navigation panel.
Search for FISSSMExperimentRole.
Select FISSSMExperimentRole.
Choose Delete.
Confirm the role deletion.
Return to the Roles list.
Search for SSMInstanceProfile.
Select SSMInstanceProfile.
Choose Delete.
Confirm the role deletion.

Your disposable AWS incident lab is now removed. Future AWS FIS runs cannot start from the deleted template.

Nice Work!

You completed the game day! Your disposable incident lab proved the full path from a CPU breach to healthy recovery.

What you learned:

Built a disposable Amazon EC2 target that AWS Systems Manager manages without administrative inbound ports.
Established a steady-state CPU baseline below the guardrail threshold. Connected an Amazon CloudWatch alarm to email delivery through Amazon SNS.
Ran a repeatable experiment with AWS Fault Injection Service (AWS FIS) that crossed the CPU threshold. Proved the CloudWatch stop condition moved the experiment to Stopped with Experiment halted by stop condition.
Secret Mission: Added automatic reboot remediation to the alarm action. Verified fis-cpu-lab returned online after the controlled interruption.

Ready to quiz yourself?