This looks to work similarly to the Persistent Volumes in Kubernetes. To put it into OOP language Kubernetes persistent storage is modeled as an abstract class

This looks to work similarly to the Persistent Volumes in Kubernetes. To put it into OOP language Kubernetes persistent storage is modeled as an abstract class and a set of concrete types that implement a class. The advantage of this model is that an application requests the "Large and Slow Disk Class" not knowing how it works on each environment and a cluster owner then describes how to configure a spinning disk EC2 Storage to fulfill this class. So, the AWS Operator lets people use the Kubernetes APIs to configure AWS resources. But, if you use those APIs directly in say your Helm chart then your app won't be able to be configured and deployed on other cloud providers without editing those objects. Is it important to your application to be loosely coupled to the cloud provider? Then you need this sort of abstraction to enable portability. It sort of continues the Kubernetes vision beyond computer/network/storage into other cloud services like databases/serverless/AI/etc.