Release: Amazon Virtual Private Cloud on 2010-09-19

Release Notes>Amazon VPC>Release: Amazon Virtual Private Cloud on 2010 09 19
Amazon EC2 and Amazon VPC now support tags, which are metadata you can optionally assign to your VPC resources such as subnets.

Details

Submitted By: GeorgeNickels@AWS
Release Date: September 19, 2010 12:00 AM GMT
Latest Version: 2010-08-31
Created On: September 16, 2010 6:42 PM GMT
Last Updated: September 20, 2010 5:44 AM GMT

These release notes provide a summary of all New Features, Resolved Issues, and Known Issues in this version of the Amazon Virtual Private Cloud (Amazon VPC).

New Features

The following table describes the new features in this release.

Feature Description

New API Version

With this release, Amazon EC2 has a new API version (2010-08-31). The WSDL is at http://ec2.amazonaws.com/doc/2010-08-31/AmazonEC2.wsdl.

Tags

Amazon EC2 and Amazon VPC now support tags, which are metadata you can optionally assign to your VPC resources such as subnets.

There are three new API actions for managing your EC2 tags: CreateTags, DescribeTags, and DeleteTags. The API tools have corresponding new commands: ec2-create-tags, ec2-describe-tags, and ec2-delete-tags. To get the latest version of the API tools, go to Amazon EC2 API Tools. The AWS Management Console now also supports tags, but only for resources you can manage on the Amazon EC2 tab of the console.

For more information, see Using Tags in the Amazon Elastic Compute Cloud User Guide.

Changes to Filters for "describe" operations When you use the “Describe” operations for VPC (e.g., DescribeSubnets), you can use filters to limit the results. With the 2010-08-31 release, we've added some new filters and slightly changed the names of some of the existing filters. We've also added filtering for ec2-describe-dhcp-options and DescribeDhcpOptions. For more information go to the Amazon Virtual Private Cloud Command Line Reference or the Amazon Virtual Private Cloud API Reference.

Known Issues

The following table describes known issues in this release.

IssueDescription

Current Limitations

During the Amazon VPC public beta:

  • You can launch one VPC with one VPN connection (per AWS account)
  • You can assign one IP address range to your VPC
  • You can't change the IP address range of a created VPC or subnet
  • Cluster compute instances don't work in VPC
  • Amazon EC2 micro (t1.micro) instances are not currently supported
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, Amazon RDS, 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.
Amazon EC2 Capabilities Currently Unavailable within Amazon VPC The following Amazon EC2 features are currently not available for use with a VPC:
  • Security Groups
  • Elastic IP Addresses
  • Elastic Load Balancing
  • Spot Instances
  • Auto Scaling
  • Amazon Elastic MapReduce
  • Amazon DevPay AMIs
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 Amazon version prior to 1.02 (even if Sysprep was used)

The activation IP address 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 your image is Sysprep'd 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>
©2014, Amazon Web Services, Inc. or its affiliates. All rights reserved.