Diagnose and Fix a Broken EC2 Web Server

Troubleshoot EC2 network and OS failures like an AWS Cloud Support Associate.

Introduction

30 Second Summary

When a website goes down, someone needs to find the cause and bring it back online. That someone is often an AWS Cloud Support Associate, diagnosing issues layer by layer until the root cause surfaces.

In this project, you will launch a cloud server and deploy a web page on it. Then you will work through two realistic break-fix scenarios that mirror the daily troubleshooting work tested in the Cloud Support Associate interview.

What You'll Build

You type your server's public IP into a browser and see a web page you launched, broke twice, and fixed twice.

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

  • A running web page you can pull up in any browser, served from an EC2 instance you launched and connected to via SSH.
  • Hands-on experience diagnosing and fixing two different failure modes: a security group blocking traffic at the network layer, and a crashed service at the OS layer.
  • A CloudWatch alarm monitoring your server's CPU utilization, proving you can set up proactive issue detection.
  • An optional Secret Mission to push your skills further.

Do I need any prerequisites?

You need an AWS account created after July 15, 2025 to have access to Free Tier credits. You should also have AWS CLI installed on Ubuntu and basic familiarity with Linux terminal commands and networking concepts like TCP/IP and ports.

Before We Start

This project puts you in the shoes of an AWS Cloud Support Associate solving real customer problems. Before we dive in, take a moment to commit to what you are building and why it matters for the role you are targeting.

Set Up Your AWS CLI and Credentials

You committed to building a troubleshooting lab in the last step. Before you can launch an EC2 instance or diagnose anything on it, your Ubuntu terminal needs a verified connection to your AWS account.

Without working credentials, every AWS CLI command fails silently or with cryptic errors. In this step, you will create access keys in the IAM console and configure the CLI so your terminal can talk to AWS.

In this step, get ready to:
  • Create access keys in the IAM console.
  • Configure the AWS CLI with your credentials.
  • Verify the connection with a test command.
Create access keys in the IAM console

Access keys are a pair of credentials that let the AWS CLI sign requests on your behalf. You create them once in the console, then feed them to the CLI.

  • Open your browser and sign in to the AWS Management Console at https://console.aws.amazon.com/.
  • In the top-right corner, click your username.
  • Select Security credentials from the dropdown.
  • Scroll down to the Access keys section.
  • Click Create access key.
  • On the Access key best practices & alternatives page, select Command Line Interface (CLI) as your use case.
  • Check the confirmation checkbox at the bottom, then click Next.
  • Skip the description tag and click Create access key.
  • On the Retrieve access keys page, click Download .csv file and save the file somewhere secure on your computer.
  • Click Done.

Save your secret access key now

This is the only time AWS shows you the secret access key. If you close this page without downloading the CSV or copying the key, you will need to delete this key and create a new one.

What are access keys?

Access keys consist of two parts: an Access Key ID (starts with AKIA) and a Secret Access Key. Together they let the CLI prove your identity to AWS without a password.

The CLI stores them in ~/.aws/credentials on your Ubuntu machine. Never share them or commit them to version control.

Configure the AWS CLI with your credentials

Now that you have your access keys, you need to tell the CLI about them. The aws configure command walks you through this with an interactive wizard.

  • Open your Ubuntu terminal.
  • Start the configuration wizard by running this command:
aws configure

What will this command ask me?

The wizard prompts you for four values, one at a time. Each prompt shows [None] in brackets if no value is currently set.

  • When you see AWS Access Key ID [None]: paste your Access Key ID from the downloaded CSV file and press Enter.
  • When you see AWS Secret Access Key [None]: paste your Secret Access Key from the CSV file and press Enter.
  • When you see Default region name [None]: type us-east-1 and press Enter.
  • When you see Default output format [None]: type json and press Enter.

Pasted the wrong value?

Run aws configure again. It overwrites the previous values. You can also press Enter on any prompt to keep the current value unchanged.

Help me fix my AWS CLI configuration.

Verify the connection

Your CLI is configured, but you have not proven it can actually reach AWS yet. One command confirms everything is wired up correctly.

Before you run the next command, what do you think you will see if the credentials are correct? What about if they are wrong?

  • Verify the connection by running this command:
aws sts get-caller-identity

You should see a JSON response containing your Account ID, user ARN, and user ID. It looks something like this:

{
    "UserId": "AIDAEXAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/your-username"
}

What does this command do?

The aws sts get-caller-identity command asks AWS "who am I?" using the credentials you just configured. If you see your account ID and ARN, your CLI can talk to AWS.

Seeing an error instead of JSON?

If you see a message about invalid credentials or expired tokens, your Access Key ID or Secret Access Key may be incorrect. Open the CSV file you downloaded and double check the values match what you entered.

If you see a connection timeout, check that your Ubuntu machine has internet access. Try running ping google.com to confirm.

Help me troubleshoot my AWS CLI credentials.

Your terminal is now connected to your AWS account. Next up, you will launch an EC2 instance and SSH into it from this same terminal.

Launch Your EC2 Instance and SSH In

Your AWS CLI credentials are configured and verified. Now it's time to launch the cloud server you'll spend the rest of this project troubleshooting.

You'll use the EC2 launch wizard in the AWS Management Console to spin up an instance running Amazon Linux 2023. Then you'll connect to it from your Ubuntu terminal using SSH. This is your first hands-on proof that you can stand up real cloud infrastructure.

In this step, get ready to:
  • Launch a t3.micro EC2 instance running Amazon Linux 2023.
  • Create a key pair for secure SSH access.
  • Connect to the instance from your Ubuntu terminal via SSH.
Launch your EC2 instance
  • In the AWS Management Console, type EC2 in the top search bar and select EC2.
  • Click Launch instance.
  • Under Name, enter troubleshoot-lab.
  • Under Application and OS Images, click Amazon Linux.
  • Confirm the Amazon Linux 2023 AMI is selected (marked Free tier eligible).
  • Under Instance type, select t3.micro (marked Free tier eligible).

Why Amazon Linux 2023 and t3.micro?

Amazon Linux 2023 is AWS's own Linux distribution, built specifically for EC2. It comes pre-integrated with AWS tools and is the standard OS you'll encounter when working in AWS Cloud Support.

The t3.micro instance type is a small, general-purpose option covered by your Free Tier credits. It has more than enough power for a web server lab.

  • Under Key pair (login), click Create new key pair.
  • Enter troubleshoot-lab-key in the Key pair name field.
  • Select RSA for the key pair type.
  • Select .pem for the private key file format.
  • Click Create key pair.

Your browser automatically downloads the troubleshoot-lab-key.pem file. On Ubuntu, this saves to your ~/Downloads folder by default.

What is a key pair?

A key pair consists of a public key (stored by AWS on the instance) and a private key (the .pem file you just downloaded). When you SSH in, your private key proves your identity to the server without needing a password.

Keep this file safe. If you lose it, you lose SSH access to the instance.

  • Scroll down to Network settings and leave everything at the defaults.
  • Click Launch instance.
  • On the success page, click View all instances.
  • Wait for your troubleshoot-lab instance to show Running in the Instance state column.
  • Click the refresh icon if the state still shows Pending. It usually takes 30 to 60 seconds.

What did the launch wizard create?

Besides your EC2 instance, the wizard automatically created a security group (named something like launch-wizard-1) with one inbound rule: SSH access on port 22 from anywhere (0.0.0.0/0).

This rule lets you connect to the instance from your terminal. No other ports are open right now.

Connect to your instance via SSH

Your instance is running in the cloud. Now you need to reach it from your Ubuntu terminal to prove you have remote access.

  • In the EC2 console, select the troubleshoot-lab instance by clicking its checkbox.
  • In the details panel below, find and copy the Public IPv4 address.
  • Set the key file permissions by running this command in your Ubuntu terminal:
chmod 400 ~/Downloads/troubleshoot-lab-key.pem

Why change file permissions?

SSH requires that your private key file is only readable by you. The chmod 400 command sets the file to read-only for the owner and removes all access for everyone else. Without this, SSH refuses to use the key.

Before you run the next command, what do you expect to see if the SSH connection succeeds?

  • Connect to your instance by running this command:
ssh -i ~/Downloads/troubleshoot-lab-key.pem ec2-user@[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]
  • SSH asks you to verify the server's fingerprint the first time you connect. Type yes and press Enter.

Your terminal prompt changes to ec2-user@ip-..., confirming you're inside the Amazon Linux 2023 instance. You're now connected to a server running in the cloud from your local Ubuntu terminal.

Connection timed out or refused?

  • Make sure you copied the Public IPv4 address, not the Private IPv4 address. The private address is not reachable from your local machine.
  • Double-check that you ran chmod 400 on the .pem file. SSH refuses keys with open permissions.
  • Confirm the instance state is Running in the EC2 console. An instance in Pending or Stopped state does not accept connections.

Why can't I SSH into my EC2 instance?

You're inside your EC2 instance and ready to build. Next up, you'll deploy a web server and run straight into your first real troubleshooting challenge.

Deploy a Web Server and Hit the Security Wall

You have a running instance and a live SSH session. The server is online, but it is not doing anything useful yet.

In this step, you will install Apache, deploy a simple web page, and try to load it from the outside world. Something will go wrong. Your job is to figure out where the traffic is being blocked and fix it.

In this step, get ready to:
  • Install and start Apache on your EC2 instance.
  • Deploy a web page and verify it works locally.
  • Diagnose and fix a network-layer block that prevents outside access.
Install and start Apache

Apache httpd is a web server that listens for incoming HTTP requests and serves web pages back to visitors. Before your instance can serve anything, you need to install it and start the service.

  • Install Apache by running this command in your SSH session:
sudo dnf install -y httpd

What does this command do?

dnf is the package manager on Amazon Linux 2023. It downloads and installs software from Amazon's repositories.

httpd is the Apache HTTP Server package. The -y flag auto-confirms the installation so you do not have to type yes at a prompt.

  • You should see download progress followed by Complete! at the end of the output.

Seeing 'No match for argument: httpd'?

Make sure you are inside the SSH session on your EC2 instance, not your local Ubuntu terminal. The httpd package is available in the Amazon Linux 2023 repositories, not in Ubuntu's default repositories.

Help me figure out why httpd won't install on my EC2 instance.

  • Start the Apache service by running:
sudo systemctl start httpd
  • Verify Apache is running by running:
systemctl is-active httpd

You should see active printed in the terminal. Apache is alive and ready to serve pages.

Seeing 'inactive' or 'failed'?

Run sudo systemctl start httpd again and watch for error messages. If you see a permission error, make sure you included sudo at the start of the command.

Help me troubleshoot why Apache httpd won't start on my instance.

Deploy your web page and test it locally

Apache serves files from /var/www/html/ by default. You need to create an HTML file in that directory for Apache to serve.

  • Create your web page by running this command:
sudo sh -c 'cat > /var/www/html/index.html << EOF
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>EC2 Troubleshooting Lab</title>
</head>
<body>
    <h1>EC2 Web Server is Running</h1>
    <p>If you can see this page, your web server is healthy.</p>
    <p>Status: Apache httpd is serving traffic on port 80</p>
</body>
</html>
EOF'

What does this command do?

This uses a heredoc (<< EOF) to write multiple lines of HTML into a file in one shot. sudo sh -c runs the whole command with root permissions, because the /var/www/html/ directory is owned by root.

  • Test that Apache is serving your page locally by running:
curl localhost

You should see your raw HTML printed in the terminal, starting with <!DOCTYPE html>. The web server works on the inside.

✔️ Awesome, I've got everything!

Great. Make sure you have saved the file and that curl localhost returned your HTML.

ⓧ I'd like to double check the full code

Your /var/www/html/index.html should contain exactly this:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>EC2 Troubleshooting Lab</title>
</head>
<body>
    <h1>EC2 Web Server is Running</h1>
    <p>If you can see this page, your web server is healthy.</p>
    <p>Status: Apache httpd is serving traffic on port 80</p>
</body>
</html>

Seeing a blank response or 'Connection refused'?

If curl localhost returns nothing or an error, check that Apache is still running with systemctl is-active httpd. If it says inactive, restart it with sudo systemctl start httpd.

If you see the default Apache test page instead of your content, the index.html file may not have been written. Run the heredoc command again.

Help me figure out why curl localhost is not returning my web page.

Access the page from your browser

Your web page works locally inside the instance. Before you try it from your browser, what do you think will happen? Will the page load?

  • Open your browser and navigate to this address:
http://[[PUBLIC_IP="your EC2 public IPv4 address"]]

The page times out or refuses to connect. This is expected.

Something is blocking your request between your browser and the web server. Time to diagnose it layer by layer, just like a Cloud Support Associate would on a real support ticket.

  • First, check if Apache is still running. In your SSH session, run:
systemctl is-active httpd

It returns active. Apache is running. The problem is not the service.

  • Check if port 80 is open on the instance by running:
sudo ss -tlnp | grep :80

You should see httpd listed as listening on port 80. The service is healthy inside the instance.

So what is blocking the traffic?

Both checks passed. Apache is running and listening on port 80. The problem is not inside the instance. The block is happening at the network layer, before traffic even reaches the operating system.

In AWS, the first layer of network filtering around an EC2 instance is the security group. It acts as a virtual firewall that controls which traffic is allowed in and out.

  • In the EC2 console, select your troubleshoot-lab instance.
  • Click the Security tab.
  • Click the security group link under Security groups.
  • Look at the Inbound rules section.

You will see only one rule: SSH on port 22. There is no rule for HTTP on port 80. The security group is blocking all web traffic from reaching your instance.

Why did this happen?

The EC2 launch wizard creates a security group that only allows SSH access by default. HTTP traffic on port 80 is not included because AWS does not assume every instance needs to be a public web server.

This is the single most common "my web server doesn't work" support ticket pattern. The service is running, the port is open inside the OS, but the security group is blocking traffic before it ever arrives.

Fix the security group

Now that you know the root cause, the fix is straightforward. You need to add an inbound rule that allows HTTP traffic on port 80.

  • Click Edit inbound rules.
  • Click Add rule.
  • Set Type to HTTP.

Selecting HTTP auto-fills Protocol to TCP and Port range to 80.

  • Set Source to Anywhere-IPv4 (0.0.0.0/0).
  • Click Save rules.

What does 0.0.0.0/0 mean?

This source range means "any IPv4 address on the internet." It allows anyone to reach your web server on port 80. For a public web page, this is the correct setting.

You just opened port 80 in the security group. What do you expect to see when you refresh your browser?

  • Refresh your browser at the same address:
http://[[PUBLIC_IP="your EC2 public IPv4 address"]]

Your web page appears. You should see the heading "EC2 Web Server is Running" and the status line confirming Apache is serving traffic on port 80.

Still seeing a timeout?

Security group changes take effect almost immediately, but your browser may have cached the failed request. Try a hard refresh with Ctrl+Shift+R or open the URL in a private/incognito window.

Also double-check that the inbound rule shows HTTP, port 80, and source 0.0.0.0/0 in the security group. If the source is set to a specific IP instead of Anywhere-IPv4, your request will still be blocked.

Help me figure out why my EC2 web page still won't load after updating the security group.

You just completed the most common troubleshooting workflow in cloud support: a working service blocked by a misconfigured security group. Next up, you will break the server a different way and learn to tell network-layer problems apart from OS-layer problems.

Troubleshoot a Service Crash

In the last step, you tracked down a network-layer block and fixed it by adding an HTTP rule to your security group. Your web page loaded in the browser for the first time.

But in real life, web servers crash for many reasons. The network path can be perfectly fine while the service itself is dead inside the instance.

In this step, you will simulate a service failure and figure out whether the problem lives at the network layer or the OS layer. This is exactly what the Cloud Support Associate interview OS round tests.

In this step, get ready to:
  • Simulate a service crash and diagnose the root cause layer by layer.
  • Fix the crashed service and harden it against future reboots.
  • Run the full diagnostic check sequence to confirm everything is healthy.
Simulate a service crash

Your web page is healthy right now. To practice real-world troubleshooting, you need to break it on purpose and then figure out what went wrong.

  • Simulate a crash by stopping Apache inside your SSH session. Run this command:
sudo systemctl stop httpd

Before you refresh the browser, think for a moment. What do you expect to see when you try to load the page now?

  • Switch to your browser and refresh the page.

The page times out or refuses to connect. Your web page is down again.

But wait. You already added the HTTP rule to the security group in the last step. So where is the problem this time?

Where should you look first?

When a web page stops loading, there are two broad places the problem can hide. The first is the network layer, where a firewall or security group blocks traffic before it reaches the instance. The second is the OS layer, where the web server process inside the instance has stopped running.

The diagnostic workflow is to rule out one layer at a time. Start at the network layer, then move inward to the OS.

  • Check the network layer first. In the EC2 console, select your troubleshoot-lab instance.
  • Click the Security tab, then click the security group link.
  • Under Inbound rules, confirm that the HTTP rule for port 80 is still there.

The HTTP rule is still present. The network layer is fine. The problem must be inside the instance.

  • Switch back to your SSH session and check the service status by running:
systemctl status httpd

The output shows Active: inactive (dead). The service is not running.

  • Confirm nothing is listening on port 80 by running:
sudo ss -tlnp | grep :80

The command returns nothing. No process is listening on port 80. This confirms the problem is at the OS layer, not the network layer.

  • Check the logs to see when and why the service stopped by running:
journalctl -u httpd --no-pager -n 20

What did the logs tell you?

The journalctl output shows timestamped entries recording when httpd was stopped. In a real crash, these logs would show error messages, out-of-memory kills, or configuration failures that caused the service to die.

This is the same log a Cloud Support Associate checks when a customer reports their web server is down. Logs tell you the why behind the failure.

Network layer vs OS layer

You have now diagnosed both types of failure. In Step 3, the security group blocked traffic before it reached the instance. That was a network-layer problem. In this step, traffic could reach the instance, but httpd was not running to answer it. That is an OS-layer problem.

The diagnostic reflex is always the same: check the security group first, then check the service. Ruling out layers in order prevents you from chasing the wrong root cause.

Fix and harden the service

You know the root cause now. The httpd process is dead. You need to restart it. You also need to make sure it starts automatically if the instance ever reboots.

  • Restart Apache by running:
sudo systemctl start httpd
  • Enable Apache to start automatically on boot by running:
sudo systemctl enable httpd

Why enable as well as start?

The start command brings the service back right now. The enable command tells the system to start it automatically whenever the instance boots up.

Without enable, a simple reboot would leave the web server down again. Hardening against reboots is a standard practice that prevents repeat support tickets.

  • Verify both settings by running:
systemctl is-active httpd

You should see active.

  • Check the boot setting by running:
systemctl is-enabled httpd

You should see enabled.

Before you refresh the browser, do you think the page will load this time?

  • Switch to your browser and refresh the page.

Your web page is back. The EC2 Web Server is Running heading appears again, confirming the service is healthy.

Page still not loading?

  • Run systemctl is-active httpd again. If it does not show active, re-run sudo systemctl start httpd.
  • Make sure you are loading http:// (not https://) followed by your instance's public IPv4 address. Some browsers auto-redirect to HTTPS, which will not work here.
  • Confirm the security group still has the HTTP rule for port 80 from the previous step.

Help me troubleshoot why my EC2 web page is not loading after restarting httpd.

Confirm your diagnostic muscle memory

Run the full diagnostic check sequence one more time. This is the same set of commands you would use on any support ticket to verify a web server is healthy.

Before you run these, predict what each command will return. Is the service active? Is something listening on port 80? Will the local HTTP request succeed?

  • Check whether the service is running:
systemctl is-active httpd

Returns active. The service is running.

  • Check that httpd is listening on port 80:
sudo ss -tlnp | grep :80

You should see httpd listening on port 80. The process is ready to accept traffic.

  • Test the web server locally to confirm it returns a successful response:
curl -s -o /dev/null -w "%{http_code}" localhost

Returns 200. The web server is healthy and serving your page.

What does this command do?

  • The -s flag silences progress output so you only see the result.
  • The -o /dev/null flag discards the HTML body since you only care about the status code.
  • The -w "%{http_code}" flag prints just the HTTP status code. A 200 means the server responded successfully.

One of the checks is not passing?

  • If systemctl is-active httpd shows anything other than active, run sudo systemctl start httpd again.
  • If the curl command returns a code other than 200, check that your index.html file still exists in /var/www/html/.

Help me figure out why my httpd diagnostic checks are not all passing.

You can now diagnose both network-layer and OS-layer failures on an EC2 instance. Next up, you will set up CloudWatch monitoring so you can catch problems before customers complain.

Set Up CloudWatch Monitoring

You have now diagnosed and fixed two types of EC2 failures. You handled a security group misconfiguration at the network layer and a crashed Apache service at the OS layer. Both times, you only discovered the problem because you manually checked your browser.

In a real Cloud Support Associate role, waiting for users to report problems is not good enough. You need monitoring that catches issues before customers notice. In this step, you will set up a CloudWatch alarm that watches your instance's CPU and would alert you if something goes wrong.

In this step, get ready to:
  • Create a CloudWatch alarm that monitors your EC2 instance's CPU usage.
  • Verify the alarm is healthy and would trigger if CPU spiked.
Navigate to CloudWatch and select your metric
  • Switch back to the AWS Management Console in your browser.
  • Type CloudWatch in the search bar at the top and select CloudWatch.

What is CloudWatch?

CloudWatch is AWS's built-in monitoring service. It automatically collects metrics from your AWS resources and lets you set alarms that trigger when a metric crosses a threshold you define.

EC2 sends basic monitoring data (like CPU usage) to CloudWatch every 5 minutes at no extra charge. Your first 10 alarms are always free, so this alarm costs nothing.

  • In the left sidebar, choose Alarms.
  • Choose All alarms.
  • Choose Create alarm.

The alarm creation wizard opens. Your first task is to pick which metric to monitor.

  • Choose Select metric.
  • Choose EC2.
  • Choose Per-Instance Metrics.
  • Find your troubleshoot-lab instance and select the checkbox next to CPUUtilization.
  • Choose Select metric at the bottom of the page.

You should see a graph of your instance's CPU usage over the past few hours. The Specify metric and conditions page is where you configure when the alarm should fire.

Configure the alarm threshold
  • Under Metric, set Statistic to Average.
  • Set Period to 5 minutes.
  • Under Conditions, for the threshold comparison, choose Greater and enter 80 as the threshold value.
  • Expand Additional configuration.
  • For Missing data treatment, choose missing.
  • Choose Next.

Why these alarm settings?

Average smooths out brief CPU spikes that do not indicate a real problem. The 5-minute period matches EC2's basic monitoring interval, which sends data to CloudWatch every 5 minutes at no extra charge.

An 80% threshold gives you a warning before the instance becomes completely unresponsive. Treating missing data as "missing" prevents the alarm from falsely firing when CloudWatch temporarily stops receiving data from a healthy instance.

  • Under Notification, choose Remove to skip the SNS notification.
  • Choose Next.

Why skip the notification?

SNS (Simple Notification Service) is the AWS service that sends alerts to your email or phone. We are skipping it here because the goal is to learn how alarm mechanics work. In production, you would connect this alarm to an SNS topic so your team gets notified automatically.

  • Enter troubleshoot-lab-cpu-high in the Alarm name field.
  • Choose Next.
  • Review your alarm configuration on the Preview and create page.
  • Choose Create alarm.
Verify your alarm is active

Before you check the alarm status, think about what state you expect it to be in. Your instance has been sitting mostly idle while you worked through the project. Is CPU anywhere near 80%?

  • In the Alarms list, find your troubleshoot-lab-cpu-high alarm.
  • Check the State column.

Your alarm shows OK. CPU usage on an idle t3.micro is well below 80%, so the alarm has nothing to report. If CPU ever spiked above 80%, this alarm would trigger, giving you a heads-up before users notice problems.

Why proactive monitoring matters

In the previous steps, you only discovered failures because you manually checked the browser. That is reactive troubleshooting. CloudWatch alarms flip this model. Instead of waiting for a user to complain, the alarm watches the metric for you and can trigger notifications the moment something crosses your threshold.

This shift from reactive to proactive monitoring is a core skill the Cloud Support Associate interview expects you to demonstrate.

Alarm not showing OK?

New CloudWatch alarms start in an initial state while CloudWatch collects its first data points. If your alarm does not show OK yet, wait about 5 minutes and refresh the page. CloudWatch evaluates the alarm once enough data arrives and it will transition to OK.

If the alarm stays in a non-OK state for more than 10 minutes, make sure you selected the correct instance and the CPUUtilization metric when creating the alarm.

Help me troubleshoot my CloudWatch alarm state

Secret mission

Build a Troubleshooting Runbook Script

What if you could run every diagnostic check from this project with a single command? Senior Cloud Support Associates build runbook scripts that standardize their troubleshooting workflow. Your mission: create a bash script that automates the full diagnostic checklist.

Clean Up Your Resources

Clean Up Your Resources

This project runs on AWS Free Tier credits. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Your EC2 instance consumes Free Tier credits while it is running. If you leave it running continuously, those credits will deplete faster. Your credits expire 6 months after account creation or when used up, whichever comes first.

If you are done with the project, choose the Delete option below to stop consuming credits.

Resources you used:

  • EC2 instance troubleshoot-lab (t3.micro). Uses Free Tier credits while running.
  • EBS volume (8 GB gp3, attached to the instance). Uses Free Tier credits.
  • Key pair troubleshoot-lab-key (stored in AWS and as a local .pem file). No cost.
  • Security group (launch-wizard). No cost.
  • CloudWatch alarm troubleshoot-lab-cpu-high. Within the Always Free tier (10 alarms free).
  • Local key file ~/Downloads/troubleshoot-lab-key.pem on your Ubuntu machine.

Keep everything running

No action needed. Choose this if you are still actively building or plan to extend the project.

  • The instance will continue consuming Free Tier credits while running.
  • Your credits last approximately 6 months from account creation or until used up.
  • The CloudWatch alarm stays within the Always Free tier and costs nothing.

Pause - I'll come back to this later

Shut down the instance to stop consuming compute credits. Your files and configuration remain intact.

  • Return to the EC2 console and choose Instances in the navigation pane.
  • Select the troubleshoot-lab instance.
  • Choose Instance state, then Stop instance.
  • The EBS volume still uses a small amount of Free Tier credits while the instance is stopped, but compute credits stop being consumed.
  • To restart later, select the instance and choose Instance state, then Start instance.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step in order.

Step 1: Terminate the EC2 instance.

  • In the EC2 console, choose Instances in the navigation pane.
  • Select the troubleshoot-lab instance.
  • Choose Instance state, then Terminate (delete) instance.
  • Choose Terminate (delete) when prompted for confirmation.
  • The attached EBS volume is deleted automatically because DeleteOnTermination is true by default for root volumes.

Step 2: Delete the key pair.

  • In the EC2 console, choose Key Pairs in the navigation pane.
  • Select troubleshoot-lab-key and choose Actions, then Delete.
  • Type Delete in the confirmation field and choose Delete.

Step 3: Delete the security group.

  • Wait about a minute after terminating the instance so the security group is no longer associated with any resources.
  • In the EC2 console, choose Security Groups in the navigation pane.
  • Select the launch-wizard security group created for this project.
  • Choose Actions, then Delete security groups.
  • Choose Delete to confirm.

Step 4: Delete the CloudWatch alarm.

  • Open the CloudWatch console. In the navigation pane, choose Alarms, then All alarms.
  • Select troubleshoot-lab-cpu-high and choose Actions, then Delete.
  • Choose Yes, Delete when prompted for confirmation.

Step 5: Delete the local key file.

  • In your Ubuntu terminal, delete the .pem file by running:
rm ~/Downloads/troubleshoot-lab-key.pem
  • This removes the private key from your machine. The public key was already removed from AWS in Step 2.

Nice Work!

Nice Work!

You've just diagnosed and fixed a broken EC2 web server from scratch. Along the way, you worked through the exact troubleshooting workflow that AWS Cloud Support Associates use every day.

You've learned how to:

  • Deployed an Apache web server on an EC2 instance running Amazon Linux 2023 and diagnosed a security group misconfiguration that blocked HTTP traffic at the network layer.
  • Simulated a service crash and recovered it using systemctl, ss, and journalctl to troubleshoot at the OS layer.
  • Created a CloudWatch alarm to monitor CPU utilization for proactive issue detection.
  • Completed an optional Secret Mission to push your troubleshooting skills further.

Ready to quiz yourself?