Your architecture passed every engineering review. The services are containerized, the deploys are automated, the uptime is fine. Then, three weeks into a security review with your largest prospective customer, their auditor asks one question nobody on your team can answer cleanly: who holds the IAM role that touches PHI? If the honest answer is "our platform vendor does, somewhere in their account," you are no longer having an engineering conversation. You are having a procurement delay.
For a company between $2M and $50M ARR, a mid-procurement re-architecture is the most expensive infrastructure decision you can make. It redirects months of engineering time away from the roadmap, it stalls the enterprise deal that triggered the review, and it restarts the compliance assessment from zero because the evidence changed underneath it. The entire failure mode is avoidable if you choose, up front, the architecture whose audit trail you actually own. That is the real axis of the Kubernetes vs serverless decision for teams holding PHI, and it is almost never the axis the comparison articles cover.
Most kubernetes vs serverless content compares cold starts, scaling curves, and developer ergonomics. Those matter, but none of them is the question that stalls a healthcare deal. An auditor evaluating a HIPAA environment works through a control narrative, and for infrastructure that narrative reduces to three ownership questions:
The distinction that decides how smoothly the audit goes is first-party evidence versus subservice-organization dependency. If the IAM role, the log group, and the VPC live in an AWS account your company owns, you answer each question by exporting the artifact directly: the policy JSON, the retention setting, the VPC configuration. If they live in a vendor's account, every one of those questions turns into "we rely on our vendor's controls," and the auditor must chase the answer through that vendor's SOC 2 report, over which you have no influence, on whose scope you have no input, and on whose renewal timeline your deal now depends. That is the frame to carry into the architecture decision, because the two architectures answer these three questions in opposite ways.
To be precise about terms: by serverless here we mean the fully managed application platforms where your code runs on infrastructure the vendor owns, in the vendor's cloud account, behind the vendor's control plane. The appeal is real. There is no cluster to run, no nodes to patch, no VPC to design. For workloads with no PHI and no enterprise compliance pressure, that reduced operational surface is a legitimate advantage, and we will say so again in the trade-off section below.
The problem appears the moment an auditor asks the three questions. On a fully managed serverless platform, the execution role that your code assumes is created and held in the vendor's account. The logs your application emits are captured by the vendor's logging pipeline, retained on the vendor's schedule, and exported through the vendor's tooling. The network boundary is the vendor's multi-tenant edge. For all three controls, the truthful answer on your audit worksheet is "the vendor does." Each of those answers converts a control you could have demonstrated in five minutes into a dependency the auditor has to trace through someone else's attestation.
In practice this plays out as a chain of follow-ups you cannot shortcut. The auditor requests the vendor's SOC 2 Type II report. The report's scope may or may not cover the specific control in question. If the vendor treats its own cloud provider as a carved-out subservice organization, the chain gets one link longer. If the report period does not cover your assessment window, you wait. None of this is hypothetical bad behavior by any vendor; it is simply what shared infrastructure looks like when it meets a control framework built around demonstrable ownership. Your compliance lead did not choose this chain, your architecture did.
There is a second cost that shows up before the audit even starts: the enterprise security questionnaire. "Does customer data leave your cloud environment?" is a standard question in healthcare procurement, and on a vendor-hosted serverless platform the answer is yes, by design. Teams in this position often end up writing paragraphs of compensating explanation for a question that could have been a one-word answer. When a prospective customer's contract includes a data sovereignty clause, the explanation stops working entirely and the re-architecture conversation begins, usually at the worst possible moment in the deal.
Kubernetes, run in your own cloud account, inverts every one of those answers. The IAM roles are in your account. The log groups are in your account. The VPC is yours. Here is the comparison scored the way an auditor would score it:
| Control | Vendor-hosted serverless | Kubernetes in your own AWS account |
|---|---|---|
| IAM roles | Execution roles created and held in the vendor's account; evidence routed through the vendor's SOC 2 | Roles and policies in your account; you export the policy JSON directly from IAM |
| Log retention | Vendor pipeline, vendor retention schedule, vendor export tooling | CloudWatch log groups in your account with a retention policy you set and can prove |
| Network boundary | Vendor's multi-tenant edge and shared network | Your VPC, private subnets, and your security groups |
| Audit posture | Subservice-organization dependency on all three | First-party evidence on all three |
What does first-party ownership look like concretely? Using Convox Rack as the working example, because it installs an EKS-based platform into your own AWS account, here is each control expressed as configuration you hold.
On an AWS Rack with the pod_identity_agent_enable rack parameter turned on, a service definition attaches IAM permissions through accessControl.awsPodIdentity.policyArns. The service that reads PHI gets exactly the policies you name, and nothing else on the cluster inherits them:
services:
records-api:
build: .
port: 3000
accessControl:
awsPodIdentity:
policyArns:
- arn:aws:iam::123456789012:policy/phi-records-read
web:
build: .
port: 3000When the auditor asks who can access patient records, the answer is a specific policy ARN in your own IAM console, attached to a specific service, with a change history in your own CloudTrail. That is a least-privilege answer you produce yourself, in minutes, without opening a vendor ticket.
Application logs land in CloudWatch log groups inside your account. Retention is set rack-wide with the cloudwatch_retention_in_days rack parameter, and individual apps can override it in their manifest through the awsLogs app settings:
appSettings:
awsLogs:
cwRetention: 365When the auditor asks how long access logs are retained and who can change that, you show the setting, the log group it governs, and the IAM policy controlling who can modify it. All three artifacts are in your account. No one outside your organization can shorten the window.
A Rack installs into a VPC in your account, and the AWS rack parameters let you draw the boundary to match your data flow requirements. The private parameter, which defaults to true, places nodes in private subnets behind NAT gateways. You can install into an existing VPC with vpc_id and your own subnet IDs, add an internal-only load balancer with internal_router, and restrict the Kubernetes API endpoint itself to private access from the Console's security settings. The subnets, route tables, and security groups are AWS resources you own and can diagram for any security questionnaire without asking anyone's permission.
Here is the objection every VP Engineering raises at this point, and it is the right objection: raw EKS ownership means your team operates the cluster. Ingress controllers, certificate management, node upgrades, IAM plumbing for workload identity, deploy tooling. For a team of ten to thirty engineers with zero or one dedicated ops people, that is a hire you did not budget for, or a quarter of roadmap you did not plan to spend. Owning the audit trail is not worth it if the price is becoming a Kubernetes operations team. We have written before about what running Kubernetes actually costs a team, and the numbers are the reason "just use EKS" is not a plan.
This is the gap a bring-your-own-cloud platform closes. Convox Rack installs the EKS cluster, the routing, the TLS, the registry, and the deploy pipeline into your AWS account, then manages the platform layer so your team works through convox deploy, a convox.yml manifest, and environment variables instead of raw Kubernetes manifests. The account, the IAM roles, the CloudWatch log groups, and the VPC are all in your name, which means every artifact from the previous section remains first-party evidence. The operational knowledge your team needs shrinks to the platform's surface, not the cluster's; we covered that gap in detail in how Convox flattens the Kubernetes learning curve.
Two compliance facts are worth stating with precision, because this audience should distrust anything fuzzier. First, Convox is compliance ready through inherited controls: because the infrastructure runs in your AWS account, your environment inherits the controls of that account, and the evidence is yours to produce. Convox is not itself certified or authorized under HIPAA or any other framework, and any vendor who words that claim differently deserves a follow-up question. Second, your HIPAA business associate agreement is signed with AWS, not with Convox. PHI lives in your account on AWS infrastructure covered by your AWS BAA; Convox never needs to be a business associate for your data because your data never leaves your account. For a buyer tired of adding one more BAA to the vendor stack, that is the cleanest possible answer.
Now the trade-off, named plainly. BYOC means you pay AWS directly for the EC2 nodes, NAT gateways, and load balancers the Rack provisions, so the infrastructure line item is yours to monitor and optimize, and Convox adds no markup on that infrastructure for self-hosted Racks. It also means you own the patching cadence decision: Rack version updates are applied through CLI or Console rack management on your schedule, which is exactly what an auditor wants to hear about change control but is also a recurring responsibility, not a fire-and-forget subscription. And to repeat the earlier concession: for workloads with no PHI and no enterprise compliance pressure, vendor-hosted serverless genuinely is less operational surface. The argument here is not that serverless is bad. It is that serverless makes the three auditor questions structurally unanswerable in the first person, and if PHI is on your roadmap, that structure is a liability you are choosing now and paying for later.
If you are weighing kubernetes vs serverless, or evaluating which is the best PaaS for a startup that holds or will hold PHI, do not start with the feature matrix. Start with the three questions, put to every vendor on your shortlist this week, in writing:
Any answer that begins with "our SOC 2 covers that" is the subservice-organization dependency described above, and your compliance lead should be in the room when you hear it. The answer you want is "you do, it is in your account, here is where to look." Loop your compliance stakeholder in now, before procurement starts, because the single most common way these evaluations stall is a platform chosen by engineering and then re-litigated by compliance six months later.
The fastest way to test control ownership is not a demo call, it is an install. A Convox Rack installs into your own AWS account, typically inside an hour of hands-on time, and you can then open your own IAM console, your own CloudWatch log groups, and your own VPC configuration and verify that every artifact an auditor will ask for is sitting in your account with your organization's name on it. Review what the platform costs alongside the AWS spend you would pay either way, and compare that total against the price of the hire or the quarter of roadmap that raw EKS would consume. That comparison, not cold-start latency, is the real kubernetes vs serverless decision for a company selling into healthcare.
No architecture is HIPAA compliant by itself; compliance is a property of your controls and processes. Serverless platforms can support HIPAA workloads, but because the vendor holds the IAM roles, logs, and network, every control becomes a subservice-organization dependency your auditor must verify through the vendor's attestations rather than through evidence you produce yourself.
Kubernetes in your own cloud account makes the evidence easier because IAM, logging, and networking are first-party artifacts you control and export directly. It makes operations harder if your team runs the cluster raw. A BYOC platform like Convox Rack keeps the ownership while managing the cluster layer, giving you the audit posture without the operational staffing cost.
On vendor-hosted serverless platforms, the vendor owns the logging pipeline, the retention schedule, and the storage, and you access logs through their tooling. That means you cannot independently prove retention or prevent changes you did not make. In a BYOC model, logs land in CloudWatch log groups inside your own AWS account with retention you set and can demonstrate.
Yes, if the PaaS runs in your own cloud account. Convox Rack installs into your AWS account, so PHI stays on infrastructure covered by your existing AWS business associate agreement, which is signed with AWS rather than with Convox. You keep platform-level ergonomics like push-to-deploy while the IAM roles, logs, and VPC remain first-party evidence.
Auditors typically ask which identities can access systems holding PHI, request the policy documents that scope those identities, and look for least-privilege separation between services. With per-service IAM scoping such as Convox's accessControl.awsPodIdentity.policyArns, you answer with a named policy ARN in your own account, attached to one service, with a change history in your own CloudTrail.
Ready to see whose name is on the audit trail? The Getting Started Guide walks through installing a Rack into your own AWS account and deploying your first application.
Create a free account and pilot a Rack in your own AWS account this week. For HIPAA and compliance-driven evaluations, talk to our team and bring your compliance lead to the first call.
