# aws-ebs-csi-driver: how Amazon EBS volumes reach Kubernetes > The CSI driver that lets a Kubernetes cluster create, snapshot, resize and modify EBS volumes, with static and dynamic provisioning, raw block support and node-local volumes. What it gives you is the plumbing; what it costs is a monthly release cadence that bumps the minor version whether or not anything user-visible changed, and a support window of two versions. **kubernetes-sigs/aws-ebs-csi-driver** — CSI driver for Amazon EBS https://aws.amazon.com/ebs/ - Repository: https://github.com/kubernetes-sigs/aws-ebs-csi-driver - Stars: 1,136 · Forks: 867 - Language: Go - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/kubernetes-sigs-aws-ebs-csi-driver ## What the driver actually provides The Amazon Elastic Block Store Container Storage Interface driver provides a CSI interface used by container orchestrators to manage the lifecycle of Amazon EBS volumes and snapshots. In Kubernetes terms it is the component that makes a PersistentVolumeClaim turn into an actual EBS volume. The feature list covers the storage lifecycle in full. Static provisioning associates an externally created EBS volume with a PersistentVolume for consumption within Kubernetes. Dynamic provisioning automatically creates EBS volumes and the associated PersistentVolumes from PersistentVolumeClaims, with parameters passed through a StorageClass for fine-grained control over volume creation. Mount options can be specified in the PersistentVolume resource to define how the volume is mounted. A volume can be consumed as a raw block device rather than as a filesystem. Volume snapshots can be created and restored from within Kubernetes. Volume resizing expands a volume by specifying a new size in the PersistentVolumeClaim. Two of the entries are newer than the core set and are worth calling out. Volume modification changes the properties of a volume, meaning its type, its IOPS or its throughput, through a `VolumeAttributesClass`, and the README points to an example directory for it. Node-local volumes mount pre-attached, node-specific EBS volumes using a single cluster-wide PersistentVolume and PersistentVolumeClaim, which is the shape you want for a node-local caching scenario where the data must not leave the node it was created on. The primary language is Go, the licence is Apache-2.0, and the project lives under the kubernetes-sigs organisation rather than under AWS, which matters because the release policy and the compatibility statement are Kubernetes SIG storage policies. ## Images and charts, and the naming convention between them The container images are published in two registries and the README tabulates them by driver version. For v1.67.0 the image is `registry.k8s.io/provider-aws/aws-ebs-csi-driver:v1.67.0` in the registry.k8s.io registry and `public.ecr.aws/ebs-csi-driver/aws-ebs-csi-driver:v1.67.0` in ECR Public, and the previous row shows the same pair for v1.66.1. The Helm chart follows the same two-registry pattern with a different version number. The chart version 2.67.0 is published as `registry.k8s.io/provider-aws/charts/aws-ebs-csi-driver:2.67.0` and as `public.ecr.aws/ebs-csi-driver/charts/aws-ebs-csi-driver:2.67.0`. The chart is also published through the GitHub Pages Helm repository and as an OCI artifact in both public registries. The relationship between the two numbers is worth noting. The driver version 1.67.0 and the chart version 2.67.0 share the minor number, which is how the release process keeps a chart and the driver it deploys in step, while allowing the chart to have its own major version for chart-level breaking changes. The recent release list shows both moving together. v1.67.0 was published on 2026-10-12, the helm chart aws-ebs-csi-driver-2.67.0 on the same day shortly before it, and v1.66.1 on 2026-10-08. The last push came on 2026-10-16, four days after the release. ## The release policy bumps the minor version every month The Releases section states the policy, and it has one clause that changes how you plan upgrades. The EBS CSI Driver publishes monthly releases, and unscheduled releases may be published for patches to security vulnerabilities and other fixes deemed urgent. The project follows semantic versioning: significant breaking changes as a MAJOR update, new features as a MINOR update, and bug or vulnerability fixes as a PATCH update. Then the clause that matters: monthly releases will contain at minimum a MINOR version bump, even if the content would normally be treated as a PATCH version. That is a deliberate design choice with a clear rationale. Because the driver is deployed as a set of DaemonSets and Deployments that talk to the node and to the Kubernetes API, a version skew between components is a real failure mode. Forcing the minor version forward every month means that a version number always identifies a specific month's state, and a cluster that skipped a month is unambiguously out of date rather than ambiguously a patch behind. The cost is that version numbers cannot be used to judge the size of a change. A minor bump does not imply a new feature, and the release notes have to be read every time. The Support section is short and equally concrete. Support is provided for the latest version and one prior version, and bugs or vulnerabilities found in the latest version are backported to the previous release in a new minor version. The README is careful to say this policy is non-binding and subject to change. ## Compatibility is with Kubernetes, not with a version of the driver The Compatibility section makes two statements, and the first is broader than most people expect. The EBS CSI Driver is compatible with all Kubernetes versions supported by the Kubernetes project and/or Amazon EKS, including extended support versions. So the driver is not tied to a narrow window of Kubernetes releases, and it keeps working on a cluster that is on an EKS extended support version rather than a standard one. The second statement is about the interface itself. The driver implements the Container Storage Interface specification version `v1.9.0`. That number is worth a moment's attention, because it is not the same as the `container-storage-interface/spec` module version in the dependency list, which is v1.13.0. The spec repository is versioned as a library, and the CSI protocol version the driver implements is a separate, slower-moving number that the driver declares. A driver implementing an older protocol version than the newest library is normal, because the protocol changes rarely and the library changes often. The dependency list backs up the compatibility story. The Kubernetes libraries are all at v0.37.1, including `k8s.io/api`, `apimachinery`, `client-go`, `component-base` and `mount-utils`. The AWS side uses the v2 SDK with `aws-sdk-go-v2` at v1.47.3, the config module, the EC2 service client at v1.338.4, the STS service client, the IMDS feature module, and the Smithy runtime. There is also `github.com/awslabs/volume-modifier-for-k8s` at v0.9.6, which is the volume modification feature, and `kubernetes-csi/csi-test/v5` at v5.6.0, the conformance test suite. ## The build targets specific OS versions, and FIPS matters The Dockerfile is more interesting than a Dockerfile usually is, because the driver is built for several platforms and because of the FIPS handling. The builder stage uses the golang 1.27.2 image from the public ECR docker library, pinned by digest, with the build platform set explicitly, and the module cache and build cache mounted as cache mounts so the dependency download is reused between builds. The build itself runs with `GOFIPS140=certified` set as an environment variable, and the Makefile is invoked with the target OS and architecture passed through. The runtime images are pinned by digest too. There is an AL2023 stage based on the EKS distro build tooling, which copies the driver binary to `/bin/aws-ebs-csi-driver` and sets `GODEBUG=fips140=off` before the entrypoint. There is a Windows stage based on the EKS distro Windows base for ltsc2019, which copies the `.exe` and sets a PATH entry. The `GODEBUG=fips140=off` line is the detail that would puzzle a reader who did not know about FIPS modes in Go: the binary is built in the certified FIPS mode, and the runtime flag switches FIPS mode off again when the container runs. The Makefile shows the platform matrix explicitly. The default version variable is `v1.67.0`, and the linker flags inject the version, the git commit and the build date into the driver and cloud packages, with `-s -w` stripping the symbol table and debug information. The binary name switches on the host OS, and the OS version default is `ltsc2022` on Windows and `al2023` elsewhere. The release matrix is broader than the defaults. For Linux the architectures are amd64 and arm64 with the al2023 OS version, and for Windows the architecture is amd64 with the OS versions ltsc2019, ltsc2022 and ltsc2025. ## Observability, and the dependencies that show it The dependency list reads like an inventory of what a CSI driver has to talk to, and two groups in it are worth pulling out. The first is observability. `prometheus/client_golang` at v1.25.0 and `prometheus/common` at v0.72.1 are direct dependencies, so the driver exports Prometheus metrics. The OpenTelemetry group is larger: the API, the OTLP trace exporter, its gRPC transport, the SDK itself at v1.47.0, and `otelgrpc` for instrumenting the gRPC calls. A CSI driver is a long-lived process that talks to the node, to the cloud API and to the Kubernetes API, and a driver that cannot tell you why a mount failed is a driver you will debug with print statements. The second group is the Kubernetes and CSI plumbing. `kubernetes-csi/csi-lib-utils` at v0.25.0 provides the service and identity helpers, `csi-proxy/client` and `csi-proxy/v2` provide the node-side proxy that the driver uses to reach the kubelet for mount operations, and `container-storage-interface/spec` at v1.13.0 provides the generated gRPC types. The AWS side is a v2 SDK, and the EC2 service client at v1.338.4 is the one that matters, since almost every CSI operation is an EC2 call: create a volume, attach it to an instance, create a snapshot, describe volumes, modify a volume. The `service/sagemaker` dependency is a surprise in a storage driver, and the README does not explain it. For the rest of the behaviour, the README points to the documentation set: driver installation, driver launch options, StorageClass parameters, node-local volumes, a FAQ, volume tagging, volume modification, the Kubernetes examples directory, driver uninstallation and the contributing guide. ## Where the EBS CSI driver is the wrong choice The first wrong case is a cluster that is not on AWS. This driver is specific to Amazon EBS. A team on GKE, AKS or a self-managed cluster on other storage has no use for it, and the equivalent drivers for other clouds follow the same CSI shape but are separate projects. The second is a team that has not migrated from the in-tree EBS plugin. Kubernetes used to ship an in-tree EBS provisioner, and moving to the CSI driver is a migration with real operational steps, including the controller and the node plugin, the StorageClass parameters changing shape, and the existing PersistentVolumes having to be handled. The README does not walk through that migration, and the install document is about fresh installation. The third is a team that wants a long support window. Two versions of support means a cluster has to be upgraded roughly monthly to stay inside the policy, and an organisation that upgrades quarterly is permanently one release behind on patches. The fourth is a workload that assumes snapshot performance or cost behaves like a block device. The driver exposes EBS snapshots through the Kubernetes API, and EBS is a network-attached block device with snapshot semantics of its own, so a database expecting local snapshot semantics has to be tested against the real thing. The fifth is a team that wants the driver to be feature-complete for every storage class option, and finds that some are gated behind a `VolumeAttributesClass` and an example rather than a first-class documented flow. What the driver gives you in exchange is the boring, important thing: a maintained path from a PersistentVolumeClaim to an EBS volume, with the release rhythm and the compatibility statement written down in advance, which is more than most storage integrations offer. ## Conclusion aws-ebs-csi-driver fits a team running Kubernetes on AWS that wants EBS volumes managed through PersistentVolumeClaims with the upstream CSI driver rather than a cloud-specific in-tree plugin, and that is prepared to follow a monthly upgrade rhythm. It does not fit a cluster outside AWS, since it is specific to Amazon EBS, and it does not fit a team that wants a long support window, because the policy covers only the latest version and one prior. Before adopting it, read `docs/install.md` and `docs/parameters.md` for the installation and the StorageClass parameters, and note that a monthly release always contains at least a minor version bump, so your Helm chart version and your driver version will move every month whether or not you want them to. ## FAQ ### How often is the aws-ebs-csi-driver released? Monthly. The README says the driver publishes monthly releases, with unscheduled releases possible for security patches and other urgent fixes, and that a monthly release contains at minimum a MINOR version bump even if the content would normally be a PATCH. ### Which versions of the EBS CSI driver are supported? The latest version and one prior version. Bugs or vulnerabilities found in the latest version are backported to the previous release in a new minor version, and the README notes the policy is non-binding and subject to change. ### Which CSI specification version does the driver implement? Version `v1.9.0` of the Container Storage Interface specification, as stated in the Compatibility section of the README. ### Where are the driver images and Helm charts published? The images are in registry.k8s.io as `provider-aws/aws-ebs-csi-driver` and in ECR Public as `ebs-csi-driver/aws-ebs-csi-driver`. The chart is in registry.k8s.io as `provider-aws/charts/aws-ebs-csi-driver` and in ECR Public as `ebs-csi-driver/charts/aws-ebs-csi-driver`, and also through the GitHub Pages Helm repository. ### What can the EBS CSI driver do with a volume beyond creating it? It can snapshot and restore volumes, expand a volume through the PersistentVolumeClaim, modify its type, IOPS or throughput through a `VolumeAttributesClass`, mount a volume as a raw block device, and mount pre-attached node-local volumes through a single cluster-wide PersistentVolume and PersistentVolumeClaim. ## Sources - [Issues](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues) - [kubernetes-sigs/aws-ebs-csi-driver on GitHub](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) - [License: Apache-2.0](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/LICENSE) - [README](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/README.md) - [Releases](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubernetes-sigs-aws-ebs-csi-driver