Skip navigation
Guidebook with colorful page markers Getty Images

Cloud Vendors' Security Guidelines: Worth Your Time?

We break down the cloud security guides and resources offered by AWS, Azure, and Google Cloud and determine how valuable they are for both novice and seasoned architects.

Making the second iteration of your cloud security architecture perfect is child’s play. The real challenge is having an adequate first iteration. If the first is so-so, engineers will have to spend weeks readjusting their configurations or start the implementation from scratch. Worse, your initial cloud security posture might have more holes than Swiss cheese from the Emmental region.

Cloud vendors provide thousands of articles, tutorials, and web pages that explain every detail cloud security. But what matters most for the first design is guidance for security architects to systematically develop a “grand design” for protecting a cloud estate. And the methodology must be helpful for both seasoned architects and architects working with a particular cloud for the first time.

So, how valuable are AWS’s Well-Architectured Framework, the Google Cloud Security Foundation Guide, and various Microsoft Azure frameworks? Let’s break down these popular vendors’ security guide offerings.

The Google Cloud Security Foundation Guide

Google‘s 130-page GCP Security Foundation Guide introduces Google’s GCP security philosophy, principles, and a sample GCP environment that serves as an example throughout the central part of the document. It elaborates on eight security-related topics, from network and identity and access management (IAM) to billing and application security (subchapters II.5-II.12, see Figure 1). The centerpieces of all these subchapters are architecture blueprints and security architecture patterns.

Figure 1Google Cloud security foundation guideline extract

Figure 1 - Google Cloud security foundation guideline -- extract of architecture-relevant chapters with the patterns

Who Is It Best For?

Figure 2 visualizes the document style: a big architectural diagram, explanation text, and a table with details for the exact configuration setup. The motto: “Present a blueprint and explain it.” Thus, security architects new to GCP or addressing one of those security topics for the first time benefit from an initial well-architectured design pattern that they can revise and customize for their concrete company context.

Figure 2Extract from section 7.3 - Enterprise-to-Google cloud connectivity pattern

Figure 2 - Extract from section 7.3, Enterprise-to-Google cloud connectivity pattern

AWS Well-Architectured Framework

Amazon launched its AWS Well-Architectured Framework already in 2015. It initially comprised five pillars but it has six today: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. In recent years, AWS has complemented these pillars with technology and industry sector-specific lenses (Figure 3).

Figure 3Figure 3 - AWS well-architected framework overview and structure

Figure 3 - AWS well-architected framework overview and structure

The AWS framework documentation for the security pillar is 155 pages detailing 66 security topics. They describe needs and requirements structured in seven areas: security foundation, identity and access management, detection, infrastructure protection, data protection, incident response, and application security. The structure might vary from GCP’s one. The main difference, however, is AWS’s approach to presenting the topics.

GCP puts architectural blueprints in the center of the explanations, whereas AWS presents a well-architectured framework without (nearly) any diagram. AWS follows a very rigid structure, as Figure 4 visualizes. It is the same for all topics: desired outcomes and anti-patterns (i.e., typically observed bad designs), followed by a short risk statement explaining the consequences of not adequately addressing a specific topic. Next comes an implementation guideline with a mix of tasks and steps. The topic descriptions conclude with links to additional articles providing more insights and highlighting other closely related AWS framework topics.

Figure 4Sample topic description in AWS’s well-architectured framework

Figure 4 - Sample topic description in AWS’s well-architectured framework security pillar, SEC08-BP04 Enforce access control

Who Is It Best For?

So, for whom is the AWS framework helpful? Obviously, it is every project manager’s best friend. It lists the designs security architects must deliver and engineers must implement. However, architects should not expect any design or pattern that helps them design solutions, though the framework contains links to potentially helpful information for the latter purpose.

Azure Security Documentation

Azure has not just one but several competing and overlapping frameworks and methodologies. In particular, there is the well-architectured framework, the architecture center, and the Azure Security Fundamentals Documentation. As Figure 5 illustrates, the latter has two sections focusing on core security architecture topics: securing cloud solutions and protecting Azure resources. Both sections link to multiple web pages. In the case of cloud security best practices, they cover various security domains, from networking to PaaS security. The individual pages introduce subtopics, often with best practices sketched in one sentence – “Don’t assign allow rules with broad ranges” or “Enable SSO” –  followed by further short explanations. But how does this Azure security fundamentals documentation help security architects structure their work and design security architectures?

Figure 5Azure Security Fundamentals Documentation

Figure 5 - Azure Security Fundamentals documentation

Who Is It Best For?

The documentation provides outstanding explanations of essential topics and motivates readers to click on links to read additional articles, helping them increase their general understanding of security topics. However, you do not learn civil engineering efficiently by reading all related Encyclopedia Britannica articles. Similarly, novice Azure security architects learn concepts but do not learn a methodology or get a conclusive task list when browsing through this documentation. There are also no architectural diagrams explaining the interplay between the various Azure cloud components and security services.

Also worth mentioning is Microsoft’s collection of architectural blueprints (Azure Architectures), of which many address security-related topics (e.g., “Secure MLOps solutions with Azure network security”). Again, they are well-written and informative. They help architects and engineers to get an understanding of best-practice designs for specific and even very niche topics. However, the presentation of the blueprints is not a systematic introduction that would help security architects with an initial IaaS or PaaS data center.

Then, there is the Azure well-architectured framework. It rests on five pillars, one dedicated to security. The security pillar covers five areas – identity management, protect your infrastructure, application security, data sovereignty and encryption, and security resources (Figure 6). Unlike AWS, the Azure framework does not provide a structured list of requirements. Instead, it briefly explains concepts and links to additional resources – not directly actionable, neither for security engineers nor for project managers or architects.

Figure 6Azure Well-Architected Framework

Figure 6 - Azure Well-Architected Framework

Bottom Line

Azure has many learning resources and documentation for all security-related and non-security-related features, but the learning curve for security architects is high. Architects have to self-structure the security domain and look at how they address the various topics in their grand design. In contrast, GCP’s Security Foundation Guide presents basic ready-to-use architectural blueprints addressing the interplay of various cloud security features and components for crucial security areas. Finally, there is the AWS Well-Architected Framework: Prussian sober, humorless, to-the-point, and overly structured. It provides a clear overview and a list of things to do. It might even be reusable as input for an initial definition of work packages for other clouds.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.