Introducing Amazon Virtual Private Cloud (VPC)

Amazon Virtual Private Cloud (Amazon VPC) lets you create your own logically isolated set of Amazon EC2 instances and connect it to your existing network using an IPsec VPN connection. This new offering lets you take advantage of the low cost and flexibility of AWS while leveraging the investment you have already made in your IT infrastructure.

This cool new service is now in a limited beta and you can apply for admission here.

Here’s all you need to do to get started:

1. Create a VPC. You define your VPC’s private IP address space, which can range from a /28 (16 IPs) up to a /18 (16,384 IPs). You can use any IPv4 address range, including Private Address Spaces identified in RFC 1918 and any other routable IP address block.
2. Partition your VPC’s IP address space into one or more subnets. Multiple subnets in a VPC are arranged in a star topology and enable you to create logically isolated collections of instances. You can create up to 20 Subnets per VPC (you can request more using this form). You can also use this form to request a VPC larger than a /18 or additional EC2 instances for use within your VPC.
3. Create a customer gateway to represent the device (typically a router or a software VPN appliance) anchoring the VPN connection from your network.
4. Create a VPN gateway to represent the AWS end of the VPN connection.
5. Attach the VPN gateway to your VPC.
6. Create a VPN connection between the VPN gateway and the customer gateway.
7. Launch EC2 instances within your VPC using an enhanced form of the Amazon EC2 RunInstances API call or the ec2-run-instances command to specify the VPC and the desired subnet.

Once you have done this, all Internet-bound traffic generated by your Amazon EC2 instances within your VPC routes across the VPN connection, where it wends its way through your outbound firewall and any other network security devices under your control before exiting from your network.

IP addresses are specified using CIDR notation, where the value after the slash represents the number of bits in the routing prefix for the address. You’re currently limited to one VPC per AWS account, however, if you have a use case requiring more, let us know and we’ll see what we can do.

Because the VPC subnets are used to isolate logically distinct functionality, we’ve chosen not to immediately support Amazon EC2 security groups. You can launch your own AMIs and most public AMIs, including Microsoft Windows AMIs. You can’t launch Amazon DevPay AMIs just yet, though.

The Amazon EC2 instances are on your network. They can access or be accessed by other systems on the network as if they were local. As far as you are concerned, the EC2 instances are additional local network resources -- there is no NAT translation. EC2 instances within a VPC do not currently have Internet-facing IP addresses.

Requirements to interoperate with our VPN implementation include:

• Ability to establish IKE Security Association using Pre-Shared Keys (RFC 2409).
• Ability to establish IPSec Security Associations in Tunnel mode (RFC 4301).
• Ability to utilize the AES 128-bit encryption function (RFC 3602).
• Ability to utilize the SHA-1 hashing function (RFC 2404).
• Ability to utilize Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode (RFC 2409).
• Ability to establish Border Gateway Protocol (BGP) peerings (RFC 4271).
• Ability to utilize IPSec Dead Peer Detection (RFC 3706).

Optional capabilities that we recommend include:

• Ability to adjust the Maximum Segment Size of TCP packets entering the VPN tunnel (RFC 4459).
• Ability to reset the “Don’t Fragment” flag on packets (RFC 791).
• Ability to fragment IP packets prior to encryption (RFC 4459).

We’ve confirmed that a variety of Cisco and Juniper hardware/software VPN configurations are compatible; devices meeting our requirements as outlined in the box at right should be compatible too. We also plan to support Software VPNs in the near future. If you want us to consider explicitly validating a device not on this list, please add your request to the Customer Gateway support thread located here.

Amazon VPC functionality is accessible via the EC2 API and command-line tools. The ec2-create-vpc command creates a VPC and the ec2-describe-vpcs command lists your collection of VPCs. There are commands to create subnets, customer gateways, VPN gateways, and VPN connections. Once all of the requisite objects have been created, the ec2-attach-vpn-gateway connects your VPC to your network and allows traffic to flow. While most organizations will likely leave the VPN connection (and VPC) up and running indefinitely, you can drop the connection, terminate the instances, and even delete the VPC if you would like.

You only pay for what you use. Pricing is on a pay-as-you-go basis. VPCs, subnets, customer gateways, and VPN gateways are free to create and to use. You simply pay an hourly charge for each VPN connection you create, and for the data transferred through those VPN connections. EC2 instances within your VPC are priced at the normal On-Demand rate. We’ll honor the hourly rate for any Reserved Instances that you have but during the beta we cannot guarantee that Reserved Instances will always be available for deployment within your VPC.

Imagine the many ways that you can now combine your existing on-premise static resources with dynamic resources from the Amazon VPC. You can expand your corporate network on a permanent or temporary basis. You can get resources for short-term experiments and then leave the instances running if the experiment succeeds. You can establish instances for use as part of a DR (Disaster Recovery) effort. You can even test new applications, systems, and middleware components without disturbing your existing versions.

As is the case with many of our betas, this one is launching in a single Availability Zone in the US-East region. You can use Amazon CloudWatch to monitor your instances, but you can’t use Elastic IP addresses, Auto Scaling or Elastic Load Balancing just yet.

Recall that all traffic from your instances routes through the VPN connection. For now, this includes traffic to other Amazon Web Services such as EC2 instances outside of your Amazon VPC, Amazon S3, Amazon SQS, and Amazon SimpleDB. You can create Elastic Block Store (EBS) volumes and attach them to your instances. EBS volumes created within your cloud can be moved to standard EC2 instances and vice-versa.

I do want to mention a few of the things on our road map as well. First, we're planning to let you directly reach the Internet from your VPC. In early discussions with potential users, we learned that most of them wanted to completely isolate their EC2 instances, routing all of the traffic back to their data center, so we gave this feature the highest priority. Later on, we'll let you decide if and how you want to expose your VPC to the Internet. Second, we're planning to let you specify the IP address of individual Amazon EC2 instances within a subnet. During this beta, Amazon EC2 instances are automatically assigned a random IP from the subnet's designated IP address range. Third, we're evaluating ways to allow you to filter traffic per subnet, kind of like how you might implement router ACLs. We're already working on these items and on other additions to the core functionality we're releasing today. If you have opinions on these items, or anything else you'd like to see in the service, e-mail us or post to the forum. This service is for you; we really need your feedback!

We think you can put Amazon VPC to immediate use and can’t wait to hear about new and imaginative use cases for it. Please feel free to leave a comment on this blog or to send us some email.

-- Jeff;

Comments

[Max]

There's a nasty problem with this kind of configuration: when the internet route between the cloud and the in-house network is disrupted, nobody is responsible. Neither Amazon nor one's ISP will typically be willing (or able) to do anything to help. For this reason, we found that in practice it's necessary to keep the interface between cloud and in-house network to a minimum and ensure that temporary disruption in communication between the two doesn't cause a loss of service to our customers. This unfortunately makes the configuration pictured here of limited use in practice, unless this new offering somehow gets around the problem.

[Rasputnik]

Interesting, look forward to it arriving in the EU.

Do you know if multicast will work between AMIs on the same VPC?

we have a couple of apps that rely on multicast to do their clustering, and last we checked that wasn't possible on EC2.

[Brace Rennels]

This is great news and think that this will help the rapid adoption of IT managers useing the Amazon cloud as a disaster recovery facility and low cost online backup solution. I can only think that replication companies like DOuble-Take Software will help increase this use of the Amazon VPC.

[Paul]

In this model, how does a 3rd party offer software, including updates, instance management within the VPC?

[brookwood1]

how does it deal with things like authentication, resource management etc..
also, will can i seamlessly move a vmware image to amzn using the aforementioned APIs?

[Ivo Blazko]

Will this service be offered in Europe as well and if so, when?

[olivier danion]

It looks a lot like the VPN-cubed solution from your CohesiveFT "partner". Isn't it ?

[Sergio]

Does amazon guarantee that instances running on the VPC do not share virtual machines with other instances outside the VPC ? (to avoid problems of side channel attacks between images executing on the same virtual machine)

[Bim Job]

This is not a "nasty problem" at all. Whether you build two datacenters of your own, rent space in two datacenters, or host on Amazon's servers, there will be a network link between your two sites, and if it goes down then your ISP and your datacenter owner are helpless to do anything, which is why they can't and won't promise to do anything.

If you have one site, you have a single point of failure. If you have redundant sites, you have the risk that the link between them will fail.

Therefore, you design your network accordingly.

And if you really care, then you build your own redundant networks. And even then, you're only reducing the chance of failure - not eliminating it.

This is a great service for people who need it and who are competent at managing a network. Everyone else will find it unhelpful.

You can't "get around" the laws of physics, and any company promising to do so is lying to you.

[Max]

@Bim Job: Ah, but if you build two datacentres of your own and choose to connect them using the internet, then you can choose to use the same ISP to connect each of them. Then when it breaks, you call that ISP and tell them to fix it and they do, because that's what you pay them for and you're free to go elsewhere.

We had our datacentre on the most expensive and best supported internet connection in the world, but when the route between Amazon and us was disrupted there was still nothing anyone could/would do. It really is a problem inherent in Amazon's setup here which does not apply to the DIY route.