<p>Observed two kinds of syntaxes for PV &amp; PVC creation in AWS EKS.</p>
<p>1)Using vol Id while creating both PV &amp; PVC (Create volume manually and using that id)
2)Without using vol Id (dynamic provisioning of PV)</p>
<p>example-1:</p>
<pre><code>- apiVersion: &quot;v1&quot;
  kind: &quot;PersistentVolume&quot;
  metadata:
    name: &quot;pv-aws&quot;
  spec:
    capacity:
      storage: 10G
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    storageClassName: gp2
    awsElasticBlockStore:
      volumeID: vol-xxxxxxxx
      fsType: ext4
</code></pre>
<p>In this case, I am creating volume manually and using that I'm creating both PV &amp; PVC</p>
<p>example-2:</p>
<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: gp2
  resources:
    requests:
      storage: 20Gi
</code></pre>
<p>In this case by just creating PVC its creating volume in the backend (AWS) and PV.</p>
<p>What is the difference and in which to use in which scenarios? Pros and cons?</p>

<p>It should be based on your requirements. Static provisioning is generally not scalable. You have to create the volumes outside of the k8s context. Mounting existing volumes would be useful in disaster recovery scenarios.</p>
<p>Using <a href="https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html" rel="nofollow noreferrer">Storage classes</a>, or dynamic provisioning, is generally preferred because of the convenience. You can create roles and <a href="https://kubernetes.io/docs/concepts/policy/resource-quotas/#storage-resource-quota" rel="nofollow noreferrer">resource quotas</a> to control and limit the storage usage and decrease operational overhead.</p>
