One of the greatest strengths of cloud computing is that many of its benefits are easy to conceptualize and articulate. That\u2019s certainly true for the benefit of cloud elasticity and agility. Your cloud-based application suddenly needs more or less computing power or storage? Simply tap some additional cloud resources \u2013 or release unneeded capacity \u2013 and problem solved!\nAt a fundamental level, every cloud customer gains improved IT elasticity and agility. But fully exploiting the potential of these cloud characteristics requires automating the scale-up\/scale-down process, rather than manually purchasing or cutting cloud instances on demand as your application needs fluctuate. As you might guess, implementing auto scaling requires a fair amount of planning and analysis.\nOne obvious requirement for those seeking to implement auto scaling is the need to place upper and lower limits on how many resources \u2013 and how much expense \u2013 the cloud system can add or drop on its own. If a company sets the minimum too high, for example, they may cause instances to continue running \u2013 and costs to keep rising \u2013 even when they\u2019re not needed.\nOther aspects of auto scaling can be even trickier to navigate. The description of Auto Scaling Groups on the Amazon Web Services website ends with a seemingly innocuous statement that hints at one of the core challenges: \u201cThe better you understand your application, the more effective you can make your Auto Scaling architecture.\u201d\nWell, yes. Unfortunately, far too many organizations don\u2019t really have in-depth insights into their applications, or into the infrastructure resources that their applications actually need and use. We discussed this lack of visibility in an earlier post that focused on the difficulty in right-sizing cloud instances.\nEven with good application transparency, when it comes to the ease and efficiency of application scaling, a lot depends on the nature of the application itself. Scaling websites and web workloads can be relatively straightforward \u2013 if you get more hits than the existing cloud instances can handle, just add another instance or two.\nBy contrast, with enterprise applications and other general workloads, doing automatic scaling well can be much more difficult. An enterprise app may run for many hours and use processing power and memory in many complicated ways. As such, it can be difficult to know which infrastructure resources are being used, much less the utilization levels of those resources. Without that knowledge, it can be impossible to make intelligent \u2013 much less automated \u2013 scaling decisions.\nIndeed, the difficulty in scaling monolithic \u201cspaghetti code\u201d applications is one of the forces driving the conversion of such apps to container-based microservices.\nNarrow-function microservices can be turned on and off when needed, and it\u2019s easier to ensure high infrastructure utilization rates with these granular elements. \u201cIt\u2019s like putting sand into jars versus stones into jars,\u201d explains Andrew Hillier, CTO of Densify. \u201cMore granular workloads are more fluid, and it is easier to stack them together \u2013 and to determine when you need more cloud instances.\u201d\nRegardless of an application\u2019s design, exploiting the full potential of auto scaling still requires that organizations have good visibility into how their apps consume resources under different loads. Many scale groups that Densify has studied, for example, have high memory utilization, but low CPU utilization. If a company changed its cloud instances to \u201chigh memory\u201d configurations, it might be able to run fewer of them, saving on the overall bill.\nUltimately, as with so many of cloud\u2019s theoretical benefits, success in automatic scaling starts with first getting good analytics into how your applications run, and knowing what infrastructure they require.