DEV Community: Sara Miteva

The Advent of Monitoring, Day 3: Easy Monitoring for Self-Hosted Projects with Checkly

Sara Miteva — Thu, 14 Dec 2023 13:42:33 +0000

This is the third part of our 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

This article was written by Daniel Paulus, Checkly's Director of Engineering.

When it comes to running self-hosted services or side projects, monitoring is key. But, who has the time to set up a complex monitoring system?

We want to deliver cool software and not be busy with configuring Prometheus servers or Grafana Dashboards. That’s where synthetic monitoring fits in perfectly – it's straightforward to set up and reliably keeps an eye on things.

Setting Up Multi-Step API Checks

I love to use Checkly for this because of the great Developer Experience it gives me. It's particularly handy with its latest feature: multi-step API checks (still in beta). Multi step checks allow you to write code and use HTTP requests to implement an arbitrary number of requests, organized in steps, and custom logic to monitor any HTTP based service. This is ideal for more advanced monitoring needs without getting too complicated.

The task at hand was to set up basic monitoring for my self-hosted ClickHouse database. For those who want to jump straight in, all the necessary code is available on GitHub. Just clone it, set up ch_pass (clickhouse password), ch_user (clickhouse user name) and ch_url (’https://IP:port’) account variables in your checkly account and run npx checkly deploy

If you prefer a step-by-step guide, here’s how I did it:

We will use Clickhouse’ HTTP interface to run queries against it to check the database health.

First, create a Checkly project. It's as easy as running npm create checkly and following the instructions. Then, you'll need four files in your checks directory:

clickhouse.check.ts:

import { MultiStepCheck, Frequency } from "checkly/constructs";
import path from "node:path";

//this defines a check. The actual code is in the spec files
new MultiStepCheck("clickhouse-check-1", {
  name: "Clickhouse Version Check",
  runtimeId: "2023.09",
  frequency: Frequency.EVERY_10M,
  locations: ["us-east-1", "eu-west-1"],
  code: {
    entrypoint: path.join(__dirname, "clickhouse.spec.ts"),
  },
});

new MultiStepCheck("clickhouse-check-2", {
  name: "Clickhouse Free Diskspace",
  runtimeId: "2023.09",
  frequency: Frequency.EVERY_12H,
  locations: ["us-east-1", "eu-west-1"],
  code: {
    entrypoint: path.join(__dirname, "clickhouse-disk.spec.ts"),
  },
});

clickhouse.spec.ts contains a very basic set of checks. First it pings the Clickhouse health endpoint to check if the server is running at all. If that succeeds, we run the most basic query, a SELECT version() and make sure the version string is returned as expected. Now we know that Clickhouse is responsive and ready to go.

import { test, expect } from "@playwright/test";
import { baseUrl, queryClickhouse } from "./utils";

const clickHouseVersion = "23.9.1.1854";

async function pingClickhouse(request) {
  const response = await request.get(`${baseUrl}/ping`);
  expect(response.ok()).toBeTruthy();
  const msg = await response.text();
  expect(msg.trim()).toBe("Ok.");
}

test("check clickhouse", async ({ request }) => {
  await test.step("ping clickhouse", async () => {
    await pingClickhouse(request);
  });

  await test.step("check clickhouse version", async () => {
    const response = await queryClickhouse("SELECT version()", request);
    expect(response[0]).toBe(clickHouseVersion);
  });
});

clickhouse-disk.spec.ts is a very simple check to make sure Clickhouse has at least 5GB of free disk space left. If not, the check will fail and we will get an alert from Checkly. Clickhouse offers a lot of interesting metrics through it’s query interface so you can monitor many other things. Take a look: https://clickhouse.com/blog/clickhouse-debugging-issues-with-system-tables

import { test, expect } from "@playwright/test";
import { queryClickhouse } from "./utils";

const diskSpaceQuery = `
SELECT 
    name, 
    free_space / 1024 / 1024 / 1024 AS free_space_gb
FROM system.disks;

`;

test("check clickhouse", async ({ request }) => {
  await test.step("check clickhouse diskspace", async () => {
    const response = await queryClickhouse(diskSpaceQuery, request);
    const row = response[0].split("\t");
    console.log(`Disk ${row[0]} has ${row[1]}GB free`);
    //make sure we got more than 5GB left
    expect(parseFloat(row[1])).toBeGreaterThan(5);
  });
});

utils.js contains a very simple Clickhouse response parser.. I know there is a lot of room for improvement here. But you know, I want to build apps not monitoring ;-) As you can see, you need to set up the environment variables for user name, password and the Clickhouse http url in your Checkly env variables for this to work.

import { expect } from "@playwright/test";
export const baseUrl = process.env.ch_url;

export async function queryClickhouse(query, request) {
  const buff = Buffer.from(query, "utf-8");
  const response = await request.post(`${baseUrl}`, {
    headers: {
      "X-ClickHouse-User": process.env.ch_user,
      "X-ClickHouse-Key": process.env.ch_pass,
    },
    data: buff,
  });

  const buf = await response.body();
  expect(response.ok()).toBeTruthy();
  const res = new String(buf).toString();
  const resArray = res.split("\n");
  resArray.pop();
  return resArray;
}

Once you have your files ready, run npx checkly login to login to your account and then give it a try by running npx checkly test. If that works and you Clickhouse cluster responds, it is time to unite testing with monitoring and deploy your checks to Checkly for continuous active monitoring. Deploy your checks using npx checkly deploy.

And we’re done! This setup will continuously monitor your ClickHouse database, ensuring it’s up and running all the time. How cool is it that you can put the monitoring code next to your application code and deploy changes that easily?

In case your service does encounter an issue, it's important to get notified quickly. Checkly offers various alerting methods, including SMS, phone calls, Slack, and Pagerduty. You can set these up by checking out Checkly's Alert Channels documentation.

With Checkly, setting up monitoring for your self-hosted projects is a breeze, giving you both peace of mind and more time to focus on other aspects of your projects.

This is the third part of our 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

This article was written by Daniel Paulus, Checkly's Director of Engineering.

The Advent of Monitoring, Day 2: Debugging Dashboard Outages with Checkly's API Checks

Sara Miteva — Tue, 12 Dec 2023 17:39:38 +0000

This is the second part of our 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

This post was written by Daniel Paulus, Checkly's Director of Engineering.

We encountered a tricky issue with our public dashboards: they were experiencing sporadic outages, happening about once every two days. The infrequency and unpredictability of these outages made them particularly challenging to diagnose.

Our Hypothesis

Initially, we tried to correlate the outages with our logs, looking at the failure times reported by our browser check failures. Unfortunately, this method didn't yield any useful insights.

This is when we tried to use high-frequency API checks, running every 10 seconds. Our existing setup involved a browser check that ran hourly, which was sufficient under normal circumstances but not detailed enough to catch these intermittent issues.

ChatGPT to the Rescue

The issue with our public dashboards is, of course, already fixed for a long time, so to simulate a similar scenario, I used ChatGPT4 to generate a simple nodeJS server for me using the following prompt:

Write a simple nodejs based rest endpoint that always returns a body "OK" and a 200 status code without using a framework. The endpoint should return right away. There should be a loop that runs every 10s and with a 0.1% chance, will cause the endpoint to return HTTP 500 for a time window of 30-60 seconds. Afterwards it will go back to returning 200.

Now all I had to do was to save the resulting code to a file and then run it with NodeJS. To publicly expose it for testing purposes a simple

ngrok http 3000

was the perfect solution.

Configuring API Checks with Checkly

Next, I configured two API checks with Checkly, one running every 5 minutes and one running every 10 seconds.

The screenshots really illustrate the benefits of temporarily or permanently using higher frequency checks. The 5 min frequency check did not detect all the error windows, and also does not help with understanding how long the service was down. Things might seem much better here compared to when you start probing the API every 10s.

5 minutes:

10 seconds:

The results are quite revealing. The high-frequency API check shows almost exactly when the issue started, when it stopped and how long it took. It identifies all the 30-60s random errors. In real-world scenarios, this makes it much easier to find the correct logs and more importantly, also understand how big the problem actually is.

By leveraging Checkly's API checks for high-resolution failure timing, we were able to identify and subsequently address a problem that our standard monitoring approach had missed. This experience underscored the importance of synthetic monitoring with higher frequency checks, especially for issues that occur sporadically. With Checkly's help, we were able to root cause and fix the dashboard's sporadic outages and could enhance the reliability of our service.

This is the second part of our 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

This post was written by Daniel Paulus, Checkly's Director of Engineering.

The Advent of Monitoring, Day 1: What Are Synthetics and Why They Are Needed

Sara Miteva — Mon, 11 Dec 2023 15:55:31 +0000

This is the first part of Checkly's 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

This post was written by Daniel Paulus, Checkly's Director of Engineering.

Hey there! Here is my take on what synthetic monitoring means and why it’s awesome!

I think it’s a very complicated word for a very straightforward concept. In fact, I am convinced, that once you've used it, you will never want to live without it.

Let’s start first with e2e testing: In essence, what you do is, define a series of steps interacting with your web app or REST API to simulate real user behavior.

For web apps, that means your test clicks buttons and types text while making assertions along the way.

For REST APIs, you check that the actual HTTP requests are fast enough and contain the expected responses. This way, you make sure core user flows are working as expected when you test your code before deploying it to production.

Any refactoring that might break a ton of unit tests will not affect e2e tests unless the core user flow is actually broken. So, they give you the ultimate signal if your system behaves as it should. If you use a modern e2e testing framework like Playwright, your tests will also be quite fast and not flaky, unlike Selenium or other old testing tools.

How does all of this relate to synthetics?

Well, the general idea is to promote those e2e tests you have created, to continuously run against your production services! Now you have the best signal there is to understand if users can actually use your service, all the time, in your production environment. You will know when things break before your users inform you. Consider also the following questions you are finally getting answers to:

The unit tests all worked, but does the feature actually work on production?
Is the auth provider having an outage and people cannot log in, although your own software is correct?
Is any other third-party dependency that is slow or broken?
It works in Germany, but does it work in California? Is there some regional blocking in place?

Take a look at the screenshot below, for example. You can immediately spot which part of the system is affected. Compare that to a list of error logs or multiple metrics dashboards and you will understand what I mean when I say synthetics give you a clear signal compared to all the noise.

Ultimately, synthetic monitoring means monitoring through simulated users, or testing in production, and is like your app's guardian angel. It's always there, quietly keeping watch, ensuring everything runs smoothly for your users.

For those in the software development scene, it's an invaluable ally, keeping your app top-notch and your users happy. With a modern tool like Checkly, leveraging Monitoring as Code, you can repurpose your existing e2e tests to run against production by writing them twice.

This is the first part of Checkly's 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

This post was written by Daniel Paulus, Checkly's Director of Engineering.

Common DevSecOps Challenges and How to Overcome Them

Sara Miteva — Tue, 18 May 2021 09:37:01 +0000

DevOps has changed the way developers and operating engineers think. The DevOps paradigm has transformed the software and technology development process. As a result, improving performance and delivering faster outcomes have become the standard of meeting the market's demands.

However, as the infrastructure evolves, security has become a new concern. Developers are now working to address it on a regular basis. Security professionals have had to look at options that can implement security mechanisms through the DevOps process, tackling the entire implementation cycle. This aims to prevent and mitigate security threats as they emerge across the software development process.

DevOps implementation, if performed correctly, can yield positive benefits for any company. This includes improved team coordination, quicker time to market, increased total efficiency, increased customer loyalty, and many others. But, without security in mind, you can lose each one of them in the blink of an eye.

That’s why, to be safer, we’ll add a “Sec” in DevOps. This article will focus on the DevSecOps methodology, and the DevSecOps challenges you might encounter when implementing it into your processes.

What is DevSecOps?

DevSecOps stands for development, security, and operations. It automates security deployment during the product development lifecycle, from original design to configuration, testing, implementation, and software delivery.

Any phase of the DevOps process should include security. The creation, plan, construct, test, launch, maintenance, and beyond. DevSecOps refers to the type of security you implement into the DevOps process. This concept improves stability by enhancing coordination and mutual responsibility across the entire DevOps workflow.

DevSecOps is a gradual and inevitable progression of the way development teams think about protection. A special security team used to handle the security of applications at the end of the implementation stage. Then, a separate quality assurance (QA) team reviewed it.

With DevSecOps, you integrate security in the agile and DevOps processes. It responds to security problems when they arise, as they are simpler, quicker, and less costly to resolve. Furthermore, rather than being the exclusive concern of a security team, DevSecOps makes application and infrastructure security a joint responsibility of production, security, and operations teams.

DevSecOps Challenges

Implementing DevSecOps comes with a number of challenges. Here are some of them:

The cultural shift

The most significant roadblock that most organizations face in adopting a DevSecOps strategy is the resistance they may encounter. Many people would be unable to make a significant adjustment to what they've been doing for years. And the impression that security was an optional extra of previous app development methods doesn't make things easier.

Another common stumbling block is the perception that improved protection slows things down and prevents creativity. Developers want to produce code quickly in order to satisfy the needs of modern companies. Security departments, on the other hand, are mostly concerned with ensuring that the code is safe. Since their goals are too dissimilar, it's difficult for these two teams to function together.

That’s why thorough preparations for both development and security professionals will remove some of the cultural challenges and get the teams on board with the new processes. Getting everyone on board and developing new practices that will work for all team members are two crucial things to do before making the shift.

Lack of knowledge

In addition to cultural preparations, professional development and education are also important. Research by Security Compass shows that the lack of education/awareness about security and compliance is one of the most common DevSecOps challenges when it comes to implementation, with 38% of the respondents highlighting it.

Start with formal in-house training that will raise awareness about security within your team. The most experienced security professionals should mentor other team members and help them level up their security game. Finally, provide your developers with online courses. They can watch them whenever they feel comfortable with the goal to learn how to address particular security issues.

Complex tool integrations

The majority of DevOps toolchains come from various vendors. Source code management, CI/CD, build tools, binary libraries, code review, and problem monitoring tools are chosen by teams based on their specific requirements.

Adding security tools makes things even more complex. Static application security testing (SAST), software composition analysis (SCA), and some kind of dynamic testing techniques are typically used in security analysis. Developers need a complete picture of the problems. However, it can be difficult to combine and reconcile results from different vendors' resources.

Finding one tool that can address your security concerns is probably the best option. It will make things easier for developers, on an individual level, and for the entire organization.

Traditional security tools vs. agile DevOps

Many software security tools were built with the idea that an employee of the security team would run the checks, analyze the sometimes lengthy list of results, and then send the list back to the development team for improvements.

This time-consuming, labor-intensive approach is incompatible with DevOps' high-speed, integrated, and automatic model. It also shows that incorporating protection into DevOps isn't enough. You need to use solutions that were built upon DevOps practices. These solutions are usually flexible and can easily be integrated into any existing agile process.

That ensures that to be fully DevOps compliant, tests should run in the background without human interference. Moreover, they can implement security policies automatically so that developers can concentrate on the most critical issues.

To enhance the security efforts of development teams, we’ve recently announced a new feature - the integrated Container Security Scan Reports in Microtica Pipelines. The system will perform an automated security scan on the container images and deliver the findings directly to the Portal’s UI. This feature is just the beginning of a series of security enhancements that are coming in Microtica.

Conclusion

DevSecOps is a methodology for approaching IT security with the mentality that security is the concern of everyone. It entails incorporating security practices into a company's DevOps system. The aim is to integrate protection into the software development process at any level. DevSecOps means you're not saving security until the end of the production period. This practice is in contrast to previous development models.

If your company already uses DevOps, you should think about switching to DevSecOps. DevSecOps is based on the DevOps philosophy at its heart, which will help you shift easily. And by doing so, you'll be able to pull together skilled individuals from various strategic backgrounds to improve the current security processes.

There's no denying that DevSecOps is changing the way businesses approach security. Many companies, though, are also wary about moving to DevSecOps for a number of factors, including a lack of knowledge of what DevSecOps is, an unwelcome cultural change for staff, budget restrictions, and often just the uncertainty of the concept.

The technological and business advantages that companies will gain from adopting DevSecOps are extremely promising. While there will undoubtedly be some setbacks when you first begin, DevSecOps can be extremely beneficial to your company in the long run. Partnering up with a company that’s already skilled in DevSecOps can help you make the most out of it.

A Step-by-Step Guide to AWS Instance Scheduler

Sara Miteva — Tue, 27 Apr 2021 19:40:51 +0000

AWS Instance Scheduler is a popular option for saving up a large portion of the cost of computing services in situations where there are predictable planned times for operating compute services. In other words, since no clients are accessing particular environments during the period, it's normal for development environments or workloads to be shut down during non-working times.

By evaluating when the instances are more widely used, you can implement more complex schedules, or even apply an always-stopped schedule and then start up the instances when you need them.

In this article, we will cover a step-by-step guide to creating an AWS schedule and apply it to several instances. At the very end, there is a section on how to do this in less than 5 mins, without having to set up and manage the infrastructure for the scheduler.

Solution Overview

AWS Instance Scheduler Architecture

This CloudFormation template creates an environment for the AWS Instance Scheduler. The solution uses the following AWS services:

A CloudWatch event triggers the Lambda function whose job is to check the EC2 and RDS instances, find the appropriate tag for a schedule, and match it against the definition of that schedule saved in DynamoDB. After that, depending on the targeted state the Lambda function decides to turn off or turn on the EC2 or RDS instance.

The default behavior of this solution is to stop EC2 and RDS instances, not terminate or delete them, as terminated instances cannot be restarted. It is also a good idea to create an RDS Instance Snapshot before stopping the instances. Each new snapshot overrides the last one. This is part of setting up the stack and is explained in the next section.

How it works

Schedules actually define when the EC2 and RDS instances should be running. Each schedule has a unique name and its configuration is stored in the DynamoDB.

The entire setup revolves around tagging, which is basically a label you give to an instance to be able to categorize it and later quickly identify it. Tags are defined with a key-value pair which you define.

The AWS Instance Scheduler solution has a default tag key called Schedule. You can of course change it if you need. The tag value should be the unique name of the schedule you want to apply to the instance. Each time the Lambda function runs, it will retrieve the configuration for the schedule from the DynamoDB and apply it to the instance.

For example you could define a tag with key: value = Schedule: work-days. The name work-days specifies a schedule where the instances should shut down on Friday evening and get started up on Monday morning. Therefore, the instances that are supposed to be covered by this schedule should be tagged with the key: value pair. In the example this is Schedule: work-days.

Create an Instance Scheduler in your AWS Account

Launch the stack

Firstly make sure you’re signed in in your AWS account. The starting step is to launch the instance schedule stack in your AWS account. You can launch the cloud formation template by clicking on this link. The template launches in the US East - N. Virginia region by default, so adjust the region according to your needs. Likewise, verify that the correct template is being used, and move to the next step.

Creating the Instance Scheduler stack - Step 1

Secondly, you need to define the Stack name and some specific parameters, like tag name (if you’d like to change the default tag name Schedule), which service you want to schedule: EC2, RDS or Both, whether you want and RDS instance snapshot before shutting down the resource, the frequency of running for the AWS Lambda function, whether you want CloudWatch metrics and logs and a couple more parameters.

Creating the Instance Scheduler stack - Step 2

Thirdly, leave the stack options as they are - empty. Continue to the last step, review the changes and deploy the stack by clicking on Create. In the AWS Console you can follow the status of the stack deployment. CREATE_COMPLETE means that the solution is deployed.

Define the Schedule

Deployed Instance Scheduler stack

In your AWS console you will find an Amazon DynamoDB table (ConfigTable) where the configurations for the periods and schedules are going to be stored. The schedule is defined by several parameters, from which the most important is the period. This is the time in which the instances should be active. It can be as specific as hours, days and months. For the schedule to work you must specify at least one of the period’s definitions: begintime, endtime, weekdays, months or monthdays.

The begintime field defines when the instance schedule should start the instances, and accordingly the endtime is when the instances should be stopped. If you define only a starting time then the instance will have to be stopped manually.

In the ConfigTable are already some predefined samples that you can use or create your own. A sample period will look like this:

Office hours sample period

This is a period set to define office hours with a begintime of 9 am and an endtime of 5 pm, applied only Monday to Friday. This period is used in a schedule to define UK office hours. You can change the periods according to your needs directly from the AWS console.

Schedules don’t have to be used only for shutting down resources. There are also some more complicated schedules you can create, for example if you look at the Vertical scaling on weekdays schedule. Here you’ll see it’s purpose is to run on smaller EC2 instances on weekends and use micro instances on working days.

Vertical scaling on weekdays schedule

Tag the appropriate instances

In order for a schedule to work, you need to tag the EC2/RDS instances you want the schedule to be applied on. You should use the tag key (the tag name you defined when creating the CFN stack - default value is Schedule) and the tag value - which is the name of the schedule stored in the Config table. When you find your resource you go to Manage Tags and enter the key-value pair defining the schedule. You can also use the Tag Editor to tag multiple instances at once.

Managing tags for an EC2 instance

CloudWatch Metrics

In conclusion, after the tag is applied the instance will be part of the resources managed by the schedule you defined for it. You can check the CloudWatch metrics to make sure the solution runs as it's designed to. In the CloudWatch console there will be a namespace <stackname>:InstanceScheduler (DevInstanceScheduler:InstanceScheduler in our case). The Lambda function updates the metrics each time it runs for each instance it’s supposed to apply a schedule on. Moreover, here you get a sense of the number of instances that are running and the ones that are stopped.

Create a Saving Schedule in Microtica

If you don’t feel like going through the hustle of launching and deploying a solution in your AWS console, you can use Microtica’s Cloud Waste Manager feature. All you have to do is:

Sign up for free
Connect your AWS Account
Set permissions only for turn on/off of instances
Go to Saving Schedules → Select an active time period for your instances
Select the instances you want to apply the schedule to
Activate

Create a saving schedule in Microtica

Recommendations to improve your AWS cost optimization strategy

Sara Miteva — Thu, 15 Apr 2021 10:55:06 +0000

You need to take care of the economic model of the architecture while designing applications and workloads on AWS. Compared to on-premises data centers, it is necessary to look beyond the fundamental pricing benefits and explore ways to leverage the infrastructure successfully to lower your AWS charge.

Regardless of whether you’re going to hire a FinOps professional or handle the process within the existing team, here are the best practices for AWS cost optimization.

Apply for AWS credits

AWS credits are one of the most common ways to save on your AWS bill. They represent something similar to a coupon code, which can help you cover costs with AWS services. You can use them until you spend them all or until they expire. There are various ways to get AWS credits, and here are some of them:

AWS Activate – for startups to set up infrastructure as quickly as possible
AWS Activate Founders – for startups that haven’t raised any venture capital, seed, or angel funding
Publish Alexa skills – for each Alexa skill you publish, you can apply for $100 AWS promotional credits
Attend AWS events and webinars – here you can find many opportunities for AWS credits
AWS Educate – educators earn $200 in AWS credits, while students can create a starter account with up to $100 in credits at a member institution
AWS for Nonprofits Credit Program – this program provides access to $2,000 for nonprofit organizations
AWS EdStart – for education technology startups
AWS Free Tier – a program that includes 85 products for businesses to start building on AWS, explained in details in the next section
Product Hunt – Product Hunt’s Ship platform allows startups to claim up to $7,500 in AWS credits.
Use Secret deals
F6S deals
Brex – if you use Brex cards, there are many benefits, including up to $5,000 in AWS credits
Startup School – if you’re a startup, Startup School can bring you a deal with free AWS credits

Utilize AWS Free Tier

Cloud platforms provide a number of services for free in the beginning, but even free services have an upper limit. The services become billable as soon as consumers hit the cap. These services are used on a daily basis by people new to cloud computing and before they fully transition to the cloud environment. Many free cloud plans come with an expiry date and the payment period begins as soon as it ends.

For example, Azure offers a free tier plan for a month, giving the possibility to run two small virtual machines with a storage capacity of 800GB. Google Cloud, on the other hand, offers $300 credit for a period of 12 months, when users can use services like Google App Engine or Google Compute Engine. AWS’s free tier plan lasts for 12 months, giving services like EC2, S3, and AWS RDS.

The Free Tier extends to a limited number of AWS offerings and is subjected to a monthly consumption cap. The AWS Free Usage Tier is divided into three pricing models: a 12-month Free Tier, an Always Free offer, and brief trials.

Some of the services available include 750 hours of Amazon EC2 Linux, 750 hours of an Elastic Load Balancer, 750 hours of Amazon RDS Single-AZ Micro DB Instances, 5 GB of Amazon S3 standard storage, 10 Amazon Cloudwatch metrics with 1,000,000 API requests, and others. You can see all the services and limitations here.

For example, the AWS Free Tier model was used at a college to teach students about web frameworks. However, you can use it for much more. This model can allow you to build and maintain a basic web application. This example by AWS can guide you through making an app with AWS Amplify, Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. Moreover, you can connect it to a serverless backend and add interactivity with an API and database.

Choose the right AWS region

When you set up your AWS modules, picking an AWS region is the first choice you have to make. Without picking a region, you can’t start working on the AWS Management Console, SDK or CLI. People usually choose the region according to distance, which is the most obvious choice. However, there are many other factors to consider. Here are some of them:

Costs – different regions have different AWS rates, check the cost calculator to count your costs for a particular region
Latency – choose a region with a smaller latency to make the app more accessible to your target customers
Security – check the regulations of each region before deciding to choose it
Service availability – not all services are available to all regions, so make sure you know which ones you need before choosing a region
AZ availability – also, not all regions have the same number of availability zones The best solution would be to choose the factor that is the most important for you and use it as a guide to choose your particular AWS region.

Use AWS Savings Plans

The AWS Savings Plan was introduced in November 2019, as a flexible pricing plan that allows consumers to save up to 72% on Amazon EC2 and AWS Fargate in return for a 1 or 3-year contract commitment to a consistent amount of compute use (e.g. $10/hour).

You can start using this feature directly from the AWS Cost Explorer control console or using the AWS API/CLI. Here’s how you can pay:

On a monthly basis, with no upfront payment
On a monthly basis, with paying at least half of the commitment price upfront
Upfront, paying the entire commitment with one payment and achieving the highest savings For example, if you commit to a usage of $10/hour, you get discount prices on all your usage up to $10 and any usage beyond this commitment will be charged at regular on-demand rates. There are two types of Savings Plans:

Analyze AWS’s guides to the Savings Plan and try to choose the best setup for your specific case.

Analyze your AWS bill

Tools like Cost Explorer, Cost & Usage Report, Trusted Advisor, or Cost Optimization Monitor to analyze your AWS bill and see how you are spending your budget. Research all categories of your bill and understand what they mean. Contact AWS Support if you find anything you can’t understand, and they’ll help you find the answer. It will be easier to separate some kinds of expenses from others by using various AWS accounts for AWS entities and centralized billing.

Single billing for all accounts

Getting a single bill is very convenient for tracking expenses and monitoring spending if you have several accounts. This helps you get an overview of all AWS costs accrued across all your accounts with a consolidated view.

There’s no extra charge for this service. In the unified billing family, the Master Account pays the costs that all the other accounts accumulate. You can easily trace the costs from each account, and the expense data can also be accessed in a CSV file.

Create billing alarms

To warn you when your AWS bill exceeds critical stages, generate billing alarms. Be sure you have many warning thresholds: when the bill rises a little bit, when the bill rises a lot, and when the budget is way over the limit.

Use reserved instances optimization

This option checks the usage history of Amazon EC2 computing and estimates an ideal size of partial cumulative reserved instances. Guidelines focus on hour-by-hour use of the preceding calendar month gathered across all combined billing accounts. It is an integral feature of cost optimization that helps you to estimate the number of hours of use you need this month depending on the sum of previous months.

With this option, you commit to purchasing a reservation for one or three years. There are three payment alternatives: full upfront, partial upfront, and no upfront. The last two allow you to pay the remaining balance monthly during the period.

Pay-as-you-go

Pay-as-you-go is a straightforward idea that does not include minimum obligations or long-term contracts. You substitute low operating costs for the upfront capital spending and just compensate for what you need. There is no need to pay for unused space in advance or get fined for wrong estimations. This is one of the key cost optimizations of the service side inherent in AWS’s pricing strategy.

Turn off unused instances by creating schedules

In order to optimize costs, it is crucial to shut down unused instances, particularly at the end of the working day or on weekends and vacations. For non-production instances such as those used for development, staging, monitoring, and QA, it is worth preparing on/off-hours. For example, implementing an “on” mode from 8.00 a.m. to 8.00 p.m. from Monday until Friday until Monday, large expense volumes can be avoided, particularly if production teams work during flexible hours.

Through evaluating usage metrics to decide when the instances are more widely used, you can implement more intense schedules or apply an always-stopped schedule that you can disrupt when you need access to the instances. It is important to figure out that you are already paying for EBS quantities and other elements connected to them while instances are set to be off.

Microtica's Cloud Waste Manager

Reducing cloud waste and reducing cloud costs is very easy with our tool Microtica. You create saving schedules so that resources or environments will turn off in the defined period. This is available for EC2, RDS instances, and auto-scaling groups.

Create schedules for environment resources

When this plan is enabled, all of these services will be labeled to be shut-down at the specified Stop time and “wake-up” at the defined Start time on the chosen days. There is a list of all your schedules with details about the effect of this schedule on the AWS account and the projected saving figures.

Read the whole guide on how to reduce costs in non-production environments.

Monitor and track your spendings

There are many tools that could help you monitor and analyze your instance metrics. You can measure the workloads according to the gathered data and scale up or down the instance size. AWS Cost Explorer resource optimizer and AWS Compute Optimizer are some of these tools.

Compute Optimizer looks at multiple parameters to be able to define some cost optimizations, like CPU, network I/O, disk, and memory. The Cost Explorer EC2 optimizer comes in handy as it considers whether you have reserved instances or not. This means that you will not have any savings as you have committed to pay an amount upfront for the instances. The Computer optimizer fails to do this connection, so it might give you a recommendation regardless of whether you have reserved or not.

Microtica’s cost explorer can show you the following data:

AWS’s estimated cost for the current month
how the month-to-date spending acts
a breakdown of last year’s cloud spending with a forecast for the coming year
the AWS account that costs you the most
the services which receive the most expenditure
costs by tag of allocation

You can also get an overview of the accumulated estimated savings for the month. The data is based on the current active saving schedules and daily utilization hours.

Check out how we helped one tech company achieve 68% in AWS cost savings.

Choose the right storage class

Amazon S3 provides six storage classes, each built for specific use cases and available at differing rates.

S3 Standard: for frequently accessed data with low latency and high throughput performance.
S3 Standard-Infrequent Access: for infrequently accessed data that needs rapid access at times.
S3 One Zone-Infrequent Access: the difference between this class and S3 Standard-IA is that it stores data in a single AZ at a 20% lower cost, instead of a minimum of three AZs.
S3 Intelligent-Tiering: transfers data to the most cost-effective access rate immediately without overhead control.
S3 Glacier: long-term data archiving.
S3 Glacier Deep Archive: long-term data archiving with access once or twice a year. The choice depends on your data needs and requirements, as well as your budget. Consider introducing object lifecycle management that moves data between the storage classes dynamically to optimize the cost of your data storage.

Intelligent tiering

S3 Intelligent Tiering was created for teams that want to automatically adjust costs when data access patterns change, eliminating the risk of performance bottlenecks and overspending. The model automatically delivers cost savings by storing objects in two access tiers: frequent access and infrequent access.

S3 Intelligent-Tiering tracks access habits and transfers objects that have not been accessed for 30 days to the infrequent access tier for a small monthly tracking and automation charge per object. In S3 Intelligent-Tiering, there are no retrieval costs. When an object from the infrequent access tier is accessed again, it is immediately transferred to the frequent access tier. As items are transferred between access levels within the S3 Intelligent-Tiering storage class, there are no additional tiering costs.

Specify expiration dates

AWS S3 allows you to define expiration dates for S3 objects, as well as rules to move objects to cheaper storage tiers. When the object reaches the expiration date, it has reached the end of its lifetime, so it’s removed asynchronously. This is known as the lifecycle expiration rule. As S3 doesn’t charge for the storage time of objects that have expired, this is a great way to eliminate some spendings that you don’t need.

There are some rules though:

For S3 Intelligent-Tiering, S3 Standard-IA, or S3 One Zone-IA storage the minimum expiration limit is 30 days, so if you define an expiration of less than 30 days you are still charged for 30 days.
For S3 Glacier storage the minimum is 90 days, so if you define it for less than 90 days to expire, you are still charged for 90 days.
For S3 Glacier Deep Archive storage if you define expiration for less than 180 days, you are charged for 180 days.

Choose the right instance type

Because multiple types of instances can cost varying amounts, it is essential to make sure that your team is using the most cost-effective ones. You have to try to pick the instance that fits the workload of the program best.

When deciding variables such as the type of processing unit and the storage space required, remember your particular use case to optimize your workloads while reducing your spending. Configure the instance resource that produces price efficiency for the value being delivered. Review your choice of instances every few months to confirm they reflect the reality of your workload.

To be able to pick the right size for a resource there is a combination of AWS tools you can use. AWS Cost Explorer resource optimizer and AWS Compute Optimizer are services that can help implement a right-sizing plan.

The tools will observe your workload performance and capacity, like CPU and memory utilization and suggest instance types and sizes according to those parameters.

Consider that development resources don’t need to be the same size as production instances. So here you could save significantly, by downsizing the non-production environments, but not having impact on the performance you need to get the job done.

Categorizing your instance with tags can be a good solution too. It is possible to track the cost per hour of operating systems in real-time, measure them using tags, and these outcomes will motivate the production team to reduce costs.

A partnership between finance and technology teams

This requires a cultural shift that will make finance and tech teams collaborate better. Cross-functional teams should work together to promote smoother implementation while gaining greater financial and corporate leverage at the same time.

This partnership should remove barriers between the two teams, providing a better overview of finances for the tech team. On the other hand, the financial department should get a clear image of how the tech team allocates its resources.

Engineering teams can more easily create better features, applications, and migrations. It also provides for a cross-functional debate of whether to invest and when. Often a company may expect to cut back on expenditures, while sometimes it chooses to invest more. Yet, teams have to know why the decisions are made.

To establish a closer relationship between the finance and technology departments, some companies adopt FinOps. FinOps manages cloud finances, with the goal to add more financial transparency to the variable expenditure model used by the company. This provides more balance between speed, costs, and software quality for teams.

FinOps enables all operating teams to access real-time data that they need to influence their spending and make wise decisions that ultimately lead to efficient optimization of cloud costs without impacting the final product’s performance, speed, and efficiency.

Use AWS License Manager

Companies seeking for an appropriate and constructive license management plan to remain consistent with license conditions, prevent costly over-provisioning, and make licensing true-ups and audits simpler by using existing software licenses. The AWS License Manager allows users to easily manage licenses in AWS and on-premise servers from various software providers.

AWS License Manager gives administrators a consolidated view of license use so they can figure out how many permits they need and avoid buying more than they use. You will also monitor overpayments and escape license audit fines with this increased visibility. AWS License Manager is simple to use and saves time and money when it comes to monitoring and handling licenses.

How much impact do these recommendations have on your AWS cost optimization strategy?

After elaborating on the recommendations, we want to see how much impact some of them could have. Moreover, we also estimated their complexity. This way, you can decide which recommendations to choose based on how much time you’ll have to spend incorporating them and the effect you’ll have from them.

Simple and fast with low impact can be S3 intelligent tiering. This takes around 10-15 mins to turn on. This monitors your object data access and automatically figures out whether the storage should be in regular S3 (which costs more) or in infrequent access (which costs less).

Another simple but more impactful recommendation to do can be Savings Plan.

Unfortunately, companies aren’t utilizing savings opportunities enough. For example, the Flexera 2021 State of the Cloud Report discovers that 52% of users use AWS Reserved Instances, while only 37% use AWS Spot Instances. However, they are quickly adopting AWS Savings Plan (30% in 2020). Organizations have to move quicker and more efficiently to achieve more savings and reduce their cloud waste.

Conclusion

Every year, cloud usage is on the rise because of the advantages of cloud computing. In addition, for enterprises, the impacts on cooperation, security, development, and revenue are evident. However, additional actions companies take can significantly boost cost-savings.

Start by creating an AWS cost optimization strategy. To do this effectively, you first need to identify your existing costs. Highlight those that are necessary and try cutting the rest. Then, define your cost optimization goals. Conduct extensive research and study on the company and the objectives you wish to accomplish. Set targets for yourself on a weekly, quarterly, or annual basis, or on a specific date that works for you.

After you’ve defined your goals, it’s time to take some action. Choose the activities you’re going to take and prioritize them. Here is the list of the AWS cost optimization suggestions we mentioned in this article:

Apply for AWS credits
Utilize AWS Free Tier
Choose the right AWS region
Use AWS Savings Plans
Analyze your AWS bill
Single billing for all accounts
Create billing alarms
Use reserved instances optimization
Pay-as-you-go
Turn off unused instances by creating schedules
Monitor and track your spendings
Choose the right storage class
Intelligent tiering
Specify expiration dates
Choose the right instance type
A partnership between finance and technology
Use AWS License Manager

Finally, monitor and measure your achievements. To be able to track your results with your specified metrics, implement tools and dashboards. Create a system for evaluating and improving your plan by comparing the outcomes to your established objectives.

And, don’t forget to iterate. Not everything that works for others will work for you. Modify and adjust your actions until you get the perfect formula of what saves you from paying enormous cloud bills.

You will realize long-term financial gains by taking measures to handle your cloud savings efficiently. This will help your business improve growth, repurpose more money for market research and development, and finally, for creating more user-oriented products and services.

We hope these tips will help you create a smart and efficient AWS cost optimization strategy. Happy saving!

AWS Costs - Explained

Sara Miteva — Mon, 05 Apr 2021 13:00:20 +0000

A successful approach to AWS cost optimization starts by gaining a thorough view of the existing costs, finding potential for cost optimization, and incorporating modifications. AWS and other providers of software have resources to help clients understand how they are spending.

In this article, I'll provide a comprehensive guide on how to understand your AWS costs and needs.

What are your data storage requirements?

The first step is to consider the performance profile for each of your workloads in order to maximize storage. To calculate input/output operations per second (IOPS), throughput, and other metrics you need for this analysis, you can conduct a performance evaluation.

AWS storage services are configured for various situations related to storage. There’s no one data storage solution that is suitable for all workloads. Evaluate data storage solutions for each workload independently when determining the storage requirements.

To do this efficiently, you should identify some key information.

How often do you access your data? AWS has different pricing plans depending on how frequently you need to access data.
Do you need high IOPS or throughput for your data store? AWS offers data types that are efficient and performance-tailored. It can help you decide the correct amount of storage and prevent overpayment by recognizing IOPS and throughput specifications.
How important is your data? It is important to maintain vital or controlled data at almost any cost and needs to be retained for a long period.
How delicate is your data? Highly confidential data needs to be shielded against unintentional and malicious modifications. Equally critical to remember are longevity, expense, and protection.
How much data do you have? This is basic information to determine the storage you need.
How temporary is your data? You only need transient data briefly, requiring no durability.
What is your data storing budget? This is also a critical factor when deciding which provider to choose.

S3 storage classes

S3 storage classes affect the availability, lifetime, and spending on objects stored in S3. Every S3 bucket can store objects with different classes, which can be modified and changed during their lifetime. Picking out the right storage class is crucial to achieving cost-effectiveness. The wrong storage class can lead to many unnecessary costs.

Amazon S3 provides six storage classes, each built for specific use cases and available at differing rates. Each of them has a different cost per gigabyte.

S3 Standard: costs are based on object size. Store here the objects that you will be accessing frequently.
S3 Standard-Infrequent Access: costs are based on object size and retrieval.
S3 One Zone-Infrequent Access: the difference between this class and S3 Standard-IA is that it stores data in a single AZ at a 20% lower cost, instead of a minimum of three AZs. However, this reduces availability.
S3 Intelligent-Tiering: transfers objects between classes based on the frequency of use, charging per transfer. Used objects go to Standard, while infrequently used objects go to Standard-IA.
S3 Glacier: long-term data archiving, additional storage at a lower cost.
S3 Glacier Deep Archive: long-term data archiving with access once or twice a year.

EBS Storage

Elastic Block Store (EBS) represents storage for EC2 virtual machines. It can go up to 16 TiB per disk, offering SSD or HDD support. This is provisioned storage you pay per gigabyte, on a monthly basis. This means that you should try to estimate the amount of storage you need at a given time and only purchase that volume. You can increase the size of your EBS storage later.

When purchasing EBS storage, the first thing you should decide is whether to use SSD or HDD volumes. SSD volumes are great for regular read and write operations, while HDD is better with wide streaming workloads that require efficient throughput.

There are several types of EBS storage volumes. You can see a list of them here.

When choosing the correct volume, the first thing that will probably come to your mind is to dismiss HDD storage, but don’t precipitate with your decision. If you decide on one of the SSD options, regularly monitoring your EBS storage can show you whether HDD would be a better choice, highlighting that you might not need that efficient performance after all. Also, don’t forget to turn off EBS storage volumes you no longer use. This can save you many unnecessary costs.

Here, we need to mention EBS snapshots as well. EBS snapshots represent a piece of the used space in the EBS storage, not the provisioned storage. They are also charged per gigabyte per month, at a price of $0.05 per GB-month of data stored. When you want to restore a snapshot, you can use EBS Fast Snapshot restore, but at a higher price.

You can start with the Free Tier that offers 30GB of EBS Storage, 2 million I/Os, and 1GB of snapshot storage.

EC2 pricing

EC2 instances are charged per hour or per second while they are running. This means that when we don’t need them, we should shut them down. Here, you’ll also have to pay for the provisioned EBS storage, regardless of whether your EC2 instances are running or not. Finally, you’ll also pay for data transfer out, a price that varies depending on the region. There are also other points of pricing you can find in the EC2 documentation.

There are several types of EC2 payment options:

There are about 400 EC2 instances you can choose from. It’s important to choose the right instance family and size in order to be cost-effective. For right-sizing, you can use Amazon CloudWatch, AWS Cost Explorer, and AWS Trusted Advisor.

Cost savings in serverless

Serverless computing can save you a lot of time and money. Here are some of the benefits:

No need for server management
Scale automatically without downtime
Pay for what you use
Migrate a large amount of everyday work to AWS
Save time you can use to focus on your actual product
Become more agile and flexible To become serverless on the AWS platform, you can use AWS Lambda for computing, DynamoDB or Aurora for data, S3 for storage, and the API Gateway as a proxy.

Database pricing (RDS & DynamoDB)

When it comes to RDS pricing, the first thing to think about is the instance you choose. The only serverless option is Amazon Aurora. Next, database storage is also an important factor. Obviously, the bigger the database, the bigger the cost. The remaining two factors are backup storage and data transfer between availability zones and storage.

You can choose one of the following Amazon RDS instances:

General purpose (T3, T2, M6g, M5, M5d, M4)
Memory optimized (R6g, R5, R5b, R5d, R4, X1e, X1, Z1d)

You can try Amazon RDS for free and pay for what you use. The payment options are on-demand or Reserved Instances. To estimate your spendings, try the Pricing Calculator.

As for DynamoDB, you can also pay on-demand or for provisioned capacity. You can see the difference between read and write capacity units depending on the pricing type here.

To affect the costs you’ll have for DynamoDB, use auto-scaling. Auto-scaling uses traffic patterns to dynamically adjust the number of read and write capacity units, which in fact helps with the difficulty to predict DynamoDB workloads. By defining a scaling policy for read/write capacity you only enter the minimum and maximum values for provisioning. With alarms, you can trigger the autoscaling policy to perform certain steps in order to scale up or down.

To save more, you can purchase reserved capacity units for a period of one or three years. This commitment will allow you to get capacity units at a reduced price.

Key takeaways

To choose the right AWS pricing plans, you need to understand your data storage requirements first. The importance, delicacy, and amount of data, as well as other characteristics, will impact the final AWS spendings you’re going to have.

Then, you need to choose from the six storage classes AWS has to offer, as well as EBS storage volumes. There are also several EC2 pricing plans and choosing serverless computing as an option. Finally, we’ve explained Amazon RDS and DynamoDB pricing. What you choose depends on your application and your data storage requirements.

Defining an AWS Cost Optimization Strategy

Sara Miteva — Fri, 02 Apr 2021 08:20:48 +0000

How well does your company handle cloud costs? While you could have spending statistics at your disposal that will reassure you that the production team is under its monthly budget or that your monthly recurring income is on an upward trajectory, this data does not actually mean that you are handling investments in the cloud as well as you should be.

RightScale and Flexera teamed up to research the cloud spending habits of companies. What they found was that 35% or even higher of cloud spend is wasted. In times when nothing is certain and when a pandemic has taken over the world, companies are very careful with their spending. Saving the resources you normally waste on cloud spend could open new possibilities for product improvement and growth.

To hit you with some more numbers, 61% of companies are prioritizing cloud cost optimization this year, which makes it a number one initiative once again. Another top-three initiative is getting better financial reporting on cloud costs.

There are many challenges with AWS that teams are facing. It is not uncommon to see reports stating that companies are overspending on the cloud. They are losing tons of money on unused assets and consuming more capacity assets than they need. Rightsizing, arranging, and obtaining Reserved Instances for predictable workloads are some of the practices that AWS users often leverage to reduce their cloud costs.

However, these options might not be the only solutions. Every year there are new initiatives, tools, and best practices for AWS cost optimization that, when used right, could save you a lot more. There are many reasons why you need an AWS cost optimization strategy. In this article, we want to give a short introduction to what an AWS cost optimization strategy looks like.

Identify your costs

Costs and expenses are two different things. Expenses are what is required for a business to continue to operate and costs are associated with the delivery of final products. Costs can be fixed or variable, depending on the production of the company.

Dividing costs into fixed or variable can help identify where you can spend less. Analyze your requirements: What kind of storage you need? How much? What will your day-to-day operations look like?

Much like production lines try to identify which products are decreasing their production and not selling, you can identify projects that are not performing like you’ve anticipated and don’t need the scaling requirements set in the beginning. Decrease those production instances and storages and auto-scale when needed.

The most important thing here shouldn’t be the costs you cut, but where you can focus the resources to increase growth. This is called strategic cost reduction.

Define your goals

Always get into something with the end goal in mind. To successfully adopt a cost reduction strategy, making a plan is first and foremost.

Do a lot of research and analysis on your business and the goals you want to achieve. Specify monthly, quarterly, yearly goals or a definite date that makes sense for your situation.

You can set up cost avoidance goals by teams. If there are teams that use a lot of computing and storage power, by looking at recommendations for rightsizing you can create targets for the team to optimize the workloads and follow the process. This is more effective than simple waste reduction, as it helps teams make intelligent decisions about the cloud needs.

Like any other initiative in the company, there needs to be direction and leadership. Cost optimization should be considered as a strategic move for the whole business.

But the most important goal here could be to create a cost-effective environment. Development teams should be enabled to understand cloud finance and economics. A good start is to obtain a cloud certification from AWS to be able to have discussions and implement cost management in the company.

Practice makes perfect

With the specified goals in mind, an execution plan is the logical next step. But with millions of compelling initiatives you can do, how do you prioritize cost optimization recommendations and decide on the best ones for you?

The most simple way to make a decision can be to look at two parameters: the benefit and the investment.

The benefit looks at the estimated potential savings you can get by implementing the recommendation.

The investment looks at the estimated level of work that is required to implement the recommendation. This can be seen from a time and resource perspective, customer impact, technical risk to the system.

Here is an example of how you can look at the parameters:

Once you assign a score value to each idea you’ll be able to get a prioritization board which will ultimately be the foundation of your implementation plan. It could look like this:

Measure and improve your strategy

In order to be able to measure the success of your strategy, you need to define some metrics to guide you. Some cost management metrics that can help you track costs more effectively are:

Monthly growth – how efficiently your AWS implementation is rising in terms of the total costs
Provisioned capacity & use – this will help you identify cloud waste
Amazon EC2 unit and instance expenses – EC2 accounts for a greater portion of your expenses compared to other services
Expenses for unused resources – this should be something that is decreasing when you have visibility into unused resources
Data retrieval costs – you should be able to identify how much of your object storage charges are susceptible to data retrieval

You can read in detail about the 9 KPIs for measuring success with AWS savings here.

Establish a continuous cost control by tracking these metrics over time and recognizing patterns for improvement.

In the next article, we'll go through some most common AWS pricing plans and break them down in order to provide a better understanding of AWS costs

Tips for Kubernetes Cost Optimization

Sara Miteva — Wed, 17 Mar 2021 14:32:30 +0000

Kubernetes is ruling the container market. According to a CNCF survey, the use of Kubernetes in production in 2020 was 93%, up from 78% in 2019. Moreover, the survey reveals that the use of containers in production in 2020 was 92%. This figure is up 300% from CNCF’s first survey in 2016.

Due to the adoption of Kubernetes by DevOps teams and the open source community’s encouragement, this figure could grow more. And if it stays at present prices, this market share still is a significant portion. This means that even though Kubernetes makes a lot of things easier, challenges will always appear, as the survey confirms. Namely, the problems listed include networking, storage, tracking, surveillance, a lack of preparation, and, of course, cost management.

Running Kubernetes can be very costly, especially if done inefficiently. When businesses first try to incorporate Kubernetes in their organizations, they usually use the same architecture and setup that performed well with initial research experiments. However, this setup is often unoptimized and companies don’t think about expenses right away. This could save a lot of unnecessary costs and encourage the implementation of good habits from the beginning.

In this article, we’ll go over several methods for controlling and lowering Kubernetes costs. Moreover, as Amazon EKS is the most common container management approach after self-managed Kubernetes, we’ll offer more actionable advice on Kubernetes cost optimization on AWS.

Kubernetes cost monitoring

This is the most logical step towards starting to manage your Kubernetes costs more efficiently. Monitoring should show you how you’re spending your money when it comes to Kubernetes. More importantly, you should identify saving opportunities.

Cloud vendors offer billing summary that provides information about what you’re paying for. However, they will usually only include a simple overview that is only slightly useful for multi-tenant Kubernetes clusters. This is inaccessible in private clouds. As a consequence, it’s popular to use external software to monitor Kubernetes consumption. Prometheus, Kubecost, Microtica, and Replex are some useful tools in this field.

Choose the tools you’ll use and how you’re going to monitor your Kubernetes costs. Then, start implementing more concrete actions for Kubernetes cost optimization.

Limiting resources

Resource constraints that are effective guarantee that no program or operator of the Kubernetes system uses too much processing power. As a result, they protect you from unwelcome shocks such as unexpected billing changes.

A container can’t use more than the resource limit you set. The kubelet (and container runtime) implement the memory cap if you set it to, for example, 4GB for a particular container. The container’s runtime prohibits it from exceeding the configured resource cap. When a process in the container attempts to use more memory than is permitted, the system kernel aborts the process with an out-of-memory (OOM) error.

Developers can enforce limits in two ways. First, reactively, when the system detects a violation. The second way is by enforcement, which means that the system never allows the container to go over the limit. They can implement the same constraints in various ways for different runtimes.

Limiting resources is crucial, especially if many of your developers have direct access to Kubernetes. They ensure that available resources are shared fairly, reducing the overall cluster size. Without limitations, one person could use all energy. This would prevent others from working, resulting in a need for more computational resources overall.

However, be careful not to limit your resources without any balance. Engineers and software cannot function properly if resource limits are too low. On the other hand, they are often worthless if they are too high. Some Kubernetes cost optimization tools, like Prometheus and Kubecost, can help you decide the balance with your resources.

To find out more about limiting resources for containers, check [this page of the Kubernetes documentation}(https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).

Autoscaling

Autoscaling means paying for what you need. That’s why you have to adjust the size of your clusters to your specific needs. You can allow Kubernetes autoscaling to be able to adapt to quick variations.

Horizontal and vertical autoscaling are the two types of autoscaling available. In a nutshell, horizontal autoscaling involves inserting and removing pods depending on whether the load is above or below a specified level. The scale of individual pods balances with vertical autoscaling.

Both methods of autoscaling are useful for dynamically adapting the usable computational capacity to your real needs. This approach, though, is not necessarily ideal as it does not function with all use cases. For example, when something is requiring computational resources it is therefore not automatically downscaled.

Choose the right AWS instance

AWS Kubernetes costs are under a direct impact by the AWS instance developers use to manage Kubernetes clusters. Instances come in a number of different forms, with varying memory and compute resource combinations. Kubernetes pods are the same way, with different resource allocation. The key to keeping AWS Kubernetes costs under check is to make sure pods stack effectively on your AWS instances. The AWS instance should match the size of your pod.

The scale, number, and historical resource utilization trends of pods all play a role in deciding which AWS instance to use. Applications may have different storage or CPU requirements, which affects the type of instance to use.

Ensuring that the Kubernetes pods’ resource consumption correlates to the overall CPU and memory available on the AWS instances they use is critical for optimizing resource use and lowering AWS costs.

Check the Amazon EC2 instance types here and choose the one that suits your needs best.

Use spot instances

When it comes to AWS instances, they are available in several billing profiles: on-demand, reserved, and spot instances. On-demand instances are the most costly but have the best degree of flexibility. Spot instances have the lowest price. However, they can be terminated with a 2-minute warning. You may also get reserved instances for a set amount of time to save costs. As a result, the choice of instance form has a direct effect on the cost of operating Kubernetes on AWS.

You can utilize spot instances for workloads that you don’t permanently need and that can handle a lot of interruptions. AWS claims that spot instances will help you save up to 90% on your EC2 on-demand instance prices.

If spot instances aren’t a choice for your application since it must still run without delay, you may get a discount if you agree to use the services for a fixed period of time. You will get a substantial discount if you agree to a one- or three-year usage term. According to AWS, this could be between 40% and 60%.

Set sleeping schedules

No matter if you run the Kubernetes clusters on on-demand, reserved, or spot instances, ensuring that underutilized clusters are terminated is crucial for cost management. You can calculate the expense of AWS EC2 by the period of time you are provisioning them. Even though underutilized instances have a much greater resource impact than necessary, they still cost you the full expense of running an instance.

To put it simply, if a development team uses a cloud-based Kubernetes environment, they only use it during business hours. If they work 40 hours a week, and the environment is still working the rest of the time, they don’t have to pay for the remaining 128 hours when they aren’t using it. This, of course, won’t be the case in every team, especially if they have flexible working hours, but turning off the environment when no one is working could significantly enhance Kubernetes cost optimization.

Developers can set this up by automating a sleeping schedule and waking up the environments only when they need them. Setting up this schedule means that the system will automatically scale down unused resources. This guarantees that the environment’s condition is saved. Moreover, the environment will “wake up” easily and automatically when the engineer needs it again, meaning that there is no disruption in the workflow.

Practice regular Kubernetes cleanup

If you give engineers full access to build namespaces on demand or use Kubernetes for CI/CD, you can end up with a lot of unused objects or clusters that are still costing you money. And if you have a sleep mode that decreases computational resources, it is only for momentarily inactive resources, still retaining storage and configuration. That’s why, when you notice that some of your resources have been inactive for a very long time, removing them would be a smart thing to do.

Right-size your Kubernetes cluster

Managing a Kubernetes cluster is different for each case. There are various methods for correctly sizing your cluster, and it is important to develop your application for consistency and durability. As a programmer, you’ll frequently need to consider the specifications for the applications you’ll be running on your cluster before building it.

Right-sizing your nodes is very important when designing apps for scale. A large number of small nodes and a small number of large nodes are two very different things. That’s why the best approach would be to find the right balance between these two ends.

However, different requirements of your apps require different numbers and sizes of nodes. Check this article to find out what size and number you need for various app cases.

Tag resources

In any environment, whether cloud, on-premises, or containers, tagging resources is a smart idea. Services are bound to go unnoticed in enterprise Kubernetes environments with numerous test, staging, and development environments. These services become a chronic burden on AWS prices, even though they aren’t used. Companies should use tagging to guarantee that all services are controlled.

AWS provides a robust tagging scheme that you can use to mark services belonging to Kubernetes. You may use these tags to stay on top of resources, resource holders, and resource usage. Effective tagging allows you to easily classify and eliminate unused services. You’ll be able to assign costs and view expense breakdowns for various services once these tags are enabled in the AWS Billing dashboard.

Conclusion

The first step in your Kubernetes cost optimization is to create an outline and begin monitoring them. Then, to avoid unnecessary computational resource usage, you can set limits, which would make the costs more manageable.

Determining the best size for your resources critical for cost reduction, and autoscaling will also help. If you use AWS, you can check their less costly options, like spot instances. Additional steps to remove idle resources include an automated sleep schedule and cleaning unused Kubernetes resources. Finally, adjust pod size and implement resource tagging for even better Kubernetes cost optimization.

Incorporating these tips into your processes will result in a cost-optimized Kubernetes system. This will save your money for more crucial business operations and product improvements.

KPIs for Measuring Success with AWS Savings

Sara Miteva — Tue, 09 Mar 2021 07:36:21 +0000

Gathering and reviewing data to obtain useful insights into your organization and assess the performance of your processes is essential. When it comes to AWS savings, it’s necessary to calculate your AWS expense and utilization performance metrics. You should do this just like you measure your operational activities. As 35% of the cloud spend is wasted, organizations need to find more effective ways to make the most out of their AWS savings.

In the previous articles of this series, we discussed the most common challenges with AWS costs, listed three reasons why organizations need AWS cost optimization, and made a short introduction to FinOps. In this article, we suggest some cost management metrics that can help you track AWS savings more effectively. Moreover, you can use them as a tool to predict future performance and make cutting decisions.

Monthly growth

Observing your monthly growth helps you to obtain a perspective of how efficiently your AWS implementation is rising in terms of the total costs. In order to conform to cyclical trends in your company, we also suggest reviewing these statistics over several periods. For example, aside from calculating one-month growth, also calculate your growth over a period of six months. This will help you understand the trends that your company follows and therefore forecast future growth.

Provisioned capacity & use

Over-provisioning, distributing services with more power than necessary, is one of the principal factors of cloud waste. Many people think of over-provisioning as a state where size did not matter from the days of on-site hosting. However, you actually pay for the capacity you provision instead of what you use. This is a warning that the environment is inefficient and that you should take remedial action to the right size and reduce your cloud expenses if your provisioned capacity is dramatically higher than the actual usage.

Amazon EC2 unit expenses

Amazon EC2 powers many AWS workloads. This means that EC2 will account for a greater portion of your expenses compared to other services. As developers usually use EC2 through a variety of workloads, we suggest that they monitor your costs at shorter instances. They can do this on a daily, or even hourly basis. These reports can also help you control pricing models more effectively. Moreover, you could understand how much EC2 does one subscriber cost you, which is a very useful metric.

Amazon EC2 instance expenses

New instance generations also support increased processing power and greater cost savings. For this purpose, it can be very effective to describe the EC2 workloads that run on older generations of instances and devise a roadmap to update to the new generations of instances. Setting a concrete goal and taking targeted actions to achieve it can be very useful in optimizing your EC2 usage efficiency and reducing your overall AWS costs.

Amazon EC2 usage coverage

There is a range of pricing models that you can use to gain greater savings. At the same time, you could be scaling up your AWS consumption. You can select between Spot instances, Savings Programs, and Reserved Instances that represent a number of different use cases for your EC2 use. Setting a threshold of how much your instance fleet should cover is useful in each case. The goal here is to choose the most optimal model for your particular case.

S3 expense per storage class

Another tool you are probably using is Amazon S3, which also plays a big role in AWS savings. This service also has a lot of built-in features to help you optimize your costs. You should evaluate the different storage groups that your company is using, similar to EC2. Then, customize policies to make an impact on them. Use lifecycle policies to automate your cost savings plan.

Expenses for unused resources

Every organization has unused resources they’re paying for. For example, recovery snapshots. But, the amount spent on them is a good indicator of how well the organization is managing finances in the cloud. There are likely hundreds, if not thousands of other unused resources in most organizations’ cloud environments. They range from idle load balances to unattached block storage volumes. However, in many cases, these are not easy to identify. Therefore, it’s a worthwhile investment to implement a cloud management platform that can bring granular visibility into your entire cloud ecosystem and can actively monitor and identify unused resources that can be terminated.

Data retrieval costs

Many companies are conscious that by keeping infrequently used data in cold storage stages, they will save a substantial amount of capital. But, when occasionally retrieved data is accessed often enough due to data retrieval costs, these costs could surpass the avoided amount by putting data in a cold storage tier.

The intelligent tiering class by AWS partially solves this problem. It can help you get an overview of how much of your object storage charges are susceptible to data retrieval. However, it doesn’t work when you have one zone storage or archived storage.

Number of cost spike notifications

As almost all billing dashboards offer a budget limit setup, this means that you’ll get a notification each time the budget is overshoot, or a similar cost rise occurs.

Sudden cost spikes can be a sign of malfunctioning assets or network breaches. This is why you need to know when they happen in real-time. Look for cloud management systems that, when designing rules, offer both flexibility and immediately warn stakeholders when policies are broken.

After you’ve created your own dashboard with the specific metrics your business needs, you should work more deeply on evaluating them. For example, metrics about spending and usage can be useful in reporting to the entire organization about the costs of your department. Metrics that refer to value can be compared to your market value drivers to produce KPIs that you can track based on your company goals. It all depends on the specific objectives you’re aiming to achieve.

What's FinOps?

Sara Miteva — Wed, 03 Mar 2021 09:14:52 +0000

As a part of our cost optimization series, we already talked about the most common AWS cost optimization challenges and the reasons why every company needs to solve this. In this article, we’re talking about FinOps as a way to optimize cloud costs.

To solve their cloud cost optimization problems, some companies develop FinOps practices. FinOps refers to Cloud Financial Management. It is the process of adding financial transparency to the cloud’s variable expenditure model. The goal is to empower teams to balance between speed, expense, and quality.

FinOps is, at its heart, a cultural shift. In order to facilitate quicker execution, cross-functional teams operate together. At the same time, acquiring more financial and organizational power is also a priority.

FinOps allows all operating teams to access real-time data they need to impact their expenditure and make wise choices that eventually contribute to successful cloud cost optimization without affecting the performance, speed, and quality of the final product.

FinOps is all about eliminating obstacles. It enables innovation teams to produce better features, software, and migrations more rapidly. It also allows a cross-functional discussion about when and where to spend. An organization can sometimes plan to cut back on spending, while other times it will decide to spend more. Yet, teams have to know why they make the choices.

The FinOps process

According to the FinOps Foundation, the FinOps process has three phases: inform, optimize, and operate.

The inform phase is when the company gains visibility over the allocation of its resources. During this phase, the focus is on where our resources have been allocated, what is the state of our budget, and what kind of future awaits with this setup. For wise decisions, the on-demand and dynamic nature of the cloud, along with personalized pricing and incentives, makes it possible for precise and real-time visibility. Based on tags, accounts, or company mappings, the correct distribution of cloud spending enables detailed chargeback and showback. Other interested parties also want to confirm that the focus remains on ROI. At the same time, they want to remain within the budget and predicting spending precisely, eliminating uncertainties.

The second phase is optimize, when the team has to identify cost optimization opportunities and act accordingly. The goal is to spend resources more efficiently, avoiding waste. To help teams optimize, cloud vendors offer multiple tools. The most costly is on-demand power. Cloud services provide discounts on commitments that usually require complicated estimates for making reservations to facilitate advanced reservation preparation and improved participation. Furthermore, departments and companies can optimize the setting by turning off any inefficient usage of energy by modifying and automating them.

The third and final phase is the operate phase. Here, organizations act according to their set goals and track their progress. The team should follow the business goals together with the speed, the efficiency, and the expense of processes. The company will mark significant progress in its cost optimization activities only if they develop an efficient FinOps culture that keeps all stakeholders on track with all happenings.

In the next part, we’ll elaborate on what a FinOps culture actually means.

The FinOps culture

To drive acceptance, FinOps needs some cultural engineering. You may be the sole authority on FinOps, but it only applies to a certain extent. To make it more transformative, you have to find other members of both the Dev and DevOps teams engaged in FinOps, and you need to make it simple for them to implement it.

FinOps is, at its heart, a cultural activity. The most powerful way for teams to control their cloud expenses is through this operations strategy. Teams can leverage FinOps to execute more efficiently while maintaining financial and organizational power.

In combination with the transition to flexible cloud investment, distributed decision-making enables technology teams to work successfully with finance and business teams to make smart decisions that accelerate continuous optimization. FinOps processes enable these teams to work at high speed while boosting the economy of the cloud system. This change helps and encourages teams on the edge and allows team members to engage in the process of increasing productivity, maximizing usage, and reducing investment in any area of the organization.

The role of a FinOps

To implement FinOps practices more effectively, many teams decide to hire a FinOps lead who will take care of everything related. Here’s what this person would do:

Cost control: Consider where expenditures derive from. Output tuning: Invest and redistribute money where you really need to.
Timely choices related to cost management: You can anticipate and make decisions with real-time knowledge.
Forecast, schedule, and secure resources: You can predict the resource needs for the future, find discounts or allocate resources from other places using the information regarding cloud data consumption.
Align IT and finance teams: Teamwork guarantees the correct budget, optimizes expenses, and reduces cash loss.

It’s really difficult, though, to find a person who has all the skills required. Where the budget permits, the safest choice is to devote a multidisciplinary team of financial and IT individuals. Another solution is to get employees with a very good financial background, supported by already established departments in the company. This is a great example of how PerimeterX implemented FinOps in their organization.

Conclusion

A company’s dedication to a FinOps strategy is long-term. The process does not always go as expected, particularly for new enterprises that are still working out the commercial side of the cloud. Any organization will effectively transition to FinOps if it meets the right guiding principles, has the right attitude, has the right employees, and has the right cloud optimization software.

Why AWS Cost Optimization?

Sara Miteva — Wed, 17 Feb 2021 09:19:14 +0000

This article is the second in our series on AWS cost optimization. In this series, we’ll introduce the challenges with AWS costs. We’ll also offer actionable recommendations on how to solve them and perform efficient AWS cost optimization.

Cloud cost optimization can help a company maximize its business value. A cost-efficient company has financial stability and success, and with that, great potential to accelerate its business growth.

The term cost optimization is commonly used in the same context as the term cost reduction. The main difference between them is that cost optimization nurtures a culture where the company is aware of its costs at all times. They take it seriously by having dedication and responsibility on an ongoing basis.

With the pandemics and the current economic situation, companies have to make cloud cost savings their number one priority. Here are the top three reasons why you need AWS cost optimization:

Remove unused and idle resources

Unused resources are one of the most important reasons why you need AWS cost optimization. Having a strategy for cost optimization can help with identifying left-over resources. There is always the possibility of someone creating a new instance of a resource and forgets to remove it afterward. Or, they scale up for testing purposes and then leave it running. All these unused resources can cause cloud waste that can not be identified that easily.

When they are not used, turning off idle resources can be one of the most effective ways to save on cloud cost. This is mostly applicable for non-production environments used for development, testing, and staging. These environments don’t need to run all the time, since they are mostly used during working hours. Defining custom sleep schedules for resources after work hours or on the weekends can make your AWS bill significantly lower.

Plan spendings

Being able to pay-as-you-go is one of the many great features of the public cloud. But it also makes it very difficult to be aware of your cloud needs and necessary budget. By looking at your cloud spending history, you can start to identify patterns of usage. Information like which AWS account costs you the most and which services create the most spendings can give you an idea of how you should allocate your budget resources.

With that knowledge, you can make better forecasts for future cost spendings. You can create an action plan and avoid surprises in your AWS bill.

As organizations are increasing their cloud use, they can’t manage their cloud costs effectively. This chart from the Flexera 2020 State of the Cloud Report shows that the public cloud spends of companies go over budget by an average of 23%.

Identify saving opportunities

Staying on top of your spendings makes it easier for you to stay on budget, especially when you visualize them. Monitoring cloud cost can help you identify opportunities for improvement.

Of course, this will not be a one-time activity. Since cloud environments are live matter, they will constantly be changing. Once you find saving opportunities like removing unused resources, new ones will appear. This is why it’s best that the process is automated. Leveraging automation to scan working environments to get notifications for identified waste or getting saving recommendations can optimize your overall operations.

Final words

As cloud usage continues to accelerate, it’s essential that we are cautious and responsible with our cloud costs. Companies that have implemented cloud optimization strategies see great benefits in many other aspects. Agile businesses increase revenue, decrease operational risk and improve team productivity. Putting the time and effort into defining a cost optimization plan, setting up responsibilities, and implementing tools to save money now will have significant results in your budget.