Managed Kubernetes Services: Could You Restore the Cluster?

Managed Kubernetes services run your control plane. They do not keep a copy of your cluster. Those are two different sentences, and the gap between them is where a bad Tuesday afternoon lives: somebody deletes the wrong namespace, an operator reconciles a custom resource into nothing, a Helm upgrade removes a volume claim it made.

There has been a first-party answer on AWS since November 2025, and in the clusters we inherit it is almost never switched on. Partly because it arrived quietly.

Our position: the backup is not the deliverable. A timed restore of one namespace into a cluster that is not production is, and until somebody has done that you do not have a recovery plan. You have a backup job.

What do managed Kubernetes services actually back up?

Nothing, until you ask. AWS's half of EKS is the API server and etcd, and it runs them well, but durability of the control plane is not a copy of your cluster. etcd surviving in three availability zones is no help when what went wrong was a kubectl delete ns typed by somebody holding an access entry nobody has reviewed since 2024.

We went through what the word managed does and does not cover in the post on what is still yours on EKS: the version, the nodes, the audit log, the endpoint. Recovery is the item people discover during the incident rather than before it.

Why is there no etcd snapshot to ask for?

Because you have no shell on the machine holding it. On a cluster you run yourself, the disaster recovery plan is a line in a cron job: etcdctl snapshot save. On EKS that command has nowhere to run, no API returns the equivalent, and support will not send you one.

So the backup has to be taken from outside, through the Kubernetes API, as objects. Which explains the prerequisite that stops most teams at step one. AWS's EKS page requires the cluster authorization mode to be "set to API or API_AND_CONFIG_MAP for AWS Backup to create Access Entries to access the EKS cluster". A cluster on CONFIG_MAP alone is not eligible.

Switching is a one-way door, worth knowing before you do it to production. The access entries page is blunt: "you can't change the authentication mode back to a mode that removes the EKS API and access entries." API_AND_CONFIG_MAP keeps the old aws-auth path working beside the new one, so it is the safer of the two for a cluster whose RBAC nobody fully understands.

What does an EKS backup actually contain?

More than we expected. AWS Backup's EKS documentation describes a composite recovery point: one child for the cluster state, one more for each persistent volume. Cluster state is "the Kubernetes manifests (YAML or JSON files) that define the desired state of Kubernetes resources in your cluster", and the FAQ lists what travels with it: "cluster name, IAM role, Amazon VPC configuration, network settings, logging, encryption, add-ons, access entries, managed node groups, Fargate profiles, pod identity associations, and Kubernetes manifest files".

Volumes come too, when they arrived through a persistent volume claim and a supported CSI driver: EBS, EFS and S3. It shipped on 10 November 2025 and needs no agent in the cluster.

Two properties to plan around. Volume children are incremental where the storage type supports it; the cluster state child is a full backup every time. And since 12 March 2026 the vault can be a logically air-gapped one, holding "immutable backup copies that are locked by default". If you need to show that a backup cannot be deleted by whoever deleted the cluster, that is the answer.

What is not in the backup, and who rebuilds it?

The account around the cluster. AWS lists the exclusions plainly: "Container images from external repositories (ECR, Docker)", "EKS cluster infrastructure components (e.g. VPCs, Subnets)", and "Auto-generated EKS resources like nodes, auto-generated pods, events, leases, and jobs".

Read that as the dependency list for your restore. The VPC, the subnets, the security groups, the registry holding your images and the KMS key all have to exist in the target account and region first. If the plan is a second region, that landing zone is Terraform somebody has to have written and run, which is the argument in the post on what has to exist before a cutover.

The limitations list is where a backup you believed in covers less than you think. Volumes "using a CSI Driver via CSI migration, in-tree storage plugins or ACK controllers are not supported", which quietly excludes much of what was provisioned before you moved to the CSI drivers. FSx is out. So are EFS volumes with non-root subpath mounts, and S3 buckets mounted at a prefix rather than whole.

A composite whose children failed comes back Partial or Completed with issues, never failed. Subscribe to the notifications.

Will the restore work in another account or region?

Not without work that belongs before the drill. Three traps, all documented.

IRSA first. The restore page says objects referencing IAM Roles for Service Accounts "retain the source cluster's OIDC provider endpoint", and that "AWS Backup does not automatically update them during restore". The destination cluster needs its own OIDC provider and every trust policy needs the new endpoint, or your pods start and fail to assume anything. AWS recommends EKS Pod Identity instead, which "does not depend on cluster-specific OIDC providers".

Storage classes are the second: "ensure that the appropriate CSI Storage Driver add-ons are installed prior to restore". A bare scratch cluster has no EBS CSI driver, so the manifests land and the volumes do not.

The third would have cost us an afternoon. Under EKS Auto Mode, Auto Mode "only attaches an Amazon EBS volume whose eks:eks-cluster-name tag matches the cluster's name", AWS Backup does not update that tag on restored volumes, and the job reports success while pods sit in ContainerCreating with FailedAttachVolume. One command per volume:

aws ec2 create-tags --resources vol-123456abcdef \
  --tags Key=eks:eks-cluster-name,Value=destination-cluster-name

One more property to design around. Every EKS restore is non-destructive: "existing objects are never overwritten or deleted". So this is a recovery tool, not a rollback tool. If a bad Helm release mangled a Deployment that still exists, the restore skips it and reports success. Undoing a change stays the pipeline's job, which is where production changes should arrive from anyway.

What does the RBI ask of a backup nobody has restored?

That you restore it. The Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 say at paragraph 133 that the NBFC "shall backup data and periodically restore such backed-up data to check its usability", and that "the integrity of such backup data shall be preserved along with securing it from unauthorised access". Paragraph 8(9) asks even the smallest entities for an "arrangement for backup of data with periodic testing".

Then the drill. Paragraph 129 puts drills for critical information systems "at least on a half-yearly basis", and paragraph 131 wants the test to switch to the alternate site for "at least a full working day (including Beginning of Day to End of Day operations)". A namespace restore into a scratch cluster is not that drill. It is the smallest piece of it you can finish this week, and reliably the piece that fails first. The rest is in the post on the 2026 directions.

What can you run on Monday?

An hour, and nothing in production changes. Find out which clusters are even eligible:

for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  aws eks describe-cluster --name "$c" \
    --query 'cluster.[name,accessConfig.authenticationMode]' --output text
done

Anything printing CONFIG_MAP cannot be backed up until you move it, through the one-way door above. Then take one backup by hand:

aws backup start-backup-job --region ap-south-1 \
  --backup-vault-name Default \
  --resource-arn arn:aws:eks:ap-south-1:111122223333:cluster/payments-prod \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole

Then the point. Build a small cluster that is not production, install the EBS CSI driver add-on, and restore one namespace:

aws backup start-restore-job --resource-type EKS \
  --recovery-point-arn <composite-recovery-point-arn> \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole \
  --metadata '{"clusterName":"restore-drill","newCluster":"false",
    "namespaceLevelRestore":"true","namespaces":"[\"payments\"]"}'

Five namespaces is the ceiling per job, and cluster-scoped resources come along whether you asked or not. Time it from the API call to a pod serving traffic, then put that number beside the recovery time somebody has already promised an auditor. The first time we ran this, the two were not close.

When is rebuilding from code the honest answer?

More often than a backup product will admit. If every manifest is in a repository, Argo CD or Flux owns the cluster, and the only real state lives in RDS, then your recovery plan is an apply and a resync. That is better evidence than a restore, because it is the path every deploy already takes. Bolting a backup onto it is ceremony and one more IAM role to review.

The case flips the moment state creeps in. A secret created by hand during an incident. A custom resource holding an operator's accumulated state. A namespace whose manifests left with a contractor, the ownership question in the post on what you own when they leave. None of those come back from code.

The short version

Run the loop and find the clusters still on CONFIG_MAP. Move the non-production ones this week and schedule production. Then put one cluster in a backup plan, with a copy into a vault in a second account.

Book two hours and restore one namespace into a cluster that is not production, with the CSI driver add-on installed first. Write down how long it took.

Then read the exclusions back. The VPC, the subnets, the security groups, the images and the IRSA trust policies are not in that recovery point, so the recovery plan is the Terraform that builds them plus the restore, never the restore alone. Whoever runs the cluster should be able to name the date of the last timed restore. If the answer is that backups are enabled, that is the finding.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.