Elastic IP on application deployed using Elastic Beanstalk

Question

I'm a bit confused about the use of the Elastic IP service offered by Amazon Web Services. I guess the main idea is that I can switch to a new version of the web application with no downtime following this simple procedure:

1. Deploy the new version on a new EC2 instance
2. Configure the new version properly and test it using a staging DB
3. Once properly tested, make this new version use the live DB
4. Associate the Elastic IP to this instance
5. Terminate all the useless services (staging DB and old EC2 instance)

Is this the common way to deploy a new version of a web application?

Now, what if the application is scaled on more instances? I configured the auto-scaling in the Elastic Beanstalk settings and this created a load balancer (I can it see in the EC2 section of the AWS Management Console). The problem is that I apparently cannot associate the Elastic IP with the load balancer, I have to associate it with an existing instance. To which instance should I associate it to? I'm confused...

Sorry if some questions may sound stupid but I'm only a programmer and this is the first time I set up a cloud system.

Answer 1

Elastic Load Balancing (ELB) doesn't work with Amazon EC2 Elastic IP addresses, in fact, the two concepts don't go along at all.

Elasticity via Elastic Load Balancing

Rather, ELB is usually used via CNAME records (but see below), and this provides the first level of elasticity/availability by allowing the aliased DNS address to change the IP of the ELB(s) in use if need be. The second level of elasticity/availability is performed by the load balancer when distributing the traffic between the EC2 instances you have registered.

Think of it this way: The CNAME never changes (just like the Elastic IP address) and the replacement of EC2 instances is handled via the load balancer, Auto Scaling, or yourself (by registering/unregistering instances).

Domain Names

Please note that the former limitation requiring a CNAME has meanwhile been addressed by respective additions to Amazon Route 53 to allow the root domain (or Zone Apex) being used as well, see section Aliases and therefore the Zone Apex within Moving Ahead With Amazon Route 53 for a fast overview and using Domain Names with Elastic Load balancing for details.

Elasticity via Elastic Beanstalk

First and foremost, AWS Elastic Beanstalk uses Elastic Load Balancing in turn as described above. On top, if that, it adds application lifecycle management:

AWS Elastic Beanstalk is an even easier approach for you to quickly deploy and manage applications within the AWS cloud. You simply upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. 

This is achieved by adding the concept of an Environment into the mix, which is explained in the Architectural Overview:

The environment is the heart of the application. once you create an environment, AWS Elastic Beanstalk provisions the resources required to run your application. AWS resources created for an environment include one elastic load balancer (ELB in the diagram), an Auto Scaling group, and one or more Amazon EC2 instances.

Please note that each environment contains a CNAME (URL) that points to a load balancer, i.e. just like using an ELB on its own.

All this comes along in Managing and Configuring Applications and Environments, that discusses some of the most vital features of AWS Elastic Beanstalk in detail, including usage examples using the AWS Management Console, CLI, and the APIs.

Zero Downtime

It's hard to identify the most relevant part for illustration purposes, but Deploying Versions With Zero Downtime precisely addresses your use case and implies all required preceding steps (e.g. Creating New Application Versions and Launching New Environments), so reading section AWS Management Console might give you the best overall picture how this platform works.