Как обычно хранят в S3 пользовательские аватарки, документы и бэкапы: в одном bucket или в нескольких

Единственно правильного варианта нет, но на практике данные обычно разделяют по назначению и требованиям: бэкапы выносят в отдельный bucket, а аватарки и пользовательские документы хранят в одном или нескольких bucket’ах с разными префиксами и политиками доступа. Я бы предложил минимум: отдельный bucket для бэкапов, отдельные bucket’ы для prod/stage/dev и внутри них префиксы вида avatars/, docs/. Такое разделение упрощает управление безопасностью, lifecycle-политиками и правами доступа.

В S3 объектно-хранилище bucket — это административная граница: для него задаются политика доступа (bucket policy), регион, шифрование по умолчанию, lifecycle-правила, репликация и т.п. Поэтому решение «один или несколько bucket’ов» всегда завязано на безопасность, требования к хранению и удобство администрирования, а не только на структуру данных.

Хранить «всё в одном bucket» с разными префиксами (avatars/, docs/, backups/) технически можно и это часто делают на маленьких проектах. Но по мере роста системы почти всегда появляется разделение:

• Отдельный bucket для бэкапов. У бэкапов, как правило, самые жёсткие требования по доступу (доступ только у бэкап-сервиса и админов), отдельные retention-политики и иной lifecycle (быстрый перевод в дешёвые классы хранения, долгий срок хранения). Логично выносить их в отдельный bucket, часто даже в отдельный аккаунт.
• Разделение по окружениям. Продакшен, стейджинг и дев обычно идут в разных bucket’ах, например myapp-prod-data, myapp-staging-data. Это снижает риск перепутать окружения и позволяет давать дев-команде более широкие права не затрагивая прод.
• Публичное vs приватное. Аватарки могут быть публично доступными через CDN, а документы — строго приватными. Удобно иметь отдельный public-bucket и private-bucket, либо чётко разделённые префиксы с разными IAM-политиками доступа через role’ы / signed URL.
• Логическая группировка, но без излишеств. Обычно не делают bucket «на каждого пользователя» — это плохо масштабируется и усложняет управление (лимиты на количество bucket’ов, политики, мониторинг). Вместо этого используют ключи объектов вида users/<userId>/avatars/<fileName> или users/<userId>/docs/<docId> в ограниченном количестве bucket’ов.
• Разные lifecycle-политики. Например, аватарки редко удаляются и могут спокойно лежать в стандартном классе хранения, пользовательские документы — подчиняются юридическим требованиям (GDPR, сроки хранения), а бэкапы нужно через N дней отправлять в архивный класс и удалять через год. Намного проще вешать разные lifecycle-правила на отдельные bucket’ы, чем пытаться тонко настраивать их только префиксами.

Практический, «приземлённый» вариант структуры для типичного веб-приложения мог бы выглядеть так:

Для продакшена:

myapp-prod-public — аватарки и прочие публичные файлы с префиксами вида avatars/, public-assets/.
myapp-prod-private — пользовательские документы, загружаемые файлы, чувствительные данные, с префиксами users/<userId>/docs/ и пр.
myapp-prod-backups — бэкапы баз данных, снапшоты конфигураций и т.п., максимально ограниченный доступ и свои lifecycle-правила.

Для стейджинга и дев-окружения — аналогичные bucket’ы с суффиксами -staging, -dev, но с другими правами доступа и, как правило, более агрессивными правилами очистки.

Важно подчеркнуть на собеседовании не просто схему, а критерии, по которым вы её выбираете:

безопасность и разделение прав (кто и к чему должен иметь доступ);
соблюдение регуляторных требований и retention-политик;
простота DevOps-процессов (деплой, бэкапы, восстановление, мониторинг);
масштабируемость и ограничение количества bucket’ов до разумного минимума.

При этом важно уметь использовать «папки» (на самом деле это просто префиксы ключей) внутри одного bucket’а, чтобы не плодить лишние bucket’ы там, где достаточно логического разделения. Например, структура ключей для пользователя может быть такой:

Создание отдельных bucket’ов для разных доменов данных и окружений можно оформить в инфраструктурном коде или просто через CLI. Например, создание bucket’а под продакшен-бэкапы:

Итого: пользовательские аватарки и документы обычно группируют в ограниченном числе bucket’ов (разделяя их префиксами и политиками доступа), а бэкапы почти всегда выносят в отдельный bucket с особыми правами и lifecycle-политиками. На собеседовании важно показать именно это понимание принципов проектирования, а не попытаться угадать «магическое число» bucket’ов.