Multi-Tenant EKS Four Walls Architecture Diagram: Namespace to Aurora Isolation

On September 18, 2026, the AWS Architecture Blog published ReadyOn’s case study on four walls of tenant isolation for its Harmony platform on Amazon EKS. The threat model is not “can an outsider reach the cluster?” — it is “can Tenant A reach Tenant B’s data?” This multi-tenant EKS tenant isolation architecture diagram maps the compound defense: namespaces, Karpenter dedicated node pools, VPC security groups, and per-tenant Aurora with IRSA tenant secrets. Facts follow that AWS post only. This is a case study — ReadyOn-specific; generalize carefully.

What a multi-tenant EKS tenant isolation architecture diagram shows

Draw tenants as parallel lanes, not one shared “multi-tenant app” box. For each tenant, stack four independent barriers at different layers: the Kubernetes API (namespace + RBAC + admission), the scheduler/compute plane (Karpenter pools with dual taints), the AWS network (per-tenant security groups and default-deny NetworkPolicies), and the data plane (dedicated Aurora + IRSA-scoped secrets). Put the private EKS API / VPN + OIDC+MFA control plane above the lanes. Stamp a callout: no shared-row filters.

The diagram’s job is to show defense in depth: crossing a tenant boundary requires defeating walls in combination, not one soft namespace alone. Kubernetes designers never intended namespaces as a sole security boundary — ReadyOn’s model pairs them with compute, network, and data walls. For broader cluster framing, see the optional companion on the Kubernetes cluster architecture diagram guide.

Wall 1: Kubernetes namespaces

Each tenant operates in a dedicated namespace with strict RBAC, resource quotas, and admission control. ReadyOn provisions every tenant through an Argo CD ApplicationSet: adding one Git config entry generates the namespace, network policies, RoleBindings, quotas, and secrets references so every tenant gets an identical posture by construction — no legacy exceptions.

Tenant principals cannot list, get, or modify resources in another namespace. Admission control blocks privileged configs and resource types tenants should not own (DaemonSets, ClusterRoles, admission webhooks). GitOps continuous reconciliation reverts unauthorized live drift within seconds. Wall 1 is the logical foundation — necessary, not sufficient.

Wall 2: Karpenter dedicated node pools

Tenants do not share compute nodes. Karpenter provisions dedicated, autoscaling node pools per tenant using a dual-taint strategy: every node carries a tenant-identifying taint (for example tenant=acme-corp) and a workload-type taint (for example workload=frontend). A pod must tolerate both to schedule. Tenant A’s frontend nodes stay apart from Tenant A’s batch nodes and from all of Tenant B’s infrastructure.

An admission controller validates that toleration claims match the namespace’s tenant identity, so forged tolerations cannot steer the scheduler into cross-tenant placement. Application nodes enforce IMDSv2 with a reduced hop limit; the IAM role on each node is scoped to that tenant’s resources. Platform nodes sit on managed node groups with a separate taint no tenant workload can tolerate.

Wall 3: VPC security groups

Wall 3 drops below the Kubernetes abstraction. Each tenant’s Aurora cluster is guarded by a security group that allows inbound only from the security group on that tenant’s application nodes. Tenant A’s nodes cannot open a TCP connection to Tenant B’s database — an AWS software-defined network rule the Kubernetes control plane does not own.

ReadyOn’s VPC is tiered: public perimeter (load balancers), private application (EKS workers), database (Aurora with no internet), and control plane (private EKS API, VPN-only with OIDC and MFA). Kubernetes NetworkPolicies enforce default-deny between namespaces; pods talk only to their own namespace and explicitly allowed platform services. VPC Flow Logs capture traffic for anomaly detection.

Wall 4: per-tenant Aurora and IRSA secrets

Each tenant gets a dedicated Amazon Aurora cluster and tenant-scoped secrets in AWS Secrets Manager. Workloads authenticate with short-lived credentials via IAM Roles for Service Accounts (IRSA) — OIDC federation into STS, unique IAM roles per tenant, credentials that expire in minutes, no long-lived access keys in app workloads. Observability (metrics, logs, traces) is routed to dedicated backends per tenant through OpenTelemetry so even operational error spikes stay invisible across tenants.

Dedicated clusters also enable distinct KMS keys per tenant for data-at-rest. Even if raw storage were exposed, one tenant’s key cannot decrypt another’s. On the diagram, label Wall 4 as Aurora + IRSA / Secrets Manager, not “shared DB + RLS.”

Why not shared-row tenancy here

A shared database places the entire isolation burden on application-layer query logic. One missing WHERE tenant_id = ? clause can disclose another tenant’s rows. ReadyOn chose dedicated Aurora so Tenant A’s code cannot construct a connection to Tenant B: it lacks the endpoint, the credentials, and the network path. Shared-row filters are not a wall in this model — they are the failure mode the fourth wall removes.

Case-study caveats

Is (case study): ReadyOn Harmony’s Four Walls reference on Amazon EKS as described Sep 18, 2026 — namespaces via Argo CD ApplicationSets, Karpenter dual-taint pools, per-tenant VPC SGs + default-deny NetworkPolicies, dedicated Aurora + IRSA secrets, private API with VPN/OIDC/MFA, GitOps as the change control plane, Pod Security Standards at restricted, and a mapped multi-tenant threat model with lateral-movement paths blocked at each wall.

Is not: a universal EKS multi-tenancy standard; a claim that every SaaS must afford dedicated Aurora per tenant; independently audited red-team results beyond ReadyOn’s stated adversarial exercises; or an invitation to invent CRD fields, Karpenter NodePool CR shapes, or metrics the AWS post does not publish. Mark the diagram case study / ReadyOn so architecture reviews do not copy cost and ops assumptions blindly.

FAQ: four walls on EKS

What are ReadyOn’s four walls of tenant isolation on Amazon EKS?

Four layered barriers: (1) Kubernetes namespaces with RBAC, quotas, and admission control; (2) Karpenter dedicated node pools with a dual-taint strategy; (3) VPC security groups plus default-deny network policies; (4) per-tenant Aurora databases with IRSA-scoped secrets — no shared database with row-level filters.

Why avoid shared-row tenancy for sensitive multi-tenant EKS workloads?

A shared database puts the whole isolation burden on application query logic — one missing WHERE tenant_id filter can leak data. ReadyOn’s case study uses a dedicated Aurora cluster per tenant so Tenant A lacks the endpoint, credentials, and network path to Tenant B’s data.

Is the Four Walls model a universal EKS multi-tenancy pattern?

No. It is a ReadyOn Harmony platform case study on the AWS Architecture Blog (Sep 18, 2026). Treat it as a reference architecture for high-stakes tenant isolation and generalize carefully for your threat model, cost envelope, and operational maturity.

Conclusion

Keep the diagram honest to the case study: tenants → namespace (Wall 1) + Karpenter dedicated pools (Wall 2) + VPC security groups (Wall 3) + per-tenant Aurora / IRSA secrets (Wall 4), with the EKS control plane above and an explicit no shared-row filters callout. Cite the AWS Architecture Blog — ReadyOn’s Four Walls of tenant isolation on Amazon EKS (Roshan Daneshvaran and Hassan Shenasa, Sep 18, 2026). Browse more architecture diagrams on the ByteDiagram blog.