AWS Cost Optimization Case Studies · Remote Since Forever

The most Flexible AWS Savings Plan

2024-03-11T01:12:09+01:00

AWS provides several ways to reduce your cost but no other program is as flexible as the Compute Saving Plan. This article covers what you need to know to successfully and efficiently use the AWS savings program.

What are Savings Plans

Put plainly, all AWS cost-saving plans offer cost reductions compared to On-Demand prices, in exchange for a long-term commitment. That commitment is 1 or 3 years long and is an hourly spend commitment type.

AWS provides three types of Savings Plans:

Compute Savings Plans,
EC2 Instance Savings Plans, and
Amazon SageMaker Savings Plans.

The focus of this article is on the most flexible type of savings plan which is the Compute Savings Plan.

Research, Research, Research

The first step we need to take is to see if there are any Recommendations. This page might tell you what AWS recommends to purchase. Not everyone gets this kind of suggestion as they are based on your usage.

Follow the next example to understand how to purchase a Compute Savings Plan.

A Simple Example: Get a Discount on a Single t4g.micro EC2 Instance

This is a straightforward example. In this example, the commitment is for 1 year in Europe (Ireland), the eu-west-1 region.

A very important note is to know that discounts vary from Region to Region so do your research beforehand.

Step 1: Check Your Bill

Find your bill in the AWS console. You can see something like this.

AWS Bill screenshot made by the author.

We identified that we are paying On-Demand prices for a t4g.micro EC2 instance.

Step 2: Identify the Savings Rate in Your Region

Find out in which region your EC2 instance is hosted. After that access the table at Savings Plan Compute Pricing page. That page will show you a table like the one below.

AWS Savings Plan Compute Pricing Page screenshot made by the author.

The goal is to get a discount on the usage of a t4g.micro EC2 instance.

On-Demand rate — $0.0092 * 720 hours (hours in a 30-day month) = $6.624
Savings Plans rate — $0.0075 * 720 hours (hours in a 30-day month) = $5.62500
Savings over On-Demand — 18%

If you commit to a 3-year term the savings will be 42% instead of 18% for the Ireland Region.

Step 3: Purchase a Plan

So the purchase plan will look like this.

AWS Savings Plan Purchase screenshot made by the author.

AWS Savings Plan Cart screenshot made by the author.

Important notes:

Do not purchase large plans and over-commit.
Purchase small plans and then monitor the coverage.
If you need more coverage at a later period in time you can purchase additional savings plans.

The hourly commitment rate is the one after the discount — the Savings Plans Rate.

Reports Analysis

Utilization Report

Below you can see a sample utilization report for a single day after the savings plan has been purchased.

AWS Utilization report screenshot made by the author.

Coverage Reports

Under the “Billing and Cost Management / Savings Plan” menu, you can find the Coverage report. Here you can get information about how much of your spending has been covered by a savings plan during a certain period. You get information such as Average coverage, Potential monthly savings vs On-Demand, and On-Demand spend not covered.

Before Creating a Savings Plan

This is an example of a Coverage report showing no active Savings plan. It has yet to be activated.

AWS Coverage report screenshot made by the author.

After Creating a Savings Plan

This is an example of a Coverage report that shows an active Savings plan with a coverage of 43%

AWS Coverage report screenshot made by the author.

It is very difficult to get 100% coverage so start with 50% and iterate.

Do Your Research First

As described above Compute Savings Plan represents a flexible savings plan that supports multiple regions, and services and you commit to a dollar amount instead of an instance type or size. But there are dangers as if you calculate wrong then you are stuck paying that committed dollar amount.

If you purchase Savings Plans you commit to a certain dollar amount on a period and you can not cancel. Therefore be careful and do your research first before committing to any kind of Savings Plan.

Migrating EC2 to AWS Graviton (ARM): A Cost-Reduction Case Study

2024-02-11T05:59:43+01:00

The world of cloud computing is changing fast, that is a fact. Some changes have a more significant impact, as was the case with the rise of AWS Graviton processors.

The whole tech industry is experiencing the growing adoption of ARM architecture, so why should it not be the case with the Cloud as well?

This article focuses on the impact of AWS Graviton on the Cloud offering, the shift towards the ARM architecture, and how Clearview is helping clients jump on the Graviton train and save on costs up to 20%.

Key points on AWS Graviton

AWS Graviton processors are becoming popular because of their superior performance and energy efficiency in cloud environments which reduces your carbon footprint,
Adapting the ARM architecture requires data migration or possible code improvements before benefiting from the superior improvements in both cost and performance.

The Rise of AWS Graviton

Understanding AWS Graviton Processors

AWS Graviton processors are powered by ARM architecture, enabling performance and cost optimizations, which represent a significant advancement in cloud computing, compared to traditional x86 processors.

Graviton processors are optimized for Cloud workloads with the following benefits:

Large L1 and L2 caches for every virtual central processing unit (vCPU), meaning that most of your workload never burdens RAM,
Every virtual CPU is a physical core, meaning more isolation between virtual CPUs,
Cores are connected in a fast mesh with ~2TB/s of bisection bandwidth, which allows applications to move very quickly from core to core,
Graviton’s RAM architecture means you don’t need to worry about application memory allocation, or which cores are running the application.

Generations of AWS Graviton

Graviton processors come in various generations with each generation offering various advances in processing power and efficiency.

Graviton

The first generation ARM architecture-based, known as A1 type, Graviton-powered EC2 instances were launched in 2018. Not every region is still providing this first-generation instance type. Use the following awscli command to check if a region supports the A1 instance type.

aws ec2 describe-instance-type-offerings \
    --location-type "availability-zone" \
    --filters Name=location,Values=us-east-2a \
    --region us-east-2 \
    --query "InstanceTypeOfferings[*].[InstanceType]" \
    --output text \
    --profile default | sort | grep a1

This processor features:

64-bit ARM Neoverse cores,
The instances are up to 40% less expensive than the same number of vCPUs and DRAM available in other instance types.

Graviton 2

Launched in 2019 it represents the second generation of AWS Graviton processes. Graviton2-based instance types offer up to 40% better price performance than fifth-generation instances.

Graviton 2 Instance types

We now have 12 instance families (M6g, M6gd, C6g, C6gd, C6gn, R6g, R6gd, T4g, X2gd, Im4gn, Is4gen, and G5g) that are powered by AWS Graviton2 processors that provide significant price performance benefits for a wide range of workloads.

Graviton 3

Launched in 2022, it is the third and latest generation that is generally available. When compared to AWS Graviton2 processors it provides:

up to 25% better computing performance,
up to 2x better floating-point performance,
up to 2x faster crypto performance, and
up to 3x better ML performance,
support for bfloat16,
and features the latest DDR5 memory, which provides 50% more memory bandwidth compared to DDR4.
up to 60% less energy usage for the same performance than comparable EC2 instances.

Graviton 3 instance types

All 7th generation instance types containing “g” means it is based on AWS Graviton 3, the silicon designed by AWS. Examples:

C7g, C7gd, C7gn: the “C” instance family is designed for compute-intensive workloads,
M7g, M7gd: “G” instance family is designed for general-purpose workloads with balanced computing, memory, and networking,
R7g, R7gd: The “R” instance family is designed for memory-intensive workloads.

Graviton 4

Launched in late November 2023 Graviton 4 represents the fourth generation and it is still in preview only, with general availability planned in Q1 of 2024. When compared to Graviton3 processors it provides:

up to 30% better computing performance,
50% more cores,
75% more memory bandwidth.

Graviton4 will be available in memory-optimized Amazon EC2 R8g instances, which are currently in preview only. R8g instances offer larger instance sizes with up to 3x more vCPUs and 3x more memory than current generation R7g instances. To learn more about Graviton4-based R8g instances, visit this link.

Switch your AWS Services to Graviton

Here we will describe which services we have switched over to AWS Graviton.

Some services can be switched with a few clicks, while others require a full data migration following best practices.

AWS EC2

Following is a tutorial on how we switched EC2 instances. Please note that t4g is run on Graviton 2. Migrating our NodeJScode to be compatible with ARM architecture meant upgrading a few packages only.

Note: do not forget to set your awscli profile as in all of these examples the default one is used.

Find ARM LTS Ubuntu Images

For the latest LTS which is 22.04 LTS (Jammy Jellyfish), currently.

aws ec2 describe-images \
    --filters "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-arm64-server-*" "Name=architecture,Values=arm64" \
    --query "sort_by(Images, &CreationDate)[].[Name, ImageId, Architecture]"  \
    --output text \
    --region us-east-1 \
    --profile=default

This command will show you the IDs of the images that support the ARM architecture. Choose one and set it at the next step.

Set AMI ID

As the AMI ID has been found in the previous command, we need to save it to a variable.

AMI_ID=ami-02ddaf75821f25213

List EC2 Key Pairs

The following commands will show keys that were added previously. If you get an empty result you need to add your public SSH key.

aws ec2 describe-key-pairs \
  --region us-east-1 \
  --profile=default

Find the Availability Zone

The zone is directly connected to the subnet.

aws ec2 describe-instance-type-offerings \
--location-type availability-zone \
    --filters Name=instance-type,Values=t4g.small \
    --region us-east-1 \
    --profile=default

Note: This step is very important as you need to find the what availability zone supports your instance size.

Find the Subnet and Security Group

We need to find the correct Subnet and SG.

List Security Groups

aws ec2 describe-security-groups \
    --query "SecurityGroups[*].{Name:GroupName,ID:GroupId}" \
    --region us-east-1 \
    --profile=default

List subnets

aws ec2 describe-subnets \
    --region us-east-1 \
    --profile=default

Note: Find the correct subnet that is used by your old EC2 instance.

Create the EC2 Instance

Please note that the following command is an example only and that you need to change the values for:

the key name,
the subnet ID,
the security group ID,
set your tags,
use your profile name.

aws ec2 run-instances --image-id $AMI_ID --instance-type t4g.small  \
    --key-name nedim \
    --subnet-id subnet-000000000000000 \
    --security-group-ids sg-00000000000000000 \
    --associate-public-ip-address \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ubuntu-test-graviton}]' \
    --region us-east-1 \
    --profile=default

Prepare the image

Connect to the VM, and run the system upgrade.

New Server Configuration with Ansible

Since we used Ansible to set up the old server the process of setting up an identically configured server was a piece of cake. All we had to do was change the hostname in the host inventory file add the new server and rerun the playbooks.

Volume size

Make sure the new disk volume is identical to the size of the old server’s disk volume as we will copy over data from the old server to the new one.

Data Migration

Using RSYNC, copy over the data from the old server to the new Graviton-based one, using the SSH protocol.

rsync -avz -e ssh /var/www/ root@enew-server.compute-1.amazonaws.com:/var/www/

Note: This data migration does not guarantee that the code will work 100%, you will need to deploy and build the code again to be sure it works as expected. In our case, we needed to upgrade several NodeJS packages.

AWS RDS

With RDS instances no migration is necessary and you can take the easy way of just modifying the instance class of your instances if your database engine version supports it.

Determine if the current database version meets the minimum required version for moving to Graviton2.

Version supporting Graviton:

MySQL: 8.0.17 and higher,
PostgreSQL: 12.3, 13 and higher,
MariaDB: 10.4.13, 10.5 and higher.

If your RDS instance isn’t at a version supported by Graviton2, you need to upgrade to a supported version.

AWS ElastiCache for Redis

Migrating Amazon Elasticache for Redis and Memcached to Graviton2-based instances offers a smooth transition, only a change of instance type is required, with a performance improvement of up to 45%, all at a 20% lower cost compared to similar x86-based instances.

The Beginning of a New Age in Cloud Computing

In conclusion, the rise of AWS Graviton and ARM architecture represents a change in cloud computing that impacts the whole IT industry. These technologies bring together improved performance, cost-effectiveness, and energy efficiency. As more organizations adopt these technologies, we can expect a future where the flexibility of ARM architecture and the efficiency of Graviton processors set the standard for cloud infrastructure.

Therefore, do not miss the chance to make the switch and be part of the new standard.

AWS Budgets and Alerts with Terraform: A Cost-Monitoring Case Study

2024-01-03T13:47:03+01:00

Monitor and Control Amazon Cloud Costs with Terraform

For every Cloud project, you need to set budgets and alerts with Terraform

AWS Budgets with Terraform

Why set up a budget for your cloud account?

If you wonder why most startups fail it is simple, they run out of money and there have been many horror stories about crazy big cloud bills.

At Clearview, when we put a new client on the Cloud, we know they will get a bill eventually. It’s our responsibility to make sure that the bill will not be a big and sudden surprise.

Setting up the budgets

Setting the AWS Cloud budget

The first step is to set budgets and alerts. We usually set:

The Account wide budget,
The Most used service budget,
The Most important tag budget.

Every budget sends out an email notification when the budget cost threshold is reached, in these two cases:

The ACTUAL cost which will be triggered once that amount has already been spent,
The FORECASTED cost notification will be triggered earlier as the cost is based on prediction based on your past usage.

As we are a tech company the budgets are set using Terraform and in the next section, you can find diagrams and code samples that explain how budgets and notifications work.

Monthly Account Budget

Set your Monthly AWS Budget.

This budget tracks account-wide costs.

resource "aws_budgets_budget" "monthly_account_budget" {
  name         = "Monthly Budget for my Account"
  budget_type  = "COST"
  limit_amount = "500"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

The notification block arguments

Each notification block inside aws_budgets_budget controls one alert. The five arguments the AWS provider expects are:

comparison_operator — one of GREATER_THAN, LESS_THAN, or EQUAL_TO. For a spend budget you almost always use GREATER_THAN.
threshold — a number. Compared against the budgeted amount.
threshold_type — PERCENTAGE or ABSOLUTE_VALUE. Percentage is easier to reason about because you don't have to rewrite the block when the budget limit changes.
notification_type — ACTUAL (the current spend) or FORECASTED (AWS's prediction based on past usage). Set one of each per budget so you get both an early warning and a real breach alert.
subscriber_email_addresses — a list of email strings. This is where the alert lands. Every address in the list receives a copy. Note: it is a Terraform list, not a comma-separated string, so use ["a@x", "b@x"] shape not "a@x, b@x".

There are two adjacent arguments that this example does not use but you might reach for:

subscriber_sns_topic_arns — send the notification to an SNS topic instead of (or in addition to) email. Useful when you want the alert to fan out into Slack via an SNS→Lambda hop.
subscriber_type on the older notification shape has been replaced by the three subscriber_* list arguments; you should not need it on modern provider versions (hashicorp/aws >= 4.0).

Full provider docs: aws_budgets_budget#notification.

Budgets by Service

AWS Budgets illustration.

EC2 Monthly Budget

This budget will track costs for EC2 services only.

resource "aws_budgets_budget" "ec2_monthly_budget" {
  name         = "My EC2 Monthly Budget"
  budget_type  = "COST"
  limit_amount = "400"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name = "Service"
    values = [
      "Amazon Elastic Compute Cloud - Compute",
    ]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/ec2_monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

S3 Monthly Budget

AWS S3 Monthly Budget.

This budget will track costs for S3 buckets only.

resource "aws_budgets_budget" "s3_monthly_budget" {
  name         = "My S3 Monthly Budget"
  budget_type  = "COST"
  limit_amount = "100"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name = "Service"
    values = [
      "Amazon Simple Storage Service",
    ]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 110
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/s3_monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

AppRunner Monthly Budget

This budget will track costs for AppRunner services only.

resource "aws_budgets_budget" "apprunner_monthly_budget" {
  name         = "My AppRunner Monthly Budget"
  budget_type  = "COST"
  limit_amount = "100"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name = "Service"
    values = [
      "AWS App Runner",
    ]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 110
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/apprunner_monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

Budgets based on tag filtering

Production Tag Monthly Budget

This budget will group multiple types of service based on the tag, in this case, the production tag is used.

production_tag_monthly_budget.tf on GitHub

Closing

This article explained the importance of setting a cloud budget and then demonstrated how to do it programmatically. Not only that, we went a step further and created nice diagrams for each budget so that it is easier for every reader to imagine the setup.

We hope this article finds its way and helps you avoid unnecessary cloud costs.