Amazon VPC and VM Import Updates

In the last couple of weeks I’ve received notification of two important updates regarding Amazon Web Services. I thought I’d share them here, as they are both relevant to use of SharePoint 2010 on EC2 and I’ve seen no mention of them elsewhere. If you’re interested in this broader topic, I’ve covered it in detail here:


My commentary here assumes some familiarity with these earlier posts. This is new functionality that enables new design options. These options should make SharePoint 2010 on EC2 more appealing for a few specific uses.

VM Import for VMware vCenter

While this first update is quite eye-catching, and will be brilliant for some scenarios, I don’t see it as massively game-changing. I first noticed it in the March 2011 AWS Newsletter, so this is pretty new stuff. I think the blurb speaks for itself:

Amazon EC2 VM Import Adds Connector for VMware vCenter
Amazon EC2 VM Import has released Connector vApp, a virtual appliance that works with VMware vCenter making it easier to import your preexisting virtual machines (VMs) to Amazon EC2. Amazon EC2 customers can use a familiar graphical user interface to select a virtual machine (VM) and specify the AWS Region, Availability Zone, operating system, instance size, security group, and VPC details (if desired) into which the VM should be imported. Once the VM has been imported, you can launch it as an instance from the AWS Management Console. For more information about this feature, see the Amazon EC2 User Guide.

I have yet to put this to the test. There may be big issues with this for all I know, but I figured it was worth spreading the word, as many people seem to be evaluating SharePoint 2010 in the cloud at the moment.

One of the “common uses” listed on the Amazon VM Import page linked above is quite clever I think:

Create a Disaster Recovery Repository for your VM images
Import your on-premise VM images to Amazon EC2 for backup and disaster recovery contingencies. Store the imported images as Elastic Block Store-backed AMIs so they’re ready to launch in Amazon EC2 when you need them. You pay no Amazon EC2 usage charges until you need to launch the instances.

This is probably the most compelling reason to consider this new functionality.

Public Addressing and the Virtual Private Cloud

The next update addresses what I saw as the major problem with Amazon EC2 for SharePoint 2010. Namely, that the Virtual Private Cloud only worked with stretched VPNs to it. There was no public addressing. This is no longer the case, as detailed in another AWS mail-out from a couple of days ago (my bold below):

We are excited to announce greatly expanded functionality of Amazon Virtual Private Cloud (Amazon VPC) that opens up the virtual networking capabilities of Amazon VPC to a much broader set of use cases. Before today, you could provision a private, isolated section of the AWS cloud and launch AWS resources into that VPC that were only accessible via an IPsec Virtual Private Network (VPN) connection to your corporate datacenter. With today’s announcement, you no longer need a VPN or existing infrastructure resources in order to leverage Amazon VPC, but can also connect to your VPC directly through the Internet – you define the virtual network that you wish to use.

With this release, you can now define a virtual network topology in the Amazon VPC that closely resembles a traditional network that you might operate in your own datacenter. You have complete control over the virtual networking environment, including selection of IP address range, creation of subnets, and configuration of route tables and network gateways. You can easily customize the network configuration for Amazon VPC, for example creating a public-facing subnet for web servers that has access to the Internet, and placing backend systems such as databases or application servers in a private-facing subnet with no Internet access.

Amazon VPC enables you to leverage multiple layers of security for access to Amazon EC2 instances, including security groups and network access control lists. Additionally, with the expanded Amazon VPC features, you can:

Divide Amazon VPC’s private IP address range into one or more public or private subnets to facilitate running applications and services in Amazon VPC.

Control inbound and outbound access to and from individual subnets using network access control lists.

Attach an Amazon Elastic IP Address to any Amazon VPC instance so it can be reached directly from the Internet.

Store data in Amazon S3 and set permissions so the data can only be accessed from within Amazon VPC.

For more information on Amazon Virtual Private Cloud, visit

The earlier design of the VPC (or more precisely, the lack of user-controlled NAT) was the major technical shortfall in the Amazon IaaS offering relative to a traditional datacentre. I haven’t yet looked at this in enough detail, as I’m not actively using EC2, so no doubt there are design nuances that will obtain. Also, the VPC and Elastic IP addresses have associated costs and this will add considerable (likely prohibitive) complexity for the network-untrained. Alternately it may require proper administration, and those associated costs.

For my personal use, I see this as a decisive improvement that will make me reconsider EC2 much more closely for testing cross-farm scenarios, perimeter security, proxies and anything that requires a full infrastructure. While much of this may have been achievable without these VPC changes, it would have been massively complex, more costly and less robust.

17-03-2011 update: as my former colleague Glyn Clough rightly points out in the comments here, I forgot to mention that EC2 also supports Windows Server 2008 R2 now, which is sweet!

15-04-2011 update: Paul Culmsee pointed out today that the VPC is still in Beta, which I’ve somehow managed to forget between December and March. This could mean pricing or other changes before RTM. Also note: Paul pointed out that the VPC does not span availability zones, which could be an issue for global organisations.

8 thoughts on “Amazon VPC and VM Import Updates”

  1. Nice article.

    From what I’ve seen in my research and testing, VPC’s by themselves don’t incur additional charges beyond what you would normally have for any instance.

    Also, DNS doesn’t function properly for instances in a VPC to the outside world be default. Amazon’s DNS servers won’t work either as they would in a normal instance. You need to specify an outside DNS server in your DHCP Options Set. See the first response from erics@aws.

  2. Hi Todd,

    I was thinking the added costs would come from the the probable use of elastic IP addresses in this scenario, rather than from the VPC proper.

    That’s good info about the outbound DNS requirement. Thanks for that!



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.