EKS Disaster Recovery, Simplified: Native Backups with AWS Backup
Published: (December 21, 2025 at 04:53 PM EST)
4 min read
Source: Dev.to
Source: Dev.to
The Turning Point – November 10 2025
Last month AWS finally closed a long‑standing gap by adding native Amazon EKS support to AWS Backup.
This isn’t a minor feature drop; it’s a real shift from DIY backup engineering to managed reliability.
Why This Matters
| Old Way | New Way |
|---|---|
| Fragmented recovery points – cluster config, EBS snapshots, and S3 objects lived in separate places. | Composite Recovery Points – AWS Backup captures cluster state plus persistent storage (EBS, EFS, S3) in a single, consistent snapshot. |
| Multiple tools – Velero, custom scripts, manually‑managed S3 buckets, and endless anxiety. | One pane of glass – EKS backups live in the same AWS Backup console you already use for EC2, RDS, DynamoDB, etc. No extra controllers or per‑cluster Velero agents. |
| Script‑driven schedules – CronJobs inside clusters. | Policy‑driven schedules – Define a Backup Plan (e.g., “Back up every 6 hours, retain for 30 days”). AWS handles scheduling, encryption, immutability, and lifecycle automatically. |
| Stressful restores – manual, error‑prone, often a gamble. | Stress‑free restores – Restore an entire cluster, a single namespace, individual PVs, or even a brand‑new EKS cluster as part of the restore workflow. |
Operational Benefits Right Now
- Cluster upgrades (e.g., 1.30 → 1.31) without fear of data loss.
- AMI roll‑outs that don’t go as planned.
- Security‑patch applications with a safety net.
- Kubernetes API changes that could break workloads.
If you run production EKS, this feature quietly changes how you sleep at night. AWS didn’t just add a backup option; they removed an entire category of operational stress.
Practical Guide: Enabling Native EKS Backups with AWS Backup
1. Add EKS as a Protected Resource
- Open the AWS Backup console.
- Choose Settings → Configure resource.
- Select Amazon EKS and enable it.
2. Create an On‑Demand Backup
- In the Protected resources view, click Create on‑demand backup.
3. Set Up a Backup Role
Create a custom IAM role (e.g., EKS-BACKUP-ROLE-EXAMPLE) and attach the following managed policies:
AWSBackupServiceRolePolicyForBackupAWSBackupServiceRolePolicyForRestores
4. Verify the Backup Progress
After starting the on‑demand backup, you’ll see its status change to In progress.
5. Confirm Completion
You can verify that the backup completed either from the AWS Backup console or directly on the EKS console.
TL;DR
- AWS Backup now natively supports Amazon EKS – one‑click, policy‑driven protection for both control‑plane state and persistent storage.
- Composite recovery points eliminate fragmented snapshots.
- Unified console gives you a single pane of glass for all your workloads.
- Set‑and‑forget backup plans replace fragile CronJobs and custom scripts.
- Restores are reliable – whole‑cluster, namespace‑level, or PV‑level, even into a brand‑new cluster.
Enable it today and turn disaster‑recovery from a nightmare into a managed service.
That is how to back up; now moving to the **Restore process**.
### Initiating a Restore
1. Open **AWS Backup** → **Protected resources**.
2. Click the **Resource ID** of the cluster you want to restore.
3. Choose the **Composite recovery point** you created.
4. Press the **Restore** button.
### Choosing Restore Options
During the restore workflow, AWS Backup presents several recovery options:
- **Restore scope** – entire EKS cluster or a specific namespace.
- **Restore destination** – original source cluster, an existing EKS cluster, or a brand‑new cluster created as part of the restore.
In this walkthrough I restored into a newly created EKS cluster to demonstrate the full capabilities of native EKS recovery and to validate how well the feature supports clean, isolated disaster‑recovery scenarios.
### Selecting Storage Resources
The next step asks you to select the storage resources to include in the restore.
In my case no persistent storage was attached to the workloads, but AWS Backup also supports restoring data backed by **Amazon EBS**, **EFS**, and **S3**, ensuring that application data and cluster state remain consistent.
### Restoration in Progress
Once the restore is initiated, AWS Backup begins recreating the cluster based on the selected recovery options, provisioning a new EKS environment as specified. This doesn’t replace disciplined GitOps workflows or careful upgrade strategies, but it finally gives platform teams a native, reliable safety net. For production EKS environments, that’s a meaningful shift in operational confidence.
Final Thoughts
Native Amazon EKS support in AWS Backup removes much of the complexity that platform teams have traditionally had to manage themselves. It delivers consistent, policy‑driven backups and predictable restores without introducing additional controllers or operational overhead.
Important Considerations
- Not all Kubernetes resources are restored exactly as‑is, particularly external integrations and cloud‑managed services.
- Restore time depends heavily on persistent‑volume size and data footprint.
- Standard AWS Backup costs apply for snapshots, storage, and retention.
- This does not replace GitOps—it complements it by providing a last‑known‑good runtime recovery option.
For teams running production EKS on AWS, this feature doesn’t eliminate the need for good engineering practices, but it significantly reduces the risk and stress associated with cluster‑level failures. That alone makes it a meaningful addition to the EKS operational toolkit.