Trennung des S3-Backup-Anbieters vom primären S3-Anbieter

Ich denke, es wäre eine schöne Ergänzung, die Flexibilität zu haben, einen anderen S3-Anbieter für Backups anzugeben, anstatt denselben Anbieter wie für den Haupt-S3-Bucket verwenden zu müssen.

Hauptgründe:

  • Die Anforderungen an einen S3-Bucket, der statische Assets speichert, unterscheiden sich oft von denen eines Buckets, der Backups speichert. Z.B. ist eine starke Netzwerkleistung für einen Bucket wichtig, der statische Assets speichert, aber nicht so sehr für einen Backup-Bucket (abgesehen davon, dass er zuverlässig ist). Sicherheit kann für einen Backup-Bucket ein höheres Anliegen sein.

  • Für einen Backup-Bucket hat der ideale Anbieter wettbewerbsfähige Preise pro GB Speicherplatz, wobei die Egress-Preise nicht von großer Bedeutung sind.

  • Einfacherer Anbieterwechsel zur Lösung von Problemen mit bestimmten Anbietern. Z.B. funktioniert Scaleway S3 perfekt als primärer S3-Bucket für mich, aber bei Backups gibt es Probleme, da sie nur 1.000 Teile-Multipart-Uploads unterstützen, während das AWS S3 SDK maximal 10.000 verwendet. Ich habe dies mit pups gelöst, indem ich die maximalen Teile im S3-Gem ersetzt habe, aber das ist ziemlich provisorisch und ich muss bei jedem Update/jeder Neuerstellung prüfen, ob sich der Pfad zur Datei geändert hat. Um dieses Problem zu lösen, müsste ich den primären Bucket migrieren, um den Backup-Bucket zu einem anderen kompatiblen Anbieter zu wechseln.

  • Einfachere und bessere Sicherheit: Wenn der Anbieter oder das Konto des Backup-Buckets kompromittiert wird, befindet sich der primäre Bucket woanders. Dies würde in der umgekehrten Situation nicht so viel helfen, wenn z.B. der Haupt-Bucket-Anbieter kompromittiert und gelöscht würde (da S3-statische Assets nicht in den Backups enthalten sind) - aber zumindest hätte die böswillige Partei keinen Zugriff auf die Backup-Daten.

  • Möglicherweise einfacher, Mitarbeitern oder Auftragnehmern Zugriff zu gewähren, der auf den Haupt-Bucket oder den Backup-Bucket beschränkt ist, wenn der Anbieter kein erweitertes Zugriffs-/Rollenmanagement pro API-Schlüssel hat.

Wie auch immer, nur ein Vorschlag - danke!

2 „Gefällt mir“