AWS Builder Center
Deploy a web server to the cloud

Deploy a web server to the cloud

Spin up an EC2 instance, install Apache, and put your own web page on the internet.

Developer. Hacker. Creator.
Time to get stateful with EC2! In serverless, everything is ephemeral, meaning nothing persists after the function runs. With a server, it's on 24/7, state is preserved, and you have full control over the environment.
Servers power the internet for things like games, streaming platforms, e-commerce sites, and social media feeds. EC2 is AWS's answer to running your own server in the cloud, without the hassle of managing physical hardware.

What you’re building

You're going to spin up an Amazon Linux virtual machine, install Apache, and expose it to the internet so it's reachable from any browser. Then you'll edit the actual file being served so you can see your own content live on the web.

Why serverless vs servers

In the prior guide  you got to build a serverless API with Lambda. Now let's see the why we'd use serverless vs servers.
Servers (EC2) You pick the OS (operating system), you install the software, it runs 24/7 whether anyone's using it or not. You pay by the hour. Good for: apps that need to stay running, custom environments, long-running processes.
Serverless (Lambda) AWS runs your code only when something triggers it (an API call, a file upload, a timer). You don't think about servers at all. You pay per request. Good for: APIs, event-driven workflows, things that happen in short bursts.
Neither is "better". A simple rule of thumb: if your app needs to stay on and running, or you need control over the OS, reach for EC2.
If you just need code to run when something happens (an API call, a file upload, a schedule) serverless is the easier path. In practice, most teams use a mix of both.
AND, deploying this EC2 instances completes the “Launch an instance using EC2” Free Tier activity, which will earn you an additional $20 in Free Tier credits.
⚠️ Be sure to follow the "Clean up" section to earn the credits but also to not accumulate charges.

Some technical background

We'll be discussing some AWS services and tools, so let's start with simple definitions of what each one does.
  • AWS IAM (AWS Identity and Access Management): is like a security guard at a building who checks your badge to decide which rooms you can enter and what you're allowed to do in each one
  • AWS Systems Manager: is like a control panel that lets you view and manage all your AWS resources from one place, automating tasks like patching servers, running commands across multiple machines, and keeping track of your infrastructure's health
  • SSH (Secure Shell): allows us to log into remote systems and execute commands

Create an IAM role for Session Manager

We need a role that lets Systems Manager connect to our instance. This will allow us to skip setting up an SSH keys setup entirely.
  1. Open the IAM Roles console 
  2. Click Create role
  3. Configure the trusted entity:
    1. Trusted entity type: AWS Service
    2. Service or use case: EC2
    3. Use case: EC2 Role for AWS Systems Manager
  4. Click Next
  5. On the "Add permissions" screen, the AmazonSSMManagedInstanceCore policy is already attached, click Next
  6. Name the role ec2-ssm-role
  7. Click Create role
You should then have an ec2-ssm-role with the SSM policy attached.

Launch an EC2 instance

All our ducks are in a row and we are ready to create our first EC2 instance! We need to pick an operating system (OS), which is like the main program that tells the computer how to work.
You can think of operating systems like Windows or macOS. In the server world, operating systems generally won't have a desktop (the screen with icons and windows you're used to). Instead, they run "headless," which means we don't use them with a keyboard, mouse, and monitor. We connect to them remotely using a tool called SSH.
We also need to decide how much computer power this server should have. For something like a free tier eligible VM (t2.micro), that's 2 VCPUs (virtual processors) and 1GB of memory (think of this like the computer's short-term memory for running programs).
Let's spin up an instance with the IAM role we created in the previous step so we can connect to it via Systems Manager.
  1. Open the EC2 console 
  2. Name your instance something like my-web-server
  3. Under "Application and OS Images", select Amazon Linux 2023 (should be the default)
  4. For "Instance type", keep t2.micro (Free Tier eligible)
  5. Under "Key pair", select Proceed without a key pair as we're using Session Manager instead
  6. Under "Network settings":
    1. Check Allow HTTP traffic from the internet (this will allow us view the web server over the internet)
  7. Expand Advanced details and find "IAM instance profile":
    1. Select ec2-ssm-role from the dropdown
  8. Click Launch instance
  9. Wait a minute or two for the instance to reach the Running state
You EC2 instance should be ready to connect after all the status checks are complete.

Connect via Session Manager

Session Manager gives you a browser-based shell so we can execute commands on the remote virtual machine.
  1. Open the EC2 Instances console 
  2. Select your my-web-server instance
  3. Click Connect (top right)
  4. Choose the Session Manager tab
  5. Click Connect
You should land in a shell as ssm-user. Run whoami to confirm you're in.
Connecting to instance via SSH & Session Manager

Install and start the apache webserver

From your Session Manager shell, run these commands:Install Apache:
1
sudo yum install -y httpd
Start the server:
1
sudo systemctl start httpd
Enable it so it survives a reboot:
1
sudo systemctl enable httpd
Confirm it's running:
1
sudo systemctl status httpd
You should see active (running) in the output.

See it live

  1. Go back to the EC2 Instances console 
  2. Select your my-web-server instance
  3. In the details pane below, find Public IPv4 address and copy it
  4. Open a new browser tab and go to http://<your-public-ip>
You should see the Apache test page, "It works!", which means your web server is live on the internet accessible to anyone.

Serve your own page

Let's replace the default Apache page with something of your own, it can be any text you wan't but keep in mind the web servers use HTML .
In your Session Manager shell, open the default web page in nano:
1
sudo nano /var/www/html/index.html
Type in some HTML, anything you want. For example:
1
2
3
4
5
<pre>
_
.__(.)< (woof)
\___)
</pre>
  1. Save the file: press Ctrl + O, then Enter to confirm
  2. Exit nano: press Ctrl + X
  3. Go back to your browser and refresh http://<your-public-ip>
You should see your custom page instead of the Apache test page.

What happened behind the scenes

Here's what AWS actually set up for you during this tutorial:
  • VPC + Subnet: Your instance launched into a default Virtual Private Cloud with a public subnet. This is the network layer that gives your instance connectivity.
  • Security Group: When you checked "Allow HTTP traffic from the internet", AWS created a firewall rule that opens port 80 to the world. Without it, no one could reach your web server.
  • IAM Role + Instance Profile: The ec2-ssm-role you created gave your instance permission to talk to Systems Manager. That's how Session Manager connected without SSH keys as the instance registers itself with SSM on boot.
  • Public IP: AWS assigned a public IPv4 address from its pool. This is how the internet reaches your instance. Note: if you stop and start the instance, this IP will change unless you use an Elastic IP.
  • Apache (httpd): You installed a web server process that listens on port 80 and serves files from /var/www/html/. When someone hits your public IP over HTTP, Apache responds with whatever's in that directory.
In short: networking (VPC, subnet, security group) gets traffic to the box, IAM gets you into the box, and Apache serves content from the box.

What will this cost

This tutorial uses a t2.micro instance, which is covered under the AWS Free Tier  for your first year. Outside of that, costs depend on your instance type, how long it runs, storage, and bandwidth.
A few things to know:
  • Stopping your instance pauses compute charges but keeps the disk (EBS volume) around for a small storage fee.
  • Terminating your instance deletes everything - the instance, the disk, gone. No more charges.
  • If you forget about a running instance, it will keep billing you. Set a billing alarm  so you don't get surprised.
You can check your current spend anytime in the AWS Billing Console .

Clean up

When you're done, terminate everything so you don't get charged.
  1. Open the EC2 Instances console 
  2. Select your my-web-server instance
  3. Click Instance state > Terminate instance
  4. Confirm by clicking Terminate
This deletes the instance and its attached storage.
(Optional): You can also clean up the security group and IAM role we created but these don’t incur charges so these steps are up to you.
Clean up the security group and IAM role:
  1. Go to EC2 > Security Groups 
  2. Find the security group that was created with your instance (it'll have the HTTP rule you added), select it, then Actions > Delete security groups
  3. Go to IAM > Roles 
  4. Search for ec2-ssm-role, select it, and click Delete
  5. Type the role name to confirm and delete
Once those are gone, you're back to a clean slate with no ongoing charges.

Next steps

You just launched an EC2 instance and setup a public web server.
In the next project in this series , we will show you how to build your first AI agent.

This project is part of the AWS Free Tier onboarding series. Everything you built here runs within the Free Tier — no surprise bills, just learning.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article