Mar 24, 2026

마지막 업데이트 Mar 30, 2026

AWS S3 AccessDenied: 먼저 볼 것들

S3 가 AccessDenied 를 반환할 때 진짜 문제는 대개 “S3 가 고장났다” 가 아닙니다. 보통은 policy evaluation 문제입니다. explicit deny, implicit deny, missing allow, bucket-level control, 또는 KMS 나 object ownership 같은 관련 권한에서 막히는 경우가 많습니다.

짧게 말하면 핵심은 이것입니다. 누가 S3 를 호출하고, 어떤 action 을 시도하고, 어느 policy layer 가 deny 하는지 먼저 그려야 합니다. 같은 403 Forbidden 도 여러 계층에서 나올 수 있습니다.

SDK 에러 문구보다 policy path 부터 본다

S3 authorization 은 path evaluation 문제에 가깝습니다.

즉 아래를 같이 봐야 합니다.

caller identity
요청 action
target bucket 또는 object ARN
IAM policy
bucket policy
public access block
encryption / ownership 관련 제어

이 경로가 선명해지기 전까지 AccessDenied 는 너무 모호합니다.

`AccessDenied` 는 보통 무엇을 뜻하나

실전에선 보통 아래 중 하나입니다.

명시적 allow 가 없다
explicit deny 가 allow 를 덮는다
bucket-level control 이 요청을 막는다
KMS 또는 object-specific permission 이 없다
caller identity 가 생각한 것과 다르다

그래서 SDK 에러 문구보다 caller identity 가 더 중요한 경우가 많습니다.

흔한 원인

1. principal 에 allow 권한이 실제로 없다

명시적인 allow 가 없으면 implicit deny 가 납니다.

특히 “S3 는 넓게 열려 있다” 고 생각했지만, 실제 bucket 또는 object action 이 정확히 grant 되지 않은 경우가 흔합니다.

2. policy 안에 explicit deny 가 있다

explicit deny 는 allow 보다 우선합니다. 그래서 가장 먼저 봐야 할 것 중 하나입니다.

예를 들면:

상위 제어 정책
restrictive bucket policy statement
의도치 않게 요청과 매칭되는 deny condition

3. bucket-level control 이 접근을 막는다

IAM 이 맞아 보여도 bucket policy 또는 public access block 이 요청을 막을 수 있습니다.

“role 에 S3 access 는 있는데요?” 문제가 자주 여기 숨어 있습니다.

4. 관련 권한이 빠져 있다

KMS permission, object ownership rule, operation-specific resource permission 이 빠져 있으면 단순 bucket access 만 봐서는 맞아 보여도 실제 요청은 실패할 수 있습니다.

5. 요청 scope 와 grant 한 ARN 이 미묘하게 다르다

팀이 거의 맞는 경로에 권한을 줬지만, 실제 failing request 가 접근하는 정확한 경로와는 다를 수 있습니다.

bucket-level 과 object-level 리소스는 특히 혼동하기 쉽습니다.

실전 점검 순서

1. caller identity 와 시도한 S3 action 을 찾는다

기초 단계입니다.

누가 호출하는지, 어떤 action 이 실패하는지 모르면 이후는 거의 추측입니다.

2. IAM allow 와 explicit deny 를 같이 본다

missing allow 와 overriding deny 둘 다 같은 증상을 만들 수 있습니다.

3. bucket policy 와 public access block 설정을 확인한다

local role permission 만 맞아서는 안 됩니다. bucket-level rule 이 다르면 여전히 막힙니다.

4. 필요하면 object-level 또는 KMS 관련 권한을 본다

bucket read 는 되는데 object 나 encryption 관련 action 만 실패하는 경우도 많습니다.

5. 요청 scope 와 실제 접근 ARN 을 비교한다

“거의 맞는” 권한 설정을 많이 잡아내는 마지막 단계입니다.

빠른 명령

aws sts get-caller-identity
aws s3api get-bucket-policy-status --bucket <bucket>
aws s3api head-object --bucket <bucket> --key <key>

누가 S3 를 호출하는지, bucket-level policy 가 관여하는지, 어떤 요청이 실제로 막히는지 확인하기 좋은 시작점입니다.

real caller identity, explicit deny 경로, failing action 이 실제로 기대한 bucket / object ARN 을 치는지 보세요.

deny path 를 찾은 뒤 무엇을 바꾸면 좋나

allow 가 빠졌다면

caller 가 필요한 exact action 을 exact resource path 에 대해 grant 해야 합니다.

explicit deny 가 있다면

정상 요청을 막는 deny condition 을 제거하거나 더 좁혀야 합니다.

bucket policy 가 blocker 라면

실제 원하는 access model 과 bucket-level rule 을 다시 맞춰야 합니다.

KMS 또는 ownership 이 blocker 라면

bucket access line 하나보다 관련 permission model 전체를 고쳐야 합니다.

caller identity 가 틀렸다면

policy 를 막 고치기보다 runtime identity 를 먼저 바로잡아야 합니다.

장애 중에 던져볼 질문

이 질문이 가장 유용한 경우가 많습니다.

정확히 어떤 principal 이 어떤 S3 action 을 어떤 resource 에 대해 시도하고 있고, policy chain 의 어느 지점에서 그 요청이 deny 되는가?

이 질문이 문제 공간을 빠르게 줄여 줍니다.

FAQ

Q. `AccessDenied` 면 무조건 IAM 문제인가

아닙니다. bucket policy, public access block, KMS, caller identity 실수도 같은 denial 을 만들 수 있습니다.

Q. 가장 빠른 첫 단계는 무엇인가

caller, action, explicit deny 존재 여부를 먼저 확인하는 것입니다.

Q. bucket policy 가 멀쩡해 보여도 실패할 수 있나

그렇습니다. IAM, KMS, object-level scope, 잘못된 caller identity 가 여전히 막을 수 있습니다.

Q. 이건 네트워크 이슈인가

대개는 아닙니다. AccessDenied 는 보통 authorization 또는 policy evaluation 문제입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.