EKS, ECR, Fargate, EBS, EFS and GuardDuty are on AWS's HIPAA eligible services list, so you can run workloads with PHI on Kubernetes under a BAA. Eligibility is not compliance: encryption, access, isolation, audit logs and what lands in your logs are yours. A control-by-control checklist, with a diagram.
AWS's HIPAA eligible services list (last updated October 15, 2026) includes Amazon EKS, Amazon ECR, AWS Fargate (for ECS and EKS), Amazon EBS, Amazon EFS and Amazon GuardDuty. With a Business Associate Addendum in place, you can run workloads that handle protected health information on EKS. What the BAA does not do is configure anything. Under the shared responsibility model, the cluster's settings are yours.
Access
Named people, least-privilege access policies, no shared admin.
Workloads
Network
Data
Audit
Where each HIPAA control sits in an EKS setup
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Network policies in the VPC CNI apply to EC2 Linux nodes only, not Fargate or Windows. If PHI runs on Fargate, isolate with namespaces, security groups and separate services instead.
Pod Identity isn't supported on Fargate either; Fargate pods use IAM roles for service accounts.
Debug tooling (kubectl exec, port-forward) is access to PHI. Restrict it with RBAC and log it.
Upgrades are a security control: a cluster on extended support still gets patches, but costs six times as much for the control plane, so plan upgrades instead.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
EKS and AI Agents: Running Agents on Kubernetes, and Letting Agents Operate Your Clusters
Two different problems. Running agents on EKS is about long-lived workers, GPUs, sandboxes for code they write, and tight egress. Letting an agent operate EKS, through the EKS MCP server or kubectl, is about read-only by default, separate roles for writes, and approvals. The setups that are safe enough to use.
Read
EKS Network Policies With the VPC CNI: Default Deny, Admin Policies, and the Limits to Know
The VPC CNI enforces Kubernetes network policies natively, and from version 1.21 adds cluster-wide admin policies that namespace owners can't override. How the tiers are evaluated, a default-deny setup, and the limits: EC2 Linux nodes only, 24 port-protocol combinations per CIDR, and pods without an owner.
Read
As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.