ParkMyCloud Release Notes: Updates to Reporting and Snooze

Over the weekend, we pushed out a new release of ParkMyCloud, with new features focusing on reporting and snooze support. Updates made in this release include:
  • Upgraded reporting, including 4 new reports: detailed costs by instance, cost summary by team, cost summary by credential, and roster of team members by team and by role. These reports can be pulled for any date range you select:
reports
  • Updated the Dashboard, which now shows how much time is left on the snooze period for snoozed instances. The time remaining will display both on the parking menu and in a tooltip, as shown below:

snoozeremaining

snoozeremaining2
  • There is a new default parking schedule called “Always Parked – Snooze to Use Instances”. Several of our customers are successfully using this “always parked” strategy to achieve maximum savings on their non-production instances.
alwaysparked

We also did some very important behind the scenes work to streamline the DevOps process and improve database development.

Coming soon: the ability to park Auto Scaling groups!

As always, we welcome your feedback. If you have any questions, comments, or suggestions for the future, please let us know in the comments below.

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:

newdashboard

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

“Always Parked” Schedule

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

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:

negationlogic

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.

Enjoy!