백업에 사용할 S3 제공자를 메인 S3 버킷 제공자와 별도로 지정할 수 있는 유연성을 갖추면 좋겠다는 의견입니다.
주요 이유:
-
정적 에셋을 저장하는 S3 버킷과 백업을 저장하는 버킷의 요구 사항은 종종 다릅니다. 예를 들어, 정적 에셋 버킷에는 강력한 네트워크 성능이 중요하지만, 백업 버킷에는 신뢰성만 있으면 충분합니다. 또한 백업 버킷의 경우 보안이 더 큰 우려 사항일 수 있습니다.
-
백업 버킷의 경우, GB당 저장 비용이 경쟁력이 있는 제공자가 이상적이며, 이GRESS(출력) 비용은 크게 중요하지 않습니다.
-
특정 제공자의 문제를 해결하기 위해 제공자를 변경하기가 더 쉬워집니다. 예를 들어, Scaleway S3는 제 메인 S3 버킷으로 완벽하게 작동하지만, 백업의 경우 1,000개 파트의 멀티파트 업로드만 지원하여 문제가 발생합니다. 반면 AWS S3 SDK는 최대 10,000개를 사용합니다. 저는 S3 게म의 최대 파트 수를 대체하는 pups를 사용하여 이 문제를 해결했지만, 이는 임시 방편이며 각 업데이트/재빌드 시 파일 경로가 변경되었는지 확인해야 합니다. 이 문제를 해결하려면 백업 버킷을 다른 호환 가능한 제공자로 전환하기 위해 메인 버킷을 마이그레이션해야 합니다.
-
백업 버킷 제공자 또는 계정이 침해된 경우 메인 버킷은 다른 곳에 있으므로 보안을 더 쉽게 강화할 수 있습니다. 반대로 메인 버킷 제공자가 침해되어 데이터가 삭제되는 경우(정적 에셋이 백업에 포함되지 않으므로)에는 도움이 덜 되지만, 적어도 공격자가 백업 데이터에 접근하지 못하게 됩니다.
-
제공자가 API 키별 고급 액세스/역할 관리를 지원하지 않는 경우, 직원이나 외주 인력에게 메인 버킷 또는 백업 버킷 중 하나에 한정한 액세스를 제공하기가 더 쉬워질 수 있습니다.
어쨌든, 단순한 제안입니다. 감사합니다!