AWS EC2 Access Guide When Browsers Are Blocked

Select Language:

If your EC2 instance suddenly becomes unreachable through a browser or SSH (PuTTY), don’t worry—there are ways to troubleshoot and fix the problem without needing paid support.

The most common reason for losing access is that something on the server crashed, security settings changed accidentally, or services stopped running altogether.

First, check the health of your instance in the EC2 console. Make sure the instance state shows “running.” Look at the status checks—if everything has passed (usually indicated as 2/2), then the problem is likely with services or settings. If a check failed, that points to the issue.

Next, view diagnostic information to gather clues. You can do this from the console by clicking on your instance, then selecting “Actions,” then “Monitor and troubleshoot.” Choose “Get system log” to see boot and system messages, and “Get instance screenshot” to see what is currently displayed on the screen. These logs often tell you what failed—like a service crashed, the disk is full, or there’s a kernel panic.

If SSH or browser access isn’t working, you can still connect using AWS Systems Manager Session Manager. For this, your instance needs the Systems Manager agent installed (it’s pre-installed on Amazon Linux 2, Ubuntu 16.04+, Windows Server 2016+) and an IAM role attached with the AmazonSSMManagedInstanceCore policy. From the console, go to Systems Manager, then Session Manager, and start a new session to your instance. This is a safe way to access your server without SSH.

Once connected through Session Manager, run some basic commands to see what might be wrong. Check the status of your web server (like Apache or Nginx), your database (MySQL, MariaDB, PostgreSQL), disk space, and system logs. For example:

Check web server status: sudo systemctl status apache2 or httpd or nginx
Check database: sudo systemctl status mysql or your database service
Check disk space: sudo df -h
Check system performance: sudo top
Review logs: sudo journalctl -xe

Problems often happen because services didn’t restart after a reboot, the disk is full, or the server is overwhelmed with too much CPU or memory use.

If you identify a service isn’t running, just start it again with:

sudo systemctl start apache2 (or your web server)
sudo systemctl start mysql (or your database)

You can also enable these to start automatically on reboot with:

sudo systemctl enable apache2
sudo systemctl enable mysql

If the server still won’t respond, try rebooting it through the console: go to Actions, then Instance State, then Reboot. This is a quick fix for temporary freezes and is safe unless you have ongoing data writes.

Verify your security group settings to make sure the rules weren’t changed. The SSH port (22) should be open to your IP address. Ports 80 and 443 should be accessible to everyone (0.0.0.0/0). Also, review Network ACLs for any restrictions.

If nothing works, the last resort is to stop the instance (but do not terminate it), take a snapshot of the root volume for backup, then restart the instance. Sometimes, this can resolve underlying hardware issues. Alternatively, detach the root volume, attach it to another instance, then recover data or make configuration changes.

You do not need to pay for support for these steps. Free options include posting questions on AWS re:Post, where the community can help, or using the AWS Support Center for account or billing inquiries. The AWS Health Dashboard can alert you to any regional service outages that may be affecting your instance.

Start your troubleshooting by reviewing the system log and instance screenshot, as these often explain why your server stopped responding. This approach can help you solve the problem without extra cost or complex steps.