Is your EC2 scheduler approach “Federalist” or “States’ Rights”?

ParkMyCloud has helped dozens of SMBs and enterprises control and reduce AWS spending. ParkMyCloud’s EC2 scheduler lets customers set automatic stop/start times (we call it “parking”) for EC2 instances.

Two primary implications of scheduling EC2 start/stop times are:

(a) determining what the “parking” schedule is; and

(b) communicating the schedule to your internal AWS users.

There are two basic ways our customers determine and communicate parking schedules. Let’s call them “Federalist” and “States’ Rights.” (These are our nicknames for what you might think of as centralized versus de-centralized IT.)

ec2 scheduler federalist or states rightsFederalist: Maintain control of the parking schedules at the organization level.

  • IT leaders must come to a consensus with their teams to determine the “right” schedules. This is based upon the typical hours their developers work.
  • They put policies in place to govern how schedules are set and named, and who has authority to change them.

NOTE: Sometimes developers work after (or before) hours because of an important deadline. ParkMyCloud easily allows them to suspend a schedule and then start it with a single click. We call this our “snooze” feature.

States’ Rights: Set a default “lights outs” state for all non-production instances so they are “always off.”

(Note that this is the opposite of AWS’ approach, which is a default “lights on.”)

  • With this approach there is just one schedule to maintain at the organizational level. (“Always Parked 24×7”). Hence there is no time wasted on arguing over the “right” schedules.
  • Each developer can work on his/her schedule using the “snooze” capability mentioned above. They can suspend the schedule for the amount of time they will be working and run the EC2 instances they need. When they leave for the day, the snooze expires and the schedule goes back into effect. (I.e., the instances automatically turn back off.)

Both of these approaches seem to work well within different corporate cultures. We have built ParkMyCloud to be flexible and simple enough to accommodate either one.

Is your approach more like Federalist or States’ Rights? Or neither? Let us know in the comments below.

New Release of ParkMyCloud: Updated Dashboard, “Always Parked” and More

Over the long weekend, we pushed out a new release of ParkMyCloud. This new release contains several feature improvements, and sets up the platform for more user-requested features to come. Let’s take a look.

Updated Dashboard

When you next log in – or first log in, if you’re a new user –  you will be greeted by a new dashboard. It has a new look and feel, with actions on the left, info on the right.

The old recommendations bar has been revamped into a Keywords tab, which alarms RED  whenever there are instances recommended to be parked:


Also notice the “Metrics” and “Policies” tabs – coming soon!

“Always Parked” Schedule

You can now create a parking schedule that parks instances 24/7:

This is great news for users who prefer a parking approach that capitalizes on the “snooze” function.

In this approach, an organization may choose to set all non-production instances on an “always parked” schedule. When developers come in to work in the morning, they can “snooze” the parking schedule on their instances for the length of the workday, for which time they will run. Then, the instances will turn off at the end of the day, maximizing savings. Several of our customers have had great success with the schedule + snooze formula.

Search Logic

This release also improves the search logic functionality.  You can now use negation logic in both the dashboard filtering and in the recommendations keywords.  Just put a “-“ in front of a search term, and everything not including that term will show up:


Schedule Removal Behavior

We have also changed the behavior for schedule removal. When a schedule is removed, the instance will no longer automatically start. Now it will remain in the state it was in when the schedule was removed.


As always, we welcome your feedback on these updates – please comment below.

You Snooze You Win: How ParkMyCloud Users Got Creative to Maximize AWS Cost Savings

I’m sure that most people have heard of the Law of Unintended Consequences.

How often have we seen some new technology or gadget with promise be used for more nefarious purposes?

For example, I am convinced that when Ernest Holmes invented the tow truck back in 1916, he had a higher purpose in mind than using them to shake down citizens for parking revenues, to fill municipal coffers.

Indeed, the Law of Unintended Consequences is always in the back of the minds of scientists, engineers, inventors and entrepreneurs as they bring new inventions and products to market. Will these products take on an unintended life of their own? Will they be used for good or for evil purposes?

Occasionally, though, something good is invented and users stumble upon an even better way of putting it to use, in a way the inventor never dreamed of.

Our Intention: Snooze for an Hour

A few months ago we released simple capability within ParkMyCloud called “Snoozing”.

First some context: When you attach a parking schedule to an AWS instance, that schedule will enforce itself and maintain the desired instance state. When the schedule says an instance is supposed to be turned off, it will be off. When it is supposed to be on, it will be turned on.

snooze when you need your instances to maximize aws cost savingsThat’s great for saving money on AWS instances that don’t need to be running 24×7, however, it can be problematic when a developer needs to come in on the weekend to get some work done and everything is turned off. Or they need to continue to work late on a weeknight, but a schedule is in place that shuts down development environments by 6 pm.

These common scenarios led several of our customers to ask us for a “snooze button” – the ability to suspend schedule action for a set period of time. So, we obliged. In fact, we integrated that ability with on/off toggles, so that a developer can select a parked instance and hit the toggle button to turn it on. The system will prompt him/her, asking how long they want to suspend the schedule. It then snoozes the schedule for that period of time for the instance(s).

The Unintended Consequence: Sleep Until Waking

dashboard15kSince we released the Start/Stop/Snooze functionality back in January of this year, a couple of our customers have taken the concept of saving money by parking instances and turned it on its ear.

They have taken the interesting approach of turning ALL of their non-production environments to be STOPPED by default, using a single parking schedule. They then require their development teams to snooze the schedule for the instances they will be using for the amount of time they will be working.

Using this approach, these users have not only maximized their monthly AWS cost savings, but they redeemed the time by avoiding the need to hammer out a set of parking schedules that suited everyone.

Bravo to them, on this innovative, out-of-the-box thinking!





Announcing AWS IAM Role Support for ParkMyCloud

Exciting news! As of today, ParkMyCloud now includes AWS IAM role support as a method to connect to your AWS account, in addition to IAM user credentials.

This secure approach to 3rd party access to AWS has been requested by many of our users and, in fact, is the preferred approach by AWS.

That means that if your organization uses IAM roles, it’s a great day to start your 30-day free trial of ParkMyCloud! Watch the video below to learn how to connect an AWS account to ParkMyCloud using an IAM role:

While IAM roles provide a secure method of key exchange for access into AWS accounts, overall security for the sessions depends heavily upon the policies you put in place. At ParkMyCloud our philosophy has always been to use the “least privilege” approach to security – use the minimum set of permissions required to get the job done, or in this case the role, and no more.

Whether you use IAM roles or IAM user credentials, we recommend a limited set of permissions for the ParkMyCloud application to do its job: ec2:Describe*, ec2:StartInstances, ec2:StopInstances and iam:GetUser. We even provide some example policies, with and without resource tag constraints.

AWS IAM RolesThese types of policies, with the security of IAM roles, provide strong assurance that access to your AWS accounts is limited and secure.

If you’re an existing user, you can also convert existing IAM user credentials into IAM roles, without having to re-discover your environments. This ensures that all your hard work setting up parking schedules and sorting instances to your teams, was not in vain. Read this article to learn how.

For more information, please see the AWS documentation on IAM Roles.


AWS Chicago Summit 2016: Rapid AWS Growth Continues

ParkMyCloud Booth AWS summit chicagoLast week, ParkMyCloud was one of the partner sponsors of the AWS Chicago Summit 2016.

We attended AWS re:Invent last fall (and we’re already looking forward to the 2016 event in December!), but this was ParkMyCloud’s first AWS Summit.

Although the event was substantially smaller than re:Invent, we were pleasantly surprised by the number of people who visited our booth and on the number of meaningful conversations we had with companies across the board, from those just assessing AWS as an option to those with established and growing AWS footprints.

Keynote from Dr. Matt Wood

The event’s keynote was given by Dr. Matt Wood, the General Manager for Product Strategy at AWS. You can watch the entire keynote recording below:

Amazingly, AWS continues to grow quickly at a rate of 70% year-over-year and is now a $10B company. EC2 makes up more than 2/3 of that business, and at last report, was growing at 95% year-over-year.


There were a few announcements of new AWS products in the keynote (full list here).

AWS now uses SSD storage as the default for EBS (Elastic Block Store). SSD is wonderful for small block, random I/O (for example for OLTP databases), but it is not cost-effective for large block sequential workloads, such as video or image processing.

Therefore, AWS announced two new magnetic EBS storage offerings:

  • A throughput optimized EBS offering (ST1) providing up to 500 MB/sec of sequential performance. It costs $0.045 / GB / month.
  • There is also a cold storage version (SC1), providing up to 250 MB/sec, but costing only $0.025 / GB / month.



AWS Inspector also became generally available. Inspector is an automated security and vulnerability assessment. It checks the security posture of your application relative to defined best practices.

AWS also announced non-disruptive, automatic platform (OS) updates for Elastic BeanStalk deployments. This will definitely save time on managing BeanStalk implementations.


They leverage “Blue” / “Green” auto scaling groups behind the load balancer to do this non-disruptively. Blue is the current production environment. Green is the version being updated. Once complete, operation is cutover to “Green”.


AWS announced as beta the ability to create managed identity pools for Cognito. I am intrigued by this and how this, with multi-factor authentication (MFA), would compare with something like SAML 2.0 and MFA.


As usual there were some interesting customer talks. I found the one from Duolingo to be quite interesting. They offer 80 different language courses for free, supporting over 18 million users per month, running 6 billion exercises. Their whole environment is managed by 2 DevOps folks!



Not only is it eye-opening to see the innovations that AWS is continuously releasing into their ecosystem, it’s also great to meet and talk with AWS customers face-to-face and talk shop.