S3 presigned URL이 일찍 만료될 때: 다운로드 재발급 설계

S3 다운로드 링크를 7일로 발급했는데 훨씬 일찍 실패한다면, URL에 넣은 만료 시간만 확인해서는 원인을 찾기 어렵습니다. 서명에 사용한 임시 자격 증명과 적용 정책이 더 짧은 제한을 만들 수 있습니다. 며칠 동안 파일에 접근하게 해야 하는 서비스라면, 오래 보관할 애플리케이션 링크와 실제 다운로드 직전에 발급할 S3 링크를 구분하는 설계가 유용합니다. 이 글은 만료 원인을 좁히고 재발급 방식을 선택하는 기준을 정리합니다.

검토 기준: 2026-10-13, AWS 공식 문서의 Signature Version 4(SigV4) 기반 S3 객체 다운로드용 GET URL입니다. 문서 검토에 따른 의사결정 가이드이며 AWS 호출, SDK 코드 실행, 운영 설정 변경은 하지 않았습니다. 아래 시각은 설명용 가상 입력입니다. 업로드, CloudFront 서명 URL, 일회용 다운로드 구현은 범위에서 제외합니다.

1. URL에 적은 기간은 접근 성공 보장이 아닙니다

사전 서명 URL(presigned URL)은 특정 S3 요청을 실행할 수 있도록 서명 정보를 담은 주소입니다. URL의 X-Amz-Expires는 초 단위 정수이며 SigV4에서 1~604800초, 최대 7일 범위입니다. 이는 요청한 유효 기간이지 다른 제한을 없애는 값은 아닙니다. AWS의 SigV4 쿼리 매개변수 설명에서 단위와 범위를 확인할 수 있습니다.

  • 서명 자격 증명: 임시 자격 증명으로 발급했다면 그 자격 증명이 먼저 만료될 때 URL도 사용할 수 없게 됩니다. 역할 자격 증명을 모두 ‘1시간짜리’로 가정하지 말고 실제 발급 경로와 만료를 확인합니다. S3 유효 기간 안내가 이 제한을 설명합니다.
  • 적용 정책: s3:signatureAge 제한이 있으면 서명에 담긴 X-Amz-Date의 나이를 기준으로 더 일찍 거부할 수 있습니다. 단위는 밀리초여서 600000은 10분입니다. 이 조건은 유효 기간을 늘리지 않습니다. 실제 발급 시각과 서명 시각이 같다는 전제를 확인해야 합니다. AWS의 추가 제어 및 signatureAge 한계를 참고하세요.
  • 현재 접근 조건: 시간이 남았더라도 요청 시점의 권한과 네트워크 조건 등을 통과해야 합니다. URL을 발급한 서버의 네트워크와 사용자가 다운로드하는 네트워크를 혼동하지 않습니다. AWS의 요청 시점 평가 설명에 근거한 점검 항목입니다.

가상 사례: 10:00에 현재 시각으로 서명하고 URL 기간은 1시간, 자격 증명 만료는 10:20, 적용되는 signatureAge 제한은 10분이라고 가정합니다. 다른 거부 조건이 없어도 새 요청을 시작할 수 있는 시간의 상한은 약 10:10입니다. signatureAge 제한이 없다면 자격 증명의 10:20이 먼저 도달합니다. 문서 규칙을 적용한 사고 실험이며, 경계 시각의 정밀한 통과 여부나 실제 AWS 응답을 측정한 결과는 아닙니다.

2. 보관할 링크를 먼저 선택합니다

다음 두 방식은 모두 파일 바이트를 S3에서 직접 받는 구조입니다. 차이는 사용자가 보관하는 주소와 애플리케이션 권한을 다시 확인하는 시점입니다. 아래 비교는 AWS가 정한 API 규격이 아니라 앞의 제약을 바탕으로 정리한 설계 제안입니다.

발급한 S3 URL을 바로 전달하는 방식

  • 보관 대상: 짧게 사용할 S3 URL 자체입니다.
  • 앱 권한 확인: URL을 발급할 때 수행합니다. 이후 S3 요청은 서명과 S3 측 접근 조건으로 평가됩니다.
  • 실패 후 복구: 앱으로 돌아와 권한을 다시 확인하고 새 링크를 받습니다.
  • 선택할 조건: 사용자가 곧바로 내려받고, 만료 후 재발급을 안내해도 되는 임시 내보내기 등에 적합합니다.

앱의 다운로드 페이지를 보관하는 방식

  • 보관 대상: 앱의 파일 식별자를 포함한 다운로드 페이지 주소입니다. S3 URL은 오래 저장할 식별자로 쓰지 않습니다.
  • 앱 권한 확인: 페이지에서 실제 다운로드를 요청할 때 사용자와 해당 파일의 접근 권한을 확인합니다. 통과하면 그때 짧은 S3 URL을 발급합니다.
  • 실패 후 복구: 같은 앱 페이지에서 다시 확인하고 발급하므로 오래된 S3 URL을 계속 재사용하지 않습니다.
  • 선택할 조건: 며칠 뒤에도 찾아올 링크가 필요하고, 그때의 앱 권한으로 새 발급 여부를 판단해야 할 때 적합합니다.

두 번째 방식도 이미 전달한 S3 URL을 즉시 회수하지는 않습니다. 앱 권한을 철회하면 이후 발급은 막을 수 있지만, 기존 URL은 자체 유효 조건이 남아 있을 수 있습니다. 링크를 가진 사람이 사용할 수 있고 여러 번 요청할 수 있다는 점은 AWS FAQ에 명시돼 있습니다. 한 번만 사용하거나 매 요청마다 앱 권한을 검사해야 한다면 두 방식만으로 충족한다고 판단하지 말고 별도 전달·상태 관리 설계를 검토합니다.

3. 실패 증상별로 첫 점검을 다르게 합니다

  1. 설정한 기간보다 일찍 실패: URL 기간, 서명 자격 증명 만료, 적용된 signatureAge 제한을 나란히 확인합니다. 기간 값을 늘리는 것부터 시작하지 않습니다.
  2. 큰 파일을 받다가 재시작만 실패: 기존 연결과 새 HTTP 요청을 구분합니다. S3는 요청 시점에 만료를 검사하므로 만료 전에 시작한 다운로드가 계속되더라도, 만료 후 새로 시작한 요청은 실패할 수 있습니다. 완료 시각을 보장하는 타이머로 설명하지 않습니다.
  3. 시간이 남았는데 403: 만료로 단정하지 않습니다. S3 오류 코드, 현재 권한·명시적 거부, 요청자의 네트워크 조건을 함께 확인합니다.
  4. 새 URL도 바로 실패: 같은 원인을 가진 링크를 반복 발급하는지 봅니다. 서명과 실제 요청의 메서드·헤더·쿼리가 달라졌는지도 확인합니다.

요청 시점의 만료 검사와 대표 오류 원인은 S3 공식 문제 해결 안내에 정리돼 있습니다. 위 목록은 그 사실을 장애 분류 순서로 재구성한 것이며 모든 403의 원인을 판정하는 규칙은 아닙니다.

4. 재발급 API에 넣을 최소 경계

이 절은 앞서 확인한 제약을 백엔드에 적용하기 위한 설계 제안입니다. AWS가 정한 재발급 API 규격이나 의무 절차를 뜻하지 않습니다.

Django를 포함한 백엔드에서는 ‘사용자 확인 → 서버가 파일 식별자를 조회 → 그 파일의 접근 권한 확인 → 새 URL 발급’ 순서를 명확히 둡니다. 클라이언트가 보낸 임의의 버킷·객체 키를 그대로 서명하는 형태는 피합니다. 파일이 준비됐는지와 현재 발급 권한을 별도로 판단하고, 실제 자격 증명의 남은 수명을 모르면 URL 설정값만으로 정확한 접근 종료 시각을 보장하지 않습니다.

재발급 횟수와 재시도 종료 조건도 정합니다. 예를 들어 자동 재발급을 한 번 시도한 뒤 같은 오류가 계속되면 사용자에게 재로그인이나 오류 확인을 안내하는 식입니다. 이 횟수는 AWS 제한이 아니라 서비스가 선택할 운영 정책입니다. 권한 거부를 반복 재발급으로 덮지 않는 것이 목적입니다.

진단 기록에는 앱 요청 ID, 발급 시각, 요청한 기간, S3 오류 코드처럼 필요한 정보를 남기되 실제 서명 URL 전체를 남기지 않습니다. URL을 임시 접근 자격 증명처럼 취급하고 서명 또는 전체 쿼리 문자열을 마스킹하라는 AWS 로깅 권고도 확인합니다. 지원 티켓이나 오류 화면에 원본 URL을 붙이는 흐름까지 점검하는 것이 좋습니다.

5. 도입·보류·되돌리기 기준

도입: 기존에 허용된 테스트 환경에서 짧은 URL의 정상 요청, URL 기간 만료, 임시 자격 증명이 먼저 끝나는 경우, 만료 후 재시작을 각각 확인합니다. 앱 권한을 잃은 사용자의 재발급이 거부되는지, 자동 재시도가 종료되는지, 로그에 서명이 남지 않는지도 확인합니다. 이는 앞으로 수행할 검증 목록이며 이 글에서 실행한 테스트가 아닙니다.

보류: 필요한 보관 기간만 정했고 서명 주체·자격 증명 수명·적용 정책을 모르는 상태라면 ‘7일 링크 보장’을 먼저 출시하지 않습니다. 일회용 사용이나 즉시 회수가 필수인 요구도 별도 설계가 준비될 때까지 보류합니다. 만료를 피하려고 장기 자격 증명으로 교체하거나 거부 정책을 완화하는 것을 기본 해결책으로 삼지 않습니다.

되돌리기: 새 재발급 경로가 실패를 늘리면 미리 준비한 이전 다운로드 흐름으로 라우팅을 되돌립니다. 이때도 권한 검사는 유지하고, 이미 발급한 URL의 수명이 되돌리기 때문에 사라지는 것은 아님을 운영 문서에 남깁니다. 자격 증명 회수는 다른 요청에도 영향을 줄 수 있으므로 단일 링크의 취소 버튼처럼 다루지 않습니다.

마지막 질문: 사용자가 오래 보관해야 하는 것은 파일에 도달하는 앱 주소인가요, S3 URL 자체인가요? 접근 권한을 다시 판단해야 하는 시점은 언제인가요? 이 두 답을 먼저 정하면 URL 기간을 늘릴지, 다운로드 시점에 재발급할지, 별도 전달 구조가 필요한지 판단하기 쉬워집니다.

출처 확인일: 2026-10-13. 공식 문서의 개별 발행·수정일은 확인하지 못했으므로 최근 변경이나 신규 기능으로 소개하지 않습니다. 문서에 나온 제약과 이 글의 설계 제안을 구분해 작성했습니다.

댓글

댓글 쓰기