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.

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 [email protected].

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

Not at present. Your image must be configured as a DHCP client and it will be assigned an IP. Currently, all instances come with internet addressable IP addresses. If you enable access through the firewall from the "world", you can address them from anywhere.

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

There is a known limitation today that prevents instances from contacting other instances via their public IP address. This is being addressed. Even when this is fixed, you should favor the internal IP/DNS name when you know you are communicating between EC2 instances. This will assure you use the lowest latency, highest throughput, and lowest cost network route.

Currently, EC2 instances cannot access instances in the new NAT environment using their public NAT IP address. Instead, the private address of an instance in the new NAT environment must be used. To help address this issue, the EC2 network will alter DNS responses from external DNS servers by replacing the public IP address for any EC2 instance in the new NAT environment with its private IP address. In this way, DNS lookups that would resolve to a public EC2 IP address will be translated to the correct internal IP address. This only works when using the UDP DNS protocol.

There is a known issue with reverse DNS of public DNS names with the new NAT instances. Since the public IP is not currently routable from within EC2, this should not be too big a problem. Use your internal IP address when possible.

The File Transfer Protocol (FTP) has a PORT command by which a client sends its address back to the server. The server then connects to the client at that address to send the file data. If the client looks up its own internal address and sends this to the server, the connection will fail. In this specific case, there are two solutions to the problem. First, the implementation of NAT that EC2 uses recognizes FTP as a special case and rewrites the PORT command address (if the ftp client connects to the server on the standard port). Second, the client can use "passive FTP" which makes connections only to the server, rather than from the server to the client. In general, applications which encode local addresses and port numbers in data sent to external servers may have problems with NAT. Care must always be taken to send the public address, rather than the internal one.

Public IP space is a limited resource. EC2 is adopting NAT to assure that we are able to efficiently make use of our public internet addresses.

Furthermore, the new NAT networking will enable Amazon to deliver new features in the future. For example, users have asked for the ability to have instances that only have internal addresses. This would allow for non-internet routable clusters which will further preserve IPs and increase security for those not running public facing servers.

From within the instance, issue the following HTTP queries:

To obtain the internal IP address:

curl http://169.254.169.254/2007-03-01//meta-data/local-ipv4

To obtain the public IP address:

curl http://169.254.169.254/2007-03-01//meta-data/public-ipv4

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 or Query 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.

From within your instance you can use REST-like queries to http://169.254.169.254/2007-03-01/ to retrieve various instance specific meta-data, including the instance ID. Refer to the Developer's Guide (section 'Using Instance Data') for the details.

Yes, although the size of the data is limited to 16K at the moment. Refer to the Developer's Guide for the details: section 'Using Instance Data' tells you how to retrieve data and the sections on the command-line tools and APIs tell you how to supply the data when launching an instance.

The Parameterized Launches feature is only available to instances that were launched after the feature was released. Therefore if you launched your instance before then, this data will not be available. We suggest you relaunch your instances if you want to use this functionality.

If after relaunching your instance you still experience problems retrieving the data, you should check:

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.

You can allow other users to launch your AMIs by modifying the AMI's launchPermission attribute. It is possible to either grant public launch permissions, which gives all users permission to launch the AMI, or to only grant launch permissions to specific users.

To grant public launch permissions:

PROMPT> ec2matt ami-5bae4b32 -t launchPermission -a -i group=all

To grant a specific user launch permissions:

PROMPT> ec2matt ami-5bae4b32 -t launchPermission -a -i userId=495219933132

To clear additional launch permissions for an AMI:

PROMPT> ec2ratt ami-5bae4b32 -t launchPermission

An AMI ID is associated with the physical bits in an image. To protect users from images being modified we require you to reregister AMIs when rebundling.

Yes. By setting the environment variable EC2_JVM_ARGS arbitrary JVM properties can be passed to the command line tools.

Yes. By passing in JVM properties via the EC2_JVM_ARGS environment variable, proxy settings can be specified for the command line tools. For example in Linux:

export EC2_JVM_ARGS="-Dhttp.proxyHost=http://my.proxy.com -Dhttp.proxyPort=8080"

The following properties are supported for configuring a proxy:

	Note
	https.proxyHost should be used when EC2_URL points to an https host, and http.proxyHost when EC2_URL points to an http host.