From Amazon ECS to Kubernetes: training for teams

Private, instructor-led training for AWS application and infrastructure engineers who need to move ECS workloads to Kubernetes.

Your team understands task definitions, services, and AWS integrations. Kubernetes changes how engineers group containers, control releases, route traffic, and give workloads access to dependencies.

LearnKube uses a sample ECS-style application to connect these tasks. Your engineers will define its Kubernetes resources, release updates, and diagnose traffic and credential problems.

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.

Translate operating behavior, not only task definitions

  • Deploy the workload by defining Pod boundaries, controllers, and configuration, so each container has the required lifecycle.
  • Preserve dependency access by reviewing traffic routes and workload credentials, so the application can reach its services after the move.
  • Diagnose failed updates by inspecting probes, events, and Service endpoints, so engineers distinguish placement, startup, and routing errors.
  • Define the capacity handoff by documenting application scaling and node ownership, so developers and platform engineers know which demand each must manage.

An ECS service is not a Kubernetes Service

An ECS task definition describes containers and their runtime requirements. An ECS service maintains tasks and coordinates deployment behavior. Kubernetes distributes those responsibilities across Pods and workload controllers. A Kubernetes Service provides stable network access to selected Pods rather than managing their release. Similar names therefore need careful interpretation.

The word service hides an important difference here. I separate replica management from network access first, because an engineer who expects a Kubernetes Service to replace failed tasks will investigate the wrong resource.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Define an ECS taskPod boundaries and configurationDeploy related containers
Maintain service tasksDeployments and rollout controlsRecover a failed update
Connect through load balancersServices and ingress controllersTrace incoming traffic
Grant AWS resource accessWorkload identity integrationDiagnose missing credentials

How we approach this transition

We propose a workshop that starts with a representative task definition and its operating requirements. Your team identifies container relationships, traffic paths, credentials, and scaling behavior before choosing Kubernetes resources.

The exercises reveal differences that a manifest conversion can miss. Engineers will practice the release and support decisions they will own on the destination platform.

A recommended four-day workshop for AWS engineers

This proposed agenda builds on your team's experience with containers and AWS. We focus on Kubernetes concepts through examples that include the dependencies your team needs to preserve.

Day 1

You will compare task definitions and ECS services with Pods, Deployments, and Kubernetes Services. We explain probes, replica management, rolling updates, and rollback.

Hands-on exercises

  • Deploy a sample application with explicit Pod boundaries and configuration.
  • Introduce an unready version and restore the previous deployment.

Day 2

We explain Helm and Kustomize, then show how controllers, nodes, and the API relate to operations. You will distinguish application replicas from the infrastructure capacity that supports them.

Hands-on exercises

  • Package application configuration for separate environments.
  • Simulate a node failure and inspect replacement Pods and available capacity.

Day 3

You will trace DNS, Services, ingress, and network policies through the application. We compare placement controls and discuss when a service mesh can help manage traffic.

Hands-on exercises

  • Trace an incoming request through the destination's load balancer and ingress.
  • Diagnose a dependency connection blocked by a selector or network policy.

Day 4

We compare workload identity with Kubernetes API permissions, then review secrets and persistent storage. You will connect autoscaling metrics to resource requests and node capacity.

Hands-on exercises

  • Diagnose credential delivery for an application dependency in the agreed lab environment.
  • Generate load and observe application scaling against available node capacity.

Your ECS workloads, AWS integrations, and infrastructure responsibilities can shape the agenda. Get in touch to tailor the workshop to your ECS-to-Kubernetes transition.

Catch misleading similarities early

If an engineer expects a Kubernetes Service to restart a failed container, the instructor can trace the responsibilities of the kubelet and the Deployment. A failed-container exercise makes the difference clear before your team writes its support procedures.

Good topic coverage, went fairly deep on details and underlying implementations. Liked the hands on labs with the environment and commands all being set up

— Wes, Coinbase.

Bring your tasks and AWS dependencies

Tell us which ECS workloads you run, how Kubernetes will provide their AWS integrations, and who will own deployment and capacity. We will recommend a course focus and exercises for your team.

Discuss your team's training