Hi @Yuki
❌ Not currently — Unity Catalog Volumes do not natively support multipart upload via AWS SDK
Unity Catalog Volumes are Databricks-managed paths in S3 (or ADLS) accessed through Unity Catalog governance.
You can’t use low-level AWS SDK multipart APIs directly with Volumes (e.g., boto3.client('s3').upload_part(...)) because:
They don’t expose raw bucket paths.
They wrap access via workspace paths like volume://catalog.schema.volume/path/.
Unity Catalog volumes are intended for managed data access via Spark and file I/O, not for direct S3 multipart SDK operations.
Unity Catalog enforces fine-grained access control, so raw multipart access bypassing Databricks governance isn't supported.
✅ Can You Still Use Instance Profiles for Multipart Uploads?
✔️ Yes, with caution
While Databricks recommends moving away from instance profiles, they are still supported for use cases like yours where low-level AWS SDK access is required (e.g., multipart upload, boto3-based apps).
Just be sure to follow least privilege IAM practices, and isolate access to only the S3 buckets involved.
✅ Databricks' official docs confirm:
“Instance profiles are still supported but should be used for specific, advanced access cases.”
Better Practice (If Unity Catalog Adoption is Your Goal)
If you want to align more with Unity Catalog + credential passthrough, here's a hybrid approach:
1. ✅ Use Spark or DBFS for most volume-based data writes
Unity Catalog Volumes:
spark.write.csv("volume://my_catalog.my_schema.my_volume/my_table")
2. For multipart upload, use instance profile + boto3 in a secured job
Keep a specific job or notebook that:
Uses boto3 with credentials injected via instance profile
Uploads directly to raw S3 (outside UC)
Flags the output to be registered in Unity Catalog later via CREATE TABLE USING LOCATION
LR