Developer Tools AWS

Apache HTTP Server on AWS User Guide

Last updated: 2026-05-21 | Product: Apache HTTP Server on AWS

Overview

This image runs the Apache HTTP Server, the open source web server, installed from the maintained package set of the operating system. The web server is the only workload on the image. There is no bundled application runtime and no database, so the platform stays lean, predictable and easy to reason about. The maintained stable line of Apache HTTP Server is provided, Apache 2.4.

Customer web content lives on a dedicated storage volume mounted at /var/www, with the document root at /var/www/html. Keeping site files on their own volume means content can be grown, snapshotted and backed up independently of the operating system disk. A clean default landing page is served on first boot so you can confirm the server is healthy before you deploy your own site.

The monitoring modules mod_status and mod_info are enabled. Their endpoints, /server-status and /server-info, keep Apache's secure default of Require local, so they are reachable only from the instance itself until you choose to open them to a trusted network. A first boot service writes a short, non secret server information file for the administrator. Apache HTTP Server has no built in credential store, so there are no application passwords to manage.

Prerequisites

Before you deploy this image you need:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network and inbound ports 80 and 443 from the networks your visitors will use
The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for Apache HTTP Server. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger for a production web server. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks your visitors use. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes a few seconds after the instance state becomes Running and the status checks pass.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg Apache HTTP Server Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22, 80, and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":20,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=apache-web-01}]'

The command prints a JSON document on success. Note the instance ID, then retrieve its public address once it is running with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Step 3: Connect and Review the Server Information File

Connect over SSH with the key pair you selected and the public IP address from step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant	SSH login user
Apache HTTP Server 2.4 on Ubuntu 24.04	`ubuntu`

The first boot service runs before the SSH daemon becomes ready, so the server information file is always in place when you log in for the first time.

ssh <login-user>@<public-ip>
sudo cat /root/apache-http-server-info.txt

The file is a short, non secret summary written by the first boot service. It records the installed Apache version, the document root, the configuration root, and the URLs of the monitoring endpoints. Apache HTTP Server has no built in credential store, so the file contains no passwords.

From the same SSH session you can confirm the deployment is healthy:

curl -fsS -o /dev/null -w 'landing page HTTP %{http_code}\n' http://127.0.0.1/

A landing page HTTP 200 response confirms the web server is serving the default page.

Step 4: The Default Landing Page

Open a web browser and navigate to http://<public-ip>/. The image serves a clean cloudimg landing page that confirms the server is online and points you to the document root and the monitoring endpoints.

Apache HTTP Server default landing page

This page exists so you can verify the server before deploying your own site. The next step replaces it with your content.

Step 5: Deploy Your Website to the Document Root

The document root is /var/www/html, which sits on a dedicated, independently resizable EBS volume mounted at /var/www. Confirm the dedicated volume is mounted:

df -h /var/www | tail -1

You will see the volume mounted at /var/www on its own device, separate from the operating system root filesystem.

Place your website files in /var/www/html. To replace the default landing page with your own index.html, copy your site into the document root and set ownership so Apache can read it:

sudo rsync -a /path/to/your/site/ /var/www/html/
sudo chown -R www-data:www-data /var/www/html

Apache serves the new content immediately, with no restart required for static files.

Step 6: Monitor the Server with mod_status

The mod_status module is enabled and publishes a live activity report at /server-status. It keeps Apache's secure default of Require local, so it is reachable from the instance itself but not from the public internet. View it from your SSH session:

curl -s http://127.0.0.1/server-status?auto | head -12

The machine readable ?auto view is convenient for scripts and monitoring agents. The full HTML report shows each worker, the request it is serving, and per child request counts.

Apache mod_status server status report

To view /server-status in a browser without exposing it publicly, forward it over SSH from your workstation:

ssh -L 8080:127.0.0.1:80 <login-user>@<public-ip>

Then browse to http://127.0.0.1:8080/server-status. To grant access to a trusted monitoring network instead, add an extra Require ip line to /etc/apache2/conf-available/cloudimg-status.conf and reload Apache. Never replace Require local with Require all granted on an internet facing server.

Step 7: Inspect the Configuration with mod_info

The mod_info module is enabled and publishes the loaded modules and the active server configuration at /server-info. Like /server-status it keeps Require local. Inspect it from your SSH session or over the same SSH forward used in step 6.

Apache mod_info server information report

The report lists every loaded module, the server settings, the timeouts, the multi processing module in use, and the configuration file paths. It is the quickest way to confirm which modules are active and where Apache is reading its configuration from.

You can also confirm the monitoring modules from the command line:

sudo apache2ctl -M | grep -E 'status_module|info_module'

Step 8: Configure Virtual Hosts

Apache serves additional sites through virtual hosts. Virtual host files live in /etc/apache2/sites-available and are enabled with a2ensite. Create a file such as /etc/apache2/sites-available/example.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example
    ErrorLog ${APACHE_LOG_DIR}/example-error.log
    CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

Enable the site, test the configuration, and reload Apache:

sudo mkdir -p /var/www/example
sudo a2ensite example
sudo apache2ctl configtest
sudo systemctl reload apache2

apache2ctl configtest reports Syntax OK when the configuration is valid. Always run it before reloading so a typo never takes the server down.

Step 9: Verify and Reload Apache Safely

Whenever you change the configuration, validate it before applying it. From your SSH session:

sudo apache2ctl configtest

A Syntax OK response means the change is safe to apply. Reload with sudo systemctl reload apache2, which applies the new configuration without dropping established connections. Use sudo systemctl restart apache2 only when a full restart is required, for example after enabling a new module.

Step 10: Enable HTTPS with Let's Encrypt

For any production deployment serve the site over HTTPS so traffic cannot be intercepted. The ssl module is already enabled on this image, and certbot can configure a certificate and an Apache virtual host automatically.

The following assumes you have a DNS record pointing your fully qualified domain name at the instance's public IP address.

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d www.your-domain.example \
  --non-interactive --agree-tos -m you@your-domain.example \
  --redirect

Certbot obtains the certificate, writes an SSL virtual host, and sets up automatic renewal through a systemd timer. After it finishes, browse to https://www.your-domain.example/ to confirm the secure site.

Step 11: Backups and Maintenance

The data to back up on an Apache HTTP Server instance is the web content and the server configuration:

sudo tar --acls --xattrs -czf /var/backups/apache-content-$(date +%F).tgz -C /var/www html

sudo tar --acls --xattrs -czf /var/backups/apache-config-$(date +%F).tgz -C /etc apache2

Ship both artifacts to an Amazon S3 bucket or another object store. Because /var/www is a dedicated EBS volume, you can also take an EBS snapshot of it on its own schedule for a point in time copy of all site content.

For kernel and package updates, Ubuntu's unattended-upgrades is enabled by default, so security patches apply automatically. To update Apache itself, run sudo apt-get update && sudo apt-get upgrade and reload the service.

Step 12: Scaling Beyond a Single Instance

For larger deployments decouple the web tier from the single instance pattern:

Put the Apache web tier behind an Application Load Balancer and scale horizontally with an Auto Scaling group
Keep shared site content on Amazon EFS mounted at the document root so every instance serves the same files
Push static assets to Amazon S3 and front them with Amazon CloudFront to offload traffic from the instances
Terminate TLS at the load balancer and use an AWS Certificate Manager certificate for managed renewal

The Apache HTTP Server documentation at https://httpd.apache.org/docs/2.4/ covers virtual hosts, performance tuning, and module configuration in depth.

Support

cloudimg provides 24/7/365 expert technical support for this image. Guaranteed response within 24 hours, one hour average for critical issues. Contact support@cloudimg.co.uk.

For general Apache HTTP Server administration questions consult the official documentation at https://httpd.apache.org/docs/2.4/.