Today we are releasing a set of features that expand the power and value of the Virtual Private Cloud. You can think of this new collection of features as virtual networking for Amazon EC2. While I would hate to be innocently accused of hyperbole, I do think that today's release legitimately qualifies as massive, one that may very well change that way that you think about EC2 and how it can be put to use in your environment.
The features include:
- A new VPC Wizard to streamline the setup process for a new VPC.
- Full control of network topology including subnets and routing.
- Access controls at the subnet and instance level, including rules for outbound traffic.
- Internet access via an Internet Gateway.
- Elastic IP Addresses for EC2 instances within a VPC.
- Support for Network Address Translation (NAT).
- Option to create a VPC that does not have a VPC connection.
The new VPC Wizard lets you get started with any one of four predefined network architectures in under a minute:
The following architectures are available in the wizard:
- VPC with a single public subnet - Your instances run in a private, isolated section of the AWS cloud with direct access to the Internet. Network access control lists and security groups can be used to provide strict control over inbound and outbound network traffic to your instances.
- VPC with public and private subnets - In addition to containing a public subnet, this configuration adds a private subnet whose instances are not addressable from the Internet. Instances in the private subnet can establish outbound connections to the Internet via the public subnet using Network Address Translation.
- VPC with Internet and VPN access - This configuration adds an IPsec Virtual Private Network (VPN) connection between your VPC and your data center – effectively extending your data center to the cloud while also providing direct access to the Internet for public subnet instances in your VPC.
- VPC with VPN only access - Your instances run in a private, isolated section of the AWS cloud with a private subnet whose instances are not addressable from the Internet. You can connect this private subnet to your corporate data center via an IPsec Virtual Private Network (VPN) tunnel.
After you choose an architecture, the VPC Wizard will prompt you for the IP addresses and other information that it needs to have in order to create the VPC:
Your VPC will be ready to go within seconds; you need only launch some EC2 instances within it (always on a specific subnet) to be up and running.
Your VPC will use one or more Route Tables to direct traffic to and from the Internet and VPN Gateways (and your NAT instance, which I haven't told you about yet) as desired., based on the CIDR block of the destination. Each VPC has a default, or main routing table. You can create additional routing tables and attach them to individual subnets if you'd like:
You can now create an Internet Gateway within your VPC in order to give you the ability to route traffic to and from the Internet using a Routing Table (see below). It can also be used to streamline access to other parts of AWS, including Amazon S3 (in the absence of an Internet Gateway you'd have to send traffic out through the VPN connection and then back across the public Internet to reach S3).
You can now create and attach a Network ACL (Access Control List) to your subnets if you'd like. You have full control (using a combination of Allow and Deny rules) of the traffic that flows in to and out of each subnet and gateway. You can filter inbound and outbound traffic, and you can filter on any protocol that you'd like:
You can also use AWS Identity and Access Management to restrict access to the APIs and resources related to setting up and managing Network ACLs.
You can now use Security Groups on the EC2 instances that your launch within your VPC. When used in a VPC, Security Groups gain a number of powerful new features including outbound traffic filtering and the ability to create rules that can match any IP protocol including TCP, UDP, and ICMP.
You can also change (add and remove) these security groups on running EC2 instances. The AWS Management Console sports a much-improved user interface for security groups; you can now make multiple changes to a group and then apply all of them in one fell swoop.
Elastic IP Addresses
You can now assign Elastic IP Addresses to the EC2 instances that are running in your VPC, with one small caveat: these addresses are currently allocated from a separate pool and you can't assign an existing (non-VPC) Elastic IP Address to an instance running in a VPC.
You can now launch a special "NAT Instance" and route traffic from your private subnet to it in. Doing this allows the private instances to initiate outbound connections to the Internet without revealing their IP addresses. A NAT Instance is really just an EC2 instance running a NAT AMI that we supply; you'll pay the usual EC2 hourly rate for it.
Several companies have been working with these new features and have released (or are just about to release) some very powerful new tools. Here's what I know about:
By running the VPN-Cubed manager in the public section of a VPC, you can connect multiple IPsec gateways to your VPC.You can even do this using security appliances from vendors like Cisco, ASA, Juniper, Netscreen, and SonicWall, and you don't need BGP.
VPN-Cubed also lets you run grid and clustering products that depend on support for multicast protocols.
I think this is the best part of the Virtual Private Cloud: you can deploy a feature-packed private network at no additional charge! We don't charge you for creating a VPC, subnet, ACLs, security groups, routing tables, or VPN Gateway, and there is no charge for traffic between S3 and your Amazon EC2 instances in VPC. Running Instances (including NAT instances), Elastic Block Storage, VPN Connections, Internet bandwidth, and unmapped Elastic IPs will incur our usual charges.
Internet Gateways in VPC has been a high priority for our customers, and I’m excited about all the new ways VPC can be used. For example, VPC is a great place for applications that require the security provided by outbound filtering, network ACLs, and NAT functionality. Or you could use VPC to host public-facing web servers that have VPN-based network connectivity to your intranet, enabling you to use your internal authentication systems. I'm sure your ideas are better than mine; leave me a comment and let me know what you think!