Отделение провайдера резервных копий S3 от основного провайдера S3

Я считаю, что было бы хорошим дополнением иметь возможность указывать другого провайдера S3 для резервных копий, вместо того чтобы использовать того же провайдера, что и для основного бакета S3.

Основные причины:

  • Требования к бакету S3, хранящему статические ресурсы, часто отличаются от требований к бакету для резервных копий. Например, для бакета со статическими ресурсами важна высокая производительность сети, тогда как для бакета с резервными копиями это не так существенно (кроме надежности). Для бакета с резервными копиями безопасность может быть более важным фактором.

  • Для бакета с резервными копиями идеальным провайдером является тот, у которого конкурентоспособные цены за гигабайт хранения, при этом стоимость исходящего трафика не имеет большого значения.

  • Проще сменить провайдера для решения проблем с конкретными поставщиками. Например, Scaleway S3 отлично работает как основной бакет S3 для меня, однако с резервными копиями возникают проблемы, так как они поддерживают только мультизагрузки до 1000 частей, тогда как AWS S3 SDK использует максимум 10 000 частей. Я решил это, изменив максимальное количество частей в библиотеке S3 с помощью pups, но это довольно временное решение, и мне нужно проверять, изменился ли путь к файлу при каждом обновлении/пересборке. Чтобы решить эту проблему, мне пришлось бы мигрировать основной бакет, чтобы переключить бакет с резервными копиями на другого совместимого провайдера.

  • Улучшенная безопасность: если провайдер или учетная запись бакета с резервными копиями будут скомпрометированы, основной бакет останется в другом месте. Это не так сильно поможет в обратной ситуации, например, если провайдер основного бакета будет скомпрометирован и данные будут удалены (поскольку статические ресурсы S3 не включены в резервные копии), — но, по крайней мере, злоумышленник не получит доступ к данным резервных копий.

  • Возможно, будет проще предоставить доступ сотрудникам или подрядчикам, ограниченный либо основным бакетом, либо бакетом с резервными копиями, если у провайдера нет расширенного управления доступом/ролями для каждого API-ключа.

В любом случае, это просто предложение — спасибо!

2 лайка