[USER=11388]@Chris D[/USER] The unfortunate part here is that attachments are stored in the internal-data:// mount where also other things are stored (imported_xml, install-lock.php, oembed_cache, image_cache, file_check, sitemaps/, etc), which are not as suitable for remote filesystem as attachments.
Architecturally, it would be more flexible if attachments were stored in a separate mount (aka filesystem) that could use a different underlying storage. The data:// mount is limited to thumbnails and avatars, which makes it easy to point to remote filesystem.
The attachment:// mount would be a private bucket (in case of most Cloud Object Storage solutions such as S3 or Swift) with access secured by temporary URLs (most flysystem adapters support generating these). This way, the action of downloading an attachment would be a redirect to a signed expiring URL, instead of streaming the attachment through the webserver.
