Kubernetes onboarding environment for developers new to EKS

The specific moment this problem bites is when a developer who knows Docker but has never touched Kubernetes is handed an EKS-based codebase and told to ship a feature. They spend their first week not writing code but learning kubectl, understanding namespaces, figuring out why their pod keeps crashing, and decoding IAM service account annotations — none of which is in the ticket they were assigned.

This gap persists because Kubernetes expertise is assumed at the infrastructure layer, and AWS documentation is written for people who already know what a control plane is. Complaints like 'the implementation is a bit complex, as it requires prior Kubernetes experience to manage the cluster' and 'it would have been great if Amazon would have provided an IDE to look at the cluster' reflect that the mental model required to operate EKS is fundamentally different from the mental model required to write application code — and there's no bridge built for people crossing that gap on the job.

What's actually missing is a structured, interactive learning environment that uses a developer's real EKS cluster (or a sandboxed replica of it) as the teaching material. Generic Kubernetes tutorials teach abstract concepts with toy clusters; they don't explain why a specific team's ingress controller is configured the way it is, or what the service account attached to a given deployment actually has permission to do. The user complaint about EKS logs — 'Amazon EKS should have proper logs so that users will be able to troubleshoot easily' — is really a complaint that the feedback loop between 'I did a thing' and 'here's what happened and why' is broken.

This is a business because developer onboarding to EKS is not a one-time event — it happens every time someone joins the team, every time a developer is promoted into infrastructure responsibilities, and every time a company migrates a new service onto Kubernetes. The buyer is the engineering manager or VP Engineering who measures onboarding time-to-productivity and knows that three weeks of confusion from every new hire is a real budget line even if it's never tracked as one.

What to build

Build a browser-based guided environment that connects to a real or sandboxed EKS cluster via read-only kubeconfig, walks a developer through their actual cluster topology with interactive explanations of each resource, and lets them safely run kubectl commands with real-time annotations explaining what each command does and what the output means.

Where to start

Sell initially to engineering managers at companies that run EKS and hire 3+ backend developers per quarter — the onboarding cost is concrete enough to justify a per-seat tool, and a single team with high turnover is a recurring revenue anchor.

The hard part

The hardest trade-off is whether to require connection to a real cluster (high value, high security friction, slow to activate) or use a realistic sandbox (faster to start, but users question whether it maps to their actual setup) — committing to the wrong side early kills either conversion or retention.

How it makes money

Per-seat monthly subscription charged to the engineering team budget, around $29/developer/month, with a team minimum of 5 seats to ensure the buyer is an engineering manager with a budget rather than an individual experimenter.