Managed Kubernetes for Multi-Tenant SaaS
Tenant isolation, cluster upgrades before support runs out, GitOps deploys, and container security that holds up in an enterprise security review — run by engineers who operate clusters every day.
Who this is for
SaaS companies already on Kubernetes, or with a concrete reason to move, that run many tenants on shared clusters, field enterprise security reviews, and have no engineer whose full-time job is the cluster.
Managed Kubernetes for SaaS is an arrangement in which an outside team designs and operates your EKS, GKE, or AKS clusters — tenancy model, upgrades, autoscaling, deploy tooling, and security — while your engineers ship services onto them. The SaaS-specific part is tenant isolation: making sure one customer's workload, data, or traffic spike cannot reach or degrade another's.
When SaaS teams hand off their clusters
Your EKS cluster is about to leave standard support, and extended support costs six times as much per cluster hour.
An enterprise prospect's security review asks how tenant workloads are isolated and whether pods can talk across namespaces.
One large tenant's batch job starved the shared cluster and degraded every other customer.
Nobody has upgraded the ingress controller, cert-manager, or CNI since the cluster was built.
Engineers deploy with kubectl from laptops and there is no record of what changed.
The operating cost of Kubernetes in a SaaS business
Kubernetes ships a new minor version roughly three times a year, and the upstream project maintains only the three most recent, each with about a year of patches. Managed services stretch that — Amazon EKS gives 14 months of standard support, then charges $0.60 instead of $0.10 per cluster hour for 12 months of extended support — but the clock still runs. Each upgrade also touches the add-ons around the cluster: CNI, ingress, DNS, cert-manager, autoscaler, storage drivers, and policy engines. Teams that treat upgrades as an occasional project end up several versions behind, paying extended-support fees and facing a sequence of upgrades instead of one.
SaaS adds tenancy decisions on top. A shared cluster with a namespace per tenant is efficient, but only safe with default-deny NetworkPolicies, ResourceQuotas and LimitRanges per namespace, Pod Security Standards enforced at the restricted level, and RBAC that keeps tenant-scoped service accounts away from each other's secrets. Large or regulated customers may require dedicated node pools or a cluster of their own. Those choices drive cost, blast radius, and what you can truthfully write in a security questionnaire.
We run clusters with the tenancy model written down as a design document, upgrades on a calendar that stays inside standard support, deploys through GitOps with Argo CD or Flux so the repository is the record of what runs, and autoscaling tuned with Karpenter or the Cluster Autoscaler plus HPA or KEDA for workloads. Security follows the Kubernetes Pod Security Standards and the CIS Kubernetes Benchmark, with admission policies that block what should never be deployed.
What runs in and around a SaaS cluster
Managed control planes
Amazon EKS, Google GKE, or Azure AKS, with managed node groups or Karpenter and cluster configuration kept in Terraform.
Tenant workloads
Namespace-per-tenant or pooled services with tenant-aware routing, ResourceQuotas, and PriorityClasses so no single tenant can consume the cluster.
Ingress and traffic
Gateway API implementations or your cloud's load-balancer controller, with per-tenant hostnames, TLS from cert-manager, and rate limits at the edge.
Deploy tooling
Helm or Kustomize manifests reconciled by Argo CD or Flux, with image versions promoted between environments by pull request.
Security tooling
Admission control with Kyverno or OPA Gatekeeper, image scanning in the registry, signed images where customers ask for supply-chain evidence, and runtime detection with Falco or a vendor agent.
Per-tenant observability
Prometheus metrics, logs, and traces carrying tenant labels, so you can answer which customer is driving load or errors.
What managed Kubernetes includes
Tenancy design
A written model for how tenants map to namespaces, node pools, or clusters, including when a customer qualifies for dedicated capacity and what it costs to provide.
Upgrade calendar
Control plane and add-on upgrades scheduled inside the provider's standard support window, rehearsed in staging, each with a rollback plan.
GitOps delivery
Argo CD or Flux reconciling every cluster from Git, so engineers deploy by pull request and configuration drift is visible.
Isolation and hardening
Default-deny NetworkPolicies, restricted Pod Security Standards, scoped RBAC, and admission policies checked against the CIS Kubernetes Benchmark.
Autoscaling and cost
Node provisioning with Karpenter or the Cluster Autoscaler, workload scaling with HPA or KEDA, and requests and limits sized from measured usage.
Cluster on-call
First response for cluster-level alerts — node failures, scheduling problems, certificate expiry, failed reconciliations — with your team paged only for application issues.
First 30 days
- Read-only review of cluster configuration, add-on versions, and support-window dates.
- Tenancy and isolation gaps documented against the Pod Security Standards and the CIS Benchmark.
- An upgrade plan for any version near the end of standard support.
- Quick fixes: default-deny policies in a pilot namespace and kubectl write access from laptops removed.
- GitOps bootstrapped for at least one environment.
After month one
- Scheduled control plane and add-on upgrades.
- Tenant onboarding and offboarding handled through code.
- Monthly cost and capacity review by namespace and tenant.
- Findings from image scanning and runtime detection triaged.
- Kubernetes audit logs and change history exported as SOC 2 evidence.
Kubernetes security references we build to
Kubernetes Pod Security Standards
The upstream privileged, baseline, and restricted profiles, enforced by the built-in Pod Security Admission controller. Tenant namespaces run at restricted unless an exception is documented.
Kubernetes: Pod Security StandardsCIS Kubernetes Benchmark
Consensus configuration checks for the control plane, worker nodes, and policies, with provider-specific editions for EKS, GKE, and AKS.
CIS Kubernetes BenchmarkKubernetes and EKS version support
Upstream maintains the three most recent minor versions with about a year of patches each. EKS adds 14 months of standard support followed by 12 months of extended support at a higher hourly price.
AWS: Amazon EKS extended support for Kubernetes versions pricingSOC 2 CC6 and CC8
The logical-access and change-management criteria. Scoped RBAC, Kubernetes audit logs, and GitOps history serve as evidence for both.
AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)Managed Kubernetes pricing
Running production clusters for a SaaS product usually fits the Professional retainer ($8,000–$15,000 per month), depending on cluster count and environments. To see where your clusters stand first, the Cloud & DevOps Audit Sprint ($5,000, 30 days) covers container and IAM posture alongside cost.
Kubernetes questions from SaaS teams
Shared clusters or dedicated clusters per tenant?
Shared clusters with namespace isolation suit most tenants. Dedicated node pools or clusters make sense when a contract requires them, a tenant's load is large enough to disturb others, or residency rules put that tenant in another region. We price dedicated capacity so it can be passed through to the customer.
What happens if we fall behind on upgrades?
On EKS, clusters past standard support move to extended support at $0.60 per cluster hour instead of $0.10, and are upgraded automatically when extended support ends. On any platform, skipping versions means several sequential upgrades, because control planes move one minor version at a time.
Should a SaaS product use Kubernetes at all?
With a few stateless services, a managed container service such as ECS or Cloud Run is usually cheaper to operate. Kubernetes pays off with many services, tenant-isolation requirements, customer-dedicated deployments, or a team that already knows it well.
Do engineers lose kubectl access?
They keep read access, logs, and port-forwarding for debugging. Write access to production goes through Git, so every change is reviewed and recorded. Break-glass access exists for incidents and is logged.
Can you take over our existing clusters and Helm charts?
Yes. We start from what runs today, bring it under GitOps, and restructure only where the current setup causes problems.
Get a Kubernetes architecture review
Send us your cluster versions and tenancy model. We will tell you how close you are to the end of support and where tenant isolation is weakest.