Verify Amazon Linux 2023 on EC2

Launch, connect to, and verify an Amazon Linux 2023 EC2 instance.

Introduction

30 Second Summary

A green status light can suggest that a cloud machine is ready. Yet that machine can still be unreachable or running a different system than someone claims.

In this project, you will prove that a short-lived Amazon EC2 server is running Amazon Linux 2023. Your proof becomes a six-slide group presentation that explains the blocked EC2 Instance Connect session, the security fix, and the cleanup.

What You'll Build

Picture your group opening a browser terminal to a live Amazon Linux 2023 instance, showing the exact fields that prove its identity, then presenting the complete launch-to-cleanup story in three minutes.

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

  • A running EC2 lab where group-project-1-al2023 reaches the running state and displays Amazon Linux 2023 as its selected Amazon Machine Image.
  • A connection diagnosis that shows why a security group limited to My IP blocks the browser service path. You can then demonstrate the repaired connection from Windows.
  • A six-slide presentation pack with screenshots, speaker notes, cost controls, and machine-readable proof from /etc/os-release.
  • Secret Mission: Add an appendix that compares /etc/os-release, /etc/system-release, and /etc/image-id to defend why your verification method is reliable.

Are there any prerequisites?

You'll need AWS and NextWork accounts with permission to manage EC2 instances and security groups. The main path uses Windows browser access, so you do not need a local SSH client.

Before We Start

This is your group's chance to commit to a short-lived Amazon Linux 2023 demonstration on Amazon EC2. Clear machine-readable proof lets you support your operating-system claim with evidence.

Prepare the AWS and NextWork Workspace

Your group has agreed on the demonstration. You also know what proof it needs.

A region mismatch can hide the resources you expect to use. Missing permissions can block the Amazon EC2 launch wizard.

A missing default VPC leaves the lab without its expected network. This step aligns NextWork with the AWS Management Console before you create any EC2 resources.

In this step, get ready to:
  • Prepare the evidence workspace in NextWork and Windows.
  • Confirm access to the Amazon EC2 launch and security pages.
  • Verify that the default VPC is available in us-east-1.
Prepare the NextWork evidence workspace

A fixed naming sequence ties each screenshot to the stage it proves. The project stays open as your guide while Windows File Explorer becomes the evidence store.

  • Go to NextWork in your browser.
  • Select the generated project named Verify Amazon Linux 2023 on Amazon EC2.

The generated project is now open with the instructions your group follows during the lab.

  • Press the Windows key to open the Windows search bar.
  • Type File Explorer and press Enter to open it.
  • Select Desktop in the left navigation pane.
  • Right-click an empty area in the Desktop view.
  • Select New from the menu.
  • Select Folder.
  • Enter Group Project No. 1 Evidence as the folder name.

You will see Group Project No. 1 Evidence in the Desktop view. This folder keeps the presentation evidence in one place.

Use This Evidence Sequence

Use the following names when you save each screenshot later:

  • Use 01-instance-running for the running instance evidence.
  • Use 02-connection-failure for the controlled browser connection failure.
  • Use 03-security-group-fix for the repaired inbound rule.
  • Use 04-terminal-connected for the connected browser terminal.
  • Use 05-os-verification for the operating-system proof.
  • Use 06-cleanup for the final cleanup evidence.
Confirm EC2 access

The launch wizard checks whether your identity can start the lab. The Security Groups page checks whether your identity can manage the network boundary.

No EC2 instance is created during this check. You can resolve an access problem before the lab creates billable resources.

  • Go to the AWS Management Console in your browser.
  • Sign in with your instructor-approved AWS identity.
  • Choose US East (N. Virginia) from the region selector.

The console now uses us-east-1 as the working region.

  • Enter Amazon EC2 in the console search bar.
  • Select Amazon EC2 from the search results.
  • Select Launch instance from the EC2 Dashboard.

The launch wizard loads without an AccessDenied message. This proves that the launch controls are available.

  • Return to the EC2 Dashboard.
  • Select Security Groups from the left navigation pane.

The Security Groups page loads without an AccessDenied message. Your identity can reach the network controls needed later.

Seeing AccessDenied?

  • Stop before creating any EC2 resources.
  • Request EC2 launch permissions from your instructor or account administrator.
  • Request security-group management permissions from your instructor or account administrator.
  • Request termination permissions from your instructor or account administrator.
  • Request the ec2:DescribeInstances permission.
  • Request the ec2-instance-connect:SendSSHPublicKey permission.

A permission request is the safe path here. Help me explain this EC2 access problem to my account administrator.

Confirm the default VPC

An Amazon VPC provides the network where the test instance runs. The default VPC supplies the public network expected by this lab.

  • Enter Amazon VPC in the AWS Management Console search bar.
  • Select Amazon VPC from the search results.
  • Select Your VPCs from the left navigation pane.
  • Inspect the Default VPC column.

Choose the tab that matches what you see in the Default VPC column.

✔️ I see Yes

A row showing Yes confirms that the default VPC exists in us-east-1.

  • Return to the EC2 Dashboard through the console search bar.

ⓧ No row shows Yes

The selected region needs a default VPC before the lab can use its expected network.

  • Choose Actions on the Your VPCs page.
  • Choose Create Default VPC.
  • Choose Create.
  • Wait for the confirmation screen to close.
  • Return to Your VPCs.
  • Confirm that one row now shows Yes in the Default VPC column.
  • Return to the EC2 Dashboard through the console search bar.

The new row confirms that the default network is available in us-east-1.

Can't Create the Default VPC?

Stop if the creation control is unavailable or the request is denied. Ask your instructor or account administrator to create the default VPC in us-east-1 with an approved identity.

Do not switch regions to work around the permission problem. Help me diagnose why I cannot create the default VPC.

Before the final check, do you expect the region, network, and evidence workspace to agree?

  • Confirm that the EC2 Dashboard region selector shows US East (N. Virginia).
  • Open the Launch instance wizard.

The wizard loads without an access error.

  • Return to the EC2 Dashboard.
  • Open the Security Groups page from the left navigation pane.

The Security Groups page loads successfully.

  • Switch back to the NextWork browser tab.

The generated project remains open for your group.

  • Return to File Explorer.

You will see Group Project No. 1 Evidence in the Desktop view.

Workspace Checkpoint

  • A default VPC exists in us-east-1 and is available for the EC2 lab.
  • Windows evidence folder created with planned files: 01-instance-running, 02-connection-failure, 03-security-group-fix, 04-terminal-connected, 05-os-verification, and 06-cleanup.

Your workspace is ready for a controlled EC2 launch. Next, you will create the test instance. You will also capture the planned connection failure.

Launch the Amazon Linux Test Instance

Your AWS workspace is ready in US East (N. Virginia), us-east-1. The evidence folder is waiting for the lab's first result.

You can now use Amazon EC2 to launch the Amazon Linux 2023 server that anchors your demonstration. This server provides the first visible proof that the lab is taking shape.

A running state proves that the server exists. Browser administration through EC2 Instance Connect also depends on an SSH network path.

In this step, get ready to:
  • Choose the standard Amazon Linux 2023 launch configuration.
  • Configure controlled browser access for the instance.
  • Prove the server is healthy before testing browser reachability.
Choose the launch configuration

An Amazon Machine Image packages the operating system used to start an EC2 instance. The standard Amazon Linux 2023 image already includes the software required by EC2 Instance Connect.

  • Return to the Amazon EC2 Dashboard from earlier.
  • Choose Launch instance.

The launch wizard now shows the configuration sections for your new server.

  • Enter group-project-1-al2023 in the Name field.
  • Select Quick Start under Application and OS Images (Amazon Machine Image).

The instance name now appears in the launch summary. The image panel shows the Quick Start choices.

  • Choose Amazon Linux.
  • Select the standard Amazon Linux 2023 AMI.

The selected image panel now identifies the standard Amazon Linux 2023 AMI.

  • Select t3.micro under Instance type.

The launch summary now pairs the selected AMI with the t3.micro instance type.

Configure the temporary lab

A security group controls which sources can reach the instance. For this first test, its SSH rule accepts only My IP.

The default public subnet provides the route needed by browser access. An auto-assigned public IPv4 address gives the instance a reachable address.

  • Choose Proceed without a key pair (Not recommended) under Key pair (login).

Why proceed without a key pair?

The standard Amazon Linux 2023 AMI comes pre-installed with EC2 Instance Connect. The service supplies a temporary SSH public key for the browser session.

This approach keeps the lab focused on browser-based administration. You do not need to manage a private key on Windows.

  • Confirm the default VPC is selected under Network settings.
  • Select a default public subnet.

The network configuration now places the instance inside the default public network prepared earlier.

  • Leave Auto-assign public IP set to Enable.
  • Create a custom security group named group-project-1-eic-sg.

The wizard now shows a new security group for this instance. The public IPv4 setting remains enabled.

  • Set the inbound rule Type to SSH.
  • Set the inbound rule Source to My IP.

The rule now shows SSH on TCP port 22 from My IP. No rule allows 0.0.0.0/0.

The EBS root volume stores the operating system. Its deletion setting prevents that root volume from remaining after the instance is terminated.

  • Keep the AMI-provided root volume under Configure storage.
  • Open Advanced.

The advanced storage settings now show how the root volume behaves when the instance is terminated.

  • Confirm Delete on termination is set to Yes.

Launching starts usage

Launching starts compute usage. Public IPv4 usage begins too.

The root volume also begins accruing storage usage. Keep this temporary lab moving toward its cleanup evidence.

  • Choose Launch instance in the Summary panel.

Amazon EC2 begins provisioning group-project-1-al2023 with the settings you selected.

Run the launch verification

The instance lifecycle separates provisioning from a healthy running state. Status checks verify that AWS can support the instance before you test browser access.

The initial status checks can take a few minutes while Amazon EC2 verifies the instance.

  • Select Instances in the EC2 navigation.
  • Select group-project-1-al2023.
  • Wait until the instance state shows running.
  • Wait until the Status check column reports passed checks.

You have the lab's first live result: a healthy Amazon Linux 2023 server.

  • Capture a screenshot showing the instance name, running state, and passed status checks.
  • Save the screenshot in Group Project No. 1 Evidence as 01-instance-running.

The health evidence is complete. The next check tests browser reachability through the selected connection path.

  • Predict the answer to this question: does a running state guarantee that the browser can reach SSH.
  • Keep group-project-1-al2023 selected on the Instances page.
  • Choose Connect.
  • Select EC2 Instance Connect.
  • Select Connect using a Public IP.
  • Confirm Username displays ec2-user.
  • Choose Connect.

The browser connection fails before a terminal opens. This is the intended shortfall in the current network rule.

  • Capture the failed browser connection attempt.
  • Save the screenshot in Group Project No. 1 Evidence as 02-connection-failure.

Why did the connection fail?

My IP is the public IPv4 address of your Windows computer. The browser session reaches the instance from the EC2 Instance Connect service.

The security group admits only the local address. It therefore blocks the service path even though the instance is healthy.

Did a terminal open instead?

  • Select the attached group-project-1-eic-sg security group from the instance details.
  • Confirm its inbound SSH rule uses My IP as the source.
  • Remove any extra SSH rule that allows 0.0.0.0/0.
  • Retry the browser connection through EC2 Instance Connect.

The connection should now fail before the terminal opens. Help me diagnose an unexpected successful connection.

Your healthy instance has exposed a precise network boundary. Next, you'll repair that path so the browser terminal can open.

Fix the Connection Path

Your healthy Amazon EC2 instance exposed a network boundary in the previous step. Its security group accepts SSH from your Windows computer's public address.

EC2 Instance Connect reaches the instance from the AWS service. Replacing My IP with the regional AWS-managed prefix list aligns the inbound rule with that connection path.

In this step, get ready to:
  • Delete the mismatched My IP SSH rule.
  • Allow SSH from the regional EC2 Instance Connect prefix list.
  • Open the browser terminal as ec2-user.
Replace the local SSH source

A My IP rule stores your local address as an IPv4 CIDR source. The AWS-managed prefix list uses a different source type.

AWS requires a new rule when the source type changes. This keeps the firewall limited to the intended service path on port 22.

  • Choose Security Groups in the Amazon EC2 navigation pane.
  • Select group-project-1-eic-sg.
  • Choose Actions.
  • Choose Edit inbound rules.
  • Choose Delete beside the existing SSH rule whose source is My IP.

Why delete the old rule?

AWS does not convert an existing IPv4 CIDR source into a prefix-list source. Deleting the old row lets you create the replacement with the correct source type.

  • Choose Add rule.
  • Set Type to SSH.
  • Set Source to Custom.
  • Select com.amazonaws.us-east-1.ec2-instance-connect as the AWS-managed prefix list.
  • Choose Save rules.

You'll see an SSH rule on TCP port 22 with com.amazonaws.us-east-1.ec2-instance-connect as its source. The previous My IP row is no longer listed.

That closes the network gap behind the failed browser connection.

Can't find the managed prefix list?

  • Confirm the console region is US East (N. Virginia).
  • Set Source to Custom.
  • Search for com.amazonaws.us-east-1.ec2-instance-connect.

Do not replace the prefix list with 0.0.0.0/0. Help me find the EC2 Instance Connect prefix list.

  • Capture the saved inbound rule in a screenshot.
  • Save the screenshot in the Group Project No. 1 Evidence folder as 03-security-group-fix.
Open the browser terminal

The prefix-list rule now permits the AWS service path. Your AWS identity still controls whether the console can send the temporary connection key.

The console uses ec2-user as the default username for the standard Amazon Linux 2023 AMI.

  • Return to Instances from the Amazon EC2 navigation pane.
  • Select group-project-1-al2023.
  • Choose Connect.
  • Choose EC2 Instance Connect.
  • Choose Connect using a Public IP.
  • Enter ec2-user in the Username field.

Before you choose Connect, predict whether the browser terminal will open with the repaired source rule.

  • Choose Connect.

You'll see an in-browser terminal with a prompt for ec2-user. The terminal is ready to accept Linux commands.

You have repaired the exact network boundary that blocked the first attempt.

Seeing an authorization error?

  • Keep the SSH source limited to com.amazonaws.us-east-1.ec2-instance-connect.
  • Ask the account administrator to verify ec2-instance-connect:SendSSHPublicKey permission.
  • Ask the account administrator to verify ec2:DescribeInstances permission.

Do not broaden the security group to 0.0.0.0/0. Help me diagnose this EC2 Instance Connect authorization error.

  • Capture the connected browser terminal with the ec2-user prompt visible.
  • Save the screenshot in the Group Project No. 1 Evidence folder as 04-terminal-connected.

Your browser terminal is ready. Next, you'll use machine-readable fields to prove that the instance runs Amazon Linux 2023.

Verify the Operating System

Your EC2 Instance Connect session proves that the instance is reachable from the browser. Reachability alone does not identify the Linux release.

Your presentation needs evidence that the running system uses Amazon Linux 2023. You will begin with a familiar Linux release tool before comparing its result with the system identity data.

In this step, get ready to:
  • Test a familiar Linux release command.
  • Gather machine-readable operating system identity evidence.
  • Save the verification screenshot with an evidence caption.
Check the familiar release tool

Linux images do not all include the same convenience tools. Testing a familiar interface reveals what this image supports.

Before you run it, predict whether this image includes the familiar release tool.

  • Ask the running system for its release details by entering this command:
lsb_release

Why is the command unavailable?

  • The unavailable command is the intended result on Amazon Linux 2023.
  • AWS does not ship lsb_release or system-lsb-core with this release.
  • This result tests command availability. It does not prove the operating system identity by itself.
  • Keep the unavailable result visible in the browser terminal for the supported check that follows.
Use the standard identity source

The /etc/os-release file provides standard machine-readable operating system identity fields. It also includes display text suitable for your presentation.

Before you run the check, predict which fields should carry the strongest verification evidence.

  • Read the standard identity file in the browser terminal from earlier by running this command:
cat /etc/os-release

What does this evidence show?

  • The /etc/os-release file is the standard source for operating system identification.
  • PRETTY_NAME provides a human-readable name for presentation slides.
  • ID="amzn" identifies Amazon Linux.
  • VERSION_ID="2023" identifies the major operating system version.
  • Locate ID="amzn" in the terminal output.
  • Locate VERSION_ID="2023" in the terminal output.
  • Locate PRETTY_NAME for the installed point release.

You should see both machine-readable fields in the output. Together, they verify that the running instance uses Amazon Linux 2023.

Missing a verification field?

  • Repeat the identity-file check above to rule out a typing mistake.
  • Confirm the browser tab is still the terminal for group-project-1-al2023.

If the expected fields remain missing, help me diagnose the operating system identity output.

Preserve the verification evidence

Your evidence should show the unsuccessful legacy check beside the supported identity fields. This makes the verification method clear without relying on the AMI label alone.

  • Keep the lsb_release result visible above the standard identity-file output.
  • Use your Windows screenshot tool to capture both terminal checks with their relevant outputs.
  • Save the image in the Group Project No. 1 Evidence folder as 05-os-verification.
  • Switch back to the NextWork project from earlier.
  • Add 05-os-verification to your project notes.
  • Place the following caption beneath the image:

The machine-readable fields ID="amzn" plus VERSION_ID="2023" prove Amazon Linux 2023. The longer PRETTY_NAME value identifies the installed point release.

Before you inspect the saved image, predict which details should make the proof defensible.

  • Return to the Group Project No. 1 Evidence folder from earlier.
  • Open 05-os-verification.
  • Confirm the image includes both terminal checks.
  • Confirm the image shows that lsb_release is unavailable.
  • Confirm the image clearly shows ID="amzn" plus VERSION_ID="2023".
  • Confirm the caption explains the role of PRETTY_NAME.

Strong work. Your saved evidence now proves the operating system family plus its major version from inside the running instance.

Your operating system proof is ready. Next, you will turn the launch story, connection diagnosis, and verification evidence into the group presentation pack.

Build the Group Presentation Pack

Your saved terminal evidence now proves that the running system is Amazon Linux 2023. The NextWork project from earlier is ready to become your group’s presentation workspace.

Screenshots alone do not explain the technical decisions behind the launch, failure, and fix. This step turns the Amazon EC2 lab into a six-slide problem-to-solution story that your group can present confidently.

In this step, get ready to:
  • Draft a six-slide script that connects each technical claim to evidence.
  • Assign the three presenters to adjacent slide pairs.
  • Review the screenshots before rehearsing the complete presentation.
Draft the six-slide script

A clear technical presentation follows cause and effect. Your six slides move from the launch configuration to the connection problem, the fix, the operating system proof, and the cleanup plan.

  • Use the project notes in the NextWork project from earlier or your existing class presentation document as the home for the script.
  • Build the six-slide script using the content in the three reference tabs below.

Slides 1 and 2

Slide 1: Group Project No. 1 - Amazon Linux 2023 on EC2.

  • Goal: Launch, connect to, identify, and clean up a cloud Linux server.
  • Result: A verified Amazon Linux 2023 instance administered from a Windows browser.

Speaker note: EC2 did not require a manual ISO installation. We selected an Amazon Machine Image that already contained the operating system.

Slide 2: What We Built.

  • Flow: A Windows browser reaches the AWS Management Console.
  • Connection: EC2 Instance Connect reaches the instance through its public IPv4 address.
  • Protection: The security group controls which traffic reaches the Amazon Linux 2023 instance.
  • Evidence: Use 01-instance-running.

Speaker note: The instance ran inside the default VPC. EC2 Instance Connect supplied browser-based SSH access without a locally managed private key on Windows.

Slides 3 and 4

Slide 3: Launch Configuration.

  • Region: US East (N. Virginia), us-east-1.
  • AMI: Standard Amazon Linux 2023 AMI.
  • Instance type: t3.micro.
  • Network: Default VPC with public IPv4 enabled.
  • Storage: AMI-provided root volume with Delete on termination set to Yes.
  • Access control: Custom security group named group-project-1-eic-sg.

Speaker note: We used a small instance with the AMI-provided root volume. This kept the temporary lab within the group’s planned budget of less than $1.

Slide 4: The Connection Problem and Fix.

  • Initial result: The instance was running, but the browser terminal could not connect.
  • Cause: My IP identifies the Windows computer’s public IPv4 address. Browser-based EC2 Instance Connect traffic comes from the AWS service.
  • Fix: Allow port 22 from the AWS-managed prefix list named com.amazonaws.us-east-1.ec2-instance-connect.
  • Evidence: Use 02-connection-failure, 03-security-group-fix, and 04-terminal-connected.

Speaker note: The failed connection separated instance health from network reachability. A running server can remain unreachable when its firewall source does not match the connection path.

Slides 5 and 6

Slide 5: Operating System Verification.

  • Unsupported path: lsb_release is not shipped with Amazon Linux 2023.
  • Supported check: Inspect /etc/os-release with cat.
  • Proof: ID="amzn" identifies Amazon Linux.
  • Version proof: VERSION_ID="2023" identifies the major release.
  • Evidence: Use 05-os-verification.

Speaker note: We used machine-readable fields as the verification proof. We reserved PRETTY_NAME for the human-readable point release.

Slide 6: Security, Cost, and Cleanup.

  • Security: No SSH rule allows traffic from 0.0.0.0/0.
  • Access: EC2 Instance Connect uses a temporary public key without a separate service charge.
  • Compute cost: One Linux t3.micro costs $0.0104 per hour in US East (N. Virginia).
  • Address cost: One public IPv4 address costs $0.005 per hour.
  • Additional costs: Amazon EBS storage, data transfer, credits, and taxes can change the final amount.
  • Cleanup: Terminate the instance, confirm root-volume deletion, and delete group-project-1-eic-sg.
  • Evidence: Reserve 06-cleanup for the cleanup confirmation.

Speaker note: Termination is part of the technical solution. Unused cloud resources can continue generating charges.

  • Save the six-slide presentation script.
  • Confirm the script contains slide titles, evidence references, and speaker notes for all six slides.

That is the story assembled. Your evidence now has a clear launch, obstacle, fix, proof, and cleanup arc.

Assign the speaking roles

Adjacent slide pairs keep each presenter’s section connected. The handoffs occur when the story moves from architecture to troubleshooting, then from troubleshooting to verification.

Speaking assignments

  • Presenter 1: Slides 1 and 2.
  • Presenter 2: Slides 3 and 4.
  • Presenter 3: Slides 5 and 6.
  • Adapt only adjacent slide pairs if your group size differs.
  • Keep the six-slide story order unchanged.
  • Add the three presenter assignments to the presentation script.
  • Save the updated presentation script.

Each slide now has a clear owner. Presenter 1 covers the goal and architecture, Presenter 2 covers the launch and connection fix, and Presenter 3 covers verification and cleanup.

Review the evidence and rehearse

Presentation evidence must stay readable without exposing unrelated account information. Each screenshot should support one claim while keeping the important AWS labels visible.

  • Return to Group Project No. 1 Evidence in Windows File Explorer.
  • Review 01-instance-running through 05-os-verification for readable labels.

The five saved images should clearly show the running instance, failed connection, repaired rule, connected terminal, and operating system proof.

  • Crop unrelated account information from each screenshot.
  • Retain the instance name, AMI label, security-group rule, terminal prompt, and operating system fields.

Each image now focuses on the evidence your group discusses. Unrelated console details no longer compete with the technical claim.

  • Save the reviewed screenshots in Group Project No. 1 Evidence.
  • Confirm the images do not expose an AWS account ID or another class member’s identifier.

Before you rehearse, which technical claim do you expect will be hardest to support within three minutes?

  • Use a timer to rehearse all six slides in three minutes.
  • Trace every technical claim to one of the five saved evidence images or an AWS source listed in the project research.

You finish the six-slide story within three minutes. Every technical claim points to saved evidence or an AWS source.

Rehearsal running over three minutes?

  • Remove repeated explanations while keeping each evidence reference.
  • Keep each speaker note focused on one decision or proof point.
  • Ask for help tightening the script without removing technical evidence. Help me shorten this six-slide EC2 presentation while preserving its evidence and technical accuracy.

Strong finish. Your group now has a presentation-ready account of the launch, controlled failure, network fix, operating system proof, cost controls, and cleanup plan.

Secret mission

Defend Your Verification Method

Cross-check your operating system evidence with Amazon Linux release data and image metadata. You will add an appendix that explains why each source carries a different level of authority.

Clean Up Your Resources

Clean Up Your Resources

Your Amazon EC2 lab has produced all of its evidence. The remaining choice is to keep it running for an immediate demonstration, stop it for a later return, or delete it entirely.

Cost warning

The Linux t3.micro compute rate in US East (N. Virginia) starts at $0.0104 per hour. The in-use public IPv4 address adds $0.005 per hour.

Your Amazon EBS storage can increase the total cost. Stopping the instance pauses compute usage while its root volume remains available.

Deletion is the recommended option once your screenshots and presentation are complete. This closes the temporary lab before further usage accumulates.

Resources you used:

  • One running Amazon Linux 2023 t3.micro EC2 instance named group-project-1-al2023 with an assigned public IPv4 address.
  • One attached EBS root volume with Delete on termination set to Yes.
  • One custom security group named group-project-1-eic-sg.
  • One Windows evidence folder named Group Project No. 1 Evidence.
  • One presentation script containing six main slides plus the verification-method appendix.

Keep everything running

No action is needed during an immediate live demonstration. This option is temporary and should end within the one-hour lab window.

  • Keep group-project-1-al2023 running only while your group needs the live demonstration.
  • Open Billing and Cost Management in the AWS Management Console.
  • Review the current charges attributed to the temporary lab.
  • Set a reminder for the end of the one-hour lab window.
  • Leave Group Project No. 1 Evidence in its current Windows location.
  • Keep the six-slide script plus its appendix available for your presentation.

Pause - I'll come back to this later

Stopping preserves the instance configuration for a later demonstration. The EBS root volume remains available and can continue incurring storage charges.

  • Return to Instances in the EC2 console.
  • Select group-project-1-al2023.
  • Choose Instance state.
  • Choose Stop instance.
  • Choose Stop in the confirmation dialog.
  • Wait until the instance state changes to stopped.
  • Keep the evidence folder and presentation script available for your return.

You'll see group-project-1-al2023 in the stopped state. Its attached root volume remains in your account.

Delete - I don't want to use this again

Termination is permanent. Your saved evidence stays available until you remove the local folder and presentation files later in this tab.

Terminate the EC2 instance:

  • Confirm the existing screenshots are saved in Group Project No. 1 Evidence.
  • Return to Instances in the EC2 console.
  • Select group-project-1-al2023.
  • Choose Instance state.
  • Choose Terminate (delete) instance.
  • Choose Terminate (delete) in the confirmation dialog.
  • Wait until the instance state changes to terminated.

You'll see the instance move through shutting-down before it reaches terminated. Because Delete on termination is set to Yes, termination also deletes the attached root volume.

Delete the custom security group:

  • Open Security Groups in the EC2 console.
  • Select group-project-1-eic-sg.
  • Choose Actions.
  • Choose Delete security groups.
  • Enter Delete if the confirmation dialog requests it.
  • Choose Delete.
  • Confirm that group-project-1-eic-sg no longer appears on the Security Groups page.
  • Capture the terminated instance view or successful security-group deletion as 06-cleanup.
  • Save 06-cleanup in Group Project No. 1 Evidence.

That is the risky cloud cleanup finished. Your temporary lab no longer has its EC2 instance, attached root volume, or custom security group.

Remove the presentation script:

  • Delete the six-slide presentation script from the NextWork notes or class presentation document where your group saved it.
  • Confirm that the six slides and verification-method appendix no longer appear there.

Remove the Windows evidence folder:

  • Return to the Windows location that contains Group Project No. 1 Evidence.
  • Select Group Project No. 1 Evidence in File Explorer.
  • Choose Delete from the folder's context menu.
  • Open Recycle Bin in Windows.
  • Select Group Project No. 1 Evidence in Recycle Bin.
  • Choose Delete to remove the folder permanently.
  • Complete the permanent-deletion confirmation.

Nice Work!

Nice Work!

You did it! Your group built a presentation-ready Amazon Linux 2023 lab on Amazon EC2.

You've learned how to:

  • Launch an Amazon Linux 2023 instance from an AMI. Administer it from Windows through browser-based EC2 Instance Connect.
  • Diagnose a connection failure caused by the difference between a local My IP rule and the EC2 Instance Connect service path. Restore access with the regional AWS-managed prefix list.
  • Prove the operating system version with machine-readable evidence from /etc/os-release. Present the launch-to-cleanup story through a six-slide script with screenshots and speaker notes.
  • Secret Mission: Defend your verification method with an appendix that separates standard OS identity from Amazon Linux release and image metadata.

Ready to quiz yourself?