For Amazon, this represented a significant departure from the previous approach of per-hour billing that had long been the standard on their platform. For Google, the change was relatively minor, moving from the already efficient per-minute billing to per-second precision on their platform. Google had long pointed at their higher billing precision as a price efficiency relative to AWS, now the two platforms are on par in terms of billing their customers strictly for what they use and nothing more, with regards to the dominant products where most customers consume cloud services.
With two of the three major CSP (Cloud Service Providers) now billing at per-second increments, all customers of all cloud platforms benefit but the ways they benefit are not always obvious at first). This post will outline the use cases most likely to benefit from the changes as well as highlighting some additional changes that while important, were not widely discussed.
Specifically with regards to AWS, first and foremost the benefits for compute will only apply to those running non-licensed Linux operating systems (e.g not RHEL, SuSE, etc.). For those who meet this criteria, the magnitude of the benefit will depend on how they consume cloud resources.
For more traditional enterprises migrating from data centers to cloud, the cost efficiencies of per-second billing are less likely to be immediately impactful if they have not yet embraced the higher level platform services like AWS EMR (Elastic Map Reduce), AWS Batch or ASG (Auto Scaling Groups). If an infrastructure isn’t leveraging cloud best practices of rightsizing, elasticity and auto scaling, the benefit of per-second billing will still be a factor in their overall spending but not to the level of those truly leveraging the benefits of the platform.
The primary beneficiaries of the change to per-second billing will be operators who function in more “cloud-native” ways. For example, consumers of the EMR service will now only pay for resources they use for the exact duration of the job. With per-second billing if a compute cluster with ten hosts completes a job in 20 minutes, customers will pay for 200 minutes of compute rather than ten full hours (600 minutes), a 66% percent savings for the compute and storage cost of that job. Conversely, users of AWS operating their own Hadoop or Spark clusters will be less likely to benefit from the change as these will be less elastic and more long lived. As a second example, previously operators were forced to balance scale up and down policies in their ASGs, with the risk that too much elasticity could dramatically increase the cost of a service provided by an ASG as every host added to an ASG would be billed for an hour of usage even if the host only participated in the ASG for ten minutes of time. With per-second billing, users of ASGs can scale more fluidly, paying only for the exact time a host participates in the group (in addition to boot time).
How Much Should AWS Customers Expect to Save?
An initial modeling by our data scientists indicates that our more cloud-native customers will save on average upwards of 10% on affected products with the AWS move to per-second billing. For example, one of Cloudability’s advanced customers, dataxu, heavily leverages large numbers of short-lived, job-specific clusters for their compute workloads. dataxu’s predicted savings are on the high end of our customer base, as 50% of their EC2 hosts operate for less than an entire hour, with a significant percent running fewer than 10 minutes. In dataxu’s case, they should expect to save 30% on their overall EC2 spending resulting in roughly a 10% net reduction in their total spend with the change to per-second billing.
More traditional enterprise users who aren’t leveraging higher-level platform features appear to be more on track to save 1-2% on their monthly spend for the affected AWS products.
AWS Reserved Instances
Less prominent in the announcement of per-second billing is a fundamental change in how certain types of RIs (Reserved Instances1) behave for non-licensed operating systems. Specifically, certain types of RIs known as ISF (Instance Size Flexibility) now have the possibility to further optimize savings for AWS customers. Prior to per-second billing, portions of an ISF RI could only apply to a single host during a single time period. With the change to per-second billing, ISF RIs can now apply to multiple hosts during overlapping time periods, further broadening the opportunity for AWS customers to benefit from discounts offered by RIs.
As an example of how ISF RIs have changed with per-second billing, consider an RI purchased for a single c4.large EC2 instance type with per-hour billing. If you operated one c4.large EC2 host for 20 minutes during the term of that RI with per-hour billing, the RI would apply to that single host even though it only operated for 20 minutes. If at the next hour you operated three c4.large hosts, each for 20 minutes, under per-hour billing only one host would benefit. With the change to per-second billing (now in the second of three hosts – each operating for 20 minutes) all three c4.large hosts will operate at a discounted rate, even if they operated for the first 20 minutes of the hour. Under the previous model, the ISF normalization units2 of an RI (ISF RIs can be split across multiple hosts) would not be applicable to two distinct hosts during the same usage time period.
As with the discussion above, this change will be more impactful for those who operate more elastic infrastructures. The number of opportunities for an ISF RI to match a host for discounted pricing has increased significantly with the change to per-second billing and in particular with the change to allow a single ISF RI to apply during overlapping time intervals during an hour.
AWS EBS Volumes
As with changes to ISF RI behavior, certain use cases for EBS (Elastic Block Store) volumes can potentially benefit from the per-second billing changes. The obvious benefit is for short lived volumes where per-second pricing will save on time previously rounded up to an hour. Not as obvious is how to effectively leverage EBS volume burst in light of the pricing changes.
For short-lived workloads like batch compute where burst IOPS3 (volume operations for managed storage) are regularly the constraint, users may wish to consider increasing volume size in order to obtain more burst IOPS, thereby completing their tasks sooner and discarding the volumes more quickly. With the per-hour billing constraint removed, provisioning overly large volumes to obtain more burst capacity becomes an option for further optimization of EBS volume spend.
Data Scale and Platform Implications
The current expectation is that raw, uncompressed spending data for all customers of AWS will increase by up to 25% depending on how frequently customers start and stop new EC2 instances and EBS volumes. For the Cloudability platform, this in turn means an increase of billions of data points per month that we will process for our customers with no change in pricing for our platform. The good news for our customers and partners is that our platform has been built to scale with the ebb and flow that naturally occurs within the CSP realm. Keeping pace with the rapid rate of evolution and change from the likes of AWS, Azure and GCP is our bread and butter, and our team and architecture have been built from the ground up to operate at scale while retaining agility in delivering features.
In addition to increases in data volume, changes in ISF RI modeling in conjunction with second level billing also massively increases the complexity of data that vendors like Cloudability must process in order to produce highly accurate RI recommendations. Whereas previously our models needed to accommodate hourly time units for predictive modeling, now with per-second billing a single t2.2xlarge ISF RI has 230,400 opportunities to match a host over a one hour period. Overlaid with 100s of RIs and 100s of thousands of hosts, the sparsity and complexity of the data now mandates a machine learning, model-driven approach to properly yield purchasing recommendations for those operating at scale. Cloudability has followed a machine learning approach to making RI recommendations for its customers and is well positioned to scale our recommendation engine with the recent changes.
The change to per-second billing will benefit CSP customers to varying degrees depending on a number of factors. Those leveraging proper tools and techniques like elasticity, rightsizing and auto scaling will experience a more substantial benefit. Only tools that can scale to accommodate the increased complexity in data and modeling will be viable partners in realizing maximum benefits during the transition. On the whole, customers of Cloudability may notice significant reduction in overall spending as part of the per-second changes, especially when comparing September and October month over month.
Cloudability’s powerful analytics infrastructure can help you quantify exactly how much each of your team saves as a result of the change to per-second billing when evaluating comparable usage patterns. Reach out to learn more or get the conversation started today.
Thanks to Patrick Phillips who contributed to the research supporting this post and Ryan Tyer, James Estes and Nate Putnam who contributed to the technical review.
1. Reserved Instances are a form of discount in exchange for committed spending. Read the AWS documentation for more information.
2. Read the AWS documentation on Instance Size Flexibility.
3. See the AWS documentation on EC2 and IOPS burst for more details.