バックアップ用に別のS3プロバイダーを指定できる柔軟性があれば、メインのS3バケットプロバイダーと同じプロバイダーを使用する必要がなくなり、良い追加機能になると思います。
主な理由:
-
静的アセットを保存するS3バケットとバックアップを保存するS3バケットでは、要件が異なる場合があります。例えば、静的アセットを保存するバケットではネットワークパフォーマンスが重要ですが、バックアップバケットではそれほど重要ではありません（信頼性があることを除けば）。バックアップバケットではセキュリティがより重要な懸念事項となる可能性があります。
-
バックアップバケットの場合、理想的なプロバイダーはGBあたりのストレージ価格が競争力があり、データ転送（egress）価格はそれほど重要ではありません。
-
特定のプロバイダーの問題を解決するために、プロバイダーを変更しやすくなります。例えば、Scaleway S3は私にとってプライマリS3バケットとしては完璧に機能しますが、バックアップに関しては問題があります。なぜなら、AWS S3 SDKが最大10,000パートのマルチパートアップロードを使用するのに対し、Scaleway S3は最大1,000パートしかサポートしていないからです。私はこれを pups を使用してS3 gemの最大パート数を置き換えることで解決しましたが、これはかなり場当たり的であり、更新/再構築のたびにファイルへのパスが変更されていないか確認する必要があります。この問題を解決するには、バックアップバケットを別の互換性のあるプロバイダーに切り替えるために、プライマリバケットを移行する必要があります。
-
セキュリティが容易に向上します。バックアップバケットのプロバイダーまたはアカウントが侵害された場合でも、プライマリバケットは別の場所にあります。逆の状況、つまりメインバケットのプロバイダーが侵害されて削除された場合（S3静的アセットはバックアップに含まれていないため）はそれほど役立ちませんが、少なくとも悪意のある当事者はバックアップデータにアクセスできなくなります。
-
プロバイダーがAPIキーごとの高度なアクセス/ロール管理を持っていない場合、従業員や請負業者にメインバケットまたはバックアップバケットに限定されたアクセスを提供することが容易になる可能性があります。
いずれにしても、提案です。よろしくお願いします！