leanercloud / autospotting

Saves up to 90% of AWS EC2 costs by automating the use of spot instances on existing AutoScaling groups. Installs in minutes using CloudFormation or Terraform. Convenient to deploy at scale using StackSets. Uses tagging to avoid launch configuration changes. Automated spot termination handling. Reliable fallback to on-demand instances.

AutoSpotting - Community Edition

Most new features, bug fixes and improvements for increased reliability and better performance developed by the main author after July 2022 are only available in the commercial version of AutoSpotting, available on the AWS Marketplace. The only exception are security fixes, which will be patched in the Community Edition on a best effort basis.

If you notice any issues in the Community Edition feel free to report them but they are not being worked on by LeanerCloud anymore. Chances are they are already solved in the Commercial Edition, so you may want to try that out.

Bug fixes and new features contributed by the community are welcome and will remain available in the Community Edition indefinitely.

The list of ehnancements in the Commercial edition is documented in detail here, but you can see below a brief feature comparison of AutoSpotting options vs. AWS AutoScaling groups.

Feature	Autoscaling Groups	AutoSpotting Community Edition	AutoSpotting Commercial
Easy configuration rollout using tags	❌	✅	✅
Automated Spot instance type diversification	If using attribute based selection	✅	✅
Allocation policy with bias for new instance types	❌	✅	✅
Spot event handling - Rebalancing Recommendation	Optional	✅ (Default - increased instance churn!)	Optional
Spot event handling - Termination Notification	❌	Optional	✅ (Default - less instance churn)
Spot event handling - Replacement with a new Spot instance	Requires Rebalancing Recommendation	✅ Via Spot termination + ASG OnDemand launch	✅ Proactive
Load balancer and Target Group TCP connection draining	✅	✅ (Relying on Autoscaling)	✅ Proactive
Automated ECS task draining	Requires UserData script changes	Requires UserData script changes	✅
Failover to on-demand instances	❌	✅ Relies on Autoscaling to Launch replacement	✅ Proactive
Instance type diversification for On-Demand Failover	❌	❌ (Single instance type from Launch Template)	✅ (Same diversification as Spot)
Automated Spot product handling	❌	❌	✅
Main deployment region	N/A	❌ (N. Virginia only)	✅ (Any region)
Parallel instance type replacement	N/A	❌	✅
Recent instance type coverage	N/A	❌	✅
Auto-update instance type information	If using attribute based selection	❌	Optional
Savings reports email	❌	❌	✅
Relax EBS bandwidth checks for increased diversification	N/A	❌	✅
Reuse ASG Launch Template when launching Spot instances	N/A	❌	✅
Support Autoscaling Groups with a Mixed Instances Policy	✅	❌ (silently fails for such groups)	✅
Costs	Free (AWS Service)	Free and open source	5% of savings from OnDemand

About AutoSpotting

AutoSpotting is the leading open source spot market automation tool, optimized towards quick/easy/frictionless adoption of EC2 Spot instances at any scale.

Since its launch in 2016, it's being used by thousands of users around the world, companies of all shapes and sizes, in aggregate saved them in the hundreds of millions of dollars so far as per our current estimations.

It is usually set up to monitor existing long-running AutoScaling groups, replacing their instances with Spot instances, with minimal configuration changes.

Often all it needs is just tagging the AutoScaling groups with spot-enabled=true, (in some cases even that can be avoided), yielding the usual 60%-90% Spot cost savings but in a better integrated and easier to adopt way than other alternative tools and solutions.

It is particularly useful if you have a large footprint that you want to migrate to Spot quickly due to management pressure but with minimal effort and configuration changes.

Demo

Here's a demo of AutoSpotting and the way it integrates with the new Spot Savings Estimator GUI. (Click to open on YouTube)

Guiding principles

• Customer-focused, designed to maximize user benefits and reduce adoption friction
• Safe and secure, hosted in your AWS account and with minimal required set of IAM permissions
• Auditable OSS code base developed in the open
• Inexpensive, easy to install and supported builds offered through the AWS Marketplace, with comprehensive support and additional features geared towards production usage at scale.
• Simple, minimalist implementation

Benefits compared to alternatives

• automated failover to OnDemand instances in the event of lost Spot capacity
• automated instance type selection for Spot diversification without configuration changes from a standard OnDemand setup, and no vendor lock-in
• bias towards cheapest AND newest instance types

How does it work?

Once installed and enabled to run against existing on-demand AutoScaling groups, AutoSpotting gradually replaces their on-demand instances with cheaper spot instances that are at least as large and identically configured to the group's members, without changing the group launch configuration in any way. You can also keep running a configurable number of on-demand instances given as percentage or absolute number and it automatically fails over to on-demand in case of spot instance terminations.

Going forward, as well as on any new ASGs that match the expected tags, any new on-demand instances above the amount configured to be kept running will be immediately replaced with spot clones within seconds of being launched.

If this fails temporarily due to insufficient spot capacity, AutoSpotting will continuously attempt to replace them every few minutes until successful after spot capacity becomes available again.

When launching Spot instances, the compatible instance types are chosen by default using a the capacity-optimized-prioritized allocation strategy, which is given a list of instance types sorted by price. This configuration offers a good tradeoff between low cost and significantly reduced interruption rates. The lowest-price allocation strategy is still available as a configuration option.

A single installation can handle all enabled groups from an entire AWS account in parallel across all available AWS regions, but it can be restricted to fewer regions if desired in certain situations.

Your groups will then monitor and use these Spot instances just like they would do with your on-demand instances. They will automatically join their respective load balancer and start receiving traffic once passing the health checks, and the traffic would automatically be drained on termination.

See this video for more imformation on AutoSpotting. https://youtu.be/foobAmWpexI

What savings can I expect?

The savings it generates are in the 60-90% range usually seen when using spot instances, but they may vary depending on region and instance type.

What's under the hood?

The entire logic described above is implemented in a set of Lambda functions deployed using CloudFormation or Terraform stacks that can be installed and configured in just a few minutes.

The stack uses the minimal set of IAM permissions required for them to work and requires no admin-like cross-account permissions. The entire code base can be audited to see how these permissions are being used and even locked down further if your audit discovers any issues. This is not a SaaS, there's no component that calls home or reveals any details about your infrastructure.

The main Lambda function is written in the Go programming language and the code is compiled as a static binary. As of August 2021 this has been included in a Docker image used by the Lambda function.

The stack also consists of a few CloudWatch event triggers, that run the Lambda function periodically and whenever it needs to take action against the enabled groups. Between runs your group is entirely managed by AutoScaling (including any scaling policies you may have) and load balancer health checks, that can trigger instance launches or replacements using the original on-demand launch configuration.

Read here for more information and implementation details.

FAQs

Many Frequently Asked Questions about the project are answered in the FAQ, please read this first before asking for support.

If you have additional questions not covered there, reach out to us on Slack and we're happy to help.

Getting Started

It's usually as easy as launching a CloudFormation (or Terraform) stack and setting the (configurable) spot-enabled tag on the AutoScaling groups where you want it enabled to true.

When installed from the AWS marketplace, all the required infrastructure and configuration will be created automatically, so you can get started as fast as possible. Otherwise you'll need to build it yourself as per the instructions available here.

For more detailed information on how to get started you can also read this document

Support

Marketplace subscribers can get support on Slack and any feature requests or issues raised via this communication channel will be prioritized.

Community support is available to OSS users on the gitter chat room, where the main authors and other users are likely to help you solve issues. This is offered on a best effort basis and under certain conditions, such as using the latest version of the software available on the main Github branch, without any code customizations and using the default configuration options.

If you need help for a large scale rollout or migrating from alternative tools/solutions get in touch on gitter.

Contributing

AutoSpotting is open source and developed in the open by a vibrant community of dozens of contributors.

The Community Edition is open for contributions, submitted according to the contribution guidelines.

Individuals and companies supporting the development of the open source code get free of charge support in getting their code merged upstream.

Community Edition

The source code from this repo is and will always be open source, so you can build and run it yourself, see how it works and even enhance it if you want.

Any external contributions to the Community Edition will be remain available to all Community Edition users, but also included in future versions of the commercial edition.

Subscriptions

A free low traffic mailing list is available on Beehiiv, where you can sign up for occasional emails related to the project, mainly related to major changes in the open source code, savings tips or announcements about other tools I've been working on.

Announcements on new Marketplace releases, including comprehensive release notes, upgrade instructions and tips to get the most out of AutoSpotting will be communicated in private to Patreon subscribers.

A Github sponsors subscription is also available for people interested in the ongoing development of AutoSpotting, with tiers covering anything from a non-strings attached donation, prioritization of feature requests, all the way to custom features development and maintenance of private customized forks.

Please get in touch on gitter if you have any questions about these offerings or if you have any other ideas on how I could provide additional value to my community.

Compiling and Installing

It is recommended to use the commercial offering available on the AWS marketplace, which is more feature-complete, easier to install, supports further development of the software and includes comprehensive support.

But if you have some special needs that require some customizations, you can always build and run your customized binaries that you maintain on your own.

More details are available here

License

This software is distributed under the terms of the OSL-3.0 license.

The AWS Marketplace offering is made available under the standard AWS Marketplace EULA.

autospotting's Issues

Fix handling of instance storage mapping

There is a bug in instance store handling.

In case the launch configuration has more device mappings than available in the specified instance type, some of them will get ignored when launching the instances, so the instance will actually have less ephemeral instance store volumes than specified in the launch configuration.

Since we compare storage in the instance information with the number of ephemeral devices in the launch configuration, this causes the storage comparison to fail for a lot of otherwise compatible and closely priced instances, potentially leaving us only with much more expensive instances likely to fail when compared by price.

The storage comparison should instead consider the minimum between the number of ephemeral devices specified in the launch configuration and the number of devices available for that instance type.

CodeDeploy support

My current autoscaling groups use CodeDeploy to deploy the web applications. CodeDeploy uses Hooks in the AutoScaling Group for that, is this supported out of the box?

Failures with AutoScaling groups defined on non-default VPC

Consider network performance attributes when choosing new instance types

Check the following attributes, only giving instances with supperior characteristics than the original instance:

• Network Performance rating
• Enhanced networking
• EBS optimized IOPS
• EBS Optimized Throughput
• EBS Optimized MaxBandwidth

Make the algorithm configurable

This could be achieved using some additional metadata specified in the tag set on the AutoScaling group.

Make it self-contained, and disable auto-updates

Fork the code into a self-contained implementation which is packaged entirely into the Lambda function's code, without external runtime dependencies.

This may be done thorugh a port to one of the lambda-based frameworks such as apex, serverless or sparta, after investigating which one of those is the best for us.

Document self-hosting binaries

This was achieved by @nmeierpolys while trying to work around #25, and it would be nice to have it documented in a new Markdown file, which would be referenced from the main readme.

Investigate weighting of instance types

This may allow us to replace a number of smaller instances with a single bigger instance, as long as the price is proportionally lower.

Also depends on #5

Paginate all API calls where it is applicable

This issue was discovered in #36, it may become a problem on AWS accounts with lots of resources.

undefined: Asset

I'm trying to test this out but I'm having trouble even getting it running locally. Following the SETUP.md, I get this:

$ go get github.com/cristim/autospotting
# github.com/cristim/autospotting
src/github.com/cristim/autospotting/autospotting.go:53: undefined: Asset
src/github.com/cristim/autospotting/autospotting.go:58: undefined: Asset

Properly handle SecurityGroups in DefaultVPC environments

When using a stack created for EC2 classic, the groups are created by name.

In VPC(inclusing DefaultVPC) they need to be given by ID.

The code may need to query the groups by name and return their ID, and pass them by ID on VPC environments.

Write tests for instance.go

Write tests for autoscaling.go

Make Agent Run for all ASG in each iteration, packaging discussions

Looks like in each iteration of the Lambda function, it runs only for one ASG, make the replacement process very long for multiple ASG environment.

Investigate and implement a better way of logging

The idea is to have different level of logging, thus allowing cleaner/shorter outputs and solve bug if need be.

Investigate group capacity set to 0 instances

Use eawsy/aws-lambda-go for packaging

This has a couple of benefits

• simpler, less custom build scripts
• build in Docker container, so it doesn't need anything but docker installed for development instead of a full Golang toolchain
• remove the Python wrapper entirely
• slightly faster execution

Possible issues

• the shipping of the instance information would need some refactoring, maybe we could be using go-bindata instead of including a blob
• Local execution would need some Investigation

Failed to tag instance

It has happened before, the waitFor function should be enough, but it's look like the request it self doesn't exists.

The instance was launch successfully with the right user data.

autoscaling.go:313: test-ecs-cluster Waiting for spot instance for spot instance request sir-7tag5hag
autoscaling.go:468: awseb-e-sku5tnq3xu-stack-AWSEBAutoScalingGroup-1F01KRYAGNGAD Failed to create tags for the spot instance request InvalidSpotInstanceRequestID.NotFound: The spot instance request ID 'sir-r1vi76vg' does not exist
status code: 400, request id: d00b11c4-ba27-4934-ab5e-5a189b6b1c64

Temporarily blacklist spot instance types after multiple launch failures in a given AZ

This is an idea I got while discussing #25.

We should have a way to track instance launch failures for a given instance type/AZ combination, and somehow temporarily blacklist them for a few hours if spot instance requests fail to be fulfilled over multiple runs in a row.

Support more Spot market products, not only Linux/UNIX

Write tests for launch_configuration.go

Write tests for spot_instance_request.go

Take into account the current reserved instance usage before launching spot instances

Support the new Ohio region and recently released instance types

Fixed in a2be373, available for installation as of the TravisCI build 63

Update regional support for R3 and D2 instance types

AWS announced increased regional availability of R3 and D2 instance types: https://aws.amazon.com/about-aws/whats-new/2016/10/announcing-regional-expansion-of-amazon-ec2-instances/

Add support for the new London region

Some Spot are created without Tag

Some spot requests are fulfilled, but no 'launched-for-asg' is been assigned to this instance.

03:08:27
autoscaling.go:443: production-ecs-cluster Created spot instance request sir-dbqr5wjj
03:08:27
autoscaling.go:483: production-ecs-cluster Failed to create tags for the spot instance request InvalidSpotInstanceRequestID.NotFound: The spot instance request ID 'sir-dbqr5wjj' does not exist
03:08:28
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:28
SpotInstanceRequestId: "sir-dbqr5wjj",
03:08:33
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:33
SpotInstanceRequestId: "sir-dbqr5wjj",
03:08:38
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:38
SpotInstanceRequestId: "sir-dbqr5wjj",
03:08:43
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:43
SpotInstanceRequestId: "sir-dbqr5wjj",
03:08:48
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:48
SpotInstanceRequestId: "sir-dbqr5wjj",
03:08:53
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:53
SpotInstanceRequestId: "sir-dbqr5wjj",
03:08:58
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:08:58
SpotInstanceRequestId: "sir-dbqr5wjj",
03:09:04
autoscaling.go:335: production-ecs-cluster Refreshed details for sir-dbqr5wjj {
03:09:04
SpotInstanceRequestId: "sir-dbqr5wjj",

Increase the automated test coverage to an acceptable value

I'd like to see it achieve somewhere around 80%

Summary of files:

• autoscaling (ref https://github.com/cristim/autospotting/issues/41)
• connections (no ref)
• instance (ref https://github.com/cristim/autospotting/issues/42)
• launch_configuration (ref https://github.com/cristim/autospotting/issues/43)
• main (ref https://github.com/cristim/autospotting/issues/272)
• region (ref https://github.com/cristim/autospotting/issues/44)
• spot_instance_request (ref https://github.com/cristim/autospotting/issues/45)
• spot_price (no ref)

Add support for Windows, and use the correct spot product for Linux

It should also work for Windows instances, not just Linux/Unix.

On Linux/Unix, also take into account the Suse and VPC/Classic spot price variations, since at the moment just Linux/Unix is used, which may sometimes cause problems.

Keep at least one (or more) reserved instance running

I have a web application and it is essential to have a number of instances always running to handle the possibility of having all spot instances shut down and make the web application still accessible.

Is it possible to configure Autospotting to keep a specific (or a number of) reserved instances without replacement while replacing the rest of the instances with spot ones ?

Failed to describe AutoScaling tags in <region> AccessDenied

I'm getting the following error:

region.go:248: Failed to describe AutoScaling tags in us-east-1 AccessDenied: User: arn:aws:sts::308824460317:assumed-role/AutoSpotting-LambdaExecutionRole-17GHN91Z6W9OE/AutoSpotting-LambdaFunction-V9LHZ91FKJK4 is not authorized to perform: autoscaling:DescribeTags

Workaround it by adding "AmazonEC2FullAccess" policy to the autospotting role.

I'm using very early version of the stack, maybe the role needs to be updated.

Currently this is the structure of the role:

{
    "Statement": [
        {
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:AttachInstances",
                "autoscaling:DetachInstances",
                "ec2:CreateTags",
                "ec2:DescribeInstances",
                "ec2:DescribeRegions",
                "ec2:DescribeSpotInstanceRequests",
                "ec2:DescribeSpotPriceHistory",
                "ec2:RequestSpotInstances",
                "ec2:TerminateInstances",
                "iam:PassRole",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Improve the instance replacement logic

The code needs to be cleaned up at least as per some of the code review comments posted on #46.

Any function that is changed needs to have its unit tests updated or created if missing.

Pick the replaced on-demand instances based on the uptime

The instances should be replaced in a way that minimizes the wasted runtime hours that the user gets charged. We should pick the on-demand instance which will be closer to a full instance hour when eventually terminated.

Max((uptime_minutes + grace_period_minutes + 15 ) % 60)

The 15min is a buffer that allows us to launch a spot instance and replace the on-demand one. It could also be parameterized, although I don't think it worth the effort.

Agent Fault during execution

Getting the following error:

`autoscaling.go:732: memory compatible, continuing evaluation
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:22 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:23 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:23 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:23 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:23 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:24 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:24 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:24 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:24 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:24 Request body type has been overwritten. May cause race conditions
2016/10/05 09:08:26 Request body type has been overwritten. May cause race conditions
autoscaling.go:489: Throttling: Rate exceeded
status code: 400, request id: 467a74c5-8adb-11e6-b8f6-5b4ea7c39369
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x478404]

goroutine 151 [running]:
panic(0x84c520, 0xc420014040)
/home/travis/.gimme/versions/go1.7.linux.amd64/src/runtime/panic.go:500 +0x1a1
github.com/cristim/autospotting/core.(_autoScalingGroup).countAttachedInstanceStoreVolumes(0xc420252740, 0xc42066ee40)
/home/travis/gopath/src/github.com/cristim/autospotting/core/autoscaling.go:842 +0x34
github.com/cristim/autospotting/core.(_autoScalingGroup).getCompatibleSpotInstanceTypes(0xc420252740, 0xc4203f5660, 0xa, 0xc4202ef800, 0xc420641ce0, 0x38, 0x0)
/home/travis/gopath/src/github.com/cristim/autospotting/core/autoscaling.go:747 +0xa16
github.com/cristim/autospotting/core.(_autoScalingGroup).getCheapestCompatibleSpotInstanceType(0xc420252740, 0xc4203f5660, 0xa, 0xc4202ef800, 0xc420641ca0)
/home/travis/gopath/src/github.com/cristim/autospotting/core/autoscaling.go:665 +0x22f
github.com/cristim/autospotting/core.(_autoScalingGroup).launchCheapestSpotInstance(0xc420252740, 0xc42032b338)
/home/travis/gopath/src/github.com/cristim/autospotting/core/autoscaling.go:361 +0x2f1
github.com/cristim/autospotting/core.(_autoScalingGroup).process(0xc420252740)
/home/travis/gopath/src/github.com/cristim/autospotting/core/autoscaling.go:63 +0x55b
github.com/cristim/autospotting/core.(_region).processEnabledAutoScalingGroups.func1(0xc4204ec420, 0xc42022cce0, 0x16, 0xc4204ec420, 0xc42025a280, 0x0, 0x0, 0x0)
/home/travis/gopath/src/github.com/cristim/autospotting/core/region.go:195 +0x74
created by github.com/cristim/autospotting/core.(*region).processEnabledAutoScalingGroups
/home/travis/gopath/src/github.com/cristim/autospotting/core/region.go:197 +0x112
END RequestId: 8e105fb4-8ada-11e6-83d3-57bdd7783738
REPORT RequestId: 8e105fb4-8ada-11e6-83d3-57bdd7783738 Duration: 9197.08 ms Billed Duration: 9200 ms Memory Size: 128 MB Max Memory Used: 15 MB `

Try it out on EC2 classic and fix any issues

The current code was recently changed in order to work on VPC, and was only tested on VPC and DefaultVPC environments, so it may have regressions on EC2 Classic.

Those need to be checked and ironed out if found.

Add new region: Canada-central

This depends on vantage-sh/ec2instances.info#214

Configuration option for the number of instances to be allowed per instance-type/AZ combination

At the moment this number is hardcoded to 20% in the autospotting instance replacement logic, which should be changed.

• we need a configuration option added to the logic that would allow an arbitrary number (the related logic may also need some clean-ups).
• the new option should be exposed through a new command-line flag, defaulting to the current hardcoded value.
• the new flag needs to be exposed by the CloudFormaiton stack as a parameter, also with the same default value.
• it needs to be configurable on a group level override using tags
• the changed code need to have unit tests
• the new option needs to be documented in the README, perhaps in multiple sections if applicable.

Consider availability zone when picking an instance type

Our instances all run in the us-east-1d availability zone. When the autospotting process runs, it's finding the cg1.4xlarge instance type as the cheapest option and trying to use that to request spot instances. Unfortunately, the cg1.4xlarge instance type isn't available in that us-east-1d AZ, only us-east-1c. We get this error on the spot request "capacity-not-available: There is no Spot capacity available that matches your request. "

For use cases like ours that are limited to a specific AZ, it would be really helpful to consider the AZ when retrieving spot pricing info, and only pick an instance type if it's available in the AZ.

When this happens, it continues to request a new spot instance each time the process runs, which fairly quickly uses up the maximum number of open spot instance requests that AWS allows, preventing other spot instance requests.

Allow keeping some residual on-demand capacity when configured as such

This depends on #5, but once that's in place we can have a way to configure the algorithm to keep some on-demand capacity.

React on the 2min termination notice

Each of the instances about to be terminated can poll a metadata entry which will specify when the termination is imminent.

This should be handled in some way that may be specific to the application, so the user should be allowed to run some code that cleanly takes that instance out of the pool.

Whitelist/blacklist certain instance types via configuration

I saw forks that hard-coded some specific instance types they need in their environment. Other people complained that some instances are problematic in certain availability zones and had them hardcoded out.

This could be configurable using CloudFormation stack parameters, passed as variables to the Lambda function now that Lambda supports this feature. We could add two new CloudFormation stack options:

WhiteListedInstanceTypes: m3.medium,c4.large
BlackListedInstanceTypes: c3.large

On another hand I think that such a global setting may not be desirable for some cases, so it may be better to also be able to apply it on a per-group basis, using additional tags set on the AutoScaling group:

AutoSpotting_WhiteListedInstanceTypes: c3.large,c4.large
AutoSpotting_BlackListedInstanceTypes:  c3.xlarge

Implement global configuration options when executed from Lambda

Currently the autospotting CLI tool supports a number of flags when executed manually, but those are completely ignored when executed from Lambda, which is not yet configurable.

This should be implemented by customizing our CloudWatch events.

• The CloudFormation stack should have configuration parameters corresponding to each of the global command-line flags
• A custom CloudWatch event should be generated by the CloudFormation template based on those stack parameters
• The event data should be handled by the autospotting Lambda handler for generating configuration data structure just like done for the command-line flags

Review all merged non-approved pull requests.

All the code that was already merged needs to be reviewed after the fact.

All identified problems would need to be raised as new issues and fixed in new pull requests.

Working with Elastic Beanstalk

Just tested it with Elastic Beanstalk - working great. just add the tags during creation of new environment.

Maybe add to README?

Roey

Do not process AutoScaling groups while the CloudFormation stack that created them is in progress

We use cfn init to publish a success signal. It would be cool if autospotting could read that and ensure that a replacement of an instance resulted in a successful deployment.

Use the average spot price over the last day/week instead of the current one

This is related to #3

Spot requests fail when no SSH key is configured

Hi!

While playing around with autospotting, I configured a Launch Configuration that did not define an SSH key. In this setup, the spot requests failed with this error message:

failed: Invalid value '' for keyPairNames. It should not be blank (400 response code)
bad-parameters: Your Spot request failed due to bad parameters.

It would be nice if autospotting supported this setup.

Choose more reliable instance types

Use the Spot Bid Advisor information about the likelyhood of instances being terminated, in order to prefer instances unlikely to be terminated in the near future.

Write tests for region.go

Refactoring to split autoscaling.go in multiple components.