EKS training for AWS cloud engineers

We offer private, instructor-led training for cloud and operations engineers who know AWS infrastructure and need to deploy and support workloads on Amazon EKS.

Your team already understands IAM, networking, and infrastructure provisioning. EKS workload decisions also require a Kubernetes model of controllers, releases, and application permissions.

LearnKube connects your team's AWS experience to a representative Kubernetes application. Through hands-on exercises, engineers work through its configuration, replacement, traffic, and access requirements.

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.
  • Deploy an EKS workload by defining application resources and tracing their controllers. Engineers can then explain how the desired state becomes running Pods.
  • Preserve application behavior using health checks and release observations. The team can judge whether the workload meets its service requirements.
  • Locate the failing layer by comparing AWS dependencies with Kubernetes status and events. This helps the team investigate the component that controls the behavior.
  • Assign operating responsibilities by mapping workloads and infrastructure. Engineers can then explain which tasks belong to AWS, the platform, or the application owner.

Your AWS infrastructure skills remain useful on EKS, but application behavior also follows Kubernetes controllers. A Deployment defines desired replicas and release settings. Its controller reconciles that state as Pods change. AWS manages the EKS control plane within a shared responsibility model. Your team still needs to explain how its workloads and integrations operate.

I ask an AWS engineer what will happen after a Pod disappears. Knowing which instance hosted it is useful, but the controller, desired state, and application requirements explain the replacement and its effect.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Provision application infrastructureWorkload desired stateTrace the controlling resource
Replace application capacityController reconciliationObserve a replacement Pod
Accept an application releaseProbes and rollout stateCompare release evidence
Assign operating dutiesAWS and workload boundariesMap the next action

Invesco's cloud engineering work combines AWS infrastructure, reusable platform patterns, Terraform, and collaboration with developers and security engineers. EKS is among the services in its cloud remit. Technical mentoring and knowledge transfer are explicit responsibilities.

For AWS engineers taking on EKS workload responsibilities, we recommend a four-day workshop that connects their infrastructure knowledge to Kubernetes application behavior. We start with what the learners can already explain.

This proposed agenda follows one application from its image to its operating dependencies. We spend less time on familiar infrastructure and container topics so the team can focus on the Kubernetes model.

Day 1

We show how containers relate to Pods, Deployments, Services, and probes. Engineers observe the controller's actions during a release and explain what the status means.

  • Deploy an application and trace its Pods back to the desired configuration.
  • Replace a Pod, then explain how the controller responds and what it means for the application's health.

Day 2

We use Helm and cluster architecture to separate application configuration from the control plane, compute, and infrastructure resources. Each dependency receives an explicit owner.

  • Compare infrastructure provisioning with the resources rendered by an application chart.
  • Explain which component responds to a changed workload setting.

Day 3

We connect DNS, Services, routing, and placement to the surrounding AWS network. Engineers distinguish a workload-selection problem from an infrastructure or capacity dependency.

  • Trace a request from its AWS entry point to the selected application Pods.
  • Use events and resource requirements to explain a Pod that remains Pending.

Day 4

We examine configuration, storage, application metrics, authentication, and RBAC. Access to AWS services shows how workload identity differs from the engineer's permission to administer resources.

  • Compare an application permission requirement with the engineer's cluster access.
  • Explain the workload's data, capacity, and recovery dependencies to a colleague.

Your AWS experience, target EKS responsibilities, and application requirements can shape the agenda. Get in touch to tailor the workshop to your move into EKS work.

When an engineer treats a Pod as a manually managed server, the instructor can replace it and show which controller is responsible. The learner explains why the new Pod appears, what configuration it uses, and which behavior still needs verification.

Iain shared how hands-on work reinforced the explanations in a Sony course that included EKS:

The labs were really interesting and really helped solidify the knowledge covered in the lectures.

— Iain, Software Engineer at Sony Interactive Entertainment.

Tell us which AWS services your team manages, what it needs to do on EKS, and which Kubernetes concepts are unfamiliar. We will recommend where to start and which workload exercises to use.

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