AWS

Amazon EKS: In-place control-plane rollback to previous Kubernetes minor (7-day window)

Amazon EKS adds in-place control-plane rollbacks to the previous Kubernetes minor for a seven-day window — useful, but nodes, CRDs and runtimes need checks.

July 13, 2026·3 min read·AI researched · AI written · AI reviewed

Amazon EKS just gave platform teams a real undo button: you can now reverse a control-plane version upgrade back to the previous minor release within a seven-day window for supported versions. That single change materially alters upgrade economics — you no longer have to build a whole new cluster and migrate workloads to get out of a botched upgrade.

This is overdue and the right call. Teams have been forced into awkward patterns — parallel clusters, heavy blue/green choreography, and fragile manual rollbacks — because the only safe exit was a full rebuild. With a seven-day in-place rollback window, the operating model tilts toward smaller, more frequent upgrades and a much faster feedback loop from staging to prod.

But don't confuse convenience with magic. The rollback targets the control plane; node components (kubelet, container runtimes, node OS, CNI, and any node-local daemons) won't automatically downgrade. CRDs, admission webhooks, and any operator-managed resources that changed under the newer control plane can still leave you with incompatible state. Treat the rollback as an escape hatch, not a substitute for compatibility testing and staged node upgrades.

Read the implementation notes and the immediate implications in our deeper piece on EKS rollbacks: Amazon EKS rollback: in-place control-plane downgrade to previous minor within 7 days.

This week's other launches are aligned: AWS is giving teams more control primitives rather than lower prices. Two deserve immediate attention.

A new primitive: Lambda MicroVMs

Lambda MicroVMs introduce a VM-like serverless primitive: VM-level isolation (no shared kernel), explicit lifecycle control, fast start/resume, and resumable state measured in hours. Architecturally, they sit between containers and full VMs — think lightweight, short-lived VMs with serverless operational semantics.

This is a big deal for agent-like workloads and stateful short-lived processes. Use cases that previously hacked around Lambdas (persistent sockets, long polling, or single-tenant isolation needs) can now run with clearer isolation and an explicit resume window. But expect fragmentation: developers will have to decide when a classic Lambda, a MicroVM, or a container on Fargate/EC2 is the right fit. And don't assume runtime compatibility with existing Lambda tooling — treat MicroVMs as a new runtime. We wrote more on this shift here: AWS Lambda MicroVMs: VM-level isolation and 8-hour resumable runtime.

AgentCore, managed knowledge bases, and the new RAG plumbing

Amazon Bedrock's AgentCore harness is focused on making it easier to build agentic workflows with a small API surface (create and invoke operations). Web search for grounded agent responses and Fully Managed Knowledge Bases (connectors, parsing, and retrieval tooling) make assembling multi-step agent workflows and enterprise RAG pipelines significantly simpler without stitching together disparate tools.

That convenience surfaces real governance and trust questions. AgentCore's interactive capabilities — shells, tool access, and web search — create new privilege boundaries that standard IAM patterns weren't built to model. The managed KBs are useful for mapping content into retriever-ready vectors, but teams must still define access controls, ingestion filters, and retention policies. This isn't just a feature race; it's an operational risk that needs integration with your audit, DLP, and secrets posture.

A few operational sidebars

CloudFormation's faster confirmation modes will speed iterative deployments — a welcome change for CI/CD-driven infra changes. ACM's ACME support lets you centralize public TLS issuance with standard ACME tooling. On compute, AWS announced new Graviton5-powered instance families offering improved compute over Graviton4 and optional local NVMe — another reason to re-evaluate cost/perf for latency-sensitive workloads.

The pattern across these announcements is clear: more reversible operations, stronger isolation primitives, and first-party agent tooling. That combination is powerful — and dangerous if teams treat it as a turnkey fix.

If you run platform or infra, the short checklist is obvious: bake more compatibility tests into upgrades, treat EKS rollback as a safety net not a cure, formalize governance for agent runtimes and knowledge ingestion, and benchmark Graviton5 instances before flipping instance families. My prediction: within 12 months most teams will upgrade Kubernetes more often because the rollback reduces the blast radius — and the teams that ignore node/CRD compatibility will be the ones still doing emergency migrations at 3 a.m.

Sources

amazon-ekslambda-microvmsamazon-bedrockgraviton5
← All articles
AWS

Amazon EKS 1.34: control-plane configuration APIs and Kubelet checkpoint support

EKS 1.34 introduces control-plane configuration APIs and Kubelet checkpoint support, enabling programmatic control of plane settings and runtime snapshots.

Sep 5, 2026·3mamazon-ekskubelet-checkpoint
AWS

AWS Lambda SnapStart for container-image functions: sub-second cold starts for 10 GB images

AWS Lambda SnapStart supports container-image functions up to 10 GB, enabling sub-second cold starts for containerized serverless CI/CD workflows at scale.

Sep 4, 2026·3maws-lambdasnapstart
AWS

AWS Lambda: Outbound Network Bandwidth Now Scales to 3 Gbps for 10 GB Functions

AWS Lambda outbound bandwidth scales to 3 Gbps for 10 GB functions. Review VPC egress, NAT sizing, monitoring, and treat Bedrock additions as a policy signal.

Sep 3, 2026·3maws-lambdaeks-distro