The cloud has gone mainstream.
Ninety percent of organizations already use the cloud in some form, and the worldwide public cloud services market is forecast to grow 17% this year to a total of $266.4 billion.
As cloud computing continues growing in popularity, an increasing number of enterprises are turning to the cloud for their storage and computing needs. In fact, an organization’s average yearly cloud budget was $2.2 million in 2018 — and that figure is only set to climb as the cloud becomes increasingly ubiquitous.
Cloud Optimization Challenge
Despite the massive growth of the cloud, it remains difficult for organizations to select and assign the right resources to a cloud application. As a result, companies spending money on cloud computing are almost certainly squandering funds on wasted resources.
Regardless of the provider used, there are many ways to implement the same application in the cloud. The challenge is that every application has its own unique set of constraints, from the cost of development and the cost of ongoing maintenance (staffing) to the cost of running cloud services themselves, the volume of traffic and the importance of future scalability.
Consequently, companies doing business in the cloud today need to find the right balance between the design of the application, the selection of cloud services and how those services are used in order to make the most effective use of their cloud resources.
So, how can companies know whether they are maximizing their cloud computing? In this post, we’ll examine how organizations can optimize their cloud costs to achieve efficiency using Amazon Web Services.
AWS Pricing Calculator
First, the “AWS Pricing Calculator” allows users to configure a cost estimate that fits their unique needs with AWS products and services. While quite useful, the tool is not perfect — it’s not complete for all the different services and it can be quite difficult to understand.
Adding to the challenge, it’s nearly impossible to determine the most cost-effective cloud architecture before you actually start building your application. In AWS, you pay for three main things:
- Data transfer in/out/between AWS regions
- Data storage per hour
- Computing resources per hour
However, there’s a significant amount of variation. Some services are more expensive than others for executing the same kind of function. Some are faster. Some scale better. Some are either easier or more difficult to develop for, and some require more or less ongoing maintenance than others.
Knowing this, the application design might have to be made more complicated in order to use AWS services in the right way to minimize costs (e.g., chunking data into larger sizes to minimize the number of requests). Because the price calculator is not perfect and there are many unknowns before development begins, it remains challenging to determine the most cost-effective architecture upfront. As such, optimizing the cost often fails to line up with optimizing the architecture because, in order to reduce the cost, you have to make your application more complicated or make compromises in the app’s design.
Two Specific Examples
1. How you might build a web app or service on Amazon.
On Amazon, there are two main ways to build a web app or service. First is Amazon EC2 (Amazon Elastic Compute Cloud), a web service that provides secure, resizable compute capacity in the cloud. Next, we have AWS Lambda, an event-driven, serverless computing platform.
With Lambda, users pay by the request count (how many requests per hour), by how many seconds of compute is used and by how many GB of memory is used per second. Because they’re effectively paying by how many requests the tool processes, as well as how much computing and memory each of your requests used, if you don’t have that many requests, then the cost can be close to zero.
With EC2 on the other hand, you have a full virtual machine in the cloud, and you pay for every hour or minute that it’s running. Users select a machine that has a specific computing and memory capacity, with the more powerful the machine costing more per hour to run. Even if they don’t have any requests coming in, they still pay the same amount per hour, regardless of whether the machine is actually doing anything.
While both are used to run web services and web applications, each has accompanying pros and cons.
Lambda, for example, is much cheaper for low-request volumes because users pay by request rather than having it running all of the time. But once larger request volumes are reached, the cost becomes more similar to that of EC2. Plus, because the architecture is so different between the two tools, users must design their app specifically to run on Lambda. Complicating matters further, it can be difficult to run some legacy software on Lambda owing to its more restrictive sandbox environment. EC2, being a full virtual machine, can run any software because the developer has full control over the system.
The tradeoff? While there’s the potential for lower costs, it’s a bit more difficult or less general to build apps on Lambda than EC2, but the latter is more expensive. Lambda is ideal for a subset of vanilla apps with regular functionality — talking to a database, doing a few calculations — but if you have something that requires special software or third-party services and plugging things together, EC2 might be the better option.
2. How your application might use the storage on Amazon in different ways.
Amazon S3, the tech giant’s object storage service, is one of the most popular AWS offerings with flexible pricing. With it, you simply pay for the used storage space and the number of requests that are made to access your data. Because you pay per request, it doesn’t matter how big the file being uploaded is — it’s the same cost. Consequently, if you upload thousands of tiny files, the request charges add up. However, if you upload one giant file, you only pay one request charge for that.
In this example, the per-request costs for S3 can add up quite quickly if the app is set up to save lots of small files often, which is common. For example, we were working on a video streaming application in which lots of little chunks of video were being saved every few seconds. To save money, we could redesign the app to combine files, buffer them into a giant file and upload that. We’d save money because we’re making fewer requests, but the downside is the app would become more complicated — there’s a greater chance of it breaking and it takes longer to develop.
In each example, cloud optimization involves toeing the line between the complexity of the app and the cost to deploy it in the cloud.
Enter Cardinal Peak
From the design of the application to the way it’s used, there is not a one-size-fits-all list of key metrics to drive optimization, so users need to assess their unique needs before moving forward. In our experience, it’s rare to find a use case in which a design is naturally cost-effective straight away. We’ve often had to jump through hoops — assessing things like the cost of development, the cost of ongoing maintenance and the cost of the services themselves, as well as the volume of traffic and how scalable the app is — to reduce the cost of building an app or using cloud storage.
Cloud optimization is not a straightforward process, and there are myriad reasons for why companies are failing to capture the cloud savings that they envisioned. At Cardinal Peak, we are an AWS design partner. That means we’ve developed numerous AWS-based solutions for clients both large and small, and our expertise with AWS enables our team to develop cost-effective and scalable cloud solutions that advance your business.
When it comes to the cloud, we know what we’re doing, we care about minimizing and ultimately optimizing your costs for the app you want to build and we possess extensive experience in building good systems that are cost-effective. Let us know how we can help take your innovative cloud-based application to the next level!