[アップデート] AWS Backup が EKS クラスターのバックアップをサポートしました

2025.11.13
 概要AWS Backup が EKS をサポートして、下記をバックアップできるようになりました。
Kubernetes リソースの構成 (Deployment などの設定)
Kubernetes が扱う各種ストレージ内のデータ
Amazon EBS
Amazon EFS
Amazon S3

What's New
https://aws.amazon.com/about-aws/whats-new/2025/11/aws-backup-supports-amazon-eks/
AWS ブログ
https://aws.amazon.com/blogs/aws/secure-eks-clusters-with-the-new-support-for-amazon-eks-in-aws-backup/
EKS においてはそもそもバックアップの必要性を感じない人も多いと思いますが、何らかのストレージを扱っている人からするとかなり嬉しいアップデートだと思います。
 EKS のバックアップがどう変わった？Kubernetes で扱うデータと構成をバックアップ可能な AWS サービスはこれまで存在しておらず、Velero のようなサードパーティ製のツールが広く使われていました。
https://velero.io/
Velero も Helm などで簡単にインストールできるとはいえ、サードパーティ製のツールを利用するハードルが高いケースもあると思います。

また、Velero などのサードパーティーツールを利用する場合は基本的に Kubernetes クラスター内へ何らかのコンポーネントをインストールする必要があります。

インストール自体は簡単でもセキュリティパッチ適用などを考えるとそれなりの工数はかかります。

AWS Backup は追加コンポーネント不要で利用でき、この点は大きなメリットです。

一方で、オンプレミスに作成していた Kubernetes クラスターから EKS に移行するようなケースでは今後も Velero の代替にはならないので注意が必要です。
https://aws.amazon.com/jp/blogs/news/backup-and-restore-your-amazon-eks-cluster-resources-using-velero/
※ 正確には PV の実態である EBS 自体のスナップショットを取得しておき、そちらから EBS を復元しつつ PV 作成時に指定することは以前から可能でした。ただ、かなり手間なので一旦この議論からは外します。念の為のバックアップとしては良いと思いますが、こういうケースにこそ今回のアップデートが刺さると思います。
 やってみる実際に EKS クラスターを作成して、バックアップとリストアを試してみます。
 EKS クラスター作成EKS 周りは Terraform で作成します。
VPC
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 6.0.1"

  name = "eks-vpc"

  cidr = "10.0.0.0/16"

  azs             = ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
  public_subnets  = ["10.0.0.0/24", "10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.100.0/24", "10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
  public_subnet_tags = {
    "kubernetes.io/role/elb" = 1
  }

  private_subnet_tags = {
    "kubernetes.io/role/internal-elb" = 1
  }

}
EKS 周り
今回は非 Auto Mode 構成にしました。

PV を作成したいので、EBS CSI driver アドオンを入れておきます。
locals {
  cluster_name = "test-cluster"
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 21.0.4"

  name               = local.cluster_name
  kubernetes_version = "1.33"

  addons = {
    coredns    = {}
    kube-proxy = {}
    vpc-cni = {
      before_compute = true
    }
    eks-pod-identity-agent = {}
    aws-ebs-csi-driver = {
      pod_identity_association = [
        {
          role_arn        = module.aws_ebs_csi_pod_identity.iam_role_arn
          service_account = "ebs-csi-controller-sa"
        }
      ]
    }
  }

  endpoint_public_access  = true
  endpoint_private_access = true
  enable_irsa             = false

  authentication_mode = "API"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  enable_cluster_creator_admin_permissions = true

  eks_managed_node_groups = {
    default = {
      name = "default"

      ami_type       = "AL2023_x86_64_STANDARD"
      instance_types = ["t3.medium"]

      min_size     = 1
      max_size     = 3
      desired_size = 2

      metadata_options = {
        http_tokens                 = "required"
        http_put_response_hop_limit = 2
      }
    }
  }

  tags = {
    backup = "true"
  }
}

module "aws_ebs_csi_pod_identity" {
  source  = "terraform-aws-modules/eks-pod-identity/aws"
  version = "2.2.1"
  name    = "aws-ebs-csi"

  attach_aws_ebs_csi_policy = true
}
 AWS Backup 設定オプトインが必要なので、AWS Backup のサービスページにある「設定」に移動します。
オプトインします。
バックアッププランやバックアップルールは他リソースをバックアップする時と変わらないので、適当に作成します。
リソースの割当てを行います。
権限としては「デフォルトのロール」を選択します。

AWSBackupServiceRolePolicyForBackup を確認した所、下記権限が付与されていました。
{
    "Version": "2012-10-17",
    "Statement": [
    // ============== 省略 ==============
        {
            "Sid": "EKSClusterConfigurationBackup",
            "Effect": "Allow",
            "Action": [
                "eks:ListClusters",
                "eks:ListTagsForResource",
                "eks:DescribeCluster",
                "eks:ListAddons",
                "eks:DescribeAddon",
                "eks:ListNodegroups",
                "eks:DescribeNodegroup",
                "eks:ListPodIdentityAssociations",
                "eks:DescribePodIdentityAssociation",
                "eks:ListAccessEntries",
                "eks:DescribeAccessEntry",
                "eks:ListAssociatedAccessPolicies",
                "eks:ListFargateProfiles",
                "eks:DescribeFargateProfile",
                "ec2:DescribeLaunchTemplateVersions"
            ],
            "Resource": "*"
        },
        {
            "Sid": "CreateBackupAccessEntry",
            "Effect": "Allow",
            "Action": [
                "eks:CreateAccessEntry"
            ],
            "Resource": "arn:aws:eks:*:*:cluster/*"
        },
        {
            "Sid": "AssociateBackupAccessPolicy",
            "Effect": "Allow",
            "Action": [
                "eks:AssociateAccessPolicy",
                "eks:DisassociateAccessPolicy"
            ],
            "Resource": "arn:aws:eks:*:*:access-entry/*",
            "Condition": {
                "StringEquals": {
                    "eks:policyArn": "arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup",
                    "eks:accessScope": "cluster"
                }
            }
        }
    ]
}
権限が付与されていることからもわかるように、AWS Backup から Kubernetes リソースへアクセスする際はアクセスエントリを利用するようです。

また、Mountpoint for Amazon S3 CSI driver を利用している場合は AWSBackupServiceRolePolicyForS3Backup をアタッチしたロールを指定する必要があります。
EKS backup setup and prerequisites ("Before you backup")

EKS Cluster Settings:

・EKS Cluster authorization mode set to API or API_AND_CONFIG_MAP for AWS Backup to create Access Entries to access the EKS cluster.

Permissions:

・AWS Backup's managed policy AWSBackupServiceRolePolicyForBackup contains the required permissions to backup your Amazon EKS cluster and EBS and EFS persistent storage

・If your EKS Cluster contains an S3 bucket you will need to ensure the following policies and prerequisites for your S3 bucket are added and enabled as documented:

・AWSBackupServiceRolePolicyForS3Backup

・Prerequisites for S3 Backups

https://docs.aws.amazon.com/aws-backup/latest/devguide/eks-backups.html#eks-backup-creation
確認のポップアップが出ますが、タグベースで対象を絞っているので「続行」をクリックします。
 Kubernetes リソース続いて Kubernetes リソースを作成していきます。

StorageClass は aws-ebs-csi-driver リポジトリのサンプル を元に明示的に gp3 を指定して作成します。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
  encrypted: "true"
PVC は aws-ebs-csi-driver リポジトリのサンプル をそのまま利用します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 4Gi
Deployment についても aws-ebs-csi-driver リポジトリのサンプル を Deployment 化して利用します。
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
        - name: app
          image: public.ecr.aws/amazonlinux/amazonlinux
          command: ["/bin/sh"]
          args:
            [
              "-c",
              "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done",
            ]
          volumeMounts:
            - name: persistent-storage
              mountPath: /data
      volumes:
        - name: persistent-storage
          persistentVolumeClaim:
            claimName: ebs-claim
Pod
% kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-5769c6887f-mpnxk   1/1     Running   0          14s
PVC
% kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
ebs-claim   Bound    pvc-c1038c8a-bff8-4853-9c69-9ee8b168b0ef   4Gi        RWO            ebs-sc         <unset>                 34s
PV
% kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-c1038c8a-bff8-4853-9c69-9ee8b168b0ef   4Gi        RWO            Delete           Bound    default/ebs-claim   ebs-sc         <unset>                          39s
Pod 内に乗り込んで PV にログを書き出せていることを確認します。
% kubectl exec -it app-5769c6887f-mpnxk -- /bin/bash
bash-5.2# ls /data/out.txt
/data/out.txt
bash-5.2# cat /data/out.txt
Wed Nov 12 12:01:40 UTC 2025
Wed Nov 12 12:01:45 UTC 2025
 リストアリストアする前に、Deployment と PVC を削除しておきます。
% kubectl delete -f deployment.yaml
deployment.apps "app" deleted
% kubectl delete -f pvc.yaml
persistentvolumeclaim "ebs-claim" deleted
どちらも削除されていることを確認できました。
% kubectl get pod
No resources found in default namespace.
% kubectl get pvc
No resources found in default namespace.
AWS Backup でボールトから復旧ポイントを確認できるので、リストアしたい地点を選択して「復元」をクリックします。
「回復設定を構成する」をクリックします。
リストアする対象の名前空間や、リストアの順番などを指定できます。

今回は default 名前空間のみを復元します。
EBS 復元の設定に移ります。

コンフィグレーションが「不完全」と表示されているのでリソース ID をクリックします。
AZ を指定する必要があったので、元々 EBS が存在していた AZ を指定します。

※ ボリュームタイプやサイズはデフォルト設定にしてしまっていますが、元の設定 (gp3、4GiB) に合わせるべきだったと思います。
コンフィグレーションが「完了」になったことを確認して「次へ」をクリックします。
復元ロールはデフォルトのものを選択して「次へ」をクリックします。
確認画面になるので「復元」をクリックします。
9 分で完了しました。
各種 Kubernetes リソースが復元できました。
Pod
% kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-5769c6887f-6wzvt   1/1     Running   0          6m55s
PVC
% kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
ebs-claim   Bound    pvc-c1038c8a-bff8-4853-9c69-9ee8b168b0ef   4Gi        RWO            ebs-sc         <unset>                 7m21s
PV
% kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-c1038c8a-bff8-4853-9c69-9ee8b168b0ef   4Gi        RWO            Delete           Bound    default/ebs-claim   ebs-sc         <unset>                          8m45s
Pod 内に乗り込むと前の Pod で書き込んだログも確認できました。

バックアップ対象である Pod が利用していたボリュームに復元された Pod がログを書き込めていることを確認できました。
bash-5.2# cat /data/out.txt
Wed Nov 12 12:01:40 UTC 2025
Wed Nov 12 12:01:45 UTC 2025
========== 省略 ==========
Wed Nov 12 13:19:59 UTC 2025
Wed Nov 12 13:20:04 UTC 2025
====== 移行が新Podの分 =====
Thu Nov 13 07:45:54 UTC 2025
Thu Nov 13 07:45:59 UTC 2025
Thu Nov 13 07:46:04 UTC 2025
Thu Nov 13 07:46:09 UTC 2025
Thu Nov 13 07:46:14 UTC 2025
Thu Nov 13 07:46:19 UTC 2025
Thu Nov 13 07:46:24 UTC 2025
Thu Nov 13 07:46:29 UTC 2025
Thu Nov 13 07:46:34 UTC 2025
Thu Nov 13 07:46:39 UTC 2025
Thu Nov 13 07:46:44 UTC 2025
Thu Nov 13 07:46:49 UTC 2025
Thu Nov 13 07:46:54 UTC 2025
Thu Nov 13 07:46:59 UTC 2025
Thu Nov 13 07:47:04 UTC 2025
Thu Nov 13 07:47:09 UTC 2025
Thu Nov 13 07:47:14 UTC 2025
Thu Nov 13 07:47:19 UTC 2025
Thu Nov 13 07:47:24 UTC 2025
Thu Nov 13 07:47:29 UTC 2025
Thu Nov 13 07:47:34 UTC 2025
Thu Nov 13 07:47:39 UTC 2025
Thu Nov 13 07:47:44 UTC 2025
Thu Nov 13 07:47:49 UTC 2025
Thu Nov 13 07:47:54 UTC 2025
Thu Nov 13 07:47:59 UTC 2025
Thu Nov 13 07:48:04 UTC 2025
Thu Nov 13 07:48:09 UTC 2025
Thu Nov 13 07:48:14 UTC 2025
Thu Nov 13 07:48:19 UTC 2025
Thu Nov 13 07:48:24 UTC 2025
Thu Nov 13 07:48:29 UTC 2025
 その他 EKS サービスページでの見え方取得したバックアップは EKS のサービスページからも確認可能です。
 Auto Mode への移行に使えるか？バックアップから新規クラスターに復元可能なのでストレージを扱うクラスターで Blue/Green 的に移行できるかなと思ったのですが、そういった使い方は無理そうでした。

ネットワーク設定やバージョンアップなら元クラスターと変更しつつ新規作成可能です。
バックアップ要件が無かったとしても Kubernetes バージョンアップ前に一応オンデマンドバックアップを取得しておくのはアリだなと思いました。
 クロスリージョンバックアップ/クロスアカウントバックアップ最初にオンプレミスからの移行には使えないという話をしましたが、Cross-Region backup や Cross-account backup には対応しているので、リージョン間やアカウント間での移行や複製には利用できそうです。
https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource
 最後にEKS 利用時に etcd のデータが吹き飛ぶケースまで想定している人はほぼいないでしょうし、何らかの理由でストレージを利用していない限りは恩恵は少ないかもしれません。

ただ、AWS サービスで EKS のバックアップできないかを聞かれるケースは何度かあったので、刺さるケースにはとことん刺さるアップデートかなと思いました。

気になる方は是非使ってみて下さい！