What is the reason for scaling Amazon EC2 by instance count rather than instance parameters?

Question

We are looking into moving our website to Amazon EC2.

The basic idea behind Amazon's cloud seems to be: "Need more RAM? You got it. Hard disk? Sure, here you go." Etc.

But Amazon seems to be pushing the instance count, rather instance parameters (RAM, disk, etc) as the way their scaling works.

"Amazon EC2 provides a truly elastic computing environment. Amazon EC2 enables you to increase or decrease capacity within minutes, not hours or days. You can commission one, hundreds or even thousands of server instances simultaneously. " http://aws.amazon.com/ec2/faqs/#How_quickly_can_I_scale_my_capacity_both_up_and_down

So, again, if my website is running on a single instance and that instance starts to bump up against some limit, how is a second instance going to help? Do they automatically: share the same ip address, perform load balancing, synchronize write data?

Or am I misunderstanding something? Thank you.

Answer 1

With EC2 you can (to some extent) scale both horizontally (adding more instances) and vertically (going to a larger instance) - however, the latter cannot be done automatically.

Almost nothing is inherently shared between instances - they run their own operating systems, have their own memory, and their own storage, and own IPs. Treat them as you would any VPS - just with a bit more automated provisioning system.

One place where EC2 differs from most VPS solutions is in the ability to add storage. This can be done without stopping the instance, in the form of 'adding new volumes' (so you would have, for example, /dev/xvda, and then add /dev/xvdb, etc.)

You can go to a larger instance via the following: Stop (not terminate) the instance Use ec2-modify-instance-attribute i-xxxxxx -t to change the instance type Start the instance

For all other aspects of scalability, you are on your own - you have to design your application to make use of what Amazon provides: Elastic IPs - to provide a single constant public IP despite changing the underlying instance Elastic Load Balancers - to distribute requests between the instances EBS volumes - for persistent storage EC2 instances - for computing power S3 & Cloudfront - for content delivery RDS - for MySQL databases managed by AWS (there is no built in scalability though)

AWS definitely doesn't do everything for you - it is not an automatic solution to take any application and instantly let it scale, but it does provide a framework on which you can build an application that will easily scale.

You can provision additional servers at will - either identical to existing ones, or different from them, and AWS will increase/decrease the number of instances on a number of metrics (e.g. load) if you want.

You can build arrays of disks, setup network file systems, network your instances together (VPC), and perform pretty much any function that would be necessary to build a scalable architecture.

At least in part the underlying reason for the setup on AWS is because each 'instance' is a predefined virtual machine. To modify the specs of a virtual machine would require you to stop and start it anyway. Amazon has provided a large assortment of instance types, to choose from, but beyond that, you cannot customize the CPU/RAM of an instance-type. Additionally, horizontal scaling overcomes the limitation of a single machine (for instance, it would be unimaginable for any large site to run on one server, no matter how large) - and avoids single points of failures. Arguably, if you need more power than is offered by their largest instances, horizontal scaling would likely end up as your solution, whether or not you ran on AWS.

Answer 2

Do they automatically: share the same ip address, perform load balancing, synchronize write data?

Short answer: No, but they can.

With most services where you need to add capacity you've got two options - you scale up or scale out.

I won't go into too much detail here as I'm repeating a Wikipedia article on the subject (http://en.wikipedia.org/wiki/Scale_out#Scale_horizontally_vs._vertically) but scaling up is as you initially suggest, adding CPU/RAM/disk while scaling out adds additional nodes.

The advantage with scaling out is that with an appropriate topology you can add capacity without disrupting the running service. This is usually accomplished by having intelligence either in the network layer (a load balancer or cluster manager) which can distribute work between your nodes, or in the application to do a similar job.

Scaling up by comparison in the majority of cases (certainly on EC2) involves shutting down the node (instance) to change the node type, causing downtime for your service unless you've already got multiple instances ready to take over.

Amazon is geared towards scaling out and has instances such as the elastic load balancer which can distribute traffic between your nodes and functionality to automatically provision new instances when load gets to a threshold, you could certainly use this functionality to increase the capacity of your website.

Of course, this all depends on how available you need your service to be, how much performance you want, how much money you've got to spend and if your application can be made to scale over multiple nodes. Usually when you scale out (web applications) the first thing you do is implement some kind of shared storage between the nodes (networked storage or a cluster file system) and either database synchronization or a shared database.