Horizontal vs vertical scaling in the cloud

Today I will be going over horizontal vs vertical scaling also known as scaling out vs scaling up. We will also take a look at the pros and cons of each strategy as they are both valid for different use cases and scenarios. There are plenty of benefits as well as potential downsides to both methods of scaling that should be considered when your architecture or expanding your cloud environment/application. Lets dive right into it with a comparison below.

horizontal vs vertical scaling

Comparing horizontal vs vertical scaling

What is vertical scaling?

Vertical scaling, also known as scaling up is the process of adding resources to your current server or instance rather than adding additional instances. An example of scaling up would be upgrading your web server AWS EC2 instance from a t3a.small (2 CPUs / 2GB Memory) to a t3a.medium (4 CPUs / 4GB Memory). With most cloud providers this is likely going to be the easiest way to scale your resources, however this does have some positives and negatives to consider which I will try to outline below.

Positives of scaling vertically:

There are several positives to scaling vertically, one of the main ones being the simplicity compared to scaling out. When scaling up on AWS for example, you would simply stop your EC2 instance, change the instance size (for example from t3.small to t3.medium), and then start your instance again. Scaling out by comparison involves setting up a load balancer, potentially an auto scaling group with a base AMI (Amazon machine image), off loading your SSL to the load balancer, modifying server configurations and more.

Additionally when comparing the available options, you should also consider the cost that comes with scaling out. At the time of this writing an AWS application load balancer costs approximately $30 per month. If your application is not critical and is running on a relatively cheap instance, it may not make financial sense to scale out and add this kind of cost. An example would be if you are running an API in a staging environment on a t3.micro instance costing $7 per month. It may not be worth the effort or cost in this case to build the extra infrastructure when you could simply scale up to a t3.small instead and pay $14 per month.

One last thing to consider if you are contemplating scaling up is that you may simply be able to optimize your server instead, a properly optimized server could potentially handle twice the amount of traffic if not more compared to a server running standard configurations.

  • Typically a quick and painless process for applications hosted in the cloud.
  • Much simpler to configure on the application side.
  • No need to offload uploads to S3 or another storage solution, everything can be served from the single server.
  • Typically cheaper than horizontal scaling for small web applications.
  • Potential for single server applications where the database and web server for example can live on a single instance.

Negatives of scaling vertically:

The single biggest con for scaling vertically will always be the single point of failure aspect, that being said for some applications or use cases this may be an acceptable risk, this is something that should definitely be kept in mind during the planning phase. Beyond that issue, you may eventually scale up to the point where your return isn’t worth the increase in cost, with AWS in particular your instance cost basically doubles each time you size up within the same instance family for example. Keep in mind that this would be a minimal increase at first but once you get into the more expensive instance sizes it starts to add up fairly quick. To help illustrate how this expense can increase monthly, I put some rough numbers with each number being the next size up instance’s monthly cost.

Instance monthly cost increases: 7, 14, 28, 56, 112, 224, 448, 996, 1900+

  • You can only scale up to a certain point, sooner or later their isn’t a more powerful server available.
  • At some point you will ultimately reach the point where the cost vastly exceeds the benefit for scaling up.
  • Single point of failure, if this server fails your application is unavailable until the issue is resolved.

Real world examples of scaling up:

Below are two quick examples of scaling vertically to help you get a clear idea of what this concept looks like.

  • Upgrading from a server with 2GB of memory to one with 4GB.
  • Increasing network throughput for your single web server.

What is horizontal scaling?

Horizontal scaling, also known as scaling out is when you add more servers or instances rather than increasing the resources on a single instance. These instances usually sit behind a load balancer which equally distributes the traffic between your servers. Additionally you can improve upon this method of scaling with AWS by utilizing an auto scaling group which basically adds and removes servers as they are needed.

Positives of scaling horizontally:

Generally speaking if scaling out is a possibility, it will be the better option for numerous reasons. The main benefit of scaling out rather than scaling up, however, is that you eliminate the single point of failure. When scaling up, you increase your server’s resources however you still only have 1 server. This can lead to downtime when issues eventually arise. By scaling out instead, you have multiple servers which means if one of them becomes unhealthy, the others can take over and thus you avoid downtime. Additionally, once you have auto scaling configured, increasing or decreasing your server count is as simple as adjusting your minimum, maximum, and desired counts.

  • Load balanced to distribute traffic evenly between multiple servers.
  • No single point of failure, provided the environment is properly architected.
  • With AWS auto scaling you can scale out during peak hours as well as scale in when traffic drops during off hours.
  • By automatically scaling down when you don’t need as many resources, you can potentially save money.

Negatives of scaling horizontally:

Now lets go over some of the negatives that come with scaling out vs scaling up. The first thing that comes to mind when thinking about scaling out is that it typically involves complications with the application. You typically need to consider things such as where your application will store user uploads for example. Another is that you will likely need to adjust your server as typically SSL is served from the load balancer rather than the actual instance in these situations (this is the recommended best practice for AWS).

Something else to keep in mind is that scaling out may not be the best solution financially as you will have additional resource costs as well as potential maintenance requirements such as AMI updates that could be avoided by scaling up instead.

  • More complex setup, typically involves additional infrastructure configuration.
  • Potentially more application level configurations or changes involved.
  • Typically, you will need to offload any files that are uploaded to S3 or another storage solution as uploads will only get to 1 server.
  • For smaller, non-critical applications this can be much more expensive than a single EC2 instance.
  • If using auto scaling, you may have additional maintenance tasks such as updating the AMI (amazon machine image).

Real world examples of scaling out:

Below are just a handful of real world examples of scaling horizontally to help you get a better idea of how the concept would work.

  • Adding additional web servers and splitting incoming traffic among them.
  • Offloading your LAMP stack’s database into a separate server or instance, thus freeing up resources.
  • Adding a fail-over RDS instance (Multi-AZ).
  • Adding read replica RDS instances to offload reads from your main database instance.

So which type of scaling is better?

So which is better when looking at horizontal vs vertical scaling? The answer is, it honestly depends on your situation. Horizontal scaling is typically going to be a better solution if your application is designed to offload media/uploads and stores any required data such as session details in an external database such as AWS RDS. However, if your application isn’t built for this type of infrastructure or you are running a non-critical application on a small AWS EC2 instance, you will likely be better off with vertical scaling simply due to the cost and effort involved in re-architecting.

There are also certain situations where it makes sense to scale up and out at the same time. An AWS specific example of this would be if you are constantly scaling in and out with many smaller instances. Adjusting your auto scaling group’s launch configuration from 6 medium sized instances to 3 large instances would cost the same but would result in less frequent scaling as 1 additional large instance would be relatively the same as adding 2 medium sized instances.


Need some help? We offer a great low cost managed cloud service that takes care of all the AWS technical details, cost optimization, as well as provides monitoring/alerting. If interested, take a look at our managed cloud service!


Bonus: Using AWS auto scaling for self healing environments

Last but not least, since we are looking at scaling, there is another concept of scaling we can look into which is known as “self healing”. In this use-case you would have a single EC2 instance, for example a web server. It would be created via an auto scaling group with no intention of actually scaling out to multiple instances, the reason for the auto scaling is instead to replace the instance or server automatically in the event that it becomes unhealthy.

With this concept there are a few things to keep in mind, the most important being that these types of instances can be replaced at any moment and should not be used to store any critical data. 1 quick example that this could be used for is to create a self healing API server. If something were to happen to this server, the health check would fail and it would be replaced automatically with a fresh healthy EC2 instance.

Leave a comment



Tweet
Share
Share
Share