Can't RDP to EC2 Windows Instance? Every Fix for "Remote Desktop Can't Connect", Credentials Errors and Black Screens, Plus RDP Without Port 3389

If you can't RDP to an EC2 Windows instance, the cause is almost always one of five things. First, the security group doesn't allow TCP port 3389 from your current IP address (and home IP addresses change). Second, the instance has no public IP, or its public IP changed after a stop and start. Third, the subnet has no route to an internet gateway, or a network ACL blocks the traffic. Fourth, the instance is still booting or failing status checks. Fifth, something inside Windows is blocking you: the Windows Firewall, Remote Desktop turned off, the RDP service stopped, the port changed, or Network Level Authentication. Run Test-NetConnection <public-ip> -Port 3389 in PowerShell. If it says TcpTestSucceeded : False, the problem is the network path; if it says True but you still can't sign in, the problem is credentials or Windows. AWS's AWSSupport-TroubleshootRDP runbook can check and fix the Windows settings without logging in. You can also skip port 3389 entirely and connect through Fleet Manager Remote Desktop in the browser, Session Manager port forwarding or an EC2 Instance Connect Endpoint. Below: every error message with its fix, in the order to check them.

Jake had moved his shop's inventory software to a small Windows Server instance on EC2 so he could check stock from home. It worked for a month. Then, on a Monday morning, Remote Desktop gave him nothing but "Remote Desktop can't connect to the remote computer for one of these reasons." He had stopped the instance over the weekend to save money, his home router had restarted, and he had changed nothing else. He called Ethan, who asked two questions before even looking: "What's the instance's public IP today, and what's yours?"

New to Windows on EC2? The cards below cover the first-login password, security groups, why public IPs change, Remote Desktop on ordinary PCs, and the SSM Agent that the browser-based fixes depend on.

The 60-second test: network problem or Windows problem?

Every RDP failure falls into one of two halves, and one PowerShell command tells you which half you are in. On your own Windows PC, open PowerShell and run:

Test-NetConnection -ComputerName 3.85.120.44 -Port 3389

Use the instance's current public IPv4 address from the EC2 console, not one you saved last week. Look at the last line:

• TcpTestSucceeded : False means nothing is answering on port 3389 at that address. The problem is the network path: the address, the security group, the network ACL, the route table, your own network, or an instance that is not running Windows' RDP listener yet. Go to the network fixes.
• TcpTestSucceeded : True means the path works and something is listening. If Remote Desktop still fails, the problem is credentials, Network Level Authentication, certificates or the Remote Desktop client. Go to the login fixes and other errors.

On a Mac or Linux machine, nc -vz 3.85.120.44 3389 does the same job: "succeeded" or "open" means the port answers; a timeout means it does not.

Before you change anything, also look at the instance in the EC2 console: Instance state should be Running, and Status checks should show all checks passed. A Windows instance needs a few minutes after it starts before Remote Desktop answers, longer if Windows is installing updates.

Ethan: "Jake's test said False. Ninety percent of the time, that means the address or the security group. Let's look at both."

How RDP to an EC2 Windows instance works (and the first connection)

It helps to picture the path a Remote Desktop connection travels, because every failure is one link in this chain breaking:

1. Your Remote Desktop client (Remote Desktop Connection, mstsc.exe, on Windows; Windows App, the app formerly called Microsoft Remote Desktop, on a Mac) connects to the instance's public IP address or public DNS name on TCP port 3389.
2. The traffic crosses your own network and your internet provider, which must allow outbound port 3389.
3. It reaches the VPC through an internet gateway, and the instance's subnet must have a route to that gateway.
4. The subnet's network ACL must allow it in, and allow the replies out.
5. The instance's security group must allow inbound TCP 3389 from your IP address.
6. Inside the instance, Windows Firewall must allow Remote Desktop, Remote Desktop must be enabled, and the Remote Desktop Services service (TermService) must be running on port 3389.
7. Finally, Windows checks your user name and password, usually with Network Level Authentication first.

How to set up an EC2 Windows instance for RDP (enable RDP on AWS EC2)

"Enable RDP on AWS EC2" mostly means getting four launch settings right, because Remote Desktop itself is already switched on in every Windows AMI that AWS publishes:

1. AMI: choose a Microsoft Windows Server AMI (2019, 2022 or 2025, Base or with SQL Server). Pick an instance type with at least 2 GiB of memory; a t3.medium or larger feels far better for Remote Desktop than a t3.micro.
2. Key pair: create or select an RSA key pair and save the .pem file somewhere safe. You need it once, to decrypt the first password.
3. Network settings: for direct RDP, pick a public subnet and set Auto-assign public IP to Enable. For the safer private design, pick a private subnet and plan to use Fleet Manager or a tunnel.
4. Security group: add a rule of type RDP (TCP 3389) with source My IP. The launch wizard's "Allow RDP traffic from Anywhere" option opens it to the whole internet; change it to My IP.
5. IAM instance profile (under Advanced details): attach a role with AmazonSSMManagedInstanceCore. It costs nothing and makes Fleet Manager, Session Manager and the troubleshooting runbooks available later, which is the difference between a two-minute fix and a volume swap.

The first connection, step by step

1. In the EC2 console, select the instance and choose Connect, then the RDP client tab.
2. Choose Get password, then Upload private key file and select the .pem key pair file you chose when you launched the instance. Choose Decrypt password.
3. Note the public DNS (or public IP), the user name Administrator and the decrypted password. Choose Download remote desktop file if you like; it is an .rdp file with the address filled in.
4. Open the .rdp file (or run mstsc and enter the address), sign in as Administrator with the password, and accept the certificate warning: the instance uses a self-signed certificate, so a warning on first connection is normal.

"Password not available yet" means Windows has not finished generating it; wait at least four minutes after launch, sometimes up to fifteen. If it never appears, the instance may have been launched from a custom AMI without password generation, which our password not available guide covers. Key pairs for Windows instances must be RSA; ED25519 key pairs cannot decrypt a Windows password.

"Remote Desktop can't connect to the remote computer": the network fixes

The full message is "Remote Desktop can't connect to the remote computer for one of these reasons: 1) Remote access to the server is not enabled 2) The remote computer is turned off 3) The remote computer is not available on the network." With an EC2 instance, reason 3 is by far the most common, and it means one of the links below. Work through them in order.

1. You are using an old address

An EC2 instance's automatically assigned public IPv4 address is released when you stop the instance, and a new one is assigned when you start it. Rebooting keeps the address; stop and start does not. That is exactly what happened to Jake. Check the current Public IPv4 address in the console, update your .rdp file, and if you need a stable address, allocate an Elastic IP address and associate it with the instance. Our public IP changed after restart guide explains the options. If the instance shows no public IPv4 address at all, it was launched in a subnet that does not auto-assign one; associate an Elastic IP or use one of the no-port options. If there is no public DNS name, the VPC's DNS hostnames setting is off; the IP address still works.

2. The security group does not allow your current IP

The instance's security group needs an inbound rule: type RDP, protocol TCP, port 3389, source your public IP address as a /32. In the console, the My IP source fills in the address you have right now, and that is the trap: most home and mobile internet connections get a new public IP address from time to time (after a router restart, for example). A rule created with My IP last month matches an address you no longer have.

1. Find your current public IP address (search "what is my IP" in a browser, or run curl https://checkip.amazonaws.com).
2. In the EC2 console, select the instance, open the Security tab and choose the security group.
3. Choose Edit inbound rules and update the RDP rule's source to your current address, or add a new rule.
4. Save. Security group changes apply within seconds, and no restart is needed.

From the AWS CLI:

aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 3389 --cidr 203.0.113.25/32

Opening 3389 to 0.0.0.0/0 "just to test" works, and it also exposes the server to password-guessing bots within minutes; if you do it, close it again the moment the test is done. Security groups are explained in depth in our security group guide.

Ethan's fix for Jake took thirty seconds: the instance had a new public IP after the weekend stop, and Jake's home address had changed when his router restarted. Two stale values, one failed connection. Ethan updated the security group to Jake's new address and allocated an Elastic IP so the server's address would never move again.

3. The subnet has no route to the internet

An instance reachable from the internet must be in a public subnet: its route table needs a route for 0.0.0.0/0 to an internet gateway (igw-...). A route to a NAT gateway is not enough; NAT gateways handle outbound traffic only, so inbound Remote Desktop cannot reach an instance in a private subnet that way. Check the subnet's route table on the instance's Networking tab. If the instance is meant to stay private (the safer design), use Fleet Manager, Session Manager or an EC2 Instance Connect Endpoint instead of a public route.

4. A network ACL blocks the traffic

Network ACLs are stateless, so they need two rules: inbound TCP 3389 from your address, and outbound TCP to your address on the ephemeral ports (1024-65535) that your client uses for the replies. The default network ACL allows everything; custom ones often allow only the ports someone thought of, and the outbound reply rule is the one that gets forgotten.

5. Your own network blocks port 3389

Many company networks, hotel and airport Wi-Fi, and some internet providers block outbound connections on port 3389. If Test-NetConnection fails from the office but works from your phone's hotspot, that is your answer. The browser-based Fleet Manager Remote Desktop and Session Manager port forwarding both travel over HTTPS (port 443), so they work through those networks.

6. Let AWS check the whole path: Reachability Analyzer

If you cannot spot the problem, VPC Reachability Analyzer traces the path for you. Create a path from the instance's internet gateway (source) to the instance's network interface (destination), protocol TCP, destination port 3389, and run it. It reports either "reachable" or the exact component that blocks the path: the route table, the network ACL rule or the security group. It is billed per analysis, at a small fee, so one run to find a stubborn blocker is well worth it.

7. The instance is not ready

If the network is fine and the port still does not answer, the instance itself may not be listening yet:

• Status checks failing: a failed system status check points to the underlying AWS hardware (stop and start the instance to move it), a failed instance status check to the operating system.
• Still booting or updating: choose Actions > Monitor and troubleshoot > Get instance screenshot. A screenshot of "Working on updates, don't turn off your computer" or a boot error explains everything. Get system log shows the console output too.
• Too small or overloaded: a t3.micro running Windows Server with a few applications can stop responding. Check the Monitoring tab for CPU at 100 percent and CPU credit balance at zero, and resize if needed.

Port open, but RDP still fails: fixing Windows settings without logging in

If the network checks out but Windows itself refuses Remote Desktop, you are in a catch-22: you cannot sign in to fix the settings that stop you signing in. AWS gives you several ways around it, and the first is the best.

Run AWSSupport-TroubleshootRDP

AWSSupport-TroubleshootRDP is an AWS Systems Manager Automation runbook that reads, and can change, the settings that most often block RDP: the RDP port, Network Level Authentication, Windows Firewall profiles, the Remote Desktop Services service and whether remote connections are allowed. By default it only reads and reports. It works on instances managed by Systems Manager and also on EC2 Windows Server instances that are not.

1. Open the Systems Manager console in the same Region as the instance.
2. Choose Documents, search for AWSSupport-TroubleshootRDP on the Owned by Amazon tab, and choose Execute automation.
3. Choose Simple execution, pick the instance with the interactive picker, and choose Execute.
4. Wait for the status to change to Success, then expand Outputs to see the current RDP port, NLA, firewall and service settings.

The same runbook fixes each setting with one parameter. From the AWS CLI (replace the instance ID and Region):

# Read the current settings (no changes)
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-0123456789abcdef0, Action=Custom" --region us-east-1

# Turn off the Windows Firewall profiles
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-0123456789abcdef0, Action=Custom, Firewall=Disable" --region us-east-1

# Allow remote connections (Remote Desktop was turned off)
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-0123456789abcdef0, Action=Custom, RemoteConnections=Enable" --region us-east-1

# Set the RDP service to Automatic and start it
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-0123456789abcdef0, Action=Custom, RDPServiceStartupType=Auto, RDPServiceAction=Start" --region us-east-1

# Put the RDP port back to 3389
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-0123456789abcdef0, Action=Custom, RDPPortAction=Modify" --region us-east-1

# Turn off Network Level Authentication (instances not joined to a domain)
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-0123456789abcdef0, Action=Custom, NLASettingAction=Disable" --region us-east-1

Run the read-only version first, fix the one setting that is wrong, and connect again. Turning the Windows Firewall off entirely is a reasonable choice on EC2 because the security group already controls which addresses can reach the instance; if your company policy requires the Windows Firewall, turn it back on afterward with an inbound rule for Remote Desktop.

What each Windows-side cause looks like

• Windows Firewall blocking 3389 (someone enabled a profile or removed the Remote Desktop rule): Test-NetConnection times out even though the security group is open.
• Remote Desktop turned off (the fDenyTSConnections registry value is 1): same symptom, port does not answer.
• Remote Desktop Services (TermService) stopped or disabled: same symptom.
• RDP port changed from 3389 to something else "for security": the port you test does not answer, but another one does. Either use the new port in your client and security group (mstsc /v:3.85.120.44:3390) or set it back to 3389.
• Network Level Authentication problems on instances not joined to a domain: the connection is refused at sign-in with an authentication error.

Use Run Command if the instance is managed by Systems Manager

If the instance appears under Fleet Manager as a managed node (the SSM Agent is running and the instance has an instance profile with the AmazonSSMManagedInstanceCore policy), you can also run PowerShell on it with Run Command and the AWS-RunPowerShellScript document, or open a PowerShell session with Session Manager. These commands re-enable Remote Desktop and its firewall rule:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

The last line shows the port Remote Desktop listens on; it should be 3389. If the instance does not show up as a managed node, our SSM Agent not online guide walks through the agent, the instance profile and the network endpoints it needs.

"Your credentials did not work" and other sign-in problems

If the connection gets as far as asking for a password and then fails, the network is fine. The usual causes:

• Wrong user name. On AWS Windows AMIs the built-in account is Administrator. If your client defaults to your own PC's account or a Microsoft account, type .\Administrator (the dot means "this computer") or Administrator explicitly. For an instance joined to a domain, use DOMAIN\user.
• A copy and paste error. Decrypted passwords are long and random, and copying them can pick up a trailing space or miss a character. Type it in manually once to rule this out.
• The password was changed. The decrypted password is only the one Windows generated at first launch. If you or a colleague changed it inside Windows, the console still shows the old one. "Get password" never shows a changed password.
• The password expired. Windows local passwords can expire under the instance's password policy; reset it (see locked out).
• A user you created who is not an administrator gets "The user cannot connect to the server due to insufficient access privileges": add the user to the Remote Desktop Users group (or grant the right to log on through Remote Desktop Services in local security policy).
• The account is locked out after too many failed attempts, often by bots if port 3389 was open to the whole internet. Wait for the lockout period to end, close 3389 to the world, and reset the password.

Lost the .pem key file?

Without the private key you cannot decrypt the original password, and AWS cannot recover it for you. You can still get back in by resetting the Administrator password: the AWSSupport-ResetAccess Automation runbook uses EC2Rescue to set a new local Administrator password and stores it encrypted in Parameter Store, or you can follow the manual reset procedure with a temporary instance. After that, consider moving to Fleet Manager with IAM Identity Center so access no longer depends on one key file.

Other RDP errors on EC2, and their fixes

"An authentication error has occurred... This could be due to CredSSP encryption oracle remediation"

This appears when your PC and the instance are at different security patch levels for CredSSP, the protocol Remote Desktop uses to pass your credentials. It usually means the instance was launched from an old, unpatched AMI. The fix is to patch the instance: run Windows Update through Session Manager or Fleet Manager, or use Systems Manager Patch Manager (AWS-RunPatchBaseline). Lowering the CredSSP policy on your PC to make the error go away weakens your own machine, so treat that only as a short-term workaround and undo it.

"Your Remote Desktop Services session has ended. Another user connected to the remote computer"

Windows Server allows two concurrent Remote Desktop sessions for administration without extra licensing. A third connection pushes someone off. If several people need to work on the server at once, they need Remote Desktop Services client access licenses (CALs), which you can buy from Microsoft or get as AWS-provided Remote Desktop Services licenses through AWS License Manager user-based subscriptions.

"No Remote Desktop License Servers available" / the remote session was disconnected

Someone installed the Remote Desktop Session Host role (for example while installing an application that "needs Terminal Services") and the 120-day licensing grace period ran out. Either configure a license server with CALs, or remove the Remote Desktop Session Host role if you only need the two built-in administrative sessions. You can still connect to the console session with mstsc /v:3.85.120.44 /admin to do it.

A black screen after signing in

• Check Get system log and Get instance screenshot in the EC2 console for errors.
• Update your Remote Desktop client, and try the client's default display settings.
• Connect with mstsc /v:3.85.120.44 /admin.
• If a full-screen application has frozen, press Ctrl+Shift+Esc to open Task Manager and close it.
• If the instance is overloaded, check the Monitoring tab and change to a larger instance type.

"Remote Desktop Connection cannot verify the identity of the computer" (Mac)

This comes from older Remote Desktop clients on macOS. Install Windows App (the current name of Microsoft Remote Desktop) from the Mac App Store and connect with that.

"The identity of the remote computer cannot be verified" (Windows)

The certificate warning on first connection is expected: EC2 Windows instances use a self-signed certificate. Check that the computer name in the warning matches your instance, then choose Yes (and optionally "Don't ask me again for connections to this computer"). Companies that need no warnings install a certificate from their own certificate authority on the instance.

Jake: "Two sessions only? My assistant and I both log in to check stock."

Ethan: "Two is fine. A third person would kick one of you off. If the team grows, you buy licenses, or better, put the inventory app on a web page."

RDP to EC2 without opening port 3389

The most reliable fix for a whole class of RDP problems is to stop exposing port 3389 at all. AWS gives you three ways to reach the Windows desktop of an instance in a private subnet, with no public IP and no inbound rule from the internet.

Fleet Manager Remote Desktop (browser RDP)

Fleet Manager, part of AWS Systems Manager, opens a Remote Desktop session to a managed Windows Server instance inside your browser. Nothing has to be open inbound, which also makes it the answer when your office network blocks port 3389.

1. Make sure the instance is a managed node: SSM Agent running (version 3.0.222.0 or later), an instance profile with AmazonSSMManagedInstanceCore, and a network path to Systems Manager (internet access through a NAT gateway, or VPC endpoints for ssm, ssmmessages and ec2messages).
2. Open Systems Manager > Fleet Manager, select the node, and choose Node actions > Connect with Remote Desktop.
3. Choose the authentication type: User credentials (a Windows user name and password), Key pair (browse to or paste the .pem file), or, if you signed in to the console through IAM Identity Center, connect without extra credentials.
4. Choose Connect. Pick a resolution from the Actions menu if the default is awkward.

Things to know: sessions disconnect after 60 minutes unless you choose Renew session, and after 10 minutes idle. You can have up to four connections in one browser window, and five active connections per account and Region by default (raise it to as many as 50 with a quota increase). Copy and paste of text works both ways in Chrome and Edge; Firefox only copies from the instance to your PC. Input is English-language only. When you sign in with IAM Identity Center, Fleet Manager creates a local Windows user in the Administrators group that stays after you disconnect. The person connecting needs IAM permissions for ssm-guiconnect:StartConnection, GetConnection and CancelConnection, plus ssm:StartSession on the instance and the AWS-StartPortForwardingSession document.

Session Manager port forwarding (your own RDP client)

If you prefer the full Remote Desktop client (multiple monitors, drive redirection, your saved settings), forward a local port to the instance's 3389 through Session Manager. Install the AWS CLI and the Session Manager plugin, then run this in Command Prompt:

aws ssm start-session --target i-0123456789abcdef0 --document-name AWS-StartPortForwardingSession --parameters portNumber="3389",localPortNumber="55678"

Leave that window open, then connect Remote Desktop to localhost:55678. Press Ctrl+C in the command window to end the tunnel when you are done. If the CLI says "SessionManagerPlugin is not found", our plugin guide fixes it.

EC2 Instance Connect Endpoint (no agent needed)

An EC2 Instance Connect Endpoint is a VPC resource that lets you open a private tunnel to instances in the VPC with your IAM permissions, with no public IP and no agent on the instance. Create the endpoint in the instance's subnet (or any subnet in the VPC), allow inbound TCP 3389 on the instance's security group from the endpoint's security group, then run:

aws ec2-instance-connect open-tunnel --instance-id i-0123456789abcdef0 --remote-port 3389 --local-port 55679

and connect Remote Desktop to localhost:55679. The remote port must be 3389. This is the best choice for instances where you cannot or do not want to run the SSM Agent. Our EC2 Instance Connect guide covers the endpoint's permissions and errors.

Ethan: "Once Jake's server was working again, I took the public IP away completely. He connects through Fleet Manager now. No port to forget, no home IP to update."

RDP to an Ubuntu or Linux EC2 instance with a desktop (xrdp)

"RDP EC2 GUI Ubuntu" is one of the most searched versions of this topic: people want a graphical desktop on a Linux instance, usually to run a browser or a desktop tool in the cloud. Linux AMIs come without a desktop and without an RDP server, so you add both. The usual pair is the lightweight Xfce desktop and xrdp, an open-source RDP server, which lets you use the same Remote Desktop client you use for Windows.

1. Launch an Ubuntu instance with at least 2 vCPUs and 4 GiB of memory (a t3.medium); a desktop on a t3.micro is painfully slow.
2. Connect with SSH or Session Manager and install the desktop and xrdp:

sudo apt update
sudo apt install -y xfce4 xfce4-goodies xrdp
echo xfce4-session > ~/.xsession
sudo adduser xrdp ssl-cert
sudo systemctl enable --now xrdp
sudo passwd ubuntu

3. The last command sets a password for the ubuntu user, because Ubuntu AMIs sign in with SSH keys only and xrdp needs a password. Choose a long one.
4. Allow TCP 3389 from your IP in the security group (or skip that and tunnel, below), then connect Remote Desktop to the instance's public IP and sign in as ubuntu with that password, session type Xorg.

A safer way to reach it without opening 3389 is an SSH tunnel, ssh -i key.pem -L 33389:localhost:3389 ubuntu@3.85.120.44, then connect Remote Desktop to localhost:33389. Session Manager port forwarding (AWS-StartPortForwardingSession with portNumber="3389") works the same way for Linux instances with the SSM Agent, which Ubuntu AMIs include. If the desktop appears and closes at once, the ~/.xsession file is missing or names a desktop that is not installed. For heavier graphics work, Amazon DCV, AWS's own remote display protocol, gives a smoother experience than RDP and has no extra license charge on EC2.

RDP error messages on EC2: quick reference

Add a separate RDP user instead of sharing Administrator

Sharing the built-in Administrator password between people makes every password change a group event and every mistake untraceable. Once you are in, create a named account for each person and add it to the right group. In an elevated PowerShell window on the instance:

$pw = Read-Host -AsSecureString "Password for jake"
New-LocalUser -Name "jake" -Password $pw -FullName "Jake" -PasswordNeverExpires:$false
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "jake"
# Only if this person must administer the server:
# Add-LocalGroupMember -Group "Administrators" -Member "jake"

Members of Remote Desktop Users can sign in with Remote Desktop without full administrator rights, which is what most day-to-day users of an application server need.

Copying files to and from the instance over RDP

With Remote Desktop Connection on Windows, open Show Options > Local Resources > More and tick the drives you want to share; they appear inside the instance under This PC as redirected drives. Copy and paste of files through the clipboard also works for small files. For large or regular transfers, upload to an S3 bucket and download on the instance with the AWS CLI or Tools for PowerShell (Read-S3Object), which is faster and works for Fleet Manager sessions, where drive redirection is not available.

Completely locked out: the last-resort fixes

If the instance is not managed by Systems Manager, the runbooks above cannot reach inside it, or you need to reset a password you cannot decrypt, these options still work. All of them involve stopping the instance, so plan for a few minutes of downtime, and remember that a stop releases an auto-assigned public IP (use an Elastic IP or the private options above afterward). Take a snapshot of the root volume first.

AWSSupport-ExecuteEC2Rescue

This Automation runbook runs EC2Rescue for Windows Server against an unreachable instance. It stops the instance, creates an AMI as a backup, attaches the root volume to a temporary helper instance, fixes common problems (firewall, RDP settings, network adapter configuration and more), and puts the volume back. Data on instance store volumes is lost, and the public IP changes unless you use an Elastic IP. In the Systems Manager console, open Documents, select AWSSupport-ExecuteEC2Rescue, choose Execute automation, and enter the instance ID as UnreachableInstanceId. Optionally give an S3 bucket in LogDestination to collect the Windows logs.

AWSSupport-ResetAccess

For a lost Administrator password (or lost key pair), this runbook uses EC2Rescue to generate a new local Administrator password and saves it, encrypted, in Systems Manager Parameter Store so you can read it after the run.

Edit the registry offline (the manual method)

When automation is not an option, the classic fix is to edit the broken instance's registry from another Windows instance:

1. Stop the broken instance and note its root volume's device name (for example /dev/sda1).
2. Detach the root volume and attach it, as a second disk, to a working Windows instance in the same Availability Zone.
3. On the working instance, open Disk Management (diskmgmt.msc) and bring the disk Online.
4. Open regedit, select HKEY_LOCAL_MACHINE, choose File > Load Hive, and open \Windows\System32\config\SYSTEM on the attached disk. Give the hive a temporary name, such as broken. Export a backup first.
5. To re-enable Remote Desktop, set HKEY_LOCAL_MACHINE\broken\ControlSet001\Control\Terminal Server\fDenyTSConnections to 0.
6. To turn off the standard firewall profile, set EnableFirewall to 0 under HKEY_LOCAL_MACHINE\broken\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile.
7. Select the hive and choose File > Unload Hive, take the disk offline, detach the volume, and reattach it to the original instance with the same device name.
8. Start the original instance and connect.

EC2 Serial Console

On instances built on the Nitro system, the EC2 Serial Console gives you a text console to Windows' Special Administration Console (SAC), even when networking inside Windows is broken. It must be enabled at the account level, and SAC must be enabled inside Windows before you need it, so it is a tool to prepare in advance for important servers rather than a rescue for an instance that is already locked.

Keep RDP on EC2 working, and safe

Most RDP emergencies are avoidable with a few habits:

• Do not leave 3389 open to the world. Internet-wide scanners find open RDP ports within minutes and start guessing passwords; GuardDuty reports this as a brute force finding, covered in our GuardDuty brute force guide. Allow only your own addresses, or better, no public access at all.
• Prefer Fleet Manager or Session Manager for administration. No public IP, no inbound rule, every session logged, and access controlled by IAM.
• Use an Elastic IP if the instance must have a public address, so stop and start does not move it. AWS charges for every public IPv4 address, Elastic IPs included, at $0.005 per hour (about $3.60 a month), whether it is attached or not, so budget for it and release addresses you no longer use.
• Keep the SSM Agent running and the instance profile attached, so the runbooks and Fleet Manager work the day you need them.
• Patch regularly with Patch Manager, so CredSSP and other mismatches never appear.
• Store the key pair safely, and create a second administrator account with its own strong password for emergencies.
• Snapshot before risky changes to the firewall, RDP port or network settings.

Frequently asked questions

A week later Jake stopped the instance over the weekend again, out of habit. On Monday he opened the AWS console on his phone, went to Fleet Manager, and was looking at the inventory screen in under a minute. "No IP addresses to remember," he told Ethan. "I should have done this from the start." Ethan agreed, and set a calendar reminder to check that the SSM Agent stayed up to date.

Revision note. Written October 21, 2026. We will update this page when EC2, Systems Manager or Remote Desktop behavior changes.