Comparing Google Cloud and Microsoft Azure

Prerequisites and outcomes

Prerequisites. Read the preceding Amazon Web Services (AWS) request-path chapter and the earlier networking lessons. The AWS chapter supplies concrete meanings for Region, Availability Zone, Domain Name System (DNS) answer, load-balancer listener, application target, object, and relational transaction. A reader arriving directly should understand that a cloud request crosses separately observable DNS, transport, application, and data stages through protocols such as Hypertext Transfer Protocol (HTTP).

After this chapter, you can:

• translate an application architecture among Amazon Web Services (AWS), Google Cloud, and Microsoft Azure without claiming that similarly named products behave identically;
• compare organization and billing hierarchies, geographic scopes, request-routing products, compute choices, managed PostgreSQL, object storage, identity, and observability;
• build and test a provider-neutral latency budget with milliseconds as the unit; and
• identify which comparison claims require a current product, region, quota, and pricing check.

Provider catalogs change frequently. Product names, supported regions, feature tiers, defaults, and quotas in this lesson are current as of July 2026. The durable subject is the method: name a workload requirement, locate the provider control that implements the requirement, collect evidence, and test the resulting path.

The same bookstore, a different procurement decision

CampusCart's university is renewing a hosting agreement. One architecture group proposes Google Cloud because another research unit already uses Google identity and billing. A second group proposes Azure because the university manages workforce accounts in Microsoft Entra ID. The existing AWS deployment serves 5,000 daily users, normally completes 80 HTTP requests per second, and reaches 400 completed HTTP requests per second during registration. PostgreSQL stores orders, while object storage holds book images.

The procurement team asks, “Which provider has the equivalent of the current AWS products?” A catalog-matching answer would be misleading. A Google Cloud global external Application Load Balancer can use a single anycast IP address with backends in multiple regions. An AWS Application Load Balancer is a regional endpoint. Azure Front Door, Azure Application Gateway, and Azure Load Balancer operate at different network scopes and protocol levels. All products distribute traffic, but the traffic entry point, supported protocols, failure scope, health mechanism, and billing dimensions differ.

The engineering team therefore traces one checkout on each proposed platform. The team also records the administrative parent of every deployed object, the geographic location, the identity used by application code, and the producer of every operational artifact. A translation becomes credible only when the translated deployment produces the required behavior under measurement.

What the engineers can observe

The browser produces the same initial evidence on all three providers: DNS timing, connection timing, Transport Layer Security (TLS) timing, HTTP status, bytes, and time to first response byte. Provider choice does not change what the browser directly establishes. Provider choice changes the managed endpoints that receive the packets and the artifacts available inside the provider network.

Google Cloud Load Balancing can produce request logs in Cloud Logging when logging is configured for the selected load-balancer type and backend. A log entry can identify the forwarding or URL-map decision, backend, status, latency, and request properties. Google Cloud's load-balancer implementation produces the entry. The CampusCart application must separately produce an application request identifier and database timing if the team needs an end-to-end correlation.

Azure Front Door or Application Gateway can send access and health-probe categories to Azure Monitor destinations through configured diagnostic settings. The chosen Azure product produces those entries. Fields and category names depend on product and diagnostic schema. Azure Resource Health and Azure Activity Log answer different questions: platform health describes provider-side resource health, while the Activity Log describes control-plane actions against Azure resources. Neither artifact is a substitute for the application's own checkout entry.

An inventory export supplies administrative evidence. Google Cloud Resource Manager represents an organization at the root, optional folders below it, projects below folders or the organization, and product resources inside projects. Policies attached above a project can be inherited downward. Azure Resource Manager places management groups above subscriptions and resource groups within subscriptions; Azure resources reside in resource groups. Microsoft Entra tenants supply identity context, but a tenant is not the same object as a subscription. AWS Organizations groups AWS accounts under a management account and optional organizational units. The three hierarchies solve related governance problems with different parent types and lifecycle rules.

Translate requirements, not names

The following table is a starting map, not a declaration of equivalence.

| Workload need | AWS example | Google Cloud example | Azure example | Comparison question | |---|---|---|---|---| | Administrative isolation and billing scope | AWS account in AWS Organizations | Google Cloud project under a folder or organization | Azure subscription under a management group | Where do quotas, invoices, inherited policy, and blast radius attach? | | Private IP network | Amazon Virtual Private Cloud (VPC) | Virtual Private Cloud network | Azure virtual network | Is the network regional or global, and what does a subnet's region or zone mean? | | Public DNS | Amazon Route 53 | Cloud DNS | Azure DNS | Which authoritative name servers answer, and how is health-based routing implemented? | | HTTP entry and routing | Application Load Balancer; other AWS edge products for global entry | Global or regional external Application Load Balancer | Azure Front Door or Application Gateway | Where does TLS terminate, what is the routing scope, and which backends are supported? | | Virtual-machine fleet | Amazon Elastic Compute Cloud Auto Scaling group | Compute Engine managed instance group | Azure Virtual Machine Scale Sets | How are health, image rollout, placement, warm-up, and scale-in controlled? | | Managed application platform | AWS App Runner, Elastic Beanstalk, containers, or functions depending on requirements | Cloud Run, App Engine, containers, or functions depending on requirements | Azure App Service, Container Apps, containers, or functions depending on requirements | Which runtime and network responsibilities remain with the customer? | | Managed PostgreSQL | Amazon Relational Database Service for PostgreSQL or Aurora PostgreSQL-Compatible Edition | Cloud SQL for PostgreSQL or another selected database | Azure Database for PostgreSQL | What topology, failover, backup, connection, extension, and version behavior applies? | | Object storage | Amazon Simple Storage Service (S3) | Cloud Storage | Azure Blob Storage | What are the consistency, retention, replication-location, authorization, and egress rules? | | Workload identity | AWS Identity and Access Management role credentials | Attached service account or workload identity mechanism | Managed identity or workload identity mechanism | Which principal obtains a short-lived token, and which policy authorizes the action? | | Operations evidence | CloudWatch, CloudTrail, and product logs | Cloud Monitoring, Cloud Logging, and Cloud Audit Logs | Azure Monitor, Activity Log, and product diagnostic logs | Which producer creates each measurement or event, and what collection must be enabled? |

Several nearby terms require care. A Google Cloud project is not merely a folder for resources. A project is the fundamental application programming interface (API), billing-association, and permission context for many Google Cloud operations. An Azure resource group is a lifecycle and management container inside a subscription; an Azure resource can belong to only one resource group at a time. An AWS account supplies a strong administrative and billing isolation scope and can be governed through AWS Organizations. Moving a design among providers therefore requires a governance translation before product deployment begins.

Network scope also differs. A Google Cloud VPC network is a global resource, while its subnets are regional. An Amazon VPC belongs to one AWS Region, and its subnets belong to Availability Zones. An Azure virtual network belongs to a region, while availability-zone support depends on the resource type and region. A copied diagram that labels every box “VPC” hides those scope differences and can lead to incorrect routing or recovery assumptions.

One checkout path on each platform

An AWS regional path can use Route 53, an Application Load Balancer in two zones, application targets, Amazon Relational Database Service (Amazon RDS) for PostgreSQL, and Amazon Simple Storage Service (Amazon S3). A Google Cloud path can use Cloud DNS, a global or regional external Application Load Balancer, a managed instance group or Cloud Run backend, Cloud SQL for PostgreSQL, and Cloud Storage. An Azure path can use Azure DNS, Azure Front Door for global application entry or Application Gateway for regional web routing, Virtual Machine Scale Sets or App Service, Azure Database for PostgreSQL, and Blob Storage.

Each path still performs causal steps. A resolver obtains an address. A client opens a transport connection. A frontend accepts TLS and selects a backend. Application code authenticates Maya, obtains database connectivity, executes a transaction, and returns a response. Object retrieval follows a separately authorized path. Provider products implement those actions at different scopes; no brand removes the need to measure the actions.

The word global needs a named object. A global Google Cloud load balancer can present a global frontend and use backends in multiple regions for supported configurations. A globally distributed frontend does not automatically make CampusCart's single-region PostgreSQL database multi-region. Azure Front Door can direct traffic among regional origins, but a single regional database remains a regional dependency. Route 53 can direct clients among regional AWS endpoints, but DNS routing alone does not copy orders between databases.

A latency budget with units and assumptions

CampusCart sets a 95th-percentile objective of 500 milliseconds for a warm checkout request. The percentile means that at least 95 percent of qualifying checkout requests complete in 500 milliseconds or less during the measured interval. The team decomposes the browser-observed duration into serial stages for a first approximation:

The variables use milliseconds per checkout. The connection stage includes Transmission Control Protocol (TCP) and TLS. A measured candidate budget is:

| Stage | Budget | |---|---:| | DNS lookup | 15 ms | | TCP and TLS connection | 55 ms | | Provider frontend routing | 20 ms | | Application work excluding database | 90 ms | | PostgreSQL transaction | 170 ms | | First response byte through body completion | 60 ms | | Estimated total | 410 ms |

The 90-millisecond margin between 410 and 500 milliseconds is not spare capacity in a universal sense. The model assumes a fresh DNS and transport path, serial stages, a warm application target, one database transaction, a controlled response size, and no retry. Reused connections can remove much of the DNS and connection work. Parallel calls can make addition overestimate elapsed time. Queuing and retries can make the estimate underestimate tail latency. Clock disagreement prevents safe subtraction between unrelated hosts unless the evidence supplies a correlation method and synchronized time.

The budget predicts where a provider migration can spend time without violating the objective. A candidate platform that adds 80 milliseconds of application-to-database network time consumes most of the margin. The calculation does not rank providers. Only measurements from equivalent regions, datasets, request mixes, compute sizes, database tiers, and connection policies support a comparison.

An empirical cross-provider test

Deploy the same minimal checkout-shaped application in approved nonproduction projects or subscriptions. Use the same application build, response bytes, synthetic dataset size, PostgreSQL schema, connection-pool limit, client region, and load schedule. Choose approximately comparable compute and database capacity, then disclose every mismatch. Increase offered traffic from 40 to 400 requests per second in ten steps. “Offered requests per second” means requests started by the generator divided by test seconds; “completed requests per second” means responses completed by the generator divided by the same interval.

Preserve browser or load-generator timings, frontend access entries, backend request entries, database duration, error codes, healthy-backend count, and cost-export identifiers. Expected evidence should show that frontend time remains a minority stage for a warm regional request and that application or database queuing grows near a capacity limit. A result in which one provider is faster can reject equality under the tested configuration, but the result cannot establish a universal provider ranking. Alternative explanations include unequal instance processors, database storage tiers, network tiers, cold starts, quota throttling, log-sampling differences, and a client that is geographically closer to one region.

Worked investigation: a false portability assumption

Initial question. Why does the Google Cloud CampusCart prototype return fast image responses but intermittently time out during order creation at 400 requests per second?

Operating conditions. The prototype uses a global external Application Load Balancer, backends in two regions, one Cloud SQL for PostgreSQL instance in a single region, and Cloud Storage for images. The load generator runs from two geographic locations. Application builds and response sizes match.

Evidence collected. Frontend request entries identify healthy backends in both application regions. Application entries show that requests sent to the region without the database wait longer for database connections and network responses. Database measurements show a connection ceiling during the peak. Image requests avoid PostgreSQL and remain fast. Resource inventory confirms that the database exists only in the first region.

Interpretation. The global frontend distributed application requests farther than the single-region database topology could support efficiently. Additional application backends increased concurrent database demand but did not add database write capacity.

Proposed intervention and prediction. Constrain write-serving application backends to the database region for the current architecture, or design and validate an explicit multi-region data strategy with conflict, consistency, recovery, and cost requirements. The constrained design predicts lower database network time and fewer connection timeouts, with less regional failure tolerance than a valid multi-region data design.

Observed or calculated result. A controlled replay with write traffic pinned to the database region completes 397 requests per second, reduces 95th-percentile checkout latency from 1,420 to 465 milliseconds, and reduces checkout timeouts from 3.7 percent to 0.3 percent. Image delivery remains below its previous 95th-percentile latency.

Bounded conclusion. Regional alignment removed the reproduced cross-region database penalty under the tested load. The result does not establish regional disaster recovery or provider superiority.

Remaining uncertainty. The test does not measure a regional outage, database failover, cross-region data recovery, long-duration cost, or client populations outside the two generator locations.

Normal cases, failure cases, and qualifications

A normal translation keeps a browser-facing frontend, stateless application capacity in more than one failure location, a managed PostgreSQL topology that matches the availability objective, and object storage with explicit access rules. Provider-native identities give application code narrowly scoped access without embedding long-lived access keys in source code.

Failure and limiting cases require product-specific reading:

• A global frontend can stay reachable while every configured origin or backend is unhealthy.
• A zone-redundant frontend does not prove that the selected database tier or application plan is zone redundant.
• Autoscaling can reach a subscription, project, regional processor, address, or database-connection quota.
• Managed platforms reduce operating-system work but can restrict runtimes, networking, connection behavior, or startup time.
• Provider health checks can mark a shallow route healthy while a required dependency fails.
• Logs can be disabled, sampled, retained for too little time, or stored outside the required jurisdiction.
• A product can exist in a provider catalog but be unavailable in the required region or excluded from a compliance authorization boundary.

Current documentation must settle current product behavior. Google Cloud's load-balancing overview distinguishes global and regional load balancers and network tiers. Azure documentation distinguishes Front Door, Application Gateway, and Azure Load Balancer. Region and zone availability changes, so a 2026 table cannot serve as a permanent procurement fact.

Common reasoning errors

“Cloud Run equals Lambda equals Azure Functions.” Similar billing or execution characteristics do not establish equivalent event sources, maximum durations, concurrency, networking, identity, or regional availability. Start from the CampusCart execution requirement and verify each behavior.

“A project, account, and resource group are the same container.” The three objects occupy different hierarchy levels and carry different billing, policy, quota, and lifecycle effects.

“Global load balancing makes the application global.” A global traffic frontend does not replicate application state or PostgreSQL writes.

“Managed means the provider owns every failure.” The provider operates more of the runtime, while the customer still owns application code, identities, data choices, configuration, capacity selections, and recovery validation.

“The lowest single test latency identifies the best cloud.” A credible comparison controls geography, compute, database capacity, warm-up, request mix, network tier, and statistical interval. One sample establishes only one observed request.

Knowledge check

Question. CampusCart moves an AWS architecture diagram to Google Cloud by renaming an Amazon VPC to a Google Cloud VPC and each Availability Zone subnet to a Google Cloud zonal subnet. Which assumption is wrong?

Answer. An Amazon VPC is regional and an Amazon VPC subnet belongs to an Availability Zone. A Google Cloud VPC network is global and a Google Cloud subnet is regional. The team must redesign and verify routing, policy, and failure scope rather than rename the boxes.

Evidence exercises

Check

Choose the CampusCart request path and produce a three-provider table with one row for DNS, HTTP frontend, compute, PostgreSQL, object storage, workload identity, request evidence, and control-plane evidence. For every cell, include a direct official-document URL and a one-sentence scope qualification. Preserve the table as Markdown or comma-separated values.

Practice

Measure a public test endpoint or an approved sandbox from one client location. Collect at least 30 uncached connection samples and 30 reused-connection samples. Preserve the command or browser export, Coordinated Universal Time timestamps, DNS milliseconds, connection milliseconds, time to first byte, status, and response bytes. Submit the distributions and explain which differences are observed versus inferred. Do not compare provider quality unless equivalent workloads were controlled.

Challenge

Write a migration decision report for CampusCart. State requirements for 400 completed requests per second, 500-millisecond 95th-percentile checkout latency, two failure locations, PostgreSQL semantics, and object-image delivery. Compare one AWS, one Google Cloud, and one Azure design. Submit architecture diagrams, current region and quota evidence, a latency budget, an identity path, a failure test, and five unresolved product-specific questions.

Authoritative sources and further reading

Required reading

• Google Cloud resource hierarchy explains organizations, folders, projects, product resources, parentage, and policy inheritance.
• Google Cloud Load Balancing overview distinguishes internal and external, global and regional, proxy and passthrough, and network-tier behavior.
• Azure Resource Manager overview explains Azure management scopes and resource groups.
• Azure load balancing and content delivery routes readers among Front Door, Application Gateway, and Azure Load Balancer instead of treating them as one product.

Implementation and version-sensitive documentation

• Google Cloud global, regional, and zonal resources is useful for current location scope; recheck the page during design.
• Azure regions and availability zones describes the Azure geographic hierarchy and current zone concepts.
• Azure subscription and service limits documents changing default and maximum quotas that can invalidate a scale plan.
• AWS Regions and Availability Zones supplies the AWS comparison baseline.

Security and responsibility reference

• Google Cloud shared responsibility and shared fate explains which security work remains with a customer across infrastructure, platform, software, and function offerings.
• Microsoft shared responsibility in the cloud distinguishes customer and Microsoft work by service category.

Transition

Product translation exposes a deeper common mechanism. Every provider must decide whether a principal may act, store bytes with stated protection and consistency, recover from failure, and charge for measured consumption. The next chapter studies identity, data protection, reliability, observability, and cost as connected operating mechanisms rather than independent product menus.