The Security Pro’s Quick Cloud Comparison: AWS, Azure, or GCP?
Over the past year I’ve noticed a very large uptick in production workloads, often from large organizations, moving beyond AWS and into Azure and GCP. This isn’t necessarily real multi-cloud — just the reality of competing services becoming more viable.
The problem for security professionals is that security models and controls vary widely across providers, are often poorly documented, and are completely incompatible. Anyone who tells you they can pick up on these nuances in a few weeks or months with a couple training classes is either lying or ignorant. It takes years of hands-on experience to really understand the security ins and outs of a cloud provider.
Covering all the details would take a few books, and be out of date before you finished reading it. In future posts we will dig into major security domains, but today I want to start with a simple, high-level comparison to give you an overall sense of the differences.
AWS is the oldest and most mature major cloud provider. This is both good and bad, because some of their enterprise-level options were basically kludged together from underlying services weren’t architected for the scope of modern cloud deployments. But don’t worry — their competitors are often kludged together at lower levels, creating entirely different sets of issues.
The biggest advantage of AWS is that, as the dominant provider, there is a lot of knowledge and tooling out there. It’s easier to get answers, find help, and find supported tools. This is on top of the platform’s overall maturity and scope. AWS also does a reasonably good job of defaulting to secure configurations. For example when you deploy an instance onto a VPC (virtual network), network access is decently restricted (although a few years ago their console wizard started opening up ports 22 and 3389 when you use it, to reduce support calls, but it’s easy enough to lock them down).
Isolation is the name of the game in AWS. Services can’t even access other services unless you explicitly enable access. The core unit in AWS is an account, and accounts are totally isolated from each other until you open access. You can tie all your accounts together into an Organization if you want, but it’s still possible to limit central access. We do this ourselves to separate production from development.
Most core security features are available — from robust API activity monitoring to basic threat intel (Guard Duty), WAF, DLP (Macie), Vulnerability Assessment (Inspector), and security event triggers for automations. There are known techniques to fill the remaining gaps. Two of the best AWS security features are their excellent implementation of security groups (firewalls) and granular IAM.
But all these benefits come with a dark side. The isolation makes enterprise scale management more difficult than it needs to be. Even within a single account it’s difficult to collect security data and manage across regions — sometimes in really … annoying … ways. For example you can create a security event hub, but it can only collect events within its own region. Security Hub is their new product to tie together both first and third party security tooling, but while it can work across accounts it is still region-limited. So you need to manage all the alerts from your accounts in Oregon, then set it up again in Virginia and/or Frankfurt to handle accounts that use those regions as well.
Managing IAM at scale can be tough, especially as you enable the more advanced features like permission boundaries and conditionals. Again this is largely due to isolation between accounts, because there is no single place to manage access for them all.
Despite those limitations, today AWS is usually the best place to start, where you run into the fewest security issues.
Azure is the provider I run into the most when running projects and assessments. Azure can be maddening at times due to lack of consistency and poor documentation. Many services also default to less secure configurations. For example if you create a new virtual network and a new virtual machine on it, all ports and protocols are open. AWS and GCP always start with default deny, but Azure starts with default allow.
Azure does have some advantages, which can be significant to enterprises. Azure Active Directory is the single source of truth for authorization and permissions management. Unlike AWS — where you need to configure federation, users, and access for each account — Azure allows it all to be managed from a single directory. This is both good and bad — management is easier and more consistent, but environments (subscriptions) are less isolated and protected from each other. During assessment over-provisioning is one of the most common issues.
Azure has two other central features which are particularly appealing to enterprise users:
- Activity logs cover console and API activity for the entire tenant (organization) by default, across regions. There isn’t any need to build custom lambda functions to move events between regions or the other complexities like we see on AWS. Although Azure AD logs can be delayed up to an hour, I have heard activity logs are much more timely.
- The Azure Security Center also covers the entire tenant (with the right licensing) and can be scoped to allow subscription-level access so local teams can manage their own alerts. This is what Security Hub is building up to become. But the ASC can be maddening due to its lack of transparency and assessment limitations. The key is to understand what it does well, what it does okay (e.g., some threat scans are only daily), and what it does poorly (compliance assessments have weird gaps).
As with AWS, you can do pretty much everything you need in Azure, but once you get past Azure AD, activity logs, and Azure Security Center… the rest can be pretty ugly to set up. For example there are two different types of security groups (network and application), which are managed differently, and one doesn’t even show up in the portal when you look at your networks. API support is all over the map, and while you can do most things in PowerShell, SDKs and other tooling are much more limited.
Azure also has real consistency, availability, and documentation problems. For example some services deploy an endpoint onto a virtual network, BUT don’t respect its network security groups. It looks like you are protected, but instead ports and/or destinations are exposed to the Internet — and this isn’t something the customer can change! I’ve had customers report all sorts of idiosyncratic behaviors and ones that don’t match documentation. In terms of support, a common complaint is that customers ask a single question, and then get 5 different answers from 3 different Microsoft consultants or support reps.
You can be secure on Azure but you need to be very careful, move slowly, and test everything.
GCP is very young in some was, but very old in others. It’s built on Google’s impressive long-term engineering and global operations, which are insanely impressive.
Like Azure, GCP is better centralized, because many capabilities were planned out from the start — compared to AWS feature which were only added a few years ago. Within your account Projects are isolated from each other except where you connect services. Overall GCP isn’t as mature as AWS, but some services — notably container management and AI — are class leaders.
The easiest way to think about GCP security is on a continuum somewhere between AWS and Azure. It offers organization-wide logging but coverage isn’t complete. It has more granular IAM which can be easier to manage centrally, but some aspects of custom policies are still in beta. This is all just a matter of maturity. GCP also generally defaults to secure configurations, but doesn’t always have the same range of security features as AWS.
GCP does include some impressive built-in security tools. The Cloud Security Command Center is their version of the Azure Security Center or Security Hub. Stackdriver Logging works great, and Google offers the open source Forseti for managing security configurations.
A downside is the very small number of security experts with deep GCP experience, and the less robust community and tooling. Again, this is to be expected of a younger service — this kind of knowledge expansion takes time.
This should give you a sense of what to expect across these services. Our future posts will break out individual security control areas and provider a more technical comparison. But we wanted to make clear that you can be secure on any of these services — with the right configurations, knowledge, and tooling.