When your EC2-hosted website becomes inaccessible after maintenance, there are several potential causes to investigate beyond the basic checks you've already performed.

First, it's possible that your web server service (like Apache, Nginx, etc.) may have stopped running during the maintenance. You should SSH into your instance and check if the web server service is active. If not, you'll need to restart it.

Second, if your website relies on a database, check if the database connection is working properly. Database connectivity issues can cause a website to appear down even when the instance is running normally.

Third, verify that your application configuration hasn't been affected. Sometimes maintenance can reset certain configurations or cause application files to become corrupted.

Fourth, check your web server logs for any specific error messages that might indicate what's happening.

If you can't SSH into the instance using regular methods, consider using AWS Systems Manager Session Manager as an alternative access method. This requires the SSM agent to be installed on your instance and an appropriate IAM role with the AmazonSSMManagedInstanceCore policy.

Once you gain access to the instance, you can:

1. Check the status of your web server with a command like systemctl status apache2 (or nginx, etc.)
2. Restart the web server if needed: sudo systemctl restart apache2
3. Ensure the web server is set to start automatically: sudo systemctl enable apache2
4. Check database services if applicable: sudo systemctl status mysql
5. Review web server error logs in locations like /var/log/apache2/error.log

If these steps don't resolve the issue, the maintenance might have caused more fundamental changes requiring additional troubleshooting.
Sources
EC2 Website Connection Timeout | AWS re:Post
My website on EC2 reports it is running but no one can see it | AWS re:Post
Website completely blank after EC2 reboot - multiple services down | AWS re:Post

Hi everyone, Thank you for all the suggestions! It turned out that the issue was that our script was stopped by the maintenance and did not re-start automatically. We have now included a routine to re-start the script following maintenance interruptions. Thanks again for all the suggestions, it was much appreciated and helped us troubleshoot.

Thank you for the suggestions, we will try them over the weekend and see what works.

Are you using the EC2 with an automatic assigned public IP address or are you using an elastic IP?

If auto assigned the IP will have changed. If using DNS you would need to update the IP address.

Can you access the EC2 via SSM?

Hi there! I can see you've already received some good suggestions from Malini and others. Let me build on those and give you a comprehensive troubleshooting path that should get your website back online.

Root Cause: Stop/Start During Maintenance The Jan 8 maintenance almost certainly triggered a stop/start cycle on your instance (not just a reboot). This is critical because:

• Your Elastic IP stays attached
• Instance passes status checks
• BUT services and applications may not restart properly

As Malini correctly pointed out, user data scripts can re-execute during stop/start and cause issues. Let me expand on this with a complete diagnostic approach.

Step-by-Step Troubleshooting

• First: Can You Access the Instance? Before anything else, verify you can connect:

ssh -i your-key.pem ec2-user@YOUR_ELASTIC_IP

If SSH fails, try AWS Systems Manager Session Manager from the AWS Console:

Go to EC2 Console → Select your instance → Connect → Session Manager This bypasses network issues and confirms if it's a connectivity problem vs application problem.

• Check User Data Execution (Malini's suggestion - this is critical!) Once connected, check if user data re-ran and caused issues:

sudo cat /var/log/cloud-init-output.log
sudo tail -100 /var/log/cloud-init-output.log

Look for errors or timestamps matching Jan 8

sudo grep -i "error\|fail" /var/log/cloud-init-output.log

What to look for:

• Timestamps around Jan 8 (maintenance date)
• Any error messages during script execution
• Whether the script completed successfully

If you see errors here, that's likely your culprit. User data re-execution can:

Overwrite configuration files Reset permissions Fail partway through, leaving things in a broken state

• Check Web Server Status (Malini's second suggestion)

sudo systemctl status nginx

For Apache

sudo systemctl status httpd

OR on Ubuntu

sudo systemctl status apache2

Alternative check

ps aux | grep nginx ps aux | grep httpd If the service is not running: bash# Start it sudo systemctl start nginx # or httpd/apache2

Enable auto-start on boot (IMPORTANT!)

sudo systemctl enable nginx

Check if it started successfully

sudo systemctl status nginx

If the service is running but website still unreachable, continue below.

• Verify Service is Listening on Correct Port

sudo ss -tlnp | grep ':80\|:443'

Or using netstat

sudo netstat -tlnp | grep ':80|:443' Expected output: You should see your web server process listening on 0.0.0.0:80 (not 127.0.0.1:80) If bound to localhost only (127.0.0.1):

Your web server config may have been changed during user data re-execution Edit your nginx/apache config to bind to 0.0.0.0 or remove IP specification

• Test Local Connectivity

curl -I http://localhost
curl -I http://127.0.0.1

If using custom port

curl -I http://localhost:8080 If this works: Issue is network/firewall related (continue to step 6) If this fails: Issue is with the application itself (check logs in step 7)

• Check OS-Level Firewall User data re-execution can reset firewall rules:

sudo iptables -L -n -v

Check for DROP or REJECT rules

For firewalld (RHEL/CentOS/Amazon Linux)

sudo firewall-cmd --list-all

Here is Quick Script you can try

#!/bin/bash
echo "-- Instance Connectivity --"
curl -I http://localhost
echo ""

echo "-- Web Server Status --"
sudo systemctl status nginx httpd apache2 2>/dev/null | grep -E "Active:|Loaded:"
echo ""

echo "-- Listening Ports --"
sudo ss -tlnp | grep ':80\|:443'
echo ""

echo "-- Firewall Rules --"
sudo iptables -L INPUT -n | grep -E "ACCEPT|DROP|REJECT" | grep -E ":80|:443"
echo ""

echo "-- Disk Space --"
df -h | grep -E "Filesystem|/$"
echo ""

echo "-- Recent User Data Execution --"
ls -lh /var/log/cloud-init-output.log
sudo tail -20 /var/log/cloud-init-output.log