Who Actually Owns the AWS Resources When Your PaaS Deploys to Production

A PaaS that deploys into your own AWS, GCP, or Azure account uses a Bring Your Own Cloud model, or BYOC. With shared-tenant PaaS, those resources go in the vendor’s account instead. That split decides who can inspect production infrastructure, see the cloud bill, and gather compliance evidence, but owning the account alone does not give them full control.

How PaaS deployment models determine who actually owns what on AWS

A developer runs git push and watches the application deploy. The build passes, the containers start, and production is live. But whose AWS account did those resources just go into? The deployment screen may not make that obvious. “Running on AWS” names the cloud provider.

Under shared-tenant PaaS, the vendor’s account holds the compute, storage, networking, and load balancers. The customer rents a slice of that environment. Under BYOC, the platform orchestrates deployment into the customer’s account, where the VPC, managed Kubernetes, databases, and other production resources reside. Both arrangements can offer a managed deployment experience. They differ in what the customer owns beneath it, and therefore in what the customer can inspect or retain without the platform.

What the shared responsibility model actually assigns to the customer in a PaaS arrangement

AWS’s shared responsibility model assigns AWS security “of the cloud,” including hardware, networking, and data centers. Customers handle security “in the cloud,” including data, access controls, application settings, and encryption. A PaaS takes on more of that stack than infrastructure-as-a-service does, but it does not take responsibility for every tenant decision. Managed infrastructure is not a transfer of accountability. The customer is still responsible for application code, identity configuration, and how data is used.

Those obligations also include encryption choices, public versus private network exposure, privileged roles, key rotation, logging, and audit-log retention within the customer’s control. The provider may supply the tools. The customer still has to configure them correctly. A provider’s ISO or SOC report does not prove that customer backups are isolated, access has been reviewed, or retention settings are appropriate. Long-lived keys, exposed backups, public storage, and missing logs remain risks under either model, so customers need to establish what else the deployment architecture puts in their hands.

How shared-tenant PaaS positions the vendor as the AWS account holder

In shared-tenant PaaS, the vendor holds the AWS account in which production runs. The customer does not receive resource-level IAM access to that environment or inspect its VPC directly. Instead, the platform exposes a narrower set of controls. These include application configuration, environment variables, secrets, scaling parameters, and region or tier selections. Each operates within the choices the vendor makes available.

Below that interface, the vendor controls subnet design, security groups, instance selection, storage provisioning, database infrastructure, and load balancer configuration. The underlying AWS bill belongs to the vendor too. The customer sees what the platform charges, but cannot see AWS Cost Explorer data for the resources that run the application. If the customer leaves or the vendor shuts down, the production resources remain the vendor’s property, and infrastructure audit evidence must come through vendor attestations.

How BYOC inverts the arrangement so resources land in the customer's account

In BYOC, the platform’s control plane is separate from its data plane. The control plane coordinates deployment, while the data plane runs the application and handles its traffic and data. That second half lives in the customer’s account. Containers, databases, caches, load balancers, TLS certificates, and VPCs are provisioned there. The vendor supplies the management layer without holding the account that contains production.

Databricks provides the clearest public reference for BYOC at scale. Its classic compute plane deploys compute and storage within the customer’s AWS, Azure, or GCP environment. The qualification is important here. Its serverless compute plane runs in a Databricks-managed account, and some metadata resides in the vendor-controlled control plane.

For customer-account deployments, direct access includes IAM policies, VPC settings, security groups, network flow logs, and actual cloud charges. Customers can apply Reserved Instances, Savings Plans, and eligible startup credits, including AWS Activate and Google for Startups Cloud Program credits, to their infrastructure bills. Standard resources also provide an exit path. When the platform provisions VPCs, managed Kubernetes, load balancers, and managed databases in the customer’s account, those resources remain there after the customer stops using the platform. The management convenience does not.

Why account placement alone does not settle the ownership question

Resources in the customer’s account still need a permissions audit. The vendor’s control plane has credentials or cross-account IAM roles that let it create, change, and destroy resources. A narrowly scoped, auditable role differs substantially from broad access that exceeds the platform’s needs. Account placement identifies the owner, but role scope determines what the vendor can do.

To check how much control it has, a team should check those roles, what operational metadata leaves its account, and which legal jurisdiction the control plane falls under. The vendor may still get logs, metrics, and deployment events. Residency alone does not establish data sovereignty. Without organization-level audit logging, it can be hard to see control-plane activity, and production data sent to development accounts can fall outside the safeguards meant to protect it. The shared-responsibility record should identify evidence sources for each control and change at audit time and whenever the architecture changes. A well-audited BYOC arrangement remains structurally stronger for compliance because it narrows the infrastructure boundary that depends on vendor evidence, without removing the need to assess the vendor.

What the ownership split means for compliance audits under SOC 2 and HIPAA

An auditor needs evidence of controls. In shared-tenant PaaS, the customer depends on the vendor’s SOC 2 report for infrastructure it cannot independently inspect. That dependency extends the evidence chain into the platform. In BYOC, the customer can produce AWS Config findings, CloudTrail logs, IAM policy documents, and encryption-key audit trails from its own account. Vendor access still needs review, but proof of infrastructure settings no longer rests entirely on the vendor’s attestation.

HIPAA makes that distinction especially practical for workloads handling electronic protected health information, or ePHI. The proposed 2026 HIPAA Security Rule update would turn previously “addressable” safeguards into mandatory requirements if finalized. The four controls call for MFA for all ePHI access, strong encryption at rest, vulnerability scanning every six months, and a 72-hour recovery time objective that has been tested. As of late 2026, the final rule had not been issued, with finalization targeted for July 2027.

The proposal also explicitly calls for business associates’ technical safeguards to be checked every year. A Business Associate Agreement would not suffice on its own. Directly inspectable resources make verification easier, although they do not prove every safeguard is working. SOC 2 and HIPAA share controls, but HIPAA has added rules for how to handle protected health information, business associate agreements, and breach notification. A SOC 2 report therefore cannot substitute for the HIPAA work a healthcare-adjacent SaaS requires.

How cost visibility follows account ownership

The same account boundary separates a platform invoice from a cloud bill. Shared-tenant PaaS embeds vendor margin in compute pricing, while the underlying AWS charges remain invisible to the customer. That limits what the customer can optimize directly. The customer can change platform tiers or scaling settings, but cannot buy commitments against resources held in the vendor’s account. The gap between platform pricing and cloud-direct pricing grows more consequential as usage increases.

BYOC exposes actual charges and instance utilization data. That lets customers right-size resources, use startup credits, and buy Reserved Instances or Savings Plans for their workloads. Compute Savings Plans can still apply when instance types change. The comparison still needs to include the platform’s separate software charge and the work it takes to run it. At low compute spend, shared-tenant simplicity may outweigh the pricing gap. As spend grows, the ability to buy directly and see utilization data gives teams more reason to own the account, especially when GPU workloads cost a lot.

GPU and inference workloads as a case where account ownership has compounding consequences

GPU instances cost far more than CPU instances, so being unable to see what is being used puts more money at stake. With shared tenancy, the customer cannot look directly at utilization in the underlying account or use its own cloud commitments and credits for those resources. For training, Spot Instances offer another way to buy compute. In BYOC, the customer’s account can place the Spot request, while a shared-tenant platform controls whether and how that optimization reaches the customer.

Responses may include personal health or financial data or be shaped by it, so where that data is processed matters from the start. The control-plane caveat still applies to these workloads. Even when inference runs inside the customer’s account, metadata egress needs review before making sovereignty claims. Direct infrastructure metrics also help teams measure the effect of quantization, which reduces model precision from FP16 to INT8 or INT4 and can lower GPU memory requirements and per-inference cost.

The strongest objection to BYOC and where it actually applies

The strongest objection is that BYOC can relocate operational work rather than remove it. IAM setup, upgrade coordination, cross-AZ egress costs, and on-call responsibility can shift toward the customer, while the vendor bills separately for software. That is a real trade-off. Shared tenancy may work better for an early-stage team that spends little on compute, has no compliance or residency requirement, and has little time or ability to audit cross-account permissions. Ownership without a concrete use for it can become an operations tax.

The decision test is to write one sentence naming the specific requirement that forces the data plane into the customer’s account. It might be residency, compliance, committed cloud spend, or a hardware requirement. If that sentence is clear, BYOC is structurally the right fit. If it is not, the next question is whether the team’s cost and compliance trajectory will create that need soon. A well-designed BYOC platform uses infrastructure as code, automation, and its control plane to handle updates and scaling, so the customer can own the account without having to run every component by hand. Shared tenancy also adds work when audits or high compute spend reveal how little the customer can do with evidence and pricing that come only from the vendor.

How to audit which model you are actually on and what to verify regardless

Ask the vendor for the AWS account ID of the account where the production containers run. Then inspect the organization’s AWS console and Cost Explorer. Compute charges that match what the application uses point to BYOC or infrastructure-as-a-service, while application resources that sit only in the vendor’s account point to shared tenancy. The account ID gives the definitive boundary.

For a move to BYOC, the next checks concern portability and delegated access. Verify whether the platform provisions standard resources, including VPCs, managed Kubernetes, standard load balancers, and managed RDS. Examine the required IAM role scope. Establish what operational metadata leaves the account and under which data-processing terms, then retain the customer-side checks for encryption, network exposure, access reviews, logging, and backups. Neither model makes those obligations disappear.

For teams seeking Kubernetes in their own GCP environment or Azure subscription, the same buying criteria apply. The useful comparison is where the data plane runs, what the vendor can access, and which operational tasks the platform handles. Cluster management, CVE patching, autoscaling, and GPU support belong in that evaluation. Claims of one-click SOC 2 and HIPAA compliance posture do not replace evidence or customer responsibility. The right fit combines PaaS convenience with inspectable resources, bounded vendor access, and a cloud bill the customer can act on.