Why "Cloud Native" Is Often Just "Vendor Bound"

The Seduction of Managed Services

When you start building on AWS (or Azure, or GCP), the first few steps feel like magic. No servers to provision. No databases to tune. Just click a button, and you have a globally-distributed, auto-scaling, fault-tolerant architecture.

This is "cloud native." At least, that's what the marketing tells you.

But let's be honest: using Lambda + DynamoDB + Step Functions + API Gateway + SQS + EventBridge + Cognito + Amplify + AppSync + S3 + CloudFront isn't an architecture. It's an entanglement with a single vendor's product suite.

And when you're that deep into a vendor's stack, you're not "cloud native." You're vendor bound.

The Hidden Lock-In Tax

Early-stage companies rarely think about portability. Why would they? Speed is everything. AWS gives you speed.

But as your architecture matures, you start feeling the squeeze:

• Cost creep: What started at $500/month is now $15,000/month—and nobody knows why.
• Data transfer fees: Moving 10TB out of AWS costs more than a year of competitive hosting elsewhere.
• API lock-in: You used DynamoDB's single-table pattern. Good luck migrating that to Postgres.
• Invisible ceilings: You hit Lambda's 15-minute timeout and now need to refactor your entire job processing architecture.

The worst part? You can't negotiate. AWS sets the price. You accept it, or you rearchitect from scratch.

This isn't "pay-as-you-go." It's "locked-in-and-compounding."

The Cloud as a Strategic Choice, Not a Default

I've spent 20 years building DDoS defense infrastructure at Link11. We use cloud providers—but selectively. The principle: use the cloud for what it does uniquely well. Own everything else.

Here's my decision framework:

✅ Use managed cloud services for:

• Global edge distribution (CloudFront, Fastly, Cloudflare)
• Ephemeral compute (Lambda, Cloud Run—when sub-second invocations actually make sense)
• Hosted identity/auth (Auth0, Cognito—because custom auth is a tar pit)
• Object storage (S3, GCS—but with lifecycle policies to control costs)

❌ Avoid managed services for:

• Core databases (Run Postgres yourself. It's mature, portable, and debuggable.)
• Message queues (Kafka, RabbitMQ, Redis—don't let AWS own your event backbone.)
• Long-running compute (VMs are cheaper, more flexible, and you actually understand the failure modes.)
• Business-critical state (Anything you'd need in a court case should be exportable without an AWS Support ticket.)

The Multi-Cloud Myth (And the Real Alternative)

"Just go multi-cloud!" is the knee-jerk response.

But multi-cloud is expensive theater. Running identical workloads on AWS + GCP doubles complexity, doubles cost, and gives you... what, exactly? The ability to failover in the (statistically unlikely) event that an entire AWS region goes dark?

The real alternative to cloud lock-in isn't multi-cloud. It's portable architecture.

Here's what that looks like:

Portability Checklist

• Use open standards: Postgres over DynamoDB. Kafka over SQS. Kubernetes over ECS (if you must orchestrate containers).
• Abstract infrastructure: Use Terraform or Pulumi. Never click through the AWS Console to provision production resources.
• Limit vendor-specific APIs: Every proprietary service you use is a future migration ticket. Budget accordingly.
• Test your exit strategy: Can you restore a full backup to a different provider in < 24 hours? If not, you're trapped.

When Vendor Binding Is Worth It

I'm not anti-cloud. I'm anti-blind dependency.

There are times when deep integration with a vendor makes sense:

• Speed to market: If you're a startup and every week counts, use the services. Get traction first, refactor later.
• Competitive moats: If AWS releases a killer feature (e.g., Graviton3 price-performance), leverage it—but understand the cost.
• Non-critical workloads: Marketing site? Internal dashboards? Sure, throw them on Vercel or Netlify. It doesn't matter if you're locked in.

But for your core business logic, for the systems that define your competitive advantage, for the data that represents years of customer trust—keep it portable.

The New Cloud Strategy: Hybrid by Design

At Link11, we run a hybrid architecture by design:

• Edge nodes on cloud providers for global reach
• Core DDoS scrubbing on owned, colocated hardware for cost and control
• Data pipelines on Kubernetes, portable across any provider
• Critical databases on managed Postgres—but with automated daily exports to cold storage

This isn't multi-cloud for the sake of it. It's strategic control. We use the cloud where it adds value. We own the infrastructure where lock-in would be catastrophic.

The Prenup You Should Have Signed

Here's the uncomfortable truth: cloud providers are not your partners. They're your vendors.

And like any vendor relationship, the power balance shifts over time. When you're small, they want your business. When you're big, they want your margin.

The smartest move you can make is to design for exit from day one:

• Use infrastructure-as-code so you can recreate your stack elsewhere.
• Avoid proprietary APIs for core workflows.
• Budget a "portability tax"—the extra 10-20% cost of using open standards instead of the fastest managed service.
• Review your architecture annually and ask: "If we had to leave AWS tomorrow, what would break?"

If the answer is "everything," you don't have an architecture. You have a dependency.

The Real Lesson

Cloud native should mean "designed to leverage cloud economics without surrendering strategic control."

It should not mean "built entirely on one vendor's product suite because it was easy at the time."

The companies that win in the next decade will be the ones that treat the cloud as a tool, not a platform. They'll use managed services where it makes sense. They'll own their data and core logic. And they'll have an exit plan that doesn't require a CTO-level rewrite.

Because in the end, "cloud native" without portability is just "vendor bound" with better marketing.

And that's a marriage you'll regret.

---