Equinix Shared Services EKS Architecture Diagram: Multi-Account Platform Split

On September 17, 2026, the AWS Architecture Blog published how Equinix moved from self-managed Kubernetes on Amazon EC2 to a shared services Amazon EKS model they call North Star. The design splits ownership across three AWS accounts — Workloads, Platform, and Network — so cloud operations owns the infrastructure plane while application teams deploy business services. This shared services Amazon EKS architecture diagram maps that multi-account platform split: Gateway API ingress and Cilium/Hubble on the EKS plane, plus a Transit Gateway hub for cross-account and hybrid connectivity. Facts below follow the AWS Architecture Blog case study (cowritten with Equinix). Treat reported outcomes (overhead reduction, deployment frequency) as Equinix/AWS claims from that post — and label the diagram a customer reference architecture, not a product launch.

What a shared services Amazon EKS architecture diagram shows

Draw three vertical account swimlanes and a connectivity hub beneath (or between) them. Left: Workloads — application teams’ Amazon EKS namespaces behind ALB + Kubernetes Gateway API, with Cilium as CNI and Hubble for flow visibility. Center: Platform — cloud-ops-owned shared EKS workloads (for example centralized GitHub Runners), managed data services (RDS, MSK, OpenSearch, MQ, S3 in the source), and NLB ingress using the same Cilium/Hubble stack. Right / bottom: Network — Transit Gateway as the multi-account hub, Route 53 Resolver endpoints, and Direct Connect toward on-premises Equinix border routers. Cross-account arrows are TGW attachments from Workloads and Platform VPCs into that hub. Stamp case study / North Star on the canvas so reviewers do not read it as a new AWS SKU.

The before picture matters for context: Equinix previously ran self-managed Kubernetes on EC2 (etcd, control plane, and workers they provisioned), with each application team owning cluster lifecycle, networking, observability, and pipelines. That decentralized model produced operational sprawl — duplicated baselines, no central governance, and painful control-plane upgrade risk. North Star is the architectural answer: consolidate infrastructure ownership, keep app teams on namespaces and business logic.

Workloads vs Platform vs Network accounts

The three-account split is the load-bearing shape of the diagram:

• Workloads account (Workloads-VPC). Hosts application team services on Amazon EKS across two Availability Zones in us-west-1 in the published UAT figure (identical patterns called out for non-prod and production). Ingress: Application Load Balancer with Kubernetes Gateway API (GatewayClass and Gateway) into application namespaces. Networking: Cilium CNI for pod-level network policy; Hubble for real-time network observability.
• Platform account (Platform-VPC). Owned by the cloud operations team. Shared infrastructure: managed data services consumed across the account boundary, CI/CD via GitHub Runners deployed as EKS workloads, and other centrally managed capabilities. Ingress to platform services uses Network Load Balancer, with the same Cilium/Hubble stack as Workloads.
• Network account (Network-VPC). Connectivity hub: AWS Transit Gateway spanning us-west-1 and us-east-2 with TGW peering, Route 53 Resolver inbound/outbound endpoints plus a private hosted zone for service discovery, and AWS Direct Connect Gateway (dual circuits) through network firewalls to on-premises Equinix border routers.

On the diagram, keep app pods and namespaces inside Workloads; keep shared runners and data services inside Platform; keep TGW, DNS resolver, and Direct Connect inside Network. Do not collapse “shared services” into a single vague box that hides the account boundary.

Gateway API ingress and Cilium on the shared plane

Ingress and dataplane choices are explicit in the case study and should stay explicit on the art:

• Workloads path: north–south traffic hits an ALB; Kubernetes Gateway API resources (GatewayClass / Gateway) provide routing into application namespaces. That is the app-facing shared ingress pattern — teams consume namespaces rather than inventing per-team ingress stacks.
• Platform path: shared services take NLB ingress. Same organization, different entry shape for platform-facing traffic.
• Cilium + Hubble: Cilium is the CNI enforcing pod-level isolation; Hubble supplies unified network-flow visibility across clusters — replacing fragmented, team-specific monitoring from the self-managed era.

Draw Gateway API on the Workloads swimlane (not as a free-floating product logo), Cilium/Hubble as the shared networking/observability baseline on both EKS planes, and keep CRD field inventing out of the caption — the source names GatewayClass and Gateway, not custom Equinix CRDs.

Transit Gateway as the multi-account hub

The Network account’s AWS Transit Gateway is the cross-account and hybrid glue. Attachments connect Workloads and Platform VPCs to the central hub so communication between accounts is controlled rather than peered ad hoc. The published architecture spans two Regions (us-west-1 and us-east-2) with Transit Gateway peering between them. Route 53 Resolver endpoints (inbound and outbound) in each Availability Zone, plus a private hosted zone, handle service discovery across the platform. Hybrid path: Direct Connect Gateway with dual circuits to on-premises Equinix border routers, with network firewalls on that path for enforcement.

On a Transit Gateway multi-account EKS diagram, TGW is a hub node — not a side annotation. Arrows: Workloads-VPC → TGW ← Platform-VPC; TGW ↔ peered TGW (second Region); TGW → Direct Connect Gateway → on-prem. That hub is what lets Platform data services and Workloads apps talk without each team building private connectivity.

What cloud ops owns vs app teams

Ownership is the organizational half of the architecture:

• Cloud operations owns and governs the infrastructure: Platform account shared services and CI/CD runners, Network account connectivity, cluster baselines, network policy posture via Cilium, and the operational model that application teams consume.
• Application teams deploy business services into pre-configured namespaces on the Workloads EKS plane, use centralized GitHub Runners for pipelines, and consume shared data services across the account boundary — without provisioning or managing control planes.

The case study reports Equinix outcomes after migrating to Amazon EKS under this model: about 40% reduction in operational overhead (AWS managing upgrades, patching, and HA), 4× increase in deployment frequency, and 100% unified architecture adoption across multiple business organizations — plus faster onboarding (days rather than weeks), Hubble-unified observability, and multi-account isolation plus Cilium policies for a tighter security scope. Cite those as Equinix/AWS published results from the Architecture Blog post, not as ByteDiagram benchmarks, and do not invent additional percentages.

Case-study caveats

Keep the diagram honest:

• Customer reference architecture, not a product launch. North Star is Equinix’s blueprint described on the AWS Architecture Blog — generalize carefully for your org; do not treat every AZ, Region, or service choice as mandatory AWS guidance.
• Published figure is UAT-shaped. The post describes a UAT environment with identical patterns for non-prod and production — draw environment replicas as a note, not as three fully detailed copies unless you need them.
• Vendor/customer metrics. Overhead, deployment frequency, and adoption figures come from the case study; hedge them on the diagram or in the caption.
• No invented CRDs or unpublished topology. Stick to Gateway API (GatewayClass/Gateway), Cilium/Hubble, ALB/NLB, TGW, Route 53 Resolver, and Direct Connect as named in the source.

Evergreen takeaway for platform teams: separate Workloads / Platform / Network concerns, put ingress and CNI on a shared baseline, and hub multi-account connectivity through Transit Gateway — then adapt account boundaries to your org’s blast-radius and compliance needs.

FAQ: multi-account EKS shared services

What accounts make up Equinix’s shared services Amazon EKS architecture?

Three AWS accounts in the North Star design: Workloads (app teams’ Amazon EKS namespaces behind Gateway API ingress), Platform (cloud ops’ shared EKS services, CI/CD runners, and managed data services), and Network (Transit Gateway hub, Route 53 Resolver, and Direct Connect back to on-premises).

Where do Gateway API and Cilium sit in the multi-account EKS split?

In the Workloads account, Application Load Balancer plus Kubernetes Gateway API (GatewayClass and Gateway) route into application namespaces; Cilium is the CNI with Hubble for network observability. The Platform account uses the same Cilium/Hubble stack with Network Load Balancer ingress for shared services.

Is Equinix’s North Star EKS design an AWS product launch?

No. It is a Sep 17, 2026 AWS Architecture Blog customer case study co-written with Equinix — a reference shared-services pattern on Amazon EKS, not a new AWS product SKU.

Conclusion

Draw App teams → Workloads (EKS + ALB/Gateway API + Cilium/Hubble), Platform (shared EKS services, data plane, NLB, same CNI/observability), and Network (Transit Gateway hub + Resolver + Direct Connect), with cross-account TGW arrows and a clear case study / North Star label. Cite the AWS Architecture Blog post on Equinix’s shared services Amazon EKS architecture for account boundaries, ingress choices, and reported outcomes — and generalize the three-account split to your platform without copying Equinix’s Region layout as dogma. Browse more architecture diagrams on the ByteDiagram blog.