Native Amazon EKS Backups with AWS Backup

#aws #eks #backup #kubernetes

TL;DR: AWS Backup now protects Amazon EKS. It backs up your cluster state and persistent data (EBS, EFS, S3) using one policy-driven workflow. You can restore a full cluster, a namespace, or specific volumes even into a brand-new EKS cluster.

It’s been available since Nov 2025, and it’s now a dependable option for production teams.

Why this matters:

Before this, many teams used scripts or tools like Velero to back up Kubernetes. It worked, but it was hard to run at scale.

Now you get:

One place to manage backups for EKS and other AWS services.
Policy-based schedules, retention, encryption, and immutability.
A single “composite” recovery point that keeps cluster state and data in sync.
Stress-free restores, including creating a new EKS cluster during restore.

What AWS Backup protects in EKS:

AWS Backup creates a composite recovery point(cluster state + persistent storage «EBS, EFS, S3» as a single, consistent recovery point) with child recovery points:

Cluster state (full backup)
- Examples: cluster name and settings, IAM role, VPC and network settings, logging, encryption, add-ons, access entries, managed node groups, Fargate profiles, pod identity associations, Kubernetes manifests.
Persistent storage (incremental where supported)
- Amazon EBS, Amazon EFS, Amazon S3 buckets (bucket-level snapshot backups)

What is not included:

Container images in external registries (ECR, Docker, etc.)
Infrastructure like VPCs and subnets
Auto-generated runtime objects like nodes, auto-generated pods, events, leases, jobs
Some CSI/ACK plugin scenarios (see Limits below)

How to enable and create a backup (Console):

Open AWS Backup → Settings → Configure resources → opt in to Amazon EKS.
Go to Protected resources → Create on-demand backup.
Choose Resource type: Amazon EKS → select your cluster.
Choose an IAM role with:
- AWSBackupServiceRolePolicyForBackup
- AWSBackupServiceRolePolicyForRestores
- If your cluster uses S3: also add AWSBackupServiceRolePolicyForS3Backup
Configure window, retention, and (optionally) lifecycle to cold storage for supported child recovery points.
Create the on-demand backup.

Tip: Set EKS Cluster authorization mode to API or API_AND_CONFIG_MAP so AWS Backup can create Access Entries.

Understanding recovery points and status:

Composite recovery point (parent): the EKS backup as a whole.
Child recovery points: cluster state and each persistent store.

Statuses:

Completed: everything finished; the cluster is protected.
Partial: some parts completed, others failed. You can re-run failed parts and still restore the successful ones.
Failed: the job did not complete; fix the issue and try again.

Restore options (Console):

In Protected resources, pick your EKS composite recovery point → Restore.
Scope:
- Full cluster
- Namespace (only to an existing cluster)
- Individual persistent volumes
Destination:
- Existing cluster (non-destructive; only the delta is applied)
- Original cluster
- New cluster (AWS Backup can provision it during restore)
Choose IAM role for restore. Review settings → Restore.

You can monitor child recovery points during restore. If some parts fail, you can restore the successful ones (for example, EBS volumes) separately.

Copying, vaults, and immutability:

You can copy composite recovery points across Regions/accounts (where supported).
Use backup vaults for organization, access control, and immutability.
Child recovery points for persistent storage support lifecycle transitions to cold storage.

Limits to know:

Persistent volumes using CSI migration, in-tree storage plugins, or ACK controllers are not supported.
S3 backups: only bucket-level snapshots are supported (no prefix-level backup via CSI mount points).
FSx via CSI driver: not supported.
EKS on AWS Outposts: not supported.
Subject to backup/restore quotas. Check the AWS Backup feature matrix for details.

Best practices:

Set EKS authorization mode to API or API_AND_CONFIG_MAP.
Use managed policies:
- AWSBackupServiceRolePolicyForBackup
- AWSBackupServiceRolePolicyForRestores
- If S3 is involved: AWSBackupServiceRolePolicyForS3Backup
Choose the right KMS key per backup vault and confirm encryption behavior for each storage type.
Prefer backup plans (scheduled, policy-driven) over ad-hoc jobs.
Test restores often (including restoring into a new cluster).
Continue GitOps for config management—backups are your safety net, not a replacement.

Quick-start checklist:

Opt in to EKS in AWS Backup Settings.
Attach the correct IAM policies to your backup/restore role.
Confirm EKS auth mode is API or API_AND_CONFIG_MAP.
Create an on-demand backup to validate end-to-end.
Set a backup plan (e.g., every 6 hours, retain 30 days).
[✔️] Test a full-cluster restore and a namespace-only restore.
[✔️] Review costs and lifecycle/cold storage options.

Costs

Expect charges for snapshots, storage, cross-Region/account copies, and retention. Persistent data size (EBS/EFS/S3) and frequency drive most costs.

Final thoughts

This feature turns EKS backup from homegrown scripts into managed reliability. With composite recovery points, clear policies, and flexible restore targets, teams get predictable protection with less operational effort. For production EKS, it’s a practical way to reduce risk during upgrades, incidents, and day‑to‑day changes.