Are AWS Reserved Instances Better Than On-Demand?

Are AWS Reserved Instances Better Than On-Demand?

AWS Reserved Instances vs. Scheduling On-Demand Instances

We are frequently asked about the impact of instance scheduling on AWS Reserved Instances for EC2 and RDS.  Scheduling On Demand instances as well as Reserved Instances (RIs) are both useful techniques for cost optimization, but they are polar opposites in terms of goals.  RIs are all about getting a better price for RDS or EC2 instances that are running all the time. Scheduling is all about reducing costs by turning off instances when they are not in use.  

How should a customer choose between buying an AWS Reserved Instance and applying scheduling to the instance?  This is an important question, as usually the savings from scheduling can exceed the savings available from a Reserved Instance.  Before we dive into that though, let’s get familiar with some critical RI nuances that can help you make the decision…and make the most of your RIs.

Note: versions of this article were originally published in 2015 and 2017. It has been completely re-analyzed, rewritten, and updated! 

Where are my Reserved Instances?

First of all, it’s worth clarifying that there is no functional difference between Amazon Reserved Instances and On Demand. It’s all in the billing. <rant> I wish I had a dollar for each time someone asked me (while looking at the AWS Console) “Which ones of these are the Reserved Instances?” </rant>. You cannot be sure which instances are using a reservation until you get your bill.  You can make a good guess, based on what account you are looking at and what reservations you have purchased, but if you are using instance size flexibility with region-based RIs, it would be a pure guess.  An instance reservation is not like a hotel reservation, where you end up with a specific room for the duration of your stay. That would be a Dedicated Host Reservation – a whole other beast with its own set of limitations.

3600 Seconds per Hour

Yep – there are 3600 seconds in an hour.  I did the math. You may ask: why does that matter?  It matters because of two things: per-second billing for EC2, and the fact that AWS RIs are billed in one hour chunks.  More precisely, RIs are billed in one “clock-hour” chunks, where a clock-hour starts on the hour and up to the final second of the hour – like 04:00:00 to 04:59:59.

If you are running a number of instances that use per-second billing, and they go up or down during a (clock) hour, then multiple instances may be able to leverage the Reserved Instance pricing.

As paraphrased shamelessly from here, if you purchase one m5.large Reserved Instance and run four matching m5.large instances for 15 minutes each (900 seconds each) in the same hour, the total running time is one hour, which consumes the entire Reserved Instance allocation.  This usage pattern is illustrated below.

That said, if multiple matching instances are running at the same time, the Reserved Instance billing benefit is applied to all of the instances, up to a maximum of 3600 seconds in a clock-hour.  On-demand rates are used for any usage after that. This is illustrated below.

By the way, remember that per-second billing only applies to instances running an open-license OS like Amazon Linux or Ubuntu.  

If your instance is running any flavor of Windows, Red Hat Linux, or any pay-by-the-hour image from the AWS Marketplace, that instance is billed by the hour, and any matching reservation will be consumed by the hour, even if the instance is not.  Any overlapping instances will each need their own RI to get RI pricing.

Elastic Reserved Instances

Wait…what?  Isn’t that kind-of an oxymoron?  Elastic means it should be able to change with my usage…and aren’t reservations are a commitment to usage?  Well, maybe…but some RIs are definitely more elastic (or at least more flexible) than others.  Regional Reserved Instances can leverage “instance size flexibility.”  This is the ability of a reservation to apply up or down to other instance types in the same family.  Regional RIs are applied in priority order from the smallest instance in the region to the largest instance in the region.  This makes these AWS reservations somewhat elastic in that if you buy reservations for smaller instance types than you normally use, then those reservations are more likely to be consumed, even if you rightsize an instance or replace one server with another of a different size.

The math of how an RI of one instance type can be applied to another instance type is governed by a “normalization factor”, described here.  Putting the table in that link another way:

Some examples of how we can use this table:

  • To fully cover one t3.medium with RIs, you would buy eight t3.nano RIs.  If you stop using the t3.medium instance, the same eight t3.nano RIs could also be used to cover:
      • Two t3.small instances
      • One t3.small and two t3.micro
      • Half of a t3.large
  • To fully cover an m5.12xlarge would require 24 m5.large RIs.  Those 24 m5.large RIs could also be used for:
      • One m5.8xlarge and one m5.4xlarge
      • One m5.8xlarge and two m5.2xlarge
      • One m5.8xlarge, one m5.2xlarge, one m5.xlarge, and two m5.large
      • Three quarters of an m5.16xlarge
      • Etc.

The lesson here is that it is easiest to manage reserved instances if you buy the smallest instance size available within an instance family.  In fact, as shown below this is the exact type of recommendation you are likely to receive from the AWS Cost Explorer.

So why do we mention AWS flexible reserved instances with relation to schedules?  Recall that the allocation of RIs to instances is done by AWS each second within a clock-hour.  Each reservation is consumed by instances in its family until all 3600 seconds have been allocated.  You do not necessarily have to keep an instance up for the whole hour to use the reservation. You can still consume the whole RI, even if you are starting and stopping instances by schedule or within an auto-scaling group over the course of an hour.

Something so cool cannot be without limitations and gotchas. Here are a few we’ve noticed:

  • Instance size flexibility is ONLY available for certain instance platforms.
    • For AWS EC2 reserved instances, only open-license linux instances support flexible RIs.  It is NOT APPLICABLE to any flavor of Windows or other licensed software and OS.
    • For AWS RDS reserved instances, instance size flexibility is available for MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines as well as the “Bring your own license” (BYOL) edition of the Oracle. [That said: it is not clear as of this writing if the recent RDS per-second billing change is also applied to RDS instance size flexibility. The billing pages still state that RDS RIs are allocated to instances on a per-hour basis.]
  • Flexibility is only available within the same instance family
  • Flexibility is only available for Regional RIs 

How does AWS Reserved Instance Pricing Work?

As usual, there are a number of different decisions that need to be made before this question can be answered.  AWS RIs are available with two different levels of flexibility and several different terms of purchase. 

In terms of flexibility, RIs can either be purchased as “standard” or “convertible.” 

  • AWS Convertible Reserved Instances – allow changing the assigned availability zone, instance size/families, operating system, tenancy, and networking type. There is no fee for changing the reservation attributes, but you can only convert the RI into a new set of attributes with equal or greater cost than the original.  If the cost is greater, you will have to pay the difference.
  • Standard Reserved Instances – once purchased, cannot be changed. They can be sold on the AWS Reserved Instance Marketplace.

Both AWS Convertible RIs and Standard RIs offer:

  • Regional vs. Availability Zone assignment scope.  Regional scope offers a lot more flexibility for where your instances can reside while still leveraging RI pricing. Availability Zone scope has the bonus of a guaranteed capacity reservation (though, like RI pricing,  capacity reservation cannot be assigned to a specific instance).
  • For open-license Linux, instance size flexibility, as described earlier.

There are a few options for terms of purchase that affect AWS RI pricing. RIs can be purchased for 1 or 3-year terms, and with no upfront, partial upfront, or all upfront payment available for each. 

To get a better idea of the difference in the amount you’ll end up paying with each purchasing option, let’s take a look at some pricing scenarios for the general purpose m5.large instance in us-east-1 (US Virginia).  When you look at these on the AWS RI price list, they are usually grouped by year terms and standard vs. convertible.  Since you can already see it that way on AWS, and because time is the greatest unknown, I am going to give a bit of a different view, keeping the years together on the same comparison chart.

One-Year Term RIs

To  benefit from the discount provided by a  reservation while keeping contract terms to a minimum, look at the 1-year RIs:

You can see from this that within the Convertible vs. Standard tiers, there is not a lot of difference between the upfront cost payment options.  Your upfront cash decision here can depend on your accounting process, perhaps accounting for the difference between CapEx and OpEx (Capital Expenditures and Operating Expenditures), or based on your current and prospective cash flow.  The pricing between the Convertible vs. Standard options are so similar as to make you seriously consider if the benefit of flexibility in the AWS Reserved Instances convertible option outweighs the minor cost savings.

Three-Year Term RIs

If are confident of your three-year usage plans, look at the 3-year RIs, shown here as the cost per year:

There is a bit more visible progression between the options here, and the cost savings difference between the 1-year graph and the 3-year graph are clearly seen.  Still, the 1-year vs. 3-year decision may again come down to accounting practices.

Note that these graphs are just for one instance type in one location in about the middle of the overall performance pack.  They do not express a true profile of all instance types/families in all locations, and you should do your own comparison before buying any RIs.  That said….

AWS Reserved Instances vs. On Demand

Scheduling Break-even

FINALLY getting into the core question.  Is it better to shut an instance down or buy a reserved instance?  Let’s do the math and compare AWS On Demand vs. Reserved, with on/off scheduling applied to the On Demand option.  Given all the different pricing options it can be a bit difficult to decide how to compare these. Let’s go with the no-upfront RI options and see where the RIs break even with scheduling.

AWS On Demand vs. Reserved Instance Purchase Option Comparison

Since the hours might be judge at this scale, here are the break-even hours in a table (hours rounded-up):

So what do these hours mean?  

By way of comparison, here are a few common schedules and their hours in ParkMyCloud (with weeks converted to months on the basis of 52 weeks/12 months = 4.33 weeks/month):

  • Running 8 AM – 5 PM, Weekdays = 195 hours/month (nominally a 73% savings)
  • Running 7 AM – 7 PM, Weekdays = 260 hours/month (64% savings)
  • Running 5 AM – 9 PM, Weekdays = 347 hours/month (53% savings)

Of the above, 7 AM – 7 PM Weekdays is the second most popular schedule in our entire system, and at 260 hours, easily is more cost-effective than the least expensive RI.  

In that final schedule above, you need to run 16 hours per day, Monday-Friday before a 3-year RI starts to look like a better deal.  If you have other matching instances on another schedule in that same region/AZ, you could then buy the RI anyway, and save even more money.

Scheduled Reserved Instances

“But wait!” you say…  “There are these things called Scheduled Reserved Instances – would they not offer me the best of both worlds?”  Maybe, but note that to support Scheduled RIs, AWS has essentially set aside hardware for use as Scheduled RIs – this is a finite set of dedicated resources.  On paper, a Scheduled RI can definitely save you a bit more money, but let’s look at the limitations.  

  • Instances intended to consume a Scheduled Reservation must be launched during their scheduled time periods using a launch configuration that matches the reservation. Let’s break that down further:
      • They are launched with “a launch configuration” and terminated by EC2 three minutes before the end of the schedule window.  You cannot stop/start/suspend them, and so they cannot maintain state internally unless you do some EBS volume tweaks after launch.
      • You cannot launch a scheduled RI outside of its scheduled window.  If you try, that instance will not use the Reservation, as you would not expect it to magically jump over onto the dedicated hardware.
  • Only three regions and only a few older generation instances families are supported.
  • Limited quantities are available (as of this writing, a search for an m4.large in us-east-1 with a Monday-Friday 7 AM – 7 PM scheduled listed only two reservations being available).
  • There is a minimum reservation size of 1,200 hours/year, 100 hours/month, 24 hours/week, or 4 hours/day.  (So you are not going to be able to use a Scheduled RI to run your database backup server for just a couple hours on Sunday mornings [I just tried…dang it.])
  • Scheduled RI purchases cannot be cancelled, modified or sold on the RI Marketplace. No buyer’s remorse allowed here…
  • And finally…  AWS describes the cost savings of Scheduled RIs over on-demand as being in the 5-10% range.  Again – you have to be really sure this workload is going to be needed on this schedule, and the workload is fully utilized.  If you find this server is ever idle or under-utilized, you may have lost an opportunity to save 50% or more by simply scheduling it with ParkMyCloud and then rightsizing it.

When launched in 2016, Scheduled RIs were only available in “US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions, with support for the C3, C4, M4, and R3 instance types.”  Given that this has not changed, I am guessing the feature has not taken off as AWS had hoped.  That said, if you have something that needs to run for 4 hours per day, daily, and can use an older instance family in a supported region…go for it!  This may also be a good place to leverage AWS Spot instance types.

Should You Buy Reserved Instances?

Deciding between different RI options starts with knowledge of how stable your usage is going to be in the coming years.  Most organizations have a good understanding of at least a baseline level of usage, and some actually construct portfolios of reserved instance purchases, much like how you might balance a stock portfolio.  For example, 3-year Standard Reserved Instances are for those applications that are stable and unlikely to change. Balance those with some 3-year Convertible Reserved Instances to help save money in the longer term but allow for some flexibility in use.  Use 1-year RIs to account for shorter-term usage volatility, with again maybe a balance between Standard and Convertible where needed for those loads that might shift over the short term.  

Just like with stocks, such portfolios require active management, awareness of what is being used and what is coming in both the short and long term.  Companies with these types of RI management typically have dedicated cloud cost management staff, though RI management itself does not need to be a full-time job.  One of our larger customers tells us they do a quarterly review of their RI portfolio, starting with using ParkMyCloud to schedule any instances they can, and then rebalancing their RIs and investing in more as needed.  This is a best practice for any size company.

For production workloads that run 24×7 long-term, you REALLY should be buying RIs. For production workloads with an unknown future, or for non-production workloads (dev, test, QA, training, etc.), the answer is “probably not”.  Be careful though, as often RIs are seen as a quick fix to save 30-50% on the cloud bill, but then other ways are found to save even more, and you end up with underutilized RIs. Before you buy a Standard RI, make sure you have evaluated your resources for underutilization and overprovisioning.  Also consider the following cost-saving options:

  • Choose smaller instance sizes – each size down can save 50%. Use ParkMyCloud Rightsizing to first make sure your resources are appropriately sized for their load before committing to an RI purchase. 
  • For open-license Linux instances, buy RIs for smaller instance types in the same instance family in order to leverage instance size flexibility (allows the RIs to more easily be allocated against other resources, even if they are running for short periods of time)
  • Use Spot Instances and Autoscaling when appropriate for short-term/volatile workloads.
  • Schedule on/off times for on-demand instances.  Use ParkMyCloud SmartParking to automatically create schedules for when the resources are not being used, while still giving your staff the flexibility to easily restart them if needed outside the normal hours. Even a generous 7 AM – 7 PM workday schedule will immediately save 65%!

The worst thing one can do is…nothing.  Set aside some time each quarter to review EC2 and RDS instance utilization.  Rightsize and schedule what you can – try a free trial of ParkMyCloud to see how we can help you with that.  After that, anything left running 24×7 is a candidate for an RI.  If you are risk-averse or time-crunched, stick with 1-year convertible RIs to save at least 36% on at least some of your resources.  Then take all that money you saved and put it into other things that will bring greater value to your business.

8 Non-Obvious Benefits of SSO

8 Non-Obvious Benefits of SSO

As an enterprise or organization grows in size, the benefits of SSO grow along with it. Some of these benefits are easy to see, but there are other things that come up as side-effects that might just become your favorite features. If you’re on the fence about going all-in on Single Sign-On, then see if anything here might push you over the edge.

1. Multi-factor Authentication

One of the best ways to secure a user’s account is to make the account not strictly based on a password. Passwords can be hacked, guessed, reused, or written down on a sticky note on the user’s monitor. A huge benefit of SSO is the ease of adding MFA security to the SSO login. By adding a second factor, which is typically a constantly-rotating number or token, you vastly increase the security of the account by eliminating the immediate access of a hacked password. Some organizations even choose to add a third factor, which is typically something you are (like a fingerprint or eye scan) for physical access to a location. Speaking of passwords…

2. Increased Password Complexity

Forcing users to go through an SSO login instead of remembering passwords for each individual application or website means they are much more open to forming complex passwords that rotate frequently. A big complaint about passwords is having to remember a bunch of them without reusing them, so a limitation on the number of passwords means that one password can be much stronger.

3. Easier User Account Deployment

This one might seem obvious to some, but by using an SSO portal for all applications, user provisioning can be greatly accelerated and secured. The IT playbook can be codified within the SSO portal, so a new user in the accounting department can get immediate access to the same applications that the rest of the accounting department has access to. Now, when you get that inevitable surprise hire that no one told you about, you can make it happen and be the hero.

4. Easier User Account Deletion

On the flip side of #3, sometimes the playbook for removing users after they leave the company can be quite convoluted, and there’s always that nagging feeling that you’re forgetting to change a password or remove a login from somewhere. With SSO, you just have one account to disable, which means access is removed quickly and consistently. If your admins were using SSO for administrative access, it also means fewer password changes you have to make on your critical systems.

5. Consistent Audit Logging

Another one of the benefits of SSO is consistent audit logging. Funneling all of a user’s access through the same SSO login means that tracking that user’s activity is easier than ever. In financial and regulated industries, this is a crucial piece of the puzzle, as you can make guarantees about what you are tracking. In the case of a user who is no longer employed by the enterprise, it can make it easier to have your monitoring tools look for such attempts at access (but you know they can’t get in, from point #4!).

6. Quickly Roll Out New Applications

Tell your IT staff that you need to roll out a new application to all users without SSO and you’ll hear groans starting in record time. However, with SSO, rolling out an application is a matter of a few clicks. This means you have plenty of options ranging from a slow rollout to select groups to start all the way to a full deployment within a matter of minutes. This flexibility can really help maximize your user’s productivity, and will make your IT staff happy to put services into play.

7. Simplify the User Experience

If you use a lot of SaaS applications or web apps that require remembering a URL, you’re just asking for your users to need reminders of how to get into them. With an SSO portal, you can make all services and websites show up as clickable items, so users don’t need to remember the quirky spelling of that tool you bought yesterday. Users will love having everything in one place, and you’ll love not having to type anything anymore.

8. Empower Your Users

Speaking of SaaS applications, one of the main blockers for deploying an application to a wider audience is the up-front setup time and effort, which leads to IT and Operations shouldering the load of the work (since they have the access). SSO can accelerate that deployment, which means the users have more power and can directly access the tools they need. Take an example of ParkMyCloud, where instead of users asking IT to turn on their virtual machines and databases, the users can log directly into the ParkMyCloud portal (with limited access) and control the costs of their cloud environments. Users feel empowered, and IT feels relieved.

Don’t Wait To Use SSO

Whether you’ve already got something in place that you’re not fully utilizing, or you’re exploring different providers, the benefits of SSO are numerous. Small companies can quickly make use of single sign-on, while large enterprises might consider it a must-have. Either way, know that your staff and user base will love having it as their main access portal!

AWS Neptune Overview – Amazon’s Graph Database Service

AWS Neptune Overview – Amazon’s Graph Database Service

AWS Neptune is AWS’s managed graph database service, offered to give customers an option to easily build and run applications that work with highly connected datasets. It was first announced at AWS re:Invent 2017, and made generally available in May 2018.

Graph databases like AWS Neptune were created to address the limitations of relational databases, and offer an efficient way to work with complex data. 

What is a graph database?

A graph database is a database optimized to store and process highly connected data – in short, it’s about relationships. The data structure for these databases consists of vertices or nodes, and direct links called edges.

Use cases for such highly-connected data include social networking, restaurant recommendations, retail fraud detection, knowledge graphs, life sciences, and network & IT ops. For a restaurant recommendations use case, for example, you may be interested in the relationships between various users, where those users live, what types of restaurants those users like, where the restaurants are located, what sort of cuisine they serve, and more. With a graph database, you can use the relationships between these data points to provide contextual restaurant recommendations to users.

Details on the AWS Neptune Offering

AWS Neptune Pricing 

The AWS Neptune cost calculation depends on a few factors:

  • On-Demand instance pricing – you’ll need to pay for the compute instances needed for read-write workloads as well as Amazon Neptune replicas. These follow the general pricing for AWS On Demand instances.
  • Database Storage & I/Os – storage is also paid per usage with no upfront commitments. Storage is billed in per GB-month increments and I/Os are billed in per million request increments. 
  • Backup storage – you are charged for the storage associated with your automated database backups and database cluster snapshots. As per usual, increasing the retention period will cost more. 
  • Data transfer – you are charged per GB for data transferred in and out of AWS Neptune.

For this, as with most AWS services, pricing is confusing and difficult to predict. 

AWS Neptune Use Cases

Use cases for the AWS graph database and other similar offerings include:

  • Machine learning, such as intelligent image recognition, speech recognition, intelligent chatbots, and recommendation engines.
  • Social networking
  • Fraud detection – flexibility at scale makes graph databases useful to work with the huge amount of transactional data needed to detect fraud. 
  • Regulatory compliance – ever-more important as HIPPA, GDPR, and other regulations pose strict regulations on the way organizations use data about customers.
  • Knowledge graphs – such as advanced results for keyword searches and complex content searches.Life sciences – graph databases are uniquely suited to store models of disease and gene interactions, protein matterns, chemical compounds, and more. 
  • Network/IT Operations to keep networks secure, including identity and access management, detection of malicious file paths, and more. 
  • Supply chain transparency – graph databases are great for modeling complex supply chains that span the globe. 

Tired of SQL?

If you’re tired of SQL, AWS Neptune may be for you. A graph database is fundamentally different from SQL. There are no tables, columns, or rows – it feels like a NoSQL database. There are only two data types: vertices and edges, both of which have properties stored as key-value pairs.

AWS Neptune is fully managed, which means that database management tasks like hardware provisioning, software patching, setup, configuration, and backups are taken care of for you.

It’s also highly available and shows up in multiple availability zones. This is very similar to Aurora, the relational database from Amazon, in its architecture and availability.

Neptune supports Property Graph and W3C’s RDF. You can use these to build your own web of data sets that you care about, and build networks across the data sets in the way that makes sense for your data, not with arbitrary presets. You can do this using the graph models’ query languages: Apache TinkerPop Gremlin and SPARQL.

AWS Neptune Visualization is not built in natively. However, data can be visualized with Amazon SageMaker Jupyter notebooks, or third-party options like Metaphactory, Tom Sawyer Software, Cambridge Intelligence/Keylines, and Arcade. 

Other Graph Database Options

There’s certainly competition in the market for other graph database solutions. Here are a few that are frequently mentioned. 

AWS Neptune vs. Neo4j

Neo4j is a graph database that has been rated most popular by mindshare and adoption. Version 1.0 was released in February 2010. Unlike AWS Neptune, Neo4j is open source. Neo4j uses the language Cypher, which it originally developed. While there are several languages available in the graph database market, Cypher is widely known by now. 

Neo4j, unlike AWS Neptune, does actually come with graph visualization, which is a huge plus for working with this kind of data, though as mentioned above, there are several ways to visualize your Neptune data.

Other

Other graph databases include: AllegroGraph, AnzoGraph, ArangoDB, DataStax Enterprise Graph, InfiniteGraph, JanusGraph, MarkLogic, Microsoft SQL Server 2017, OpenLink Virtuoso, Oracle Spatial and Graph (part of Oracle Database), OrientDB, RedisGraph, SAP HANA, Sparksee, Sqrrl Enterprise, and Teradata Aster.

AWS Neptune – Getting Started

If you’re interested in the new service, you can check out more about AWS Neptune. As you get started, the AWS Neptune docs are a great resource. Or, check out some AWS Neptune Tutorials on YouTube

Once you’re on board, make sure you have cost control as a priority. ParkMyCloud can now park Neptune databases to ensure you’re only paying for what you’re actually using. Try it out for yourself!

Can Azure Dev/Test Pricing Save You Money?

Can Azure Dev/Test Pricing Save You Money?

Azure Dev/Test pricing is an option that Azure offers to give developers access to the tools that are necessary to support ongoing development and testing in Microsoft Azure services. This, hopefully, should give the user more control of their applications and environments reducing waste. 

Azure Dev/Test Pricing Options

With Azure Dev/Test pricing, three different options are available to users – Individual, Teams (Enterprise Agreement Customers), and another Teams option for those customers that don’t fall under the enterprise agreement. These pricing options are offered solely to active Visual Studio subscribers. We’ll dig in a little deeper to the pricing options and the benefits associated with each one. 

Option 1: Individuals

The individual option is meant to let users explore and get familiar with Azure’s services. As you can imagine, pricing for individuals is a little different than team pricing. Individuals are given the pricing option of monthly Azure credits for those who are subscribed to Visual Studio. If this pricing option is chosen, the individual is given a separate Azure subscription with a monthly credit balance ranging from $50-150.

You get to decide how you use your monthly credit. There are several Azure services that you can put the credit towards. The software included in your Visual Studio subscription can be used on Azure VMs for no additional charges, you pay a reduced rate for the VMs that you run. 

These monthly credits are ideal for personal workloads, but other options are more optimal for team workloads.

Option 2: Teams – Enterprise Agreement Customers

Teams that have an Enterprise Agreement in place have access to low Dev/Test rates for multiple subscriptions. The funds that are on the customer’s Enterprise Agreement will be used – there is no separate payment. A discount is given to customers at this level – all Windows and Windows Server, Virtual Machines, Cloud Services, and more are discounted off normal Enterprise Agreement rates. 

Unlike the option for Individuals, the team’s option for enterprise agreement customers allow end-users to access the application to provide feedback and to run tests – only Visual Studio subscribers can actually use the Azure resources running in this subscription. 

Option 3: Teams – All Other Customers

If a user isn’t an enterprise agreement customer but wants to use Azure for their teams, they would fall under this category. This rate offers a pay-as-you-go Dev/Test pricing option. This pricing option is very appealing because it allows users to quickly get their teams up and running with dev/test environments. Users are only allowed to use these environments for development and testing.  

This is a more flexible and inclusive option, it allows for multiple team members to interact with the resources, it’s not limited to just the account owners. 

Can Azure Dev/Test Save You Money?

All three options allow users to use the software that is included in their Visual Studio subscription for dev/testing. For VMs being run in environments in all three of these options, users are given a discounted price that is based on a Linux VM rate. 

Microsoft Azure users that are looking to save money on their cloud costs may want to use one of these options. These pricing options come with the benefit of no additional Microsoft software charges on Azure Virtual Machines and exclusive dev/test rates on other Azure services. 

Interview with AC3: How MSP Software Choices Save Providers & Clients Time and Money

Interview with AC3: How MSP Software Choices Save Providers & Clients Time and Money

We chatted with Greg Cockburn, Principle Practice Lead for Australia-based managed services provider AC3, about how they selected ParkMyCloud as part of their MSP software portfolio

Great to speak with you, Greg! Can you start out by telling us about AC3 and what you all do? 

Sure. So our go-to-market strategy is about cloud, infrastructure, data, software integration, and cybersecurity management. We can help you on your journey from a consulting phase about a new project, or during a migration into the cloud, all the way through to managing that on an ongoing basis. We provide managed services, cybersecurity expertise, day-to-day operations, cloud infrastructure builds, software development, and everything in between. 

It requires us to really understand the client’s business. For us, it’s really all about enabling technology to solve business problems.

What’s your role at AC3?

My role is Principle Practice Lead, I look after all of the practices which include AWS, Azure, systems integration and management, and two up and coming practices: software and data, and cybersecurity.

How many customers do you all have? 

About a thousand. That’s about a 50/50 split of customers using AWS or Azure, and customers in private cloud. And that’s across both government and private organizations and all sizes. 

Are most of your customers in your general geographical area?

Yes. Most of our customers are Australian or New Zealand based.

So of your customers that are using AWS or Azure, how far are they into their cloud journey? 

It’s a very varied mix. We have everything from mid-sized agencies that have been running WordPress environments and need help with customizations, all the way through to large enterprises and governments. Where they are in their cloud journeys can vary greatly. 

For some, we’re starting with a lift-and-shift and then kind of unraveling some of their workloads to see if we can start making use of native services. For others, there are workloads that we’re looking after or were built that are completely serverless. For example last year we built a completely serverless data lake for New South Wales Spatial Services.

How did you start using ParkMyCloud?

I personally had a particular need to solve a resource scheduling problem, so I checked out some MSP software options for scheduling and then jumped in and used it. ParkMyCloud had a simpler interface compared to some of the other products out there, and got the job done. It was an easy model to understand and consume, and it wasn’t going to cost an arm or leg. I liked that the pricing wasn’t based on percentages or anything complicated. 

And then it kind of just started to snowball from there. We’ve got more and more customers using ParkMyCloud, and we’ve started to integrate it into our monitoring. 

What was the specific use case that got you looking for a solution? 

The customer wanted to be able to manage on and off schedules themselves. We have our own internal process that does some of that, but it wasn’t available to customers – there was no interface they could use to create, apply, or override their own schedules.

One customer was saying to us, look, we need to be able to turn it off potentially days at a time as opposed to just a regular schedule. And then sometimes we might want to be able to have it running all week if we’re doing load testing or vulnerability testing or something like that. 

So we jumped on board with ParkMyCloud and signed this customer as a bit of a proof of concept. They were really happy with everything. They were able to schedule everything, group things together, and it made perfect sense for them from there. 

Now we have many more customers using ParkMyCloud, and have hooks inside our internal monitoring system for ParkMyCloud so we can keep an eye on everything.

Has it saved you or your team any time to hand off the scheduling to the end-users?

Definitely. By being able to give end users control, they’re able to drive how and when they have things and can turn them on and off on an as-needed basis.

Before, one of our engineers would have to understand the problem, talk to the customer, grab those requirements, put it into a ticket, go in and put the scheduling into our system, test it to make sure that it worked, and close that ticket. Now it’s a completely different team that can take care of that – a team that is more customer aligned rather than the support team. They can just spin up a new account for ParkMyCloud. The automation takes care of hooking it into the AWS account with the right roles, etc., and the customer gets an email to get started with and they’re off and away.

Do you have any other feedback about your and your customers’ experience using ParkMyCloud? 

The ParkMyCloud team has been really responsive which helped me integrate the product with Google’s suite for SSO. When we’ve raised suggestions, the team has been responsive supporting those initiatives and we’ve seen some of them come to fruition. 

We also appreciate that the interface is easy to use and the pricing model is simple. It’s just really easy. That was the big key thing for us. There are other solutions and MSP software offerings out there that can do some sort of scheduling. But what tends to happen with these tools is that they end up doing many things and they don’t do them well. Software providers do better when they remember their original core focus and stick to that.

Thanks so much for your time, Greg!

Learn more with the full case study: Managed Services Provider AC3 Automatically Optimizes Customers’ Cloud Environments with ParkMyCloud.

Want tips, tricks, and insights for an optimized cloud?

> No, I like wasting time and money.