How to create an AWS EC2 cost estimation (+ saving tips)

How to create an AWS EC2 cost estimation (+ saving tips)

Subscribe to my newsletter and never miss my upcoming articles

There are many strategies by which you can deploy a microservice-based application. One of the most used in the past few years is the container pattern, especially with the rise of Docker containers. Containers are used to package all the necessary executables, configuration files, code, and dependencies so that an application can run reliably on any computing environment.

So many companies use containerized technology on top of ECS or EKS to run microservice applications on AWS. Elastic Container Service (ECS) and Elastic Container Service for Kubernetes (EKS) are container management services that support Docker containers and allow you to run applications on a managed cluster of Amazon EC2 instances. So there is no need to manage the infrastructure to deploy individual microservices.

Container-based deployment and Kubernetes have immense cost-savings potential and are a common approach to reduce operational efforts for deployment.

ECS and EKS are great for container management, but you still need a compute layer to run your containers. Among many compute options are EC2 instances that offer a wide choice of compute power: processor, storage, and networking. If you want to run your workloads on EC2, it’s always a good idea to estimate your costs based on your designed architecture.

To estimate your compute EC2 costs, you can use the AWS Pricing Calculator. Creating a cost estimate will help you better understand your system’s needs and set some expectations around the budget of the project.

EC2 instance types

To start estimating EC2 costs, you need to get familiar with the predefined instance types, so you can identify the best one for you. They are grouped into families that emphasize some possibilities for your workloads:

  • General Purpose – also known as balanced instances, best for web servers, microservices, small and medium databases, development environments, and code repositories.

  • Compute Optimized – designed for compute-intensive workloads, like batch processing, data analytics, scientific modeling, dedicated gaming servers, machine learning, and high-performance computing.

  • Memory-Optimized – memory-intensive applications that process large data sets in memory, such as databases and real-time streaming.

  • Accelerated Computing – used for graphics processing, machine learning, data pattern matching, and other numerically intensive workloads.

  • Storage Optimized – designed for high, sequential read and write access to very large data sets on local storage. Best for NoSQL databases, in-memory databases, data warehousing, Elasticsearch, analytics workloads.

For a typical, simple microservice application, a minimum configuration of t2.medium instance type should do the work. T2 instances are the lowest-cost general purpose instance type. You can easily change your instance types if after a while your needs change.

image.png

Estimating EC2 compute costs in the Pricing Calculator

EC2 Payment models

In the pricing calculator, find the Amazon EC2 service to configure it and get an estimation.

Let’s go and add two EC2 instances. The idea behind that decision is to create a reliable system so that if one of the instances fails, the other one is active and can support the workload. For even bigger reliability you can even add three instances.

There are six possible ways to define your payment model for Amazon EC2 instances:

  1. On-Demand – which is the most flexible one, but the most expensive-looking at a long run
  2. Compute Savings Plans – are the most flexible out of the saving plans, with cost reduction up to 66%. With this plan it’s possible to change compute instances from one type to another, also apply different sizes and shift workloads from one region to another, or even move from EC2 to Fargate or Lambda. All within the same plan.
  3. EC2 Instance Savings Plans – this plan costs the least, with cost reductions up to 72%. But you need to commit to an individual instance type in a region. In the region, you have the flexibility to change usage within the same family instance.
  4. Reserved Instances

    • Standard RI – capacity reservations that recur on a daily, weekly, or monthly basis. Typically provide the highest discount levels.
    • Convertible RI – if you don’t have a good understanding of your long-term requirements you can choose Convertible RI, as they enable you to change the instance family and other parameters associated with a Reserved Instance at any time, as many times as you need. They offer a significant discount (typically 45% compared to On-Demand).
  5. Spot Instances – unused EC2 instances that run whenever capacity is available and can be purchased for a smaller price than the On-Demand instances. You can see pricing options here.

Comparing pricing models

A comparison table for two EC2 instances:

Pricing modelPrice / month
On-demand67.74 USD
Compute Savings Plans1 year – 48.33 USD
3 years – 33.73 USD
Additional discounts for upfront payment
EC2 Instance Savings Plans1 year - 41.90 USD
3 years - 29.20 USD
Additional discounts for upfront payment
Standard Reserved Instances1 year - 41.90 USD
3 years - 29.20 USD
Additional discounts for upfront payment
Convertible Reserved Instances1 year - 48.33 USD
3 years - 33.73 USD
Additional discounts for upfront payment
Spot Instances21.02 USD

As you can see, Spot instances can bring you up to 30% of savings compared to on-demand instances, but your application should be flexible about when they run or be interrupted. This is good for some background processing, batch jobs, or data analysis.

Reserved instances are also a good saving option, having in mind you need to be committed to a yearly contract and know in specifics your compute requirements. This is really hard to do in the very beginning, so you’ll probably get to this approach once your solution is mature and you can determine costs based on past performance.

If you’re just starting with your application, then it’s probably best to go with the simplest choice – On-demand resources. This means that you pay per hour for your compute capacity, and you pay for as much as you use. You also have control over the instances’ livecycle, when it starts, launches, stops, or terminates. With that kind of flexibility, you can introduce your own schedule of working.

Saving tip: We here are assuming to need 730 hours of compute power in a month, which means we’re considering instances working non-stop 24/7 for the whole month. This will probably not be the case all the time. There might be periods in your project where you’ll need all the instances up and running all the time, but for the most part of the development process, you’ll need them during work hours and on workdays.

So a rough estimate of this would be:

  • 5 days a week x 8 working hours = 40 hours per week x 4 weeks in a month = 160 hours
  • 2 instances x 0.0464 USD x 160 hours in month = 14.85 USD

Which in fact is the lowest sum of them all. So with some smart decisions that your application allows, of course, you’ll be able to remain flexible and save money at the same time. Here is how you can reduce AWS costs in non-production environments.

EBS Storage

You can also add block storage volumes to each instance. Amazon Elastic Block Storage is designed for use with EC2 for throughput and transaction-intensive workloads, such as relational and non-relational databases, containerized applications, file systems, and more.

There are six different volume types, depending on the performance, volume size, and price. In order to learn more here is a great article about AWS EBS Pricing. For the purposes of a simple microservices application, you can choose General Purpose SSD (gp2) with the default storage of 30 GB.

  • 30 GB x 0.10 USD x 2 instances = 6.00 USD (EBS Storage Cost)

AWS Free Tier includes 30GB of Storage, 2 million I/Os, and 1GB of snapshot storage with Amazon Elastic Block Store (EBS).

Saving tip: One of the cost optimization best practices is to look for unattached EBS volumes in your AWS accounts. This kind of waste can be really easy to produce, especially if you have been working with AWS for a long time and launched many instances without checking the delete box. Be sure to consider this into your AWS cost savings strategy.

Advanced estimate

If you need a more detailed estimate for EC2 with concrete metrics for workload, data transfer, and storage, you can create an advanced estimate in the pricing calculator. This allows you to define workload patterns such as:

  • Constant usage – constant predictable load
  • Daily spike – peaks once a day, like midnight running tests
  • Weekly spike – peak once a week, like a blog posting
  • Monthly spike – once a month, like some reports

This helps you create the right balance between On-demand and RIs usage, so you can cover your workloads in the most efficient and cost-optimal way.

image.png

Conclusion

EC2 instances can be a significant part of your cloud costs, especially if your infrastructure is based solely on these compute instances. Therefore, it’s a good idea to estimate your compute costs for your planned resources.

With the AWS Pricing Calculator, you can estimate costs for EC2 workloads. There are two options available: Quick and Advanced Estimates, depending on how detailed an estimate you need.

You can also divide your resources into groups using cost allocation tags, and estimate costs for each of those groups.

You should also continuously monitor the usage so that you can optimize your cloud costs. This is beneficial so that you can prevent overprovisioning of instances, shut down instances on non-production environments when you’re not using them, and understand whether your workloads are eligible for reserved instances.

Microtica’s Cloud Waste Manager can help! Book a demo today!

 
Share this