Skip to content
Kubernetes deployments are growing rapidly, but disaster recovery remains a challenge. Organizations need solutions that are simple to manage while also integrating seamlessly with the underlying complexity of AWS EKS, a highly dynamic Kubernetes service.
In this guide, we’ll walk through how to configure cross-region and cross-account disaster recovery for AWS EKS using N2W. You’ll learn how to replicate backups across AWS accounts and regions, centralize disaster recovery management, and build flexible recovery strategies that help ensure your Kubernetes applications can be restored quickly and efficiently when needed.
Before diving in, make sure you’re running N2W v4.6 along with the associated patch v4.6.1. These releases introduced native support for AWS EKS Disaster Recovery. If you haven’t upgraded yet, check out:
What N2W backs up and restores for EKS
N2W gives you comprehensive coverage across your EKS environment, including allowing customers to streamline backup for:
- EKS clusters
- Namespaces
- Cluster-scoped resources
- Persistent volumes
When it comes time to restore, N2W provides multiple flexible options:
- recovery to the same cluster or a different EKS cluster
- disaster rollback and cross-cluster migration in a single workflow
- restore to the same account or a different one
- target the same region or switch to another
- choose to restore specific namespaces
For more information on EKS backup and recovery, see our EKS User Guide
Configuring Cross-Region and Cross-Account Disaster Recovery for EKS
Before setting up cross-region or cross-account EKS disaster recovery in N2W, there are a few prerequisites and configurations to take care of, both on the N2W side and in AWS.
The first thing you’ll need is Velero, which handles the heavy lifting for EKS backups and restores. Follow this guide to install Velero on your EKS cluster before proceeding.
Choosing your EKS backup mode
N2W offers two backup modes for EKS DR:
- Standard EBS when you want to do local backups from the same account, for example
- Portable (Kopia) which is the mode for disaster recovery scenarios
To select your preferred mode, navigate to the policy, click the policy name, then go to the Options page. You’ll find the EKS Backup Mode selector at the bottom of the screen.
💡 Heads up: If you see policies.form.eks.backup instead of readable labels, or the Kopia option isn’t showing up, do a hard refresh in Chrome by pressing Shift + F5.
Below is the console before your cache is cleared.
Once the old cookies are cleared, the display names should update correctly. You’ll now see the EKS Backup Mode selector with two options:
Select Portable (Kopia) and navigate to the DR tab.
As an example, here’s how to configure a cross-region DR setup: set your source region (Frankfurt, in this case) and your destination region (Ireland), then click Save.
On the left tab click on EKS DR Configurations.
The console will prompt you to complete a few fields:
- Choose the relevant user
- Under Backup Bucket, select the source account
- Select the source region (Frankfurt) and the destination bucket
For your DR bucket:
- Select your DR account and region (in this case Ireland).
📋 Prerequisite: This step requires an S3 bucket already set up in your DR region. If you haven’t created one yet, it won’t appear in the list, so let’s take care of that first before continuing with the N2W setup.
Head over to the AWS Console, navigate to the S3 dashboard, and click Create Bucket.
Make sure the correct region is selected, then click Create Bucket. Give your bucket a unique name and if you want to save some time, you can copy the configuration from an existing bucket rather than setting everything up from scratch.
Now that you have S3 buckets set up in both Frankfurt and Ireland, head back to N2W and refresh the page. Ireland will now appear as an available DR destination region, along with the bucket you just created. Select your region and bucket, then save the configuration.
Additional Configuration for Cross Account Disaster Recovery
💡 If you are implementing cross-account EKS DR, you’ll need to create a separate EKS DR configuration – one pointing to the same account and region (Frankfurt) for the source, and another pointing to the destination account and its corresponding bucket.
If you haven’t set up a DR account in N2W yet, you’ll need to create one and add it in the N2W console before proceeding.
Returning to our cross-region DR walkthrough – head back to N2W and your destination region should now be visible and ready to select.
Head to the Backup Monitor to run the policy. One thing worth noting: when using Portable (Kopia) mode, backups will take slightly longer than usual, though still just a few minutes. This is because Kopia completes the backup in your local region (Frankfurt, in this case) before transferring it to the S3 bucket.
🔧 Troubleshooting: If your EKS cluster backup fails, the first place to check is the Backup Log. You might see is a Velero cluster partial failure and the log will point you to exactly where things went wrong.
In this case, the daemon set pod not found in running state and permissions should be modified to be the IAM rule used by the Velero server IRSA.
Head to the AWS console to modify your permissions. See our user guide for common troubleshooting issues and required IAM permissions.
Restoring your EKS cluster
Before starting your recovery, make sure Velero is installed on both the source and destination EKS clusters.
When you’re ready, head to the Recover screen in the Backup Monitor. Select your target account, region, and cluster, then choose your DR bucket as the recovery source and kick off the recovery.
N2W gives you full flexibility at restore time. You can recover all namespaces, persistent volumes, and cluster-scoped resources, or narrow it down to just the specific namespaces you need. The example below walks through how to select the namespaces you want to recover.
How to get started using N2W for EKS backup and disaster recovery
You can trial N2W for free and implement one-click, policy-driven backup and recovery for AWS EKS, seeing how it fully integrates into the same console used for all of your other cloud resources without relying on complex siloed platforms and procedures.