Fix AWS EC2 "Windows Password Not Available Yet" Error

If your Windows EC2 instance says the password "is not available yet," the fix is almost never patience — it's figuring out which of two nearly identical-sounding AWS error messages you're actually looking at, because they mean opposite things and call for opposite fixes. Wait the 4 minutes AWS asks for. If it's still stuck after that, check your exact wording: "not available yet" is usually IAM permissions or a launch agent that never got a password-generation instruction, while "Password is not available" (no "yet") means the instance's Amazon Machine Image, or AMI — the disk-image template Amazon EC2 boots your server from — was never told to generate a random password at all, and no amount of waiting will change that.

Which error are you actually looking at?

Jake had this open in three browser tabs before he even messaged Ethan. "It says password not available. I waited. I waited longer. Nothing." Ethan asked him to read the exact sentence out loud, word for word, because in his experience half the people stuck on this problem are actually looking at two different messages and treating them as the same thing.

They look alike at a glance. They are not the same error, and AWS documents them as two separate problems with two separate fixes. Here's how to tell them apart before you do anything else.

That first row is the one almost everyone lands on, so that's where we'll spend the most time. But if your screen matches row two or three, skip straight there — you're not in a waiting problem, you're in a configuration problem, and no amount of refreshing the console fixes it.

One more thing worth doing before you touch anything else: copy the exact text of your error message somewhere you can compare it against, word for word, because the three versions above are easy to blur together after the fifth time you've read them today. Jake's shop keeps a sticky note on the monitor for exactly this kind of thing — not because it's sophisticated, but because tired eyes skim "not available" and "not available yet" as the same sentence, and this entire post exists because those two sentences aren't the same problem.

Fix 1: Actually wait the 4 minutes — and understand why it exists

To connect to a Windows instance with Remote Desktop Protocol (RDP — the built-in Windows tool for remotely controlling a computer's desktop over a network), you need an account and a password. On a freshly launched EC2 instance, that password isn't something AWS stores for you in plain text. It's generated inside the instance itself, the very first time it boots, by a small piece of software called the launch agent — either EC2Config on older Windows Server images, or EC2Launch and its newer version EC2Launch v2 on Windows Server 2016 and later.

That agent creates a random administrator password, then encrypts it using the public half of the key pair you chose when you launched the instance. A key pair is really two mathematically matched files: a public key AWS uses to lock the password up, and a private key — the .pem file that downloaded to your computer at launch — that's the only thing able to unlock it again. AWS only ever stores the encrypted version, on purpose, so nobody at AWS can read your password even if they wanted to. When you click "Get password" in the console, you're asking AWS to hand you that encrypted blob, and then your browser or the AWS CLI decrypts it locally using the private key file you supply. None of this can happen until the instance has actually finished booting Windows and the agent has run. That's the real reason for the 4-minute figure: it isn't an arbitrary throttle, it's roughly how long a fresh Windows boot plus first-run agent tasks takes.

Here's what to check, in order, once you're past the 4-minute mark:

1. Open the instance's console output (the raw boot log AWS captures from the instance — go to Actions, then Monitor and troubleshoot, then Get system log). If it's completely empty, the instance may not have finished booting at all — that's a different, boot-level problem, not a password problem.
2. If the output isn't empty, look for a line naming the launch agent and its version, something like "EC2 Agent: Ec2Config service v3.18.1118." Seeing that line at all confirms the agent is installed and ran. Then search the same log for the line Ec2SetPassword: Disabled. If you find it, the AMI was built with password generation turned off — go straight to the AMI fix below; more waiting will never produce a password.
3. If password generation isn't disabled and you're still stuck, the next most likely cause isn't the instance at all — it's your AWS account's permissions. Continue to the next section.

Fix 2: Check the one IAM permission almost nobody thinks to check

This is the part of the AWS documentation people skim past, and it's the counterintuitive part: the "still waiting" error isn't only a timing message. It's also what you see if your AWS Identity and Access Management (IAM — the AWS service that controls who is allowed to do what inside your account) user or role simply isn't allowed to ask for the password in the first place.

Retrieving the password calls an underlying action named GetPasswordData. If the IAM policy attached to your user doesn't explicitly allow ec2:GetPasswordData, the console and the CLI can both surface the exact same "not available" wording you'd see from a genuinely new instance — which is exactly why this gets misdiagnosed as a timing issue for hours.

Ask whoever manages your AWS account's permissions to confirm your user or role has ec2:GetPasswordData allowed, either directly or through a broader EC2 permission set. If you're the account owner and using the root user or an administrator-level policy, this almost never applies to you — it shows up most often on shared team accounts where someone was given a narrow, "just enough to launch instances" policy, which sounds safe right up until the day they need the one permission nobody thought to include.

This is also worth checking if you manage multiple AWS accounts under an organization, or if your company uses a permission boundary or a service control policy layered on top of individual user policies. A permission can be allowed at the user level and still get blocked further up that chain, which produces the exact same symptom from the person actually clicking the button — so if the policy on your own user looks correct and it's still failing, ask whether anything broader in the account or organization structure could be denying the action before it ever reaches you.

"Cannot retrieve Windows password": you launched without a key pair

If your exact message is "Cannot retrieve Windows password" — no mention of waiting, no mention of a custom AMI — the cause is simpler and more final than either of the errors above. You must use the private key of the key pair you specified when you launched the instance to decrypt the password. If no key pair was specified at launch, there is nothing to decrypt with, and there never will be.

The good news is this mistake is completely avoidable next time — the launch wizard in the EC2 console won't let you skip the key pair step without an explicit acknowledgment, so if you hit this, it usually means that acknowledgment box got checked without thinking, often on a rushed launch late on a Friday when everyone just wants the server running before the weekend.

Reading the retrieval screen correctly (username matters more than you'd think)

Before we get into the harder fixes, let's cover the console walkthrough properly, because a surprising number of "password won't decrypt" tickets are actually username mismatches, not encryption problems at all. The default username for the Administrator account on your instance depends on the language of the operating system baked into the AMI — for an English OS it's Administrator, for a French OS it's Administrateur, for a Portuguese OS it's Administrador. If your OS language doesn't have a matching entry, choose Administrator (Other) instead of guessing.

1. Open the Amazon EC2 console and choose Instances in the navigation pane.
2. Select your instance, then choose Connect.
3. On the Connect to instance page, choose the RDP client tab.
4. For Username, pick the entry matching your OS's language (see above).
5. Choose Get password.
6. On the Get Windows password screen, choose Upload private key file and select the exact .pem file you specified at launch — or paste its full contents into the text box.
7. Choose Decrypt password.

If step 7 fails with something like a garbled result rather than a clean error, double-check you uploaded the correct key file — it's common to have several similarly-named .pem files across different projects, and pasting the wrong one produces decryption garbage that looks like a bug but isn't. It's also worth saving a fresh copy of the decrypted password somewhere you'll actually find it next time, since re-decrypting later means finding that exact key file again.

"Password is not available" — fixing the actual AMI problem

This is the message with no "yet" in it, and it's the one that trips up people using their own custom AMIs — including AMIs made from an EC2 instance someone else already logged into and configured by hand. If your Windows instance isn't configured to generate a random password, this is exactly the wording you'll get when you try to retrieve one, and checking the console output will show Ec2SetPassword: Disabled.

To recover access to a new instance that's giving you this error, you first reset the administrator password for the source instance you used to create the AMI, since the new instance's password has to match the administrator password already on that original machine. Then, so this doesn't repeat every time you launch from the same AMI, configure the launch agent to generate a fresh password automatically at the next boot.

Console method: turn on random password generation and rebuild the AMI

1. Connect to the instance over RDP using whatever credentials currently work on it.
2. From the Windows Start menu, open EC2ConfigService Settings (Windows Server 2008 through 2012 R2) or EC2 Launch Settings (Windows Server 2016 and later).
3. For Administrator Password, choose Random.
4. Choose Shutdown without Sysprep, then confirm. Sysprep is a Windows tool that strips a machine's unique identity so it's ready to be cloned into a fresh template; you skip it here because you're only changing a setting, not turning this specific server into a generic starting point for others.
5. Back in the EC2 console, wait until the instance shows a Stopped state, then select it.
6. Choose Actions, then Image, then Create image, and give it a name.
7. Choose Create image. Every instance you launch from this new image afterward will decrypt its password with a key pair as expected.

PowerShell method: schedule it without opening the settings dialog

For Windows Server 2016 and 2019 instances running EC2Launch, you can skip the GUI entirely and schedule the password-generation script to run once, automatically, on the next boot:

PS C:\> C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -Schedule

This runs one time during the next boot and then deactivates the scheduled task so it doesn't run repeatedly on every subsequent restart.

Getting the password from the AWS CLI instead of the console

Jake avoids anything that looks like a command line, but Ethan pushed back on that instinct here. "You already have a terminal open half the day for something else. This is one line."

The command is get-password-data, and it retrieves the encrypted administrator password directly, decrypting it locally with the private key file you point it at:

aws ec2 get-password-data --instance-id i-1234567890abcdef0 --priv-launch-key C:\Keys\MyKeyPair.pem

A working response comes back with the decrypted password sitting in a field called PasswordData, alongside the instance ID and a timestamp.

Here's the detail that trips people up, and it's the second real "gotcha" in this whole topic: PasswordData returns an empty string if the password isn't available — not an error, not an exception, just a quiet empty value. If you're scripting this as part of an automated build pipeline and only checking whether the command "succeeded," you can sail right past a genuinely missing password without noticing, because the CLI call itself completes fine either way.

Also worth knowing if you're rebundling AMIs for repeated use: for the EC2Config service specifically, the password is not generated for rebundled AMIs unless Ec2SetPassword was re-enabled before bundling — which is exactly the setting the console walkthrough above turns back on.

The adjacent task that trips people up right after this one works: once you've got the password, you still need the AWS CLI itself configured with credentials and a default Region before get-password-data will run at all. If the command comes back complaining it can't find your instance rather than returning empty or garbled data, that's usually not a password problem either — it's the CLI pointed at the wrong Region, or not authenticated yet. Running aws configure once, with an access key, a secret key, and the Region your instance actually lives in, clears that up before you even get to the password question.

Lost your password or key pair entirely: the reset options, cheapest to most involved

Sometimes there's no shortcut around the fact that access is genuinely gone — an employee left with the only .pem file on their laptop, a backup wasn't taken, or the password was changed by someone who's no longer around to ask. AWS gives you four real ways back in, and they trade off convenience against how much they touch the running instance.

Option A: EC2Rescue via Systems Manager Run Command (instance keeps running)

This is the least disruptive path, but it only works if the instance is already set up for AWS Systems Manager, a service for managing and running commands on fleets of instances remotely, with the Systems Manager agent installed, and the instance has internet access through a public IP address or a NAT gateway — a component that lets instances without their own public address still reach the internet — or a configured VPC endpoint using AWS PrivateLink.

1. Attach a policy to the instance's IAM role allowing the action ssm:PutParameter on the resource path parameter/EC2Rescue/Passwords/i-* — this is what lets the tool write the new encrypted password somewhere you can retrieve it.
2. Open the Systems Manager console and choose Run Command, then Run a Command.
3. For Command document, choose AWSSupport-RunEC2RescueForWindowsTool.
4. Confirm the Command parameter is set to ResetAccess.
5. Under Targets, choose Choose instances manually and select your instance.
6. Choose Run.
7. Once it finishes, select your instance's ID in the Targets and outputs section and choose View output for instructions on retrieving the new password.

The new password gets written, encrypted, into a part of Systems Manager called Parameter Store — a secure storage location for configuration values and secrets that you'd otherwise have to manage yourself. Once you're back in, rotate the password again through Windows itself and delete that parameter, so a working password isn't sitting in Parameter Store any longer than it needs to be.

Option B: AWSSupport-ResetAccess automation (instance stops and restarts)

This is the hands-off option for either a lost key pair or a lost password, and it's a Systems Manager Automation document — a scripted, multi-step workflow — that uses AWS CloudFormation, a service that provisions a defined set of AWS resources automatically from a template, and AWS Lambda, a service that runs small pieces of code without you having to manage a server for it, to carry out an offline EC2Rescue password reset without you touching any of the individual steps yourself.

1. Open the Systems Manager console, choose Automation, then Execute automation.
2. For Automation document, choose AWSSupport-ResetAccess, then choose Next.
3. For Input parameters, enter your instance's InstanceID.
4. Choose Execute, then wait for the state to change to Success — this can take up to 25 minutes, and you can watch its progress under Executed steps.
5. Use your existing key pair to decrypt the newly generated password from the EC2 console, the same way you would for any new instance.

If the scenario is specifically a lost key pair rather than a lost password, the automation creates a password-activated AMI you can launch a brand-new instance from, selecting a key pair you actually still own — look in the EC2 console under AMIs for one named starting with AWSSupport-EC2Rescue-Post-Script-Backup, followed by your instance ID and a date. Launch from that AMI, confirm your applications work the way you expect on the new instance, and only then terminate the old one.

Option C: Manual EC2Rescue with a temporary helper instance (full control)

This is the version with no automation wrapped around it — useful if the automated document doesn't fit your setup, or you just want to see every step yourself. It works by physically moving your instance's boot disk onto a second, healthy instance temporarily, running the fix against it there, and moving it back.

1. Create or choose a temporary helper instance in the same Availability Zone as the one you're fixing, with RDP access already working on it.
2. Take a snapshot or AMI backup of the instance that needs its password reset, as a safety net.
3. Stop the instance that needs the reset.
4. Detach its root volume, then attach that same volume to the helper instance as a secondary volume.
5. On the helper instance, download and run the EC2Rescue for Windows Server tool.
6. In the tool, choose Offline Instance, then select the volume you just attached.
7. Choose Diagnose and Rescue, then under Detected possible issues, select Reset Administrator Password (or the Ec2SetPassword check box, depending on the tool version) and continue through the wizard.
8. Detach the volume from the helper instance and reattach it to the original instance as its root volume, then start the original instance again.
9. Once it's running and passing status checks, retrieve the password through the console or CLI as normal — it should decrypt cleanly now.

Option D: Fleet Manager's Reset Node User Password (a different Fleet Manager feature than the RDP shortcut below)

Worth being precise here, because Fleet Manager actually offers two separate things people conflate: connecting over RDP without a password at all, covered next, and directly resetting the password for any user on a managed node. This second feature requires encryption to already be configured for AWS Systems Manager Session Manager using an AWS KMS key — a service that creates and manages the encryption keys used to protect data — and the instance's IAM role needs kms:Decrypt permission on that specific key. If that's already set up, open Fleet Manager, select the node, choose Node actions, then Node Settings, then Reset Node User Password, pick or type the username, and follow the prompt to set a new password on the spot.

The option nobody mentions: skip the password entirely

Here's Ethan's actual opinion, stated plainly: for anyone who connects to Windows instances often, chasing key pairs and decrypting passwords is the slow way to do this now, and most people simply haven't been told there's a faster one.

Fleet Manager, a capability inside AWS Systems Manager, lets you connect to your own Windows Server instances over RDP directly from the Systems Manager console — powered by Amazon DCV, AWS's remote-display technology — without ever touching a key pair or a decrypted password screen. You can view up to four instances at once in the same browser window.

To use it: open the EC2 console, choose Instances, select your instance, choose Connect, then on the RDP client tab set Connection Type to Connect using Fleet Manager, and choose Fleet Manager Remote Desktop. Enter your credentials and choose Connect. You don't need to specifically open incoming RDP traffic from your IP address for this to work — Fleet Manager handles that itself, which is precisely the point: your instance's RDP port never has to be exposed to the public internet at all.

Cleaning up afterward: don't leave a working password lying around

This is the part almost every guide skips, and it's the closest thing this topic has to a genuine safety angle. If you used the Systems Manager Run Command path, your new password was written into Parameter Store in encrypted form so you could retrieve it — but "encrypted and sitting there" is still worse than "not sitting there at all." Once you've confirmed you're back into the instance, change the password again from inside Windows and delete the parameter from Parameter Store, so there's no longer a copy of a working credential parked in your AWS account waiting to be read by anyone with access to that parameter path.

The same logic applies to any .pem key pair file you had to dig up or re-download during this process — if it ended up copied into a shared drive, a support ticket, or a chat thread while you were troubleshooting, that's the moment to actually delete those copies once you're done, not "later."

It's also worth writing down, somewhere your team will actually find it, exactly which fix solved it this time — the IAM permission that was missing, the AMI that needed rebuilding, or the fact that the instance simply needed the full 4 minutes. Jake's shop keeps a running note taped inside a supply cabinet of "things that broke and how we fixed them," which sounds almost too simple to mention, except that it's the reason the second time this happens to him, it takes five minutes instead of an afternoon.

Edge cases that don't fit the standard fix

You created the AMI yourself, from an instance someone else logged into

This is the single most common way people accidentally end up on "Password is not available." If instance A was configured with a fixed, remembered password and then imaged into an AMI without ever re-enabling random password generation, every instance launched from that AMI inherits the same fixed password behavior — and none of them can hand you a freshly generated one through the console. The fix is the AMI rebuild covered earlier, done once, upstream, so it doesn't repeat on every future launch.

Encrypted root volumes

If your instance's root Amazon EBS volume is encrypted, the AWSSupport-ResetAccess automation simply won't run against it — that's a documented, hard limitation, not a bug you can work around with a retry. For an encrypted root volume, the manual EC2Rescue path with a temporary helper instance, or the Systems Manager Run Command path if it's already set up, are the ones left on the table.

Auto Scaling groups and launch templates

If the affected instance is managed by an Auto Scaling group, don't just stop it to apply a fix — detach it from the group first, then stop and start it, then attach it back, or the group may simply replace it while you're mid-fix and you'll be back where you started on a brand-new instance with the exact same problem.

Instance store volumes

If the instance has any instance store volumes — the ones that live on physical storage attached to the underlying host rather than persistent Amazon EBS storage — stopping the instance to reconfigure the password agent, or to run an offline reset, removes any data sitting on those volumes. Move anything you need off them first.

Your key pair worked yesterday, in a different region

Key pairs are scoped to a single AWS Region — a key pair you created while working in one Region is only ever usable for instances launched in that same Region, and Amazon EC2 says so directly: the key pair you're handed back "is available only in the Amazon Web Services Region in which you create it." If you keep a folder of similarly-named .pem files for different projects and grabbed the wrong one because a teammate's instance happens to sit in a different Region than yours usually does, the decrypt step won't quietly warn you about that — it just fails the same way a genuinely wrong key does. Double-check the Region shown in the top-right corner of the console matches the Region you generated that key pair in before you assume the key itself is broken.

Do you actually need a third-party tool for this?

Jake found three browser extensions promising to "auto-fix" EC2 password errors before he asked Ethan about any of this. Ethan's answer was blunt: no, and be careful installing anything that asks for your AWS credentials to solve a problem AWS's own console, CLI, and Systems Manager already solve natively. Every fix in this post — retrieving the password, resetting it, or bypassing it entirely through Fleet Manager — is a built-in AWS capability with no extra software, no extra cost beyond what you're already paying for the instance and any Systems Manager usage, and no third party holding your decrypted credentials at any point. If you come across a tool promising a shortcut around any of the steps above, the honest comparison is: it's doing exactly what get-password-data or Fleet Manager already does, just with an extra party now able to see your instance's login.

When none of this works

Be honest with yourself about where you are on this list. If you've confirmed the exact error wording, waited past 4 minutes, checked ec2:GetPasswordData permissions, checked console output for Ec2SetPassword: Disabled, and you launched with a real key pair — and it still won't decrypt — the most reliable remaining path is the AWSSupport-ResetAccess automation or, if the root volume is encrypted, the manual EC2Rescue steps with a helper instance, because both are designed specifically to rebuild password access from a known-good state rather than guess at what's wrong.

If you genuinely don't know the original administrator password, the AMI was built with password generation disabled, you have no key pair that matches anything on the instance, and the root volume is encrypted so the automated document is off the table too, there is a hard stop here worth naming plainly: at that point you're relying entirely on the manual EC2Rescue path with a helper instance. If even that can't reach the disk for some reason, the account you're trying to use to log in is a dead end. The instance itself isn't lost, and its data on EBS volumes generally isn't either, but plan around building a new access path rather than continuing to retry the old one.

Frequently asked questions

How long should I actually wait before the password is ready?

AWS's own guidance is at least 4 minutes after launch before trying to retrieve the auto-generated password, with the password typically available within a few minutes of that. If it's been noticeably longer and nothing has changed, treat it as a configuration issue rather than a timing one.

Why do I still get "not available yet" after 10, 20, or even 60 minutes?

Past the 4-minute mark, this usually means the launch agent isn't configured to generate a password (verify by checking the console output for the Ec2SetPassword line), or the IAM account you're using isn't allowed to call ec2:GetPasswordData.

What's the difference between "Password is not available" and "Password not available yet"?

"Not available yet" implies timing and is often resolvable by waiting or checking permissions. "Password is not available" (no "yet") means the instance's AMI was launched with password generation not configured, or the default password was changed — this is permanent until you fix the AMI or reset the password.

Why does the AWS CLI get-password-data command return an empty string?

The PasswordData field in the CLI's response returns an empty string specifically when the password isn't available yet, rather than throwing an error. If you're automating this, check for an empty value, not just command success.

Do I need a specific IAM permission to get the Windows password?

Yes — your IAM account needs the ec2:GetPasswordData action allowed to retrieve the password through either the console or the CLI. Without it, the request can fail in a way that looks identical to a timing error.

What if I never created or specified a key pair when I launched the instance?

You'll see "Cannot retrieve Windows password" with no wait-related wording. There's no key to decrypt with, so this can't be fixed on the running instance directly — you'd terminate it and relaunch from the same AMI with a key pair specified, or use the AWSSupport-ResetAccess automation or Fleet Manager's Reset Node User Password to restore access without one.

Can I recover the password if I lost my .pem key pair file entirely?

Yes, if the root volume isn't encrypted. The AWSSupport-ResetAccess automation can create a password-activated AMI from your current instance so you can launch a fresh one with a key pair you still own, or the manual EC2Rescue path with a helper instance can reach the disk directly if the automated document doesn't apply to your setup.

Why does my instance say "Ec2SetPassword: Disabled" in the console output?

This means the AMI you launched from was created with password generation deliberately turned off, usually because a prior instance was imaged without re-enabling random password creation first. Reconfigure the launch agent to generate a random password and rebuild the AMI to fix it for future launches.

Will stopping and starting my instance delete my data?

Data on any instance store volumes is removed when you stop the instance. Data on Amazon EBS volumes persists through a stop and start. Confirm which storage type your instance uses before stopping it to apply a password-agent fix or run an offline reset.

Does stopping and starting change my instance's public IP address?

Yes, if the instance has an associated public IP address rather than an Elastic IP address, stopping and starting it releases that address and assigns a new one. If you need the address to stay fixed, use an Elastic IP address instead.

What happens if my instance is part of an Auto Scaling group?

Detach the instance from the Auto Scaling group before you stop and start it, then reattach it once you're done, so the group doesn't quietly replace it while you're mid-fix.

Can I connect to my Windows instance without ever retrieving a password?

Yes — Fleet Manager, part of AWS Systems Manager, lets you RDP into your own Windows Server instances directly from the Systems Manager console without a key pair or decrypted password, and it handles the RDP network access for you so the port doesn't need to be publicly open.

Can Fleet Manager reset my password too, not just connect me without one?

Yes, but it's a separate feature from the passwordless RDP connection: Reset Node User Password requires encryption already configured for Session Manager through an AWS KMS key, plus kms:Decrypt permission on that key for the instance's IAM role. With that set up, you can set a new password for any user on the node directly from Fleet Manager.

I finally got back in — is there anything I should clean up afterward?

Yes. If you used the Systems Manager Run Command reset, the new password was written into Parameter Store in encrypted form — change the password again from inside Windows and delete that parameter once you're confirmed back in, so a working credential isn't left sitting there.

Why is my username wrong even though the password decrypted fine?

The default Administrator username depends on the language of the operating system in the AMI — for example, Administrateur for a French OS or Administrador for a Portuguese OS. If your OS's language doesn't have a matching localized entry, choose Administrator (Other) rather than assuming plain "Administrator."

What should I do if none of these fixes work?

Run the AWSSupport-ResetAccess automation through AWS Systems Manager if your root volume isn't encrypted, or fall back to the manual EC2Rescue steps with a temporary helper instance if it is. Both exist specifically to rebuild administrator access on EC2 Windows instances from a known-good state.

Revision note. Written September 2026. AWS occasionally renames console menu paths and settings dialogs, so if a step above no longer matches what you see, the underlying agent behavior described here should still hold. If you're reading this at 1am with a customer waiting on a server you can't get into, take a breath — every path in this post ends somewhere, even the ones that start with "you're locked out for good."