Eks Platform Engineering

EKS Platform Engineering

Guidance for designing and building an Internal Developer Platform (IDP) on Amazon EKS. This skill is opinionated: it teaches one proven, integrated golden-path stack end to end rather than cataloguing every option. The reference architecture and tool choices below are the recommended default; deviate only with a reason.

This is the "how do I build a platform that other teams self-serve from" skill. For "how do I run a single EKS cluster well" (compute, networking, security, cost, upgrades), use eks-best-practices instead.

When to Use This Skill

Activate when the user wants to:

• Build or design an Internal Developer Platform / developer self-service on EKS
• Stand up or wire together a developer portal (Backstage), GitOps (ArgoCD/Argo Workflows), progressive delivery (Argo Rollouts), or promotion (Kargo)
• Define golden paths — standardized, paved ways for app teams to ship
• Abstract AWS resources behind Kubernetes (ACK, kro) or applications behind a developer-facing model (Backstage templates + kro, or OAM/KubeVela)
• Enable self-service environment or resource provisioning
• Measure platform success (DORA metrics)
• Use GenAI (Kiro) to author platform templates/manifests
• Extend the platform to AI/ML or data-engineering workloads

Don't use this skill for:

• Single-cluster EKS architecture, sizing, cost, or upgrade decisions with no self-service/platform angle → eks-best-practices
• Standalone Terraform/OpenTofu module authoring → terraform-skill
• Discovering what's already running on a cluster → eks-recon
• Generic Kubernetes concepts (Claude knows these)

What Is an Internal Developer Platform

CNCF defines a platform as "an integrated collection of capabilities defined and presented according to the needs of the platform's users." An IDP packages tools, services, and automation so application, ML, and data teams self-serve — provisioning environments, resources, and deployments without tickets — while a platform team owns the paved paths and guardrails.

Why it matters: speed (faster delivery), control (safe, consistent operations), cost (economies of scale), and continuous improvement (shared golden paths). Platform engineering has moved from emerging trend to mainstream practice — Gartner's widely-cited forecast that 80% of large software organizations would stand up platform engineering teams by 2026 reflects how quickly the discipline has been adopted.

The core principle — separation of concerns:

• Platform team defines how: portal templates, the application abstraction (Backstage software templates + kro compositions, or OAM component/trait definitions), ACK controllers, CI/CD scaffolds, promotion stages, guardrails.
• App/ML/data teams choose what: pick a template, fill parameters, push code. They never touch raw Kubernetes or AWS APIs.

See references/idp-architecture.md for the full reference architecture and the IDP value/challenge framework.

The Opinionated Platform Stack

This is the recommended, integration-tested stack. Each layer has one default tool.

Maturity note on kro: kro (which bundles many resources into one simple custom resource) is newer and less battle-tested than the rest of this stack — as of June 2026 it is at v0.9.2 with a v1alpha1 API (pre-1.0; the maintainers note breaking changes may still land). It works well and is a Kubernetes SIG subproject, but confirm its current maturity fits your risk tolerance before you standardize on it. If you want a more established tool for the same job — composing AWS and Kubernetes resources behind one API — Crossplane is the proven alternative.

Application-abstraction choice: the default above (Backstage templates + kro) keeps the platform on one composition engine. KubeVela / OAM is a fully supported alternative that gives a richer Application model (Components + Traits) — choose it if you want that abstraction, but note its current velocity before standardizing on it (see references/application-model-oam.md).

Cluster topology — hub-and-spoke (default): a hub cluster runs the platform control plane (ArgoCD, Backstage, GitLab, Keycloak, Kargo); spoke clusters (dev, prod) run workloads. EKS Auto Mode is the default cluster type so the platform team isn't managing nodes. Infrastructure metadata flows to clusters via the GitOps Bridge pattern. Details: references/idp-architecture.md.

The Golden Paths

A golden path is a paved, opinionated route from intent to running software, with guardrails baked in. The platform ships these as Backstage templates. The four core paths:

1. Provision an environment — Backstage template → kro composes VPC + EKS Auto Mode cluster + add-ons + ArgoCD registration. Minutes, not days. → references/infrastructure-abstraction.md
2. Provision an AWS resource — Backstage template → ACK manifest committed to Git → ArgoCD syncs → ACK provisions the AWS resource. → references/infrastructure-abstraction.md
3. Onboard an application — Backstage template → kro CICDPipeline → Argo Workflows CI + ArgoCD CD. Developer contract: provide a Dockerfile + the platform's application manifest (a kro-rendered resource, or an OAM Application if you run the KubeVela abstraction); the platform does the rest. → references/developer-portal-backstage.md, references/gitops-delivery.md
4. Ship safely to production — Argo Rollouts canary with gates in dev; Kargo promotes the validated artifact to prod (auto in dev, manual approval for prod). → references/progressive-delivery.md

The developer contract (what app teams provide vs. what the platform handles) is the design heart of every golden path — see references/golden-paths.md.

Guardrails — making the paved path the safe path

Self-service is only safe if the guardrails are built into the golden path, so they apply automatically and a developer cannot accidentally skip them:

• Policy-as-code — an admission policy engine (Kyverno or OPA Gatekeeper) automatically rejects unsafe workloads at deploy time. Examples: no privileged containers, images only from approved registries, required labels present.
• Supply-chain security — the platform's CI signs each image and produces an SBOM (a bill of materials of what is inside the image), and the cluster only admits signed images. This guarantees every running container actually came from your pipeline, not from somewhere untrusted.
• Least-privilege IAM, Pod Security Admission, and ingress conventions — encoded once in the platform's application abstraction (the kro composition or, on KubeVela, the OAM traits), so every app inherits them by default instead of each team getting them right by hand.

The platform team owns these controls; app teams get them for free. For the cluster-level depth behind each one, use eks-best-practices (its security.md and security-supply-chain.md references).