Technical FAQ

Here are a few common reasons for broken connectivity to your instance.

An instance's state is changed to running as soon as we start to boot your OS. This means there will be some delay (possibly a few minutes depending on your configuration) during which your instance will not have been fully set-up. After this period, it should be fully functional.

Additionally, you will need to make sure you have authorized the appropriate access to your host through the Amazon EC2 firewall. If you have launched your instances without specifying a security group, the default group is used. Permissions on the default group are very strict by default and disallow all access from the Internet and other groups. You will need to add permissions to your default group or you will have to set up a new group with appropriate permissions. See the developer guide for more information on the “Securing the Network”.

Assuming you have authorized port 22, a useful debugging tool is to try to open an ssh connection with verbose output. You should use the man page to get the exact syntax for your system, but the command is likely to look like ssh -vv root@[hostname]. This output would be very useful if posting to the forum.

Launch errors may be the result of an internal error during launch or a corrupt Amazon EC2 image. The former should be rare, and we actively test for and isolate suspect hosts. You should use the “DescribeInstances” API to look for more details on why your instance failed to launch.

NB: the ec2-describe-instances command line tool does not conveniently print out this information yet! You can use the -v flag to read the SOAP response from this tool and get the information discussed above.

You can always feel free to attempt to launch the image again, but if you run into a persistent problem (especially with a shared image), you should post to the Amazon EC2 forum.

This is a "feature" of the shutdown command. If you issue shutdown without a -h (halt) flag it shuts down the network and switches to single user mode. The instance is still running but without a network. You should always use shutdown -h when working inside an Amazon EC2 instance.

You can shut the instance down using the TerminateInstances call (ec2-terminate on the command line).

When you sign up with Amazon Web Services, you are given an AWS Account ID. This is your username. More detail is provided in the Getting Started Guide.

The instances themselves will be terminated and will have to be relaunched. The data on the instances' hard drives will be lost.

Always replicate important data or store it in Amazon S3.

Amazon EC2 has to move the images around the network before they can be launched. For big images and/or congested networks, this can take several minutes. Images are cached to alleviate this problem, so it should be less noticeable as you use your images more frequently.

This situation should be rare and is the result of a software error or misconfiguration. We actively monitor for it, but please let us know if you do encounter this.

Make sure that you are using the correct user ID and certificate to create and upload the image. You need to use the same ID and certificate to register the image with Amazon EC2.

This error indicates that we don’t currently have enough available capacity to service your request. During our beta, capacity is limited.

If you are requesting a large number of instances, there may not be enough server capacity to host them. You could try again at a different time or specify a smaller number of instances to launch.

This error indicates that you have reached your concurrent running instance limit. For new users during the public beta, this limit is 20.

If you need additional capacity, please contact us at aws@amazon.com.

Each user has a concurrent running instance limit. For new users during the public beta, this limit is 20.

No. Your image must be configured as a DHCP client and it will be assigned an IP.

You can use a dynamic DNS service, such as DynDNS or ZoneEdit.

You can set up NTP (the Network Time Protocol) which does this for you. You can find more information at http://www.ntp.org/. This is particularly important if you plan on using any of Amazon's web services (such as Amazon S3 or Amazon EC2) from within an instance, since requests to these services need to be timestamped.

Not at present.

Not at present. For now, if you need more capacity launch more instances.

Not at present. For now, you will have to use the SOAP API or the provided API command line tools.

With a service as flexible as Amazon EC2, customers can launch any number of load balancing systems within Amazon EC2. The load balancing instances can forward traffic to other systems. There are several open source solutions that are in wide use.

Amazon EC2 currently only provides the most basic monitoring. You can tell from DescribeInstances whether we believe your instance is running or not. However, you may regard your systems running in Amazon EC2 as your data center, and so any monitoring instrumentation that you wish to include on the systems – be it SNMP or some other mechanism – is entirely up to you.

Not at present. For now you can get the instance ID by bundling an image with your credentials and calling ec2-describe-instances. The return values contain both the hostname (which the instance knows) and the instance ID.

The following command should do the trick (assuming the command line tools have been configured correctly): ec2-describe-instances | grep $HOSTNAME | awk '{print $2}'

Not at present.

Not with any reliability. Amazon EC2 tries to shut an instance down cleanly (in which case normal system shutdown scripts will run), but there is only a short time available for things to happen and in some cases (hardware failure, for example) this does not happen. Since there is no entirely reliable way to ensure shutdown scripts run, it is best to have a strategy in place to deal with abnormal terminations.

To reduce the risk of replay attacks our requests include a timestamp. This, along with the most important parts of the request, is signed to ensure the message (including the timestamp) can't be modified without detection.

If the difference between the timestamp in the request and the time on our servers is larger than 5 minutes the request is deemed too old (or too new) and an error is returned.

You need to ensure that your system clock is accurate and configured to use the correct timezone. NTP is a good way to do this.

All instances come with internet addressable IP addresses. If you enable access through the firewall from the "world", you can address them from anywhere.