AWS S3 403 AccessDenied 해결 순서: IAM·버킷 정책·KMS·공개 차단 점검

그림: 403 오류에서는 권한을 무작정 넓히기보다 요청자·작업·리소스·거부 정책을 먼저 특정해야 합니다.

S3에서 AccessDenied 또는 HTTP 403을 받았을 때 버킷을 공개로 바꾸는 것은 해결책이 아닙니다. 같은 403이라도 요청한 IAM 주체, 작업, 객체 경로, 버킷 정책, 공개 접근 차단, KMS 키 정책에 따라 원인이 다릅니다. 아래 순서는 권한을 불필요하게 넓히지 않고 원인을 좁히는 방법입니다.

1. 실제 요청자·작업·리소스를 기록한다

먼저 실패한 명령과 전체 오류 메시지에서 누가 어떤 작업을 어떤 ARN에 요청했는지 확인하세요. 로컬 프로파일, 서버의 인스턴스 역할, 컨테이너의 태스크 역할이 서로 다를 수 있습니다. CLI에서 아래 명령으로 현재 사용 중인 주체를 확인할 수 있습니다. 공개 문서나 문의 글에 결과를 붙일 때는 계정 ID와 민감한 경로를 가리세요.

aws sts get-caller-identity
aws s3api head-object --bucket BUCKET_NAME --key path/to/object

head-object의 실패만으로 객체가 존재하는지까지 단정하면 안 됩니다. 권한에 따라 존재 여부가 드러나지 않도록 응답이 달라질 수 있습니다. 작업 이름이 GetObject인지 ListBucket인지도 구분하세요. 버킷 목록과 객체 읽기는 서로 다른 권한입니다.

2. 오류 문구에서 명시적 거부와 허용 누락을 구분한다

AWS의 S3 오류 설명에 정책 유형이 표시된다면 먼저 그 정책을 확인하세요. explicit deny는 해당 조건의 거부문이 있다는 뜻이고, no ... policy allows는 필요한 허용문이 없다는 뜻입니다. 같은 계정·조직 안의 요청은 상세 문구가 나올 수 있지만, 조직 밖 계정 간 요청은 일반적인 Access Denied만 보일 수 있습니다. 따라서 오류 메시지가 간단하다고 IAM 정책만 문제라고 판단하면 안 됩니다.

관찰 결과	먼저 확인할 항목	흔한 실수
GetObject만 실패	객체 ARN, 버킷 정책, KMS 권한	버킷 ARN에만 권한 부여
ListBucket만 실패	버킷 ARN과 prefix 조건	객체 ARN에만 권한 부여
브라우저 공개 URL만 실패	Block Public Access, CloudFront 접근 방식	문제 해결을 위해 버킷 전체 공개
특정 네트워크에서만 실패	VPC 엔드포인트 정책과 조건	IAM 허용문만 반복 수정
SSE-KMS 객체만 실패	KMS 키 정책·IAM·키 지역	S3 권한만 확대

3. IAM·버킷 정책·조직 정책을 함께 본다

IAM 사용자나 역할 정책의 Allow가 있어도 버킷 정책, 권한 경계, 조직 SCP·RCP, VPC 엔드포인트 정책의 거부가 우선할 수 있습니다. 필요한 작업과 리소스 ARN을 정확히 대조하세요. 예를 들어 객체 읽기는 arn:aws:s3:::BUCKET_NAME/path/to/object 형태의 객체 리소스에 대한 권한을 요구합니다. 임시로 s3:*와 Resource: *를 주는 방식은 원인 분석을 흐리고 보안 위험을 키웁니다.

4. 공개 접근 차단과 암호화 조건을 분리해서 확인한다

웹사이트 이미지처럼 공개 접근이 필요한 경우에도 버킷을 무조건 공개하지 마세요. S3 Block Public Access는 계정·버킷·액세스 포인트 등 여러 수준에서 적용되며, 가장 제한적인 조합이 작동합니다. CloudFront를 쓴다면 배포의 원본 접근 설정을 먼저 확인하세요. 반대로 내부 애플리케이션의 비공개 객체라면 공개 설정이 아니라 적절한 IAM 역할과 버킷 정책이 답입니다. SSE-KMS를 사용하는 객체는 해당 KMS 키에 대한 권한도 점검해야 합니다.

5. 재현과 수정은 최소 권한으로 검증한다

1. 실패한 주체와 API 작업, 대상 ARN, 시간과 요청 ID를 기록합니다.
2. 같은 자격 증명으로 같은 요청을 재현합니다.
3. 오류 문구가 가리키는 정책을 먼저 확인합니다.
4. 버킷·객체 ARN, 조건식, 공개 차단, KMS 정책을 순서대로 대조합니다.
5. 필요한 범위의 허용문만 수정한 뒤 원래 요청을 다시 실행합니다.
6. 다른 경로나 역할에 원치 않는 접근이 열리지 않았는지 확인합니다.

접근 오류와 별도로 저장 비용을 검토 중이라면 S3 스토리지 클래스 비교 가이드를 참고하세요. 스토리지 클래스 변경은 403 권한 오류를 해결하지 않습니다.

6. 자주 묻는 질문

Q. 403이면 객체가 반드시 존재하나요?
아닙니다. 권한 구성에 따라 존재 여부를 알 수 없는 응답이 돌아올 수 있으므로 객체 경로와 목록 권한을 별도로 확인해야 합니다.

Q. 버킷 정책에 Allow가 있으면 IAM 정책은 필요 없나요?
계정 관계와 다른 정책의 거부 여부에 따라 달라집니다. AWS의 정책 평가와 오류 문구를 기준으로 판단하세요.

Q. 공개 접근 차단을 꺼야 이미지를 보여줄 수 있나요?
반드시 그렇지는 않습니다. CloudFront와 비공개 S3 원본을 연결하는 방식 등 더 제한적인 구성을 먼저 검토하세요.

공식 자료: AWS S3 403 문제 해결 · S3 Block Public Access · S3 API별 필요 권한 (확인일: 2026-09-24)