CDP:Scale Up Pattern

From AWS-CloudDesignPattern
Revision as of 00:31, 28 November 2012 by Cdpadmin (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Dynamic Server Spec Up/Down


Problem to Be Solved

Typically it is difficult to estimate, during the system development phase, the server resources that will be required after deployment.

If the server resources are insufficient after deployment, the server will not perform well, or will be unable to keep up with batch processes. On the other hand, excessive server resources require excessive investments and mayactually produce losses.

While it would be nice to be able to adjust server resources after system deployment, this is difficult because the server resources depend on the specification of the physical machine.

Explanation of the Cloud Solution/Pattern

The AWS Cloud lets you switch the virtual server specifications (CPU, memory size, and the like) as needed. You can adjust the specifications even after launching of the virtual server.

While in the past you would have to replace the physical server and reinstall the operating system if resources prove inadequate after deployment, there is no such need to do so in the AWS Cloud. You can deploy a system by launching a virtual server, and adjust the server specifications while monitoring the resource usage.



  • Launch an EC2 instance and build the system.
  • Monitorthe resource utilization using vmstat or a resource monitor, CloudWatch, or the like, and if the specification is inadequate (or excessive), stop the EC2 instance, and then restart after adjusting the instance type using the Change Instance Type menu of the AWS Management Console.




  • This eliminates the need for precise estimation of server specifications at the time of system design/development.
  • This reduces opportunity costs due to system stoppages and the inability to provide services to customers caused by inadequate resources.
  • This enables reduction in waste, in terms of expenses, because you can switch to a reduced specification if you discover that the resources are excessive.


  • When you need to adjust a server specification, you will need to stop the EC2 instance temporarily. The system will go off-line at this time for a period of time from about 30 seconds up to several minutes (depending on the disk space and the setup of the server).
  • Despite being able to adjust the server specifications, iyou are still limited by the upper limit for the instance type. As a result, if the resources are inadequate despite selecting the instance type with the maximum processing performance, you will have to consider the use of Scale-out Pattern, caching, substituting another service of AWS, for example.


  • If you can predict the processing peak, then you can also adjust the server specification automatically to match. For example, if closing processes with high overhead are performed at the end of the month, then you can put together a schedule where the specification is adjusted upward at that time, and adjusted downward otherwise.
  • You can handle Frequent processing delays through temporarily modifying the server specification, and then returning the server specification to the original after making improvements to performance of the application or database. This is used particularly often in areas such as consumer-oriented servers where the access frequency cannot be read, and in database servers, for example, which are difficult to scale-out.

See the Scale-out Pattern.

Personal tools