Private EKS training for application and platform teams

We provide private, instructor-led Amazon Elastic Kubernetes Service (EKS) training for application developers, platform engineers, and SREs working with AWS-based workloads.

Your teams need shared release checks, clear access boundaries, and evidence from workload investigations. The same EKS application requires different actions from each role.

LearnKube follows one application from deployment through AWS integration to a support handoff. Participants explain its behavior and compare their responsibilities.

Hands-on learning and the skills engineers take back to work.

Preview: course-wide figures are not yet available.

  • Hands-on learning
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    Of respondents applied their new skills at work within 90 days.
  • Use a shared EKS model by following an application through Kubernetes resources and AWS dependencies. Both groups can then explain how it works.
  • Apply common release criteria by reviewing configuration, health probes, and recovery assumptions. This keeps application-specific requirements clear.
  • Clarify operating ownership by comparing workload changes, cluster dependencies, and access permissions. Each group can identify its actions and handoffs.
  • Review a workload together using application status, traffic observations, and permission requirements. The groups can identify gaps using the same evidence.

EKS teams need to understand how AWS and Kubernetes access control work. An engineer's permission to change a workload differs from the workload's permission to call AWS services. Releases also depend on application health and shared cluster components. The workshop follows one application across these boundaries so each role can explain the evidence and decide what to do next.

I ask who needs permission to do what: the engineer changing a Deployment, or the application calling an AWS service. The answer changes both the control to inspect and the team that owns the next action.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Decision to alignCommon basisShared exercise
Release acceptanceProbes and rollout stateCompare release evidence
Traffic investigationServices and AWS load balancersTrace a request path
Access responsibilityEngineer and workload identitiesIdentify the required permission
Support handoffStatus, events, and dependenciesAssign the next action

Sony's application developers, SREs, and technical leads wanted hands-on Kubernetes training to prepare for EKS. They already had container experience. Their request focused on deployments, networking, AWS load balancers, and IAM/RBAC.

LearnKube delivered private, four-day online Kubernetes training for the group, followed by another course that included EKS. Both courses combined teaching with labs. Uyi, a solutions architect in the repeat course, shared what he found valuable:

The format of the course works - presentation and labs. I particularly like that the labs make you think and not just copy and paste blindly.

— Uyi, Solutions Architect at Sony Interactive Entertainment.

For application and platform teams sharing EKS responsibilities, we recommend the following workshop around one workload and its operating decisions.

This proposed agenda connects core Kubernetes concepts to EKS examples and decisions for each role. We shorten container topics the team already knows and choose AWS integrations that fit your environment.

Day 1

We show how container images, Deployments, Services, and probes relate to the application. Both groups compare a completed rollout with the application behavior needed for release acceptance.

  • Explain an unready release using workload status and application observations.
  • Compare the evidence each role needs before accepting or reversing an update.

Day 2

We inspect Helm configuration alongside the EKS control plane, nodes, and shared controllers. Participants separate application settings from cluster dependencies and identify who can change each resource.

  • Compare rendered releases and identify application changes and platform dependencies.
  • Trace a change through its controller and record the responsible role and required handoff.

Day 3

We trace the request path through DNS, an AWS load balancer, Kubernetes routing, and the application's Pods. Networking and scheduling examples show dependencies that cross team boundaries.

  • Compare workload health with health evidence from its AWS load balancer.
  • Prepare a support handoff that identifies the affected resource, observed behavior, and the owner of the next action.

Day 4

We examine configuration, persistent storage, autoscaling signals, and RBAC through the same application. Participants review its AWS service-access model and compare workload permissions with engineer access.

  • Identify which identity needs the permission and which team owns the relevant Kubernetes or AWS configuration.
  • Review the application's release, data, capacity, and access requirements using shared criteria and role-specific actions.

Your EKS workloads, AWS integrations, and responsibility boundaries can shape the agenda. Get in touch to tailor the workshop to how your teams work together.

When a developer attributes an AWS access-denied response to Kubernetes RBAC, the instructor can compare the application's AWS request with the engineer's cluster access. Both groups identify the caller, inspect the relevant permission, and explain which owner can change it.

Tell us which teams use EKS, which release or access decisions need a shared understanding, and how their responsibilities differ. We will recommend a course focus and exercises for each role.

You can also buy LearnKube training through AWS Marketplace. Contact us if you need a private offer for the agreed workshop scope.