Equinix Cut Kubernetes Operational Overhead by 40% With a Shared Services Architecture on EKS
Cloud Platform EngineeringEquinix ran Kubernetes in the way that most organizations eventually run it wrong: each application team owned and operated their own self-managed cluster on EC2. The result was operational sprawl — duplicated infrastructure, inconsistent security configurations, no centralized governance, and fragmented solutions to common problems like CI/CD, observability, and data services.
The fix was a shared services architecture on Amazon EKS. The outcome, documented on the AWS Architecture Blog: 40% reduction in operational overhead, 4× increase in deployment frequency, and 100% adoption across multiple business organizations.
The Problem with Team-Owned Clusters
Self-managed Kubernetes on EC2 is operationally heavy. Every team managing their own cluster is responsible for the full lifecycle: provisioning, networking, version upgrades, security patching, node management, and the cumulative maintenance burden that compounds as cluster count grows.
Beyond operational cost, the distributed model creates governance gaps. Cloud operations teams couldn’t enforce consistent security policies or networking standards when every cluster was independently managed. Common infrastructure problems — CI/CD pipelines, observability stacks, database access — were solved redundantly by each team in slightly different ways.
The Three-Account Architecture
Equinix restructured around three dedicated AWS accounts:
Workloads Account — EKS clusters across two Availability Zones with Application Load Balancer for ingress. Cilium CNI handles pod-level network policies; Hubble provides network observability. Application teams deploy here but don’t manage the cluster.
Platform Account — Centrally managed shared infrastructure: managed data services (RDS, MSK, OpenSearch, MQ, S3), centralized CI/CD via GitHub Runners on EKS, and Network Load Balancer for service ingress. Application teams access these services without provisioning or operating them.
Network Account — AWS Transit Gateway spanning two regions for cluster-to-cluster connectivity. Route 53 Resolver endpoints for DNS. AWS Direct Connect for hybrid connectivity to Equinix’s on-premises infrastructure — a critical integration given Equinix’s business as a colocation and interconnection provider.
What the Separation Achieves
The multi-account boundary is the key architectural decision. By separating workloads from platform services from networking:
- Application teams get namespace-level self-service without access to cluster infrastructure
- Platform teams maintain and govern the shared layer without touching application code
- Network teams manage Transit Gateway and Direct Connect routing without cluster-level visibility
The Argo CD-managed GitOps workflow ensures consistent configuration across all tenant namespaces — no manual provisioning that drifts from the baseline.
Quantified Outcomes
- 40% reduction in operational overhead — primarily from eliminating cluster lifecycle management across application teams
- 4× increase in deployment frequency — new deployment pipeline through centralized CI/CD on EKS
- 100% adoption across multiple Equinix business organizations
- Days vs weeks for new team onboarding — self-service namespace provisioning through GitOps
The deployment frequency improvement is notable: centralized CI/CD standardization typically accelerates pipelines by removing per-team CI infrastructure variability and enabling shared validation tooling.
The So What
The Equinix architecture demonstrates the core tradeoff in platform engineering: accepting centralized ownership of shared infrastructure in exchange for removing that burden from application teams. The 40% overhead reduction isn’t magic — it’s the aggregate saving of all the teams that are no longer managing Kubernetes cluster lifecycle, rolled up to a platform function that can amortize the effort across the organization.
The three-account pattern is replicable. The specific service choices (Cilium, Karpenter, RDS/MSK) are reasonable defaults that most EKS-based organizations can evaluate against their existing tooling. The prerequisite is organizational willingness to move from team-owned infrastructure to platform-managed infrastructure — which is a governance and culture change as much as a technical one.
Source: AWS Architecture Blog
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →