Release: Amazon Virtual Private Cloud on 2011-03-27

Release Notes>Amazon VPC>Release: Amazon Virtual Private Cloud on 2011 03 27
New Dedicated Instances option for instances launched into a VPC, and a new API version: 2011-02-28

Details

Submitted By: Francis@AWS
Release Date: March 27, 2011 7:00 AM GMT
Latest Version: 2011-­02-­28
Latest WSDL: http://ec2.amazonaws.com/doc/2011-­02-­28/AmazonEC2.wsdl
Created On: March 28, 2011 5:57 AM GMT
Last Updated: March 28, 2011 5:57 AM GMT

New Features

FeatureDescription
New API Version With this release, Amazon VPC has a new API version (2011-02-28). The WSDL is at http://ec2.amazonaws.com/doc/2011-02-28/AmazonEC2.wsdl. To get the latest version of the API tools, go to Amazon EC2 API Tools.
New Amazon EC2 Dedicated Instances Dedicated Instances are Amazon EC2 instances launched within your Amazon Virtual Private Cloud (Amazon VPC) that run hardware dedicated to a single customer. Dedicated Instances let you take full advantage of the benefits of Amazon VPC and the AWS cloud—on-demand elastic provisioning, pay only for what you use, and a private, isolated virtual network&emdash;all while isolating your Amazon EC2 compute instances at the hardware level.

Known Issues

IssueDescription

Windows Server 2008 R2

Windows Server 2008 R2 is not currently supported in Amazon VPC.

SQL Server Reserved Instances

SQL Server Reserved Instances are not currently supported in Amazon VPC.

Current Limits

With the current implementation of Amazon VPC:

  • You can have one VPC per AWS account per Region
  • You can assign one IP address range to your VPC
  • You can't change the IP address range of a created VPC or subnet
  • If you plan to have a VPN connection to your VPC: You can have one VPN gateway, one customer gateway, and one VPN connection per AWS account per Region
  • Other VPC resources are limited (go to Appendix B: Limits in the Amazon Virtual Private Cloud User Guide)

Current Service Limitations

With the current implementation of Amazon VPC:

  • Your VPC, subnets, and any instances you launch in the VPC must all reside in a single Availability Zone in the us-east-1 or eu-west-1 region.
  • You can't use either broadcast or multicast within your VPC.
  • Amazon EC2 Spot Instances, Cluster Instances, and Micro Instances are not available in a VPC.
  • AWS Elastic Beanstalk, Elastic Load Balancing, Amazon Elastic MapReduce, Amazon Relational Database Service (Amazon RDS), and Amazon Route 53 are not available.
  • Amazon DevPay paid AMIs are not available in a VPC.
Older API Version Clients and Latest Console Display Different Results If you use a client that is based on an older API version of Amazon VPC, but you also use the AWS Management Console to manage your VPC resources, you'll see different results between the two interfaces.
Elastic IP Addresses Not Interchangeable Any EC2 Elastic IP addresses your AWS account has cannot be used with your VPC, and any VPC Elastic IP addresses you have can't be used with EC2.
Security Groups Not Interchangeable Any EC2 security groups your AWS account has cannot be used with your VPC, and any VPC security groups you have can't be used with EC2.
Traffic Sent to Overlapping IP Address Ranges Is Dropped For customers using the optional IPsec VPN gateway: 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.
Tags for Amazon VPC Resources Not Supported in the Console You can tag your Amazon VPC resources using the API or command line tools, but those tags are not available to work with in the AWS Management Console.
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 Endpoints

If 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:
  • You have created your own Windows Server 2008 AMI but opted not to Sysprep that image using the Amazon Ec2Config utility (this is true for all Windows Server 2008 AMI versions)
  • You have created your own AMI from an Amazon version prior to 1.02 (even if Sysprep was used)

The activation IP addresses for VPC instances are:

  • 169.254.169.250
  • 169.254.169.251 (backup)

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 C:\Program Files\Amazon\Ec2ConfigService\Settings\ActivationSettings.xml with the following XML. Once you do that, anytime you Sysprep your image with the Ec2Config service utility, your freshly launched instance will be able to locate its KMS servers in any environment.

<?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>
©2013, Amazon Web Services, Inc. or its affiliates. All rights reserved.