Launch Your First AWS Web Server

Launch an EC2 web server, diagnose blocked HTTP, and secure access to your IP.

Introduction

30 Second Summary

A website can be running perfectly while every visitor still sees a blank browser tab. The missing piece is often the path between the visitor and the server.

In this project, you will launch a Linux web server on Amazon EC2. You will trace a deliberate connection failure before securing the working site.

What You'll Build

Your finished server responds in Microsoft Edge with a custom page that proves your AWS network path is working.

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

  • A live web page that displays “Hello from my first AWS web server” from your own cloud server.
  • A browser test that proves a healthy server can remain unreachable until a security group allows HTTP traffic.
  • A stop-and-start recovery that brings the same page back at a newly assigned public IPv4 address.
  • Secret Mission: Replace public HTTP access with a rule that allows only your current public IPv4 address.

Are there any prerequisites?

This project requires a personal AWS account with billing enabled plus a Windows computer. The account must have root-user MFA configured with a non-root administrative identity for everyday work.

The project is estimated to cost under $0.05 when you delete the resources after about one hour.

Before We Start

This is your moment to lock in what you are building and why the first browser test is designed to fail. You will launch an Amazon EC2 web server with no inbound HTTP security group rule, so the failed request becomes evidence you can diagnose.

Set Up a Safe AWS Workspace

A personal AWS account controls real cloud resources. Protecting its most powerful identity keeps one mistake from exposing the entire account.

Multi-factor authentication (MFA) protects the root user. AWS IAM Identity Center gives you a separate administrative identity for daily work.

You will also fix one AWS Region for the project. You will finish with the Amazon EC2 console ready for the web server.

In this step, get ready to:
  • Confirm root-user MFA plus a non-root administrative identity.
  • Enter the AWS Management Console through the non-root identity.
  • Confirm the project Region plus the default VPC.
Confirm your security baseline

The root user has unrestricted access to the account. AWS recommends keeping it out of everyday work.

Your normal console session needs an administrative identity from IAM Identity Center. Choose the path that matches your account.

  • Select the tab that describes your current security setup.

✔️ Root MFA and an admin identity are ready

Use this path when root-user MFA is already active. Your IAM Identity Center administrative user must also have access to the AWS account.

  • Open the AWS access portal from your IAM Identity Center invitation or saved portal link.
  • Sign in with your IAM Identity Center administrative user.
  • Use the assigned account entry to open the AWS Management Console.
  • Choose your account name on the console navigation bar.
  • Confirm the menu identifies your administrative user.
  • Confirm the menu does not identify the session as Root user.

Your daily administrative session is separate from the root user. That separation keeps the account owner credentials out of the project workflow.

ⓧ Root MFA or an admin identity is missing

This path briefly uses the root user to protect the account. You will leave that session as soon as the administrative identity is ready.

  • Sign in to the AWS Management Console by choosing Root user.
  • Choose your account name on the right side of the navigation bar.
  • Choose Security credentials.
  • Find the Multi-factor authentication (MFA) section.
  • Choose Assign MFA device if no MFA device is listed.
  • Enter a name that identifies your authenticator in the Device name field.
  • Choose Authenticator app.
  • Choose Next.

Keep the MFA setup private

The MFA setup screen contains a secret configuration key. Keep the QR code plus the secret key out of screenshots or shared messages.

  • Choose Show QR code.
  • Scan the QR code with your authenticator app.
  • Enter the current code in the MFA code 1 field.
  • Wait up to 30 seconds for a new code.
  • Enter the new code in the MFA code 2 field.
  • Choose Add MFA.

The root user now requires a second factor at sign-in. That closes the most important account-security gap.

  • Choose the Regions selector in the navigation bar.
  • Choose US East (N. Virginia).
  • Use the console search bar to search for IAM Identity Center.
  • Select IAM Identity Center from the results.
  • Choose Enable under Enable IAM Identity Center.
  • Choose Create AWS organization if AWS asks to create an organization.
  • Open the AWS Organizations verification email if AWS sends one.
  • Use the email link to verify the account email address.

IAM Identity Center can now manage a workforce identity for the account. The next actions create that identity.

  • Choose Users in the IAM Identity Center navigation pane.
  • Choose Add user.
  • Enter your admin username in the Username field.
  • Keep Send an email to this user with password setup instructions selected.
  • Enter your admin email address in the Email address field.
  • Enter your admin email address in the Confirm email address field.
  • Enter your first name in the First name field.
  • Enter your last name in the Last name field.
  • Choose Next.
  • Choose Next without adding a group.
  • Choose Add user.

The user exists in the Identity Center directory. It still needs an account assignment before it can manage EC2.

  • Choose AWS accounts in the navigation pane.
  • Select the checkbox beside your AWS account.
  • Choose Assign users or groups.
  • Choose the Users tab.
  • Select the checkbox beside your admin username.
  • Choose Next.
  • Choose Create permission set.
  • Create the AdministratorAccess predefined permission set.

The permission set defines what the identity can do in the account. This project uses administrative access because you need to launch EC2 resources plus manage their networking.

  • Return to the Assign users and groups browser tab.
  • Choose the refresh icon beside Create permission set.
  • Select the checkbox beside AdministratorAccess.
  • Choose Next.
  • Choose Submit.

The administrative identity now has access to the account. Finish by activating its credentials outside the root session.

  • End the root-user console session.
  • Open the invitation sent to your admin email address.
  • Find the email with the subject Invitation to join AWS IAM Identity Center.
  • Use the invitation link to register a password.
  • Sign in to the AWS access portal as your admin username.
  • Use the assigned account entry to open the AWS Management Console.
  • Choose your account name on the console navigation bar.
  • Confirm the menu identifies your administrative user instead of the root user.

That is the sensitive setup complete. Your root user has MFA protection plus your daily work now uses a separate identity.

Having trouble with account access?

Check the junk folder if the IAM Identity Center invitation has not arrived. Confirm that the email address on the user matches the inbox you are checking.

If your user can enter the access portal but cannot open the account, return to the root session. Confirm that the user has the AdministratorAccess permission set assignment.

Keep passwords plus MFA codes out of any help request. Help me diagnose my IAM Identity Center access problem.

Choose the working Region

EC2 resources belong to a specific Region. Fixing the project to one Region prevents the server from appearing to disappear when the console changes location.

  • Choose your account name on the console navigation bar.
  • Confirm the menu identifies your IAM Identity Center administrative user.
  • Close the account menu.
  • Choose the Regions selector in the navigation bar.
  • Choose US East (N. Virginia).
  • Confirm the Regions selector displays US East (N. Virginia).

Why does the Region matter?

The Region code for US East (N. Virginia) is us-east-1. The instance plus its network resources must stay in this Region so you can find them throughout the project.

Confirm Amazon EC2 and the default VPC

An Amazon VPC is the virtual network that holds your server. A default VPC provides the network foundation for the first EC2 instance.

  • Use the console search bar to search for EC2.
  • Select Amazon EC2 from the search results.
  • Confirm the EC2 dashboard loads in US East (N. Virginia).
  • Use the console search bar to search for VPC.
  • Select Amazon VPC from the search results.
  • Choose Your VPCs in the navigation pane.
  • Find the row whose Default VPC column shows Yes.

The row confirms that a default VPC is available in the selected Region. The launch wizard can use it in the next step.

  • Use the console search bar to search for EC2.
  • Select Amazon EC2 to return to its dashboard.

Before the final check, do you expect the console to show the root user or your IAM Identity Center administrative user?

  • Choose your account name on the console navigation bar.
  • Confirm the menu identifies your non-root administrative user.
  • Close the account menu.
  • Choose the Regions selector.
  • Confirm the selected Region is US East (N. Virginia).
  • Close the Regions selector.
  • Confirm the Amazon EC2 dashboard remains open.

Your safe workspace is ready. The console now uses a protected non-root identity in the correct Region with a default VPC available.

Your account is protected plus your EC2 workspace is in place. Next, you will launch a healthy web server with its HTTP path deliberately blocked.

Launch a Blocked Web Server

Your AWS workspace now uses a non-root identity in US East (N. Virginia). The Region is fixed to us-east-1.

A healthy server can still be unreachable when its network path is closed. This step lets you see that separation directly.

In this step, Amazon EC2 runs an Amazon Linux 2023 virtual machine. cloud-init installs Apache HTTP Server during the first boot.

The attached security group will have no inbound rules. You will compare the instance's health with the result from a browser request.

In this step, get ready to:
  • Configure an Amazon Linux 2023 instance with a t3.micro instance type.
  • Create an EC2 key pair plus a security group with no inbound rules.
  • Bootstrap Apache with user data before testing the blocked browser request.
Configure the instance

An AMI supplies the operating system for an EC2 instance. The instance type controls the compute capacity assigned to it.

  • In the EC2 dashboard from earlier, choose Launch instance.
  • In Name and tags, enter nw-first-web-server as the instance name.

The wizard's summary now identifies the server as nw-first-web-server.

  • In Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI from Amazon Linux under Quick Start.
  • In Instance type, select t3.micro.

The summary now shows Amazon Linux 2023 with the t3.micro instance type.

The downloaded private key can be used to access the server. Treat this file like a credential.

  • In Key pair (login), choose Create new key pair.
  • Enter nw-first-web-server-key in the Key pair name field.

The key pair dialog now shows the project-specific key name.

  • Keep the default key pair settings.
  • Choose Create key pair.

Your browser downloads the private key file. That sensitive access file now exists on your Windows computer.

  • Keep the downloaded private key file in your Downloads folder.
Prepare the blocked server

The network settings connect the instance to the default VPC. They also control whether the instance receives a public IPv4 address.

  • Under Network settings, choose Edit.
  • Keep the VPC set to the default VPC confirmed earlier.
  • Keep Auto-assign public IP enabled.

The network summary now shows the default VPC with an auto-assigned public IPv4 address.

  • Select Create security group.
  • Enter nw-first-web-server-sg as the security group name.

The wizard now associates the new security group name with this instance.

  • Remove the automatically suggested SSH inbound rule.
  • Confirm that the inbound rules list is empty.

The security group now has no inbound rules. Its default outbound rule remains unchanged.

What is a security group?

A security group acts as a virtual firewall for an EC2 instance. Its rules control incoming traffic plus outgoing traffic.

A new security group has no inbound rules by default. It also has a default rule that allows outbound traffic.

The AMI's default EBS root volume stores the operating system plus the website files. The launch wizard already supplies the required root storage.

  • Leave Configure storage unchanged.

The instance now keeps the AMI's default root storage configuration.

EC2 user data supplies first-boot instructions to cloud-init. This configuration installs Apache before writing your custom page.

  • Expand Advanced details.

The User data field is now available near the bottom of the wizard.

  • Paste this configuration into the User data field:
#cloud-config
package_update: true

packages:
  - httpd

runcmd:
  - systemctl start httpd
  - systemctl enable httpd
  - [ sh, -c, 'echo "<!doctype html><html lang=\"en\"><head><meta charset=\"utf-8\"><meta name=\"viewport\" content=\"width=device-width,initial-scale=1\"><title>My First AWS Web Server</title></head><body style=\"font-family:Arial,sans-serif;max-width:720px;margin:80px auto;padding:24px;background:#f4f7fb;color:#172033\"><main style=\"background:white;padding:40px;border-radius:16px;box-shadow:0 12px 32px rgba(0,0,0,.12)\"><h1>Hello from my first AWS web server</h1><p>This page is running on Amazon EC2 with Amazon Linux 2023 and Apache HTTP Server.</p><p>I reached it through an explicit security group rule on TCP port 80.</p></main></body></html>" > /var/www/html/index.html' ]

What does this configuration do?

  • The #cloud-config header tells EC2 to process the content as cloud-init configuration.
  • The package_update setting refreshes the available package information.
  • The packages section installs httpd from the Amazon Linux repository.
  • The systemctl start httpd command starts Apache during the first boot.
  • The systemctl enable httpd command configures Apache to start during later boots.
  • The final command writes the custom page to /var/www/html/index.html.
  • Confirm that the first line is #cloud-config.
  • Confirm that the final line writes the page to /var/www/html/index.html.

User data looks different?

  • Compare the indentation under packages with the reference below.
  • Compare the indentation under runcmd with the reference below.

Use this if the configuration still looks wrong: Help me compare my EC2 user data with the required cloud-init configuration..

✔️ Awesome, I've got everything!

Your user data matches the required cloud-init configuration. The server is ready to launch.

ⓧ I'd like to double check the full code

#cloud-config
package_update: true

packages:
  - httpd

runcmd:
  - systemctl start httpd
  - systemctl enable httpd
  - [ sh, -c, 'echo "<!doctype html><html lang=\"en\"><head><meta charset=\"utf-8\"><meta name=\"viewport\" content=\"width=device-width,initial-scale=1\"><title>My First AWS Web Server</title></head><body style=\"font-family:Arial,sans-serif;max-width:720px;margin:80px auto;padding:24px;background:#f4f7fb;color:#172033\"><main style=\"background:white;padding:40px;border-radius:16px;box-shadow:0 12px 32px rgba(0,0,0,.12)\"><h1>Hello from my first AWS web server</h1><p>This page is running on Amazon EC2 with Amazon Linux 2023 and Apache HTTP Server.</p><p>I reached it through an explicit security group rule on TCP port 80.</p></main></body></html>" > /var/www/html/index.html' ]

Launching the instance starts usage-based billing. The full project is estimated to cost under $0.05 when its resources run for about one hour before cleanup.

  • In the wizard's Summary section, choose Launch instance.

The console confirms that the instance launch has started. EC2 is now creating the server plus its attached resources.

  • Choose Instances in the EC2 navigation pane.

Launch not starting?

  • Review the Summary section for a missing required field.
  • Confirm that the console still shows US East (N. Virginia).
  • Confirm that nw-first-web-server-key is selected under Key pair (login).

Use this if the launch remains blocked: Help me identify which EC2 launch setting is incomplete..

Test the blocked server

EC2 status checks measure whether the instance is healthy from an infrastructure perspective. The browser test answers a separate question about network reachability.

First boot can take a few extra minutes while cloud-init installs Apache. A pending status check during this wait is normal.

  • Find nw-first-web-server in the Instances table.
  • Wait until Instance state shows Running.
  • Wait until Status check shows 2/2 checks passed.

That is the compute side confirmed. Your EC2 instance is running with both infrastructure checks passing.

The instance details provide the identifiers you need for later checks. Record each value while the healthy instance is selected.

  • Select the checkbox beside nw-first-web-server.
  • In the Details tab, record the Instance ID here: your instance ID.
  • Record the Public IPv4 address here: your instance's public IPv4 address.
  • Choose the Security tab.
  • Record the attached security group ID here: your security group ID.
  • Confirm that Inbound rules is empty.
  • Confirm that Outbound rules retains the default outbound rule.
  • Press the Windows key to open Windows search.
  • Type Microsoft Edge into the search field.
  • Press Enter to open the browser.

Before you try the address, do you think a healthy instance guarantees that its web page will load?

  • Click the address bar in Microsoft Edge.
  • Enter http:// followed by your instance's public IPv4 address.
  • Press Enter to send the request.

Microsoft Edge cannot load the page. That failure is intentional.

The EC2 status checks proved that the instance is healthy. The HTTP request is still blocked because the security group has no inbound rule for TCP port 80.

Did the page load unexpectedly?

  • Switch back to the EC2 console from earlier.
  • Open nw-first-web-server-sg from the instance's Security tab.
  • Remove every inbound rule from the security group.
  • Save the rule changes.
  • Return to Microsoft Edge.
  • Refresh the page.

The page should become unreachable once the attached security group has no inbound rules.

Use this if the page still loads: Help me determine why my EC2 page remains reachable with no inbound security group rules..

Your server is healthy while its web path remains blocked. Next, you will change one network control and watch the custom page become reachable.

Open the Web Path

Your Amazon EC2 instance passed both status checks. The failed browser request proved that a healthy server can still be unreachable.

The missing control is an inbound HTTP rule on the security group. You will add it to open the browser request path.

In this step, get ready to:
  • Open the inbound rules for the attached security group.
  • Allow public HTTP traffic on TCP port 80.
  • Refresh the browser to verify the complete request path.
Open the attached security group

The attached security group acts as the virtual firewall for your instance. Its empty inbound rule list is the exact reason the browser request stopped.

  • In the Amazon EC2 console from earlier, choose Instances from the left navigation pane.
  • Select the nw-first-web-server instance.
  • Open the Security tab.
  • Select the nw-first-web-server-sg security group link.
  • Open the Inbound rules tab.
  • Choose Edit inbound rules.

You will see no existing inbound entries. This confirms that the security group is still blocking every request initiated from the internet.

Allow inbound HTTP traffic

This change exposes only web traffic on TCP port 80. Every other inbound port stays closed.

Choosing the predefined HTTP type fills the protocol automatically. It also fills the port range.

  • Choose Add rule.
  • Set Type to HTTP.
  • Confirm Protocol shows TCP.
  • Confirm Port range shows 80.
  • Set Source to Anywhere-IPv4.
  • Choose Save rules.

You will see one inbound HTTP rule for TCP port 80 from 0.0.0.0/0. The change applies automatically to the attached instance.

What does Anywhere-IPv4 mean?

Anywhere-IPv4 represents 0.0.0.0/0. It permits any IPv4 address to send traffic to the selected port.

Verify the complete request path

Before you refresh, do you expect the same failed request or the custom page this time?

  • Switch back to the failed page in Microsoft Edge.
  • Refresh the page.

You have opened the missing path. You will see the heading Hello from my first AWS web server.

Below the heading, you will see This page is running on Amazon EC2 with Amazon Linux 2023 and Apache HTTP Server.

How does the request reach the page?

  • Microsoft Edge sends an HTTP request to the instance's public IPv4 address.
  • The security group accepts TCP traffic on port 80 from Anywhere-IPv4.
  • The Apache HTTP Server receives the accepted request.
  • The /var/www/html/index.html file supplies the page shown in the browser.

Page still not loading?

  • Confirm the page address uses http:// with the instance's current public IPv4 address.
  • Confirm nw-first-web-server-sg is still attached to nw-first-web-server.
  • Confirm the inbound rule shows HTTP on port 80 from Anywhere-IPv4.

Help me diagnose why my EC2 web page still does not load after adding the HTTP security group rule.

Your blocked server is now a reachable website. Next, you will stop and start the instance to discover what persists when its public address changes.

Stop, Start, and Find the Server

Your Amazon EC2 web server now loads in Microsoft Edge through the inbound HTTP rule. The next test shows what survives when you pause the server.

Stopping an EBS-backed instance pauses compute usage charges while its root volume remains stored. AWS releases its auto-assigned public IPv4 address, so the restarted server must be found again.

In this step, get ready to:
  • Record the server's current public IPv4 address.
  • Complete a stop and start cycle for the same EC2 instance.
  • Recover the persisted website at its newly assigned public IPv4 address.
Stop the instance

The stop control can feel risky, although your EBS-backed server remains available for the later start. First, capture the current address as your comparison point.

  • Return to the Instances page in the Amazon EC2 console from earlier.
  • Select the checkbox beside nw-first-web-server.
  • Record the value shown under Public IPv4 address: your old public IPv4 address.
  • Choose Instance state above the instances table.
  • Choose Stop instance.
  • Confirm the stop in the dialog.
  • Wait until Instance state shows Stopped.

Stopping usually takes a few minutes while AWS shuts down the operating system. The transition between states is expected.

Before you refresh the old URL, do you expect its page to remain available after the instance reaches Stopped?

  • Switch back to the existing web server tab in Microsoft Edge.
  • Refresh the page at the old public IPv4 address.

Microsoft Edge cannot reach the page at the old address. That failed request is the intended result.

This Failure Is the Point

The security group still permits HTTP traffic. The stopped instance cannot answer the request.

Start the same instance

The unchanged instance ID anchors this lifecycle test to one server. Starting it reconnects the existing EBS root volume while AWS assigns a public IPv4 address again.

  • Return to the Instances page in the Amazon EC2 console.
  • Select the checkbox beside nw-first-web-server.
  • Choose Instance state above the instances table.
  • Choose the option that starts the selected instance.

Starting usually takes a few minutes while AWS boots the operating system. A short wait here is normal.

  • Wait until Instance state shows Running.
  • Wait until Status check shows 2/2 checks passed.
  • Record the new value under Public IPv4 address: your new public IPv4 address.
  • Compare the new public IPv4 address with your old public IPv4 address.

You'll see that your new public IPv4 address differs from your old public IPv4 address. The unchanged instance ID confirms this is the same server.

Load the page at the new address

The root volume still holds the website file. The inbound HTTP rule still allows traffic to port 80.

Before you load the updated URL, do you expect the custom page to return after the address change?

  • Select the address bar in Microsoft Edge.
  • Enter http:// followed by your new public IPv4 address.
  • Press Enter.

You'll see “Hello from my first AWS web server” on the custom page. The page also identifies the server as Amazon EC2.

That's the full lifecycle test complete. Your website survived while its network address changed.

Page Missing at the New Address?

  • Confirm that Status check shows 2/2 checks passed.
  • Check that the address bar uses your new public IPv4 address.
  • Confirm that nw-first-web-server-sg still shows the HTTP rule with source Anywhere-IPv4.

Help me diagnose why the EC2 website does not load after the stop and start cycle.

Why Did the Website Survive?

  • The EBS root volume retained /var/www/html/index.html while the instance was stopped.
  • The Apache HTTP Server service was enabled by systemctl enable httpd, so it starts during the next boot.
  • The attached security group retained its inbound HTTP rule for the restarted instance.

You can now recover an EC2 website after a stop and start cycle without confusing persistent storage with a temporary public address.

Secret mission

Restrict the Website to Your IP

Your website currently accepts requests from every public IPv4 address. Narrow its HTTP rule to your current public IPv4 address while keeping the page available on your own network.

Clean Up Your Resources

Clean Up Your Resources

Your next choice is to keep the website available, pause the server for later, or remove every project resource. A running Amazon EC2 instance creates ongoing charges until you stop or terminate it.

Cost warning

The running t3.micro instance costs $0.0104 per hour. Its auto-assigned public IPv4 address adds $0.005 per hour.

The EBS root volume costs $0.08 per GB-month. This storage charge continues while the instance is stopped.

The project is estimated to cost under $0.05 when the resources run for about one hour before deletion. AWS Free Tier credits may reduce that amount.

The amounts are small for this lab, but they keep accumulating over time. Choosing Pause or Delete after your demonstration keeps the total predictable.

Resources you used:

  • One t3.micro instance named nw-first-web-server.
  • One default root EBS volume containing Amazon Linux 2023, Apache HTTP Server, and the custom website.
  • One auto-assigned public IPv4 address attached while the instance is running.
  • One security group named nw-first-web-server-sg.
  • One EC2 key pair named nw-first-web-server-key.
  • One downloaded private key file stored on Windows.
  • One local user-data.yaml file containing the cloud-init configuration.

Keep everything running

No action is needed. Choose this option if you are still demonstrating the website from your current network.

  • Leave nw-first-web-server in the Running state.
  • Keep the nw-first-web-server-sg inbound rule restricted to your current public IPv4 address with a /32 prefix.
  • Store the downloaded private key file in a secure location.
  • Retain user-data.yaml if you want to reuse the server configuration.

The custom website stays available from your current network. Instance usage, public IPv4, and EBS storage charges continue.

Pause - I'll come back to this later

Stop the instance to halt compute usage billing while preserving its root EBS volume. This option keeps the server ready for a later start.

  • Return to Amazon EC2 in the AWS Management Console from earlier.
  • Choose Instances in the EC2 navigation panel.
  • Select nw-first-web-server.
  • Choose Instance state.
  • Choose Stop instance.
  • Confirm the stop request.
  • Wait until the instance state shows Stopped.

Instance usage billing stops while the server remains in the Stopped state. EBS storage billing continues.

AWS releases the current public IPv4 address when the instance stops. A later start assigns a new public IPv4 address.

When you return, resume the server with these actions:

  • Select nw-first-web-server on the Instances page.
  • Choose Instance state.
  • Choose Start instance.
  • Wait until the instance shows Running.
  • Wait until the status column shows 2/2 checks passed.

The website remains on the EBS-backed server. Use the newly assigned public IPv4 address when you open it again.

Delete - I don't want to use this again

Termination is permanent, so this option can feel drastic. It is the cleanest choice when you have finished the project.

Terminate the instance:

  • Return to Amazon EC2 in the AWS Management Console from earlier.
  • Choose Instances in the EC2 navigation panel.
  • Select nw-first-web-server.
  • Choose Instance state.
  • Choose Terminate (delete) instance.
  • Choose Terminate (delete) in the confirmation window.
  • Wait until the instance state shows terminated.

That is the irreversible part complete. The instance no longer accrues compute charges.

AWS releases the auto-assigned public IPv4 address. The default root EBS volume is deleted with the instance.

Delete the security group:

  • Choose Security Groups under Network & Security in the EC2 navigation panel.
  • Select nw-first-web-server-sg.
  • Choose Actions.
  • Choose Delete security groups.
  • Confirm the deletion.
  • Confirm that nw-first-web-server-sg no longer appears in the security group list.

Delete the EC2 key pair:

  • Choose Key Pairs under Network & Security in the EC2 navigation panel.
  • Select nw-first-web-server-key.
  • Choose Actions.
  • Choose Delete.
  • Confirm the deletion.

Remove the local project files:

  • Press the Windows key to open search.
  • Search for nw-first-web-server-key.
  • Select the downloaded private key file in the search results.
  • Press Delete.
  • Search for user-data.yaml.
  • Select user-data.yaml in the search results.
  • Press Delete.
  • Empty the Windows Recycle Bin to remove both files permanently.

Your EC2 instance, root EBS volume, public IPv4 address, security group, key pair, and local project files are now removed. These project resources can no longer create ongoing charges.

Nice Work!

Nice Work!

You made it! Your Amazon EC2 web server now serves a custom page to your current network. You turned a deliberate connection failure into a working server with restricted access.

What you learned:

  • Used Amazon Linux with cloud-init user data to install and start Apache HTTP Server automatically. Confirmed the instance was healthy through EC2 status checks.
  • Experienced a blocked HTTP request while the instance stayed healthy. Fixed the network path with a security group rule for TCP port 80.
  • Stopped and restarted an EBS-backed instance. Reached the persisted site through its newly assigned public IPv4 address. Compared stopping with termination so you can make cost-aware cleanup choices.
  • Secret Mission: Replaced the public Anywhere-IPv4 rule with My IP. Confirmed the source used a /32 prefix. Preserved access from your current network through least privilege.

Ready to quiz yourself?