For a mid-market SaaS product, all three major clouds will do the job. The differences that matter are rarely the ones in comparison tables - compute is compute, and headline instance pricing lands within a few percent. What actually differs is the managed service quality in specific areas, the enterprise relationship, and how much your team already knows. That last one is usually decisive and usually undervalued.
01Where they genuinely differ
Setting aside marketing, each provider has areas of real strength. The honest summary is that AWS has the broadest and most mature service catalogue, Azure has the strongest position in enterprises already invested in Microsoft, and GCP has the best data and Kubernetes story relative to its size.
| Area | Strongest | Notes |
|---|---|---|
| Service breadth and maturity | AWS | Almost always has a managed option |
| Enterprise / Microsoft estates | Azure | AD integration, EA pricing, procurement fit |
| Data and analytics | GCP | BigQuery remains a genuine differentiator |
| Kubernetes | GCP | GKE is the most polished managed offering |
| Regional coverage | AWS | Widest footprint for residency needs |
| Hiring pool | AWS | Most engineers have AWS experience |
02What actually drives cloud cost
Teams compare instance pricing and then get a bill dominated by things they never modelled. On a typical SaaS workload, compute is rarely the largest surprise - data transfer, managed database provisioning and idle non-production environments routinely are.
Egress in particular is where architecture meets billing. Cross-availability-zone traffic, chatty service-to-service calls and unoptimised media delivery generate charges that do not appear in any capacity plan. This is architectural cost, and it is far cheaper to design for than to optimise afterwards.
- Data egress and cross-AZ transfer - frequently underestimated.
- Managed databases provisioned for peak and never resized.
- Non-production environments running outside working hours.
- Orphaned volumes, snapshots and load balancers.
- Logging and observability ingestion at full verbosity.
03The multi-cloud question
Multi-cloud is usually pursued to avoid lock-in and usually delivers the opposite: you standardise on the lowest common denominator, forgo the managed services that make each provider worthwhile, and double your operational surface.
There are legitimate reasons - a regulatory requirement, a customer contractually demanding it, or an acquisition that arrived with a different estate. Avoiding hypothetical lock-in is not one of them for a mid-market company. The realistic hedge is keeping your architecture portable in principle: containers, infrastructure as code, and avoiding the most proprietary services where an equivalent exists.
04Managed services and where lock-in actually hurts
Managed services are the reason to use a cloud at all - running your own database is rarely a good use of a mid-market team's time. But lock-in varies enormously by service, and it is worth being deliberate about which forms you accept.
Managed Postgres is portable in practice; the data model transfers. A proprietary serverless data store with its own query semantics is not. Accept deep lock-in where the service is genuinely differentiating, and prefer portable equivalents where it is not.
| Category | Lock-in | Guidance |
|---|---|---|
| Managed Postgres / MySQL | Low | Use freely |
| Object storage | Low | Use freely; APIs are near-compatible |
| Kubernetes | Low | Portable by design |
| Managed queues | Medium | Abstract behind a thin interface |
| Proprietary NoSQL | High | Only where genuinely differentiating |
| Serverless platform features | High | Accept deliberately, not by drift |
05Making the decision
Rank the criteria honestly: existing team expertise, any residency requirements, the specific managed services you will actually depend on, and your procurement relationship. Price should be the last input rather than the first, because the difference between providers is small relative to the difference between disciplined and undisciplined usage of any one of them.
- What does the team already operate confidently?
- Do residency requirements narrow the options?
- Which two or three managed services will you genuinely depend on?
- Is there an existing enterprise agreement worth leveraging?
- Can you model cost at 10x current scale, including egress?
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.