2. AWS, GCP and Azure Platform Models

Introduction and Context

Cloud platforms are not merely collections of remotely hosted servers. They are large-scale operating models that combine physical infrastructure, virtualization, software-defined networking, managed services, identity systems, commercial arrangements, automation interfaces, and governance controls. Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure are the dominant general-purpose public cloud platforms used by enterprises, governments, software companies, and DevOps teams.

For a DevOps professional, comparing these providers requires more than listing equivalent services. The important questions concern how infrastructure is organized, how resources are governed, how services are exposed through consoles and APIs, how limits and service guarantees affect architecture, and how organizational requirements influence provider selection. A technically attractive service may be unsuitable if it creates unacceptable compliance exposure, operational complexity, vendor dependence, or cost volatility.

Although the three providers offer broadly similar capabilities, their platform models reflect different historical origins. AWS developed from Amazon’s large-scale retail infrastructure and emphasizes a highly extensive service portfolio. GCP emerged from Google’s expertise in distributed computing, data processing, and container orchestration. Azure grew from Microsoft’s enterprise software ecosystem and is particularly integrated with Microsoft identity, productivity, database, and hybrid-management technologies. These differences do not make one provider universally superior; they create different architectural and managerial trade-offs.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the relationship between cloud regions, availability zones, global services, and edge locations.

2. Compare the account, subscription, project, folder, organization, and resource hierarchies of AWS, Azure, and GCP.

3. Classify major cloud services and identify comparable offerings across the three providers.

4. Distinguish consoles, command-line interfaces, software development kits, and infrastructure-as-code interfaces.

5. Interpret quotas, service limits, and service-level agreements in architectural planning.

6. Evaluate cloud providers using technical, operational, financial, regulatory, and strategic criteria.

7. Apply these concepts to a multi-cloud or provider-selection scenario.

The Physical and Logical Geography of Cloud

A cloud platform consists of physical data centers connected by private and public networks. Providers abstract this infrastructure into geographical and logical units. A region is a defined geographic area containing one or more independent data-center groupings. Regions are selected for latency, data-residency, disaster-recovery, legal, and pricing reasons.

An availability zone (AZ) is an isolated location within a region. AWS describes AZs as distinct locations with independent power, cooling, and networking; Azure uses the term availability zone in supported regions; GCP commonly organizes infrastructure into zones within regions. The exact physical design and naming conventions differ, but the architectural principle is similar: workloads should be distributed across failure domains rather than concentrated in one location.

A region is not automatically a disaster-proof boundary. A regional outage, control-plane incident, network failure, software defect, or regulatory event can affect multiple zones. High-resilience designs therefore distinguish among:

• Zonal resilience, which protects against failure of a single zone.
• Regional resilience, which uses more than one region.
• Global resilience, which combines regions with global traffic management, replicated data, and geographically distributed clients.

Not every service is available in every region, and services may have different deployment scopes. A virtual machine may be zonal, a subnet may be regional, an identity directory may be global, and an object-storage bucket may be regional, dual-region, or multi-region depending on the provider and configuration. Architects must therefore verify service scope rather than assume that all resources behave alike.

Beyond regions and zones, providers operate edge locations, points of presence, content-delivery networks, and specialized network sites. These support low-latency delivery, DNS resolution, security filtering, and sometimes serverless or container execution near users. Edge presence improves access latency but does not necessarily mean that primary data is stored at the edge.

Provider Resource Hierarchies

Cloud governance depends heavily on hierarchy. Hierarchy determines where identities, policies, budgets, quotas, billing relationships, and audit controls are applied.

AWS

In AWS, the basic administrative boundary is the account. Organizations can group accounts under an AWS Organization, apply service control policies, consolidate billing, and create organizational units. Resources are created in regions and are associated with accounts. AWS also distinguishes global services, such as aspects of identity management, from regional services.

A common enterprise model uses separate accounts for production, development, security, logging, networking, and shared services. This limits the impact of errors and makes billing and access boundaries clearer. However, multiple accounts create operational work: cross-account roles, centralized logging, networking, naming, and policy inheritance must be designed carefully.

Microsoft Azure

Azure uses a hierarchy of management groups, subscriptions, resource groups, and resources. An organization can place multiple subscriptions beneath management groups, assign policies and role-based access controls at suitable scopes, and organize resources into resource groups according to lifecycle or application ownership.

A subscription is a major billing, quota, and management boundary. A resource group is a logical container whose resources generally share a lifecycle, although some related resources may have different deployment characteristics. Azure’s hierarchy is especially useful for enterprises that need policy inheritance across departments, business units, or regulatory environments.

Google Cloud

GCP uses an organization, optional folders, projects, and resources. The project is a central working boundary: it commonly contains APIs, service identities, billing association, quotas, and deployed resources. Folders allow organizations to group projects by department, environment, or compliance domain.

The project-centered model encourages teams to separate workloads into projects. This supports independent permissions, APIs, budgets, and quotas, but it also requires deliberate management of shared networks, service accounts, and inter-project communication.

Comparative interpretation

These models are functionally comparable but not identical. AWS emphasizes accounts; Azure emphasizes subscriptions within a management-group hierarchy; GCP emphasizes projects within an organization and folder structure. A direct terminology translation can be misleading. For example, an AWS account is not exactly the same as an Azure subscription, and a GCP project is not simply an equivalent of either. The correct comparison is based on purpose: billing boundary, identity boundary, quota boundary, deployment boundary, and policy boundary.

Service Taxonomies and Equivalent Capabilities

Cloud services are best understood by capability rather than by product name. The principal categories include compute, storage, networking, databases, identity and security, observability, integration, analytics, artificial intelligence, developer tools, and management services.

For compute, AWS provides Amazon EC2, Lambda, ECS, and EKS; Azure provides Virtual Machines, Functions, Container Apps, and AKS; GCP provides Compute Engine, Cloud Run, Cloud Functions, and Google Kubernetes Engine. These products are not interchangeable in every operational detail. Their pricing, scaling behavior, supported runtimes, networking models, regional availability, and integration patterns differ.

Object storage is represented by Amazon S3, Azure Blob Storage, and Google Cloud Storage. Block and file storage also exist across the platforms, but performance characteristics, replication options, access tiers, lifecycle rules, and API semantics must be examined before migration.

Managed relational database services include Amazon RDS and Aurora, Azure SQL Database and Azure Database services, and Cloud SQL and AlloyDB on GCP. Globally distributed or specialized databases include different products with different consistency, transaction, and availability models. A database comparison must therefore consider data model, consistency requirements, backup recovery, replication, operational control, and application compatibility—not only the product label.

Networking services include virtual private clouds or networks, subnets, route tables, firewalls, load balancers, private connectivity, DNS, and content delivery. Terminology varies: AWS uses VPC, Azure uses Virtual Network, and GCP uses VPC networks. Their scope also differs. For example, some network constructs are regional while others are global or project-level. These distinctions affect address planning and cross-region architecture.

Identity services are equally important. AWS Identity and Access Management, Microsoft Entra ID and Azure role-based access control, and Google Cloud IAM provide authentication, authorization, federation, workload identities, and policy controls. Effective security relies on least privilege, centralized identity, short-lived credentials, strong auditability, and separation of human and machine identities.

The classification of services also helps DevOps teams avoid inappropriate abstraction. A managed Kubernetes service reduces control-plane administration but does not eliminate responsibility for workloads, identities, network policies, images, secrets, or observability. Similarly, a serverless service removes server management but leaves application design, concurrency, permissions, data protection, and cost management as engineering responsibilities.

Management Interfaces: Console, CLI, SDK, and Infrastructure as Code

Every major provider exposes several management interfaces. The web console is useful for exploration, visualization, troubleshooting, and learning. It is not usually the best mechanism for repeatable production deployment because manual actions are difficult to review and reproduce.

Command-line interfaces support scripting and operational workflows. AWS CLI, Azure CLI, and Google Cloud CLI allow users to inspect resources, change configurations, authenticate automation, and integrate commands into pipelines. CLI commands are powerful but can become opaque when scripts lack version control, error handling, testing, and documentation.

Software development kits provide language-specific abstractions for applications and automation. SDKs are appropriate when provisioning or management is part of a larger program, controller, platform service, or internal tool. They also expose provider-specific behaviors such as pagination, retries, asynchronous operations, and error codes.

Infrastructure as code (IaC) expresses desired infrastructure in declarative configuration. Native tools include AWS CloudFormation, Azure Resource Manager templates and Bicep, and Google Cloud deployment mechanisms. Cross-provider tools such as Terraform and Pulumi can improve consistency across heterogeneous environments, although they introduce their own state management, provider-plugin, upgrade, and abstraction challenges.

A mature DevOps organization normally uses the console for investigation, CLI and SDKs for controlled operations, and IaC for durable environments. Changes should pass through code review, automated validation, policy checks, deployment pipelines, and drift detection. The goal is not to prohibit consoles but to prevent undocumented production change.

Quotas, Limits, and Service-Level Agreements

Cloud capacity is constrained by quotas. A quota may limit the number of virtual CPUs, addresses, load balancers, API requests, storage resources, keys, projects, or concurrent executions. Some limits are adjustable through a request; others are fixed service constraints. Quotas may be regional, zonal, account-level, project-level, subscription-level, or resource-specific.

Quotas are not merely administrative inconveniences. They influence architecture. A rapidly scaling platform may fail if it reaches a regional compute quota. A large microservice deployment may encounter limits on load balancers, routes, or API operations. A multi-tenant service must account for both provider quotas and internal tenant limits.

Good practice includes identifying quotas during design, monitoring utilization, requesting increases before migration, distributing workloads where appropriate, and testing failure behavior. Quota increases should not be treated as guaranteed capacity or as a substitute for architectural efficiency.

A service-level agreement (SLA) is a provider’s contractual commitment regarding service availability or performance under defined conditions. SLAs commonly specify measurement periods, exclusions, service dependencies, and service credits. A service credit is generally compensation for a breach; it is not a guarantee that applications will remain available.

An application SLA is usually stricter and broader than an individual provider SLA. If an application depends on several services, the combined availability cannot be assumed to equal the best individual SLA. Dependencies, client networks, application defects, unsuitable deployment topology, and incorrect configuration may remain outside the provider’s commitment. Therefore, resilience must be designed through redundancy, health checks, backups, tested restoration, graceful degradation, and operational readiness.

A Framework for Selecting a Cloud Provider

Provider selection should begin with business and workload requirements rather than brand preference. A useful evaluation framework considers six dimensions.

Technical fit includes compute models, data services, networking, integration, performance, supported operating systems, observability, and regional availability. Operational fit includes automation, skill availability, managed-service maturity, incident response, support quality, and compatibility with existing delivery pipelines.

Economic fit includes consumption pricing, discounts, licensing, data-transfer charges, support fees, commitment terms, idle-resource exposure, and cost-management tooling. Total cost of ownership should include migration, training, refactoring, security controls, and exit costs.

Governance and compliance fit includes data residency, certifications, contractual terms, audit access, encryption, key management, identity federation, retention, and regulatory obligations. Certification alone does not make a workload compliant; the customer remains responsible for configuration and operational practices.

Strategic fit considers ecosystem strength, acquisitions, product direction, partner network, talent availability, and the organization’s tolerance for vendor dependence. Resilience fit evaluates regional coverage, cross-region replication, failure isolation, portability, and recovery capabilities.

A weighted decision matrix can make assumptions visible. However, numerical scores should not create false precision. A provider that scores highly overall may still be unacceptable if it fails a mandatory requirement such as residency or a required database capability.

Applied Case: Selecting a Platform for a Regulated Digital Service

Background

The following is an illustrative case. A financial-services organization is developing a customer-facing digital service for three continents. It requires relational transactions, analytical processing, continuous delivery, strong audit trails, encryption using customer-controlled keys, and recovery from a regional outage. The organization already operates Microsoft identity and collaboration tools but also has a data-engineering team experienced with Google technologies.

Situation and analysis

The initial proposal recommends one provider solely because its compute price is lowest. The architecture team challenges this approach. The service must meet residency requirements, support private connectivity to existing systems, provide managed databases, and allow independent development and production boundaries. The team maps requirements to provider regions, database replication options, identity integration, quota availability, support arrangements, and data-transfer costs.

The team identifies three risks. First, a low virtual-machine price does not represent total cost because storage operations, outbound transfer, managed database capacity, and premium support may dominate expenditure. Second, a multi-region design may be impossible for a particular database configuration in the required jurisdictions. Third, the organization’s recovery objective cannot be met merely by purchasing a high-availability service; replication and restoration must be tested.

Approach and solution

The organization creates a weighted decision matrix with mandatory and desirable criteria. It evaluates AWS, Azure, and GCP using documented evidence and proof-of-concept tests. Azure receives a strong score for identity integration and hybrid connectivity. GCP performs strongly for analytics and container-oriented delivery. AWS offers broad service choice and mature multi-account governance. The final decision is to use Azure for the regulated transaction system while retaining a controlled GCP analytics environment, connected through governed interfaces rather than unrestricted data duplication.

The architecture uses separate production and non-production subscriptions or projects, centralized logging, policy enforcement, private endpoints, managed keys, infrastructure as code, and automated policy checks. Data copied to analytics is minimized and classified. Recovery exercises are scheduled before launch.

Outcome and learning points

The selected design is not the cheapest in every individual service category, but it provides stronger alignment with identity, residency, operating skills, and recovery requirements. The organization also documents exit assumptions, portability boundaries, and the conditions under which the secondary provider may be expanded.

The case demonstrates that provider choice is a portfolio decision. It must integrate technology, governance, finance, people, and risk. Multi-cloud is not automatically resilient: it can increase duplicated skills, monitoring complexity, networking costs, and inconsistent security. It is valuable only when its benefits justify those costs.

Challenges, Governance, and Professional Practice

The principal operational risks include accidental exposure of storage, excessive permissions, untracked manual changes, uncontrolled resource creation, weak secrets management, inadequate logging, and unexpected data-transfer charges. Provider-native defaults can also create confusion when similar services have different scopes or security behaviors.

Governance should establish account or project design, naming standards, tagging and labeling, ownership, budgets, policy-as-code, identity federation, key management, backup requirements, incident procedures, and decommissioning controls. Separation of duties is important: the person who develops infrastructure should not automatically approve production access or disable audit controls.

Ethical and regulatory practice requires protecting personal and confidential data, minimizing collection and retention, documenting automated decisions where relevant, and ensuring that operational convenience does not override legal obligations. Cloud providers operate the underlying platform, but customers remain accountable for their data, identities, configurations, and applications under the shared-responsibility model.

Automation and analytics improve governance when used carefully. Policy engines can block public storage or unapproved regions; cost analytics can identify idle resources; anomaly detection can reveal unusual API activity; and deployment pipelines can enforce security tests. Automation must be observable and reversible. A poorly designed automated policy can interrupt legitimate workloads at scale.

Current Developments and Best Practices

Current platform development is characterized by managed Kubernetes, serverless containers, platform engineering, confidential-computing options, specialized AI services, sovereign-cloud initiatives, and increasingly granular policy automation. Generative AI services are being integrated into development and operations, but their use raises questions about data disclosure, model accuracy, intellectual property, and human oversight.

Important practices include:

• Design around failure domains and test recovery rather than relying on stated availability.
• Separate environments and apply least privilege through federated identity and short-lived credentials.
• Use IaC, code review, automated policy validation, and drift detection.
• Track service scope, regional availability, quotas, dependencies, and data-transfer paths.
• Measure total cost, including storage, requests, support, licenses, transfer, and engineering effort.
• Maintain provider-specific expertise while documenting portability boundaries.
• Treat observability, backup, restoration, and incident response as first-class architecture concerns.
• Review provider changes, deprecations, pricing, and compliance terms continuously.

Chapter Summary

AWS, Azure, and GCP provide comparable cloud capabilities through different organizational and operational models. Regions and availability zones define important failure and deployment boundaries, while global services and edge locations require separate analysis. AWS organizes governance primarily around accounts and organizations; Azure uses management groups, subscriptions, and resource groups; GCP uses organizations, folders, and projects.

Cloud services should be compared by capability, scope, performance, management responsibility, and commercial terms rather than by names alone. Consoles support exploration, while CLIs, SDKs, and infrastructure as code enable repeatable operations. Quotas influence design, and SLAs are contractual commitments that do not replace application-level resilience. Provider selection should combine technical, operational, economic, governance, strategic, and recovery criteria. The most suitable platform is the one that best satisfies the complete workload and organizational context.

Key Terms

Region: A geographic cloud location containing one or more isolated infrastructure areas.

Availability zone: An isolated failure domain within a cloud region.

Edge location: A network site used to deliver content or services close to users.

Account: An AWS administrative, billing, identity, and resource boundary.

Subscription: An Azure billing, quota, and management boundary.

Project: A central GCP boundary for resources, APIs, identities, quotas, and billing association.

Management group: An Azure hierarchy level used to organize subscriptions and apply governance.

Folder: A GCP hierarchy level used to organize projects.

Resource group: An Azure logical container for resources that commonly share a lifecycle.

Service taxonomy: A classification of cloud capabilities such as compute, storage, networking, and databases.

Console: A graphical interface for managing cloud resources.

CLI: A command-line interface for scripted or interactive cloud operations.

SDK: A programming library used to interact with cloud services.

Infrastructure as code: The practice of defining infrastructure through version-controlled configuration.

Quota: A limit on cloud resource capacity or API usage.

SLA: A contractual service-availability or performance commitment.

Shared responsibility: A model dividing security and operational duties between provider and customer.

Policy as code: Machine-readable rules used to evaluate or enforce governance requirements.

Data residency: The geographical or legal requirement governing where data is stored or processed.

Multi-cloud: The deliberate use of services from more than one cloud provider.

Review Questions

Short Answer Questions

1. What is the relationship between a cloud region and an availability zone?

2. Why is a GCP project an important governance boundary?

3. Distinguish a cloud console from a command-line interface.

4. What is the difference between a quota and an SLA?

5. Why should provider services be compared by capability rather than name?

Long Answer Questions

1. Compare AWS, Azure, and GCP resource hierarchies and explain their implications for enterprise governance.

2. Explain how regional and zonal architecture contributes to resilience and identify its limitations.

3. Discuss the roles of consoles, CLIs, SDKs, and infrastructure as code in a DevOps operating model.

4. Develop a framework for selecting a cloud provider for an enterprise workload.

5. Explain why a provider SLA does not by itself guarantee application availability.

Analytical / Application Questions

1. A company operates a production database in one zone and claims that its regional design is highly available. Analyze the claim and propose improvements.

2. An organization selects a provider solely because virtual-machine prices are lowest. Identify the omitted cost and governance factors that should be evaluated.

3. Design a high-level account, subscription, or project structure for an enterprise with development, production, security, logging, and analytics workloads. Justify the boundaries.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the architectural purpose of availability zones?

A. They provide separate billing accounts within one provider.

B. They create isolated failure domains within a region.

C. They store all global services in one location.

D. They eliminate the need for application backups.

Correct Answer: B. They create isolated failure domains within a region.

Question 2

Which hierarchy is correctly associated with Google Cloud?

A. Organization, folders, projects, resources

B. Management groups, subscriptions, resource groups, resources

C. Organization, accounts, organizational units, resources

D. Region, zone, subscription, resource group

Correct Answer: A. Organization, folders, projects, resources

Question 3

Why is infrastructure as code generally preferred for repeatable production deployment?

A. It prevents all provider outages.

B. It removes the need for identity controls.

C. It enables versioning, review, and reproducible changes.

D. It guarantees lower prices than manual deployment.

Correct Answer: C. It enables versioning, review, and reproducible changes.

Question 4

A workload reaches its regional virtual-CPU quota during an automated scale-out event. What is the most appropriate interpretation?

A. The provider SLA has automatically been violated.

B. The workload has encountered a capacity constraint requiring planning or redesign.

C. The region has become physically unavailable.

D. The application has exceeded its data-residency requirement.

Correct Answer: B. The workload has encountered a capacity constraint requiring planning or redesign.

Question 5

Which factor is least appropriate as the sole basis for selecting a cloud provider?

A. Identity and compliance requirements

B. Regional and database capabilities

C. The advertised price of one virtual-machine type

D. Operational skills and support requirements

Correct Answer: C. The advertised price of one virtual-machine type

Question 6

What is a key limitation of relying only on an individual cloud service SLA?

A. An SLA normally guarantees application logic correctness.

B. An SLA removes the need for redundancy.

C. An SLA may exclude customer configuration and dependent services.

D. An SLA applies equally to every service and region.

Correct Answer: C. An SLA may exclude customer configuration and dependent services.

Question 7

An enterprise wants policies inherited across many Azure subscriptions. Which construct is most directly designed for this purpose?

A. Availability zone

B. Management group

C. Object-storage bucket

D. Edge location

Correct Answer: B. Management group

Question 8

Which practice most directly reduces undocumented production changes?

A. Using the console for every deployment

B. Disabling audit logs to reduce storage cost

C. Requiring reviewed infrastructure-as-code changes through a pipeline

D. Increasing API quotas before each release

Correct Answer: C. Requiring reviewed infrastructure-as-code changes through a pipeline

Question 9

Why can multi-cloud increase rather than automatically reduce operational risk?

A. It always prevents data replication.

B. It can create duplicated skills, monitoring, networking, and governance complexity.

C. It makes all services identical across providers.

D. It eliminates the need for provider-specific knowledge.

Correct Answer: B. It can create duplicated skills, monitoring, networking, and governance complexity.

Question 10

A regulated organization is comparing providers. Which evaluation method is most defensible?

A. Choose the provider with the largest service catalogue without testing.

B. Choose the provider already used by competitors.

C. Use mandatory criteria and a weighted assessment supported by proof-of-concept evidence.

D. Choose the provider with the cheapest compute service.

Correct Answer: C. Use mandatory criteria and a weighted assessment supported by proof-of-concept evidence.