Порівняльний аналіз Mountpoint для S3, S3FS та Goofys

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Максим Луцький, я працюю DevOps-інженером в компанії Avenga. Певний час тому, проглядаючи Release notes AWS, я помітив коротку нотатку про вихід інструменту Mountpoint для S3, що дозволяє монтувати вміст бакета в локальну файлову систему.

Мені стало цікаво: невже раніше так не можна було? І я почав досліджувати, які альтернативи взагалі доступні, як вони працюють і що із цього всього найкраще. Проте кроляча нора виявилась глибшою, ніж я очікував. Тому пропоную результати порівняння кількох схожих інструментів для монтування бакетів, загальне враження від них і бачення їх застосування.

До речі, стаття доступна також англійською.

Основи

В галузі хмарних обчислень Amazon Web Services (AWS) революціонізував спосіб зберігання та керування даними для організацій. Amazon S3 (Simple Storage Service) є одним з наріжних каменів цієї екосистеми; він надає масштабоване, надійне та високодоступне об’єктне сховище. Та все ж, поки S3 пропонує безпрецедентну гнучкість, процес роботи з ним відрізняється від традиційних файлових систем.

Для подолання цього бар’єру представлено Mountpoint для S3 — інструмент, що дозволяє користувачам монтувати Amazon S3-бакети як файлові системи на їхніх комп’ютерах.

AWS оголосив про загальну доступність Mountpoint для Amazon S3 9 серпня 2023 року, заявивши, що це файловий клієнт з відкритим кодом, готовий до використання в продуктивних середовищах. Він полегшує підімкнення Linux-орієнтованих застосунків безпосередньо до бакетів Amazon S3 та їх доступ до об’єктів, послуговуючись запитами до API локальної файлової системи.

Використовуючи Mountpoint для S3, застосунки можуть отримувати доступ до об’єктів, збережених в Amazon S3, за допомогою файлових операцій (відкриття та читання). Mountpoint для S3 автоматично перетворює запити API локальної файлової системи на REST API-запити до об’єктів S3. Клієнт також оптимізований для застосунків, що потребують високої пропускної здатності читання великих об’єктів (потенційно від багатьох клієнтів одночасно).

Він підтримує як послідовні, так і випадкові операції читання чинних файлів, а також записує нові об’єкти послідовно з одного клієнта за раз. Це, наприклад, добре підходить для масштабних застосунків для аналізу даних, які паралельно читають і генерують значні об’єми даних в S3, але не потребують можливості робити зміни всередині чинних об’єктів. Це означає, що Mountpoint для S3 годиться для застосунків, які працюють з інтерфейсом файлової системи.

Це потужний інструмент, який можна використовувати для різних завдань, зокрема:

• для Data lakes;
• для тренування ML;
• для рендерингу зображень;
• для симуляції автономних транспортних засобів;
• для ETL (extract, transform, load)-процеси.

Хоча Mountpoint може здатися чудовим вибором для розвʼязання проблеми монтування бакетів Amazon S3 як локальної файлової системи, це не перший інструмент, що вирішує подібні завдання. Урешті-решт, окрім Mountpoint, існували й інші проєкти з відкритим кодом, які пропонували подібну функціональність. Серед найвідоміших можна виділити: S3FS, Goofys, RioFS, ObjectiveFS тощо. Можна провести порівняльний аналіз інструменту для монтування бакетів S3 від AWS, а також двох найпопулярніших рішень з відкритим вихідним кодом від спільноти — S3FS і Goofys.

S3FS — це реалізація FUSE (Filesystem in Userspace) з відкритим вихідним кодом і популярний командний клієнт для швидкого і легкого керування файлами об’єктного сховища на машинах з операційними системами Linux, macOS і FreeBSD. Він часто оновлюється й має велику спільноту на GitHub. S3FS дозволяє користувачам монтувати бакети Amazon S3 як локальні файлові системи, надаючи шар абстракції файлової системи над об’єктами S3. Метою S3FS є спрощення завдань міграції, обробки та керування даними.

Goofys — це ще один інструмент з відкритим вихідним кодом, заснований на FUSE і призначений для Linux та macOS з метою монтування бакетів Amazon S3 як локальних файлових систем. Його основними особливостями, як стверджують розробники, є простота та легкість. Мова програмування, на якій він був розроблений, — Go. Goofys надає менший рівень функціональності, ніж S3FS-fuse (назва утиліти S3FS), але з кращою продуктивністю.

Порівняння AWS Mountpoint для S3, S3FS та Goofys

Інсталювання

S3FS: для Linux є доступними попередньо зібрані пакети, які можна встановити за допомогою вбудованих системних менеджерів пакетів. Додаткова конфігурація містить налаштування файлу ${HOME}/.aws/credentials або окремого файлу ${HOME}/.passwd-s3fs з обліковими даними AWS.

Goofys: на Linux однойменна утиліта Goofys може бути встановлена як попередньо скомпільований бінарний файл, доступний до завантаження з репозиторію проєкту на GitHub. Додаткова конфігурація має налаштування файлу ${HOME}/.aws/credentials або встановлення змінних середовища з обліковими даними AWS.

Mountpoint для S3: утиліта Mountpoint з назвою mount-s3 може бути встановлена за допомогою попередньо зібраного пакета, що зберігається в репозиторії Amazon. За необхідності також можливо зібрати утиліту з вихідних кодів (така функція доступна для всіх трьох утиліт). Додаткова конфігурація містить налаштування файлу ${HOME}/.aws/credentials або встановлення змінних середовища з обліковими даними AWS.

Продуктивність

Тестування пропускної здатності інструментів для монтування виконано за допомогою утиліти FIO як найбільш поширеної для таких цілей, а також з використанням утиліти JuiceFS bench.

Утилітою FIO було протестовано швидкість послідовного запису й читання файлів розміром 4 та 16 ГБ у режимах 1 процесу та 16 процесів, а також змішані функції читання й запису та функції випадкового читання й запису (але тільки в режимі одного процесу).

У процесі використання JuiceFS bench виконано тестування функцій read та write для файлу розміром 1 ГБ з розміром блоку 1 МБ, а також запису й читання для 100 файлів розміром 128 КБ кожен, 1 та 16 процесами. Тестування виконувалося на інстансі EC2 розміром m5.4xlarge + EBS io2 100Gb, з операційною системою Amazon Linux 2 в регіоні us-east-1a, підімкненому до бакета в регіоні us-east-1.

Під час тестування пропускної здатності використано такі версії утиліт:

• Fio — 3.7
• JuiceFS — 1.0.4
• Goofys — 0.24
• S3FS — 1.93
• Mount-s3 — 1.0.0

Команда FIO, що використовувалась для тестування:

fio --name=seq_1_thread --directory=<mounted_directory> --size=<size_of_file> --rw=<type_of_IO_pattern> --bs=128k --direct=1 --numjobs=<number_of_jobs> --ioengine=libaio --iodepth=16

• Size — були протестовані значення 4 ГБ та 16 ГБ.
• rw — були застосовані значення write, read, rw, randwrite, randread.
• bs — розмір блоку файлу 128 КБ, як усереднене значення.
• direct — небуферизованний I/O.
• numjobs — кількість процесів для виконання операції.
• ioengine — визначає, як завдання виконує I/O у файл. Libaio було обрано як вбудоване асинхронне I/O в Linux.
• iodepth — кількість I/O юнітів, що будуть триматися в обробці для доступу до файлу. Значення 16 було обрано для емуляції асинхронного доступу до файлів.

Команди, що використовувалися для монтування:

Goofys

goofys test-bucket /tmp/goofys

S3FS

s3fs test-bucket /tmp/s3fs -o bucket_size=1PB,parallel_count=400,ensure_diskfree=1024,del_cache,use_cache=/tmp/

mount-s3

mount-s3 test-bucket /tmp/mount --allow-delete

Отримані результати

Goofys продемонстрував високу продуктивність в послідовних операціях запису та читання, проте ці показники є результатом певних обмежень у його функціональності: відсутність передачі метаданих файлів, слабка сумісність з POSIX. Крім того, Goofys не зберігає інформацію про права, власника, групу файлу, а також символьні та жорсткі посилання на них, і підтримує лише послідовний запис.

В операціях випадкового читання / запису пропускна здатність спостерігається на рівні <1 МБ/с, що не можна назвати задовільною швидкістю у роботі з файловою системою. У цілому Goofys продемонстрував високу стабільність і надійність у роботі з файлами. Під час його тестування не виникло жодних проблем з надійністю та безперебійністю роботи.

S3FS показав найповільнішу пропускну здатність для файлових операцій серед інших інструментів. Основною причиною такої швидкості є передача метаданих за допомогою HTTP-хедерів. Натомість він має низку відмінних особливостей, що надають роботі зі змонтованим бакетом S3 характер роботи зі звичайною файловою системою. S3FS забезпечує високий рівень сумісності з POSIX, що містить читання / запис файлів, каталогів, символьних посилань, прав доступу, uid/gid, розширених атрибутів (xattr), перейменування через копіювання на стороні сервера.

Ще однією важливою функцією S3FS є кешування даних, за допомогою якої дані кешуються на локальному диску. Кешування дозволяє підтримувати операції випадкового запису та дописування даних до файлів, що існують. Goofys також підтримує дописування даних до файлу, але лише шляхом його перезапису, тоді як mount-s3 цю функцію зовсім не має. Це можна спостерігати на графіках пропускної здатності, де лише S3FS може виконувати випадкові та комбіновані операції читання та запису, використовуючи кешовані дані.

Однак кешування також може призвести до проблем під час роботи з файлами, й цю функцію неможливо вимкнути. Під час роботи з великими файлами, локальна файлова система може переповнитися через те, що кеш S3FS здатен зайняти весь доступний дисковий простір (доступні опції монтування для запобігання такій ситуації), що робить подальші операції неможливими. Під час тестування пропускної здатності виявлено кілька проблем, що негативно вплинули на швидкість операцій з даними.

Перша проблема пов’язана з кешуванням: після виконання кількох тестів з операціями над файлами розміром 16 ГБ в 16 паралельних процесах, на локальному диску (EBS io2 100Gb) не залишилося вільного місця, оскільки весь простір був зайнятий кешем S3FS, що призвело до зупинки операцій з даними. Ця проблема може бути вирішена лише мануальним видаленням кешу, оскільки параметри монтування S3FS дозволяють резервувати вільний простір на диску та видаляти кеш тільки після розмонтування бакету.

Друга проблема стосується пула обробників застосунку. S3FS може вичерпати обробників в своєму пулі після певного часу з початку виконання операцій над великими файлами в режимі multipart upload, залежно від розміру блоку і кількості запитів. Це репрезентовано в логах S3FS:

Упродовж усього часу, поки обробники перестворювалися та додавалися назад у пул, операції з даними не відбувалися, що значно знижувало середню швидкість передачі даних.

Mountpoint для S3 показав результати, дуже схожі до Goofys, з точки зору пропускної здатності передачі даних та загальних функціональних можливостей. Mountpoint для S3 також демонструє низьку сумісність із POSIX, підтримуючи лише найбільш базові функції, такі як open, close, read, write, create та opendir. Він не використовує передачу метаданих файлів та не підтримує кешування. Також не підтримуються такі функції: перейменування каталогів, символьні посилання, жорсткі посилання, збереження прав доступу, uid, gid і випадковий запис.

Однак найбільшими недоліками є неможливість дописувати або змінювати файли, що існують. Кожен файл, створений в змонтованій файловій системі, стає незмінним, що вимагає його мануального видалення та перезаписування для будь-яких змін в ньому. Goofys також має схоже обмеження, проте він може автоматично перестворювати файли під час дописування в них даних. Крім того, відсутня сумісність із параметрами файлу fstab для систем Linux, що ускладнює автоматичне монтування при запуску ОС.

Ще одним обмеженням є (за замовчуванням) те, що після монтування бакету файли в ньому неможливо видалити. Це можна виправити, змонтувавши каталог з відповідним ключем --allow-delete. Варто також зазначити, що замість утиліти JuiceFS bench для тестування запису та читання великої кількості файлів малого розміру для Mountpoint для S3 була використана утиліта FIO.

Це пов’язано з тим, що Mountpoint для S3 не підтримує зміну або перезапис уже створених файлів, а алгоритм роботи JuiceFS bench спочатку створює порожні файли у файловій системі, а потім записує в них дані. Зміна такої поведінки алгоритму роботи не передбачена. Також не передбачена можливість запису у файл відразу після його створення, як це можливо у FIO. Тому результати такого тестування є, можливо, менш точними для Mountpoint для S3 на останній діаграмі.

Масштабованість

S3FS. Теоретично, S3FS здатен підтримувати одночасне монтування одного бакета S3 кількома клієнтами. Однак через відсутність координації між клієнтами під час монтування одного й того ж бакета, існують ризики, пов’язані з операцією write, оскільки контроль над одночасним запису даних є відсутнім, а S3 працює за моделлю last-writer-wins.

Та все ж деякий рівень консистентності даних зберігається. Це стосується одночасних запитів на читання та запис від кількох клієнтів водночас. Проте це забезпечується підходом AWS read-after-write до консистентності з грудня 2020 року.

Goofys. Оскільки Goofys використовує ту ж імплементацію FUSE (Filesystem in Userspace), його можливості щодо масштабованості еквівалентні S3FS.

Mountpoint, згідно з документацією AWS, здатен масштабуватися на тисячі екземплярів. Mountpoint для S3 базується на тій же бібліотеці AWS Common Runtime (CRT), яка використовується більшістю SDK AWS. Для Amazon S3 CRT додає клієнта, який реалізує шаблони щодо продуктивності, зокрема тайм-аути, повтори та автоматичну паралелізацію запитів для високої пропускної здатності.

Гнучкість налаштувань

Goofys не має багато опцій, що доступні під час монтування бакету S3, — лише базові. Серед важливих функцій є можливість ввімкнення кешування, підтримка ОС-специфічних параметрів монтування, що дозволяє використання fstab для автоматичного монтування під час запуску ОС. Доступні опції також містять управління TTL кешем, ACL для об’єктів, шифрування, зокрема SSE-C. З іншого боку, відсутня підтримка налаштування multipart uploads, запитів до S3 або проксі та недостатня документованість інструменту в цілому.

S3FS надає надзвичайно велику кількість опцій, доступних при монтуванні. Особливо корисними є можливості налаштування кешування, параметрів зберігання кешу на локальному диску та його використання, можливість додавати HTTP-заголовок для кожного файлу, налаштування кількості запитів до S3 і параметрів multipart upload для кожного запиту.

S3FS надає можливість повністю вимкнути функцію multipart upload, вибрати API для підімкнення, а також об’єкти IAM, що будуть використовуватися для доступу до файлів. Крім того, він пропонує можливість використовувати fstab для автоматичного монтування, використання xattr, налаштування проксі для передачі даних, підтримку багатопотокової роботи та може працювати у фоновому режимі.

Загалом, S3FS пропонує надзвичайну гнучкість в налаштуванні. Варто зазначити, що конфігурування кожного клієнта є рекомендованим, адже налаштування за замовчуваннями показують середню продуктивність роботи. І для її покращення саме тонке конфігурування кожного монтування, залежно від середовища використання, є необхідним.

Mountpoint для S3 має обмежені можливості конфігурації монтування, показуючи навіть меншу гнучкість налаштування, ніж Goofys. Проте mount-s3 надає найвищий рівень інтеграції з AWS S3 серед інших інструментів. Деякі з найважливіших функцій містять встановлення регіону (що виявляється в автоматичному визначенні регіону бакету під час старту), підтримку S3 Access points (що дозволяє монтувати бакет через його ARN точки доступу), підтримку S3 Multi-Region Access Points, S3 Object Lambda Access Points, S3 Transfer Acceleration за доступу до S3. Інструмент може працювати в багатопотоковому або фоновому режимах.

На цей час основним недоліком є відсутність підтримки ОС-специфічних параметрів монтування, що заважає використовувати fstab для автоматизації. Крім того, не підтримується шифрування SSE-C, а також IAM та ACL. Їхнє конфігурування повинно бути виконано на стороні S3. Можливість ввімкнення кешування чи налаштування проксі запитів відсутня.

Крім того, всі три інструменти підтримують можливість вибору класу зберігання для нових об’єктів, дозволяють використовувати requester-pays бакети, можливість монтування префіксу бакету та підімкнення до бакету S3 через endpoint. Крім того, ці інструменти дозволяють редагувати біти прав доступу для каталогів і файлів, так само як їхні UID і GID (оскільки оригінальні не зберігаються).

Використання

S3FS здатний монтувати бакети S3 так, ніби вони є директоріями на локальній машині. Це може бути корисним в разі потреби отримувати доступ до даних S3 за допомогою звичайних файлових операцій та для широкого спектра програм і утиліт, що очікують файлової системи за стандартом POSIX (LSB). Сценаріями використання можуть бути: потокове відтворення великих медіафайлів, кешування часто використовуваних даних локально для зменшення витрат на передачу даних і підвищення продуктивності, створення резервних копій і архівів безпосередньо на S3.

З іншого боку, S3FS не є таким продуктивним, як інші інструменти монтування. Це може бути критичним, особливо для застосунків, що потребують великої пропускної здатності для обробки даних. Налаштування і конфігурація S3FS є безперечно складнішою, ніж використання Goofys або Mountpoint.

Для Goofys характерна простота. Це відмінний вибір, якщо є потреба в легкому, простому в користуванні інструменті для монтування бакетів S3. Goofys може бути ефективним способом доступу до даних S3, з ним не має необхідності в складних налаштуваннях для швидкого розгортання проєкту або проєктів невеликого масштабу. У порівнянні з S3FS, Goofys використовує менше ресурсів, що важливо для обмежених у ресурсах середовищ, тому це найкращий вибір, коли продуктивність і ефективність ресурсів є основними питаннями.

З іншого боку, Goofys не має таких розширених функцій (доступних у S3FS), як, наприклад, опції налаштування multipart upload. Через свою легкість, що відчувається в недостатній гнучкості налаштування та слабкій сумісності з POSIX, він може бути не найкращим вибором для проєктів, де застосунки залежать у своїй роботі від бітів прав доступу файлів або випадкових операцій.

Mountpoint для S3 концептуально є простим інструментом. Його головна мета — ефективно використовувати можливість мережевого каналу передачі даних для підвищення пропускної здатності при роботі з даними, що дозволяє зменшити витрати, не знижуючи рівень продуктивності та стабільності. Він підтримує роботу з файлами, яка містить послідовне і випадкове читання, послідовний запис. Mountpoint є єдиним рішенням для проєктів рівня enterprise, де потрібен офіційний, production-ready та enterprise-ready клієнт для ефективного доступу до S3 об’єктів з можливістю масштабування та офіційною підтримкою від AWS. Усі інші імплементації FUSE не визнані розробниками, як production-ready.

З іншого боку, відсутність кешування, сумісності з POSIX та проблема з дозаписуванням файлів без автоматичного перезапису роблять цей інструмент прийнятним лише для програм із великою кількістю операцій читання (з деякими винятками).

Загалом будь-яка імплементація FUSE або інший «міст» між об’єктним і файловим сховищами має чітко визначену галузь застосування через свої вбудовані обмеження і не є універсальним рішенням, за винятком деяких сценаріїв використання. Таке рішення може використовуватися для легасі-застосунків, які співіснують з хмарними технологіями. Оскільки міграція цих легасі-застосунків до хмарного середовища може бути вартісною і займати багато часу, не кажучи вже про загальну можливість чи потребу в такій міграції. Тому в таких випадках застосункам, що здатні працювати лиш з файловими сховищами, доводиться взаємодіяти з даними, які зберігаються в хмарному середовищі.

Також існують випадки, коли сховище даних було перенесено в хмару, але легасі-застосунки, які ним користуються, можуть виконувати лише операції читання і запису зі звичайною файловою системою. Проте навіть у таких сценаріях застосунок повинен відповідати певним умовам, щоб працювати продуктивно і надійно з об’єктним сховищем, яке змонтоване як файлова система:

• Перш за все застосунок, що буде виконувати операції з файлами, не повинен вимагати великої пропускної здатності обробки файлів і не повинен дуже залежати від семантики POSIX.
• Якщо застосунок одночасно виконує операції читання та запису файлів, найкраще використовувати справжню файлову систему для роботи з даними і копіювати лише кінцеві результати в об’єктне сховище. Це пов’язано з тим, що одночасні операції читання та запису або не підтримуються, або мають низьку пропускну здатність, що було відображено на діаграмах з результатами тестування.
• FUSE-клієнт найбільш корисний і практичний, коли лише невелика частина застосунків в проєкті вимагає класичної файлової системи для роботи, в основному проводячи прості операції читання або запису, тоді як більшість застосунків виконує пряму взаємодію з об’єктним сховищем.

Важливо також пам’ятати про обмеження імплементацій FUSE:

• Не варто покладатись на метадані файлів, такі як: власник, група, права доступу, використовуючи клієнт FUSE. Натомість для керування правами доступу ліпше скористатись S3 key policies.
• Не використовувати атомарні перейменування файлів або директорій (наприклад: команда mv).
• Мінімізувати операції лістингу директорій через низьку ефективність, а відповідно, і швидкість такої операції.
• Підтримувати тільки послідовні операції, операції випадкового запису або дозапису файлу, памʼятаючи, що вони оптимізовані за допомогою multipart upload і вимагатимуть перезапису цілого об’єкту.
• Не використовувати символьні посилання та жорсткі посилання.
• Не варто покладатись на 100% консистентність даних між клієнтами під час спільного використання файлів (у випадках одночасного монтування цими клієнтами того самого бакета S3), оскільки координація між кількома клієнтами, які монтуватимуть однаковий бакет S3 при записі файлів, не передбачена.
• FUSE-клієнти не є оптимізованими для роботи з файлами дуже великого розміру (1 ТБ або більші).

Застосунок, що використовує файловий клієнт FUSE, повинен працювати переважно з дуже простими операціями, як-от читання або запис файлів й проводити їх одночасно.

Дуже зручно думати про S3 як про файлову систему, але це не так. S3 — це розподілена NoSQL база даних для великих об’єктів, яка не підтримує кастомні атрибути або пошук вмісту. Вона повністю атомарна, з read-after-write моделлю консистентності, з більшою затримкою порівняно з GlusterFS або навіть NFS. Проте для випадку конкурентного запису об’єктів, S3 користується моделлю last-writer-wins. Це означає, що в об’єкті збережені дані отримані від клієнта, який останнім отримав підтвердження запису. У зв’язку із цим в деяких ситуаціях можлива невизначеність щодо того, які саме дані були збережені в об’єкт.

До таких ситуацій належать одночасний запис і читання файлу, що вже існує, або одночасний запис файлу двома клієнтами з нестабільними мережевими каналами, коли підтвердження запису може надсилатися з різною швидкістю. Такі ситуації невизначеності можуть створювати дуже дивні, хоч і тимчасові ситуації. Наприклад, коли один сервер обслуговує новий вміст, а інші — старий.

Зі свого боку FUSE клієнти також можуть створювати невизначеності в роботі з файлами. S3FS намагається забезпечити дуже POSIX-сумісну файлову систему, але вона може виконуватися лише обмежену кількість операцій. Наприклад, одне з обмежень S3FS — inotify — виявляє лише локальні зміни, але не зовнішні, зроблені іншими клієнтами або інструментами. Це може здатись складним для розуміння.

Якщо програмне забезпечення вебсервера кешує вміст у RAM і покладається на моніторинг за змінами на диску через inotify, вебсервер продовжуватиме обслуговувати старий вміст нескінченно. Ще гірше, якщо команда монтування S3FS виконана без опції use_cache, тоді затримка при обробці запитів значно зросте, сповільнюючи сайт, оскільки він завантажує дані з S3 під час кожного запиту. Це також може збільшити загальний рахунок використання акаунту AWS через витрати за кожен запит. Іншим негативним наслідком може бути погіршення користувацького досвіду від роботи з сайтом, оскільки швидкість завантаження сторінки знизиться.

Загалом зберігання статичних ресурсів в AWS S3, з подальшим їхнім монтуванням як файлів на сервер з вебзастосунком, буде значно повільнішим, з меншою надійністю та більшими витратами, ніж використання вбудованих можливостей S3 з хостингу статичних сайтів. Це пов’язано з тим, що швидкість опрацювання й передачі для великої кількості малих файлів клієнтами FUSE є досить низькою (можна побачити на графіку).

Звісно, використання клієнтів FUSE, як-от Mountpoint для S3 та інших, — безкоштовне, але існують витрати, пов’язані з кожним запитом до Amazon S3 (крім запитів в одному регіоні) та плати за зберіганням даних в бакеті (залежить від об’єму даних та класу зберігання).

Висновок

Підсумовуємо: Mountpoint для S3, Goofys і S3FS — це клієнти, які дозволяють використовувати об’єктне сховище AWS S3 (S3FS та Goofys можуть працювати з іншими) у застосунках, які очікують роботи з традиційними файловим сховищем.

S3FS є потужним інструментом для безшовної інтеграції Amazon S3 в середовище Linux. Він є хорошим вибором для сценаріїв, які передбачають монтування S3 як файлової системи, яка підтримує певний рівень сумісності з POSIX, де рівень продуктивності не є критичним. S3FS має гнучку конфігурацію з широким вибором важливих опцій та може бути застосованим для створення резервних копій і архівів, потокового відтворення, а також кешування.

Goofys можна обрати, коли основними вимогами є простота, легкість, продуктивність та ефективність використання ресурсів. Особливо добре підійде для проєктів невеликого масштабу або перевірки POC та проєктів, де немає залежності від складних операцій з файлами.

У випадках, коли потрібен надійний, офіційний, production-ready клієнт з високою продуктивністю для роботи з об’єктним сховищем AWS S3, то Mountpoint для S3 є єдиним вибором. Оскільки він забезпечує високий рівень інтеграції з AWS та відповідає вимогам enterprise з підтримки. Mountpoint для S3 підходить для застосунків, які виконують багато операцій читання, як-от Data Lakes, Machine Learning, та під час роботи з масштабованими застосунками.

Проте конкретний вибір методу доступу до AWS S3 потрібно розглядати, зважаючи на вимоги щодо зручності, сумісності й продуктивності, що потребує кожен окремий проєкт.