Every cloud architecture decision is a bet on the future. Some bets pay off. Others compound silently into technical debt that gets prohibitive to unwind. I have been watching this play out at QIT Solutions for over two decades. The decisions that look fine in year one are the ones that hurt most by year five.
The problem is that nobody is making bad cloud decisions out of laziness. They are making the easiest decision available at the time, given the information they had. The real question is which of today's easy decisions will look obvious in 2031, and which will look like a trap.
The vendor lock-in spectrum
Lock-in is not binary. It is a spectrum, and pretending otherwise is how organizations end up trapped in places they never meant to land. Every managed service you adopt trades operational simplicity for reduced portability. That is often a great trade. The problem is making the trade without understanding the long-term implications.
I categorize every cloud service into one of three buckets when I review a client's stack:
- Commodity: Available from any provider with similar pricing and capability. Object storage, virtual machines, basic networking, managed Postgres, managed Redis. Optimize for cost. The switching cost is real but bounded, so use the cheapest reliable option that fits.
- Differentiating: Provider-specific but replaceable in 6-12 months with deliberate effort. Most managed Kubernetes flavors, identity services, queue/event services, container orchestration. Optimize for productivity now, but maintain an exit plan you could actually execute. If you cannot describe the migration path in one paragraph, you do not have a plan.
- Strategic: Deep platform integration where the lock-in is the value. SageMaker pipelines, Vertex AI, Azure ML Studio, BigQuery's analytics fabric, AWS Lambda Edge functions tied to CloudFront. Only adopt these when the competitive advantage clearly justifies the dependency. And document why future you said yes.
Most engineering teams treat all three categories the same. They optimize the commodity tier for productivity (paying premium prices for object storage when they could be paying half) and the strategic tier for cost (avoiding the platform integration that would actually win the market). The result is a cloud bill that is too high and a feature set that is too thin.
The multi-cloud trap
Here is a contrarian take that I get pushback on every time I make it: most organizations pursuing multi-cloud are making a mistake. Real multi-cloud, meaning running production workloads simultaneously across AWS, Azure, and GCP, adds enormous operational complexity for marginal benefit.
What most organizations actually need is multi-cloud capability, not multi-cloud operations. Those are very different things.
- Multi-cloud capability means your architecture could run on a second cloud if it had to. Your services are container-packaged. Your data layer uses portable formats. Your CI/CD does not depend on a single provider's primitives. You could migrate in a quarter if you needed to.
- Multi-cloud operations means you actually run workloads across two or three clouds at the same time. Now you need cross-cloud networking, cross-cloud identity, cross-cloud observability. Your engineers context-switch between three IAM models. Your finance team reconciles three sets of egress charges.
Capability is cheap insurance. Operations is permanent overhead. The 2-3× engineering cost of running multi-cloud rarely pays for itself in the resilience or negotiating leverage you supposedly get. AWS does not actually care that you have a Pulumi config that could deploy to GCP. They care about your committed spend.
The few organizations that genuinely benefit from multi-cloud operations have one of three real reasons: regulatory requirements that mandate it (and even then, usually a hybrid on-prem + single cloud is fine), specific workloads where one cloud is dramatically better (BigQuery for petabyte analytics, Azure for Microsoft-stack integrations), or genuine vendor dispute risk where you are betting your business on someone whose terms could change overnight. If none of those describes you, single-cloud with multi-cloud capability is the right answer.
The decisions that haunt you most
After enough cloud migrations and post-mortems, the decisions that come back to bite organizations are not random. They cluster around the same five patterns:
1. Data gravity decisions
Your data is where your lock-in actually lives. Compute is portable. Code is portable. Three petabytes of data sitting in S3 with cross-region replication and Glacier lifecycle policies. That is not portable, no matter how loudly your architects insist otherwise.
The data-gravity decisions that haunt you in five years: choosing a proprietary analytics format (BigQuery, Synapse, Redshift columnar) before you understand whether the analytics use case justifies the dependency, picking a managed database whose snapshot/dump format only restores back into the same product, and accepting the egress charges of moving 100 TB out of your provider as a hypothetical "future problem." That future arrives faster than people think.
2. Identity decisions
Identity is the hardest thing to migrate. Once 200 SaaS apps are wired to Azure Entra ID (or Okta, or Auth0), changing identity providers is a 6-month project that touches every team. The decision to standardize on a particular identity stack at year one becomes a 15-year commitment by year three. The right move is to pick deliberately, document why, and build identity abstractions thick enough that you could swap underneath.
3. Serverless vs container decisions
Lambda is a productivity superpower for the right workload and a trap for the wrong one. Cold starts, vendor-specific event sources, IAM permission models, observability tooling. They all bind you to one provider. For high-throughput services or anything you might want to run on-prem someday, containers are usually the right answer even when serverless looks cheaper at low scale.
4. Observability stack decisions
CloudWatch / Stackdriver / Azure Monitor are convenient on day one and insufficient by month six. Then you bolt on Datadog or New Relic, but your traces still flow through cloud-native pipelines that do not export cleanly. By year three, you have three observability tools paying three vendors and answering different questions. Picking an observability stack independent of your cloud (OpenTelemetry, Prometheus, Grafana, or a single SaaS that handles all three clouds) is the kind of boring decision that compounds well.
5. ML/AI platform decisions
This is the new big one. The AI platform you commit to in 2026. Whether you pick SageMaker, Vertex, Azure AI Foundry, OpenAI's API directly, or some specialized vendor will determine which models and which pricing curves you have access to in 2030. The space is moving fast enough that any "definitive" choice today is wrong in 18 months. The right move is to build behind an abstraction layer (LangChain, LlamaIndex, or your own thin SDK) so you can swap providers without rewriting application code. The teams that wired GPT-4 directly into their app in 2023 are now stuck or rewriting; the ones who built behind an abstraction switched to Claude or Gemini in an afternoon when the pricing or capability shifted.
How I help clients decide
When I sit down with a CTO to review their cloud architecture, the conversation usually does not start with technology. It starts with three questions:
What does this organization look like in five years? Are you scaling to 10× the headcount? Going multi-region? Getting acquired? Each of those changes which decisions matter. A startup that expects to be acquired by a Microsoft-stack enterprise should not pick GCP for anything strategic, even if AWS or GCP is technically better today.
Where are you actually constrained? Sometimes the answer is engineering hours. Sometimes it is dollars. Sometimes it is regulatory. The right architecture is the one that releases the binding constraint, not the one that optimizes the unconstrained dimension. Most cloud architecture mistakes I see come from optimizing engineering productivity when the binding constraint was actually compliance, or vice versa.
What do you regret about your last architecture? This is the most useful question. Almost every CTO can name 1-2 decisions from their last role that they would do differently. Those answers map directly to the decisions they are about to repeat in this role, in slightly different form. Naming the regret out loud makes it harder to repeat.
For a deeper look at the regulatory side of this, particularly data sovereignty as a constraint, see the CTO guide to data sovereignty in 2026. And if your organization keeps starting these conversations and never finishing them, the patterns I see in why digital transformations stall usually apply.
The honest truth about cloud architecture decisions
You will get some of these wrong. Every CTO does. The goal is not perfect decisions. The goal is recoverable ones. Build optionality where the cost of optionality is low (commodity tier, observability, identity abstractions). Spend lock-in deliberately where it earns its keep (strategic tier, only when the competitive advantage is real). And write down why you said yes to the dependencies you accepted, so the version of you that has to revisit the decision in 2031 can understand what you were thinking.
The cloud architecture decisions that haunt you in five years are rarely the ones that looked obviously wrong at the time. They are the ones that looked obviously right and stayed unchallenged for too long. Calendar a quarterly review of your top three cloud bets. Be willing to admit when one of them is no longer paying off. The best architects I work with treat their architecture as a living artifact, not a monument.
Frequently asked questions
What is the 3-4-5 rule in cloud computing?
The 3-4-5 rule is a heuristic some architects use: 3 availability zones, 4 nines of availability target, 5 years of architectural lifespan before major rework. It is more mnemonic than science. Useful as a sanity check on whether your architecture is over-engineered for a startup or under-engineered for an enterprise. Most teams need fewer nines than they think and more architectural lifespan than they plan for.
How do I avoid vendor lock-in on AWS, Azure, or GCP?
You do not avoid it. You spend it deliberately. Use commodity-tier services (S3, EC2, managed Postgres) where switching cost is low. Build abstractions in front of differentiating services so you could swap them in 6-12 months. Only adopt strategic-tier services (SageMaker, BigQuery, deeply integrated Lambda) when the platform advantage is the actual reason you are buying. Document the trade.
Should I go multi-cloud to avoid vendor lock-in?
Probably not. Multi-cloud operations (running production across two clouds simultaneously) costs 2-3× the engineering effort and rarely returns that investment in resilience or pricing leverage. Multi-cloud capability (architecting so you could move if you had to) costs much less and gives you most of the benefit. Pick single-cloud + capability unless you have a specific regulatory, workload, or vendor-risk reason to actually run multi-cloud.
What is the difference between multi-cloud and hybrid cloud?
Hybrid cloud combines public cloud with on-premises or private cloud infrastructure. Multi-cloud combines two or more public cloud providers. Hybrid is more common and often necessary for regulatory or latency reasons. Multi-cloud is rarer and usually less justified than its proponents claim.
How often should I review my cloud architecture?
Quarterly review of the top 3-5 architectural bets, with an annual deeper review of the full stack. The point is not to redesign every quarter. The point is to catch decisions that have stopped earning their keep before they compound. Most organizations skip this and discover their architecture problems through outages or finance complaints, both of which are more expensive than a 90-minute meeting every three months.
About the author
Jess Coburn runs QIT Solutions, a managed services firm that has handled cloud architecture, infrastructure, and IT operations for hundreds of small and mid-sized businesses since 2002. He writes about practical IT operations, cloud trade-offs, and where the cost of complexity actually shows up. More posts on cloud and CTO strategy live on the blog, and you can find him on LinkedIn.