Diagnose a Broken EC2 Web Server

Troubleshoot and restore an unreachable EC2 Apache web server.

Introduction

30 Second Summary

A website can look healthy from the server's point of view while every customer sees a page that never loads. Support work begins in the gap between those two experiences.

In this project, you will investigate a simulated customer outage on an Amazon EC2 web server. You will use AWS Systems Manager Session Manager plus a Bash diagnostic script to identify the blocked network path before documenting the resolution in a PDF.

What You'll Build

The repaired public URL opens in Microsoft Edge as a green CASE RESOLVED report for incident CSA-HTTP-001, ready to print as your interview evidence.

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

  • Reproduce a customer-visible outage while healthy EC2 checks remain visible in the console.
  • Run a reusable diagnostic report that shows Apache HTTP Server is enabled, active, listening on port 80, and answering locally.
  • Restore public HTTP access with one security group rule while leaving SSH closed.
  • Secret Mission: stop Apache deliberately and prove that the same customer symptom can come from an application-layer failure.

Are there any prerequisites?

You'll need an AWS account with an active Free plan or usable credits. The account needs administrator-level access for creating the lab resources.

You'll also need Microsoft Edge or Google Chrome on Windows.

Before We Start

Before the hands-on work begins, commit to treating this exercise as a customer support case. You will define the customer’s problem, the recovery goal, and the evidence that separates host, application, and network failures.

Launch the Broken Support Case

You have defined the customer symptom and the evidence needed to isolate it. Your Amazon EC2 lab now needs a healthy server with an intentionally blocked HTTP path.

An empty security group creates that controlled failure. AWS Systems Manager Session Manager gives you browser-based access while SSH stays closed.

In this step, get ready to:
  • Confirm that your AWS plan or credits can cover the lab.
  • Create the instance role for Session Manager access.
  • Launch the blocked support case and verify that Apache starts at boot.
Guard your budget and create the instance role

The account check is your cost gate. The AWS Identity and Access Management (IAM) role then lets the instance register with Session Manager.

Protect Your Credits

Billing screens can feel risky. This check keeps the decision in your hands before any resource exists.

A Free plan or usable credits keeps the lab inside its intended budget. The instance must also show Free tier eligibility before launch.

  • Press Cmd+Space on macOS or the Windows key on Windows to open system search.
  • Type Microsoft Edge in the search field.
  • Press Enter to open Microsoft Edge.
  • Go to the AWS Management Console.
  • Sign in with your administrator-level access.
  • Review your account plan or available credits to confirm whether this lab is covered.
  • Continue only if the account shows a Free plan or usable credits.

Good call. You have confirmed that the lab fits within your available AWS allowance before creating resources.

  • Use the console search bar to open IAM.
  • Select Roles in the left navigation.
  • Choose Create role.
  • Select AWS service as the trusted entity type.
  • Select EC2 as the use case.
  • Continue to the permissions selection.
  • Search for AmazonSSMManagedInstanceCore.
  • Select only AmazonSSMManagedInstanceCore.

Why This Permission?

The managed policy gives the instance the permissions needed to operate as a Systems Manager managed node. Session Manager can then provide the support shell without an inbound SSH rule.

  • Continue to the role details.
  • Enter EC2SupportLabRole in the Role name field.
  • Choose Create role.
  • Select EC2SupportLabRole from the roles list.
  • Confirm that the permissions list contains only AmazonSSMManagedInstanceCore.

Where Is the Instance Profile?

Creating an EC2 role in the IAM console also creates an instance profile with the same name. You can select the EC2SupportLabRole instance profile during the instance launch.

Launch the intentionally blocked EC2 instance

The standard Amazon Linux 2023 (AL2023) AMI provides the operating system for the support case. User data installs Apache HTTP Server while the empty inbound rules preserve the planned customer failure.

  • Use the console search bar to open EC2.
  • Select Instances in the left navigation.
  • Choose Launch instances.
  • Enter aws-support-case under Name and tags.
  • Select the standard Amazon Linux 2023 AMI under Application and OS Images (Amazon Machine Image).
  • Select t3.micro under Instance type only when it is marked Free tier eligible.
  • Select Proceed without a key pair (not recommended) under Key pair (login).
  • Leave Configure storage unchanged to use the default root volume.

Why Skip the Key Pair?

Session Manager provides the browser-based shell for this lab. Skipping the key pair supports the goal of keeping inbound SSH access closed.

  • Expand Network settings.
  • Set Auto-assign Public IP to Enable.
  • Select the option that creates a new security group.
  • Enter aws-support-case-sg as the security group name.
  • Remove the automatically added SSH inbound rule.
  • Confirm that the inbound rules list is empty.

Your Controlled Failure

The empty inbound rules block both SSH and public HTTP traffic. The instance can still initiate the outbound connection required by Session Manager.

  • Expand Advanced details.
  • Select EC2SupportLabRole under IAM instance profile.
  • Set Credit specification to standard.
  • Scroll to the User data field.
  • Leave User data has already been base64 encoded clear.

What User Data Creates

The first-boot script installs Apache. It also creates the case-resolution page and the reusable diagnostic script.

EC2 runs this script as the root user during the first launch. The script therefore uses service and package commands without sudo.

  • Paste the opening section of user-data.sh into the empty User data field using this code:
#!/bin/bash

dnf install -y httpd

cat > /var/www/html/index.html <<'HTML'
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>AWS Cloud Support Case CSA-HTTP-001</title>
  <style>
    :root { color-scheme: dark; font-family: Arial, sans-serif; background: #0b1220; color: #e5edf8; }
    body { margin: 0; padding: 48px 20px; background: linear-gradient(135deg, #0b1220, #17233a); }
    main { max-width: 900px; margin: 0 auto; }
    .status { display: inline-block; padding: 8px 12px; border: 1px solid #34d399; border-radius: 999px; color: #34d399; font-weight: 700; letter-spacing: 0.08em; }
    h1 { margin: 20px 0 8px; font-size: 2.5rem; }
    .subtitle { color: #a9b8cf; font-size: 1.1rem; }
    .grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); gap: 16px; margin-top: 28px; }
    section { padding: 20px; border: 1px solid #31415c; border-radius: 14px; background: rgba(17, 27, 46, 0.9); }
    h2 { margin-top: 0; color: #7dd3fc; font-size: 1.05rem; }
    code { color: #fbbf24; }
    .full { grid-column: 1 / -1; }
    @media print { :root { background: white; color: #111827; } body { padding: 0; background: white; } section { background: white; border-color: #cbd5e1; } .subtitle { color: #475569; } }
  </style>
</head>

What Does This Code Do?

  • The interpreter line tells Linux to run the user data as a Bash script.
  • The package command installs Apache from the Amazon Linux 2023 repository.
  • The quoted here-document starts writing the support page to /var/www/html/index.html.
  • The page head defines the document metadata and the report styling.
  • Confirm that the first line in User data is #!/bin/bash.
  • Confirm that the current final line is </head>.

First Chunk Out of Place?

Clear the field if text appears before the interpreter line. Paste the opening section again from its first line.

Use this if the opening section does not match. Help me check the first section of my EC2 user-data script.

  • Place your cursor immediately after </head> in the User data field.
  • Append the support page body by pasting this code:
<body>
  <main>
    <span class="status">CASE RESOLVED</span>
    <h1>AWS Cloud Support Case</h1>
    <p class="subtitle">Incident CSA-HTTP-001: EC2 web server healthy locally but unreachable to customers</p>
    <div class="grid">
      <section><h2>Customer symptom</h2><p>The public HTTP endpoint did not load even though the EC2 instance was running.</p></section>
      <section><h2>Host evidence</h2><p>EC2 system and instance status checks passed.</p></section>
      <section><h2>Application evidence</h2><p><code>httpd</code> was enabled and active, with a TCP listener on port <code>80</code>.</p></section>
      <section><h2>HTTP evidence</h2><p>A HEAD request to <code>http://localhost/</code> returned response headers successfully.</p></section>
      <section class="full"><h2>Root cause</h2><p>The attached security group had no inbound rule permitting TCP port 80, so customer traffic could not reach the healthy Apache service.</p></section>
      <section><h2>Resolution</h2><p>Added one inbound HTTP rule for TCP port 80 and kept SSH closed.</p></section>
      <section><h2>Prevention</h2><p>Validate host, service, listener, local HTTP, and network policy as separate troubleshooting layers.</p></section>
      <section class="full"><h2>Skills demonstrated</h2><p>Amazon EC2, Amazon Linux 2023, AWS Systems Manager Session Manager, Linux service management, TCP and HTTP troubleshooting, security groups, scripting, and incident communication.</p></section>
    </div>
  </main>
</body>
</html>
HTML

What Does This Code Do?

  • The page body records the customer symptom and the evidence gathered during the case.
  • The report sections capture the root cause and the resolution.
  • The remaining sections capture prevention advice and the skills demonstrated.
  • The final HTML delimiter closes the support-page here-document.
  • Confirm that <body> appears directly below </head>.
  • Confirm that the current final line contains only HTML.

Page Markup Misaligned?

Check that the body starts immediately after the closing head tag. Keep the closing here-document delimiter on its own line.

Use this if the page body landed in the wrong place. Help me fix the page section in my EC2 user-data script.

  • Place your cursor immediately after the closing HTML delimiter.
  • Append the diagnostic script and Apache startup commands by pasting this code:
cat > /usr/local/bin/support-check.sh <<'SCRIPT'
#!/bin/bash

echo "=== AWS CLOUD SUPPORT TRIAGE ==="
echo
echo "[1] Apache boot configuration"
systemctl is-enabled httpd
echo
echo "[2] Apache runtime state"
systemctl is-active httpd
echo
echo "[3] TCP port 80 listener"
ss -ltnp 'sport = :80'
echo
echo "[4] Local HTTP response"
curl --head --max-time 5 http://localhost/
SCRIPT

systemctl start httpd
systemctl enable httpd

What Does This Code Do?

  • The second here-document creates /usr/local/bin/support-check.sh as a reusable diagnostic script.
  • The script checks Apache boot configuration and runtime state.
  • The script checks the TCP port 80 listener and the local HTTP response.
  • The final commands start Apache and enable it for future boots.
  • Confirm that the diagnostic-script section appears directly below the closing HTML delimiter.
  • Confirm that the final line in User data is systemctl enable httpd.

Bootstrap Ending Missing?

Check that the SCRIPT delimiter appears on its own line. Confirm that both Apache service commands follow it.

Use this if the diagnostic script looks incomplete. Help me check the final section of my EC2 user-data script.

✔️ Awesome, I've got everything!

Great. Double check that the User data field ends with systemctl enable httpd before launching the instance.

ⓧ I'd like to double check the full code

Compare the complete user-data.sh file below with the contents of your User data field:

#!/bin/bash

dnf install -y httpd

cat > /var/www/html/index.html <<'HTML'
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>AWS Cloud Support Case CSA-HTTP-001</title>
  <style>
    :root { color-scheme: dark; font-family: Arial, sans-serif; background: #0b1220; color: #e5edf8; }
    body { margin: 0; padding: 48px 20px; background: linear-gradient(135deg, #0b1220, #17233a); }
    main { max-width: 900px; margin: 0 auto; }
    .status { display: inline-block; padding: 8px 12px; border: 1px solid #34d399; border-radius: 999px; color: #34d399; font-weight: 700; letter-spacing: 0.08em; }
    h1 { margin: 20px 0 8px; font-size: 2.5rem; }
    .subtitle { color: #a9b8cf; font-size: 1.1rem; }
    .grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); gap: 16px; margin-top: 28px; }
    section { padding: 20px; border: 1px solid #31415c; border-radius: 14px; background: rgba(17, 27, 46, 0.9); }
    h2 { margin-top: 0; color: #7dd3fc; font-size: 1.05rem; }
    code { color: #fbbf24; }
    .full { grid-column: 1 / -1; }
    @media print { :root { background: white; color: #111827; } body { padding: 0; background: white; } section { background: white; border-color: #cbd5e1; } .subtitle { color: #475569; } }
  </style>
</head>
<body>
  <main>
    <span class="status">CASE RESOLVED</span>
    <h1>AWS Cloud Support Case</h1>
    <p class="subtitle">Incident CSA-HTTP-001: EC2 web server healthy locally but unreachable to customers</p>
    <div class="grid">
      <section><h2>Customer symptom</h2><p>The public HTTP endpoint did not load even though the EC2 instance was running.</p></section>
      <section><h2>Host evidence</h2><p>EC2 system and instance status checks passed.</p></section>
      <section><h2>Application evidence</h2><p><code>httpd</code> was enabled and active, with a TCP listener on port <code>80</code>.</p></section>
      <section><h2>HTTP evidence</h2><p>A HEAD request to <code>http://localhost/</code> returned response headers successfully.</p></section>
      <section class="full"><h2>Root cause</h2><p>The attached security group had no inbound rule permitting TCP port 80, so customer traffic could not reach the healthy Apache service.</p></section>
      <section><h2>Resolution</h2><p>Added one inbound HTTP rule for TCP port 80 and kept SSH closed.</p></section>
      <section><h2>Prevention</h2><p>Validate host, service, listener, local HTTP, and network policy as separate troubleshooting layers.</p></section>
      <section class="full"><h2>Skills demonstrated</h2><p>Amazon EC2, Amazon Linux 2023, AWS Systems Manager Session Manager, Linux service management, TCP and HTTP troubleshooting, security groups, scripting, and incident communication.</p></section>
    </div>
  </main>
</body>
</html>
HTML

cat > /usr/local/bin/support-check.sh <<'SCRIPT'
#!/bin/bash

echo "=== AWS CLOUD SUPPORT TRIAGE ==="
echo
echo "[1] Apache boot configuration"
systemctl is-enabled httpd
echo
echo "[2] Apache runtime state"
systemctl is-active httpd
echo
echo "[3] TCP port 80 listener"
ss -ltnp 'sport = :80'
echo
echo "[4] Local HTTP response"
curl --head --max-time 5 http://localhost/
SCRIPT

systemctl start httpd
systemctl enable httpd
  • Choose Launch instance.

Your support-case infrastructure now exists. AWS begins the first boot while user data installs Apache and creates the diagnostic artifacts.

Launch Blocked?

Confirm that t3.micro is available in the selected Region. Recheck its Free tier eligibility before trying again.

Use this if the launch cannot continue. Help me troubleshoot why my EC2 support instance will not launch.

Verify Session Manager access

First boot can take several minutes because user data installs Apache and writes both support files. Session Manager also needs time to register the instance as a managed node.

  • Return to the Instances list.
  • Wait until aws-support-case shows a running instance state.
  • Wait until the EC2 status checks pass.
  • Select aws-support-case.
  • Confirm that the instance details show a public IPv4 address.
  • Choose Connect.
  • Choose Session Manager.
  • Choose Connect to open the browser-based shell.

Before you run the boot check, do you expect Apache to be enabled after the user-data script finishes?

  • Check the Apache boot configuration by running this command:
sudo systemctl is-enabled httpd

What Does This Command Prove?

The command asks systemd whether Apache is configured to start during future boots. It verifies the persistent boot setting created by user-data.sh.

Public reachability remains a separate test. This result gives you host configuration evidence before you test the customer path.

You should see enabled. That result confirms the first-boot automation configured Apache to start at boot.

Session Manager Not Ready?

  • Wait a few more minutes if the instance has only just reached its running state.
  • Confirm that EC2SupportLabRole is selected as the instance profile.
  • Confirm that the role still has only AmazonSSMManagedInstanceCore attached.

Use this if the connection or boot check still fails. Help me diagnose my EC2 Session Manager connection.

That is the lab backbone ready. Your EC2 instance accepts browser-based support sessions while its empty inbound rules keep the customer path blocked.

Next, you will use the public IPv4 address to reproduce the customer's failed request before changing the configuration.

Reproduce the Customer Incident

The Amazon EC2 support lab is running. Apache HTTP Server is enabled at boot.

Your next goal is to test the website through the customer's browser path. The reported problem needs a clear before-and-after comparison before you investigate or repair anything.

In this step, get ready to:
  • Test the public website from Microsoft Edge.
  • Record the customer-visible result.
  • Compare the browser result with the EC2 system and instance checks.
Test the public website from Microsoft Edge

A public IPv4 address is the web server's customer-facing destination. An HTTP request from Microsoft Edge tests the same external path a customer uses.

  • Switch back to the AWS Management Console tab from earlier.
  • Choose Instances in the Amazon EC2 navigation pane.
  • Select the checkbox beside aws-support-case.
  • Copy the value beside Public IPv4 address.
  • Record the value here: your public IPv4 address.
  • Press the Windows key to open Windows search.
  • Enter Microsoft Edge in the search bar.
  • Press Enter to open Microsoft Edge.
  • Click the address bar.
  • Enter http://your public IPv4 address in the address bar.

Before you test the address, do you think the support-case page will load?

  • Press Enter to test the public website.

Microsoft Edge may spend a short time waiting for a response. That pause comes from the browser trying to reach the server.

The support-case page does not load. You have reproduced the customer's visible symptom.

Did the page load?

  • Confirm that the address you entered matches the Public IPv4 address shown for aws-support-case.
  • Confirm that the security group named aws-support-case-sg still shows no inbound rules.

Help me check why the controlled website failure did not occur.

Compare the failure with EC2 status checks

The EC2 status checks assess AWS infrastructure plus the instance's own software and network connectivity. Passing checks support a narrow conclusion about whether the virtual machine is healthy enough for deeper investigation.

  • Switch back to the AWS Management Console tab from earlier.
  • Choose Instances in the Amazon EC2 navigation pane.
  • Select aws-support-case.

Before you open the health view, do you expect the instance checks to match the failed browser result?

  • Choose the Status and alarms tab.
  • Confirm that the system check is passing.
  • Confirm that the instance check is passing.

What Do These Checks Prove?

  • System checks monitor the AWS infrastructure hosting the instance.
  • Instance checks monitor the instance's software and network connectivity.
  • Passing both checks shows that the virtual machine is healthy enough for deeper inspection.
  • Public website reachability still requires separate evidence.

The browser path fails while the EC2 system and instance checks pass. You now have evidence of a customer-visible external failure alongside a virtual machine that remains healthy enough for deeper investigation.

You have reproduced the incident without changing the system. Next, you'll gather evidence from inside the instance to identify which layers are healthy.

Prove the Server Is Healthy from Inside

Your Amazon EC2 instance passed its status checks. However, Microsoft Edge still cannot load the public HTTP page.

Now you'll use AWS Systems Manager Session Manager to gather evidence from inside the instance. EC2 status checks cannot prove that Apache HTTP Server is running, listening, or answering requests.

In this step, get ready to:
  • Return to the existing browser-based Session Manager shell.
  • Run the diagnostic script and isolate the healthy server layers.
Return to the Session Manager shell

The browser shell reaches the instance without an inbound SSH rule. This preserves the original customer symptom while you inspect the operating system.

  • Switch back to the browser tab containing the Session Manager shell from earlier.

You'll see the shell ready to accept commands on aws-support-case.

Session no longer open?

  • Return to the Instances page in Amazon EC2.
  • Select aws-support-case.
  • Choose Connect.
  • Choose Session Manager.
  • Choose Connect.

Help me reconnect to my EC2 instance through Session Manager.

Run the layered diagnostic

A layered troubleshooting report tests one boundary at a time. This Bash script checks the boot configuration, runtime process, TCP listener, and local web response.

Before you run the report, picture which of the four internal checks you expect to fail.

  • Run the existing diagnostic script in the Session Manager shell by running:
sudo bash /usr/local/bin/support-check.sh

What does this report check?

  • The boot check proves Apache is configured to start with the instance.
  • The runtime check confirms that httpd currently has an active process.
  • The socket check looks for a TCP listener on port 80.
  • The local HEAD request asks Apache for response headers through http://localhost/.
  • Read the report from the first check through the fourth check.

What should I see?

  • The Apache boot configuration reports enabled.
  • The Apache runtime state reports active.
  • The socket section shows a TCP listener on port 80.
  • The local request returns HTTP response headers from http://localhost/.

All four checks pass inside the instance. The fault is now narrowed to the path between Microsoft Edge and the healthy local Apache service.

Report missing a healthy check?

  • Confirm that the Session Manager shell is connected to aws-support-case.
  • Wait a few minutes if the diagnostic script is missing because the first-boot user data may still be finishing.
  • Run the diagnostic script again after the first-boot setup finishes.

Help me diagnose an unhealthy check in the support report.

That's the core diagnosis complete. You have proved that the host, Apache process, TCP listener, and local HTTP path are healthy.

Your evidence clears the host, service, socket, and local HTTP layers. Next, you'll repair the customer path with the smallest network change.

Repair the Network Access Layer

Your browser-based AWS Systems Manager Session Manager evidence proved that Apache HTTP Server is healthy inside the instance. The customer request still stops at the network boundary.

The empty security group is the remaining gap. In this step, you'll add one inbound HTTP rule that restores the customer path while keeping SSH closed.

In this step, get ready to:
  • Locate the security group attached to the support instance.
  • Permit public HTTP traffic on TCP port 80.
  • Verify that the resolved support page loads while SSH remains closed.
Open the attached security group

The instance's security details link directly to the firewall controlling its traffic. Its empty inbound rule list explains why local requests succeed while customer requests never reach Apache.

  • Switch back to the Amazon EC2 console tab from earlier.
  • Choose Instances in the navigation pane.
  • Select the checkbox beside aws-support-case.
  • Choose the Security tab.
  • Open the aws-support-case-sg link in the security group details.

You'll see no inbound rules listed. This confirms that the firewall has no path for customer HTTP traffic.

Add the HTTP inbound rule

Opening a public path can feel risky. The narrow change exposes only TCP port 80.

  • Choose Edit inbound rules.
  • Choose Add rule.
  • Set Type to HTTP.
  • Set Source to Anywhere-IPv4.
  • Confirm that Source displays 0.0.0.0/0.
  • Choose Save rules.

You'll see exactly one inbound rule for TCP port 80 from 0.0.0.0/0. That is the precise network change this incident needed.

SSH remains closed because the security group has no inbound SSH rule.

Can't save the inbound rule?

  • Confirm that the rule's Type is HTTP.
  • Confirm that the rule's Source is Anywhere-IPv4.
  • Confirm that your administrator-level AWS sign-in can edit security group rules.

Help me troubleshoot why I cannot save the HTTP inbound rule.

Refresh the customer page

Security group rule changes apply automatically to associated resources. The Apache process and the support page remain unchanged.

Before you refresh, which result do you expect from the same public address?

  • Switch back to the Microsoft Edge tab from the earlier customer test.
  • Refresh the current page.

You'll see the green CASE RESOLVED page for incident CSA-HTTP-001.

That is a strong diagnosis: one HTTP rule restored the customer path without opening SSH.

What did the repair change?

The HTML page and Apache service stayed the same throughout this repair. The new inbound rule changed whether the browser could reach TCP port 80.

The before-and-after result identifies the empty inbound policy as the root cause.

Still can't load the page?

  • Confirm that the address bar still uses the http:// scheme.
  • In the aws-support-case-sg inbound rules page, confirm that exactly one HTTP rule allows Anywhere-IPv4.
  • In the Session Manager shell from earlier, confirm that the existing diagnostic output shows Apache as active with a TCP port 80 listener.

Help me troubleshoot why the public EC2 page still does not load.

Your network repair is proven from the customer's browser. Next, you'll turn this incident into a portable PDF that presents your evidence and resolution clearly.

Package the Resolution for Your Portfolio

Your Amazon EC2 web server is reachable again. You proved that one HTTP rule restored the customer path while SSH stayed closed.

Support engineers need to communicate evidence and root cause clearly. A portable incident artifact turns this resolution into proof you can discuss during an interview.

In this step, you'll export the resolved page from Microsoft Edge as a PDF. You'll then rehearse a two-minute case explanation.

In this step, get ready to:
  • Export the resolved support-case page as a PDF.
  • Review the PDF for every required incident section.
  • Rehearse a two-minute explanation of the resolution.
Export the resolved case as a PDF

The resolved page already records the customer symptom and the evidence behind your diagnosis. Exporting it preserves that incident story in a file you can open without the live web server.

  • Switch back to the resolved case page in Microsoft Edge.
  • Open the print window by pressing Ctrl+P.
  • Select Microsoft Print to PDF from the printer list.
  • Select Print to continue.
  • Select a Windows folder that you can return to.
  • Enter AWS-Cloud-Support-Case-Resolved.pdf as the file name.
  • Complete the save operation.

Good work. Your resolved support case now exists as AWS-Cloud-Support-Case-Resolved.pdf in the folder you selected.

PDF Missing After Saving?

  • Repeat the print flow if the file is absent from the folder you selected.
  • Check that Microsoft Print to PDF is selected before completing the print flow.

Ask for help if the PDF still does not appear: Help me troubleshoot why Microsoft Edge is not saving my resolved support-case page as a PDF on Windows.

Review and rehearse the resolution

A useful incident artifact makes the reasoning visible from symptom to prevention. Reviewing the exported file confirms that the full case survived the print process.

Before you open the PDF, take a moment to predict whether every evidence section made it into the export.

  • Return to the Windows folder you selected during the save.
  • Open AWS-Cloud-Support-Case-Resolved.pdf.

What Should I See?

The open PDF should contain these sections:

  • The Customer symptom section records the failed public endpoint.
  • The Host evidence section records the passing EC2 checks.
  • The Application evidence section records the healthy Apache service.
  • The HTTP evidence section records the successful local response.
  • The Root cause section identifies the missing inbound rule.
  • The Resolution section records the minimal HTTP-only fix.
  • The Prevention section captures the layered troubleshooting approach.
  • The Skills demonstrated section summarizes the technical evidence behind the case.

Your PDF gives your explanation a fixed evidence trail. The strongest interview answer follows that trail in the same order you investigated the incident.

  • Set a two-minute limit for your rehearsal.
  • Begin with the customer impact.
  • Describe the checks you performed.
  • Explain the evidence that ruled out a host failure.
  • Explain the evidence that ruled out an application failure.
  • State the security-group root cause.
  • Describe the minimal HTTP-only fix.
  • Finish with your prevention advice.

That's the case packaged. You now have a local incident report that shows the symptom and the evidence behind your resolution.

Secret mission

Diagnose an Application-Layer Failure

The customer sees the same failed page again while the original HTTP rule remains in place. Use the existing triage script to isolate the new root cause. Restore Apache to prove recovery across both paths.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the lab active, pause it for later, or delete it entirely. Keeping the lab active can continue consuming AWS allowances or credits.

Cost warning

The running aws-support-case instance can continue consuming compute allowance or credits. Its Amazon EBS root volume can continue consuming storage allowance or credits after you stop the instance.

Outside applicable allowances or credits, a public IPv4 address costs $0.005 per IP-hour. The Delete option below ends this lab's ongoing resource usage.

Resources you used:

  • Cloud compute: One Amazon EC2 instance named aws-support-case with its default root volume and auto-assigned public IPv4 address.
  • Network access: One security group named aws-support-case-sg with public HTTP access on TCP port 80.
  • Instance access: One AWS Identity and Access Management (IAM) role named EC2SupportLabRole with its same-name instance profile.
  • Local evidence: One Windows file named AWS-Cloud-Support-Case-Resolved.pdf.

Keep everything running

No action is needed. Choose this if you still want the resolved page available for demonstrations or further practice.

  • The aws-support-case instance stays running with Apache active.
  • The public case-resolution page remains reachable through the instance's current public IPv4 address.
  • The aws-support-case-sg security group keeps TCP port 80 open while SSH remains closed.
  • The EC2SupportLabRole role remains available for browser-based Session Manager access.
  • The AWS-Cloud-Support-Case-Resolved.pdf file remains in the Windows folder where you saved it.

Pause - I'll come back to this later

Stop the running instance to pause compute usage. The root volume remains stored so you can return to the lab later.

  • Return to the Instances page in the EC2 console.
  • Select the checkbox beside aws-support-case.
  • Choose Instance state.
  • Choose the option that stops the selected instance.
  • Confirm the stop request.

You'll see the instance move to a stopped state. Compute usage stops while the Amazon EBS root volume persists.

The auto-assigned public IPv4 address is released. The public URL changes after you start the instance again.

  • Keep aws-support-case-sg attached so the HTTP rule is ready when you return.
  • Keep EC2SupportLabRole so Session Manager access is ready after the next start.
  • Keep AWS-Cloud-Support-Case-Resolved.pdf in its current Windows folder.

Delete - I don't want to use this again

Remove the project resources to close the lab. Terminating the instance is permanent, so your local PDF remains the only copy of the case artifact unless you delete it too.

  • Confirm that AWS-Cloud-Support-Case-Resolved.pdf is stored in the Windows folder you want to use.
  • Return to the Instances page in the EC2 console.
  • Select the checkbox beside aws-support-case.
  • Choose Instance state.
  • Choose Terminate (delete) instance.
  • Confirm the permanent action with Terminate (delete).
  • Wait until the EC2 console reports that aws-support-case is terminated.

You'll see the instance enter a terminated state. Its auto-assigned public IPv4 address is released.

The attached root volume configured for deletion is removed permanently.

  • Return to the EC2 console after termination finishes.
  • Open the page that lists security groups in the network section.
  • Select aws-support-case-sg.
  • Use the page's delete action to remove the selected security group.
  • Confirm that aws-support-case-sg no longer appears in the security group list.

The network policy for the deleted lab is now removed from your account.

  • Return to the AWS Management Console from earlier.
  • Find IAM with the console's service search.
  • Choose Roles.
  • Open EC2SupportLabRole.
  • Use the role page's delete action to remove EC2SupportLabRole.
  • Confirm that EC2SupportLabRole no longer appears in the role list.

The PDF has no ongoing cost. Keep it unless you want to remove every local artifact from this lab.

  • Close AWS-Cloud-Support-Case-Resolved.pdf if it is still open.
  • Search Windows for File Explorer.
  • Open the matching app.
  • Return to the folder where you saved the PDF.
  • Select AWS-Cloud-Support-Case-Resolved.pdf.
  • Press Shift+Delete to request permanent deletion.
  • Confirm the deletion.

You'll no longer see the PDF in its saved Windows folder.

Nice Work!

Nice Work!

You did it! You diagnosed two failures on an Amazon EC2 web server. Your evidence separated a blocked network path from a stopped Apache service.

What you learned:

  • Built an Amazon Linux 2023 support lab that you can access through AWS Systems Manager Session Manager. Created a reusable Bash triage script for checking service health.
  • Used layered troubleshooting to prove that the host was healthy. The local service evidence narrowed the first root cause to the security group.
  • Restored public HTTP access with one inbound rule while keeping SSH closed. Exported AWS-Cloud-Support-Case-Resolved.pdf as evidence of your investigation.
  • Secret Mission: Diagnosed an application-layer failure caused by stopped Apache. Restored the service using the same evidence-driven workflow.

Ready to quiz yourself?