Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

AWS EC2: Instance from my own Windows AMI is not reachable

Tags:

amazon-ec2

I am windows user and wanted to use a spot instance using my own EBS windows AMI. For this I have followed these steps:

  • I had my own on-demand instance with specific settings
  • Using AWS console I used option "Create Image EBS" to create EBS based windows AMI. IT worked and AMI created successfully
  • Then using this new AMI I launched a spot medium instance that was created well and now running with status checks passed.
  • After waiting an hour or more I am trying to connect it using windows 7 RDC client but is not reachable with client tool's standard error that either computer is not reachable or not powered on.

I have tried to achieve this goal and created/ deleted many volums, instances, snapshots everything but still unsuccessful. Doesn't anybody else have any solution to this problem?

Thanks

like image 977
Salik Avatar asked Dec 03 '12 18:12

Salik


People also ask

Why is my EC2 instance not reachable?

The instance may be unresponsive because you configured a static IP address. For a VPC, create a network interface and attach it to the instance. For EC2 Classic, enable DHCP. Verify that a local network configuration isn't blocking access.

How do I access my Amazon EC2 instance from Windows?

To connect to your Windows instance using an RDP clientOpen the Amazon EC2 console at https://console.aws.amazon.com/ec2/ . In the navigation pane, select Instances. Select the instance and then choose Connect. On the Connect to instance page, choose the RDP client tab, and then choose Get password.

Why AMI unable to connect to a port on an EC2 Windows?

The following issues can prevent a connection to an EC2 Windows instance on a specific port: The service that uses the port isn't running on the instance. Windows Firewall is blocking traffic to the port. A security group is blocking traffic.

Why is my EC2 Windows instance unreachable and failing one or both of its status checks?

An EC2 instance becomes unreachable if a status check fails. A system status check failure indicates a problem with the AWS systems that your instance runs on. When a problem with an underlying host impacts your production, you can stop and start your instance to migrate from the current underlying host.


1 Answers

Basically what's happening is that the existing administrator password (and other user authentication information) for Windows is only valid in the original instance, and can't be used on the new "hardware" that you're launching the AMI on (even though it's all virtualized).

This is why RDP connections will fail to newly launched instances, as will any attempts to retrieve the administrator password. Unfortunately you have no choice but to shut down the new instances you've been trying to connect to because you won't be able to do anything with them.

For various reasons the Windows administrator password cannot be preserved when running a snapshot of the operating system on different hardware (even virtualized hardware) - this is a big part of the reason why technologies like Active Directory exist, so that user authentication information is portable between machines and networks.

It sounds like you did all the steps necessary to get this working except for one - you never took any steps to cause a new password to be assigned to your newly-launched instances based on the original AMI you created.

To fix this, BEFORE turning your instance into a custom AMI that can be used to launch new instances, you need to (in the original instance) run the Ec2ConfigService Settings tool (found in the start menu when remoted into the original instance using RDP), and enable the option to generate a new password on next reboot. Save this setting change.

Then when you do create an AMI from the original instance, and use that AMI to launch new instances, they will each boot up to your custom Windows image but will choose their own random administrator password.

At this point you can go to your ec2 dashboard and retrieve the newly-generated password for the new instance based on the old AMI, and you'll also be able to download the RDP file used to connect to it.

One additional note is that Amazon warns that it can take upwards of 30 minutes for the retrieval of an administrator password after launching a new instance, however in my previous experience I've never had to wait more than a few minutes to be able to get it.

like image 186
Ryan Weir Avatar answered Oct 02 '22 08:10

Ryan Weir