Cloud Services Explained: Reading AWS, GCP, and Azure as Business Decisions
Choosing a cloud provider is not a question of which service is technically superior. It is a business decision that simultaneously determines three variables: cost structure, vendor dependency risk, and hiring market. When a startup says “we use AWS,” that single statement has direct implications for financial modeling and acquisition risk assessment.
Whether M&A professionals and VC investors can evaluate cloud choices with meaningful criteria makes a significant difference in the quality of technical due diligence. This article organizes the essential differences between the three major cloud providers and offers the perspective needed for investment and acquisition judgment.
Why Cloud Selection Is a Business Decision
To an engineer, this looks like a technical choice of which services to use. But from a management and investment perspective, it directly connects to three business variables.
1. Locking in Cost Structure
Cloud usage fees increase in proportion to product scale. As users grow, compute, storage, and bandwidth costs rise. This structure effectively requires thinking about the break-even point inclusive of cloud costs. In startup unit economics analysis, cloud costs are often classified as Cost of Goods Sold (COGS), directly affecting gross margin.
2. Dependency on Vendor-Specific Services
Clouds offer not just generic server resources (EC2/GCE/VM) but managed services — databases, queues, AI services, authentication. The more these are used, the higher the migration cost becomes. The question “can we move from AWS to another cloud in three months?” may yield the answer “not impossible, but it would require re-engineering worth hundreds of millions of yen.”
3. Direction of the Hiring Market
Engineer skillsets are tied to cloud platforms. Requirements like “AWS experience” or “GCP certified” only become meaningful once the cloud platform is decided. In Japan’s engineer market — where クラウド (cloud) skills are increasingly a standard hiring criterion — AWS has the largest pool of experienced candidates, followed by GCP and Azure. Changing cloud providers also means changing the premises of the hiring market.
The Essential Differences Between the Three Major Clouds
| AWS | GCP | Azure | |
|---|---|---|---|
| Market Share (approx.) | ~33% | ~11% | ~22% |
| Design Philosophy | Breadth of services and track record | Engineering sophistication | Microsoft ecosystem integration |
| Greatest Strength | Most services, proven track record, hiring market | AI/ML, data infrastructure, Kubernetes | Enterprise IT affinity, compliance |
| Hiring Market (Japan) | ◎ Largest | ○ Medium | ○ Medium (enterprise-leaning) |
| Cost Tendency | Can become expensive with many features | Competitive compute pricing | Advantageous with enterprise contracts |
| Typical Selection Reason | The de facto “start here” choice | Need AI/ML capabilities, GKE excellence | Office 365 / Active Directory integration |
AWS: What It Means to Be the De Facto Standard
AWS was launched by Amazon in 2006 and effectively defined the concept of cloud computing. It now offers over 200 services — its greatest strength and also the source of its complexity.
What “using AWS” means in investment judgment comes down to two things. First, it has the largest pool of engineers with experience, making team expansion easier. Second, it has the most abundant online documentation and community, tending to reduce problem-solving time.
The risk, however, is “overuse of managed services.” AWS has many services — DynamoDB (proprietary database), SQS (message queue), Kinesis (streaming) — that have equivalents in other clouds but carry high migration costs. As usage grows, AWS dependency deepens, weakening future negotiating leverage (price negotiations, SLA revisions).
GCP: Google’s Technical Excellence and Narrow Ecosystem
GCP takes the approach of “offering externally what Google uses internally.” Kubernetes (the de facto standard for container management), BigQuery (large-scale data analytics), and Vertex AI (ML platform) are all industry-leading services.
Particularly in AI/ML capabilities, GCP’s advantage is clear. Integration with TensorFlow (developed by Google), access to TPUs (AI-specialized chips), and the maturity of Vertex AI make it a compelling choice for startups whose core product revolves around AI functionality.
The weaknesses are a narrower hiring market and service discontinuation risk. Google has historically discontinued many products — Google+, Google Wave, Google Stadia, and others. GCP’s managed services carry a non-zero version of this same risk.
Azure: Connection to Enterprise IT
Azure has its greatest strength in the enterprise IT context. Active Directory (the standard for corporate authentication), seamless integration with Office 365, Teams, and SharePoint, and the fact that many companies in Japan and worldwide already have contracts with Microsoft all work in its favor.
A startup building enterprise-facing B2B services choosing Azure “to get adopted by customer IT departments” is a business-rational decision. The breadth of compliance certifications (HIPAA, SOC2, ISO27001, etc.) is also valued for products targeting regulated industries.
However, the startup ecosystem (OSS communities, YC-portfolio startups, etc.) is dominated by AWS, and the technical community around Azure is relatively smaller. B2C services and engineer-culture-driven startups tend toward AWS and GCP.
Realistic Assessment of Lock-in Risk
“Depending on a cloud provider is a risk” is a commonly heard statement, but the reality is more nuanced. Lock-in comes in stages.
The key question in assessing lock-in risk is not “what is the migration cost?” but “what is the probability that migration becomes necessary, and what is the impact?” For small and mid-sized startups, absorbing a 2x price increase from AWS is often cheaper than migrating away. The core issue is not demonizing lock-in, but whether the dependency cost is understood and consciously accepted as a choice.
The Overlooked Cost: Data Egress Fees
One of the most frequently overlooked cost factors is data transfer fees between clouds. All three major clouds charge nothing for data “ingress” (data coming in) but charge for “egress” (data going out). For data-intensive products (video, images, log analytics), egress costs can represent 20–40% of total cloud spending.
When evaluating an investment target with a data-aggregation business model, understanding the cloud’s egress cost structure directly affects the accuracy of financial modeling.
The Reality of Multi-Cloud Strategy
“Adopting multi-cloud to avoid dependence on a single provider” sounds reasonable but is more complex in practice.
Cases where multi-cloud works effectively are limited. First, when different regions have different regulatory requirements necessitating different clouds per region. Second, when specific capabilities are separated by purpose (e.g., AI/ML on GCP, enterprise integration on Azure). Third, when a company acquires another with a different cloud base through M&A, resulting in unintentional multi-cloud.
Startups adopting multi-cloud for risk diversification purposes typically incur increased costs and complexity. Managing two clouds in parallel requires engineers with expertise in both, and deployment pipelines, monitoring, and cost management all double. For startups competing with limited resources, focusing on one cloud is more rational in most cases.
When you hear “we’re multi-cloud,” the important judgment is whether that represents a strategic decision or a deferral of decision-making and historical accumulation.
Cloud Evaluation Checklist for Investment and M&A
Cost Structure Assessment
- What percentage of revenue/ARR do cloud costs represent? — For SaaS businesses, 10–25% is typically the benchmark. Above that suggests cost structure issues
- What is the scaling characteristic (rate of cloud cost increase vs. revenue growth)? — Ideally, when revenue doubles, cloud costs grow 1.5x. Linear or super-linear growth warrants investigation
- Are there cost optimization efforts in place? — Reserved instance, spot instance, Savings Plans utilization; regular cleanup of unused resources
Dependency Assessment
- Is primary data stored in exportable formats? — Dependency on cloud-specific compression formats or encryption schemes
- How far does managed service usage extend? — Are there OSS-replaceable alternatives, or is there deep dependency on proprietary services?
- Is there an egress cost estimate? — Has the transfer cost been modeled for scenarios where data volume grows significantly?
Operations Assessment
- How many engineers have cloud expertise? — A single-point-of-knowledge situation should be assessed as a bus factor (key-person risk)
- Is Infrastructure as Code (IaC) in place? — Is infrastructure managed as code via Terraform, CloudFormation, etc.? An indicator of reduced single-person dependency and reproducibility
- Is there a multi-region configuration? — Is there risk of a single regional failure taking down all services?
Summary: Reading Cloud Selection as “Strategic Readability”
The ultimate question in cloud selection assessment is the accountability behind “why did you choose this cloud?” If the reasoning aligns with the business characteristics (AI-centric → GCP, enterprise customer affinity → Azure, ecosystem breadth → AWS), then any cloud can be a valid choice.
The problem is when the only explanation is “we just kind of started using it” or “that’s what the founding CTO knew.” If a team cannot articulate the rationale for their cloud selection, it may indicate low readability of the overall technology strategy.
In post-acquisition integration (PMI) as well, understanding the cloud configuration is an important part of the initial assessment. Being able to accurately read cloud infrastructure directly connects to the ability to evaluate finance, risk, and hiring as an integrated whole.
Related Articles
Alongside cloud selection, language choice is another factor that determines a product’s technical foundation. Programming Language Guide for Investors and Executives organizes Python, TypeScript, Go, Rust, and others along business decision axes.
The overall framework for technical due diligence, including cloud evaluation, is covered in Tech Due Diligence Overview: 7 Evaluation Axes. For post-acquisition technical risks, see 10 Technical Risks Discovered After Investment as well.
Tied Inc. provides technical due diligence support for VCs and corporate M&A teams. For details on technical DD including cloud strategy evaluation, visit our investor services page or contact us.