Whether you're taking your first steps with Kubernetes or you're an experienced practitioner looking to sharpen your skills, our Amazon EKS workshop series delivers practical, real-world experience that moves you forward. Learn directly from AWS solutions architects and EKS specialists through hands-on sessions designed to build your confidence with Kubernetes. Register now and start building with Amazon EKS!
How do I troubleshoot RDP connection issues with my EC2 Windows instance?
I can't use Remote Desktop Protocol (RDP) to connect to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.
Resolution
You might receive RDP connection issues for one of the following reasons:
- Remote access to the server is turned off.
- The remote computer is turned off.
- The remote computer is unavailable on the network.
- The IP address that you want to connect is incorrect.
- The port for RDP traffic is changed or in use by another service.
- The security group that's attached to the instance doesn't allow RDP traffic from your IP address.
- The Remote Desktop Service (TermService) isn't running inside the operating system (OS).
- The OS firewall doesn't allow inbound connections on port 3389.
To resolve connection issues, review your settings. If there are no necessary changes to your settings, then use the EC2Rescue tool to Diagnose and Rescue your instance. Or, use EC2Rescue to set the instance to a Last Known Good Configuration.
Use EC2Rescue Diagnose and Rescue
Complete the following steps:
- Create a temporary instance in the same virtual private cloud (VPC), Availability Zone, and subnet as the affected instance.
- Stop the affected instance, and then detach its root volume.
- Attach the volume to an existing Windows instance that you can use RDP with.
- Download and run EC2Rescue on the temporary instance.
- Choose Offline Instance.
- Select the affected disk.
- After the volume successfully loads, choose Diagnose and Rescue.
Note: You will see a list of issues that can be fixed. The issues that prevent access are listed as red icons. - Use disk management to take the impaired volume offline and detach it. Then, attach the volume as the root volume to the original instance. Make sure that the device ID is /dev/sda1.
- Use RDP to try to connect to your instance again.
Restore to Last Known Good Configuration
Complete the following steps:
- Launch a new test instance in the same subnet as the affected instance.
- Stop the affected instance.
- After the instance is stopped, detach the root volume and attach it to the helper instance.
- Download EC2Rescue, and then extract it from the ZIP file.
- Run the EC2Rescue application as administrator, and then choose Offline instance.
- Select the offline volume that you attached in step 3, and then choose Next.
- Choose Restore, and then choose Last Known Good Configuration (LKGC). Then, choose Restore.
Additional troubleshooting steps
Check the instance status
To check the instance status, capture a screenshot of the instance.
If the instance OS successfully boots, but fails instance status checks, then there's an issue with the OS network adapter drivers. Or, the OS network isn't correctly configured.
To resolve this issue, complete the following steps:
- Create a secondary elastic network interface.
- Attach the secondary network interface to the instance.
- Use RDP to test the instance connection.
Use Systems Manager
If the preceding troubleshooting steps don't resolve your issue, then use the AWS Systems Manager AWSSupport-TroubleshootRDP runbook.
For more information about how to manually troubleshoot connection issues, see Remote Desktop can't connect to the remote computer.
These instructions are useless. Step 1 refers to an article listing commands to be run on the instance: THIS CANNOT BE DONE IF THE AWS CUSTOMER CANNOT CONNECT TO RDP Step 2 is only if the AWS Instance control panel reports failed checks. THIS IS USELESS IF THE AWS PANEL DOESN'T REPORT ANY ERRORS AND DOESN'T SAY WHAT IT TESTED! Step 3 depends if the network is using an AWS NAT Gateway, but the link is a general concept introduction and DOESN'T DIRECTLY SAY HOW TO CHECK IF AN INSTANCE THAT CANNOT BE REACHED IS DOING THAT Step 4 asks the AWS customer to remotely check if port 3389 is open on the public IP, and then refers to the overly generic documentation for the TCP test command on the AWS customer's own PC. THIS PROVIDES NO INFORMATION ON WHAT TO DO IF THE TCP PORT ISN'T OPEN ACCORDING TO THE TEST!
Thank you for your comment. We'll review and update the Knowledge Center article as needed.
I echo what AWS-User-4644975 said. I tried step 4 (remotely check if port 3389 is open on the public IP using powershell command), the test failed but there is no information on what to do next. What should the next steps be to open this port?
Thank you for your comment. We'll review and update the Knowledge Center article as needed.
I had issues connecting to an EC2 Windows instance using RDP. In my case, the problem was caused by an incorrectly configured VPC.
So running a command like this went into timeout:
nc -zv 35.X.X.X 3389
I inspected the VPCs Route tables and noticed that there is no public gateway configured (no idea how this happened as I had no issues connecting in the past).
After adding an igw, it worked without issues.
Relevant content
- asked 2 years ago
- asked 3 years ago
- asked 8 months ago
