Introduction

This message means Kubernetes accepted your PersistentVolumeClaim, but the EBS CSI provisioner never created the backing EBS volume. On a brand-new EKS cluster, the most common reasons are that the EBS CSI driver is not installed correctly, the StorageClass is wrong, or the driver lacks AWS permissions to create volumes.

The key is to debug this as a provisioning chain: PVC, StorageClass, CSI controller, AWS permissions, and scheduling. If any link is missing, the PVC stays in Pending.

What the message actually means

A PVC using ebs.csi.aws.com is asking the EBS CSI driver to provision storage dynamically. When you see:

waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com"

Kubernetes is basically saying:

• the PVC exists
• the StorageClass points at the EBS CSI provisioner
• no actual volume has been created yet

That narrows the problem to the driver, its permissions, or the class and scheduling setup around it.

Verify the EBS CSI driver is installed and running

On a new EKS cluster, this is the first thing to check.

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver
kubectl get csidrivers

You want to see the EBS CSI controller components running and the ebs.csi.aws.com driver registered.

If those pods are missing or failing, the PVC cannot be provisioned. On EKS, make sure the EBS CSI add-on or equivalent driver installation actually completed.

Check the StorageClass

Next, inspect the class the PVC is using:

kubectl get storageclass
kubectl describe storageclass gp3

A typical dynamic EBS StorageClass looks like this:

1apiVersion: storage.k8s.io/v1
2kind: StorageClass
3metadata:
4  name: gp3
5provisioner: ebs.csi.aws.com
6volumeBindingMode: WaitForFirstConsumer
7parameters:
8  type: gp3
9allowVolumeExpansion: true

The important field is the provisioner name. If the class still points at an old provisioner or a typo, no EBS volume will ever be created.

WaitForFirstConsumer is also common on EKS because it lets Kubernetes choose an availability zone that matches where the Pod is scheduled.

Verify AWS permissions for the driver

Even with the driver running, provisioning fails if the CSI controller cannot call EC2 APIs such as volume creation and attachment.

Check the controller logs:

kubectl logs -n kube-system deploy/ebs-csi-controller -c ebs-plugin

If you see authorization failures around volume APIs, the driver identity is missing required permissions.

On EKS, the CSI driver typically needs AWS permissions to perform actions such as:

• creating volumes
• deleting volumes
• attaching volumes
• describing volumes and instances

If the add-on uses an IAM role for the service account or another cluster identity mechanism, confirm that it is correctly attached and trusted.

Check scheduling assumptions

A PVC can also appear stuck because the volume binding depends on where the Pod will run.

Useful checks:

kubectl get pvc
kubectl describe pvc my-claim
kubectl get pods -o wide

If your workload cannot schedule onto a suitable node, volume creation may not progress the way you expect. This is especially relevant when:

• all compute is misconfigured
• the Pod has node constraints that no node satisfies
• the cluster uses storage binding modes that wait for Pod placement

You should also confirm you are using worker nodes appropriate for EBS-backed persistent storage.

A practical troubleshooting order

On a fresh EKS cluster, the fastest order is usually:

1. confirm the EBS CSI driver is installed and healthy
2. confirm the StorageClass uses ebs.csi.aws.com
3. inspect the PVC events with kubectl describe pvc
4. inspect CSI controller logs
5. verify AWS permissions and Pod scheduling

That sequence prevents random guessing and usually surfaces the missing link quickly.

Common Pitfalls

The most common mistake is assuming the presence of a PVC automatically means the cluster has a working CSI driver. On a new EKS cluster, the driver installation is often the missing step.

Another issue is using a StorageClass name that exists but points at the wrong provisioner or outdated storage configuration.

People also miss permission problems. The driver can be running normally while still failing every EC2 call because its AWS identity is incomplete.

Finally, do not debug only the PVC object. The useful evidence is often in the CSI controller logs and the PVC event stream together.

Summary

• This PVC message means the EBS CSI provisioner never created the backing volume.
• First verify that the EBS CSI driver is installed and healthy on the EKS cluster.
• Check that the StorageClass really uses ebs.csi.aws.com.
• Inspect CSI controller logs and AWS permissions if volume creation is still failing.
• Use PVC events and scheduling state together to find where the provisioning chain is blocked.