kubernetesoperatorsPractitioner

Forensic Container Checkpointing on Amazon EKS: What You Need to Know

5 min read AWS Containers BlogAug 12, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

Forensic container checkpointing exists to address the need for capturing the state of running containers, especially for debugging and recovery scenarios. In production, applications often need to maintain their state across failures or during migrations. This capability allows you to freeze a container's state, making it easier to analyze issues or restore functionality without losing critical data.

The checkpointing process utilizes the Kubelet Checkpoint API, which provides an HTTP endpoint on each node. When you trigger a checkpoint, the kubelet processes the request, verifies the identity of the caller, and invokes the CRI CheckpointContainer RPC on containerd. This, in turn, calls the CRIU tool, which captures the container's full runtime state, including memory, file descriptors, and network connections. The checkpoint data is then stored as a tar archive in the /var/lib/kubelet/checkpoints directory, allowing the container to continue running without interruption.

In production, you need to ensure that your environment meets specific prerequisites, such as running Kubernetes 1.34 or later with containerd 2.x. Be aware that while restoring checkpoints on the same host is straightforward, migrating them to different hosts can introduce challenges. TCP connections typically do not survive this migration, requiring your application to re-establish connections, which can complicate recovery efforts. It's crucial to test your setup thoroughly to understand these limitations and prepare for them accordingly.

Key takeaways

→Utilize the Kubelet Checkpoint API to create container checkpoints via HTTP requests.
→Leverage CRIU to capture a container's full runtime state, including memory and network connections.
→Store checkpoint data as tar archives in /var/lib/kubelet/checkpoints for easy access.
→Ensure your Amazon EKS cluster runs Kubernetes 1.34 or later to use checkpointing features.
→Be cautious when migrating checkpoints between hosts due to potential loss of TCP connections.

Why it matters

In production, the ability to checkpoint containers can significantly reduce downtime and data loss during failures. This capability is essential for maintaining the reliability of stateful applications in dynamic environments like Kubernetes.

Code examples

Bash

# SSH into a worker node or use AWS Systems Manager Session Manager
containerd --version   # Expect 2.1.0 or later
criu --version         # Expect 3.15 or later

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Linux FoundationSponsor

Industry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.

Get CKA certified →

Forensic Container Checkpointing on Amazon EKS: What You Need to Know

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Why Your Controller's Cache Keeps the API Server Running Smoothly

Taming Secret Sprawl in Multi-Account Kubernetes with External Secrets Operator

Mitigating Staleness in Kubernetes Controllers: What You Need to Know