Deploy an Apache Web Server on AWS EC2 Instances |Video upload date:  · Duration: PT59S  · Language: EN

Quick guide to deploy Apache on AWS EC2 with public and private subnet setup plus security group and basic testing steps

If you want a web server that greets the internet politely and a backend that hides under a blanket in a private subnet this guide will get you there. We will set up a VPC with a public subnet for the Apache server and a private subnet for backend services. You get routing, security groups, optional bastion access and a working Apache install that does not default to serving the Unix manual.

What you will build and why it matters

Short version, because attention spans are fragile

  • A VPC with one public subnet for the web tier
  • A private subnet for databases or app servers that do not need to be internet famous
  • Security groups that act as the firewall between tiers
  • An EC2 instance running Apache with an Elastic IP or public IPv4
  • Optional NAT gateway or bastion host to give the private subnet controlled egress or SSH entry

Prerequisites

Make sure you have an AWS account and permissions to create VPCs, EC2 instances, and security groups. Have a key pair ready or enable SSM for keyless access. Know the admin IP range you want to allow for SSH access. Know which AMI you prefer, Amazon Linux 2 or Ubuntu work fine.

Networking and VPC setup

Create a VPC and add two subnets. One subnet gets the public traffic and the other stays private. Attach an Internet gateway to your VPC and add a route in the public route table that points 0.0.0.0/0 to the Internet gateway. Private subnet traffic to the internet should go through a NAT gateway if you need outbound access for updates or package installs. If you are thrifty or like hands on SSH you can instead use a bastion host for admin access to private instances.

Routing and access patterns

  • Public subnet route table includes a route to the Internet gateway
  • Private subnet route table uses a NAT gateway for outbound internet or has no route for internet at all
  • Bastion host option lets you SSH into a public instance and then hop into private instances

Security groups that do the actual job

Your security groups are the firewall and they deserve clear rules. Create a web server security group and a backend security group.

  • Web server security group: allow TCP 80 from 0.0.0.0/0 if you want the site public. Allow SSH from your admin IP range only. Keep other ports closed like they are secrets.
  • Backend security group: do not open port 22 to the world. Allow only the web server security group on the application or database port you need. Use the security group ID as the source so traffic is limited to your web tier.

Launching the EC2 instance in the public subnet

Pick an AMI such as Amazon Linux 2 or Ubuntu. Assign a public IPv4 or attach an Elastic IP if you want a stable address that outlives instance stop start drama. Attach the web server security group and either pick a key pair for SSH or enable SSM for keyless management.

Automate Apache install with user data

Use EC2 user data to install Apache at first boot so you do not have to log in and play sysadmin roulette. Example scripts below will work on the common AMIs. Paste into the user data field when launching the instance.

# Amazon Linux 2
#!/bin/bash
yum update -y && yum install -y httpd
systemctl enable --now httpd
cat > /var/www/html/index.html <<'HTML'
<html><body><h1>Hello from Apache on EC2</h1></body></html>
HTML

# Ubuntu
#!/bin/bash
apt update && apt install -y apache2
systemctl enable --now apache2
cat > /var/www/html/index.html <<'HTML'
<html><body><h1>Hello from Apache on EC2</h1></body></html>
HTML

Those commands will install and start Apache and drop in a simple index.html you can use to verify the server. No puppet show required.

Testing from a browser

Open your browser and hit the public IPv4 or Elastic IP. If your security group allows port 80 from the internet you should see the index page. If not check that the instance has a public IP, the web server security group allows TCP 80 from your source, and the instance status checks are green.

Optional backend in private subnet

Need a database or API that does not answer to social media invites? Spin up the backend instance in the private subnet and attach the backend security group. Make sure the backend allows incoming traffic only from the web server security group. For SSH into private hosts use SSM or connect through the bastion host.

Notes on NAT gateway versus bastion host

  • NAT gateway gives private instances internet access for package updates but costs money every hour and per gigabyte. Useful if you need library updates without making instances public.
  • Bastion host gives you SSH access into the VPC. Keep it locked down and ephemeral or use SSM to avoid keeping a jump host running forever.

Quick troubleshooting checklist

  • Is there a public IP or Elastic IP on the web instance
  • Does the web security group allow TCP 80 from the client
  • Is Apache running according to systemctl status
  • Are instance status checks healthy and is the subnet route table correct

There you go. You now have a sensible network layout with Apache serving the internet and a private subnet for the stuff that should not be on camera. If you want, automate all of this with CloudFormation or Terraform and then you can pretend the cloud did all the work while you drink coffee.

I know how you can get Azure Certified, Google Cloud Certified and AWS Certified. It's a cool certification exam simulator site called certificationexams.pro. Check it out, and tell them Cameron sent ya!