|User-specified IP address||Before this release, when you launched an instance into a VPC, an available IP address from the subnet was automatically assigned to the instance. With the 2010-06-15 API version, you can now optionally specify which one of the subnet's available IP addresses you want to assign the instance. If the address you specify is already in use, the service returns an InvalidIPAddress.InUse client error.
The ec2-run-instances command now accepts a --private-ip-address parameter. For example:> ec2-run-instances ami-1a2b3c4d --subnet subnet-5d6c7b8a --private-ip-address 10.0.0.25 ...
For more information, go to ec2-run-instances in the Amazon Elastic Compute Cloud Command Line Reference.
The RunInstances action in the Query API now takes a PrivateIpAddress parameter. The RunInstances action in the SOAP API now takes a privateIpAddress element. For more information, go to RunInstances (for the Query API) and RunInstances (for the SOAP API) in the API reference.
During the Amazon VPC public beta:
|No Support for Amazon VPC in the AWS Management Console||You can't use the AWS Management Console to execute any of the Amazon VPC API operations or launch instances into a VPC. Any instances you launch (with the command line tools or API) appear in your list of running instances that the console displays. However, the console doesn't display the IP address, subnet ID, or VPC ID of those instances. Also the console incorrectly displays "Error" or a hyphen in the Security Group field for those instances.|
|No Direct Internet Access from a VPC||Any VPC traffic to/from the Internet must currently route through the established VPN connection and through your existing IT infrastructure to the public Internet. You are currently unable to send/receive Internet traffic directly from your VPC.|
|Unsupported AWS Services Only Accessible Via VPN Connection||Amazon VPC allows you to deploy Amazon EC2 instances within your VPC. Resources provided by services such as Amazon S3, Amazon SQS, Amazon SimpleDB and others can't currently be deployed within your VPC, and, as such, are only accessible to resources within your VPC via the VPN connection, through your network, and to the respective service's public endpoint. You may need to create firewall exceptions to allow cloud-based instances to access the Internet (and possibly NAT) from your existing IT infrastructure.|
|Broadcast and Multicast Unsupported in a VPC||You are unable to employ either broadcast or multicast within your VPC.|
|Increased Latency in Bundling Linux/UNIX S3-Backed AMIs||You may experience increased latency in bundling Linux/UNIX AMIs within Amazon VPC. Such bundles are transferred from the instance, through the VPN connection, through your network and to the public Amazon S3 endpoint. You may need to create firewall exceptions to allow cloud-based instances to access the Internet (and possibly NAT) from your existing IT infrastructure."|
|Service Currently Available in One Availability Zone||Currently your VPC, subnets, VPN gateway, and any instances you launch in the VPC must all reside in a single Availability Zone in the us-east-1, or in the eu-west-1 region.|
|Traffic Sent to Overlapping IP Address Ranges Is Dropped||If your VPC's IP address range overlaps with an IP address range in use within your existing IT infrastructure, Amazon VPC will drop any traffic to said range. To avoid this, create your VPC so it does not overlap with current or expected future subnets in your network.|
|Ordering of DHCP Option Values Not Guaranteed||When you specify DHCP options, some options (e.g., DNS servers) accept multiple values. The ordering of these values is not guaranteed. After creating the options, you should use the DescribeDhcpOptions operation (or the ec2-describe-dhcp-options command) to confirm the order in which the options will be delivered to instances.|
|AWS Capabilities Currently Unavailable within Amazon VPC||The following AWS services and Amazon EC2 features are currently not available for use with a VPC:
|Configuration Changes for Windows Server 2008 AMIs||If you've created your own Windows Server 2008 AMIs from Amazon's Windows Server 2008 base images prior to v1.02, you need to make a couple of changes to your existing configuration in order to activate your instances' licensing when launching in a VPC. In some cases, you might need to make changes for v1.02 as well, depending on your needs.
Manually Locate VPC Activation EndpointsIf you want to launch a Windows Server 2008 AMI in a VPC, you must manually set the Windows Activation endpoint in your instance if either of the following conditions are true:
The activation IP address for VPC instances are:
To set the endpoint manually, execute the following commands from the command line:
Slmgr.vbs /skms 169.254.169.250 Slmgr.vbs /ato
Update Ec2Config Service Settings
If you're using an AMI that was created from an Amazon public Windows Server 2008 image prior to v1.02, then you should also make a change to one of the Activation Settings files in the Ec2Config service to reflect the new discovery hierarchy, which includes the preceding endpoints for VPC activation.
To make this change, overwrite the file
<?xml version="1.0" encoding="utf-8"?> <ActivationSettingsTable> <!-- KMS Servers are searched for/activated against based on settings in this file. Each "methodSettings" section is attempted until a KMS server is found and instance is successfully activated. --> <!-- Try autodiscovery first... --> <!-- NOTE: Autodiscover clears any KMS that is already set! --> <MethodSettings> <SetAutodiscover>true</SetAutodiscover> <TargetKMSServer/> <DiscoverFromZone/> <ReadFromUserData>false</ReadFromUserData> <LegacySearchZones>false</LegacySearchZones> <DoActivate>true</DoActivate> </MethodSettings> <!-- Try the first virtual IP for VPC instances --> <MethodSettings> <SetAutodiscover>false</SetAutodiscover> <TargetKMSServer>169.254.169.250</TargetKMSServer> <DiscoverFromZone/> <ReadFromUserData>false</ReadFromUserData> <LegacySearchZones>false</LegacySearchZones> <DoActivate>true</DoActivate> </MethodSettings> <!-- Try the backup IP for VPC instances... --> <MethodSettings> <SetAutodiscover>false</SetAutodiscover> <TargetKMSServer>169.254.169.251</TargetKMSServer> <DiscoverFromZone/> <ReadFromUserData>false</ReadFromUserData> <LegacySearchZones>false</LegacySearchZones> <DoActivate>true</DoActivate> </MethodSettings> <!-- Now search the DNS suffix list. This should already have been set by the SetDNSSuffix plugin, controlled by the setting in the primary config file. --> <MethodSettings> <SetAutodiscover>false</SetAutodiscover> <TargetKMSServer/> <DiscoverFromZone/> <ReadFromUserData>false</ReadFromUserData> <LegacySearchZones>true</LegacySearchZones> <DoActivate>true</DoActivate> </MethodSettings> <GlobalSettings> <LogResultToConsole>true</LogResultToConsole> </GlobalSettings> </ActivationSettingsTable>