Amazon EKS training for teams already using containers

We offer private, instructor-led training for developers, SREs, and technical leads who already use containers and need practical application skills on Amazon EKS.

Your team can build and run images. That does not explain a Kubernetes release or its AWS traffic path, including probes, selectors, controllers, credentials, and operational evidence.

LearnKube uses a representative containerized service to connect those resources. Your engineers will practice releases and follow requests and dependency access through the EKS environment.

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 a repeatable release by defining workload resources, configuration, and Helm values, so the application can run without manual changes to its containers.
  • Preserve application reachability by aligning probes, Service selectors, and the chosen AWS traffic integration, so requests can reach ready replicas.
  • Diagnose failed application paths by inspecting events, logs, endpoints, and credentials, so engineers distinguish workload failures from network or AWS access problems.
  • Define application and platform ownership by documenting release, integration, capacity, and support boundaries, so teams know which changes they can make and which require escalation.

Knowing how to run a container does not explain how Kubernetes coordinates its release. A Deployment manages workload replicas, while an integration such as the AWS Load Balancer Controller connects traffic resources to AWS infrastructure. The team must align image behavior, probes, selectors, and Service endpoints before a request can reach the intended application version.

I want an engineer to follow a request from the AWS endpoint to a ready Pod. A healthy container image alone cannot explain whether labels, Service selection, and the load-balancer integration agree.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Run a container imageWorkload resources and configurationDeploy a repeatable release
Update the applicationProbes and rollout behaviorRehearse a failed update
Receive external trafficAWS and Kubernetes routingTrace a request to Pods
Reach an AWS dependencyWorkload credentials and permissionsDiagnose denied service access

Sony Interactive Entertainment's developers, SREs, and technical leads already knew containers. A theory-heavy Kubernetes introduction left demand for practical work and guidance on moving existing container services to EKS.

LearnKube delivered private training, followed by another course. Simon described the instruction and labs:

Presenters showed a real passion for the topic and thorough understanding, the labs where great with well structured documentation.

— Simon, Senior Software Engineer at Sony Interactive Entertainment.

This proposed agenda keeps basic container material brief. It gives more attention to workload configuration, release behavior, networking, and the integrations needed on EKS.

Day 1

We connect existing images to Pods, Deployments, Services, and probes. You will examine labels, selectors, rollout progress, and rollback through the release of a sample application.

  • Deploy the service with explicit startup and readiness behavior.
  • Introduce a failed update and restore the previous application version.

Day 2

You will package resources with Helm and compare Kustomize for environment variation. We explain controllers, the control plane, and nodes through the replacement of workload instances.

  • Create a repeatable application release with separate environment values.
  • Observe a node or workload failure and identify the resources responsible for recovery.

Day 3

We trace DNS, Services, ingress, and the selected AWS load-balancer integration. You will examine network policies, service mesh use cases, affinity, and placement requirements.

  • Trace an external request through its AWS endpoint to an application Pod.
  • Diagnose a selector, network, or placement problem that prevents the intended response.

Day 4

You will examine configuration, secrets, persistent storage, and workload credentials. We distinguish Kubernetes RBAC from AWS permissions and connect autoscaling metrics to workload and compute capacity.

  • Diagnose a workload that can run but cannot access its required AWS service.
  • Apply application load and inspect resource use, replica changes, and capacity constraints.

Your container services, AWS integrations, and team responsibilities can shape the agenda. Get in touch to tailor the workshop to your application team's EKS adoption.

When an engineer sees a healthy container but no client response, the instructor can inspect selectors, endpoints, and the traffic controller. Your team can identify the missing relationship instead of rebuilding an image that already runs correctly.

Tell us which applications already use containers, what their EKS environment will provide, and who will own releases and incidents. We will recommend practical exercises for those responsibilities.