<p>I'm aware of the concept &quot;provisioner&quot; but i do not understand what intree ebs driver means.
Is ebs.csi.aws.com the csi driver maintained by the aws and the other maintained by k8s itself?
Is one better than the other?</p>

<p>As per <a href="https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi" rel="noreferrer">the official documentation</a>:</p>
<blockquote>
<p>Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.</p>
</blockquote>
<blockquote>
<p>As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.</p>
</blockquote>
<p>So answering your question - yes, ebs.csi.aws.com is maintained by AWS while the in-tree plugin is maintained by Kubernetes but it seems like they've stopped implementing new features as per <a href="https://grepmymind.com/its-all-about-the-data-a-journey-into-kubernetes-csi-on-aws-f2b998676ce9" rel="noreferrer">this article</a>:</p>
<blockquote>
<p>The idea of this journey started picking up steam when I realized that the in-tree storage plugins were deprecated and no new enhancements were being made to them starting with Kubernetes 1.20. When I discovered that simply switching from gp2 to gp3 volumes meant I had to start using the AWS CSI Driver I realized I was behind the times.</p>
</blockquote>
<p>Answering your last question it's probably better to use ebs.csi.aws.com as per <a href="https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-ebs-container-storage-interface-driver-is-now-generally-available/" rel="noreferrer">this note</a>:</p>
<blockquote>
<p>The existing in-tree EBS plugin is still supported, but by using a CSI
driver, you benefit from the decoupling between the Kubernetes
upstream release cycle and the CSI driver release cycle.</p>
</blockquote>
