Amazon Web Services (AWS) is the premier cloud platform globally, covering over 1 million users in 190 countries. With a comprehensive array of cloud services covering secured networking, virtual servers, databases, big data processing, object storage, AI/ML, and more, AWS offers IT resources on an On-Demand basis with a flexible pay-as-you-go pricing structure.
Companies are drawn to AWS-based cloud computing for three primary reasons: unlimited scaling and capacity, cost-effectiveness and flexibility, and user-friendly interfaces. AWS likens its services to utility offerings, billing customers based on their usage time and capacity. This shift eliminates capital expenditure, as AWS supplies all resources and trims operational expenditure to usage only, removing the wait for a break-even point or cost recovery.
However, efficiently managing extensive IT infrastructures in AWS requires a precise cost management strategy. Even the most experienced IT operations teams can struggle with the complexity of billing, especially for modern distributed applications that utilize various services, often resulting in unexpectedly high charges.
In this article, we'll introduce cost-saving methods to reduce cloud expenses when planning & managing a cloud infrastructure.
What financial challenges you can face within AWS Cloud
While AWS is a primary public cloud service provider, it brings specific challenges, particularly in cloud spending. Many large and small businesses are perplexed by AWS's intricate pricing structures.
Here are some of the financial issues organizations can encounter when hosting with AWS.
Changing pricing structures:
AWS's virtual server (EC2) service offers over 40 instance type families, each with a dozen or more specific instance types. These vary in price and are subject to change, with older instance types seeing price reductions as new ones are introduced.
Changing architecture:
Evolving application architectures lead organizations to adopt new AWS services and features, impacting the size of their cloud infrastructure. Predicting changes becomes challenging when responding to dynamic needs, such as adding a microservice or adjusting the AWS API Gateway.
Unpredictable usage patterns:
To ensure the high availability of critical services, AWS customers often utilize native scalability features, like auto-scaling groups. However, running this with On-Demand Instances can be expensive in the long run. Predicting usage patterns becomes challenging due to the rapid environmental changes to meet traffic demands.
Cloud adoption without proper planning introduces unpredictability for engineers. Onboarding new users, implementing new features, application re-architecture, and the need for high availability all contribute to dynamic workloads.
Operations and finance teams attempt to manage cloud costs by pre-purchasing capacity with Reserved Instances (RIs), Spot Instances, or Savings Plans (SPs). However, aligning these options with actual usage patterns can be challenging. The imbalance arises because usage patterns estimated at the start of the fiscal year may not align with practical needs. Constantly managing these instances and discount plans becomes a cumbersome task for AWS administrators, emphasizing the need for a more automated, real-time solution.
Various AWS pricing models
AWS provides a range of pricing strategies to assist users in selecting the most suitable option for their resources, focusing mainly on compute and database resources. These models are relevant to
- Instances on EC2
- Database instances on RDS
- Cluster nodes on Redshift
- Nodes on EMR
- Functions using Lambda
On-Demand Instances
The default pricing model for AWS instances is the On-Demand model, where customers are billed by the minute or hour without any upfront payment for resource usage. The key advantage of On-Demand is its flexibility, allowing users to scale without a long-term commitment or pre-payment.
However, this flexibility comes at a cost, as On-Demand is the most expensive option.
Scaling applications solely with On-Demand instances without proper planning can significantly impact monthly bills.
For example, running an m5.xlarge Linux EC2 instance 24x7 with specific configurations in the us-east-1 region would result in a monthly cost of $174.81 (as of July 2023) using the AWS pricing calculator.
Alternatively, purchasing a Reserved Instance for the same node with a one-year commitment and no upfront payment would reduce the monthly bill to $122.98. With a monthly difference of $51.83, it's evident that On-Demand Instances are not cost-effective for scalability, return on investment (ROI), or long-term, predictable usage.
However, there are valid use cases for having a small percentage of On-Demand instances:
- Pre-production workloads: instances used in development, testing, or Proof-of-Concepts (PoC).
- Initial AWS exploration: when experimenting with AWS for the first time.
- Seasonal workloads: some workloads, such as end-of-year sales or holiday peaks, may be seasonal. For these scenarios, using On-Demand instances during peak periods and scaling down afterward can be more cost-effective than committing to long-term cases.
Spot Instances
With its vast infrastructure, AWS often has unused resources, leading to the introduction of Spot Instances to minimize upkeep costs for these surplus resources.
Think of Spot Instances as discounted opportunities, akin to airlines offering reduced prices for unoccupied flight seats. As leftover capacity, customers can acquire these instances at savings of up to 90% off the On-Demand price. However, there's a catch. If another paying AWS customer needs the capacity and is willing to pay On-Demand, the Spot Instance is terminated, and the capacity is reassigned. While Spot Instances are suitable for short bursts of performance, they are not recommended for long-running workloads.
Despite their cost-effectiveness, Spot Instances come with risks. They lack coverage under the AWS SLA, meaning AWS doesn't guarantee uptime even if you hold a Spot Instance.
Consequently, they are not considered a viable option for mission-critical production applications.
To use Spot Instances effectively, users must establish a robust launch configuration, including accurate predictions of instance outages, timely bidding in the Spot market, automated handling of terminations, load balancing configuration, and more.
Source: AWS
However, Spot Instances can benefit certain workloads where risks can be accepted. Examples include:
- CI/CD pipelines: losing an instance means rerunning an unfinished workflow when another instance becomes available.
- Non-production workloads: workloads that don't require continuous uptime.
- Workloads with quick data regeneration: where lost data can be regenerated swiftly.
- Containerized workloads: instances are needed periodically for container orchestration.
Also, Spot Instances can be cost-effective when used with commitment-specific pricing models. For instance, a travel booking application using Reserved Instances can detach them from other nodes and attach them to additional nodes during peak seasons, ensuring performance and cost savings without committing to more Reserved Instances.
Reserved Instances explained
Reserved instances (RIs) offer a pricing alternative similar to the default On-Demand model but with a key distinction. Customers "reserve" a specific resource for a term ranging from 1 to 3 years. As part of this reservation, an upfront fee is paid, which can take three forms:
- Full upfront payment: the total cost of running the instance over the chosen period.
- Partial upfront payment: a partial cost of running the instance over the chosen period.
- No upfront payment: no upfront payment for the instance over the chosen period.
Savings of up to 72% on AWS instance costs can be achieved based on upfront payment, the term (1 or 3 years), and the type of RIs available. In simple terms, higher upfront payments and longer commitments result in greater savings.
There are three types of RIs, each with a specific best use case
Standard Reserved Instances
Ideal for steady-state production systems running for extended periods.
Scheduled Reserved Instances
Suited for production systems with predictable peaks and workloads running for extended periods.
Convertible Reserved Instances
Designed for production systems with extended runtimes that may have slightly different needs.
It's important to note that RIs are not tied to a specific instance but function more like a purchased license. They can be applied to several instances and switched between eligible cases. While RIs offer significant cost savings, managing them manually can be challenging, especially considering the obligation to pay for reserved capacity regardless of usage.
Recognizing the challenges users face with unused RIs, AWS introduced the AWS Reserved Instance Marketplace. This platform allows organizations to list their unused RIs for sale, providing flexibility in commitment terms. RIs with up to one month remaining on their term are eligible for sale in the Marketplace.
Spot Instances and Reserved Instances: key differences
Comparing costs: On-Demand vs. Reserved Instance for m1.large linux instance in US-east
Introducing Savings Plans
In 2019, AWS introduced Savings Plans as an alternative to Reserved Instances. Unlike Reserved Instances, Savings Plans don't require a commitment to a specific payment term or instance type. Instead, customers commit to a minimum spending amount per hour for either one or three years. In return, AWS offers a significantly reduced hourly rate during the committed term. Savings Plans apply to computing resources such as EC2, Fargate, or Lambda, providing the flexibility to choose the best instance type for pricing discounts.
- Compute savings plans
Ideal for systems with rapid evolution and potential shifts to different services or EC2 instance families. While more expensive, Compute Savings Plans offer greater flexibility. They can be applied to EC2 instances, Fargate, or Lambda services, covering any instance family, size, AWS region, operating system, or tenancy. Savings can reach up to 66%.
- EC2 savings plans
Specifically for EC2 instances, applicable to a particular instance family in a specific region. This applies regardless of availability zone, covering any instance size, operating system, or tenancy. Suited for large but predictable workloads, EC2 Savings Plans are more restricted but provide higher savings, up to 72%.
Savings plans have some drawbacks, such as being limited to EC2 Compute, Fargate, and Lambda usage only. They do not cover RDS, EMR, or Redshift expenses. Unlike Reserved Instances, Savings Plans also lack a marketplace for selling unused instances. This means customers are committed to spending the minimum amount for the chosen duration, and overcommitting can lead to a significant expense spike. Purchasing Savings Plans requires careful planning compared to alternative pricing models.
While hybrid cloud adoption offers benefits like cost reduction and improved efficiency, it comes with challenges. Hybrid cloud security becomes complex, and responsibility shifts to developers, potentially creating a skills gap. Data transfer between clouds introduces vulnerabilities, emphasizing the need for robust encryption. Governance and compliance pose challenges, managed differently across on-premises, private, and public clouds, requiring training for successful implementation.
So, what have we come to in the real case? Using Reserved Instances and AWS Savings Plans together can be very efficient and economically reasonable
We would like to explain and show on a live example that when you buy an AWS Savings Plan, it doesn't mean you can ignore saving money in other ways. Many people who get AWS Savings Plans already have Reserved Instances for a better deal. Getting rid of all your Reserved Instances and switching to only Savings Plans isn't the smartest money move. On the flip side, having only Reserved Instances might not be flexible enough for your business needs. Combining both methods gives you good discounts and the flexibility to adapt in the long run.
Let’s look at one of our customers' AWS accounts and how much such a combination saves his pocket monthly. This screen displays expenses for the past month, broken down by services. As you can see, more than half, namely 65%, go to computing services.
Now let’s have a look at the Reserved Instance & Savings Plan Summary for the previous month:
In total, such a combination saved our client more than $128,000 last month.
It will also be interesting to see the statistics for half a year, which shows that this approach saved our client approximately $750,000.
So, if you layer Reserved Instances on top of your AWS Savings Plan, you get an extra discount that helps save money until your reservations expire. If you have things you know will use resources consistently and aren't covered by Reserved Instances, using an AWS Savings Plan on them is a safe choice.
Closing thoughts
Effectively navigating cloud computing with AWS necessitates careful preparation and strategic planning. Understanding the required resources for your workload and making informed estimates about usage patterns can significantly contribute to optimizing your cloud expenses. Additionally, hosting simpler applications on AWS tends to be more cost-effective, prompting consideration for re-architecting large monolithic applications into smaller, independent services that collaboratively function.
However, it's crucial to recognize that no one-size-fits-all solution exists for every scenario. Each use case comes with its unique set of requirements, and a well-thought-out combination of pricing plans often yields better results. For instance, employing a blend of Reserved Instances and Savings Plans can effectively cover uninterrupted production workloads while complementing the remaining needs with a mix of On-Demand and Spot Instances through automated monitoring and pricing calculations.
Implementing such a system, although beneficial, is not without complexity. Developing an efficient mechanism to manage instances, plans, and billing requires intricate engineering work involving time that might otherwise be spent on developing new features for your application.
Cut your Kubernetes cloud bill with these 5 hacks for smarter scaling and resource tuning
PostgreSQL blends relational and NoSQL for modern app needs
Mutable vs immutable infra key perks drawbacks and Terraform hacks