Native EKS Backup: Basics and Two Tutorials [2026]

How Do You Back Up AWS EKS?

You can back up Amazon EKS using AWS Backup, which provides a fully managed and centralized service for protecting both the cluster state and persistent application data. AWS Backup supports automated scheduling and retention policies, helping standardize and manage backup operations across your EKS environments. It allows for immutable backups, as well as cross-region and cross-account copy capabilities for disaster recovery and compliance needs.

This integration eliminates the need for custom scripts or third-party tools. AWS Backup’s EKS integration does not use backup sidecars, controllers, or custom scripts. You can restore entire EKS clusters, individual namespaces, or specific persistent volumes depending on your recovery needs.

However, AWS Backup with Amazon EKS has several important limitations. It does not support all volume types, such as those provisioned via in-tree plugins, CSI migration, or FSx drivers. Key infrastructure components like VPCs, subnets, and container images are excluded, and S3 backups are restricted to entire buckets. Additionally, EKS cluster state is always backed up as a full snapshot with no incremental option, and cold storage transitions apply only to persistent volumes, not the full backup. We’ll discuss these limitations in more detail below.

This is part of a series of articles about Kubernetes security

In this article:

• Understanding Amazon EKS Backup Structure
• Tutorial #1: Backup your EKS Clusters with AWS Backup
• Limitations of AWS EKS Backup
• Tutorial #2: Policy-Driven EKS Backup with N2W
• Comparison table: when to use each

Amazon EKS Backup Structure

Amazon EKS backups in AWS Backup are organized into a hierarchical structure built around recovery points. This structure separates cluster configuration from persistent data while grouping them under a single logical backup.

At the top level is the composite recovery point. This recovery point represents the entire EKS cluster backup. It acts as a container that groups all related backup components created during the backup operation.

Inside the composite recovery point are nested recovery points. Each nested recovery point corresponds to a specific resource that is part of the cluster. This design allows AWS Backup to track and restore individual components, such as cluster state or persistent volumes, independently when needed.

One nested recovery point is the Amazon EKS Cluster Configuration child recovery point. This contains the EKS cluster state. The cluster state includes Kubernetes manifests (YAML or JSON) that define the desired configuration of resources such as secrets, ConfigMaps, StatefulSets, DaemonSets, storage classes, replica sets, persistent volume claims, custom resource definitions, roles, and role bindings.

Additional nested recovery points are created for persistent storage. These are called Persistent Volume child recovery points and contain backups of supported storage types, including Amazon EBS, Amazon EFS, and Amazon S3, when used with supported EKS add-on CSI drivers.

Not all components of an EKS environment are included in this structure. Backups exclude container images stored in external repositories such as Amazon ECR or Docker Hub. They also exclude infrastructure components like VPCs and subnets, as well as auto-generated Kubernetes resources such as nodes, pods created automatically, events, leases, and jobs.

Each child recovery point is encrypted. The EKS cluster configuration child recovery point is encrypted using the KMS key associated with the target Backup Vault. Persistent storage recovery points are encrypted according to the encryption model of the underlying storage service, such as EBS snapshots, S3 backups, or EFS backups.

Tutorial #1: Backup your EKS Clusters with AWS Backup

AWS Backup provides a native way to back up Amazon EKS clusters by creating a composite recovery point that includes both the cluster state and the persistent volumes attached to it. This backup process allows you to capture the Kubernetes configuration and associated persistent data in a coordinated and recoverable way.

What Gets Backed Up

An Amazon EKS backup consists of two key components:

• EKS Cluster State: Includes Kubernetes manifests that define your cluster’s desired state, such as deployments, secrets, config maps, persistent volume claims, CRDs, and RBAC policies.
• Persistent Storage: Captures the data volumes used by the cluster, including EBS, EFS, and S3 volumes linked through persistent volume claims and supported by the EKS CSI Driver.

These are grouped into a composite recovery point that nests separate recovery points for each component.

Note: EKS backups do not include container images, underlying infrastructure (like VPCs or subnets), or auto-generated Kubernetes resources such as ephemeral pods or jobs.

Prerequisites

Before running a backup:

• Ensure that EKS cluster authorization mode is set to API
  
• Attach the AWSBackupServiceRolePolicyForBackup IAM policy to allow AWS Backup to access your cluster and persistent volumes.
  
• If S3 is used in your cluster, include the AWSBackupServiceRolePolicyForS3Backup and validate S3-specific prerequisites.
  
• Backup encryption will follow the key configuration of the target backup vault (via AWS KMS).

Step 1: Create an On-Demand EKS Backup

You can create an EKS backup via the AWS Backup console:

1. Open the AWS Backup console and navigate to Protected Resources.
   
2. Click Create on-demand backup button.

3. Under Resource type, select Amazon EKS.

4. Select the EKS cluster to back up.
   
5. Click Create on-demand backup.
   
6. Configure settings like retention period and cold storage transitions.
   
7. Click Create on-demand backup to start the job.

Each backup creates a composite recovery point, which is trackable via its ARN. Nested recovery points are created for the cluster state and each persistent volume.

Backup Job Status

A backup job can end in one of three states:

• Completed: All components were backed up successfully.
  
• Failed: The job failed and should be retried after resolving issues.
  
• Partial: Some resources failed to back up; failed components can be retried individually.

You can monitor these states and set up notifications for backup events.

Managing Recovery Points

You can take the following actions on recovery points:

• Copy: Composite and supported nested recovery points can be copied across regions or accounts.
  
• Delete: Composite points can only be deleted after all nested points are deleted or disassociated (except for the cluster state, which cannot be disassociated).
  
• Disassociate: Nested recovery points can be unlinked from a composite, except the cluster state.
  
• Restore: Nested recovery points with a “Completed” status can be restored individually.

AWS Backup supports full lifecycle management and cold storage transitions for persistent volume backups, enabling cost-efficient retention of long-term backups.

Step 2: Restore an Amazon EKS Cluster

You can restore Amazon EKS backups using the AWS Backup console or CLI by selecting the desired recovery point from a backup vault. Each EKS backup is a composite recovery point, which contains both the cluster state and persistent volumes.

Restore Types and Targets

AWS Backup supports several restore types, each offering different levels of granularity:

• Full Cluster Restore: Restores all Kubernetes resources and persistent volumes to either a new or existing EKS cluster. This type does not overwrite existing resources—objects that already exist in the target cluster are skipped.
  
• Namespace Restore: Lets you restore up to five specific namespaces, including associated Kubernetes objects and persistent storage. Namespace-scoped resources are restored without impacting other parts of the cluster.
  
• Persistent Volume Restore: Allows for standalone restores of EBS, EFS, or S3 storage, without requiring the full cluster state to be restored.

When restoring to an existing cluster, the operation is non-destructive. Existing Kubernetes resources are preserved, and skipped objects can be monitored using SNS notifications.

Prerequisites and Permissions

Before performing a restore:

• Ensure the IAM roles used in the original cluster (e.g., pod IAM roles, IRSA settings, OIDC providers) exist in the target account and Region.
• Match the EKS version between source and target clusters to avoid API compatibility issues.
• Pre-install any required CSI storage drivers in the target cluster.
• Confirm that S3 buckets and container image repositories are accessible with the necessary cross-account or cross-region permissions.
• Ensure that security groups, subnets, and availability zones match the restore configuration, especially when restoring EBS volumes.

Use the AWSBackupServiceRolePolicyForRestores policy for general restore operations. For clusters that include S3 data, attach the AWSBackupServiceRolePolicyForS3Restore policy as well.

Restore Workflow (Console)

To restore an EKS cluster using the AWS Backup console:

1. Open the AWS Backup console and navigate to Backup vaults.
2. Select the vault and find the recovery point for your EKS cluster.
3. Click Restore, then choose one of the following options:
   • Restore full EKS cluster
   • Select namespaces to restore
4. Configure the target cluster:
   • For a new cluster, define the cluster name, version, VPC settings, node groups, security groups, and IAM roles.
   • For an existing cluster, select it from the dropdown menu.
5. Choose the appropriate IAM role for the restore operation.
6. Optionally adjust the restore order for Kubernetes resources.
7. Click Restore backup to initiate the process.

Persistent Storage Configuration

During the restore, AWS Backup remounts persistent storage:

• EBS: Requires selecting an Availability Zone. AWS Backup restores the volume and places pods in matching zones to ensure volume mounting.
• S3: Buckets are remounted if accessible and versioned properly.
• EFS: Restored to a new directory prefix. Access points and mount targets must be manually reconfigured post-restore.

Key Considerations

• Restores are non-destructive and won’t overwrite existing Kubernetes objects. Existing objects are skipped even if they are misconfigured, drifted, or out of date.
• Use EKS audit logs and SNS notifications for troubleshooting skipped or failed objects.
• Verify compatibility of cluster-scoped objects and namespaces with the target environment before initiating the restore.

Limitations of AWS EKS Backup

Although AWS Backup provides native support for protecting EKS clusters, it has important limitations. These affect what resources can be backed up, how data is stored, and which environments are supported. Understanding these constraints is essential for designing a reliable backup strategy.

Key limitations include:

• Unsupported Volume Types: Persistent volumes provisioned via CSI migration, in-tree storage plugins, or ACK controllers are not supported.
• Amazon FSx: FSx volumes mounted through the CSI driver cannot be backed up with AWS Backup.
• S3 Prefix Restrictions: Backups do not support specific prefixes within Amazon S3 buckets—only full buckets can be backed up.
• S3 Snapshot-Only: S3 backups created as part of an EKS backup are limited to snapshot types only.
• No Support for AWS Outposts: EKS clusters running on AWS Outposts are not supported.
• No Infrastructure or Image Backups: EKS backups exclude VPCs, subnets, and container images from Amazon ECR or other registries.
• Partial Support for Cold Storage: Only persistent volume recovery points can transition to cold storage—not the composite recovery point.
• No Backup Indexing or Search: There is no native support for indexing or searching EKS backups.
• Cluster State Backups Are Full Only: The EKS cluster state is always backed up as a full backup, not incrementally.
• Quota Limits: Backup and restore jobs are subject to AWS Backup service quotas, which may impact large-scale operations.

These limitations highlight the need to evaluate AWS Backup’s capabilities alongside other tools, especially for advanced recovery or hybrid environments.

Tutorial #2: Policy-Driven EKS Backup with N2W

AWS Backup’s native EKS integration covers the basics, but it has a hard ceiling: it only manages EKS in isolation. If your environment includes RDS databases, EC2 instances, and EKS clusters that all need to be protected together (and recovered together) you’re orchestrating that across separate tools and workflows.

How N2W’s EKS Backup Works

N2W takes a different approach. It uses Velero to handle the Kubernetes-layer backup and recovery, and integrates that directly into the same policy engine you use for every other AWS resource. 

The result: one policy can back up an EKS namespace running a WordPress deployment and the RDS database it depends on. So it’s scheduled, automated, and recoverable as a unit.

This architecture also means N2W isn’t subject to some of the limitations of AWS Backup’s native EKS support: there’s no 5-namespace restore cap, namespace renaming during recovery is supported, and you can restore cluster-scoped resources selectively.

Prerequisites

Before adding EKS to an N2W policy, Velero must be installed as a one-time setup. See the Velero Installation Guide in our docs (Appendix H) for full instructions. At a minimum you’ll need:

• An S3 bucket for storing Kubernetes manifests
• An IAM role with S3 and EBS snapshot permissions, configured via IRSA or EKS Pod Identity
• The velero-plugin-for-aws installed on the cluster
• Network connectivity between the VPC and the EKS API endpoint (outbound HTTPS, port 443)
• An EKS Access Entry for the N2W instance’s IAM role with AmazonEKSClusterAdminPolicy scoped to the Velero namespace

IRSA is the recommended authentication method for production environments. EKS Pod Identity is simpler to configure if your cluster doesn’t have an OIDC provider set up.

Step 1: Add EKS Resources to a Policy

1. In the N2W console, navigate to Policies and open or create a policy.
2. Select the Backup Targets tab and click Add Backup Targets.
3. Choose EKS Clusters to back up an entire cluster (all namespaces, cluster-scoped resources, and persistent volumes), or EKS Namespaces to target specific namespaces only.
4. Select your cluster or namespaces from the list.
5. Configure your schedule, retention, and lifecycle settings as you would for any other resource type.

To combine EKS with other AWS resources in the same policy (for example, an EKS namespace and an RDS instance that the application depends on) simply add both as backup targets within the same policy. They’ll be backed up on the same schedule and managed together.

Step 2: Recover EKS Clusters or Namespaces

1. In the Backup Monitor, select the AWS Cloud view.
2. Use the Search backups box to find your EKS resource by resource ID or tag value.
3. Filter by resource type using the By Instance list — select EKS Cluster or EKS Namespace.
4. Select the resource, choose a backup from the list, and click Recover.
5. Select the target Cluster Name from the list that appears.

To restore the full cluster: Select the cluster backup. This restores all namespaces, workloads, persistent volumes, and optionally cluster-scoped resources.

To restore specific namespaces:

1. Select the Namespaces tab.
2. To include cluster-scoped resources (ClusterRoles, ClusterRoleBindings, CRDs), check Include Cluster Resources. This is recommended when restoring into a new or empty cluster; leave it unchecked when restoring into an existing cluster to avoid conflicts.
3. Select one or more namespace names from the Namespace Name list.
4. Optionally rename each namespace using the Target Namespace Name field — useful for restoring into the same cluster without overwriting the live environment.
5. Click Recover.

When to Use N2W vs. Native AWS Backup for EKS

	AWS Backup (Native)	N2W
Namespace restore limit	5	No hard limit
Namespace renaming on restore	No	Yes
Cross-cluster restore	Yes	Yes
Cross-region DR for EKS	No (backup-then-copy, copy can be automated)	Yes
Cross-account DR for EKS	No (backup-then-copy, copy can be automated)	Yes
Application-consistent backups	No (crash-consistent PV snapshots)	Yes

When each makes sense

Native AWS Backup works if EKS is your only workload and you’re happy living inside AWS’s plan-and-resource-assignment model. Setup is light. Day-2 ops stay simple.

N2W fits when EKS is one piece of a bigger AWS footprint that has to be backed up, restored, and recovered together. The v4.6 release adds cross-region and cross-account DR for EKS specifically, so the same policy that protects your EC2 fleet and RDS databases now covers your Kubernetes workloads with matching resiliency.

Two scenarios where the math gets obvious:

1. A namespace restore beyond AWS Backup’s 5-namespace limit.
2. A regional outage where you need to recover EKS, RDS, and EC2 into a clean DR account without scripting your way out of it.

Try N2W for Amazon EKS Backup free