Apache HTTP Server

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 SecureAnyCloud 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. 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 initialization takes a few seconds after the instance state becomes Running and the status checks pass.

This command launches an instance from the SecureAnyCloud Apache HTTP Server Marketplace AMI into an existing subnet and security group. Make these replacements:

• Replace <ami-id> with the AMI ID shown on the Marketplace listing.
• Replace <key-name> with your EC2 key pair name.
• Replace <subnet-id> with your subnet ID.
• Replace <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}]'

On success, the command prints a JSON document. Note the instance ID. Once the instance is running, retrieve its public address withaws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from step 2. On the Apache HTTP Server 2.4 on Ubuntu 24.04 variant, the SSH login user is 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. Read it:

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

The first boot service writes a short, non-secret summary to this file. 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, confirm that 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.

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

This page lets you verify the server before you deploy your own site. The next step replaces it with your content.

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

df -h /var/www | tail -1

The output shows 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 that 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.

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 you can reach it 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.

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/sac-status.conf and reload Apache. Never replace Require local with Require all granted on an internet-facing server.

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.

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 reads its configuration from.

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

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

Apache serves additional sites through virtual hosts. Virtual host files live in /etc/apache2/sites-available, and you enable them 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 you reload, so a typo never takes the server down.

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

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 you enable a new module.

For any production deployment, serve the site over HTTPS so that 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.

These commands assume that 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. When it finishes, browse to https://www.your-domain.example/ to confirm the secure site.

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 archives 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.

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

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.