AWS and GCP Platforms and Well-Architected Design

Introduction

Cloud deployment requires more than knowing how to start a virtual machine. A DevOps practitioner must understand how a cloud provider organizes resources, how identities and permissions are applied, how services correspond across providers, and how architectural decisions are evaluated. Amazon Web Services (AWS) and Google Cloud Platform (GCP) are both large public-cloud ecosystems, but they use different organizational models, names, defaults, and operational conventions.

This chapter introduces the practical foundations needed to work safely and effectively with both platforms. It explains AWS accounts and Organizations, GCP organizations and projects, consoles, command-line interfaces (CLIs), software development kits (SDKs), service equivalence, and the principles of AWS Well-Architected and the Google Cloud Architecture Framework. The aim is not to memorize product names. It is to develop transferable design reasoning: identify a workload, define its requirements, select appropriate managed services, control access and cost, and continuously improve the resulting system.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Distinguish AWS accounts, Organizations, organizational units, and regions from GCP organizations, folders, projects, billing accounts, and regions.
2. Navigate cloud consoles and explain the roles of CLIs and SDKs.
3. Select broadly equivalent AWS and GCP services while recognizing important differences.
4. Apply least privilege, tagging or labeling, quotas, budgets, and policy controls.
5. Use the AWS Well-Architected Framework and Google Cloud Architecture Framework to evaluate a design.
6. Explain why portability is not the same as simple product-to-product substitution.
7. Analyse a small deployment scenario and justify architectural decisions.

1. The Cloud Resource Model

A cloud platform exposes resources through a hierarchy. The hierarchy separates ownership, billing, identity, policy, and workload resources. Understanding this structure prevents common errors such as deploying into the wrong environment or granting permissions at excessive scope.

AWS structure

An AWS account is a fundamental security and billing boundary. Resources such as Amazon Elastic Compute Cloud (EC2) instances, Amazon Simple Storage Service (S3) buckets, and databases are created within an account and a Region. A company may use AWS Organizations to manage multiple accounts from a management account. Organizational units (OUs) group accounts for policy administration; for example, separate OUs may contain production, development, and security accounts.

AWS Identity and Access Management (IAM) controls authentication and authorization. A principal may be a human user, role, or service. In professional environments, human access should normally use federation and temporary roles rather than long-lived access keys. Service control policies can restrict what accounts in an Organization are allowed to do, while IAM policies grant permissions to principals. A service control policy does not itself grant access; it establishes a maximum permission boundary.

A Region is a geographic area containing multiple Availability Zones (AZs). An AZ is an isolated location within a Region. Some resources are Regional, while others are global or tied to a single AZ. This distinction matters when designing for resilience and when estimating cost.

GCP structure

GCP commonly uses an organization at the top of the resource hierarchy. Folders can group projects by department, environment, or application. A project is a central management boundary: it contains enabled APIs, many resources, quotas, IAM policies, and usage records. A workload usually requires one or more projects, such as separate production and non-production projects.

A billing account is linked to projects and records charges; it is not identical to a project. IAM policies can be inherited from the organization or folder and applied at project, folder, or resource level. Google Cloud Identity and access management uses principals such as users, groups, service accounts, and workforce or workload identities.

GCP regions contain zones. Many compute resources are zonal, while some services are regional or global. A project ID is globally unique and is frequently used in command-line commands and resource names. A project name is descriptive and may not be unique; confusing the two causes deployment errors.

Comparative hierarchy

The mapping is useful but not exact. An AWS account often resembles a GCP project operationally, but an account is a stronger security boundary in several contexts, whereas a GCP project is also a primary API, quota, and resource-management boundary. A migration plan must inspect actual behavior rather than assume structural equivalence.

2. Consoles, CLIs, and SDKs

Cloud providers offer three complementary interaction methods.

The web console is a graphical interface useful for exploration, visual inspection, troubleshooting, and learning. It exposes many options but can encourage undocumented manual changes. A console action may also hide important defaults, such as an automatically selected network or logging setting.

A CLI is a command-line program that sends authenticated API requests. AWS CLI commands commonly begin with aws; Google Cloud CLI commands commonly begin with gcloud. CLIs are valuable for repeatable operational tasks, scripting, querying resources, and integrating commands into CI/CD pipelines. Commands should be tested in a non-production environment and should explicitly identify the account, project, region, or profile being used.

An SDK is a programming library that allows application code or automation tools to call cloud APIs. AWS provides SDKs such as the AWS SDK for Python (Boto3), while Google provides client libraries for languages including Python, Java, Go, and JavaScript. SDKs are appropriate when logic requires loops, conditions, error handling, state management, or integration with an existing application.

Authentication and context

A safe workflow makes the execution context visible. In AWS, named profiles can select credentials and Regions. In GCP, the active account and project can be inspected and changed using the Google Cloud CLI. Organizations should use single sign-on, multifactor authentication, temporary credentials, and workload identity mechanisms wherever possible.

A useful operational sequence is:

1. Authenticate through the approved identity provider.
2. Confirm the selected account, project, subscription-like billing context, and Region.
3. Inspect existing resources and policies.
4. Make the smallest required change.
5. Verify the result and record the change.
6. Revoke or expire temporary access.

The principle is simple: authentication establishes who is acting; authorization determines what that identity may do; context determines where the action occurs.

Infrastructure as code

Infrastructure as code (IaC) expresses desired infrastructure in version-controlled files. AWS CloudFormation and AWS Cloud Development Kit are AWS-oriented tools. Google Cloud Deployment Manager has historically existed for GCP, while Terraform and other tools are commonly used for multi-cloud provisioning. IaC supports peer review, repeatability, drift detection, and automated testing. It does not automatically make a design secure: insecure configuration can be reproduced just as efficiently as secure configuration.

3. Mapping AWS and GCP Services

Service mapping is a starting point for analysis, not a promise of identical functionality.

A reliable mapping process begins with workload requirements. For storage, ask whether data is object, block, or file data; what durability and latency are needed; whether versioning and retention are required; and where data may legally reside. For compute, ask whether the workload is long-running, event-driven, containerized, or batch-oriented. For databases, identify transaction model, query patterns, consistency, backup, and recovery requirements.

The “lowest common denominator” is not always the best multi-cloud design. It may discard valuable provider capabilities and increase operational complexity. A better approach is to identify which components must be portable and which may deliberately use provider-specific managed services.

4. Well-Architected Design as a Decision Discipline

A well-architected framework is not a product checklist. It is a set of questions that exposes risk and makes trade-offs explicit. Every architecture must balance reliability, security, performance, cost, operational effort, and organizational goals.

AWS Well-Architected Framework

The AWS framework is organized around six pillars:

1. Operational excellence: operate and improve systems effectively. Practices include automation, observability, runbooks, small reversible changes, and learning from operational events.
2. Security: protect information and systems. Core practices include strong identity foundations, traceability, defense in depth, encryption, and preparation for incidents.
3. Reliability: ensure a workload performs its intended function correctly and recovers from failures. Design includes failure analysis, automated recovery, change management, and tested recovery procedures.
4. Performance efficiency: use computing resources efficiently as requirements change. Managed services, appropriate instance types, caching, and measurement are important.
5. Cost optimization: achieve business value at an appropriate cost. Practices include measurement, eliminating waste, selecting suitable pricing models, and matching supply to demand.
6. Sustainability: reduce environmental impacts associated with running cloud workloads. Efficient utilization, right-sizing, lifecycle policies, and managed services can contribute.

The pillars are interdependent. Increasing redundancy may improve reliability but increase cost. Stronger encryption may introduce performance or operational requirements. A sound design records these trade-offs rather than claiming that every objective is maximized simultaneously.

Google Cloud Architecture Framework

Google Cloud presents architecture guidance through themes including system design, operational excellence, security, reliability, performance optimization, cost optimization, and sustainability. The exact presentation may evolve, but the central method remains consistent: understand business requirements, design for failure, automate operations, protect data and identities, measure performance, control cost, and minimize resource waste.

Google’s guidance often emphasizes separation of concerns, decoupling, observability, managed services, horizontal scalability, and policy-based governance. These ideas overlap substantially with AWS guidance, but implementation details depend on GCP’s resource hierarchy, IAM, networking, and service behavior.

Applying a framework

A practical review can use the following sequence:

• Define business outcomes and measurable service objectives.
• Identify users, data, dependencies, and trust boundaries.
• List failure modes, including regional, dependency, credential, and configuration failures.
• Select a deployment pattern and justify service choices.
• Define access, logging, backup, recovery, and change controls.
• Estimate cost using expected usage rather than only resource prices.
• Test assumptions through prototypes, load tests, restore tests, and failure exercises.
• Revisit the design as workload requirements change.

Availability is often discussed using a service-level objective (SLO), but availability percentages must be interpreted over a stated period. If a service is available for time A during total observation time T, its measured availability is:

Here, A and T must use the same time unit. This simple ratio does not predict future availability, and it does not replace a provider’s contractual service-level agreement. For example, over a 30-day period of 43,200 minutes, a 99.9% target permits approximately 43.2 minutes of unavailability, assuming the target is defined over that period and excludes no special cases. In practice, the contract’s measurement rules govern.

Recovery objectives should also be explicit. The recovery point objective (RPO) is the maximum acceptable amount of data loss measured in time; the recovery time objective (RTO) is the target time to restore service. RPO and RTO are requirements, not automatically delivered properties of a backup system. They must be validated through restoration and recovery testing.

5. Security, Governance, and Cost Foundations

Security begins with identity. Apply least privilege: grant only the permissions required for a defined task, for the shortest practical duration, at the narrowest appropriate scope. Prefer groups and roles over individual permission exceptions. Separate production from development. Protect the root or super-administrator account with multifactor authentication and avoid routine use.

Use preventive and detective controls together. Preventive controls restrict actions through policies, organization constraints, service controls, and network rules. Detective controls use audit logs, configuration monitoring, threat detection, and alerts. Logs should be centralized, protected from unauthorized alteration, and retained according to operational and legal requirements.

Data governance includes classification, encryption, retention, deletion, residency, and access review. Encryption at rest and in transit is important, but key management also requires rotation, separation of duties, recovery planning, and careful control of key administrators. Privacy laws and sector regulations may impose restrictions on personal, financial, health, or government data. A cloud provider’s compliance certification does not transfer the customer’s entire compliance responsibility to the provider.

Cost governance should begin before deployment. Assign AWS tags or GCP labels where supported, separate environments, create budgets and alerts, review idle resources, and select appropriate purchasing models. Cost estimates must include data transfer, managed-service charges, storage operations, logs, backups, and support plans—not merely compute instances.

6. Illustrative Case: A Multi-Environment Student Portal

This is a fictional illustrative case.

Background

A college operates a student portal that serves course schedules, notices, and assignment metadata. The development team wants to deploy a new version using either AWS or GCP. The portal has moderate daytime traffic, must protect student information, and should continue operating if one virtual machine fails.

Problem

The initial proposal uses one virtual machine, a local database, administrator access shared by developers, and manual console deployment. It has no tested backup, no cost budget, and no clear distinction between testing and production.

Analysis

The design has single points of failure, weak accountability, and high change risk. A local database may be lost with the machine. Shared administrator credentials prevent reliable attribution. Manual deployment increases configuration drift. The workload does not necessarily require a complex Kubernetes platform; additional orchestration could create unnecessary operational burden.

Approach and solution

The team creates separate development and production boundaries: separate AWS accounts within an Organization or separate GCP projects under suitable folders. A managed relational database is selected instead of a database installed on the application host. The application is deployed as a managed container service or an autoscaled compute group behind a load balancer. At least two failure domains are used where the selected service supports them.

Access is granted through federated identities and short-lived roles or service identities. Developers cannot directly modify production resources except through an approved deployment pipeline. Secrets are stored in a managed secret service rather than source code. Logs, metrics, and alerts are configured before launch. Database backups are enabled, retention is documented, and a restoration exercise is scheduled.

The architecture review asks: What happens if an instance fails? What happens if credentials are exposed? How is a deployment rolled back? How much data loss is acceptable? How will unexpected traffic affect cost? Which student data may be stored in the selected Region? These questions are more valuable than simply listing products.

Outcome

The revised design reduces the number of manually operated components, improves accountability, and provides a tested recovery path. It may cost more than the original single-machine design during very low usage, but it substantially reduces operational and data risks. The team documents the trade-off and reviews usage monthly.

Learning points

• Environment separation is both a governance and reliability practice.
• Managed services can reduce operational work but do not remove configuration responsibility.
• High availability requires eliminating relevant single points of failure, not merely buying a larger machine.
• A framework review produces evidence-based decisions when requirements and trade-offs are documented.

7. Limitations and Contemporary Practice

Cloud abstractions can conceal complexity. A managed service still depends on quotas, regional capacity, identity configuration, network paths, provider incidents, and correct application behavior. Multi-region and multi-cloud designs can improve resilience in selected situations, but they increase data synchronization, observability, skills, testing, and cost requirements. They should be justified by explicit risks rather than adopted as slogans.

Provider services evolve rapidly. Names, console layouts, pricing, supported regions, and recommended practices change. Professionals should consult current provider documentation, pricing pages, service quotas, and security guidance before implementation. Architecture frameworks are useful lenses, not guarantees. A workload can satisfy a checklist and still fail because requirements were misunderstood or controls were not tested.

Artificial intelligence can assist with configuration analysis, log summarization, code generation, and anomaly detection. However, generated infrastructure or policy should be reviewed like any other untrusted change. Do not place confidential data into an AI tool without authorization, and retain human accountability for access, privacy, safety, and production decisions.

Best-Practice Checklist

• Use separate environments and appropriate account or project boundaries.
• Confirm identity, region, account, and project before every change.
• Prefer temporary credentials, federation, multifactor authentication, and least privilege.
• Deploy repeatably through reviewed IaC and CI/CD pipelines.
• Tag or label resources and establish budgets, quotas, and ownership.
• Centralize logs and monitor security, reliability, performance, and cost signals.
• Define RPO, RTO, and SLOs in business terms and test them.
• Design for failure and remove important single points of failure.
• Select services from requirements rather than superficial name matching.
• Review architecture continuously as usage, threats, and provider capabilities change.

Chapter Summary

AWS and GCP organize cloud resources through different but conceptually related hierarchies. AWS emphasizes accounts within Organizations and OUs, while GCP emphasizes projects within organizations and folders. Regions and Availability Zones or zones provide geographic and failure-domain structure. Consoles support exploration, CLIs support repeatable commands and operations, and SDKs support programmable integration.

AWS and GCP offer broadly comparable capabilities for compute, storage, databases, networking, identity, monitoring, and containers, but equivalent names do not imply equivalent behavior. Service selection must follow workload requirements, security constraints, operational capability, and cost considerations.

The AWS Well-Architected Framework uses operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability as its six pillars. Google Cloud Architecture Framework guidance addresses closely related concerns through system design, operational excellence, security, reliability, performance, cost, and sustainability. Both frameworks are decision disciplines: they encourage explicit requirements, failure analysis, measurement, automation, governance, and continuous improvement.

A professional cloud deployment separates environments, applies least privilege, protects and observes data, controls cost, uses automation, and tests recovery. Cloud responsibility is shared; managed services reduce some operational tasks but do not eliminate customer responsibility for configuration, identities, data, and application behavior.

Key Terms

AWS account: A fundamental AWS resource, security, and billing boundary.

AWS Organization: A management structure for multiple AWS accounts.

Organizational unit: A group of AWS accounts used for administration and policy application.

GCP organization: The top-level Google Cloud resource hierarchy associated with an enterprise identity.

GCP project: A primary GCP boundary for APIs, resources, quotas, IAM, and usage records.

Folder: A GCP grouping layer between an organization and projects.

Region: A geographic cloud location containing one or more failure domains.

Availability Zone: An isolated AWS location within a Region.

Zone: A localized GCP failure domain within a region.

IAM: Identity and Access Management; controls authentication and authorization.

Least privilege: Granting only the permissions necessary for a task.

CLI: Command-line interface used to issue cloud API operations.

SDK: Software development kit used by programs to call cloud APIs.

Infrastructure as code: Version-controlled expression of desired infrastructure configuration.

RPO: Recovery point objective; maximum acceptable data loss expressed as time.

RTO: Recovery time objective; target time for restoring service.

SLO: Service-level objective; a measurable target for service performance or availability.

Well-Architected Framework: A structured method for evaluating cloud architecture decisions.

Tag or label: Metadata attached to resources for organization, ownership, automation, or cost analysis.

Shared responsibility model: Division of security and operational responsibilities between provider and customer.

Review Questions

5 Short Answer Questions

1. What is the primary operational difference between an AWS account and a GCP project?
2. State one appropriate use for a cloud console, CLI, and SDK.
3. Why is service mapping between AWS and GCP not a simple product-name substitution?
4. Define RPO and RTO.
5. List the six AWS Well-Architected Framework pillars.

5 Long Answer Questions

1. Explain the AWS and GCP resource hierarchies and discuss how they support environment separation and governance.
2. Compare console, CLI, SDK, and infrastructure-as-code workflows in terms of repeatability, visibility, and automation.
3. Explain how least privilege, logging, multifactor authentication, and temporary credentials contribute to cloud security.
4. Describe how a team should conduct a Well-Architected review for a new web application.
5. Discuss the benefits and limitations of using managed services and multi-cloud strategies.

3 Analytical / Application Questions

1. A development team has placed production and testing resources in one project or account and uses shared administrator credentials. Analyse the risks and propose a revised governance model.
2. A service must tolerate the failure of one virtual machine and restore data within four hours while losing no more than fifteen minutes of updates. Identify the relevant reliability requirements and propose tests to validate them.
3. Choose AWS or GCP for a small event-driven application. Justify your compute, storage, identity, monitoring, and cost-control choices using at least four Well-Architected principles.

Multiple Choice Questions with Answers

Question 1

Which AWS construct is primarily used to group and govern multiple AWS accounts?

A. Availability Zone

B. AWS Organization

C. Security group

D. S3 bucket

Correct Answer: B. AWS Organization

Question 2

What is the primary management boundary for APIs, quotas, IAM, and many resources in GCP?

A. Zone

B. Folder

C. Project

D. Billing invoice

Correct Answer: C. Project

Question 3

Which tool is most appropriate for a Python program that must call a cloud API conditionally and handle errors?

A. Web console

B. SDK

C. Region

D. Availability Zone

Correct Answer: B. SDK

Question 4

Which AWS Well-Architected pillar focuses on protecting systems and information?

A. Security

B. Performance efficiency

C. Sustainability

D. Cost optimization

Correct Answer: A. Security

Question 5

A service is available for 99.9% of a 30-day period containing 43,200 minutes. Approximately how much unavailability does this percentage permit?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 6

What does an RPO specify?

A. The maximum acceptable data loss measured in time

B. The maximum number of users in a project

C. The time required to deploy a new region

D. The provider’s monthly invoice date

Correct Answer: A. The maximum acceptable data loss measured in time

Question 7

Which practice best supports least privilege?

A. Giving every developer permanent administrator access

B. Using shared root credentials for convenience

C. Granting only required permissions at the narrowest suitable scope

D. Disabling audit logs to reduce storage cost

Correct Answer: C. Granting only required permissions at the narrowest suitable scope

Question 8

Why should AWS and GCP service mappings be treated as approximate?

A. The providers use identical APIs but different logos

B. Equivalent services can differ in data models, defaults, pricing, and operational behavior

C. Cloud providers do not offer storage services

D. Regions have no effect on cloud architecture

Correct Answer: B. Equivalent services can differ in data models, defaults, pricing, and operational behavior

Question 9

Which practice most directly improves reproducibility of infrastructure changes?

A. Manual console changes without records

B. Shared passwords

C. Infrastructure as code stored in version control

D. Disabling deployment reviews

Correct Answer: C. Infrastructure as code stored in version control

Question 10

Which statement about managed cloud services is correct?

A. They eliminate all customer security responsibilities

B. They require no monitoring or configuration

C. They can reduce operational work but do not remove customer responsibility for correct use

D. They guarantee that an application cannot fail

Correct Answer: C. They can reduce operational work but do not remove customer responsibility for correct use