AWS eks documentation change
Summary
Added documentation for using Mountpoint for Amazon S3 CSI driver with pod-level authentication via IRSA, caching configurations, and performance considerations
Security assessment
The change introduces documentation for using IAM Roles for Service Accounts (IRSA) to control pod access to S3 buckets, which is a security feature. However, there is no evidence of addressing a specific security vulnerability.
Diff
diff --git a/eks/latest/best-practices/aiml-storage.md b/eks/latest/best-practices/aiml-storage.md index ee224bae8..cc45f6a4b 100644 --- a//eks/latest/best-practices/aiml-storage.md +++ b//eks/latest/best-practices/aiml-storage.md @@ -136,0 +137,47 @@ For complete examples, see the [FSx for Lustre Driver Examples in GitHub](https: +**Scenario: Single GPU instance workload** + +**Mountpoint for Amazon S3 with CSI Driver:** You can mount an S3 bucket as a volume in your pods using [Mountpoint for Amazon S3 CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/s3-csi.html). This method allows for fine-grained access control over which Pods can access specific S3 buckets. Each pod has its own mountpoint instance and local cache (5-10GB), isolating model loading and read performance between pods. This setup supports pod-level authentication with IAM Roles for Service Accounts (IRSA) and independent model versioning for different models or customers. The trade-off is increased memory usage and API traffic, as each pod issues S3 API calls and maintains its own cache. + +**Example** Partial example of a Pod deployment YAML with CSI Driver: + + + # CSI driver dynamically mounts the S3 bucket for each pod + + volumes: + - name: s3-mount + csi: + driver: s3.csi.aws.com + volumeAttributes: + bucketName: your-s3-bucket-name + mountOptions: "--allow-delete" # Optional + region: us-west-2 + + containers: + - name: inference + image: your-inference-image + volumeMounts: + - mountPath: /models + name: s3-mount + volumeMounts: + - name: model-cache + mountPath: /models + volumes: + - name: model-cache + hostPath: + path: /mnt/s3-model-cache + +**Performance considerations:** + + * **Data caching** : Mountpoint for S3 can cache content to reduce costs and improve performance for repeated reads to the same file. Refer to [Caching configuration](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#caching-configuration) for caching options and parameters. + + * **Object part-size** : When storing and accessing files over 72GB in size, refer to [Configuring Mountpoint performance](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#configuring-mountpoint-performance) to understand how to configure the `--read-part-size` and `--write-part-size` command-line parameters to meet your data profile and workload requirements. + + * **[ Shared-cache](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#shared-cache) ** is designed for objects up to 1MB in size. It does not support large objects. Use the [Local cache](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#local-cache) option for caching objects in NVMe or EBS volumes on the EKS node. + + * **API request charges** : When performing a high number of file operations with the Mountpoint for S3, API request charges can become a portion of storage costs. To mitigate this, if strong consistency is not required, always enable metadata caching and set the `metadata-ttl` period to reduce the number of API operations to S3. + + + + +For more details, see the [Mountpoint for Amazon S3 CSI Driver](https://docs.aws.amazon.com/eks/latest/userguide/s3-csi.html) in the Amazon EKS official documentation. We recommend monitoring the performance metrics of [Amazon S3 with Amazon CloudWatch metrics](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudwatch-monitoring.html) if bottlenecks occur and adjusting your configuration where required. +