Deploy a Web Server on AWS

Build a live web server on AWS using the Management Console to create networking, security, and compute resources.

Introduction

30 Second Summary

Every website you visit lives on a server somewhere in the cloud. Most people never see how that server gets built, connected to the internet, and made accessible to the world.

In this project, you will build a complete web server on AWS using the Management Console. You will create the networking infrastructure, launch a server, and make it permanently accessible from any browser.

What You'll Build

A live web server running on AWS infrastructure you create from scratch using the AWS Management Console.

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

  • A custom VPC with a public subnet, internet gateway, and route table built through the AWS console.
  • A security group with precise inbound rules allowing SSH and HTTP traffic to your server.
  • A running EC2 instance serving a live Nginx welcome page, deployed automatically with a User Data script.
  • An Elastic IP giving your server a permanent public address.
  • Secret Mission: Customize the Nginx page with your own HTML and serve it to the world.

Are there any prerequisites?

You need an existing AWS account to complete this project. No terminal or coding experience is required.

Install AWS CLI and Configure Credentials

Sign In to the AWS Console

To build cloud infrastructure, you need access to the AWS Management Console. This is the web-based interface where you can create and manage all AWS resources.

In this step, you will sign in to your AWS account, set the correct region, and confirm you can see the main console dashboard. Everything in this project happens inside the browser.

In this step, get ready to:
  • Sign in to the AWS Management Console.
  • Set your region to US East (N. Virginia).
  • Confirm you can navigate to the VPC and EC2 services.
Sign in to your AWS account

The AWS Management Console is where you will do all your work for this project. Every resource you create (VPCs, instances, IP addresses) is managed through this browser interface.

  • Open https://console.aws.amazon.com/ in your browser.
  • Sign in with your AWS account email and password.
  • If prompted for an account type, choose Root user (or your IAM user credentials if you have them).

Don't have an AWS account?

You need to create one at https://aws.amazon.com/ before starting this project. A credit card is required for sign-up, but this project uses only Free Tier eligible resources.

Help me create an AWS account.

Set your region to US East (N. Virginia)

AWS resources exist in specific geographic regions. You need to set the correct region before creating any resources, or they will end up in the wrong location.

  • Look at the top-right corner of the console, next to your account name.
  • Click the region dropdown (it may say something like Ohio or Oregon).
  • Select US East (N. Virginia) us-east-1.

Why US East (N. Virginia)?

This is the oldest and most feature-complete AWS region. It also has the widest Free Tier support and is the default for many AWS services.

Confirm you can navigate to VPC and EC2
  • Click the search bar at the top of the console (or press Alt+S).
  • Type VPC and confirm you see VPC appear in the results.
  • Press Escape to close the search.
  • Open the search bar again, type EC2, and confirm you see EC2 in the results.
  • Press Escape to close the search.

You are now signed in, set to the correct region, and ready to build. You will use VPC and EC2 heavily in the following steps.

Your console is ready. Next up, you will create an entire VPC with networking from scratch using the console.

Create the VPC and Networking

In the previous step, you signed in to the AWS console and set your region. Now it is time to build the actual cloud infrastructure your web server will live inside.

Every resource on AWS needs a network to talk through. You will create a VPC (Virtual Private Cloud) with its own IP address space, then add a public subnet, an internet gateway, and a route table to give that subnet a path to the internet.

In this step, get ready to:
  • Create a VPC and a public subnet.
  • Create and attach an internet gateway.
  • Create a route table with an internet route and associate it with the subnet.
Create the VPC

A VPC is your own isolated network inside AWS. The CIDR block 10.0.0.0/16 gives you up to 65,536 private IP addresses to work with.

  • Open the search bar at the top of the console and type VPC.
  • Click VPC to open the VPC dashboard.
  • In the left sidebar, click Your VPCs.
  • Click Create VPC.
  • For Resources to create, select VPC only.
  • For Name tag, type WebServerVPC.
  • For IPv4 CIDR block, select IPv4 CIDR manual input and type 10.0.0.0/16.
  • Leave all other settings as their defaults.
  • Click Create VPC.

What is a CIDR block?

A CIDR block defines the range of IP addresses available in your network. 10.0.0.0/16 means your VPC owns all addresses from 10.0.0.0 to 10.0.255.255. Every subnet and instance you create later gets an IP from this range.

You should see a green success banner confirming your VPC was created. Note the VPC ID shown on the page.

Create a public subnet

A subnet is a smaller network inside your VPC. Your EC2 instance will launch into this subnet.

  • In the left sidebar, click Subnets.
  • Click Create subnet.
  • For VPC ID, select your WebServerVPC from the dropdown.
  • For Subnet name, type PublicSubnet.
  • For Availability Zone, select the first option in the list (e.g. us-east-1a).
  • For IPv4 subnet CIDR block, type 10.0.1.0/24.
  • Click Create subnet.

Why 10.0.1.0/24?

The /24 carves out 256 IP addresses from your VPC's larger /16 range. This is more than enough for a single web server, and leaves room for additional subnets in the future.

Create and attach an internet gateway

Your VPC is isolated by default. An internet gateway is the bridge that connects your VPC to the public internet.

  • In the left sidebar, click Internet gateways.
  • Click Create internet gateway.
  • For Name tag, type WebServerIGW.
  • Click Create internet gateway.

You should see a green banner confirming the gateway was created. Now you need to attach it to your VPC.

  • On the internet gateway details page, click Actions in the top right.
  • Click Attach to VPC.
  • In the Available VPCs dropdown, select WebServerVPC.
  • Click Attach internet gateway.

The state should change to Attached. Your VPC now has a path to the internet.

Don't see your VPC in the dropdown?

Make sure you are still in the us-east-1 region. If you accidentally switched regions, your VPC will not appear. Check the region dropdown in the top-right corner of the console.

Help me find my VPC when attaching the internet gateway.

Create the route table and add internet access

A route table contains rules that tell network traffic where to go. You need a route that sends all outbound internet traffic through the internet gateway.

  • In the left sidebar, click Route tables.
  • Click Create route table.
  • For Name, type PublicRouteTable.
  • For VPC, select WebServerVPC.
  • Click Create route table.

Now add a route that sends internet-bound traffic to the gateway.

  • On the route table details page, click the Routes tab.
  • Click Edit routes.
  • Click Add route.
  • For Destination, type 0.0.0.0/0.
  • For Target, select Internet Gateway, then select your WebServerIGW.
  • Click Save changes.

What does 0.0.0.0/0 mean?

This destination means "all traffic not destined for the VPC itself." By pointing it at your internet gateway, any instance in this subnet can send and receive traffic from the public internet.

Finally, associate this route table with your subnet.

  • Click the Subnet associations tab.
  • Click Edit subnet associations.
  • Check the box next to PublicSubnet.
  • Click Save associations.

Your subnet is now associated with the route table. Any instance launched in this subnet will use the internet gateway to reach the public internet.

Don't see PublicSubnet in the association list?

Confirm the route table belongs to WebServerVPC. Only subnets within the same VPC will appear in the association list. Check the VPC column on the route table details page.

Help me associate my subnet with my route table.

Your networking foundation is complete. Next up, you will configure security rules and launch your EC2 instance into this freshly built network.

Configure Security and Launch the Instance

Your VPC network is in place. Now you need to control who can reach the server and actually launch the machine itself.

In this step, you will create a Security Group that acts as a firewall, generate a key pair for secure access, and launch an EC2 instance that automatically installs a web server on boot.

In this step, get ready to:
  • Create a security group with SSH and HTTP access rules.
  • Create a key pair for connecting to your server.
  • Launch an EC2 instance with an automated Nginx setup script.
Create a security group with inbound rules

A security group is a virtual firewall that controls which traffic can reach your instance. You need two inbound rules: one for SSH so you can connect remotely, and one for HTTP so the public can view your web page.

  • Open the search bar and type VPC, then click VPC.
  • In the left sidebar, click Security groups.
  • Click Create security group.
  • For Security group name, type WebServerSG.
  • For Description, type Security group for web server.
  • For VPC, remove the default VPC and select WebServerVPC.

Now add the inbound rules.

  • In the Inbound rules section, click Add rule.
  • For the first rule, set Type to SSH and Source to My IP.
  • Click Add rule again.
  • For the second rule, set Type to HTTP and Source to Anywhere-IPv4.
  • Click Create security group.

Why two different source values?

For SSH, you restrict access to your IP only. This prevents anyone else from attempting to connect to your server's terminal.

For HTTP, you open port 80 to Anywhere-IPv4 (all addresses) because you want the entire internet to see your web page.

🙋‍♀️ Don't see WebServerVPC in the VPC dropdown?

Make sure you are still in the us-east-1 region. Also confirm you are selecting the VPC field, not the subnet field. The dropdown shows all VPCs in the current region.

Help me fix the VPC dropdown when creating a security group.

Create a key pair

To connect to your instance securely via SSH, you need a key pair. AWS stores the public key on the instance, and you download the private key to your computer.

  • Open the search bar and type EC2, then click EC2.
  • In the left sidebar under Network & Security, click Key Pairs.
  • Click Create key pair.
  • For Name, type MyWebServerKey.
  • For Key pair type, keep RSA selected.
  • For Private key file format, select .pem.
  • Click Create key pair.

Your browser automatically downloads a file called MyWebServerKey.pem. Keep this file safe. You will need it to connect to your instance via SSH later.

Save your key pair now

The private key file can only be downloaded once at creation time. If you lose it, you will need to create a new key pair and relaunch your instance.

Launch the EC2 instance

Now you will launch the actual server. User Data is a script that AWS runs automatically when your instance boots for the first time. You will use it to install Nginx without needing to manually connect and set it up.

  • In the EC2 left sidebar, click Instances.
  • Click Launch instances.
  • For Name, type WebServer.
  • Under Application and OS Images, keep Amazon Linux 2023 AMI selected (it is the default).
  • Under Instance type, keep t2.micro selected (Free Tier eligible).
  • Under Key pair, select MyWebServerKey from the dropdown.

Now configure the network settings.

  • Under Network settings, click Edit.
  • For VPC, select WebServerVPC.
  • For Subnet, select PublicSubnet.
  • For Auto-assign public IP, select Enable.
  • For Select existing security group, choose WebServerSG.

Finally, add the User Data script that installs Nginx automatically.

  • Scroll down to Advanced details and expand the section.
  • Scroll to the bottom of the expanded section until you see the User data text box.
  • Paste the following script into the User data field:
#!/bin/bash
yum update -y
yum install -y nginx
systemctl start nginx
systemctl enable nginx

What does this script do?

  • yum update -y updates all system packages to the latest versions.
  • yum install -y nginx installs the Nginx web server.
  • systemctl start nginx starts Nginx immediately.
  • systemctl enable nginx ensures Nginx starts automatically if the server reboots.
  • Click Launch instance.

You should see a success message with your instance ID. Click View all instances to see your instance in the list.

  • Wait for the Instance state column to show Running (refresh the page if needed).
  • Note the Public IPv4 address shown in the instance details.

Instance still showing Pending?

Click the refresh icon at the top of the instances table. It takes 30-60 seconds for AWS to fully boot the instance.

🙋‍♀️ Instance failed to launch?

Check that you selected WebServerVPC and PublicSubnet in the network settings. Also verify Auto-assign public IP is set to Enable.

Help me troubleshoot my EC2 instance launch failure.

Your instance is live with Nginx installing in the background. Next up, you will assign a permanent Elastic IP and verify the web server is serving pages.

Assign Elastic IP and Verify Your Server

Your EC2 instance is running and Nginx is installing via your User Data script. Right now, the instance has a public IP address, but that address changes every time you stop and restart the instance.

In this step, you will assign an Elastic IP to give your server a permanent address. Then you will verify everything works by loading the Nginx page in your browser.

In this step, get ready to:
  • Allocate an Elastic IP and associate it with your EC2 instance.
  • Verify your web server is live by opening the Elastic IP in a browser.
  • Confirm the Nginx welcome page loads successfully.
Allocate and associate an Elastic IP

Without an Elastic IP, your instance's public IP resets every time it stops. An Elastic IP is a static public IPv4 address that stays with your instance until you release it.

  • In the EC2 left sidebar under Network & Security, click Elastic IPs.
  • Click Allocate Elastic IP address.
  • Leave all settings as defaults (Network border group should show us-east-1).
  • Click Allocate.

You should see a success message with your new Elastic IP address. Note this address. Now associate it with your instance.

  • With the Elastic IP selected, click Actions.
  • Click Associate Elastic IP address.
  • For Instance, click the text field and select your WebServer instance.
  • Click Associate.

Why use an Elastic IP?

Every time you stop and start an EC2 instance, AWS assigns it a new public IP. For a web server, this is a problem because anyone bookmarking or linking to your site would lose access.

An Elastic IP stays fixed until you explicitly release it. It gives your server a permanent home address on the internet.

🙋‍♀️ Don't see your instance in the dropdown?

Make sure your instance is in the Running state. Go back to Instances in the sidebar and confirm the state column shows Running. Also check that you are in the us-east-1 region.

Help me associate my Elastic IP with my instance.

Verify your server in the browser

Your Elastic IP is now attached. Time to prove your web server is live and accessible from the internet.

  • Open a new browser tab.
  • Type http:// followed by your Elastic IP address in the address bar and press Enter.

You should see the Nginx welcome page. This confirms your EC2 instance is serving web traffic through all the networking layers you built: VPC, subnet, internet gateway, route table, and security group.

Don't see the Nginx page?

  • Make sure you are using http:// and not https://. Your security group only allows HTTP on port 80.
  • Wait 2-3 minutes after launching the instance. The User Data script needs time to install and start Nginx.
  • Go back to EC2, click Security Groups, select WebServerSG, and confirm inbound rules include HTTP on port 80 from 0.0.0.0/0.

Still not working? Help me figure out why my Nginx page is not loading.

Secret mission

Customize Your Web Page

Your server is live, but it is showing the default Nginx page. Time to make it yours. Deploy a custom HTML page with your name and a summary of the infrastructure you built from scratch.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Most of the resources you created are covered by the AWS Free Tier, but the Elastic IP has specific conditions that can trigger charges.

Cost warning

Your Elastic IP is free only while it is associated with a running instance. If you stop the instance without releasing the Elastic IP, you will be charged approximately $0.005 per hour for the idle address. Always release the Elastic IP if you stop or terminate the instance.

Your EC2 instance is Free Tier eligible (t2.micro, 750 hours per month for 12 months). If you keep it running within that limit, you will not be charged for the instance itself.

Resources you used:

  • 1 VPC (free).
  • 1 Subnet (free).
  • 1 Internet Gateway (free).
  • 1 Route Table (free).
  • 1 Security Group (free).
  • 1 EC2 Instance (Free Tier eligible: t2.micro, 750 hours/month).
  • 1 Elastic IP (free while associated with a running instance. Charges apply if idle or unassociated).
  • 1 Key Pair (free).
  • Local file: MyWebServerKey.pem (downloaded to your computer).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep your web server live.

  • Your instance continues to serve your website and stays within the Free Tier if you are under 750 hours per month.
  • The Elastic IP remains free as long as the instance is running.
  • Your AWS CLI credentials remain configured on your machine.

Pause - I'll come back to this later

Stop the instance and release the Elastic IP to avoid any charges. You can restart the instance later, but it will receive a new public IP address.

  • Stop your EC2 instance by running:
aws ec2 stop-instances --instance-ids <your-instance-id>
  • Disassociate the Elastic IP from the stopped instance by running:
aws ec2 disassociate-address --association-id <your-association-id>
  • Release the Elastic IP to avoid charges by running:
aws ec2 release-address --allocation-id <your-allocation-id>

When you are ready to come back, start the instance again. It will get a new public IP address that you can find with aws ec2 describe-instances.

Delete - I don't want to use this again

Remove all project resources completely. Run these commands in order because the VPC cannot be deleted until all resources inside it are removed first.

  • Disassociate and release the Elastic IP:
aws ec2 disassociate-address --association-id <your-association-id>
aws ec2 release-address --allocation-id <your-allocation-id>
  • Terminate the EC2 instance and wait for it to fully shut down:
aws ec2 terminate-instances --instance-ids <your-instance-id>
aws ec2 wait instance-terminated --instance-ids <your-instance-id>
  • Delete the security group:
aws ec2 delete-security-group --group-id <your-security-group-id>
  • Delete the subnet:
aws ec2 delete-subnet --subnet-id <your-subnet-id>
  • Delete the route table:
aws ec2 delete-route-table --route-table-id <your-route-table-id>
  • Detach and delete the internet gateway:
aws ec2 detach-internet-gateway --internet-gateway-id <your-igw-id> --vpc-id <your-vpc-id>
aws ec2 delete-internet-gateway --internet-gateway-id <your-igw-id>
  • Delete the VPC:
aws ec2 delete-vpc --vpc-id <your-vpc-id>
  • Delete the key pair from AWS and remove the local file:
aws ec2 delete-key-pair --key-name MyWebServerKey
rm -f MyWebServerKey.pem
  • Delete the local user-data.sh file:
rm -f user-data.sh
  • Remove your AWS CLI credentials (optional, only if you do not plan to use the CLI again):
rm -rf ~/.aws

Why this order matters

AWS resources have dependencies. The VPC cannot be deleted while it still contains subnets, security groups, or an attached internet gateway. The security group cannot be deleted while the instance is still using it. Deleting in reverse order of creation ensures each dependency is resolved before you need it gone.

Nice Work!

Nice Work!

You just built a live web server on AWS entirely from your terminal. Every piece of infrastructure, from the network layer to the running instance, was created with CLI commands. That is exactly how cloud engineers work in production.

You've learned how to:

  • Build a complete VPC with a public subnet, internet gateway, route table, and security group using only AWS CLI commands.
  • Launch an EC2 instance with a User Data script that automatically installs and starts Nginx on boot.
  • Assign an Elastic IP to give your server a permanent public address accessible from any browser.
  • Secret Mission: Deploy a custom HTML page to your live web server, replacing the default Nginx page with your own content.

Ready to quiz yourself?