Is it secure?
Yes. Security was designed into AutoScalr from the beginning. We have two different security models you can operate AutoScalr in. The first is the simplest and most commonly used and does not require any in-account resources to be running. It follows AWS best practices for cross account access by utilizing cross account IAM roles that only have the minimum required permissions. This role is setup by a Cloud Formation template during the signup process. Once in place, AWS will enforce that only the AutoScalr account can assume this role, and only when a predetermined ExternalId generated during the signup process is provided. All access is also recorded and audit-able via Cloud Trail. For more details on this process and how secure it is see the following links:
A second option is available that does not require any cross-account privileges at all. A portion of the AutoScalr optimizer runs inside your AWS account, alleviating the need for any cross-account access.
Are spot instances risky to use?
Not if managed correctly. This site is powered by 95% spot instances and maintains 99.999% availability. But a single spot instance definitely incurs some risk. If the spot market price goes above your bid, it will be taken away from you, and if that was the only instance powering your application, it is now unavailable while you spin up new instances. However, the more typical cloud app deployment has multiple instances behind a load-balancer. If managed properly by diversifying instances across multiple spot markets, you can isolate the level of impact any single spot market price spike has on your application. For example, if you have your spare CPU capacity target set to 20% and the maximum in any one spot market setting as 20%, then even in the case of a price spike, you have adequate computational power running the application and your users would never notice a difference. And immediately AutoScalr would start new instances to diversify and return to the target spare capacity level to provide protection from a subsequent price spike. This constant monitoring and diversification logic is what AutoScalr focuses on for you, allowing you to save money without a lot of work, and focus on your core business objectives.
Why not just use Reserved Instances?
Reserved instances are a great way to save money on your AWS bill if you can predict your instance type usage levels reasonably well into the future. AutoScalr can still help you save more though, since spot prices are typically significantly below the reserved instance price for the same instance type, and do not require a significant up front commitment like reserved instances do. They are two independent strategies that can help you reduce cost, and you should apply both if you can. As far as working together, AutoScalr will work seamlessly with your reserved instances, using them instead of on demand instances when they are available.
What factors are considered when scaling up or down?
There are many factors that AutoScalr uses during scaling actions. First, the settings for maximum exposure in one spot market and for all spot markets is analyzed to make sure any proposed actions will not violate those settings. Next factors such as the current diversity over markets, prices in different spot markets, when the next time existing instances will incur a charge, and volatility of prices in certain markets are blended together to choose which instance type and spot market to place new instances in, or remove from for scaling down.
Is my application at risk if the AutoScalr service goes down?
No. We have never had a production outage of the service to date, but more importantly the way we designed our deployment architecture has a fallback mechanism built-in: the existing AutoScalingGroup your application was using before. So even if the AutoScalr service was offline, the normal AutoScalingGroup scaling thresholds will scale the application up or down. It would use On-Demand instances, so costs would return to what you were paying before, but application availability and performance would not be affected. We do recommend that you set these scaling parameters so that they do not conflict with normal AutoScalr operation, such as scaling up and down at a higher CPU level than the AutoScalr CPU settings, and/or only kick in after a longer time period of meeting the CPU criteria. Otherwise the two scaling mechanisms will fight with each other somewhat and you will lose some of the cost-savings and diversification AutoScalr provides.
Does AutoScalr support Terraform?
Yes. Terraform or CloudFormation are our two recommended ways of using AutoScalr. To enable AutoScalr for one of your existing Terraform stacks, you simply need to add a single new resource of about 8 lines to your Terraform file and all the initialization and coordination is handled behind the scenes when the stack is applied, updated, or destroyed. More details on using Terraform with AutoScalr can be found in the AutoScalr Terraform Provider.
Does AutoScalr support CloudFormation?
Yes. Using either Terraform or CloudFormation is the recommended ways of using AutoScalr. To enable AutoScalr for one of your existing CloudFormation stacks, you simply need to add about a dozen lines to your CloudFormation template and all the initialization and coordination is handled behind the scenes when the stack is created, modified, or deleted.
Does AutoScalr support Chef / Puppet based deployments?
Yes. AutoScalr has a REST API for application registration that supports Chef, Puppet, or custom scripted deployment options.
How does AutoScalr differ from Spot Fleet?
Spot Fleet and AutoScalr both provide diversification across many Spot markets by supporting multiple instance types. Spot Fleet does not provide diversification over a percentage of On-Demand as a guaranteed safety net. Every instance will always be a spot instance of some kind. If your application's availability requirements can tolerate that level of risk, Spot Fleet is a good choice. If giving up a few percentage points of cost savings for an On-Demand safety net sounds appealing, then AutoScalr would be a better choice. A second difference is that Spot Fleet does not natively integrate with the AutoScalingGroup construct widely used in many existing deployments. It does have an AutoScaling capability recently launched, but it must be setup and managed separately, and requires making code changes to the application to get new instances to register with an existing AutoScalingGroup and/or ELB. If you have an existing stack using AutoScalingGroup, you can leverage AutoScalr immediately, Spot Fleet will require some development work. In addition, AutoScalr provides additional cost-saving features that Spot Fleet does not, such as constantly rebalancing instances as prices fluctuate. The end result is AutoScalr typically manages clusters at a lower price point than Spot Fleet does.