임시 다운로드를 S3에서 직접 제공하면 S3 presigned URL을, 여러 지역의 이용자에게 CDN 캐시를 쓰면서 접근을 제한하려면 CloudFront 서명 URL을 검토하세요. OAC는 CloudFront의 S3 원본 접근을 제어하며 이용자의 다운로드 자격을 대신 확인하지 않습니다. 두 서명 방식을 같은 URL에 섞기 전에 어느 서비스가 요청을 검증할지 정해야 합니다.
혼동의 원인: 이용자 권한·서명·원본 접근을 한 설정으로 보기
애플리케이션은 로그인한 사람이 해당 파일을 받을 수 있는지 판단합니다. 그 다음 허용된 파일과 기간에 한정해 URL을 발급합니다. 파일 저장소를 비공개로 만들었다는 사실만으로 이 애플리케이션 권한 검사가 생기지는 않습니다. 반대로 앱 화면에서 버튼을 숨겨도 이미 유출된 유효 URL의 접근까지 막을 수는 없습니다.
S3는 URL을 발급한 주체의 권한과 서명·유효 기간 등을 바탕으로 직접 요청을 처리합니다. CloudFront 서명 URL은 배포에 연결한 공개 키와 정책으로 이용자 요청을 검증하고, 원본을 읽어야 할 때 별도로 S3 접근 권한을 사용합니다. 발급용 비공개 키와 OAC의 역할을 구별해 운영하세요.
| 판단 항목 | S3 presigned URL | CloudFront 서명 URL |
| 이용자 요청 | S3 직접 요청의 서명 검증 | CloudFront viewer 서명 검증 |
| 캐시 경로 | CDN을 전제로 하지 않음 | 캐시 동작·원본 정책 설계 |
| 발급 권한 | IAM 주체 권한과 자격 유효 기간 | 서명 키·신뢰할 키 그룹 |
| 원본 통제 | 버킷·IAM 정책 | OAC와 버킷 정책도 별도 |
1. 한 번의 다운로드와 반복 배포를 나눠 고른다
내부 업무의 소수 파일을 짧게 공유하는 경우에는 S3 직접 전달 경로가 단순할 수 있습니다. 같은 콘텐츠를 여러 지역에서 반복 다운로드한다면 CloudFront 캐시와 원본 요청량·전송 경로를 함께 평가합니다. 요청 수·다운로드 크기·지역·캐시 정책이 다르면 비용 비교도 달라지므로 “CDN이 항상 싸다”는 식의 결론은 내리지 않습니다.
다운로드 한 파일을 제어하는 것과 HLS처럼 여러 파일을 묶어 제공하는 경우도 구분합니다. 여러 파일의 접근 기간을 함께 관리해야 하면 CloudFront 서명 쿠키가 후보가 될 수 있습니다. 먼저 실제 클라이언트의 쿠키 지원과 도메인·재생 경로를 확인하세요.
2. CloudFront를 고르면 viewer 제한과 OAC를 각각 확인한다
해당 캐시 동작에서 서명 URL 또는 쿠키를 요구하도록 설정하고 신뢰할 키 그룹을 연결합니다. 이것이 이용자 요청의 제한입니다. 이어 S3 REST 원본에 OAC를 연결하고 해당 배포만 필요한 객체를 읽을 수 있도록 버킷 정책을 설계합니다. 공개 버킷이나 기존의 다른 읽기 권한이 남아 있으면 원본을 통한 우회 경로가 유지될 수 있습니다.
OAC를 연결했다는 이유만으로 모든 CloudFront URL이 자동 비공개라고 판단하지 마세요. S3 웹사이트 엔드포인트를 REST 원본과 같은 조건으로 취급해서도 안 됩니다. 기존 서비스에서는 정책을 한꺼번에 교체하기보다 시험용 경로로 영향 범위를 확인하고 이전 설정과 복구 기준을 보존합니다.
3. 만료와 캐시를 분리해 검증한다
S3 presigned URL은 발급에 사용한 임시 자격 증명이 더 먼저 만료되면 URL에 적힌 기간보다 일찍 사용할 수 없게 됩니다. CloudFront는 요청을 받을 때 서명과 정책을 확인하며 캐시에 객체가 있다는 사실만으로 서명 검사를 생략하지 않습니다. 이미 시작된 다운로드와 만료 후 새 요청·Range 요청은 다르게 관찰할 수 있으므로 하나의 응답만 보고 만료가 안 된다고 판단하지 않습니다.
설계 검증용 가상 체크리스트 — 실제 요청 결과 아님
허용 사용자 → 허용 파일 URL 발급 → 다운로드 확인
비허용 사용자 → 발급 API에서 거부되는지 확인
서명 없는 CDN URL → viewer 제한 적용 확인
만료 후 새 요청 → 만료 정책 적용 확인
S3 직접 주소 → 원본 우회 권한이 남았는지 확인확인 방법과 주의사항: URL은 접근 권한으로 다룬다
대표 파일로 정상·무서명·변조·만료 후 요청과 S3 직접 접근을 각각 기록합니다. 서버 로그의 요청 경로·상태와 애플리케이션의 발급 결정을 함께 봅니다. 브라우저 로컬 캐시가 화면에 파일을 보여주는 것과 서버에서 새 다운로드가 허용되는 것을 구분하세요. 키 교체 때는 새 키 발급, 기존 URL 유효 기간, 구 키 제거의 순서를 시험합니다.
서명 URL은 소유자가 기간 안에 재사용·전달할 수 있는 접근 수단입니다. 한 번만 사용 가능한 링크가 필수라면 앱의 상태 관리와 별도 설계가 필요합니다. 전체 URL을 공개 로그·채팅·분석 도구에 남기지 말고 HTTPS와 짧은 유효 기간을 사용하세요. CORS 설정이나 URL 인코딩 문제를 해결하려고 버킷을 공개하지 않습니다.
FAQ
OAC만 켜면 유료 회원만 받을 수 있나요? OAC는 원본 접근 제어입니다. 이용자 자격 확인과 viewer 서명 제한은 별도로 설계합니다.
S3 서명 URL의 호스트만 CDN 주소로 바꾸면 되나요? 서로 다른 서명 검증 방식입니다. 선택한 서비스의 발급 방식과 정확한 요청 URL을 사용해야 합니다.
캐시 무효화로 모든 링크를 즉시 폐기할 수 있나요? 객체 캐시 제거와 URL 권한 취소는 다른 작업입니다. 서명 키·정책·유효 기간과 응용 프로그램 요구를 함께 검토하세요.
공식 출처와 관련 글
공식 자료 확인일은 2026년 10월 16일입니다. 명령·설정은 공식 문서로 확인했으며 운영 서비스에서 직접 실행한 시험·속도·비용 결과가 아닙니다. 실제 적용 전 설치 버전과 대상 서비스의 지원 범위를 확인하세요.
S3 presigned URL 권한·만료·bearer token
관련 글: CloudFront와 Cloudflare의 캐시·원본·비용 비교
'소프트웨어개발' 카테고리의 다른 글
| Docker COPY checksum not found 해결: 빌드 컨텍스트·dockerignore·스테이지 확인 (0) | 2026.10.17 |
|---|---|
| PostgreSQL 이전: pg_dump와 AWS DMS 선택, 중단 시간·CDC·검증 기준 (0) | 2026.10.17 |
| Docker·CI Git dubious ownership 해결: UID·마운트·safe.directory 점검 (0) | 2026.10.16 |
