CloudAcademy
  1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Optimizing Cloud Costs with Spot Instances and Spotinst

AWS Spot Instances - How Do They Work?

Developed with
Spotinst

The course is part of this learning path

SysOps Administrator – Associate Certification Preparation for AWS - 2018
course-steps 33 certification 4 lab-steps 30 quiz-steps 4 description 5
play-arrow
Start course
Overview
DifficultyIntermediate
Duration38m
Students175

Description

Overview
This course from Kevin McGragh, VP of Architecture at Spotinst.com explains how to leverage excess cloud capacity from providers such as AWS, Microsoft Azure, and Google Cloud Platform to optimize the costs of cloud computing using spot instances. 

Intended Audience
Everyone working with Cloud compute workloads, from start-ups to large corporations.

Prerequisites 
A basic understanding of cloud computing and cloud computing billing models. if you are new to cloud computing we recommend completing our What is Cloud Computing course first. 


Learning Objectives
This course will enable you to:

  • Recognize and explain how to run and manage workloads on excess cloud capacity using Spot Instances. 
  • Recognize and explain the risks and benefits of the spot market.
  • Recognize and implement Spot Instances to reduce cloud compute costs. 

Outline 

  • introduction
  • AWS spot instances - How do they work?
  • Overview, Basic Concepts and First Steps
  • The Advantages of Spot Instances
  • Best Practices, Workloads and Use Cases
  • Summary

Feedback 
If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

 

Transcript

- [Mentor] Topic two: AWS Spot Instances. Drill down: How do they work? AWS Spot Advisor. The AWS Spot Advisor analyzes Spot price history to help you determine pools with the least chance of interruption and highlights the savings over on-demand rates. The advisor analyzes price history from matching instance types over the past week and month to show you how often the selected bid price did not clear the Spot price. So, how does it work? First, choose the technical parameters: virtual CPUs, memory, platform, availability zone, and amount required. Once these options are selected, an output with a list of compatible instance types is generated, including the average Spot price and the likelihood of interruption. There are two options to request Spot Instances, but we will focus on the newer, AWS recommended, RunInstance API. RunInstance provides a single way to request both On-Demand and Spot Instances without the need to understand the Spot bidding process. The command has an option to include a maximum bid price, which will default to the current On-Demand price, if omitted. As long as the Spot price is lower than the maximum bid price and capacity is available, the request is fulfilled immediately. Otherwise, the request will be fulfilled in a future time when the Spot price falls below the maximum price and capacity is available. Spot Instances run until terminated or until Amazon EC2 must interrupt them. This is also known as a Spot Instance interruption. Instance interruption behavior. 

There are a few actions that Spot Instances are able to follow when interrupted. Instances can be configured to hibernate, stop, or terminate. The hibernating feature works much like a laptop when closing the lid. Before the instance is interrupted, a daemon running on the instance will freeze the memory and store it to the EBS root volume. The EC2 service will retain the EBS root volume and any other attached EBS data volumes. The instance will be unusable until capacity is restored and the bid price meets market conditions. When the instance comes back online, the EBS root device is restored to its prior state. EBS root volumes are reattached, the instance retains its instance ID and memory is thawed from disk back to RAM. There is no charge for compute while the instance is in hibernation state, but you will pay for any EBS provision volumes. The hibernation feature is available on instance types in C3, C4, M4, R3, and R4 families with memory of less than 100 gigabytes. 

The instance will always remain in the same Availability Zone and must be running Amazon Linux, Ubuntu, Microsoft Windows operating systems that support the EC2 Hibernation Agent. Instances can also be stopped in the event of interruption. A stopped instance will not retain any memory but will keep the EBS root device and any attached EBS volumes to persist data. This is similar to shutting down a server to power back on later. When capacity and bid price are met again, the instance will go through a normal boot procedure with all previous EBS volumes attached. Lastly, an instance can be terminated. This is the default option for Spot Instances. No data, network configurations, IP, or other information will be retained. The instance, in its entirety, will be deleted and removed by EC2. Spot Blocks. Spot Blocks are AWS Spot Instances that will run continuously for a finite duration, usually between one and six hours. Pricing is typically 30 to 45% less than On-Demand and based on the requested duration and available capacity of those instances. An additional 5% discount is offered during non-peak hours for the specified region. Spot Blocks and Spot Instances are priced separately. Launching a Spot Block is similar to launching On-Demand and Spot Instances. The only difference is the inclusion of the BlockDuration parameter. This parameter specifies the required number of hours of the instance or instances are guaranteed to run. When Spot capacity is available for the requested duration, the instances will launch and run continually for a flat hourly rate. The instances will be terminated by EC2 at the end of the time block. This model is good for situations where jobs need to run continuously without interruption for up to six hours. Spot Blocks are highly recommended for batch workloads.

About the Author

Kevin McGrath is the VP of Architecture for Spotinst, specializing in Cloud Native and Serverless product designs. Kevin is responsible for researching and evaluating innovative technologies and processes leaning on his extensive background in DevOps and delivering Software as a Service within the communications and IT infrastructure industry.

Kevin started his career at USi, the first Application Service Provider (ASP) 20 years ago.  It was here he began delivering enterprise applications as a service in one of the first multi-tenant shared datacenter environments. After USinternetworking was acquired by AT&T, Kevin served in the office of the CTO at Sungard Availability Services where he specialized in migrating legacy workload to cloud native and Serverless architectures.

Kevin holds a B.A. in Economics from the University of Maryland and a Masters in Technology Management from University of Maryland University College.