AWS vs Azure vs Google Cloud Market Share 2019: What the Latest Data Shows

AWS vs Azure vs Google Cloud Market Share 2019: What the Latest Data Shows

Q1 earnings are in for the ‘big three’ cloud providers and you know what that means – it’s time for an AWS vs Azure vs Google Cloud market share comparison. Let’s take a look at all three providers side-by-side to see where they stand.

Note: a version of this post was originally published in April 2018. It has been completely rewritten and updated for 2019.

AWS vs. Azure vs. Google Cloud Earnings

To get a sense of the AWS vs Azure vs Google Cloud market share breakdown, let’s take a look at what each cloud provider’s reports shared.

AWS

Amazon reported Amazon Web Services (AWS) sales of $7.7 billion, compared to $5.44 billion at this time last year. AWS revenue grew 41% in the first quarter – at this time last year, that number was 49%.

Across the business, Amazon’s growth rates are slowing down – which perhaps is all that can be expected at their mammoth size. However, their profit margins are increasing, giving investors a boon of $7.09 earnings per share compared to the projected $4.72.

AWS has been a huge contributor to this growth. This quarter, AWS revenue makes up 13% of total Amazon sales, up from 10% in the fourth quarter. AWS only continues to grow, and bolster the retail giant time after time.

In media commentary, AWS’s numbers seem to speak for themselves:

Azure

While Amazon breaks out revenue from AWS separately, Microsoft has a more nebulous “commercial cloud business” – which includes not only Azure, but Office 365, Dynamics 365, and other segments of the Productivity and Business Processes Division. This fact frustrates many pundits as it simply can’t be compared directly to AWS, and inevitably raises eyebrows about how Azure is really doing. Microsoft reported that the commercial cloud business grew 41% in the first three months of 2019, to $9.6 billion.

What Microsoft reported for Azure specifically is the growth rate: 73%. However, Microsoft did not specify what that growth actually represents. This time last year, the Azure growth rate was reported at 93%. Supposedly, analysts say that Azure is growing at a faster rate than AWS was at a similar size, but without specific numbers, it’s hard to say what this actually means.

Here are a few headlines on Microsoft’s reporting that caught our attention:

Google Cloud

Like Microsoft, Google avoided reporting specific revenue numbers for its cloud business yet again. Parent company Alphabet reported $36.34 billion in revenue for the quarter, up 17% from $31.15 billion for the same quarter last year. Google Cloud Platform revenue is included in Google’s “other” revenue category, alongside G Suite, Google Play, and hardware such as Nest. That category reported revenue of $5.45 billion for the quarter, up 25% from the same quarter last year when it was $4.25 billion.

According to Google and Alphabet CFO Ruth Porat, “Google Cloud Platform remains one of the fastest growing businesses in Alphabet with strong customer momentum reflected in particular in demand for our compute and data analytics products”. But without specifics, it’s hard to say what this means.

Further reading on Google’s quarterly reporting:

2018 vs. 2019 Market Share

When we originally published this blog last year, we included a market share breakdown from analyst Canalys, which reported AWS in the lead owning about a third of the market, Microsoft in second with about 15 percent, and Google sitting around 5 percent.

This year they report an overall growth in the cloud infrastructure market of 42%. By provider, AWS had the biggest sales gain with a $2.3 billion YOY increase, but Canalys reports Azure and Google Cloud with bigger percentage increases.

AWS vs Azure vs Google Cloud Market Share – And the winner is:

Ultimately, it seems clear that in the case of AWS vs Azure vs Google Cloud market share – AWS still has the lead.

Bezos has said, “AWS had the unusual advantage of a seven-year head start before facing like-minded competition. As a result, the AWS services are by far the most evolved and most functionality-rich.”

Our anecdotal experience talking to cloud customers often finds that true, and it says something that Microsoft and Google aren’t breaking down their cloud numbers just yet.

Others have made their own estimates. In November, a Goldman Sachs report stated that AWS, Azure, Google Cloud, and Alibaba Cloud made up 56% of the total cloud market, with that projected to grow to 84% this year. The report shows AWS far, far in the lead with 47% of the market projected for this year, with Azure and Google trailing at 22% and 8% market share, respectively.

AWS remains far in the lead for now. With that said, it will be interesting to see how the actual numbers play out, especially as Google positions itself for multi-cloud and Azure continues rapid growth rates. Perhaps this time next year will report revenue numbers broken out and we’ll be able to say for sure.

Azure Low Priority VMs for Cost Savings

Azure Low Priority VMs for Cost Savings

Among the many ways to purchase and consume Azure resources are Azure low priority VMs. These virtual machines are compute instances allocated from spare capacity, offered at a highly discounted rate compared to “on demand” VMs. This means they can be a great option for cost savings – for the right workloads. And we love cost savings! Here’s what you need to know about this purchasing option.

How Azure Low Priority VMs Work

The great part about these virtual machines is the price: it’s quite attractive with a fixed discount of 60-80% compared to on-demand. The “low priority” part means that these VMs can be “evicted” for higher priority jobs, which makes them suitable for fault-tolerant applications such as batch processing, rendering, testing, some dev/test workloads, containerized applications, etc.

Low priority VMs are available through Azure Batch and VM scale sets. Through Azure Batch, you can run jobs and tasks across compute pools called “batch pools”. Since batch jobs consist of discrete tasks run using multiple VMs, they are a good fit to take advantage of low priority VMs.

On the other hand, VM scale sets scale up to meet demand, and when used with low priority VMs, will only allocate when capacity is available. To deploy low priority VMs on scale sets, you can use the Azure portal, Azure CLI, Azure PowerShell, or Azure Resource Manager templates.

When it comes to eviction, you have two policy options to choose between:

  • Stop/Deallocate (default) – when evicted, the VM is deallocated, but you keep (and pay for) underlying disks. This is ideal for cases where the state is stored on disks.
  • Delete – when evicted, the VM and underlying disks are deleted. This is the recommended option for auto scaling because deallocated instances are counted against your capacity count on the scale set.

Azure Low Priority VMs vs. AWS Spot Instances

So are low priority VMs the same as AWS Spot Instances? In some ways, yes: both options allow you to purchase excess capacity at a discounted rate.

However, there are a few key differences between these options:

  • Fixed vs. variable pricing – AWS spot instances have variable pricing while Azure low priority VMs have a fixed price as listed on the website
  • Integration & flexibility – AWS’s offering is better integrated into their general environment, while Azure offers limited options for low priority VMs (for example, you can’t launch a single instance) with limited integration to other Azure services.
  • Visibility – AWS has broad availability of spot instances as well as a Spot Instance Advisor to help users predict availability and interruptibility. On the other hand, Azure has lower visibility into the available capacity, so it’s hard to predict if/when your workloads will run.

Should You Use Azure Low Priority VMs?

If you have fault-tolerant batch processing jobs, then yes, low priority VMs are worth a try to see if they work well for you. If you’ve used these VMs, we’re curious to hear your feedback. Have you had issues with availability? Does the lack of integrations cause any problems for you? Are you happy with the cost savings you’re getting? Let us know in the comments below.

Related reading:

AWS New Services 2019 – What’s in Preview?

AWS New Services 2019 – What’s in Preview?

As the cloud giant, Amazon Web Services (AWS) is constantly innovating – it’s no surprise that at any given time, there’s a list of AWS new services that will soon be released. We’ve put together a list of AWS new services that are currently in “preview” and are expected to be released later this year. Many of these were announced at AWS re:Invent 2018.

Interested in a list of all the services AWS offers? We actually just put that together too. See all 170 services here: AWS Services List.

AWS New Services 2019

This list is broken down by category, including Analytics, Blockchain, Compute, Database, Internet of Things, Machine Learning, and Security. While all are in preview right now, their release dates may vary.

Analytics

AWS Lake Formation

    • AWS Lake Formation makes it easy to set up a secure data lake in days.
    • Lake Formation collects and catalogs data from databases and object storage, moves the data into your new Amazon S3 data lake, cleans and classifies data using machine learning algorithms, and secures access to your sensitive data.
    • Benefits: build data lakes quickly, simplify security management, and make self-service access to data both easy and secure
    • Announced: November 2018 (at re:Invent)

Blockchain

Amazon Managed Blockchain

    • Amazon Managed Blockchain makes it easy to create and manage scalable blockchain networks
    • Fully managed
    • Automatically scales to meet the demands of thousands of applications running millions of transactions. Manages your certificates, lets you easily invite new members to join the network, and tracks operational metrics such as usage of compute, memory, and storage resources.
    • Can replicate an immutable copy of your blockchain network activity into Amazon Quantum Ledger Database (QLDB), a fully managed ledger database so you can easily analyze the network activity outside the network and gain insights into trends.
    • Announced: November 2018 (at re:Invent)

Amazon Quantum Ledger Database (QLDB)

    • Amazon QLDB is a ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log ‎owned by a central trusted authority
    • Tracks each and every application data change and maintains a complete and verifiable history of changes over time
    • Benefits: immutable and transparent, cryptographically verifiable, highly scalable, serverless, easy to use.
    • Announced: November 2018 (at re:Invent)

Compute

AWS Outposts

    • AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
    • Use the same APIs, same tools, same hardware, and same functionality across on-premises and the cloud to deliver a truly consistent hybrid experience.
    • Outposts can be used to support workloads that need to remain on-premises due to low latency or local data processing needs.
    • AWS Outposts come in two variants:
      • 1) VMware Cloud on AWS Outposts allows you to use the same VMware control plane and APIs you use to run your infrastructure
      • 2) AWS native variant of AWS Outposts allows you to use the same exact APIs and control plane you use to run in the AWS cloud, but on-premises.
    • Announced: November 2018 (at re:Invent)

Database

Amazon RDS on VMware

    • Amazon RDS on VMware lets you deploy managed databases in on-premises VMware environments
    • Provides cost-efficient and resizable capacity while automating time-consuming administration tasks including hardware provisioning, database setup, patching, and backups.
    • Allows you to utilize the same simple interface for managing databases in on-premises VMware environments as you would use in AWS. You can easily replicate RDS on VMware databases to RDS instances in AWS, enabling low-cost hybrid deployments for disaster recovery, read replica bursting, and optional long-term backup retention in Amazon Simple Storage Service (S3).
    • Announced: November 2018 (at re:Invent)

Internet of Things

AWS IoT Events

    • AWS IoT events is a fully managed IoT service that makes it easy to detect and respond to events from IoT sensors and applications
    • Continuously monitors data from multiple IoT sensors and applications, and it integrates with other services, to enable early detection and unique insights into events.
    • Benefits: easily ingest operations data, trigger a range of actions, easily build rules.
    • Announced: November 2018 (at re:Invent)

AWS IoT SiteWise

    • AWS IoT SiteWise is a managed service that makes it easy to collect and organize data from industrial equipment at scale.
    • Provides software running on a gateway that resides in your facilities and automates the process of collecting and organizing industrial equipment data.
    • Benefits: monitor operations across facilities, quickly compute common industrial performance metrics, and build applications to analyze industrial equipment data, prevent costly equipment issues, and reduce production inefficiencies.
    • Announced: November 2018 (at re:Invent)

AWS IoT Things Graph

    • AWS IoT Things Graph is a service that makes it easy to visually connect different devices and web services to build IoT applications.
    • Provides a visual drag-and-drop interface for connecting and coordinating devices and web services, so you can build IoT applications quickly.
    • You can get started with AWS IoT Things Graph using these pre-built models for popular device types, such as switches and programmable logic controllers (PLCs), or create your own custom model using a GraphQL-based schema modeling language, and deploy your IoT application to AWS IoT Greengrass-enabled devices such as cameras, cable set-top boxes, or robotic arms in just a few clicks
    • Announced: November 2018 (at re:Invent)

Machine Learning

Amazon Personalize

    • Amazon Personalize is a machine learning service that makes it easy for developers to create individualized recommendations for customers using their applications.
    • Allows developers with no prior machine learning experience to easily build sophisticated personalization capabilities into their applications, using machine learning technology perfected from years of use on Amazon.com.
    • Amazon Personalize will process and examine the data, identify what is meaningful, select the right algorithms, and train and optimize a personalization model that is customized for your data. You provide an activity stream from your application – page views, signups, purchases, and so forth – as well as an inventory of the items you want to recommend, such as articles, products, videos, or music.
    • Announced: November 2018 (at re:Invent)

Amazon Forecast

    • Amazon Forecast is a fully managed service that uses machine learning to deliver highly accurate forecasts, based on the same technology used at Amazon.com.
    • Uses machine learning to combine time series data with additional variables to build forecasts.
    • Requires no machine learning experience to get started.
    • Announced: November 2018 (at re:Invent)

Amazon Textract

    • Amazon Textract is a service that automatically extracts text and data from scanned documents. It goes beyond simple optical character recognition (OCR) to also identify the contents of fields in forms and information stored in tables.
    • Using machine learning to instantly “read” virtually any type of document to accurately extract text and data without the need for any manual effort or custom code.
    • Benefits: extract data quickly and accurately, no code or templates to maintain, lower document processing costs.
    • Announced: November 2018 (at re:Invent)

AWS DeepRacer

    • AWS DeepRacer is the first autonomous scale car specifically developed to help developers get hands-on with reinforcement learning.
    • Gives developers a simple way to learn RL, experiment with new RL algorithms and simulation-to-real domain transfer methods, and experience RL in the real world.
    • Participate in the AWS DeepRacer League at in-person events throughout the globe.
    • Announced: November 2018 (at re:Invent)

Security, Identity & Compliance

AWS Security Hub

    • AWS Security Hub gives you a comprehensive view of your high-priority security alerts and compliance status across AWS accounts.
    • Offers a single place that aggregates, organizes, and prioritizes your security alerts, or findings, from multiple AWS services, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie, as well as from AWS Partner solutions.
    • Announced: November 2018 (at re:Invent)

Trends in AWS New Services

Looking at these new services as a sample group, there are a few trends in the emerging technology. To no one’s surprise, there are a few blockchain and IoT announcements, both of which continue to be trending topics. Machine learning products also make up much of the list above – interestingly, with several releases of technology used to power Amazon.com.

Have you tried any of these new services? Let us know what you think of them!

AWS IAM User vs IAM Role for Secure SaaS Cloud Management

AWS IAM User vs IAM Role for Secure SaaS Cloud Management

While going through our recent Cloud Cost Optimization Competency review with AWS, one of the things they asked us to do was remove the ability for customers to sign up for our service using AWS IAM User credentials. They loved the fact that we already supported AWS IAM Role credentials, but their concern was that AWS IAM User credentials could conceivably be stolen and used from outside AWS by anyone. (I say inconceivable, but hey, it is AWS.)  This was a bit of a bitter pill to swallow, as some customers find IAM Users easier to understand and manage than IAM Roles. The #1 challenge of any SaaS cloud management platform like ours is customer onboarding, where every step in the process is one more hurdle to overcome.

While we could debate how difficult it would be to steal a customer cloud credential from our system, the key (pun intended) thing here is why is an IAM Role preferred over an IAM User?

Before answering that question, I think it is important to understand that an IAM Role is not a “role” in perhaps the traditional sense of Active Directory or LDAP. An AWS IAM Role is not something that is assigned to a “User” as a set of permissions – it is a set of capabilities that can be assumed by some other entity. Like putting on a hat, you only need it at certain times, and it is not like it is part of who you are. As AWS defines the difference in their FAQ:

An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM role does not have any credentials and cannot make direct requests to AWS services. IAM roles are meant to be assumed by authorized entities, such as IAM users, applications, or an AWS service such as EC2.

(The first line of that explanation alone has its own issues, but we will come back to that…)

The short answer for SaaS is that a customer IAM Role credential can only be used by servers running from within the SaaS provider’s AWS Account…and IAM User credentials can be used by anyone from anywhere. By constraining the potential origin of AWS API calls, a HUGE amount of risk is removed, and the ability to isolate and mitigate any issues is improved.

What is SaaS?

Software as a Service (SaaS) means different things to different vendors. Some vendors claim to be “SaaS” for their pre-built virtual machine images that you can run in your cloud. Maybe an intrusion detection system or a piece of a cloud management system. In my (truly humble) opinion this is not a SaaS – this is just another flavor of “on prem” (on-premise), where you are running someone’s software in your environment. Call it “in-cloud” if you do not want to call it “on-prem”, but it is not really SaaS, and it does not have the challenges you will experience with a “true” SaaS product – coming in from the outside. A core component of SaaS is that it is centrally hostedoutside your cloud. For an internal service, you might relax permissions and access mechanisms somewhat, as you have total control over data ingress/egress. A service running IN your network…where you have total control over data ingress/egress…is not the same as external access – the epitome of SaaS. Anyway: </soapbox>. (Or maybe </rant> depending on the tone you picked up along the way…)  

The kind of SaaS I am focussing on for this blog is SaaS for cloud management, which can include cloud diagramming tools, configuration management tools, storage management+backup tools, or cost optimization tools like ParkMyCloud.

AWS has enabled SaaS for secure cloud management more than any other cloud provider. A bold statement, but let’s break that down a bit. We at ParkMyCloud help our customers optimize their expenses at all of the major cloud providers and so obviously all the providers allow for access from “outside”. Whether it is an Azure subscription, a GCP project, or an Alibaba account, these CSP’s are chiefly focussed on customer internal cross-domain access. I.e., the ability of the “parent” account to see and manage the “child” accounts. Management within an organization. But AWS truly acknowledges and embraces SaaS.

You could attribute my bold statement to an aficionado/fanboi notion of AWS having a bigger ecosystem vision, or more specifically that they simply have a better notion of how the Real World works, and how that has evolved in The Cloud. The fact is that companies buy IT products from other companies…and in the cloud that enables this thing called Software as a Service, or SaaS. All of the cloud providers have enabled SaaS for cloud access, but AWS has enabled SaaS for more secure cloud access.

AWS IAM Cross-account Roles

So…where was I?  Oh…right…Secure SaaS access.

OK, so AWS enables cross-account access. You can see this in the IAM Create Role screen in the AWS Console:

If your organization owns multiple AWS accounts (inside or outside of an AWS “organization”), cross-account access allows you to use a parent account to manage multiple child accounts. For SaaS, cross-account access allows a 3rd-party SaaS provider to see/manage/do stuff with/for your accounts.

Looking a little deeper into this screen, we see that cross-account access requires you to specify the target account for the access:

The cross-account role allows you to explicitly state which other AWS account can use this role. More specifically: which other AWS account can assume this role.

But there is an additional option here talking about requiring an “external ID”…what is that about?  

Within multiple accounts in a single organization, this may allow you to differentiate between multiple roles between accounts….maybe granting certain permissions to your DevOps folks…other permissions to Accounting…and still other permissions to IT/network management.

If you are a security person, AWS has some very interesting discussions about the “confused deputy” problem mentioned on this screen. It discusses how a hostile 3rd party might guess the ARN used to leverage this IAM Role, and states that “AWS does not treat the external ID as a secret” – which is all totally true from the AWS side. But summing it up: cross-account IAM Roles’ external IDs do not protect you from insider attacks. For an outsider, the External ID is as secret as the SaaS provider makes it.

Looking at it from the external SaaS side, we get a bit of a different perspective. For SaaS, the External ID allows for multiple entry points…and/or a pre-shared secret. At ParkMyCloud (and probably most other SaaS providers) we only need one entry point, so we lean toward the pre-shared secret side of things. When we, and other security-conscious SaaS providers, ask for access, we request an account credential, explicitly giving our AWS account ID and an External ID that is unique for the customer. For example, in our UI, you will see our account ID and a customer-unique External ID:

Assume Role…and hacking SaaS

If we look back at the definition of the AWS IAM Role, we see that IAM roles are meant to be assumed by authorized entities. For an entity to assume a role, that party has to be an AWS entity that has the AWS sts:AssumeRole permission for the account in which it lives. Breaking that down a bit, the sts component of this permission tells us this comes from the AWS Secure Token Services, which can handle whole chains of delegation of permissions. For ParkMyCloud, we grant our servers in AWS an IAM Role that has the sts:AssumeRole permission for our account. In turn, this allows our servers to use the customer account ID and external ID to request permission to “Assume” our limited-access role to manage a customer’s virtual machines.

From the security perspective, this means if a hostile party wanted to leverage SaaS to get access to a SaaS customer cloud account via an IAM User, they would need to:

  • Learn an account ID for a target organization
  • Find a SaaS provider leveraged by that target organization
  • Hack the SaaS enough to learn the External ID component of the target customer account credentials
  • Completely compromise one of the SaaS servers within AWS, allowing for execution of commands/APIs to the customer account (also within AWS), using the account ID, External ID, and Assume Role privileges of that server to gain access to the customer account.
  • Have fun with the customer SaaS customer cloud, but ONLY from that SaaS server.

So….kind-of a short recipe of what is needed to hack a SaaS customer. (Yikes!)  But this is where your access privileges come in. The access privileges granted via your IAM role determine the size of the “window” through which the SaaS provider (or the bad guys) can access your cloud account. A reputable SaaS provider (ahem) will keep this window as small as possible, commensurate with the Least Privilege needed to accomplish their mission.

Also – SaaS services are updated often enough that the service might have to be penetrated multiple times to maintain access to a customer environment.

So why are AWS IAM Users bad?

Going back to the beginning, our quote from AWS stated “An IAM user has permanent long-term credentials and is used to directly interact with AWS services”. There are a couple frightening things here.

Permanent long-term credentials” means that unless you have done something pretty cool with your AWS environment, that IAM User credential does not expire. An IAM User credential consists of a Key ID and Secret Access Key (an AWS-generated pre-shared secret) that are good until you delete them.

“…directly interact with AWS services” means that they do not have to be used from within your AWS account. Or from any other AWS account. Or from your continent, planet, galaxy, dimension, etc. That Key ID and Secret can be used by anyone and anywhere.

From the security perspective, this means if a hostile party wanted to leverage SaaS to get access to a SaaS customer cloud account via an IAM Role, they would need to:

  • Learn an account ID for a target organization
  • Find a SaaS provider leveraged by that target organization
  • Hack the SaaS enough to get the IAM User credentials.
  • Have fun…from anywhere.

So this list may seem only a little bit shorter, but the barriers to compromise are somewhat lower, and the opportunity for long-term compromise is MUCH longer. Any new protections or updates for the SaaS servers has no impact on an existing compromise. The horse has bolted, so shutting the barn door will not help at all.

What if the SaaS provider is not in AWS?  Or…what if *I* am not in AWS?

The other cloud providers provide some variation of an access identifier and a pre-shared secret. Unlike AWS, both Azure and Google Cloud credentials can be created with expiration dates, somewhat limiting the window of exposure. Google does a great job of describing their process for Service Accounts here. In the Azure console, service accounts are found under Azure AD>App registrations>All apps>App details>Settings>Keys, and passwords can be set to expire in 1 year, 2 years, or never. I strongly recommend you set reminders someplace for these expiration dates, as it can be tricky to debug an expired service account password for SaaS.

For all providers you can also limit your exposure by setting a very limited access role for your SaaS accounts, as we describe in our other blog here.

Azure does give SaaS providers the ability to create secure “multi-tenant” apps that can be shared across multiple customers. However, the API’s for SaaS cloud management typically flow in the other direction, reaching into the customer environment, rather than the other way around.

IAM Role – the Clear Winner

Fortunately, when AWS “strongly recommended” that we should discontinue support for AWS IAM User-based permissions, we already supported an upgrade path, allowing our customer to migrate from IAM User to IAM Role without losing any account configuration (phew!). We have found some scenarios where IAM Role cannot be used – like between the AWS partitions of AWS global, AWS China, and the AWS US GovCloud. For GovCloud, we support ParkMyCloud SaaS by running another “instance” of ParkMyCloud from within GovCloud, where cross-account IAM Role is supported.

With the additional security protections provided for cross-account access, AWS IAM Role access is the clear winner for SaaS access, both within AWS and across all the various cloud providers.

Why the Principle of Least Privilege is Important for SaaS-based Cloud Management

Why the Principle of Least Privilege is Important for SaaS-based Cloud Management

The principle of least privilege is important to understand and follow as you adopt SaaS technologies. The market for SaaS-based tools is growing rapidly, and can typically be activated much more quickly and cheaply than creating a special-purpose virtual machine within your cloud environment. In this blog, I am focusing specifically on the SaaS cloud management tool area, which can include services like cloud diagramming tools, configuration management tools, storage management and backup tools, or cost optimization tools like ParkMyCloud.

Why the Principle of Least Privilege is Important

Before you start using such tools and services, you should carefully consider how much access you are granting into your cloud. The principle of least privilege is a fundamental tenet of any identity and access control policy, and basically means a service or user should have no more permissions than absolutely required in order to do a job.

Cloud account privileges and permissions are typically granted via roles and permissions. All of the cloud providers provide numerous predefined roles, which consist of pre-packaged sets of permissions. Before granting any requested predefined role to a 3rd-party, you should really investigate the permissions or security policy embedded in that role. In many (most?) cases, you are likely to find that the predefined roles give a lot more information or capabilities away than you are really likely to want.

SaaS Onboarding – Where Least Privilege Can Get Lost

For on-boarding of new SaaS customers, the initial permissions setup is often the most complicated step, and some SaaS cloud management platforms try to simplify the process by asking for one of these predefined roles.  For example, the Amazon ReadOnlyAccess role or the Azure Reader role or the GCP roles/viewer role.  While this certainly makes onboarding of SaaS easier, it also exposes you to a massive data leakage problem.  For example, with the Amazon ReadOnlyAccess role a cloud diagramming tool can certainly get a good enough view of your cloud to create a map…but you are also granting read access for all of your IAM Users, CloudTrail events and history, any S3 objects you have not locked-down with a distinct bucket policy, and….lots of other stuff you probably do not even know you have.  It is like kinda like saying – “Here, please come on in and look at all of our confidential file cabinets – and it is OK for you to make copies of anything interesting, just please do not change any of our secrets to something else…”  No problem, right?

Obviously, least privilege becomes especially critical when giving permissions to a SaaS provider, given the risk of trusting your cloud environment to some unknown party.

Custom Policies for SaaS

Because of the broad nature of many of their predefined roles, all of the major cloud providers give you the ability to assign specific permissions to both internal and external users through Policies.  For example, the following policy snippets show the minimum permissions ParkMyCloud requests to list, start, and stop virtual machines on AWS, Google, and Azure.

Creating and assigning these permissions makes SaaS onboarding a bit more complicated, but it is worth the effort in terms of reducing your exposure.

Other Policy Restrictions

What if you want to give a SaaS provider permissions, but lock it down to only certain resources or certain regions?  AWS and Azure allow you to specify in the policy which resources the policy can be applied to. Google Cloud….not so much.  AWS takes this the farthest, allowing for very robust policies down to specific services, and the addition of tag-based caveats for the policy permissions, for example:

This policy locks down the Start and Stop permissions to only those instances that have the tag name/value parkmycloud: yes, and are located in the us-east-1 region.  Similar Conditions can be used to lock this down by region, instance type, and many other situations. (This recent announcement shows another way to handle the region restriction.)

Azure has somewhat similar features, though with a slightly different JSON layout, as described here.  It does not appear you can use resource tags to for Azure, nor does Azure provide easy ways to limit the geographic scope of permissions.  You can get around the location and grouping of resources by using Azure Management Groups, but that is not quite as flexible as an arbitrary tag-based system, and is actually more intended to aggregate resources across subscriptions, rather than be more specific within a subscription.  That said, the Azure permissions defined here are a bit more granular than AWS.  This does allow for a bit more specificity in permissions if it is needed, but can no doubt grow tedious to list and manage.

Google Cloud provides a long list of predefined roles here, with an excellent listing the contained permissions.  There is also an interesting page describing the taxonomy of the permissions here, but Google Cloud appears to make it a bit difficult to enumerate and understand the permissions individually, outside of the predefined roles.  Google does not provide any tag or resource-based restrictions, apart from assignment at the Project level. More on user management and roles by cloud provider in this blog.

Gotchas

You may note that the ec2:Describe permission in our last example does not have the tag-based restriction.  This is because the tag-based restriction can only be used for certain permissions, as shown in the AWS documentation.  Note also that some APIs can do several different operations, some of which you may be OK with sharing, and others not.  For example, the AWS ModifyInstance permission allows the API user to change the instance type.  But…this one API (and associated permission) also allows the API user to modify security group assignments, shutdown behaviors, and other features – things you may not want to share with an untrusted 3rd party.

Key takeaway here?  Look out for permissions that may have unexpected consequences.

Summary

Beware of SaaS cloud management providers who are asking for simple predefined roles from your cloud provider.  They are either giving a LOT more functionality than you are likely to want from a single provider, or they are asking for a lot more permissions than they need.  Ask for a “limited access policy” that gives the SaaS provider ONLY what they need, and look for a document that defines these permissions and how they tie back to what the SaaS provider is doing for you.

These limited access policies serve to limit your exposure to accidents or compromises at the SaaS provider.

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

> No, I like wasting time and money.