Compare 2020 market measures without mixing definitions

Older cloud-computing articles often put vendor revenue figures in one table as if every figure meant the same thing. A combined “commercial cloud” number can include multiple product lines, while a hyperscale infrastructure estimate measures a narrower market. A 2020 quote about Google, Microsoft and Amazon cannot be directly compared without checking the period, currency, business definition and source methodology.

Market share can help a reader understand ecosystem maturity or provider adoption, but it is not a proxy for the availability of a specific service in a specific region. A smaller market footprint does not necessarily imply poor fit for one workload, and a vendor with a leading share may not meet a data-residency or operational constraint. When using historical rankings, label the source and year; for an investment or vendor choice in 2026, retrieve comparable fresh data separately.

Model one comparable workload before discussing price

Cloud pricing is not a simple hourly virtual-machine comparison. The bill can depend on instance family, storage class, provisioned capacity, egress, cross-zone traffic, managed databases, load balancers, monitoring, support and reservations or commitments. A meaningful comparison puts the same user-facing service and reliability target on each provider before reviewing any calculator output.

Choose a bounded example: an application handling 10,000 requests per day, retaining 200 GB of files, keeping 30 days of operational logs and needing service through one zone outage. Specify traffic patterns, peak concurrency, database engine, backup retention and geographic region. Then use official AWS, Azure and Google Cloud pricing tools to evaluate the same assumptions. Confirm product names, editions and rates directly; calculator results are estimates, not universal prices.

The most common hidden comparison errors are different recovery targets, omitted outbound traffic and inconsistent managed-service choices. A cheaper estimate that excludes backups or a standby database is not comparable to one that includes them. Record every assumption so a second engineer can reproduce the estimate.

Select services by technical boundaries and ownership

All three platforms offer ways to run compute, host containers, store objects, operate databases and analyze data, but their identity models, network constructs, service quotas and managed-product semantics differ. Calling three services “equivalent” based on marketing labels can hide differences that matter during an incident or migration.

For a basic web application, compare managed compute and database choices according to runtime, supported deployment pattern, identity access, network path, backup and telemetry requirements. For analytics or AI, include data movement, governance and evaluation constraints rather than reducing the decision to which platform has the most named services. Record what the team must manage itself and what the provider operates under the shared-responsibility boundary.

A useful exercise is to draw one end-to-end request and ask where authentication occurs, which policy allows storage access and how logs can reconstruct a failed transaction. If a service needs credentials, prefer workload identities and narrowly scoped permissions where supported. One provider may fit the team’s existing skills and tooling better even when another offers a similar feature set.

Compare startup support without assuming credits

AWS Activate, Microsoft for Startups and Google for Startups Cloud Program have offered combinations of credits, guidance or partnership resources. Their names and eligibility rules have evolved, and an archived 2020 credit amount is not a current offer. Check the provider’s official program site for country, company age, funding or partner prerequisites, supported product charges, credit expiry and restrictions.

Credits should not become the foundation of a workload’s long-term economics. Estimate a normal month after credits expire and calculate what migration would cost if the chosen service becomes more expensive or less appropriate. Startup support can reduce early experimentation cost, but security, reliability and data ownership still require explicit design.

For a small team, the highest-value benefit might be architecture support or incident guidance rather than the largest promotional amount. Evaluate whether the program makes a specific project easier to build and operate, then preserve acceptance terms and forecast costs without credits.

Design resilience around actual failure scenarios

Cloud vendor comparisons often emphasize the count of data centers or availability zones. Reliability instead depends on how an application uses fault domains and on whether critical dependencies are replicated or recoverable. A service placed in two zones can still fail if its single database, shared credentials or deployment system is not resilient.

Write two scenarios: loss of one availability zone and corruption of a database table through an application bug. The first calls for redundancy and traffic rerouting; the second calls for safe recovery of data, possibly from a versioned backup. Distributed availability does not replace restoration testing. Specify a recovery time objective and a recovery point objective with the business owner before deciding whether any multi-region design is justified.

Test recovery with synthetic data. Do not label an infrastructure diagram as an executed failover or infer that the most expensive provider setup necessarily has the strongest reliability.

Compare governance, identity and data location

Cloud governance begins with separate accounts or subscriptions/projects, roles, policies, audit trails and cost ownership. Before provisioning, identify the company’s access rules, regulatory constraints, retention limits and incident response procedures. Each platform has native governance tools, but the application must still define which identity can perform each operation and how the decision is audited.

Data residency can limit the regions and products available for a workload, and data transfer across borders or environments may require additional review. Do not use a historical market-share chart to answer an access or regulatory question. Ask the provider about the actual selected service’s availability and documentation, then test permitted and denied requests against the configuration that would be deployed.

Use a decision matrix rather than naming a winner

A lightweight decision matrix should distinguish hard requirements from preferences. Hard requirements may include residency, supported runtime, identity integration, contractual terms or a maximum tolerable outage. Preferences may include team familiarity, managed service breadth, analytics ecosystem and pricing. Weight only the preferences after filtering out providers that cannot meet the hard constraints.

For the same workload, score each remaining option on total expected cost, operational burden, security evidence, failure recovery and migration risk. Record what was confirmed from current documentation and what remains an assumption. A high score is a planning aid, not a guarantee that real costs or latency will match a spreadsheet.

The 2020 comparison remains interesting as history: it shows why market dominance, startup promotion and feature counts attracted attention at the time. A durable cloud choice in 2026 comes from a controlled workload comparison, not from declaring that the cloud “war” has a permanent winner.