Amazon S3의 액세스 거부(403 금지) 오류 문제 해결

중요

2024년 5월 13일에 버킷 소유자가 시작하지 않은 무단 요청에 대한 요금을 면제하기 위해 변경 사항을 배포하기 시작했습니다. 이 변경사항 배포가 완료된 후에는 개별 AWS 계정이나 AWS 조직 외부에서 요청이 시작된 경우 AccessDenied(HTTP 403 Forbidden) 오류를 반환하는 요청에 대해 버킷 소유자에게 요청 또는 대역폭 요금이 부과되지 않습니다. 청구되지 않는 HTTP 3XX 및 4XX 상태 코드의 전체 목록에 대한 자세한 내용은 Amazon S3 오류 응답에 대한 청구 섹션을 참조하세요. 이 청구 변경 사항은 애플리케이션 업데이트를 요구하지 않으며 모든 S3 버킷에 적용됩니다. 모든 AWS 리전에서 이 변경 사항의 배포가 완료되면 설명서가 업데이트됩니다.

다음 주제에서는 Amazon S3의 액세스 거부(403 금지) 오류의 가장 일반적인 원인을 다룹니다.

참고

Access Denied(HTTP 403 Forbidden)의 경우 S3는 요청이 버킷 소유자의 개인 AWS 계정이나 버킷 소유자의 AWS 조직 외부에서 시작된 경우 버킷 소유자에게 요금을 청구하지 않습니다.

참고

권한 문제를 해결하려는 경우 버킷 정책 및 IAM 정책 섹션부터 시작하여 권한 확인을 위한 팁의 안내를 따르세요.

버킷 정책 및 IAM 정책

버킷 수준 작업

버킷 정책이 없는 경우 버킷은 버킷 소유 계정의 모든 AWS Identity and Access Management(IAM) 아이덴티티에서 오는 요청을 암시적으로 허용합니다. 또한 버킷은 다른 계정의 다른 IAM 아이덴티티의 요청과 익명(서명되지 않은) 요청을 암시적으로 거부합니다. 그러나 IAM 사용자 정책이 없는 경우 요청자(루트 사용자가 아닌 경우)의 요청이 암시적으로 거부됩니다. 이 평가 논리에 대한 자세한 내용은 IAM 사용 설명서에서 계정 내에서 요청 허용 여부 결정을 참조하세요.

객체 수준 작업

버킷 소유 계정에서 객체를 소유한 경우 버킷 정책 및 IAM 사용자 정책은 객체 수준 작업에 대해 버킷 수준 작업과 동일한 방식으로 작동합니다. 예를 들어, 버킷 정책이 없는 경우 버킷은 버킷 소유 계정의 모든 IAM 아이덴티티에서 오는 객체 요청을 암시적으로 허용합니다. 또한 버킷은 다른 계정의 다른 IAM 아이덴티티의 객체 요청과 익명(서명되지 않은) 요청을 암시적으로 거부합니다. 그러나 IAM 사용자 정책이 없는 경우 요청자(루트 사용자가 아닌 경우)의 객체 요청이 암시적으로 거부됩니다.

외부 계정에서 객체를 소유한 경우 객체 액세스 제어 목록(ACL)을 통해서만 객체에 대한 액세스 권한을 부여할 수 있습니다. 여전히 버킷 정책과 IAM 사용자 정책을 사용하여 객체 요청을 거부할 수 있습니다.

따라서 버킷 정책 또는 IAM 사용자 정책으로 인해 액세스 거부(403 금지) 오류가 발생하지 않게 하려면 다음 요구 사항을 충족해야 합니다.

• 동일 계정 액세스의 경우 버킷 정책 또는 IAM 사용자 정책 내에 권한을 부여하려는 요청자에 대한 명시적인 Deny 명령문이 없어야 합니다. 버킷 정책과 IAM 사용자 정책만 사용하여 권한을 부여하려면 이러한 정책 중 하나에 명시적인 Allow 명령문이 하나 이상 있어야 합니다.

• 크로스스 계정 액세스의 경우 버킷 정책 또는 IAM 사용자 정책 내에 권한을 부여하려는 요청자에 대한 명시적인 Deny 명령문이 없어야 합니다. 버킷 정책과 IAM 사용자 정책만 사용하여 크로스 계정 권한을 부여하려면 요청자의 버킷 정책과 IAM 사용자 정책 모두에 명시적인 Allow 명령문을 포함해야 합니다.

참고

버킷 정책의 Allow 명령문은 동일한 버킷 소유 계정이 소유한 객체에만 적용됩니다. 하지만 버킷 정책의 Deny 명령문은 객체 소유권과 관계없이 모든 객체에 적용됩니다.

버킷 정책을 검토 또는 편집하는 방법

참고

버킷 정책을 보거나 편집하려면 s3:GetBucketPolicy 권한이 있어야 합니다.

1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.

2. 왼쪽 탐색 창에서 버킷(Buckets)을 선택합니다.

3. 버킷 목록에서 버킷 정책을 보거나 편집할 버킷의 이름을 선택합니다.

4. 권한 탭을 선택합니다.

5. 버킷 정책에서 편집을 선택합니다. 버킷 정책 편집 페이지가 나타납니다.

AWS Command Line Interface(AWS CLI)를 사용하여 버킷 정책을 검토하거나 편집하려면 get-bucket-policy 명령을 사용하세요.

참고

잘못된 버킷 정책으로 인해 버킷이 잠긴 경우 루트 사용자 보안 인증 정보를 사용하여 AWS Management Console 버킷에 로그인하세요. 버킷에 다시 액세스하려면 루트 사용자 보안 인증 정보를 사용하여 버킷 정책을 삭제해야 합니다.

권한 확인을 위한 팁

요청자에게 Amazon S3 작업을 수행할 수 있는 적절한 권한이 있는지 확인하려면 다음을 시도해 보세요.

• 요청자를 식별합니다. 서명되지 않은 요청인 경우 IAM 사용자 정책이 없는 익명 요청입니다. 미리 서명된 URL을 사용하는 요청인 경우 사용자 정책은 요청에 서명한 IAM 사용자 또는 역할에 대한 정책과 동일합니다.

• 올바른 IAM 사용자 또는 역할을 사용하고 있는지 확인합니다. AWS Management Console 오른쪽 상단을 확인하거나 aws sts get-caller-identity 명령을 사용하여 IAM 사용자 또는 역할을 확인할 수 있습니다.

• 요청을 수행하는 IAM 사용자 또는 역할과 관련된 IAM 정책을 확인합니다. 다음 방법 중 하나를 사용할 수 있습니다.

  • IAM 정책 시뮬레이터로 IAM 정책을 테스트합니다.

  • 다양한 IAM 정책 유형을 검토합니다.

• 필요한 경우 IAM 사용자 정책을 편집합니다.

• 액세스를 명시적으로 거부하거나 허용하는 다음 정책의 예시를 검토합니다.

  • 명시적 허용 IAM 정책: IAM: 프로그래밍 방식rhk 콘솔에서 여러 서비스에 대한 액세스 허용 및 거부

  • 명시적 허용 버킷 정책: 여러 계정에 객체를 업로드하거나 퍼블릭 액세스에 객체 ACL을 퍼블릭 설정할 수 있는 권한 부여

  • 명시적 거부 IAM 사용자 정책: AWS: 요청된 AWS 리전에 따라 AWS에 대한 액세스 거부

  • 명시적 거부 버킷 정책: 버킷에 작성되는 모든 객체에 SSE-KMS 요구

Amazon S3 ACL 설정

ACL 설정을 확인할 때는 먼저 객체 소유권 설정을 검토하여 버킷에 ACL이 활성화되어 있는지 확인하세요. ACL 권한은 권한을 부여하는 용도로만 사용할 수 있으며 요청을 거부하는 데는 사용할 수 없다는 점을 유의하시기 바랍니다. 또한 ACL은 버킷 정책 또는 IAM 사용자 정책의 명시적 거부에 의해 거부된 요청자에게 액세스 권한을 부여하는 데 사용할 수 없습니다.

객체 소유권 설정이 버킷 소유자 적용으로 설정됨

버킷 소유자 적용 설정을 활성화하면 ACL 설정으로 인해 액세스 거부(403 금지) 오류가 발생할 가능성은 거의 없습니다. 이 설정은 버킷과 객체에 적용되는 모든 ACL을 비활성화하기 때문입니다. 버킷 소유자 적용은 Amazon S3 버킷의 기본 및 권장 설정입니다.

객체 소유권 설정이 버킷 소유자 선호 또는 객체 라이터로 설정됨

ACL 권한은 버킷 소유자 선호 설정 또는 객체 라이터 설정에서도 여전히 유효합니다. ACL에는 버킷 ACL과 객체 ACL이라는 두 가지 종류가 있습니다. 두 ACL 유형의 차이점에 대해서는 ACL 권한 및 액세스 정책 권한 매핑을 참조하세요.

거부된 요청의 작업에 따라 버킷 또는 객체에 대한 ACL 권한을 확인하세요.

• Amazon S3에서 LIST, PUT 객체, GetBucketAcl 또는 PutBucketAcl 요청을 거부한 경우 버킷에 대한 ACL 권한을 검토하세요.

  참고

  버킷 ACL 설정으로는 GET 객체 권한을 부여할 수 없습니다.

• Amazon S3가 S3 객체에 대한 GET 요청 또는 PutObjectAcl 요청을 거부한 경우 해당 객체에 대한 ACL 권한을 검토하세요.

  중요

  객체를 소유한 계정이 버킷을 소유한 계정과 다른 경우 객체에 대한 액세스는 버킷 정책으로 제어되지 않습니다.

크로스 계정 객체 소유권인 경우 GET 객체 요청으로 인한 액세스 거부(403 금지) 오류 문제 해결

버킷의 객체 소유권 설정을 검토하여 객체 소유자를 파악합니다. 객체 ACL에 액세스할 수 있는 경우 객체 소유자의 계정도 확인할 수 있습니다. (객체 소유자의 계정을 보려면 Amazon S3 콘솔에서 객체 ACL 설정을 검토하세요.) 또는 객체 소유자의 정식 ID를 찾도록 GetObjectAcl 요청을 수행하여 객체 소유자 계정을 확인할 수도 있습니다. 기본적으로 ACL은 GET 요청에 대한 명시적 허용 권한을 객체 소유자의 계정에 부여합니다.

객체 소유자가 버킷 소유자와 다르다는 것을 확인한 후 사용 사례 및 액세스 수준에 따라 다음 방법 중 하나를 선택하여 액세스 거부(403 금지) 오류를 해결하는 데 도움을 받으세요.

• ACL 비활성화(권장) - 이 방법은 모든 객체에 적용되며 버킷 소유자가 수행할 수 있습니다. 이 방법은 버킷 소유자에게 버킷의 모든 객체에 대한 소유권과 완전한 제어 권한을 자동으로 부여합니다. 이 방법을 구현하기 전에 ACL 사용 중지를 위한 사전 조건을 확인하세요. 버킷을 버킷 소유자 적용(권장) 모드로 설정하는 방법에 대한 자세한 내용은 기존 버킷에 대한 객체 소유권 설정을 참조하세요.

  중요

  액세스 거부(403 금지) 오류를 방지하려면 ACL을 비활성화하기 전에 반드시 ACL 권한을 버킷 정책으로 마이그레이션해야 합니다. 자세한 내용은 ACL 권한에서 마이그레이션하기 위한 버킷 정책 예시를 참조하세요.

• 객체 소유자를 버킷 소유자로 변경 - 이 방법은 개별 객체에 적용할 수 있지만 객체 소유자(또는 적절한 권한이 있는 사용자)만 객체 소유권을 변경할 수 있습니다. 추가 PUT 비용이 적용될 수 있습니다. (자세한 내용은 Amazon S3 요금을 참조하세요.) 이 방법은 버킷 소유자에게 객체의 전체 소유권을 부여하여 버킷 소유자가 버킷 정책을 통해 객체에 대한 액세스를 제어할 수 있도록 합니다.

  객체 소유권을 변경하려면 다음 중 하나를 수행합니다.

  • 사용자(버킷 소유자)는 객체를 다시 버킷에 복사할 수 있습니다.

  • 사용자는 버킷의 객체 소유권 설정을 버킷 소유자 선호로 변경할 수 있습니다. 버전 관리가 비활성화된 경우 버킷의 객체를 덮어씁니다. 버전 관리가 활성화된 경우 동일한 객체의 중복 버전이 버킷에 표시되며, 버킷 소유자는 만료되도록 수명 주기 규칙을 설정할 수 있습니다. 객체 소유권 설정을 변경하는 자세한 방법은 기존 버킷에 대한 객체 소유권 설정 섹션을 참조하세요.

    참고

    객체 소유권 설정을 버킷 소유자 선호로 업데이트하면 해당 설정은 버킷에 업로드되는 신규 객체에만 적용됩니다.

  • 객체 소유자가 bucket-owner-full-control 미리 제공된 객체 ACL을 사용하여 객체를 다시 업로드하도록 할 수 있습니다.

  참고

  크로스 계정 업로드의 경우 버킷 정책에 bucket-owner-full-control 미리 제공된 객체 ACL을 요구할 수도 있습니다. 예시 버킷 정책은 버킷 소유자가 완벽하게 제어할 수 있도록 보증하면서 객체에 업로드하는 크로스 계정 권한 부여를 참조하세요.

• 객체 라이터를 객체 소유자로 유지 - 이 방법을 사용하면 객체 소유자를 변경하지 않지만 객체에 개별적으로 액세스 권한을 부여할 수 있습니다. 객체에 대한 액세스 권한을 부여하려면 객체에 대한 PutObjectAcl 권한이 있어야 합니다. 그런 다음 액세스 거부(403 금지) 오류를 수정하려면 요청자를 객체 ACL에 있는 객체에 액세스할 수 있는 피부여자로 추가하세요. 자세한 내용은 ACL 구성 단원을 참조하십시오.

S3 퍼블릭 액세스 차단 설정

실패한 요청에 퍼블릭 액세스 또는 퍼블릭 정책이 포함된 경우 계정, 버킷 또는 S3 액세스 포인트에서 S3 퍼블릭 액세스 차단 설정을 확인하세요. 2023년 4월부터 모든 퍼블릭 액세스 차단 설정이 새 버킷에 기본값으로 활성화되어 있습니다. Amazon S3가 '퍼블릭'을 어떻게 정의하는지에 대한 자세한 내용은 "퍼블릭"의 의미 섹션을 참조하세요.

설정이 TRUE인 경우 퍼블릭 액세스 차단 설정은 ACL, 버킷 정책 및 IAM 사용자 정책에서 허용하는 권한을 재정의하는 명시적 거부 정책으로 작동합니다. 퍼블릭 액세스 차단 설정이 요청을 거부하는지 확인하려면 다음 시나리오를 검토하세요.

• 지정된 액세스 제어 목록(ACL)이 퍼블릭이면 BlockPublicAcls 설정이 PutBucketAcl 및 PutObjectACL 호출을 거부합니다.

• 요청에 퍼블릭 ACL이 포함된 경우 BlockPublicAcls 설정이 PutObject 호출을 거부합니다.

• BlockPublicAcls 설정이 계정에 적용되고 요청에 퍼블릭 ACL이 포함된 경우, 퍼블릭 ACL이 포함된 모든 CreateBucket 호출이 실패합니다.

• 퍼블릭 ACL에서만 요청 권한을 부여한 경우 IgnorePublicAcls 설정이 요청을 거부합니다.

• 지정된 버킷 정책에서 퍼블릭 액세스를 허용하는 경우 BlockPublicPolicy 설정이 PutBucketPolicy 호출을 거부합니다.

• BlockPublicPolicy 설정이 액세스 포인트에 적용된 경우 퍼블릭 정책을 지정하고 액세스 포인트를 통해 이루어진 모든 PutAccessPointPolicy 및 PutBucketPolicy 호출이 실패합니다.

• 액세스 포인트 또는 버킷에 퍼블릭 정책이 있는 경우 RestrictPublicBuckets 설정이 AWS 서비스 보안 주체를 제외한 모든 크로스 계정 호출을 거부합니다. 또한 이 설정은 모든 익명(또는 서명되지 않은) 호출을 거부합니다.

퍼블릭 액세스 차단 설정 구성을 검토하고 업데이트하려면 S3 버킷에 대한 퍼블릭 액세스 차단 설정 구성 섹션을 참조하세요.

Amazon S3 암호화 설정

Amazon S3는 버킷에 대한 서버 측 암호화를 지원합니다. 서버 측 암호화는 데이터를 받는 애플리케이션 또는 서비스에 의해 해당 대상에서 데이터를 암호화하는 것입니다. Amazon S3에서 AWS 데이터 센터의 디스크에 데이터를 쓰면서 객체 수준에서 데이터를 암호화하고 사용자가 해당 데이터에 액세스할 때 자동으로 암호를 해독합니다.

이제 기본적으로 Amazon S3가 Amazon S3 관리형 키(SSE-S3)를 사용한 서버 측 암호화를 Amazon S3 내 모든 버킷 암호화의 기본 수준으로 적용합니다. 또한 Amazon S3에서는 객체를 업로드할 때 서버 측 암호화 방법을 지정할 수 있습니다.

버킷의 서버측 암호화 상태 및 암호화 설정을 검토하는 방법

1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.

2. 왼쪽 탐색 창에서 버킷(Buckets)을 선택합니다.

3. 버킷 목록에서 암호화 설정을 확인할 버킷을 선택합니다.

4. 속성(Properties) 탭을 선택합니다.

5. 기본 암호화 섹션까지 아래로 스크롤하여 암호화 유형 설정을 확인합니다.

AWS CLI를 사용하여 암호화 설정을 확인하려면 get-bucket-encryption 명령을 사용합니다.

객체의 암호화 상태를 확인하는 방법

1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.

2. 왼쪽 탐색 창에서 버킷(Buckets)을 선택합니다.

3. 버킷 목록에서 객체가 포함된 버킷의 이름을 선택합니다.

4. 객체 목록에서 암호화를 추가하거나 변경할 객체의 이름을 선택합니다.

   객체 세부 정보 페이지가 나타납니다.

5. 서버 측 암호화 설정 섹션까지 아래로 스크롤하여 객체의 서버 측 암호화 설정을 확인합니다.

AWS CLI를 사용하여 객체 암호화 상태를 확인하려면 head-object 명령을 사용합니다.

암호화 및 권한 요구 사항

Amazon S3에서는 3가지 유형의 서버 측 암호화를 지원합니다.

• Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)

• AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화

• 고객 제공 키를 사용한 서버 측 암호화(SSE-C)

암호화 설정에 따라 다음 권한 요구 사항을 충족하는지 확인하세요.

• SSE-S3 - 추가 권한이 필요하지 않습니다.

• SSE-KMS(고객 관리형 키 사용) - 객체를 업로드하려면 AWS KMS key에 대한 kms:GenerateDataKey 권한이 필요합니다. 객체를 다운로드하고 객체의 멀티파트 업로드를 수행하려면 KMS 키에 대한 kms:Decrypt 권한이 필요합니다.

• SSE-KMS(AWS 관리형 키 사용) - 요청자는 aws/s3 KMS 키를 소유한 계정과 동일한 계정을 사용해야 합니다. 또한 요청자는 객체에 액세스할 수 있는 올바른 Amazon S3 권한을 가지고 있어야 합니다.

• SSE-C(고객 제공 키 사용) - 추가 권한이 필요하지 않습니다. 버킷의 객체에 고객 제공 암호화 키를 사용하여 서버 측 암호화를 요구하고 제한하도록 버킷 정책을 구성할 수 있습니다.

객체가 고객 관리형 키로 암호화된 경우 KMS 키 정책에서 kms:GenerateDataKey 또는 kms:Decrypt 작업을 수행하도록 허용해야 합니다. KMS 키 정책을 확인하는 방법에 대한 지침은 AWS Key Management Service 개발자 안내서의 키 정책 보기를 참조하세요.

S3 객체 잠금 설정

버킷에 S3 객체 잠금이 활성화되어 있고 객체가 보존 기간 또는 법적 보존으로 보호되는 경우 객체를 삭제하려고 하면 Amazon S3에서 액세스 거부(403 금지) 오류를 반환합니다.

버킷에 객체 잠금이 활성화되어 있는지 확인하는 방법

1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.

2. 왼쪽 탐색 창에서 버킷(Buckets)을 선택합니다.

3. 버킷 목록에서 검토하려는 버킷의 이름을 선택합니다.

4. 속성(Properties) 탭을 선택합니다.

5. 객체 잠금 섹션까지 아래로 스크롤합니다. 객체 잠금 설정이 활성화됨인지, 비활성화됨인지 확인합니다.

객체가 보존 기간 또는 법적 보존으로 보호되는지 확인하려면 해당 객체의 잠금 정보를 확인하세요.

객체가 보존 기간 또는 법적 보존으로 보호되는 경우 다음을 확인하세요.

• 객체 버전이 규정 준수 보존 모드로 보호되는 경우 영구적으로 삭제할 방법이 없습니다. 루트 사용자를 포함하여 요청자가 영구적 DELETE 요청을 수행하면 액세스 거부(403 금지) 오류가 발생합니다. 또한 규정 준수 보존 모드로 보호되는 객체에 대해 DELETE 요청을 제출하면 Amazon S3는 해당 객체에 삭제 마커를 생성한다는 점을 유의하시기 바랍니다.

• 객체 버전이 거버넌스 보존 모드로 보호되고 사용자에게 s3:BypassGovernanceRetention 권한이 있는 경우 보호를 우회하고 버전을 영구적으로 삭제할 수 있습니다. 자세한 내용은 거버넌스 모드 우회를 참조하세요.

• 객체 버전이 법적 보존으로 보호되는 경우 영구 DELETE 요청으로 인해 액세스 거부(403 금지) 오류가 발생할 수 있습니다. 객체 버전을 영구적으로 삭제하려면 객체 버전에 대한 법적 보존를 제거해야 합니다. 법적 보존을 제거하려면 s3:PutObjectLegalHold 권한이 있어야 합니다. 보존을 제거하는 방법에 대한 자세한 내용은 S3 객체 잠금 구성 섹션을 참조하세요.

VPC 엔드포인트 정책

Virtual Private Cloud(VPC) 엔드포인트를 사용하여 Amazon S3에 액세스하는 경우 VPC 엔드포인트가 Amazon S3 리소스에 액세스하는 것을 차단하지 않는지 확인하세요. 기본적으로 VPC 엔드포인트 정책은 Amazon S3에 대한 모든 요청을 허용합니다. 특정 요청을 제한하도록 VPC 엔드포인트 정책을 구성할 수도 있습니다. VPC 엔드포인트 정책을 확인하는 방법에 대한 자세한 내용은 AWS PrivateLink 가이드의 엔드포인트 정책을 사용하여 VPC 엔드포인트에 대한 액세스 제어를 참조하세요.

AWS Organizations 정책

AWS 계정이 조직에 속한 경우 AWS Organizations 정책에 따라 Amazon S3 리소스에 액세스하지 못할 수 있습니다. 기본적으로 AWS Organizations 정책은 Amazon S3에 대한 요청을 차단하지 않습니다. 하지만 AWS Organizations 정책이 S3 버킷에 대한 액세스를 차단하도록 구성되지 않았는지 확인하세요. AWS Organizations 정책을 확인하는 방법에 대한 지침은 AWS Organizations 사용 설명서의 모든 정책 나열을 참조하세요.

액세스 포인트 설정

Amazon S3 액세스 포인트를 통해 요청하는 동안 액세스 거부(403 금지) 오류가 발생하는 경우 다음을 확인해야 할 수 있습니다.

• 액세스 포인트의 구성

• 액세스 포인트에 사용되는 IAM 사용자 정책

• 크로스 계정 액세스 포인트를 관리하거나 구성하는 데 사용되는 버킷 정책

액세스 포인트 구성 및 정책

• 액세스 포인트를 만들 때 인터넷 또는 VPC를 네트워크 오리진으로 지정할 수 있습니다. 네트워크 오리진이 VPC로만 설정된 경우 Amazon S3는 지정된 VPC에서 시작되지 않은 액세스 포인트에 대한 모든 요청을 거부합니다. 액세스 포인트의 네트워크 오리진을 확인하려면 Virtual Private Cloud(VPC)로 제한된 액세스 포인트 생성 섹션을 참조하세요.

• 액세스 포인트를 사용하여 사용자 지정 퍼블릭 액세스 차단 설정을 구성할 수도 있습니다. 이 설정은 버킷 또는 계정 수준의 퍼블릭 액세스 차단 설정과 유사하게 작동합니다. 사용자 지정 퍼블릭 액세스 차단 설정을 확인하려면 액세스 포인트에 대한 퍼블릭 액세스 관리 섹션을 참조하세요.

• 액세스 포인트를 사용하여 Amazon S3에 성공적으로 요청하려면 요청자에게 필요한 IAM 권한이 있는지 확인하세요. 자세한 내용은 액세스 포인트를 사용하도록 IAM 정책 구성 단원을 참조하십시오.

• 요청에 크로스 계정 액세스 포인트가 포함된 경우, 버킷 소유자가 액세스 포인트에서 온 요청을 승인하도록 버킷 정책을 업데이트했는지 확인하세요. 자세한 내용은 크로스 계정 액세스 포인트에 대한 권한 부여 단원을 참조하십시오.

이 주제의 모든 항목을 확인한 후에도 액세스 거부(403 금지) 오류가 계속 발생하는 경우 Amazon S3 요청 ID를 검색하고 AWS Support에 추가 지침을 요청하세요.