A lot of organisations come to us for help after they have spent weeks wrestling with AWS Instance scheduler. Other users who have never tried to grapple with the 40 page instructional document ask us why they shouldn’t use it instead of GorillaStack.
Instance Scheduler Overview
The AWS Instance Scheduler is a solution written by the AWS Solutions team, based off an old blog post outlining how to write your own instance scheduler. That guide and this solution provide users with a roll your own instance scheduler. We will outline the key points of difference between the AWS Instance Scheduler and the GorillaStack Rules Engine.
GorillaStack Feature Set
The first and most obvious difference between GorillaStack and the AWS Instance Scheduler is the difference in the feature set. GorillaStack’s Rules Engine can be triggered on multiple triggers (not just schedules) and can perform a far greater set of actions beyond scheduling instances, around preparation for disaster recovery, snapshot creation/retention, patching, auto scaling management and DynamoDB scaling, to name just a few. GorillaStack also completes the feedback loop by providing an Event Log (with audit information and execution history) as well as our Engine Room (providing ROI and savings tracking to report back to the business).
Managed Solution vs. In House Instance Scheduler
Many teams that we speak with are time poor and lack the human resources they need for projects that deliver genuine value to their business. Managed solutions have become increasingly popular over the last few years, as businesses realise the critical importance of maintaining focus on business objectives.
While the AWS Instance Scheduler seems straightforward to deploy and use, there are hidden complexities in the nature of its implementation, configuration and maintenance. These problems are compounded in enterprises, with complex, large, multi-account environments and distinct teams with different requirements.
GorillaStack provides enterprise-grade automation software as a managed service, with all the features that large businesses require (SAML, role based access control, audit history on rule configuration) and all the features that the end users want (notifications, actions, customisation).
Timezones, Notifications, Snoozing and Cancelling
GorillaStack has been designed for large, dynamic teams and continues to be developed by their feedback. Some examples of significant features differences that make a difference to users:
- Multi-timezone support: To save users from having to convert to UTC and never again get stung by daylight savings changes in your locality.
- Notifications: For any scheduled rule in GorillaStack, you can configure a notification to be delivered by Slack or Email to notify you of what resources are targeted by the current rule. In the notification, the users are also provided the option to snooze or cancel (of course, access to these actions are also customisable using our custom role based access control).
- Snoozing and Cancelling: Occasionally cases come up where the scheduled time is no longer appropriate for a particular day. It could be that users are working late, or systems are still in use. Either way, users should be able to say “not today” (cancel) or “wait X minutes” (snooze). This is possible only in GorillaStack and spares users of the alternative, which is having to delete and re-add the configuration in the Instance Scheduler, or otherwise remove tags for targeting and re-add them later
- Team Enablement: By supporting SAML and complex, custom user roles – organisations empower teams to manage environments by giving variable access to the end user. This is magnified in organisations with fluid requirements (changing schedule requirements, changing personnel, changing tag management, changing tag variables) where it would otherwise be near impossible to maintain code with a central owner.
Incomparable flexibility in targeting
Another area where GorillaStack’s Rules Engine really shines is how it manages granular targeting of resources. Users implementing the AWS Instance Scheduler need to make decisions in implementation about whether to implement a cross region or cross account flavour. If configured for multiple accounts, all schedules will always apply to all accounts and all regions. In GorillaStack on the other hand, for each rule, the user has the option to select which regions and accounts at a per rule basis, so all accounts and all regions is an option, but isn’t mandated.
Within the AWS Instance Scheduler deployment, the user is required to specify a particular Resource Tag Key, which will be used to consider Resource Tag values to match against each schedule configured. This means that every resource to be targeted can only be identified on the presence of a single tag.
In GorillaStack on the other hand, we provide the notion of TagGroups. Users specify a combination of Resource Tag Key:Value pairs and matching strategies (case sensitive, case insensitive or using regular expressions). The user can then combine these using a boolean expression to define how to match against resources at runtime. This gives the ability to cut into specific subsets of resources at a far more granular level.
GorillaStack serves small businesses and startups all the way through to some of the largest private enterprises and government organisations in the world. The common strand that runs through each of our customers is their focus on innovation and progress. The best practicing organisations recognize the importance of enabling their teams to focus on the core work that drives towards a business’s overall strategy whilst allowing the undifferentiated heavy lifting to be taken care of by tools that were specifically designed for the job at hand.