Post Syndicated from Chhavi Kaushik original https://aws.amazon.com/blogs/architecture/how-equinix-cut-operational-overhead-with-a-shared-services-architecture-on-amazon-eks/

This post is cowritten by Manikandan Vasu, Vanji Sivajothy, and Ramchandra Koty from Equinix.

Equinix is the world’s digital infrastructure company, operating over 260 data centers across more than 70 metros globally. To address the operational sprawl that had grown from its earlier self-managed Kubernetes environment, Equinix built a shared services architecture on Amazon EKS. Previously, Equinix operated a self-managed Kubernetes environment on Amazon EC2 instances. In this model, they provisioned EC2 instances serving as etcd, control plane, and worker nodes, relying on open-source tooling to automate the installation and configuration of Kubernetes components. While this approach provided control and flexibility in the early stages of their Kubernetes journey, it also introduced a structural problem: individual application teams independently provisioning and managing their own clusters, each with its own lifecycle, configuration, and operational patterns.

Over time, this decentralized ownership model created significant operational sprawl. With no shared infrastructure layer, the cloud operations team had no consistent mechanism to enforce governance, standardize configurations, or provide common infrastructure services across the organization. Each application team operated in isolation, making decisions about networking, observability, security policies, and deployment pipelines independently. This resulted in a fragmented environment that was increasingly difficult to manage, secure, and scale.

Key operational challenges included:

• Operational sprawl – Independently managed clusters led to duplicated infrastructure and no unified operational baseline.
• No centralized governance – The cloud operations team had no mechanism to enforce network isolation, security policies, or deployment standards across team-owned clusters.
• Lack of shared services model – Common needs (CI/CD, observability, data services, networking) were solved differently by each team, creating redundancy.
• Cluster lifecycle complexity – Upgrading and patching control planes across multiple self-managed clusters introduced compounding risk with every cycle.

These challenges made it clear that Equinix needed a fundamental architectural shift, from a model where every team managed its own cluster. They moved to a shared services architecture where the cloud operations team centrally owns and governs the infrastructure while application teams focus purely on their business services. This led to their migration to Amazon EKS with a multi-account strategy designed for scalability, security, and centralized control.

In this post, we walk through how Equinix designed and implemented their shared services architecture on Amazon EKS after migrating from their self-managed Kubernetes environment. We also cover the operational results they achieved, including 4x faster deployments and significantly reduced operational overhead.

The solution: A shared services architecture on Amazon EKS (North Star architecture)

Key architecture capabilities

The North Star architecture implements a multi-account, shared services model on Amazon EKS that cleanly separates concerns between application teams and the cloud operations team. The diagram illustrates the user acceptance testing (UAT) environment, with identical patterns replicated across non-production (system integration testing and development) and production, built around three core AWS accounts:

1. Workloads Account (Workloads-VPC): The Workloads account hosts all application team services running on Amazon EKS in a dedicated VPC deployed across two Availability Zones (AZ-1 and AZ-2) in us-west-1 for high availability. Traffic ingress is managed through Application Load Balancer (ALB) with Kubernetes Gateway API (GatewayClass and Gateway resources) providing precise routing to application namespaces. Cilium serves as the Container Network Interface (CNI), enforcing network policies that isolate workloads at the pod level, while Hubble provides real-time network observability across all application traffic flows.
2. Platform Account (Platform-VPC): The Platform account is owned and operated by the cloud operations team, housing all shared infrastructure services in a separate VPC. This includes:
• Managed data services: Amazon RDS, Amazon MSK, Amazon OpenSearch Service, Amazon MQ, and Amazon S3 consumed by application workloads across the account boundary.
• CI/CD infrastructure: GitHub Runners deployed as EKS workloads, providing a centralized, self-service pipeline for all application teams.
• Shared services: Capabilities managed centrally and accessible to all application teams.

Traffic ingress to platform services is handled through Network Load Balancer (NLB), with the same
Cilium/Hubble networking and observability stack as the Workloads account.

3. Network Account (Network-VPC): A dedicated Network account acts as the connectivity hub, implementing an AWS Transit Gateway architecture that spans two Regions (us-west-1 and us-east-2) with Transit Gateway peering between them. Key networking capabilities include:
• Cross-account connectivity: AWS Transit Gateway attachments connect both the Workloads and Platform VPCs to the central hub, enabling controlled communication between accounts.
• DNS resolution Amazon Route 53 Resolver endpoints (inbound and outbound) in each Availability Zone, with a private hosted zone providing service discovery across the platform.
• Hybrid connectivity: AWS Direct Connect Gateway with dual circuits connecting back to on-premises Equinix border routers through network firewalls for security enforcement.

Results: Measurable impact across the organization

The migration to Amazon EKS delivered clear, measurable outcomes that validated Equinix’s North Star architecture strategy:

40% Reduction in operational overhead by eliminating the need to manage Kubernetes infrastructure. AWS now handles upgrades, patching, and high availability automatically.

4x Increase in deployment frequency, enabling engineering teams to ship features and updates faster, freed from the constraints of infrastructure bottlenecks.

100% Unified architecture adopted across multiple business organizations, establishing a single, consistent operating model for all containerized workloads.

Additional operational improvements include:

• Enhanced developer productivity: Standardized CI/CD workflows through centralized GitHub Runners and self-service namespace provisioning reduced friction across the development lifecycle, allowing application teams to deploy independently without cloud operations team intervention.
• Improved observability: Hubble provides unified network flow visibility across both clusters, replacing fragmented, team-specific monitoring.
• Strengthened security posture: Multi-account isolation between application and shared services workloads, combined with Cilium network policies for pod-level segmentation, reduced the scope of potential security incidents and simplified compliance enforcement.
• Accelerated onboarding: New application teams onboard to the North Star architecture in days rather than weeks, deploying into pre-configured namespaces with access to shared data services, CI/CD pipelines, and observability. They do this without provisioning or managing cluster infrastructure.

“Amazon EKS gave us the foundation we needed to establish our North Star architecture – a scalable, standardized infrastructure that lets our engineers focus on what matters most: delivering innovation for our customers.”

Conclusion

Equinix’s migration to Amazon EKS from a self-managed environment demonstrates how leading digital infrastructure companies are using managed services from AWS to eliminate undifferentiated operational work and redeploy engineering talent toward higher-value innovation.

The North Star architecture now serves as Equinix’s blueprint for scaling containerized workloads across additional business organizations and geographies. It is an architecture that grows with the company while maintaining the governance, security, and operational consistency that enterprise-scale infrastructure demands.

If you are managing complex, distributed infrastructure, the broader takeaway is this: when you consolidate operational ownership onto a well-architected infrastructure and remove the burden of cluster management from your application teams, you can achieve a markedly different pace of innovation.

To get started with your own Amazon EKS deployment, visit the Amazon EKS product page or follow the Getting started with Amazon EKS guide. You can also explore the EKS Best Practices Guide for recommendations on multi-tenancy, networking, and security.

---

About the authors