DisruptOps: The Security Pro’s Quick Comparison: AWS vs. Azure vs. GCP

By Rich

I’ve seen a huge increase in the number of questions about cloud providers beyond AWS over the past year, especially in recent months. I decided to write up an overview comparison over at DisruptOps. This will be part of a slow-roll series going into the differences across the major security program domains – including monitoring, perimeter security, and security management. Here’s an excerpt:

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.

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.

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.

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.

No Related Posts

Just don’t run Hadoop or Elastic in AWS even using their solutions to those because BigQuery. Brownfield you’re probably on Azure anyways. If you’re Brownfield though, bless your heart, you need the ETL set that BigQuery offers, just start dumping data in Sheets if nothing else. But you won’t do that. 

Am really looking forward to learning more Drill (or SparkSQL) but there’s a lot of Dremel in BigQuery. 

I know I barely touched on cybersecurity but attack cycles for AWS are finally shaping into semi-permanency and wide reach. So in AWS, you’re sink or swim at this point; the others you’re chillin on a raft or tube. 

Having containers figured out sounds like ultra zen. Is it even true though? If partly true, what does it even mean? Which C word is more interesting and core here—cloud or container?

By Andre Gironda

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.