re:Invent 2025 - Simplify backup for stateful Amazon EKS workloads

Platform engineers managing stateful Kubernetes workloads have traditionally relied on third-party add-ons, custom scripts, or inconsistent per-team processes to protect their data. With native Amazon Elastic Kubernetes Service (Amazon EKS) support now available in AWS Backup, that complexity is no longer necessary. In session CNS209 at re:Invent 2025, Santosh Vallurupalli, Senior Solutions Architect at AWS, walked through this new capability, the steps to configure it, and a reference architecture for deploying backup protection across a real-world organization. In this post, we'll cover what you can now protect in EKS clusters, how to configure your first backup plan in two steps, and how to structure your accounts for a resilient, production-grade backup strategy.

AWS Backup is a fully managed service that centralizes and automates data protection across 20+ AWS services and hybrid workloads. Rather than managing each service's backup mechanism separately, you define backup plans that capture your requirements: which resources to protect, how many copies to retain, where copies should live, and what lifecycle policies apply. AWS Backup then handles execution on your behalf. You can manage these plans through a decentralized model where individual application teams own backup configurations in their own accounts, or through a centralized model using AWS Organizations where a backup administrator defines policies once and distributes them to member accounts across the organization.

What native EKS support covers

The newly launched EKS integration covers two categories of data. The first is Kubernetes objects, including both cluster-scoped resources such as ClusterRoles, ClusterRoleBindings, and StorageClasses, and namespace-scoped resources such as Deployments, ConfigMaps, and Secrets. The second is stateful workload data: persistent volumes (PVs) backed by Amazon EBS, Amazon S3, and Amazon EFS. You can back up application data alongside its Kubernetes configuration in a single operation, with no add-ons or custom scripts required. You select EKS from the AWS Backup console, choose your clusters, and you are ready to go.

This capability is most valuable before maintenance windows. Before performing a version upgrade, an API migration, or an Amazon Machine Image (AMI) rollout, you can use AWS Backup to create a consistent snapshot of the cluster state. If something goes wrong during the window, you can restore objects from that snapshot and bring the cluster back to its pre-maintenance state without manual reconstruction. At restore time, you have two choices: restore the full set of objects onto an existing target cluster, or have AWS Backup provision a new skeleton cluster first and then run the restore on top of it. You can also scope a restore to specific namespaces rather than the full cluster, which is useful when only a subset of workloads needs recovery.

Getting started in two steps

Setting up AWS Backup for EKS involves two steps. The first is creating a backup plan, where you define what to protect, how many copies to retain, where copies should live, and what lifecycle policies apply. AWS Backup provides pre-built templates for common scenarios. For more control, you can build a custom plan through the console's guided configuration or define the plan as a JSON file and import it directly. Each of these paths leads to the same execution engine.

The second step is assigning resources to your backup plan. You can do this manually by browsing and selecting individual resources, or you can use tag-based assignment. With tag-based assignment, you specify a tag key and value, and AWS Backup automatically discovers supported resources carrying those tags and brings them into scope. Resources tagged correctly at creation time are protected from that point forward, with no additional manual steps required each time a new workload is deployed.

A reference architecture for production use

For organizations running EKS at scale, the session presented a multi-account architecture within an AWS organization that addresses both disaster recovery and ransomware resiliency. Access into the environment is controlled through AWS IAM Identity Center and multi-factor authentication (MFA) for backup administrators.

The architecture relies on several designated account types. A backup delegated admin account is where administrators centrally create and distribute backup policies to workload accounts across the organization. Without this separation, administrators would need direct access to each individual workload account, which becomes impractical as the number of accounts grows. A separate CMK (customer managed key) account centralizes the lifecycle management of encryption keys used to encrypt backups, including key rotation, renewal, and deletion, within a single defined boundary.

Workload accounts contain the EKS clusters and their PVs. Backup policies from the delegated admin account trigger the primary backup copy in each workload account. Amazon GuardDuty integrates with AWS Backup to run real-time scanning of backups and flag items that warrant further review, providing forensic validation as a built-in step of the workflow.

Data bunker accounts are logically isolated AWS accounts that host second and third backup copies. These accounts run no workloads and are accessible only through break-glass mechanisms. The architecture uses two data bunker accounts: one in the primary region and one in a separate region to provide regional resiliency. Backups stored in logically air-gapped vaults within these accounts are immutable. No user, including root and administrative users, can modify or delete them once stored. This property gives you a trustworthy recovery point even when your primary environment is no longer reliable.

A forensics account rounds out the architecture, serving as a dedicated space for testing restore workflows, validating that backups are complete and usable, and running analysis when needed. Treating restore testing as a scheduled activity rather than something reserved for real incidents gives you confidence in your recovery posture before you actually need it.

This architecture applies beyond EKS. Since AWS Backup supports 20+ AWS services, the same multi-account structure works for combinations of workloads. Replace EKS with Amazon RDS, Amazon DynamoDB, or other supported services and the organizational pattern remains the same. To explore the full feature set and get started, visit the AWS Backup service page or watch the full session below.

Watch the full session: re:Invent 2025 CNS209 - Simplify backup for stateful Amazon EKS workloads