From self-managed Kubernetes to Amazon EKS: training for platform teams

We offer private, instructor-led training for Kubernetes platform engineers who plan to move from their own cluster management to Amazon EKS.

Your team knows workload resources and cluster components. AWS integrations add distinct access and operating decisions, including IAM, VPC networking, storage, node capacity, and upgrade responsibilities.

LearnKube uses a representative workload to connect existing Kubernetes knowledge to EKS. Your engineers will investigate the identities and infrastructure dependencies behind a successful deployment.

Discuss your team's training

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

Preview: course-wide figures are not yet available.

  • Hands-on learning
    60%
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    86%
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    92%
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    95%
    Of respondents applied their new skills at work within 90 days.

Connect workload operation to the AWS environment

  • Deploy the workload on EKS by reviewing network, storage, and compute dependencies, so familiar resources use the AWS integrations they require.
  • Preserve application access by configuring the selected workload identity mechanism and IAM permissions, so service calls use the intended credentials after the move.
  • Diagnose cross-layer failures by separating Kubernetes events from AWS access and infrastructure evidence, so engineers can identify which system rejected or blocked an operation.
  • Assign continuing duties by documenting node, upgrade, integration, and incident ownership, so the team understands what EKS manages and what it must retain.

Cluster access and AWS access follow different paths

EKS introduces AWS access mechanisms around familiar Kubernetes APIs. Access entries connect IAM principals with cluster permissions, while EKS Pod Identity can supply AWS credentials to workloads on supported compute. These solve different access problems. The team must connect its existing roles, application permissions, and compute choices to the mechanisms used on the destination.

I want the team to identify which IAM role the application actually uses. A successful AWS call can hide an unintended dependency on the node role, which can fail when compute options change.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Grant operator accessEKS access and permissionsDiagnose a rejected API call
Access an AWS serviceWorkload credentials and IAMIdentify the effective role
Expose application trafficVPC and load-balancer integrationsTrace an external request
Maintain workload capacityCompute options and node lifecycleRehearse workload replacement

How we approach this transition

We propose a workshop based on your current cluster and selected EKS compute options. The team identifies the integrations behind its workloads and the responsibilities that change when the control plane moves to EKS.

The exercises follow one application's release, traffic, storage, and AWS access paths. Identity examples use a mechanism supported by the selected compute environment rather than assume that every EKS option behaves identically.

A recommended four-day workshop for Kubernetes teams adopting EKS

This proposed agenda shortens familiar fundamentals. It focuses on the AWS operating model around workload APIs your engineers already use.

Day 1

We review the application's resource requirements, probes, and rollout behavior against EKS. You will identify where networking, storage, and compute configuration affect otherwise familiar manifests.

Hands-on exercises

  • Deploy a representative application and identify its EKS integration dependencies.
  • Rehearse a failed release and distinguish workload recovery from infrastructure changes.

Day 2

You will use Helm and compare Kustomize for destination-specific resources. We review control-plane and node responsibilities across the selected EKS compute options and maintenance model.

Hands-on exercises

  • Separate portable application configuration from EKS-specific settings.
  • Rehearse workload replacement during a controlled capacity or node change.

Day 3

We connect Pod networking, Services, DNS, and ingress to the selected VPC and load-balancer configuration. You will examine network policies, service mesh use cases, and placement constraints.

Hands-on exercises

  • Trace an external request through the AWS and Kubernetes traffic path.
  • Diagnose a workload that lacks suitable capacity or required network reachability.

Day 4

You will distinguish operator access to Kubernetes from workload access to AWS services. We cover secrets, persistent storage, HPA metrics, node capacity, and the roles involved in each permission decision.

Hands-on exercises

  • Inspect the identity used by a Pod for a sample AWS API request.
  • Diagnose a failed operation and identify whether the correction belongs in cluster access, Kubernetes RBAC, or IAM.

Your EKS compute options, AWS integrations, and operational responsibilities can shape the agenda. Get in touch to tailor the workshop to your self-managed-Kubernetes-to-EKS transition.

Follow the credential actually used by the workload

When an engineer assumes that a Kubernetes role binding permits access to an AWS service, the instructor can inspect the application's credential path. Your team can distinguish cluster authorization from the IAM decision for the external service.

Asked what he liked most about a separate LearnKube course, Zebin answered:

the systematic way to explain the subject

— Zebin, Consultant at F5.

Bring the cluster design and intended EKS configuration

Tell us how you manage Kubernetes today, which EKS compute and integration options you plan to use, and who will own operations. We will recommend exercises for those changes.

Discuss your team's training