![throttled series throttled series](https://i.ytimg.com/vi/iKYa20mDyWY/maxresdefault.jpg)
Let’s imagine you have an application that is currently running on the Standard_A2_v2 VM size. The most obvious benefit is going to be the cost. Now, that we’ve covered why burstable sizes make sense for some applications, let’s understand the benefits. As the physics of semiconductors limits the number of cores, CPU clock speeds and RAM you can add to a single node, users have solved this problem by developing applications that can scale horizontally to more nodes.īut, if you have an application that is small enough for a single node and only needs to use 100% of the CPU for a small time, burstable sizes will provide you the most cost-effective way to run it. This is a classic vertical scalability problem. However, sometimes the application demands more computing power. Typically, users will solve this problem by deploying a VM size with smaller number of cores and lesser RAM. Therefore, anytime your VM is not using 100% CPU, you are leaving computing cycles on the table that you are paying for. When you deploy a VM in the cloud, you’re paying the same regardless of the % of CPU used. To understand why, we first need to understand how the pricing for a VM works in the cloud. If you have applications that remain idle for a long time and burst occasionally, then the B-series might be the perfect fit for you. So why do I need a burstable size anyway? # If you still have questions after reading, hit me up on Twitter or leave a comment below. In the below few words (or more :smile: ) I try to explain what this means and why you should care. This VM type is meant to compete directly with AWS' T2 instances. Azure recently introduced its first burstable VM size - the B-series.