The popular AWS Elastic Load Balancing Feature is now available within the Virtual Private Cloud (VPC). Features such as SSL termination, health checks, sticky sessions and CloudWatch monitoring can be configured from the AWS Management Console, the command line, or through the Elastic Load Balancing APIs.
When you provision an Elastic Load Balancer for your VPC, you can assign security groups to it. You can place ELBs into VPC subnets, and you can also use subnet ACLs (Access Control Lists). The EC2 instances that you register with the Elastic Load Balancer do not need to have public IP addresses. The combination of the Virtual Private Cloud, subnets, security groups, and access control lists gives you precise, fine-grained control over access to your Load Balancers and to the EC2 instances behind them and allows you to create a private load balancer.
Here's how it all fits together:

When you create an Elastic Load Balancer inside of a VPC, you must designate one or more subnets to attach. The ELB can run in one subnet per Availability Zone; we recommend (as shown in the diagram above) that you set aside a subnet specifically for each ELB. In order to allow for room (IP address space) for each ELB to grow as part of the intrinsic ELB scaling process, the subnet must contain at least 100 IP addresses (a /25 or larger).
We think you will be able to put this new feature to use right away. We are also working on additional enhancements, including IPv6 support for ELB in VPC and the ability to use Elastic Load Balancers for internal application tiers.
-- Jeff;


outstanding Jeff.
we're very excited about this.
any indication yet of when multicast support might be added to vpc?
tx
ashley
Posted by: ashley brener | November 21, 2011 at 09:57 PM
Great job. Now hoping that ELB will support paid AMIs soon :)
Posted by: Mat | November 24, 2011 at 07:17 AM
Jeff, are connections from a VPN into the VPC still precluded from using ELB.
"We are also working on additional enhancements...and the ability to use Elastic Load Balancers for internal application tiers." seems to indicate that isn't supported yet and the diagram doesn't include that scenario either.
Thanks
Mark
Posted by: Mroggen | November 25, 2011 at 07:59 AM
We have the same question as Mark. Currently the company security policy dictates that all internet access goes through the main office.
Whilst we can make sure the instances themselves access the internet over the company connection/VPN by the use of the routing tables, this is not the case for incoming traffic through the load balancers, as those require the use of the internet gateway on the Amazon side.
Any information regarding this functionality, especially a timeline, would be greatly appreciated. Projects are currently still in testing phase and it would be nice to know if the functionality is going to be available once we switch to running production.
Posted by: Freaky - | December 21, 2011 at 02:53 AM
I wonder what the top layer would look like for using latency based routing?
Posted by: exprexxo | May 10, 2012 at 12:41 PM
Can you be more specfic about how the pink ELB section is actually created? Everything I have tried gives me the servers of one ELB or the other but not both, i.e. all servers.
Posted by: John | May 17, 2012 at 10:30 PM
Hi,
You said "In order to allow for room (IP address space) for each ELB to grow as part of the intrinsic ELB scaling process, the subnet must contain at least 100 IP addresses"
What is the genesis of this limit? Rightscale benchmarks of the ELB have monitored 22 IPs in use for a sustained request rate of 19,000/sec ! So what is the reason for requiring a minimum CIDR of /25 ?
thx
sudarshan
Posted by: Sudarshan Murty | May 25, 2012 at 12:42 PM