EKS training before your first application launch

We offer private, instructor-led training for application and platform teams preparing to launch an application on EKS or move an existing service there.

Your engineers understand the application and its current deployment process. The team needs evidence for the new release path, including traffic acceptance, state dependencies, and recovery limits.

LearnKube uses a representative launch rehearsal to connect Kubernetes releases to AWS integrations. Participants explain the acceptance and recovery evidence needed before their team supports the release.

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 the candidate application using a clear configuration and health model. The team can then explain the release it plans to accept.
  • Preserve the required service behavior by comparing traffic, data, and access observations. Acceptance then covers more than a completed rollout.
  • Investigate a failed rehearsal using Pod, controller, and AWS integration evidence. This helps the group identify which requirement or dependency needs attention.
  • Define the launch handoff by recording acceptance criteria, stop conditions, and owners. Application and platform teams can then explain what to do next.

A completed Deployment rollout shows the updated replicas, but other launch requirements still need evidence. The application's AWS load balancer path, external permissions, and data dependencies also affect acceptance. The team can rehearse these relationships with a sample workload and explain its acceptance and recovery criteria before the first release or migration.

A rollback restores a Pod template, not every external change. I ask which traffic, configuration, or data dependency also changed, then have the team explain what recovery requires beyond the Deployment revision.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Accept the candidate releaseRollout and service evidenceReview launch observations
Direct client trafficAWS routing and targetsTrace the candidate endpoint
Preserve application dataState and recovery dependenciesReview replacement behavior
Assign launch responsibilitiesStop criteria and ownersRehearse a support handoff

Joynext already used EKS for its OTA service and planned to move its Navigation cloud from Nomad to EKS. The engineering group included developers with different Kubernetes experience, with security and management joining selected parts of the training.

The buyer wanted private instruction tailored to its use cases despite existing online course resources. LearnKube delivered onsite Kubernetes training. After the course, the buyer reported that it went well and planned to apply ideas from it.

For a team approaching an EKS application launch, we recommend the following release-rehearsal workshop. Its proposed exercises follow one candidate application through acceptance, recovery, and the support handoff.

This proposed agenda follows the candidate application and a clear set of acceptance questions. It connects a successful lab release to the extra evidence needed for a production handoff.

Day 1

We connect images, Deployments, probes, and update strategies to application acceptance. Participants compare the new release with the behavior expected by its users.

  • Introduce a candidate version and inspect rollout and application health separately.
  • Define a stop condition for a release that does not meet its required behavior.

Day 2

We review Helm output and the controllers that maintain the application. The group records which configuration belongs to the release and which dependencies need a different owner.

  • Compare candidate and current resources without hiding their external dependencies.
  • Rehearse a failed update and explain what the recorded revision can restore.

Day 3

We trace DNS, an AWS load balancer, Kubernetes routing, and placement to the application. Participants gather the observations needed before directing clients to the new workload.

  • Explain why a ready Pod does not by itself establish that the intended client can reach the service.
  • Investigate a candidate replica that lacks the capacity or connectivity its release requires.

Day 4

We connect persistent state, credentials, scaling signals, and RBAC to the launch criteria. The team brings this evidence together for a bounded release and support rehearsal.

  • Compare replacement behavior with the application's data and external-service requirements.
  • Present the acceptance record, remaining questions, stop conditions, and operating owners.

Your current release process, EKS target, and launch responsibilities can shape the agenda. Get in touch to tailor the workshop to your EKS application launch.

When an engineer presents a successful rollout as the whole launch decision, the instructor can trace the client path and state dependencies. Participants then identify the missing observation and the owner who can supply it.

A release manager in a Sony Kubernetes course that included EKS described the practical material:

Practise material was nice and building up the concept

— Laxmikant, Release Manager at Sony Interactive Entertainment.

Tell us what your team plans to release on EKS, which behavior must stay the same, and who owns the application and its dependencies. We will recommend a course focus and launch-rehearsal exercises.

You can buy the agreed training through AWS Marketplace. Contact us if you need a private offer.