From AWS Lambda to Kubernetes: training for application engineers

We offer private, instructor-led training for engineers who operate event-driven functions on AWS Lambda and need to move selected execution paths to Kubernetes.

Your team knows function handlers and event sources. A container restart does not reproduce an event-delivery contract, including acknowledgement, retries, concurrency, and failed-event handling.

LearnKube uses a sample event processor to connect execution behavior to Kubernetes workloads. Your engineers will compare a service, worker, and bounded task before choosing the appropriate model.

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.

Preserve event behavior around the workload

  • Choose the execution model by comparing services, long-running workers, and bounded Jobs, so each selected function has an appropriate Kubernetes lifecycle.
  • Preserve event processing by examining acknowledgement, duplicate handling, and retry ownership, so replacement containers do not silently change application effects.
  • Diagnose incomplete work by tracing workload status, logs, and event outcomes, so engineers distinguish container failure from delivery or credential problems.
  • Define integration ownership by documenting the event source, scaling signals, and failed-event handling, so the team knows which behavior sits outside core Kubernetes.

Execution and delivery need separate decisions

A Lambda function is invoked through an event integration, with asynchronous retries supplied by Lambda for that invocation mode. Kubernetes provides workload controllers, not the same event-delivery contract. A service, queue consumer, or Job can be appropriate depending on the task. Engineers must preserve acknowledgement, duplicate handling, and failure reporting alongside the container's lifecycle.

I start with the event contract, not the container manifest. A restarted worker can repeat a completed side effect, so the team must decide when to acknowledge work and how to recognize duplicate delivery.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Execute an invocationService, worker, or JobSelect a workload controller
Retry a failed eventAcknowledgement and duplicate handlingRecover an interrupted task
Control concurrent workWorker capacity and metricsObserve processing under load
Access AWS servicesDestination workload credentialsDiagnose an access failure

How we approach this transition

We propose a workshop around one event-processing path and its failure behavior. Your team identifies the event source, acknowledgement point, retry rules, and external effects before it selects Kubernetes resources.

The exercises teach workload execution, diagnosis, and recovery. Event adapters and application changes remain explicit integration work, rather than features that Kubernetes supplies automatically when a function becomes a container.

A recommended four-day workshop for event-driven teams

This proposed agenda connects Kubernetes fundamentals to event processing. It distinguishes the workload lifecycle from the system that delivers and records work.

Day 1

We compare containers, Deployments, and Jobs with the requirements of a selected function. You will examine probes and releases for long-running workloads, alongside completion and retries for bounded tasks.

Hands-on exercises

  • Run a representative processor as a worker and compare it with a bounded Job.
  • Interrupt an attempt and inspect which work repeats after recovery.

Day 2

You will use Helm and compare Kustomize for event-processor configuration. We explain the control plane, kubelet, and reconciliation to distinguish Pod replacement from the decision to redeliver an event.

Hands-on exercises

  • Package workload resources and external endpoint configuration as a release.
  • Simulate a node failure and trace the resulting execution and event state.

Day 3

We examine DNS, Services, ingress, and network policies for the selected event path. You will discuss service mesh use cases, resource requests, and placement constraints for workers.

Hands-on exercises

  • Trace a connection between the processor and its event source.
  • Diagnose a network or placement failure that prevents a worker from receiving work.

Day 4

You will examine persistent outputs and configuration alongside autoscaling metrics. We cover secrets, authentication, RBAC, and AWS access through the destination's selected identity integration.

Hands-on exercises

  • Replay a sample event and inspect how the application recognizes an existing result.
  • Compare event backlog, processing capacity, and the metric available to the autoscaler.

Your event sources, retry rules, and AWS integrations can shape the agenda. Get in touch to tailor the workshop to your Lambda-to-Kubernetes transition.

Find the gap between a restart and a safe retry

An engineer can explain when the existing function records success and acknowledges an event. The instructor can interrupt the sample processor between those actions and examine which duplicate effects the application must prevent.

I liked how we delved deep into each of the topics and the interactive sessions to clarify doubts, whenever any.

— Aveek, Senior Data Engineer at DPG Media.

Start with one execution path and its event contract

Tell us which Lambda functions you want to move, how their events are delivered, and who will own integration and recovery. We will recommend a course focus for that execution model.

Discuss your team's training