Too many systems mix these together. A service account, a cloud role, a permissions boundary, and an application authorization decision become a single tangled mess. It works, but only in one place. A good exit architecture makes identity understandable outside the provider. Who is the user? What is the workload? What can it access? Where is that policy defined? Can those rules be represented somewhere else without reverse-engineering the whole application? If the answer is no, the system is not portable.

Data is the real trap

Compute is usually easier to move than data. Data has gravity, governance, cost, and format problems. Enterprises love managed databases, object stores, analytics platforms, and AI data services because they remove operational burden. That is fine. The problem starts when organizations stop thinking about how data would be extracted, transformed, validated, and rehydrated somewhere else.

Cloud exit architecture requires clear thinking about data formats, metadata, lineage, encryption, retention, and replication. If the only usable form of your data lives inside a provider-specific service, you have a portability problem. This does not mean every database must be open source or self-managed. That is another extreme and usually a bad one. It means architects should understand the exit path before choosing the service.