AWS Reserved Instances FAQ

This AWS Reserved Instances FAQ is a culmination of questions we are often asked about using Reserved Instances to save on your Amazon Web Services (AWS) costs.

First, let’s make sure you’re all on the same page. AWS Reserved Instances are a way to save money on your cloud bill by reserving capacity in advance, which you can choose to pay for all, some, or no upfront. Due to the different billing model and variety of options, these often raise questions.  Let’s explore a few:

Q1: How do I know which instances are reserved?

Because of how AWS billing works, Reserved Instances aren’t applied until you’re actually being charged for the instances. Think of it more like a “voucher” than a specific virtual machine.

This means that you run your instances as you normally would throughout the month, without seeing which will be billed as reserved vs. on-demand. When your bill comes on the 5th of the next month, AWS will look at your reservations and your usage and automatically apply the reservations that match the instances.

This means that you don’t have to decide which instances are reserved, but it also means you don’t have the visibility into what your true costs are going to be. You’ll have to track this on your own, or use some tools to help you manage your Reserved Instances. AWS has included some reports in the Cost Explorer that can help you visualize your month-to-date usage of your reservations.

Q2: What if I don’t need that instance type anymore?

There’s a couple of options for unused reservations, depending on the reason you aren’t using them anymore. The first option is to sell the reservation on the Reserved Instance Marketplace. This marketplace lets you list your reservation and allows others to purchase it from you. The reservations are grouped together, with the cheapest being sold first in that group. Once someone purchases your reservation, you start getting charged at the on-demand rate (if you still use that type).

The other option is to purchase convertible reservations, which allow you to change the attributes of the reservation (as long as it’s to a more expensive instance type). These convertible types give you much more flexibility, especially as your company or application are growing in use, but they do come with a smaller savings rate over standard Reserved Instances.

Q3: How do Reserved Instances work if I have multiple AWS accounts?

Many users of AWS in large organizations have started using a multi-account strategy, either for security reasons or billing reasons. When managing multiple AWS accounts, billing and reservations can get confusing. The good news is that reservations can “float” across multiple linked accounts, even if they weren’t purchased in the master account. Amazon is smart enough to attempt to apply the reservation to the account it was purchased in, but if a suitable instance is not found, it can apply it to an instance in a different account that matches. You can also choose to exclude linked accounts from receiving these floating reservations if you’d like.

Q4: Are AWS Reserved Instances better than On Demand?

Great question. This is actually the subject of the most popular post on the ParkMyCloud blog. In short: usually yes, but only for production environments. Otherwise, On Demand instances with on/off schedules are typically better value.

Conclusion

Reserved Instances can help save a lot of money on your AWS bill, but require a different way of thinking about your instances than the normal pay-as-you-go that you may be used to with cloud computing. These reservations are typically used for steady-state workloads with consistent usage. Did we miss any of your questions in this AWS Reserved Instances FAQ? Let us know!

Read more ›

Announcing Alibaba Cloud Cost Control with ParkMyCloud

We’re happy to announce that ParkMyCloud now supports Alibaba Cloud!

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) users have saved millions of dollars on their cloud bills using ParkMyCloud’s automated cloud cost optimization platform. Customers like McDonald’s, Sysco, and Unilever use ParkMyCloud to automatically turn off idle cloud resources as part of their DevOps process.

Now, Alibaba Cloud customers can do the same.

Why Alibaba?

Alibaba Cloud is experiencing rapid customer adoption and growth – in the 4th quarter of last year, they saw over 100% growth, with more than 300 products and features launched. The company is clearly expanding their horizons beyond retail and putting a focus on innovation and development in the cloud space – both in China where their core customer base is located, and throughout the world as companies globally choose Alibaba as their primary cloud provider or as part of a multi-cloud strategy.

But the real reason we’re here is to help cloud users solve the enormous problem of cloud waste.

We estimate that Alibaba users will waste $552 million on idle cloud resources this year – that’s $1.5 million per day that could easily be saved with automated cost optimization in place. There’s no time to lose in getting cost control measures in place.

See it In Action

Get a preview of ParkMyCloud – watch this 2-minute demo to see how it works. To see a full demo and get your questions answered, schedule a personalized demo now.

Try Now for Free

You can get started with Alibaba Cloud cost control now with a free 14-day trial of ParkMyCloud, with full access to premium features.

After your trial expires, you can choose to continue using the free tier, or upgrade to use premium features such as SmartParking, full API access, advanced reporting and SSO.

Cheers, and happy parking.

Read more ›

Alibaba Cloud Customers Can Now Reduce Up to $552M in Annual Waste with ParkMyCloud

ParkMyCloud Provides Alibaba Cloud Customers with Continuous Cost Optimization by Turning Off Idle Resources

June 27, 2018 (Dulles, VA) – ParkMyCloud, the leading enterprise platform for continuous cost control in public cloud, announced today that it now provides automated cost optimization and reduction for Alibaba Cloud, the largest public cloud provider in China and a rapidly growing U.S. cloud provider. ParkMyCloud now supports four top cloud providers, with Alibaba joining Amazon Web Services (AWS), Microsoft Azure (Azure), and Google Cloud Platform (GCP).

ParkMyCloud saves money by automatically turning off idle cloud resources, a process it calls “parking”. Customers including McDonald’s, Sysco Foods, and Unilever have integrated cost control into their DevOps processes using ParkMyCloud.

ParkMyCloud estimates that up to $552 million will be wasted on idle Alibaba Cloud resources this year – all of which can be easily saved with ParkMyCloud’s automated optimization and elimination of idle resources.

“ParkMyCloud has had an international customer base from the start, and we look forward to working with companies around the world that choose Alibaba as their primary cloud or as part of their multi-cloud strategy,” said Jay Chapel, ParkMyCloud CEO. “Given their rapid growth – over 100% growth for the 4th quarter, with more than 300 products and features launched – Alibaba is clearly putting a focus on innovation and development in the cloud space. We look forward to helping their customers optimize resource usage as Alibaba Cloud expands internationally.”

ParkMyCloud was founded in 2015 with initial support for AWS. It followed with support for Azure and GCP, while developing capabilities to allow DevOps users to fully automate cloud cost control with innovations such as SmartParking.

About ParkMyCloud

ParkMyCloud is a SaaS platform that automatically identifies and eliminates public cloud resource waste, reducing spending by 65% or more — think “Nest for the cloud.” AWS, Azure, Google Cloud, and Alibaba Cloud users such as McDonald’s, Sysco Foods, Unilever, Avid, and Sage Software have used ParkMyCloud to cut their cloud spending by millions of dollars. ParkMyCloud helps companies like these optimize and govern cloud usage by integrating cost control into their DevOps processes. For more information, visit https://www.parkmycloud.com.

Contact

Katy Stalcup

kstalcup@parkmycloud.com

(571) 334-3291

Read more ›

Interview: Hitachi ID Systems Optimizes Training Infrastructure with ParkMyCloud

Hitachi ID Systems recently reached their first ParkMyCloud birthday – to celebrate, we chatted with Patrick McMaster about how they optimize training infrastructure and why he and his team said “We honestly couldn’t be happier with ParkMyCloud.”

Can you start by telling me about Hitachi ID Systems and what you and your team do within the company?

Hitachi ID Systems makes identity and access management (IAM) software. I am the training coordinator, so I handle getting clients and potential partners up to speed with how our software works, how to install it, how to administrate it, etc. For those who are more interested in learning about software, we set them up with a virtual environment and course materials or an instructor to get them up to speed with how the software works.

Can you describe how you’re using public cloud?

We use AWS exclusively. When we advertise that we’re running a course a few months ahead of time, our infrastructure starts seeing the registrations and will start creating VMs, applying patches, getting the latest version of the appropriate software installers on the desktop and getting everything ready for the students, who will be accessing geographically-local AWS infrastructure.

In the past, everything for this online training was very manual. We on the training team  would spin up the VMs manually, do the updates manually, and send the information to the potential students., Then when the course was over we would go through and do the reverse – shutting the elements down and turning off the virtual machine on AWS.

What does the supporting training infrastructure in AWS look like?

We have a number of VMs running per student or team that only need to be active during the team’s local business hours, plus some additional supporting infrastructure which is required 24/7. We started to realize as we got more students and began offering self-paced training that our AWS fees were increasing from the 24/7 access we were providing, but also just the management of keeping track of which students are where, when they should be brought into the system, when they should be shut down, etc. We needed to find a solution pretty quickly as we experienced that period of rapid growth.

How did that lead you to finding ParkMyCloud?

We knew we needed to automate the manual processes for this. Of course, lots of organizations tend to come up with solutions internally first. We’re a software company, so we had the talent for that, but we never have enough time. I’ve come to terms more and more every year with the benefits of delegating to the other sources. I realized that we are probably not the first organization to have this problem, so I Googled and found ParkMyCloud.

It became quickly evident that the features that you offered were exactly what we were looking for.

Can you describe your experience as a ParkMyCloud user so far?

Sure! So just before our demo of ParkMyCloud, we were fighting with this issue of trying to figure out how we can manage multiple time zones and multiple geographic locations, and not pay for that time that VMs are just spun up.

Then we went through the ParkMyCloud demo process and started our trial. We connected to our system and looked at ways to set up different schedules and pull information from AWS. There was definitely a moment where everyone in the room looked each other and said, “we must be missing something” – there had to be some additional steps we hadn’t thought out because it seemed too easy to work. But it really was that easy.

It just took a week of monitoring to make sure everything was turning off when it was supposed to – the bulk of our effort was really in that first week, and the time we need to spend in the interface is so small. We can go into ParkMyCloud’s dashboard and make exceptions to the schedule when needed, but the time that we actually spend thinking about these things is now about 2 hours a week, whereas before it was something that members of our staff might struggle with for 1-2 days. It’s been a huge improvement.

We did some calculations just in terms of uptime versus what we were doing before, and having the different schedules at our disposal and being able to spend that one week coming up with every scenario we could come up with was time well-spent. Now there are very few exceptions. I don’t think we’ve had to create a new schedule in a long time. Everything is organized logically, it’s very easy for us to find everything we need.

Who is responsible for tracking your AWS spending in the organization? Have they had any feedback?

Our finance department. Since we started using ParkMyCloud, it’s been very very quiet. No news is good news from finance. We are saving about 40% of our bill.

Do you have any other cloud cost savings measures in place?

Not for this training infrastructure. We have a pretty unique use case here. Our next steps are going to be more towards automatic termination, automatic spinning things up, more time-saving measures rather than cost.

This summer ParkMyCloud is working on instance rightsizing, if that’s something that would be helpful for you.

 That’s definitely something that we could use. We are always trying to find better ways of doing things.

OK, great, thanks Patrick! Appreciate your time.

 Thank you, have a good one!

 

Read more ›

4 Types of Idle Cloud Resources That Are Wasting Your Money

We have been talking about idle cloud resources for several years now. Typically, we’re talking about instances purchased On Demand that you’re using for non-production purposes like development, testing, QA, staging, etc. These resources can be “parked” when they’re not being used, such as on nights and weekend, saving 65% or more per resource each month. What we haven’t talked much about is how the problem of idle cloud resources extends beyond just your typical virtual machine.

Why Idle Cloud Resources are a Problem

If you think about it, the problem is pretty straightforward: if a resource is idle, you’re paying your cloud provider for something you’re not actually using. This adds up.

Most non-production resources can be parked about 65% of the time, that is, parked 12 hours per day and all day on weekends (this is confirmed by looking at the resources parked in ParkMyCloud – they’re scheduled to be off just under 65% of the time.) We see that our customers are paying their cloud providers an average list price of $220 per month for their instances. If you’re currently paying $220 per month for an instance and leaving it running all the time, that means you’re wasting $143 per instance per month.

Maybe that doesn’t sound like much. But if that’s the case for 10 instances, you’re wasting $1,430 per month. One hundred instances? You’re up to a bill of $14,300 for time you’re not using. And that’s just a simple micro example. At a macro level that’s literally billions of dollars in wasted cloud spend.

4 Types of Idle Cloud Resources

So what kinds of resources are typically left idle, consuming your budget? Let’s dig into that, looking at the big three cloud providers — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

  • On Demand Instances/VMs – this is the core of the conversation, and what we’ve addressed above. On demand resources – and their associated scale groups – are frequently left running when they’re not being used, especially those used for non-production purposes.
  • Relational Databases – there’s no doubt that databases are frequently left running when not needed as well, in similar circumstances to the On Demand resources. The problem is whether you can park them to cut back on wasted spend. AWS allows you to park certain types of its RDS service, however, you can not park like idle database services in Azure (SQL Database) or GCP (SQL). In this case, you should review your database infrastructure regularly and terminate anything unnecessary – or change to a smaller size if possible.
  • Load Balancers – AWS Elastic Load Balancers (ELB) can not be stopped (or parked), so to avoid getting billed for the time you need to remove it. The same can be said for Azure Load Balancer and GCP Load Balancers. Alerts can be set up in Cloudwatch/Azure Metrics/Google Stackdriver when you have a load balancer with no instances, so be sure to make use of those alerts.
  • Containers – optimizing container use is a project of its own, but there’s no doubt that container services can be a source of waste. In fact, we are evaluating the ability for ParkMyCloud to park container services including ECS and EKS from AWS, ACS and AKS from Azure, and GKE from GCP, and the ability to prune and park the underlying hosts. In the meantime, you’ll want to regularly review the usage of your containers and the utilization of the infrastructure, especially in non-production environments.

Cloud waste is a billion-dollar problem facing businesses today. Make sure you’re turning off idle cloud resources in your environment, by parking those that can be stopped and eliminating those that can’t, to do your part in optimizing cloud spend.

Read more ›

4 Orphaned Cloud Resources Eating Away at Your AWS Budget – and How to Avoid Them

We recently discussed how orphaned volumes and snapshots contribute to cloud waste and what you can do about it, but those are just two examples of orphaned cloud resources that result in unnecessary charges. The public cloud is a pay-as-you-go utility, requiring full visibility of specific infrastructure – you don’t want to be charged for resources you aren’t using. Here are other types of orphaned cloud resources that contribute to cloud waste (and cost you money):

Unassociated Elastic IPs  

Elastic IPs are reserved public IP addresses designed for dynamic cloud computing in AWS. As a static IPv4 address associated with your AWS account, Elastic IPs can continue running an EC2 instance, even if it is stopped and restarted, by quickly remapping the address to another one of your instances. You can allocate an Elastic IP address to any EC2 instance in a given region, until you decide to release it.  

The advantage of having an Elastic IP (EIP) is the ability to mask the failure of an EC2 instance, but if you do not associate the address to your account – you’re still getting charged. To avoid incurring a needless hourly charge from AWS, remember to release any unassociated IPs you no longer need.

Elastic Load Balancers (with no instances)

Cloud load balancing allows users to distribute workloads and traffic with the benefit of the cloud’s scalability. All major cloud providers offer some type of load balancing – AWS users can balance workloads and distribute traffic among EC2 instances with its Elastic Load Balancer, Google Cloud can distribute traffic between VM instances with Google Cloud Load Balancing, and Azure’s Load Balancer distributes traffic across multiple data centers.   

An AWS Elastic Load Balancer (ELB) will incur charges to your bill as long as it’s configured with your account. Like with Elastic IPs, whether you’re using it or not – you’re paying. If you have no instances associated with your ELB, delete to avoid paying needless charges on your monthly bill.   

Unused Machine Images (AMIs)

A Machine Image provides the information required to launch an instance, which is a virtual server in the cloud. In AWS they’re called AMIs, in Azure they’re Managed Images, and in Google Cloud Platform they’re Custom Images.

As part of your measures to reduce unnecessary costs from orphaned volumes, delete unused machine images when you no longer need them. Unless deleted, the snapshot that was created when the image was first created will continue to incur storage costs.

Object Storage

One of the growing pains that organizations face is the management of isolated pools of data in their cloud environment. Fragmented storage can result from data coming from a number of sources used by applications and business processes. Object Storage was designed to break down silos into scalable, cost-effective storage to store data in its native format. AWS offers object storage solutions like Amazon S3 and Amazon Glacier, Google has Google Cloud Storage, and Azure calls its solution Azure Blob Storage. All options help you manage your storage in one place, keeping your data organized and your business more cost effective.  

Although object storage in and of itself is a cost effective solution, there are still ways to optimize and reduce costs within this solution. Delete files you no longer need so that you’re not paying for them. Delete unused files which can be recreated. In S3, use the “lifecycle” feature to delete or overwrite older versions of data. Clean up incomplete uploads that were interrupted, resulting in partial objects that are taking up needless space. And compress your data before storing to give you better performance and reduce your storage requirements.

How to Avoid Wasted Spend on Orphaned Cloud Resources

Don’t let forgotten resources waste money on your cloud bill. Put a stop to cloud waste by eliminating orphaned cloud resources and inactive storage, saving space, time, and money in the process. Remember to:

  • Release unassociated IPs you no longer need.
  • Remove Elastic Load Balancers with no instances attached.
  • Delete unused machine images when you no longer need them.
  • Keep object storage minimal – optimize by “cleaning up” regularly, removing files you don’t need.

The premise of the cloud and the resources available to you were meant to be cost effective, but it’s up to you keep costs in check. Optimize your cloud spend with visibility, management, and cost automation tools like ParkMyCloud to get the most out of your cloud environment.  

Read more ›

How to Keep Costs in Check After Converting a Monolith to Microservices

You’ve gone full-blown DevOps, drank the Agile Kool-Aid, cloudified everything, and turned your monolith to microservices — so why have all of your old monolith costs turned into even bigger microservices costs? There are a few common reasons this happens, and some straightforward first steps to get microservices cost control in place.

Why Monolith to Microservices Drives Costs Up

As companies and departments adapt to modern software development processes and utilize the latest technologies, they assume they’re saving money – or forget to think about it altogether. Smaller applications and services should come with more savings opportunities, but complexity and rapidly-evolving environments can actually make the costs skyrocket. Sometimes, it’s happening right under your nose, but the costs are so hard to compile that you don’t even know it’s happening until it’s too late.

The same thing that makes microservices attractive — smaller pieces of infrastructure that can work independently from each other — can also be the main reason that costs spiral out of control. Isolated systems, with their own costs, maintenance, upgrades, and underlying architecture, can each look cheaper than the monolithic system you were running before, but can skyrocket in cost when aggregated.

How to Control Microservices Costs

If your microservices costs are already out of control, there are a few easy first steps to reining them in.

Keep It Simple

As with many new trends, there is a tendency to jump right in and switch everything to the new hotness. Having a drastic cutover, while scrapping all of your old code, can be refreshing and damaging all at the same time. It makes it hard to keep track of everything, so costs can run rampant while you and your team are struggling just to comprehend what pieces are where. By keeping some of what you already have, but slowly creating new functionality in a microservices model, you can maintain a baseline while focusing on costs and infrastructure of your new code.

The other way to keep it simple is to keep each microservice extremely limited in scope. If a microservice does just one thing, without a bunch of bells and whistles, it’s much easier to see if costs are rising and make the infrastructure match the use case. Additional opportunities for using PaaS or picking a cloud provider that fits your needs can really help maximize utilization.

Scalability and Bursting

Microservices architectures, by the very nature of their design, allow you to optimize individual pieces to minimize bottlenecks. This optimization can also include cost optimization of individual components, even to the point of having idle pieces turned completely off until they are needed. Other pieces might be on, but scaled down to the bare minimum, then rapidly scale out when demand runs high. A fluctuating architecture sounds complex, but can really help keep costs down when load is low.

User Governance

Along with a microservices architecture, you may start having certain users and departments be responsible for just a piece of the system. With that in mind, cloud providers and platform tools can help you separate users to only access the systems and infrastructure they are working on so they can focus on the operation (and costs) of that piece. This allows you to give individual users the role that is necessary for minimal access controls, while still allowing them to get their jobs done.

Ordered Start/Stop and Automation with ParkMyCloud

ParkMyCloud is all about cost control, so we’ve started putting together a cost-savings plan for our customers who are moving from monolith to microservices.

First, they should use ParkMyCloud’s Logical Groups to put multiple instances and databases into a single entity with an ordered list. This way, your users do not have to remember multiple servers to start for their application – instead, they can start one group with a single click. This can help eliminate the support tickets that are due to parts of the system not running.

Additionally, use Logical Groups to set start delays and stop delays between nodes of the group. With delays, ParkMyCloud will know to start database A, then wait 10 minutes before starting instance B, to ensure the database is up and ready to accept connections. Similarly, you can make sure other microservices are shut down before finally shutting down the database.

Everything you can do in the ParkMyCloud user interface can also be done through the ParkMyCloud REST API. This means that you can temporarily override schedules, toggle instances to turn off or on, or change team memberships programmatically. In a microservices setup, you might have certain pieces that are idle for large portions of the day. With the ParkMyCloud API, you could have those nodes turned off on a schedule to save money, then have a separate microservice call the API to turn the node on when it’s needed.

The Goal: Continuous Cost Control

Moving from monolith to microservices can be a huge factor in a successful software development practice. Don’t let cost be a limiting factor – practice continuous cost control, no matter what architecture you choose. By putting a few costs control measures in place with ParkMyCloud, along with some automation and user management, you can make sure your new applications are not only modern, but also cost-effective.

Read more ›

Sabre Chose Multi-Cloud for Cost Control – But They Need to Get it Right

Travel technology company Sabre announced a strategic agreement with Microsoft last week, weeks after a similar agreement with AWS. There are a lot of factors contributing to these decisions, but among them, it seems likely they’ve chosen multi-cloud for cost control.

The company has been under the leadership of CEO Sean Menke for a year and a half, and in that time has already downsized its workforce by 10% – saving the company $110 million in annual costs. Against such a backdrop, clearly, cost control will be front of mind.

So how will a multi-cloud strategy contribute to controlling costs as Sabre aims to “reimagine the business of travel”, in their words?

Why Multi-Cloud for Cost Control Makes Sense

As Sabre moves into AWS and Azure, they plan to write new applications with a microservices architecture deployed on Docker containers. Containerization can be an effective cost-saving strategy by reducing the amount of infrastructure needed – and thereby reducing wasted spend, and simplifying software delivery processes to increase productivity and reduce maintenance.

Plus, containerization has the advantage of ease of portability. With a large and public account like Sabre’s, this becomes a cost reduction strategy as AWS and Azure are forced into competition for their business against each other. “We want to have incentives for (cloud providers) not to take our business for granted,” said CIO Joe DiFonzo.

Avoiding vendor lock-in and optimizing workloads are the top two cited reasons for companies to choose a multi-cloud strategy – both of which contribute to cost control.

Either Way, Cost Has to Be a Factor

Aside from the reasons listed above, Sabre may have chosen to make deals with both AWS and Azure due to each cloud providers’ technological strengths, support offerings, developer familiarity, or for other reasons. Whether they’ve chose multi-cloud for cost control as the primary reason is debatable, but they certainly need to control costs now that they’re there.

First of all, most cloud migrations go over budget – not to mention that 62% of first-attempt cloud migrations take longer than expected or fail outright, wasting money directly and through opportunity cost.

Second, Sabre’s legacy system of local, on-premises infrastructure means their IT and development staff is used to the idea of resources that are always available. Users need to be re-educated to learn a “cloud as utility” mindset – as a Director of Infrastructure of Avid put it, users need to learn “that there’s a direct monetary impact for every hour that an idle instance is running.” Of course, this is an issue we see every day.

For companies new to the cloud, we recommend providing training and guidelines to IT Ops, DevOps and Development teams about proper use of cloud infrastructure. This should include:

  • Clear governance structures – what users can make infrastructure purchases? How are these purchases controlled?
  • Turning resources off when not needed – automating non-production resources to turn off when not needed can reduce the cost of those resources by 65% or more (happy to help, Joe DiFonzo!)
  • Regular infrastructure reviews – especially as companies get started in the cloud, it’s easy to waste money on orphaned resources, oversized resources, and resources you no longer need. We recommend regular reviews of all infrastructure to ensure every unused item is caught and eliminated.

Cheers to you, Sabre, and best of luck in your cloud journey.

Read more ›

AWS vs Alibaba Cloud Pricing: A Comparison of Compute Options

More cloud users are starting to investigate Alibaba Cloud, so the time is ripe for a comparison of AWS vs Alibaba Cloud pricing. Commonly recognized as the #4 cloud provider (from a revenue perspective anyway), Alibaba is one of the fastest growing companies in the space today.

Alibaba has been getting a lot of attention lately, given its rapid growth, and its opportunities for cloud deployments within mainland China. ParkMyCloud is preparing to release support for Alibaba, and that of course has let us focus on pricing and cost savings – our forte. In this article I am going to dive a bit into the pricing of the Alibaba Elastic Compute Service (ECS), and compare it with that of the AWS EC2 service.

Alibaba vs Aliyun

Finding actual pricing for comparison purposes can be a bit complicated, as the prices are listed in a couple different places and do not quite exactly match up. If one searches for Alibaba pricing, one ends up here, which I am going to call the “Alibaba Cloud” site. However, when you actually get an account and want to purchase an instance, you can up here or here, both of which I will call the “Aliyun” site. [Note that you may not be able to see the Aliyun sites without signing up for an account and actually logging-in.]  

Aliyun (literally translated “Ali Cloud”) was the original name of the company, and the name was changed to Alibaba Cloud in July 2017. Unsurprisingly, the Aliyun name has stuck around on the actual operational guts of the company, reflecting that it is probably hard-coded all over the place, both internally and externally with customers. (Supernor’s 3rd Conjecture: Engineering can never keep up with Marketing.)

Both sites show that like the other major cloud providers, Alibaba’s pricing model includes a Pay-As-You-Go (PAYG) offering, with per-second billing. Note, however, that in order to save money on stopped instances, one must specifically enable a “No fees for stopped instances” feature. Luckily, this is a global one-time setting for instances operating under a VPC, and you can set it and forget it. Unlike AWS, this feature is not available for any instances with local disks (this and other aspects of the description lead me to believe that Alibaba instances tend to be “sticky” to the underlying hardware instance). On AWS, local disks are described as ephemeral, and are simply deallocated when they are not in use. Like AWS, system/data disks continue to accrue costs even when an instance is stopped.

Both sites also show that Alibaba also has a one-month prepaid Subscription model. Based on a review of the pricing listed for the us-east-1 region on the Alibaba Cloud site, the monthly subscription discount reflects a substantial 30-60% discount compared to the cost of a PAYG instance that is left up for a full month. For a non-production environment that may only need to be up during normal business hours (say, 9 hours per day, weekdays only), one can easily see that it may be more cost-effective to go with the PAYG pricing, and use the ParkMyCloud service to shut the instances down during off-hours, saving 73%.

But this is where the similarities between the sites end. For actual pricing, instance availability, and even the actual instance types, one really needs to dive into a live Alibaba account. In particular, if PAYG is your preference, note that the Alibaba public site appears to have PAYG pricing listed for all of their available instance types, which is not consistent with what I found in the actual purchasing console.

Low-End Instance Types – “Entry Level” and “Basic”

The Alibaba Cloud site breaks down the instance types into “Entry Level” and “Enterprise”, listing numerous instance types under both categories. All of the Entry Level instance types are described as “Shared Performance”, which appears to mean the underlying hardware resources are shared amongst multiple instances in a potentially unpredictable way, or as described by Alibaba: “Their computing performance may be unstable, but the cost is relatively low” – an entertaining description to say the least. I did find these instance types on the internal purchasing site, but did not delve any further with them, as they do not offer a point of reference for our AWS vs. Alibaba Cloud pricing comparison. They may be an interesting path for additional investigation for non-production instance types where unstable computing performance may be OK in exchange for a lower price.

That said…after logging in to the Alibaba management console, reaching the Aliyun side of the website, there is no mention of Entry Level vs Enterprise. Instead we see the top-level options of “Basic Purchase” vs “Advanced Purchase”. Under Basic Purchase, there are four “t5” instance types. The t5 types appear to directly correspond to the first four AWS t2 instance types, in terms of building up CPU credits.

These four instance types do not appear to support the PAYG pricing model. Pricing is only offered on a monthly subscription basis. A 1-year purchase plan is also offered, but the math shows this is just the monthly price x12. It is important to note that the Aliyun site itself has issues, as it lists the t5 instance types in all of the Alibaba regions, but I was unable to purchase any of them in the us-east-1 region – “The configuration for the instance you are creating is currently not supported in this zone.”  (A purchase in us-west-1, slightly more expensive, was fine).

The following shows a price comparison for Alibaba vs AWS for “t” instance prices in a number of regions. The AWS prices reflect the hourly PAYG pricing, multiplied by an average 730 hour month. I was not able to get pricing for any AWS China region, so the Alibaba pricing is provided for reference.

While the AWS prices are higher, the AWS instances are PAYG, and thus could be stopped when not being used, common for t2 instances used in a dev-test environment, and potentially saving over 73%. One can easily see that this kind of savings is needed to compete with the comparatively low Alibaba prices. I do have to wonder what is up with that Windows pricing in China….does Microsoft know about this??

Aliyun “Advanced Purchase”

Looking at the “Advanced” side of the Aliyun purchasing site, we get a lot more options, including Pay-As-You-Go instances. To keep the comparison simple, I am going to limit the scope here to a couple of instance types, trying to compare a couple m5 and i3 instances with their Alibaba equivalents. I will list PAYG pricing where offered.

In this table, the listed monthly AWS prices reflect the hourly pay-as-you-go price, multiplied by an average 730 hour month.

The italicized/grey numbers under Alibaba indicate PAYG numbers that had to be pulled from the public-facing website, as the instance type was not available for PAYG purchase on the internal site. From a review of the various options on the internal Aliyun site, it appears the PAYG option is not actually offered for very many standalone instance types on Alibaba…

The main reason I pulled in the PAYG prices from the second source was for auto scaling, which is normally charged at PAYG prices. In Alibaba, “all ECS instances that Auto Scaling automatically creates, or manually adds, to a scaling group will be charged according to their instance types. Note that you will still be charged for Pay-As-You-Go instances even after you stop them.”  It is possible, however, to manually add subscription-based instances to an auto scaling group, and configure them to be not removed when the group scales-down.

In general, the full price of the AWS Linux instances over a month is 22-35% higher that of an Alibaba 1-month subscription. A full price AWS Windows instance over a month is 9-25%  higher than that of an Alibaba subscription. (And once again, it appears Windows licensing fees are not a factor in China.)

AWS vs Alibaba Cloud Pricing: Alibaba is cheaper, but…

Alibaba definitely comes out as less expensive in this AWS vs Alibaba cloud pricing comparison – the one-month subscription has a definite impact. However, for longer-lived instances, AWS Reserved Instances will certainly be less expensive, running about 40-75% less expensive than AWS PAYG, and thus less than some if not all of the Alibaba monthly subscriptions. AWS RI’s are also more easily applicable to auto scaling groups than a monthly subscription instance.

For non-production instances that can be shut down when not in use, PAYG is less expensive for both cloud providers, where ParkMyCloud can help you schedule the downtime. The difficulty with Alibaba will actually be finding instances types that can actually be purchased with the PAYG option.

Read more ›
Copyright © ParkMyCloud 2016-2018. All rights reserved|Privacy Policy