BYOC AI Platform on AWS: What "Runs in Your Account" Actually Means
A BYOC (bring your own cloud) AI platform installs the vendor's product into an AWS account you control, so the data plane — inference, conversation store, files, embeddings, audit logs — runs under your IAM, your network, and your keys, while the vendor operates a control plane for provisioning, licensing, and upgrades. "Runs in your account" is therefore a claim about specific components, and it becomes true or false in six verifiable places: the IAM role, the network path, the key policies, the upgrade mechanism, support access, and the responsibility split. As of 2026-08-28, this page makes each one concrete.
Why "runs in your account" needs a definition
Most vendor pages leave the phrase deliberately soft: an architecture diagram with a dotted line, the word "private," and no statement of which stores sit on which side. That vagueness is not cosmetic — the whole value of BYOC is inspectability, and you cannot inspect a boundary nobody will draw. The precise question is the control-plane/data-plane split: which components process and hold your content (data plane, in your account), and which machinery provisions and operates the product (control plane, typically the vendor's). Everything else on this page is a way of forcing that split into writing.
| Component | Plane | Why it sits there | What to confirm |
|---|---|---|---|
| Model serving / inference | Data plane | The whole point of BYOC: prompts and completions are processed on compute in your account, so content never transits vendor infrastructure. | That inference truly runs on instances or services in your account — not a private path back to vendor-hosted models. |
| Conversation store | Data plane | Chat history is the densest concentration of content in the system; in a BYOC split it lives in a database in your account. | Which database, in whose account, encrypted under whose key. |
| File and attachment store | Data plane | Uploads and their extracted text belong beside the conversation store, under the same account boundary. | That extracted text and conversions land in your account too — not just the original file. |
| Embeddings / vector index | Data plane | The stored chunk text beside each vector is usually source content verbatim — it must sit inside the boundary with everything else. | Where the index runs and whether chunk text is stored alongside vectors. |
| Audit log | Data plane | Your evidence layer should be yours: the per-request record lands in your account, exportable without the vendor in the path. | That log storage and export run under your control, with vendor access to the logs itself logged. |
| Provisioning and orchestration | Control plane | Something has to install, configure, and upgrade the stack; vendors typically keep this machinery in their own account. | Exactly what the control plane can reach in your account, through which role, with which permissions. |
| Licensing, billing, and entitlements | Control plane | Seat counts and feature flags are vendor business state, not your content — they stay vendor-side in nearly every BYOC design. | What metadata flows out to support it, and that content is not part of that flow. |
| Telemetry and health monitoring | Depends on the vendor | Vendors need operational signals to support the deployment; the design question is what the signals contain and where they go. | The documented egress inventory: endpoints, payloads, and whether content or identifiers ever ride along. |
The table describes how BYOC architectures typically split — treat it as the checklist you hold against any vendor's specific answer, ours included.
The six dimensions that make it concrete
Each dimension below is an AWS mechanism, a verification step, and the red flag that tells you the boundary is softer than the diagram. AWS's own documentation for the mechanics is linked at the bottom of the page.
01IAM: who can assume what
- The mechanics:
- Cross-account access in AWS is an assumed role: your account publishes a role with a trust policy naming the vendor's principal, an external ID guards against the confused-deputy problem, and each assumption (sts:AssumeRole, a management event) is logged by CloudTrail by default. The role's permission policy — not the vendor's intentions — sets the ceiling on what the vendor can touch, intersected with any permissions boundaries and service control policies in force, and with the resource policies on the resources themselves.
- What to verify:
- The exact role trust and permission policy JSON before signing: which principals can assume it, whether an external ID is required, what actions and resources it allows, whether sessions are time-bounded — and whether CloudTrail data events (for example S3 object-level reads) are enabled for the stores that matter, since data events are off by default and billed separately, unlike the management events that record the assumption itself.
- Red flag:
- A vendor that asks for an IAM user with long-lived access keys, or a role trusting the vendor with administrator-level permissions 'to simplify setup'.
02Network path: PrivateLink and egress
- The mechanics:
- AWS PrivateLink exposes a service as an interface endpoint — an elastic network interface in your subnets, governed by security groups, endpoint policies, and network ACLs — so traffic to the service traverses the AWS network rather than the public internet (route tables govern the gateway endpoints, S3 and DynamoDB). PrivateLink is also unidirectional: connections are initiated from your side, and the service provider cannot open connections back into your VPC. The rest of the network story is your VPC's egress configuration — routes, endpoints, and security groups decide what can still call out.
- What to verify:
- The full egress inventory of the deployed stack: which endpoints exist, what still calls out (telemetry, licensing, updates), and whether the deployment functions with egress restricted to a documented allowlist.
- Red flag:
- 'Nothing leaves your VPC' asserted over a VPC with a default route to the internet and an undocumented telemetry callback.
03KMS: whose keys, and what the key policy says
- The mechanics:
- Encryption at rest in AWS resolves to KMS keys, and a key's policy is an access-control boundary in its own right — with two precisions. Authorization to call Decrypt yields nothing by itself: the principal also needs read access to the ciphertext, and cross-account use requires both the key policy and the principal's own identity policy to allow it. 'Customer managed key' is a statement about who administers the key — what matters is who the policy names as key users.
- What to verify:
- Per content-bearing store: which key encrypts it, who controls the key policy, which principals hold Decrypt and GenerateDataKey, what grants exist, who can schedule key deletion — and whether conditions such as kms:ViaService and encryption-context scoping narrow those permissions, because conditions are where real scoping lives.
- Red flag:
- Key custody presented as if it blocks vendor access while the key policy quietly lists vendor roles among the key users for content stores.
04Upgrades: how vendor code reaches your account
- The mechanics:
- BYOC does not freeze the software — vendor updates arrive somehow: images pulled from a vendor registry, artifacts applied by a pipeline role, or operator-driven releases. Each mechanism is a standing write path into your account and deserves the same scrutiny as any deployment credential.
- What to verify:
- The exact mechanism, whether the upgrade role is separate from support access and scoped to deployment actions only, whether you can pin versions or defer a release, and what the rollback path is.
- Red flag:
- Silent upgrades through an always-on role that can also read data stores — a deployment credential and a data credential fused into one.
05Support access: break-glass, not standing
- The mechanics:
- Production support in someone else's account is a designed event: access requested per incident, granted by you, time-boxed, scoped, and logged where you can see it. The alternative — standing shell or session-manager access to data-plane hosts — quietly converts 'your account' back into shared custody.
- What to verify:
- How support access is requested, who approves it, how long it lives, what it can reach, and where you see the record of everything it did.
- Red flag:
- Standing engineer access to data-plane hosts described as necessary 'for support responsiveness'.
06Shared responsibility: who patches, who watches, who answers
- The mechanics:
- AWS's shared responsibility model splits duties between AWS and whoever operates workloads; BYOC adds a third party, so every layer needs an explicit owner: account guardrails, network, keys, platform software, models, content configuration, monitoring, and incident response.
- What to verify:
- A written per-layer split for the specific offering you are buying — not the marketing page's version — including who monitors what and who owes whom notification when something breaks.
- Red flag:
- 'Fully managed' and 'fully in your control' claimed in the same document, with no table that says which layer is which.
A typical shared-responsibility split
AWS's shared responsibility model already splits duties between AWS and whoever runs workloads; BYOC adds the vendor as a third party. The table below is the typical division — the deliverable from any serious vendor conversation is your deployment's version of it, in writing.
| Layer | Customer | Vendor |
|---|---|---|
| AWS account, billing, and guardrails | Owns the account, org policies, budgets, and CloudTrail. | Operates only through the roles you granted; no account-level control. |
| Network and egress | Owns VPC design, route tables, endpoints, and the egress allowlist. | Documents required endpoints and works within your egress policy. |
| Encryption keys | Administers key policies and grants for content-bearing stores. | Declares which principals need which key operations, and why. |
| Platform software and upgrades | Approves or schedules releases where the design allows; controls pinning. | Builds, tests, and delivers updates through the documented mechanism. |
| Models and serving stack | Chooses what runs and where; owns the compute bill for it. | Maintains the serving stack and model catalog it ships. |
| Content, retention, and access configuration | Owns retention settings, roles, and the record/non-record decisions. | Provides the controls and documents their defaults honestly. |
| Monitoring and incident response | Watches the account, the network, and the data plane it now owns. | Watches the control plane and its own delivery paths; notifies on a contracted clock. |
Where PrivateStack stands
The claims we make are the site's standing ones, stated the same way everywhere: the Enterprise deployment runs the data plane inside the customer's own AWS account, deployed through an assumed, least-privilege IAM role, so prompts, outputs, and logs stay in your VPC — and AWS is the only cloud we support for BYOC today. Everything else on this page is the standard we expect to be held to: bring the six dimensions to the evaluation and ask us for the role policy, the egress inventory, the key-policy answers, the upgrade mechanism, and the support access design for the specific configuration you would buy. The Verified Deployment program covers part of that ground — its PSV-1.0 criteria record the scope, evidence the deployment boundary, and review access configuration, the data path, audit evidence, model inventory, and operational ownership. The egress-inventory and key-policy questions on this page go further than those criteria: put them to the vendor directly, or bring them into a Verified review as additional asks. The security page carries the full control set.
Two companion tools sharpen the conversation with any vendor: the AI vendor security questionnaire turns the isolation and access-control dimensions into scored questions (its IB and AC domains are this page in interrogative form), and the zero data retention vs no training guide maps the planes the data-plane column protects.
Questions people actually ask
- What does BYOC actually mean for an AI platform?
- Bring your own cloud: the vendor's platform is installed into an AWS account you control, instead of your data flowing to infrastructure the vendor controls. Done properly, the data plane — inference, conversation store, files, embeddings, logs — runs in your account under your IAM, your network, and your keys, while the vendor keeps a control plane for provisioning, licensing, and upgrades. The precision matters: 'runs in your account' is a claim about specific components, and the vendors worth shortlisting will tell you which ones without being pressed.
- Is BYOC automatically more secure than a hosted deployment?
- No — it relocates trust rather than removing it. You gain direct inspectability: the stores, the network path, and the keys are in your account, subject to your controls and your CloudTrail. You also inherit real work — the data plane is now yours to monitor and patch on the agreed split — and you retain vendor trust in three places: the control plane, the upgrade path, and support access. A hosted deployment with honest terms can beat a BYOC deployment nobody operates.
- What still depends on the vendor in a BYOC deployment?
- Three things, and they deserve most of your diligence: the control plane (what can it reach in your account, through which role), the upgrade mechanism (a standing write path into your environment), and support access (break-glass or standing). The six-dimension checklist on this page exists because these are exactly the places where 'runs in your account' claims go vague.
- How is BYOC different from self-hosting an open-source stack?
- Self-hosting means you run everything, including the parts that are undifferentiated toil: patching, upgrades, log plumbing, evidence export. BYOC keeps the software a vendor's product — built, updated, and supported by them — while the data plane runs in your account. You trade some vendor trust (control plane, upgrade path) for a large operational burden you no longer carry. The self-hosted comparison page scores that trade honestly, including where self-hosting wins.
- What does PrivateStack ship today?
- The Enterprise deployment runs the data plane inside the customer's own AWS account — deployed through an assumed, least-privilege IAM role — so prompts, outputs, and logs stay in your VPC, and AWS is the only cloud we support for BYOC today. For everything this page says to verify — role policies, egress inventory, key policies, upgrade mechanics, support access — ask us the same questions you would ask any vendor, and expect document-grade answers rather than adjectives.
Weighing BYOC against running an open-source stack yourself? The self-hosted comparison scores that trade honestly — including where self-hosting wins. And for the full field — closed API through air-gapped — the five-architecture comparison scores all five on six axes, including when BYOC is the wrong answer.
AWS documentation for the mechanics
The mechanisms above are AWS facts, not vendor claims — read them at the source.
- IAM: providing access to AWS accounts owned by third parties — Cross-account roles, trust policies, and the external ID that guards against the confused-deputy problem.
- What is AWS PrivateLink? — Private connectivity between VPCs and services without traversing the public internet.
- Key policies in AWS KMS — The key policy as an access-control boundary: who can use a key, who can administer it, and how grants extend it.
- AWS Shared Responsibility Model — The baseline split between AWS and the customer that a BYOC vendor's split layers onto.