Amazon Bedrock Agents and Vertex AI Agent Builder resolve the deployment question by answering it for you: execution runs in the provider's managed runtime, inside your account, under their isolation model. That is the right answer for most organizations, and the wrong one for the specific case where a contract, a regulator, or a residency clause constrains processing to infrastructure you control directly.
Where the managed runtime genuinely wins
If you are already committed to one cloud, the managed runtime is the shortest credible path to production, and pretending otherwise would be dishonest. Identity is already federated. The audit plane already exists and your security team already reads it. Model access, scaling, and patching are somebody else's on-call rotation. Procurement is an existing contract rather than a new vendor review.
From the standard
“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”
That last point decides more deployments than any architectural argument. A capability available under an existing agreement ships months before one that requires a new vendor through security review.
The four decisions you inherit
| Decision | Managed runtime | BYOC execution plane |
|---|---|---|
| Where inference runs | The provider’s region and endpoints | A gateway you approved, on-premises included |
| Sandbox isolation | The provider’s model, not usually specified to the tenant | A hypervisor boundary you can inspect from inside |
| Egress control | The provider’s network controls | eBPF filter and DNS sinkhole, on an allowlist you define |
| Audit record | The provider’s log schema and retention | A distributed trace you own, spanning both planes |
None of these is a defect. They are the terms of a managed service: you accept the provider's answers in exchange for not having to build them. The question is only whether any of the four collides with a constraint you cannot negotiate.
The test that decides it
Not "how sensitive is this data" — everyone answers "very", and the answer carries no information. Ask instead: is there a written commitment, to a regulator or to a customer, that constrains where this data may be processed?
If the answer is no, use the managed runtime. It is faster, cheaper to operate, and the isolation model is built by a team with more security engineers than you will ever hire for this. If the answer is yes, the question becomes whether the provider's regions and terms satisfy that commitment — and where they do not, no data processing agreement changes where the packets go.
The air-gapped case is the clean discriminator
A managed cloud runtime cannot run in an environment with no route to the provider. If your deployment target is genuinely air-gapped or fully egress-restricted, the decision is already made and the remaining question is only whether the alternative is honestly air-gapped — a system that must reach a hosted embedding endpoint is not, whatever else is true of it.
What is portable, and what is not
Model access is portable in principle — the same families are available across providers, and routing inference elsewhere is a configuration change. The orchestration logic is portable with effort. What is not portable is the integration surface: tool definitions written against the provider's schema, identity wiring, audit plumbing, and the agent definitions themselves.
That surface is where the switching cost actually lives, and it is usually larger than a model-portability discussion suggests. Worth pricing before it is load-bearing, not after.
A reasonable middle
These are not mutually exclusive. A common and sensible shape is the managed runtime for workloads on data that may leave, and a controlled execution plane for the subset genuinely constrained by contract or regulation. Splitting by data class rather than by preference keeps the fast path fast and reserves the expensive topology for the cases that actually require it.
Axionalytics
Production agentic AI for enterprise engineering, data, and revenue teams.