Controlling your costs on AWS using the power of Agile Stacks

Posted by Sean O'Shaughnessey on May 28, 2020 3:08:00 AM
Sean O'Shaughnessey
Find me on:

Agile Stacks is motivated to help our customers save money as they deploy the compelling Kubernetes container orchestration platform. We have had several customers save a significant amount of money using our ever-expanding capabilities of using AWS Spot Instances. For example, Zeeto reduced cloud costs by 75% by adopting the Agile Stacks DevOps automation platform SuperHub on AWS. The company completely automated the software delivery process using an infrastructure-as-code approach and maximized their savings by deploying on Spot Instances.

What are Spot Instances?

AWS regularly has an excess capacity of servers not dedicated to its subscription customers. AWS makes this excess capacity available as a Spot Instance, but they don't promise availability.

A Spot Instance is an unused server that is available for less than the On-Demand subscription price. Spot Instances enable you to request unused servers at steep discounts and therefore can lower your Amazon costs significantly. The hourly price for a Spot Instance (the Spot price) can be different in each Availability Zone and can be changed constantly by Amazon. As a user, you choose how much you will pay for a Spot Instance and as long as there is capacity, your Spot Instance will be available. Spot Instances do not have an SLA for uptime though, they are ephemeral.

Spot Instances are available at a discount of up to 90% off compared to On-Demand pricing.

Spot Instances are a cost-effective choice if you can be flexible about when your applications run and if your applications can be interrupted. Kubernetes is handy when deploying Spot Instances.

How does Kubernetes help for Spot Instances?

Let's start with a basic understanding of one of the most significant reasons that organizations use Kubernetes in their architecture. The smallest deployable object in Kubernetes is a Pod. A Pod is a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources. A Pod contains an application's container (or, in some cases, multiple containers), storage resources, a unique IP address, as well as options that govern how the container(s) should run.

Each Pod runs a single instance of a given application. If you want to scale your application horizontally, you would use multiple Pods, one for each instance. In Kubernetes, this is referred to as replication.

Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created, it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the Pod is deleted, the Pod is evicted for lack of resources, or the Node fails.

When you use AWS Spot Instances, each instance is assigned to Kubernetes as a Node. When AWS needs to take away that Spot Instance, AWS sends a Spot Instance Termination Notice. Spot Instance Termination Notices are a new feature that can help you manage Spot interruptions by giving your applications time to prepare for a graceful shutdown. In the case of Kubernetes, we need to drain the Node using kubectl drain so that it is an orderly shutdown. To Kubernetes, this looks like the Node failed (the last condition in the previous paragraph). As soon as Kubernetes detects the failed Node, it immediately replicates a new Node to replace it. This means the ephemeral nature of a Spot Instance is mitigated by Kubernetes.

Kubernetes makes AWS Spot Instances a viable alternative to keep your application alive and minimize your costs. Agile Stacks SuperHub makes this process a lot easier to implement and manage.

How does Agile Stacks help this process?

Spot Instances are ephemeral so it is possible that an entire class of Spot Instances (i.e. all of a certain size server) could be temporarily taken away by AWS. This wholesale elimination doesn't happen often, but it has happened in the past. In theory, AWS could eliminate all Spot Instances of all kinds if they need all of those servers for more profitable subscriptions. If you want your application always to be alive, you cannot afford to have all classes of Spot Instances wiped out and your SLA processes need to then revert to On Demand instances.

Spot Instance management in SuperHub 2

Agile Stacks SuperHub takes away all of the hard work of managing this complicated scenario of Spot Instances going away. With SuperHub, you can quickly and easily set up different rankings of Spot Instances to be turned on by Kubernetes. We automatically detect the Spot Instance Termination Notice so that Kubernetes can drain the Node and start a new one.

As an example, let's assume that your application needs to run on at least an m5.large server. AWS has the right to change its pricing at any time, but as I write this, the on-demand price for an m5.large server is $0.096 per hour, and its Spot price is $0.0202 per hour. That is a savings of 79%!

Since your application needs at least an m5.large server, it is fine on larger servers and can run adequately on m5.xlarge or m5.2xlarge servers. As I write this, an m5.2xlarge server has a Spot price of $0.0831 per hour, which is over 13% cheaper than the on-demand price of the much smaller m5.large server.

In Kubernetes, you want to set up your cluster to manage the availability of these various servers. You want to configure Kubernetes to follow this logic:

If (spot instance of m5.large server node dies) then 
(start spot instance of m5.large server) then
If (spot instance of m5.large server node isn’t available)
(start m5.xlarge server) // You are saving 56% with this larger server
If (spot instance of m5.xlarge server isn’t available) then
(start spot instance of m5.2xlarge server) // You are saving 13% with this much larger server
If (spot instance of m5.2xlarge server isn’t available) then
(start on demand instance of m5.large server) // Until the spot instances come back online we won’t be saving money.

If you prefer to follow this logic in the form of a flowchart, see the attached image below.

It is extremely rare (in fact, I don't know that it has ever occurred) for AWS to turn off multiple classes of Spot Instance servers. However, this logic prepares for 3 classes of Spot instances to disappear and still maintains that the application doesn’t fail if configured in high-availability mode.

If you are very proficient with Kubernetes, you can configure Kubernetes to handle this situation yourself. If you are not an expert, you can simply use Agile Stacks SuperHub to handle this situation. It is all done in our easy to use, point-and-click-and-deploy interface. We would enjoy explaining more about the power of Agile Stacks; you can sign up for a demo of the product here. We would love to talk to you about the power and cost savings using Agile Stacks to monitor and manage your Kubernetes deployments.

Spot Instance management in SuperHub 1

 

Topics: Cloud, CTO, DevOps Automation, Infrastructure Automation

Subscribe Here!

Recent Posts

Posts by Tag

See all

RSS Feed