Add copySnapshotToRegion VolumeSnapshotClass parameter (EC2 CopySnapshot)

[kalirajanselvaraja]

Is your feature request related to a problem? Please describe.

We use Kubernetes VolumeSnapshot with the AWS EBS CSI Driver and need an opt-in way to automatically create a cross-region copy of each EBS snapshot for disaster recovery / regional redundancy. Today the driver can create a snapshot in the controller’s region, but there is no built-in option to copy that snapshot to another region as part of the snapshot workflow.

---

Describe the solution you'd like in detail

Add support for cross-region snapshot copy configured via VolumeSnapshotClass.parameters (same pattern as existing snapshot features).

Proposed parameters:

• copySnapshotToRegion: destination AWS region (e.g. us-west-2). If unset/empty, behavior is unchanged.
• Optional:
  • copySnapshotEncrypted: true|false to request an encrypted destination copy.
  • copySnapshotDestinationKmsKeyId: destination-region KMS key ID/ARN to use when encrypting the copy.

Example:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc-dr
driver: ebs.csi.aws.com
deletionPolicy: Delete
parameters:
  copySnapshotToRegion: "us-west-2"

Optional parameters (encrypted destination copy and KMS in the destination region):

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc-dr-encrypted
driver: ebs.csi.aws.com
deletionPolicy: Delete
parameters:
  copySnapshotToRegion: "us-west-2"
  copySnapshotEncrypted: "true"
  copySnapshotDestinationKmsKeyId: "arn:aws:kms:us-west-2:111122223333:key/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Using a KMS key UUID instead of ARN:

parameters:
  copySnapshotToRegion: "us-west-2"
  copySnapshotEncrypted: "true"
  copySnapshotDestinationKmsKeyId: "12345678-1234-1234-1234-123456789012"

Encrypted copy without an explicit destination key (when account/AWS defaults allow):

parameters:
  copySnapshotToRegion: "ap-southeast-2"
  copySnapshotEncrypted: "true"

Explicitly unencrypted destination copy (only when appropriate for your case):

parameters:
  copySnapshotToRegion: "eu-west-1"
  copySnapshotEncrypted: "false"

Notes:

• Replace regions, account IDs, and KMS key IDs/ARNs with your own values.
• Quote "true" and "false" so Kubernetes passes them as strings to the CSI driver.
• The KMS key policy in the destination region must allow the IAM principal used by the EBS CSI controller.
• Encrypted cross-region copies often need an explicit destination CMK; if copy fails with only copySnapshotEncrypted: "true", add copySnapshotDestinationKmsKeyId.

Expected behavior / acceptance criteria:

• If copySnapshotToRegion is not set: no behavior change compared to today.
• If copySnapshotToRegion is set:
  • Driver creates the source snapshot normally.
  • After the source snapshot is ready, driver triggers EC2 CopySnapshot into the requested destination region.
  • If copySnapshotToRegion equals the driver/controller region: fail with InvalidArgument.
• Copy should be idempotent on retries (avoid creating multiple destination copies for the same source snapshot).
• Document IAM requirements (at minimum ec2:CopySnapshot; possibly tagging permissions depending on how results are recorded).

---

Describe alternatives you've considered

• External automation (Lambda / EventBridge / scripts) that watches for snapshots and performs cross-region copy. This adds operational complexity and is not directly tied to the CSI snapshot lifecycle and configuration.
• Maintaining separate workflows per team/namespace instead of a CSI driver-supported parameter.

---

Additional context
This should follow the existing model of snapshot configuration via VolumeSnapshotClass.parameters (similar to snapshot tagging, Fast Snapshot Restore, and snapshot lock).

[mdzraf]

Hi @kalirajanselvaraja , thank you for this feature request. Currently, volume snapshots in the CSI spec / Kubernetes lack any topology information, which is a prerequisite for topology-aware scheduling and features such as snapshot copying. We have previously discussed snapshot copying with sig-storage and currently have a Kubernetes Enhancement Proposal (KEP) under review that proposes adding topology support to volume snapshots in Kubernetes. Until this KEP is implemented, we will not be able to propose adding snapshot copying to CSI/Kubernetes, and therefore cannot yet support it in the CSI Driver. We'll keep this issue open to give any updates once we have completed all of the necessary CSI/Kubernetes changes that will allow us to support snapshot copying.

/kind feature

[ConnorJC3]

/lifecycle frozen

We intend to support this eventually, but as mentioned above this is not currently possible in Kubernetes/CSI and we are engaging with SIG Storage and the rest of the upstream community on KEPs to introduce the feature to Kubernetes. Pre-emptively freezing this issue as that will take time.