Case 09

EKS Platform Foundation

EKS as a product with foundations under the skyline: network, identity, nodes, and add-ons you can rebuild — not a one-off click-ops island.

Open on GitHub ↗ Discuss this pattern All cases
01

How it works

Raise the foundation — then the skyline.

EKS Platform Foundation by Andrey Lesnikov — blueprint layers under workloads so clusters are repeatable platform products.

Kubernetes skyline standing on four foundation blueprint layers
Skyline on blueprints — rebuildable EKS, not a pet cluster.
Animated foundation layers stacking then workload skyline rising
Lifecycle — Network → Identity → Nodes → Add-ons → Workloads
  1. 01

    Lay network + baseline

    VPC, CNI, and private API posture come first — the ground the skyline stands on.

  2. 02

    Bind identity

    IRSA, RBAC, and cluster auth are contracts, not afterthoughts bolted to a living cluster.

  3. 03

    Shape node capacity

    Node groups carry upgrade and drain rules so capacity changes are boring on purpose.

  4. 04

    Install the platform roof

    Ingress, DNS, metrics, and policy add-ons complete a foundation you can rebuild from Git.

02

Evidence

From problem to proof.

How the system is framed, operated, and proven — not a slide deck summary.

01
When to use

Every cluster is assembled differently — networking, identity, nodes, and add-ons are click-ops islands you cannot rebuild from Git.

02
When not

The foundation already exists and the gap is delivery topology (App-of-Apps, multi-region overlays) or industrial twin convergence — use GitOps / TwinOps cases instead.

03
See also

Terraform Platform Modules and GitOps: Argo CD & Flux turn the foundation into a rebuildable product. Multi-Region GitOps covers promotion across skies.

Live signal Last commit · · a126adc docs: add OpenSSF Scorecard badge (#10) GitHub ↗
Checks · passingv1.0.0 · 10 Oct 2026
Open in repo
/manifests
Constraints

AWS account boundaries, workload identity, node lifecycle, ingress policy, autoscaling, logging, and upgrade safety.

03

Related

Nearby systems.

Case 13

Terraform Platform Modules

  • Modules
  • Versions
  • Plan

Cloud platforms drift when teams copy infrastructure snippets and adjust them under delivery pressure

Infra changes as reviewable product PRs

Read case ↗ GitHub ↗
Case 04 · Flagship

GitOps: Argo CD & Flux

  • Git
  • Argo CD
  • Flux

Teams need a clear delivery model before GitOps becomes another layer of operational confusion

Delivery as explicit platform contracts

Read case ↗ GitHub ↗
Case 12 · Pattern

Multi-Region GitOps

  • Git
  • Overlays
  • Sync

Multi-region systems need repeatable promotion and rollback without turning every deployment into manual coordination

Regional drift stays auditable

Read case ↗ Proved in GitOps: Argo CD & Flux ↗
Available for meaningful infrastructure conversations

Build systems that stay calm under pressure.

Available for conversations

Talk infrastructure

Book a working session

Meet ↗

Evidence first

For deep dives

Explore the systems

All cases ↗