Elastic Network Interfaces in the Virtual Private Cloud
Dfg
Admin
If you look closely at the services and facilities provided by AWS, you'll see that we've chosen to factor architectural components that were once considered elemental (e.g. a server) into multiple discrete parts that you can instantiate and control individually.
For example, you can create an EC2 instance and then attach EBS volumes to it on an as-needed basis. This is more dynamic and more flexible than procuring a server with a fixed amount of storage.
Today we are adding additional flexibility to EC2 instances running in the Virtual Private Cloud. First, we are teasing apart the IP addresses (and important attributes associated with them) from the EC2 instances and calling the resulting entity an ENI, or Elastic Network Interface. Second, we are giving you the ability to create additional ENIs, and to attach a second ENI to an instance (again, this is within the VPC).
Each ENI lives within a particular subnet of the VPC (and hence within a particular Availability Zone) and has the following attributes:
Similar to an EBS volume, ENIs have a lifetime that is independent of any particular EC2 instance. They are also truly elastic. You can create them ahead of time, and then associate one or two of them with an instance at launch time. You can also attach an ENI to an instance while it is running (we sometimes call this a "hot attach"). Unless the Delete on Termination flag is set, the ENI will remain alive and well after the instance is terminated. We'll create a ENI for you at launch time if you don't specify one, and we'll set the Delete on Terminate flag so you won't have to manage it. Net-net: You don't have to worry about this new level of flexibility until you actually need it.
You can put this new level of addressing and security flexibility to use in a number of different ways. Here are some that we've already heard about:
Management Network / Backnet - You can create a dual-homed environment for your web, application, and database servers. The instance's first ENI would be attached to a public subnet, routing 0.0.0.0/0 (all traffic) to the VPC's Internet Gateway. The instance's second ENI would be attached to a private subnet, with 0.0.0.0 routed to the VPN Gateway connected to your corporate network. You would use the private network for SSH access, management, logging, and so forth. You can apply different security groups to each ENI so that traffic port 80 is allowed through the first ENI, and traffic from the private subnet on port 22 is allowed through the second ENI.
Multi-Interface Applications - You can host load balancers, proxy servers, and NAT servers on an EC2 instance, carefully passing traffic from one subnet to the other. In this case you would clear the Source/Destination Check Flag to allow the instances to handle traffic that wasn't addressed to them. We expect vendors of networking and security products to start building AMIs that make use of two ENIs.
MAC-Based Licensing - If you are running commercial software that is tied to a particular MAC address, you can license it against the MAC address of the ENI. Later, if you need to change instances or instance types, you can launch a replacement instance with the same ENI and MAC address.
Low-Budget High Availability - Attach a ENI to an instance; if the instance dies launch another one and attach the ENI to it. Traffic flow will resume within a few seconds.
Here is a picture to show you how all of the parts -- VPC, subnets, routing tables, and ENIs fit together:
I should note that attaching two public ENIs to the same instance is not the right way to create an EC2 instance with two public IP addresses. There's no way to ensure that packets arriving via a particular ENI will leave through it without setting up some specialized routing. We are aware that a lot of people would like to have multiple IP addresses for a single EC2 instance and we plan to address this use case in 2012.
The AWS Management Console includes Elastic Network Interface support:
The Create Network Interface button prompts for the information needed to create a new ENI:
You can specify an additional ENI when you launch an EC2 instance inside of a VPC:
You can attach an ENI to an existing instance:
Basically most of it goes over my head but I skimmed it and liked what I saw, the next host jump might be Amazon Cloud Servers.
For example, you can create an EC2 instance and then attach EBS volumes to it on an as-needed basis. This is more dynamic and more flexible than procuring a server with a fixed amount of storage.
Today we are adding additional flexibility to EC2 instances running in the Virtual Private Cloud. First, we are teasing apart the IP addresses (and important attributes associated with them) from the EC2 instances and calling the resulting entity an ENI, or Elastic Network Interface. Second, we are giving you the ability to create additional ENIs, and to attach a second ENI to an instance (again, this is within the VPC).
Each ENI lives within a particular subnet of the VPC (and hence within a particular Availability Zone) and has the following attributes:
- Description
- Private IP Address
- Elastic IP Address
- MAC Address
- Security Group(s)
- Source/Destination Check Flag
- Delete on Termination Flag
Similar to an EBS volume, ENIs have a lifetime that is independent of any particular EC2 instance. They are also truly elastic. You can create them ahead of time, and then associate one or two of them with an instance at launch time. You can also attach an ENI to an instance while it is running (we sometimes call this a "hot attach"). Unless the Delete on Termination flag is set, the ENI will remain alive and well after the instance is terminated. We'll create a ENI for you at launch time if you don't specify one, and we'll set the Delete on Terminate flag so you won't have to manage it. Net-net: You don't have to worry about this new level of flexibility until you actually need it.
You can put this new level of addressing and security flexibility to use in a number of different ways. Here are some that we've already heard about:
Management Network / Backnet - You can create a dual-homed environment for your web, application, and database servers. The instance's first ENI would be attached to a public subnet, routing 0.0.0.0/0 (all traffic) to the VPC's Internet Gateway. The instance's second ENI would be attached to a private subnet, with 0.0.0.0 routed to the VPN Gateway connected to your corporate network. You would use the private network for SSH access, management, logging, and so forth. You can apply different security groups to each ENI so that traffic port 80 is allowed through the first ENI, and traffic from the private subnet on port 22 is allowed through the second ENI.
Multi-Interface Applications - You can host load balancers, proxy servers, and NAT servers on an EC2 instance, carefully passing traffic from one subnet to the other. In this case you would clear the Source/Destination Check Flag to allow the instances to handle traffic that wasn't addressed to them. We expect vendors of networking and security products to start building AMIs that make use of two ENIs.
MAC-Based Licensing - If you are running commercial software that is tied to a particular MAC address, you can license it against the MAC address of the ENI. Later, if you need to change instances or instance types, you can launch a replacement instance with the same ENI and MAC address.
Low-Budget High Availability - Attach a ENI to an instance; if the instance dies launch another one and attach the ENI to it. Traffic flow will resume within a few seconds.
Here is a picture to show you how all of the parts -- VPC, subnets, routing tables, and ENIs fit together:
The AWS Management Console includes Elastic Network Interface support:
Basically most of it goes over my head but I skimmed it and liked what I saw, the next host jump might be Amazon Cloud Servers.