Warakorn - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Building scalable applications using AWS Auto Scaling

David Linthicum reviews building applications using AWS Auto Scaling, adding and removing EC2 instances and elastic load balancing.

Scaling applications within Amazon Web Services is about as easy as the hype would lead you to believe. One of the values that we get from cloud computing is the ability to auto scale as well as auto provision. There's no need to buy as much hardware and software as needed to deal with peak loads; just allocate what you need, when you need it. 

The feature of AWS Auto Scaling allows application developers and application managers to create an auto scaling group. This is done by specifying an EC2 instance ID, and then telling AWS the desired number of EC2 instances that will participate in the auto scaling group. 

The auto scaling subsystem automatically creates a launch configuration, and binds it to an auto scaling group. The name of the launch configuration derives its label and attributes (from the specified instance) from the auto scaling group.

As you add and remove EC2 instances using AWS Auto Scaling, it's important to make sure you address load balancing as well. AWS provides a facility to distribute your Web application processing load across all EC2 instances. The AWS Elastic Load Balancing service can balance the load of inbound Web traffic using all of the EC2 instances that are executing in the group. 

The values of these services are clear:

  • Application developers no longer need to deal with scaling and load balancing inside of the application. The ability to decouple scaling services as much as possible makes the application much easier to manage, deploy and, of course, scale.
  • The option to manage application instances as linked groups also makes management easier. 
  • The value of elasticity keeps the business out of the hardware and software buying game. Remember the days when scaling applications meant buying stuff and bolting it into a data center?

Keep in mind that auto scaling and the Elastic Load Balancer mechanism are just a portion of AWS offerings that allow applications to scale. Those who build cloud-native applications on AWS should do their research, as well as get some training, to make sure they leverage the right aspects of the AWS cloud. 

Most excitingly, perhaps, is the option of decoupling the application from the underlying infrastructure while still providing the ability to scale. This is important because as more enterprises move to the cloud, decoupling the application can reduce the cost of migration as well as the cost of migrating to other platforms. 

So, the process looks something like this:

  • Understand the scaling features of AWS, or you'll end up redoing several things, such as refactoring an application to take better advantage of the cloud-native services that allow the application to scale. The trick here is to do it right the first time.   
  • Consider the application mods, or new application development architectures and scaling approaches. 
  • Define the best approach for development.
  • Build and test for scale using test tools such as CopperEgg, or perhaps even running your own applications, adding load and observing the behavior of AWS, which I'm finding is the best approach.

With that, happy scaling. 

Dig Deeper on AWS application lifecycle management (ALM) tools

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What tips have you learned from building applications using AWS Auto Scaling?
Hi David, good overview on AWS auto scaling basics.  Does AWS enable teams to hook in their own auto scaling policies?   Based on my understanding, the scaling rules are very limited, and only kick in when an instances is deemed unhealthy.     Apache Stratos has more sophisticated monitoring facilities and auto scale rules that analyze relevant cloud instance events (published by each instance).    For example, a team can configure Apache Stratos to scale up/down based on message requests, CPU/memory limits, or number of active, concurrent users.    Do you see your clients asking for this level of sophistication?