Right-sizing My Multi Tier Web Application on AWS: Unleashing the Cost Savings Potential on AWS

In my previous post, we explored hosting and running a multi-tier web application on AWS.

https://medium.com/@can.yalcin/host-run-a-multi-tier-web-application-on-aws-lift-shift-19ad0adeb074

This time, we’ll shift our focus to optimizing that setup. We’ll delve into right-sizing our technology stack, which means ensuring we’re using the most efficient resources for our application’s needs. This process can unlock significant cost-saving opportunities, so let’s dive in!

Don’t Overpay for Cloud: A Guide to Rightsizing Your AWS Instances

Imagine buying a car with a monster engine just to drive to the grocery store down the street. That’s kind of what happens when you don’t rightsize your instances on AWS.

Rightsizing is all about finding the perfect fit. It’s the process of matching the type and size of your instances to your workload’s needs. You want them powerful enough to handle the job, but not so powerful that you’re wasting money on unused resources.

By rightsizing your instances, you can:

• Save money: This is the big one! You’ll only be paying for the resources you actually use.
• Improve performance: Properly sized instances can actually run smoother than their oversized counterparts.
• Reduce waste: No more paying for unused processing power or storage space.

Many organizations jump into the cloud headfirst, prioritizing speed over efficiency. They get their applications up and running quickly, assuming they can optimize costs later. This approach, common among many organizations (including our own — we recently lifted and shifted our application to AWS!), can lead to unnecessary expenses in the long run. To avoid falling into this trap ourselves, let’s shift gears and focus on rightsizing our cloud environment.

Understanding Our AWS Workload: Scaling for Weekday Waves

Running a web application comes with traffic fluctuations. My app is no different — it experiences a surge of visitors during weekdays, averaging 15,000 daily. These visitors typically spend around 2 minutes on the platform, leading to higher CPU usage on weekdays compared to weekends.

To handle these traffic spikes, I’ve leveraged the power of AWS. Here’s a breakdown of my setup:

• Tomcat Application: This is the engine powering my website. Its CPU usage can reach 75% at peak times, but thankfully, these peaks are infrequent.
• Autoscaling Group: This is the magic behind handling the traffic variations. It’s configured with a minimum of 1 instance and can scale up to 4 instances to meet demand. The autoscaling group aims to maintain an average CPU utilization of 50%, ensuring smooth performance even during peak hours.
• Instance Type: I am utilizing 4 m5.large instances for both the Tomcat application and backend servers. These instances provide 2 virtual CPUs (vCPUs) each, offering a good balance between cost and performance.

For network management, I rely on:

• Application Load Balancer: This distributes incoming traffic across our Tomcat instances, ensuring visitors experience consistent performance.
• Security Groups: Three separate security groups with a total of 8–10 rules define network access for my resources, keeping things secure.

Additional AWS Services in Play:

• S3 Bucket: This acts as our storage solution, holding a small amount of data (less than 1 GB per month).
• Amazon Route 53: This manages my private hosted zone, essentially the address book for my internal network.
• Certificate Manager: This service takes care of our SSL certificates, ensuring secure connections for our users.

The estimated cost: monthly and yearly:

Keeping your cloud costs under control is a constant battle, especially when your applications rely heavily on EC2 instances. These instances are often the biggest contributor to your AWS bill, so optimizing their size can have a significant impact on your bottom line.

As dicussed above, I want an option that delivers strong performance during peak hours while keeping costs in check during lulls. This is where burstable instances come in.

What are Burstable Instances?

Think of a burstable instance like a car with a built-in speed boost. These instances provide a baseline level of CPU power for a sustained period, but also offer short bursts of additional CPU power when needed. These bursts are fueled by CPU credits, which are slowly replenished over time. As long as your workload stays within the baseline and occasionally uses the credits for short spikes, you won’t incur any additional charges.

M5.large vs Burstable Instances: A Breakdown

Now, let’s compare my current m5.large instances to burstable instances:

• M5.large: These instances offer a consistent level of CPU power (2 vCPUs) well-suited for workloads with steady demands. They are a good choice for applications that require predictable performance. However, during our weekend lulls, I might be paying for more power than I actually use.
• Burstable Instances (T3 family): A T3 instance, like the t3.large which has the same specs (2 vCPUs, 8 GiB memory) as my m5.large instance, provides a baseline CPU power with the ability to burst for additional power using CPU credits. This aligns well with my fluctuating traffic patterns. During weekdays, I can leverage the burstable CPU credits to handle surges in visitors. On weekends, when usage is lower, I’ll benefit from the credits being replenished, reducing my costs.

Since the t3 family seems like a better fit for my needs, let’s explore the potential cost savings when switching from an M5 large instance to a t3.large instance. I’ll break down the estimated monthly and yearly costs to help myself to make an informed decision.

The following image illustrates the monthly and yearly costs associated with switching from m5.large to a t3.large instances:

In a significant win, I slashed my yearly cloud costs by 15.2%, bringing the total down from $4,373.56 to $3,708. This impressive saving was achieved simply by rightsizing my EC2 instance types after closely monitoring resource utilization.

But can I optimize further? Since my application relies heavily on EC2 instances, exploring EC2 Savings Plans is the next logical step to potentially reduce my cloud bill even more. Let’s delve into this option!

After checking all plans and considering my options, I’ve recently implemented EC2 Instance Savings Plans with a 1-year reservation, incurring no upfront payment.

This strategic move has resulted in a significant reduction in my yearly costs, bringing them down from $4,373.56 to just $2,464.08 — that’s a winning percentage of 44.1%!

I am ecstatic about these savings, but is this the ultimate solution? Let’s delve deeper and explore the potential benefits of upfront payment options:

I just optimized my EC2 Instance Savings Plans by switching from a No Upfront option to a Partial Upfront payment plan, while maintaining my 1-year reservation. This resulted in a significant cost reduction, bringing my annual spend down from $4,373.56 to $2,362.51.

That’s a substantial saving of 46.18%. By taking advantage of this Savings Plans flexibility, I was able to achieve considerable cost savings without sacrificing the benefits of a reserved instance.

While there are further optimizations to discover, this blog post focuses on the immediate cost reductions achievable through rightsizing and leveraging AWS Savings Plans. By implementing these strategies, you can gain significant savings without sacrificing performance. It’s important to remember that cost optimization is an ongoing process, and there’s always room for further exploration.

Summary

In my quest to optimize my AWS setup, I focused on ensuring our resources efficiently met my application’s needs. This involved rightsizing my instances — I swapped m5.large instances for t3.large burstable instances, a better fit for my workload. I then explored AWS Saving Plans, identifying significant cost-saving opportunities. By implementing these changes, I achieved a dramatic reduction in my annual costs. My initial expenditure of $4,373.56 dropped to $2,362.51, representing a cost reduction of 46.18%.

In conclusion, I hope you found this blog informative! Remember, cost optimization is a continuous journey, not a one-time destination. There’s always room to uncover new efficiencies. So keep exploring ways to improve, and have AWSome days!