AWS S3에서 업로드된 이미지를React애플리케이션에서 다운로드하려 할 때,CORS오류가 발생 !
확인된 이유
AWS는 일반적인a태그를 이용해서 이미지 다운로드가 안돼서fetch함수를 사용해서GET메소드로 가져온 다음,Blob형식으로 변환을 해줘야 다운로드가 가능한데,GET메서드가CORS오류가 발생하는 현상
S3버킷의CORS설정이 해당 애플리케이션의 도메인이나 요청 메서드를 허용하지 않기 때문에 발생
S3버킷의CORS설정을 수정해React애플리케이션의 도메인과 요청 메서드(GET,POST등)를 허용해야 합니다.
AWS 버킷 설정 → 권한 선택

권한 설정
CORS(Cross-origin 리소스 공유) 편집
[
{
"AllowedHeaders": ["*"],
"AllowedMethods": ["GET"],
"AllowedOrigins": ["*"],
"ExposeHeaders": []
}
]
AllowedHeaders : 브라우저가 요청에 포함할 수 있는 헤더를 지정합니다. 보안을 위해 특정 헤더만 허용하는 것이 좋습니다.
AllowedMethods : 허용하는 HTTP 메서드를 지정합니다.
[GET, POST, 등]
AllowedOrigins : 리소스에 접근할 수 있는 원본을 지정합니다. 개발 중에는 ["*"]를 사용하여 모든 도메인에서의 접근을 허용할 수 있지만, 배포 시에는 구체적인 도메인을 지정하는 것이 좋습니다.
ExposeHeaders : 브라우저에서 접근할 수 있게 할 추가적인 헤더를 지정합니다.
"서버에서 직접
Blob형태로 직접 제공하는 것이 좋지 않을까?" 라는 생각을 했었습니다.
하지만 위 방식은 클라이언트(예: React)에서 S3에 직접 접근하는 것보다 서버 리소스와 네트워크 대역폭을 더 많이 사용하게 됩니다.
따라서 클라이언트가 S3에서 이미지를 직접 다운로드할 수 있도록 하는 것이 일반적으로 더 효율적입니다.
결론적으로 어떤 방식으로든 구현은 가능하나 네트워크 사용, 서버 부하 등의 각각의 장단점이 있습니다.
효율성 : 클라이언트가 S3에서 직접 이미지를 다운로드하면,
서버는 단지 이미지의 URL만 클라이언트에게 제공하면 됩니다.
즉, 이미지 데이터가 서버를 거치지 않기 때문에 서버의 네트워크 대역폭과 리소스 사용이 절약됩니다.
확장성 : 클라이언트가 직접 S3와 통신함으로써, 서버의 부하가 줄어들고, 서버가 처리해야 할 요청의 수가 감소합니다.
고해상도 이미지나 대용량 파일을 다룰 때 서버의 확장성과 성능에 긍정적인 영향을 줍니다.
속도 : S3와 같은 파일 스토리지 서비스는 전 세계에 분산된 데이터 센터를 통해 콘텐츠를 제공하기 때문에,
사용자가 물리적으로 가까운 데이터 센터에서 데이터를 받을 수 있어 다운로드 속도가 빨라집니다.
서버 리소스 사용 : 서버가 클라이언트에게 이미지를 Blob 형태로 제공하려면, 서버가 S3 이미지 데이터를 받아야 합니다. 이후 이 데이터를 클라이언트에 전송하기 전에 서버 메모리에 임시로 저장됩니다.
이 과정에서 서버의 네트워크 대역폭과 리소스(예: CPU, 메모리)가 사용됩니다.
네트워크 대역폭 : 이미지 데이터가 서버를 통해 클라이언트에서 전송되는 과정에서 네트워크 대역폭을 두 번 사용됩니다.
S3 → 서버, 서버 → 클라이언트 (총 2번)
동시에 많은 사용자가 이미지를 요청할 때 서버의 네트워크 대역폭에 부정적인 영향을 줄 수 있습니다.
지연 시간 : 서버를 경유하는 추가적인 네트워크 요청은 전체적인 지연 시간을 증가시킬 수 있습니다.
이로 인해 사용자가 이미지를 받기까지의 시간이 길어질 수 있습니다.
종합적으로,
클라이언트 → S3에서 직접 리소스를 다운로드 하는 것이서버의 리소스와 네트워크 대역폭을 절약하고,사용자에게 더 빠른 다운로드 속도를 제공하여전반적인 사용자 경험을 향상시키는 것이 효과적인 방법으로 볼 수 있습니다.그러나
보안,접근 제어,사용자 인증등의 요구 사항이 있는 경우에는서버를 경유하는 방식이 필요할 수 있으므로이 경우에는서버와 네트워크 구성을 최적화하여 부하를 관리하는 것이 중요합니다.
좋은 내용이네요~!