Amazon EC2 Update - Virtual Private Clouds for Everyone!

If you use or plan to use Amazon EC2, you need to read this post!

History Lesson
Way back in the beginning (OK, 2006) we launched Amazon EC2. When you launched an instance we gave it a public IP address and a DNS hostname. You had the ability to create a Security Group for ingress filtering and attach it to the instance at launch time. Each instance could have just one public IP address, which could be an Elastic IP if desired. Later, we added private IP addresses and an internal DNS hostname to each instance. Let's call this platform "EC2-Classic" (that will be on the quiz, so remember it).

In 2009 we introduced the Amazon Virtual Private Cloud, better known as the VPC. The VPC lets you create a virtual network of logically isolated EC2 instances and an optional VPN connection to your own datacenter.

In 2011 we announced a big upgrade to EC2's networking features, with enhanced Security Groups (ingress and egress filtering and the ability to change membership on running instances), direct Internet connectivity, routing tables, and network ACLs to control the flow of traffic between subnets.

We also added lots of other features to VPC in the past couple of years including multiple IP addresses, multiple network interfaces, dedicated instances, and statically routed VPN connections.

How to Make it Easier to Get the Power of VPC and the Simplicity of EC2
We want every EC2 user to be able to benefit from the advanced networking and other features of Amazon VPC that I outlined above. To enable this, starting soon, instances for new AWS customers (and existing customers launching in new Regions) will be launched into the "EC2-VPC" platform. We are currently in the process of enabling this feature, one Region at a time, starting with the Asia Pacific (Sydney) and South America (São Paulo) Regions. We expect these roll-outs to occur over the next several weeks. We will update this post in the EC2 forum each time we enable a Region.

You don’t need to create a VPC beforehand - simply launch EC2 instances or provision Elastic Load Balancers, RDS databases, or ElastiCache clusters like you would in EC2-Classic and we’ll create a VPC for you at no extra charge.  We’ll launch your resources into that VPC and assign each EC2 instance a public IP address. You can then start taking advantage of the features I mentioned earlier: assigning multiple IP addresses to an instance, changing security group membership on the fly, and adding egress filters to your security groups. These VPC features will be ready for you to use, but you need not do anything new and different until you decide to do so.

We refer to the automatically provisioned VPCs as “default VPCs.”  They are designed to be compatible with your existing shell scripts, CloudFormation templates, AWS Elastic Beanstalk applications, and Auto Scaling configurations. You shouldn’t need to modify your code because you’re launching into a default VPC.

Default VPCs for (Almost) Everyone
The default VPC features are available to new AWS customers and existing customers launching instances in a Region for the first time. If you’ve previously launched an EC2 instance in a Region or provisioned ELB, RDS, or ElastiCache in a Region, we won’t create a default VPC for you in that Region.

If you are an existing AWS customer and you want to start gaining experience with this new behavior, you have two options. You can create a new AWS account or you can pick a Region that you haven't used (as defined above). You can see the set of available platforms in the AWS Management Console (this information is also available through the EC2 APIs and from the command line). Be sure to check the Supported Platforms and Default VPC values for your account to see how your account is configured in a specific Region.

You can determine if your account is configured for default VPC within a particular Region by glancing at the top right corner of the EC2 Dashboard in the AWS Management Console. Look for the Supported Platforms item.  “EC2-VPC” means your instances will be launched into Amazon VPC.

Here is what you will see if your AWS account is configured for EC2 Classic and EC2-VPC (without a default VPC):

You can also see the supported platforms and the default VPC values using the EC2 API and the Command Line tools.

All Set Up
As I noted earlier in this post, we'll create a default VPC for you when you perform certain actions in a Region. It will have the following components:

• One default subnet per Availability Zone.
• A default route table, preconfigured to send traffic from the default subnets to the Internet.
• An Internet Gateway to allow traffic to flow to and from the Internet.

Each VPC will have its own private IP range (172.31.0.0/16 to be precise); each subnet will be a "/20" (4096 IP addresses, minus a few that are reserved for the VPC).

EC2 instances created in the default VPC will also receive a public IP address (this turns out to be a very sensible default given the preconfigured default route table and Internet Gateway). This is a change from the existing VPC behavior, and is specified by a new PublicIP attribute on each subnet. We made this change so that we can support the EC2-Classic behavior in EC2-VPC. The PublicIP attribute can't currently be set for existing subnets but we'll consider allowing this in the future (let us know if you think that you would find this to be of use).

You can modify your default VPC as you see fit (e.g., creating or deleting subnets, creating or modifying route tables, adding VPN connections, etc.)  You can also create additional, nondefault VPCs just like the VPCs you can create today.

Once you are up and running in a VPC within an AWS Region, you'll have access to all of the AWS services and instance types that are available in that Region (see the List of AWS Offerings by Region page for more information). This includes new and important services such as Amazon Redshift, AWS OpsWorks, and AWS Elastic Beanstalk.

New VPC Features
We're also adding new features to VPC. These are available to all VPC users:

DNS Hostnames - All instances launched in a default VPC will have private and public DNS hostnames. DNS hostnames are disabled for existing VPCs, but can be enabled as needed.  If you’re resolving a public hostname for another instance in the same VPC, it will resolve to the private IP of the target instance.  If you’re resolving a public hostname for an instance outside of your VPC, it will resolve to the public IP address of that instance.

DNS Name Resolution - DNS resolution is enabled in all VPCs but we’ve added the ability for you to disable use of the Amazon provided DNS service in your VPC as needed.

ElastiCache - You can now create ElastiCache cache nodes within VPC (both default and nondefault VPCs).

RDS IP Addresses - RDS database instances in VPC can now be provisioned as Internet-facing or private-facing instances. Internet-facing RDS database instances have public IP addresses so that they can be accessed from EC2 Classic instances or on-premises systems. For more information on this feature, read the documentation on Amazon RDS and the Amazon Virtual Private Cloud Service.

Learning About VPC
To learn more about Amazon VPC, please consult the following resources:

• VPC Home Page.
• VPC Documentation.
• Detecting Your Supported Platforms.
• Differences Between Amazon EC2-Classic and EC2-VPC.

We’re happy to give you the advanced features of Amazon VPC coupled with the simplicity of Amazon EC2. If you have any questions, the AWS Support Team is ready, willing, and able to help.

-- Jeff;

 

Comments

[tom]

lol, you guys getting close to running out of IPs in 10.0.0.0/8 subnet?

[Joshua]

For existing customers:
Is a process for "used AZs" coming to move over from EC2-Classic to EC2-VPC?

Or ist it: You are a previous customer, you had instances in almost every AZ, so you are screwed?

Also: What's with RIs? Is there still a distinction between VPC and non VPC RIs?

[Thefalken]

Is this cost neutral ?
I mean, I'm now going to have a vastly more complicated set up, using more AWS 'stuff', even if I just have the single EC2 instance to muck about with, right ?

[Joekiller]

How does this affect the EIP limit of VPCs?

[ceejayoz]

@Thefalken VPC doesn't cost anything unless you're using specific enterprisey features. There wouldn't be any cost involved for basic EC2-style usage.

[D. Svanlund]

From the post: "The PublicIP attribute can't currently be set for existing subnets but we'll consider allowing this in the future".

What about a new subnet in a "Nondefault VPC"? Well, I probably know the answer already, which makes this a feature request. The public IP address appears to be the missing link when comparing "Default VPC" and "Nondefault VPC". Everything else works in the exact same way (after turning on DNS hostnames).

[Hassan Hosseini]

Thanks Jeff. I thought this blog about VPC Reserved Instances vs EC2 Reserved Instances might be useful for the readers: http://blog.planforcloud.com/2013/02/amazon-vpc-reserved-instances-vs-ec2.html

Cheers,
Hassan

[Eric Schultze]

Joshua,
The current focus in on enabling new AWS accounts and existing accounts new to a Region. We'll simultaneously start looking at building tools and methodologies to help existing customers migrate to Amazon VPC. We'd like to talk with folks to see what methods would work best for them.

Regarding RIs, customers who are using Default VPCs can purchase RIs, they'll only see one type of RI rather than having to select between VPC and EC2 RIs (since these customers can only launch in VPC, there's no reason to offer two types of RIs)

[Eric Schultze]

Joekiller, EIP limits don't change. If you're launching instances into a default subnet in a default VPC, those instances will receive Public IPs, just like in EC2-Classic, and that doesn't count against any of your IP limits.

If you're launching instances into a nondefault subnet (in any VPC), you will need to associate EIPs, just like you do today in VPC.

[Eric Schultze]

D. Svanlund - Yes, we're currently working on a public IP solution for nondefault subnets.

[Eric Schultze]

Hassan,

Today, Reserved Instances can be purchased for either EC2 or VPC instances. No matter which instance platform they're purchased for, the reserved instance pricing will apply to the instance, whether it's EC-Classic or EC2-VPC. The select of EC2 or VPC when you purchase the RI only applies to the capacity reservation in the specific platform.

For example, if you purchase 100 reserved instances in VPC, you'll get the pricing benefit on those 100 instances, whether you launch them in EC2 or in VPC. However, the capacity reservation only applies to VPC. If you launch 100 instances in VPC, those have been reserved for you and the launches will succeed. If you try and launch 100 instances in EC2, however, the launch may fail if there isn't enough capacity to satisfy your request (as the capacity reservation only existed in VPC)

Going forward, for folks who are Default VPC customers, they can only launch instances in VPC, so they are only given a single option for an RI purchase, and that capacity reservation will apply to the EC2-VPC platform.

[Doug Daniels]

In the new EC2-VPC, can you authorize ingress to other accounts' security groups? The classic EC2 security groups allowed this, which is very useful for service providers.

[Jeff Barr]

Doug, that feature is not supported but it is definitely on our roadmap.

[James]

I've created a new AWS account but haven't got a default VPC in Sydney or Sao Paulo. Is this feature actually active yet?

[Matt Rardon]

Definitely interested in adding the option to allow existing subnets to have public IPs

[Omar]

I was wondering how I can enable the option "Enable DNS hostname support for instances launched in this VPC." on the vpc creation thought a cloud formation template.