Everything you need to know to get pro with CloudOptimo

Spot Fleet and CloudOptimo 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 CloudOptimo would be a better choice. A second difference is that Spot Fleet does not natively integrate with the AutoScalingGroup constructs widely used in many existing deployments. It does have an AutoScaling capability recently launched, but it must be set up 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 CloudOptimo immediately, Spot Fleet will require some development work. In addition, CloudOptimo provides additional cost-saving features that Spot Fleet does not, such as constantly rebalancing instances as prices fluctuate. The end result is CloudOptimo typically manages clusters at a lower price point than Spot Fleet does.
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 CloudOptimo 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 CloudOptimo operation, such as scaling up and down at a higher CPU level than the CloudOptimo 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 CloudOptimo provides.
There are many factors that CloudOptimo 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.
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. CloudOptimo 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 upfront commitment like reserved instances do. They are two independent strategies that can help you reduce costs, and you should apply both if you can. As far as working together, CloudOptimo will work seamlessly with your reserved instances, using them instead of on-demand instances when they are available.
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 CloudOptimo 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 CloudOptimo focuses on for you, allowing you to save money without a lot of work, and focus on your core business objectives.
Yes. Security was designed into CloudOptimo from the beginning. We follow 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 CloudOptimo 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, please review the following

Still in need of assistance?
Get in touch with us to learn more!