AWS just handed platform teams direct programmatic access to the Kubernetes control plane and a way to freeze live containers — at the same time.
Amazon EKS 1.34 now exposes APIs to configure core control-plane components (kube-apiserver, kube-scheduler, kube-controller-manager) and adds support for the Kubernetes Kubelet checkpointing feature. The checkpointing support enables snapshotting of a container's runtime state when the container runtime and host kernel support checkpoint/restore (for example, CRIU-compatible runtimes); it is not a universal, kernel-agnostic live-migration mechanism. This is a new operational surface with real use cases and real ways to shoot yourself in the foot.
Why this matters
Control-plane configuration via EKS APIs removes the last purely manual component of managed Kubernetes on AWS. Want to tweak scheduler profiles, admission plugin ordering, or API-server flags at scale across clusters? You can now do it through EKS APIs instead of ad-hoc bootstrap hacks or opaque defaults. That's the right call: infrastructure-as-code for control-plane settings reduces snowflakes.
But it's also a new trust boundary. These APIs change the semantics of "cluster admin": they are effectively control-plane superpowers. If your org treats EKS control-plane APIs like any other IAM permission, you will be fine. If you bolt them onto an existing cluster-admin group with broad access and no audit or git-backed policy, you're courting outages and privilege escalation. This is not a theoretical risk — operator misconfiguration of admission plugins or scheduler policy can silently alter scheduling behavior across namespaces and break production traffic in ways standard RBAC doesn't easily expose.
Kubelet checkpoint: snapshots, not backups
The Kubelet checkpointing support is the other headline. With compatible runtimes and host kernels, checkpointing can persist a container's execution state (including process memory and FD state) for tooling, debugging, and experimental migration workflows. Important caveats: checkpoint images are heavyweight, depend on CRIU or equivalent runtime support, and are fragile across kernel and runtime versions. They are a forensic/tooling primitive, not a drop-in replacement for durable backups or application-level replication. Teams that treat checkpoint artifacts like backups will run into portability and consistency edge cases.
What else landed and why it matters
-
EKS Distro published an update to keep AWS-maintained downstream builds aligned with recent Kubernetes releases for customers running Kubernetes outside managed EKS.
-
Lambda SnapStart is expanding to container-image functions, reducing cold-start latency for already-initialized functions — a meaningful win for interactive APIs and some ML inference patterns. If you run large containerized Lambdas for inference, this changes cost-latency tradeoffs; pair it with AWS's newer higher network bandwidth options for very large functions.
-
Amazon Bedrock broadened model availability and tooling for agentic, retrieval-augmented workflows, including expanded regional availability and additional GovCloud tooling. Combined with Agent Registry and managed retrieval features, AWS is stacking primitives for workflows that must run inside regulated accounts.
What platform teams should do right now
Treat the new EKS control-plane APIs as high-risk IAM resources: gate them with scoped roles, require git-backed pull requests for any change, and instrument audit logs into the same pipeline that gates controller and infra changes. Add automated checks for scheduler and admission-plugin changes to your CI — these are the knobs that can quietly mutate cluster behavior.
Also, prototype Kubelet checkpointing in non-production. It will be invaluable for debugging and migration experiments, but it will also surface kernel and workload assumptions you didn't know you had.
Final thought
This trio of releases — control-plane APIs, checkpointing support, and SnapStart expansion — signals something clear: AWS is moving from managed primitives to managed operations primitives. You're getting more power, and with it more responsibility. Treat these new APIs like the sensitive control plane they are, or expect the first incident to be an object lesson in why "automation without guardrails" is a feature that bites back.
Related reading: see my deeper look at Lambda SnapStart for container-image functions and how Bedrock's agent tooling is evolving into a full operations platform.
Sources
- Containers Blog – EKS control plane configuration and Kubelet Checkpoint in Amazon EKS 1.34
- EKS Distro – Version Dependencies (EKS-D 1.37 v1-37-eks-2)
- Daily AWS – September 2, 2026 (Lambda SnapStart for container image functions; Bedrock Web Search in GovCloud)
- Artificial Intelligence Blog – Announcements (Claude Fable 5.1, GPT‑5.6 models, SageMaker HyperPod on EKS)
- Amazon Bedrock – AI Announcements (Claude Fable 5.1 and regional GPT‑5.6 availability)
- About Amazon – AWS Summit NYC and Agentic AI features (Agent Registry, Web Search, Managed Knowledge Base)