두 개의 Amazon S3 버킷 간에 객체를 복사할 수 없는 이유는 무엇입니까?

7분 분량
0

Amazon Simple Storage Service(Amazon S3) 버킷에서 다른 버킷으로 객체를 복사하려고 하는데 작동하지 않습니다. 이 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

버킷 간에 객체를 복사할 때 발생하는 문제를 해결하려면 다음 내용을 확인하십시오.

  • 버킷 정책 및 AWS Identity and Access Management(IAM) 정책
  • 객체 소유권
  • AWS KMS(AWS Key Management Service) 암호화
  • Amazon S3 Glacier(Amazon Simple Storage Service Glacier) 스토리지 클래스
  • 버킷에 요청자 지불 활성화
  • AWS Organizations 서비스 제어 정책
  • Amazon S3의 Amazon Virtual Private Cloud(VPC) 종단점과 교차 리전 요청 문제

해결 방법

버킷 정책 및 IAM 정책

버킷 간에 객체를 복사하려면 올바른 권한이 구성되어 있는지 확인해야 합니다. 동일한 AWS 계정의 버킷 간에 객체를 복사하려면 IAM 정책을 사용하여 권한을 설정할 수 있습니다. 서로 다른 계정의 버킷 간에 객체를 복사하려면 관련 IAM 정책과 버킷 정책 모두에 대해 권한을 설정해야 합니다.

참고: 버킷 정책을 수정하는 방법에 대한 지침은 S3 버킷 정책을 추가하려면 어떻게 해야 합니까?를 참조하십시오. IAM 사용자의 권한을 수정하는 방법에 대한 지침은 IAM 사용자의 권한 변경을 참조하십시오. IAM 역할의 권한을 수정하는 방법에 대한 지침은 역할 수정을 참조하십시오.

다음 필수 권한을 확인합니다.

  • 최소한 IAM 자격 증명(사용자 또는 역할)에는 소스 버킷에서 s3:ListBucket 및 s3:GetObject 작업에 대한 권한이 있어야 합니다. 버킷이 동일한 계정에 있는 경우 IAM 자격 증명의 정책 또는 S3 버킷 정책을 사용하여 이러한 권한을 설정합니다. 버킷이 다른 계정에 있는 경우 버킷 정책과 IAM 자격 증명의 정책을 모두 사용하여 이러한 권한을 설정합니다.
  • 최소한 IAM 자격 증명에는 대상 버킷에서 s3:ListBucket 및 s3:PutObject 작업에 대한 권한이 있어야 합니다. 버킷이 동일한 계정에 있는 경우 IAM 자격 증명의 정책 또는 S3 버킷 정책을 사용하여 이러한 권한을 설정합니다. 버킷이 다른 계정에 있는 경우 버킷 정책과 IAM 자격 증명의 정책을 모두 사용하여 이러한 권한을 설정합니다.
  • 관련 버킷 정책 및 IAM 정책을 검토하여 필요한 권한과 충돌하는 명시적 deny 명령문이 없는지 확인합니다. 명시적 deny 명령문은 allow 문을 재정의합니다.
  • 특정 작업의 경우 IAM 자격 증명에 작업 내 필요한 모든 작업에 대한 권한이 있는지 확인합니다. 예를 들어 aws s3 cp 명령을 실행하려면 s3:GetObject 및 s3:PutObject에 대한 권한이 필요합니다. --recursive 옵션을 함께 aws s3 cp 명령을 실행하려면 s3:GetObject, s3:PutObject 및 s3:ListBucket에 대한 권한이 필요합니다. aws s3 sync 명령을 실행하려면 s3:GetObject, s3:PutObject 및 s3:ListBucket에 대한 권한이 필요합니다.
    참고: AssumeRole API 작업을 사용하여 Amazon S3에 액세스하는 경우 신뢰 관계가 올바르게 구성되었는지도 확인해야 합니다.
  • 버전별 작업의 경우 IAM 자격 증명에 버전별 작업에 대한 권한이 있는지 확인합니다. 예를 들어, 특정 버전의 객체를 복사하려면 s3:GetObjectVersion 뿐 아니라 s3:GetObject에 대한 권한도 필요합니다.
  • 객체 태그가 있는 객체를 복사하는 경우 IAM 자격 증명에 s3:GetObjectTagging 및 s3:PutObjectTagging 권한이 있어야 합니다. 원본 객체에 대해서는 s3:GetObjectTagging 권한이 있어야 하고 대상 버킷의 객체에 대해서는 s3:PutObjectTagging 권한이 있어야 합니다.
  • 관련 버킷 정책 및 IAM 정책을 검토하여 Resource 요소 경로가 올바른지 확인합니다. 버킷 수준 권한의 경우 Resource 요소가 버킷을 가리켜야 합니다. 객체 수준 권한의 경우 Resource 요소는 하나 이상의 객체를 가리켜야 합니다.

예를 들어 s3:ListBucket과 같은 버킷 수준 작업에 대한 정책 명령문에서는 다음과 같이 Resource 요소에서 버킷을 지정해야 합니다.

"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"

s3:GetObject 또는 s3:PutObject와 같은 객체 수준 작업에 대한 정책 명령문에서는 다음과 비슷하게 Resource 요소에서 하나 이상의 객체를 지정해야 합니다.

"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"

객체 소유권

버킷 정책에 올바른 권한이 있지만 아직도 버킷 간에 객체를 복사하는 데 문제가 있는 경우 객체를 소유하는 계정을 확인합니다. 버킷 정책은 버킷 소유자가 소유한 객체에만 적용됩니다. 다른 계정이 소유한 객체의 ACL(액세스 제어 목록)에 서로 충돌하는 권한이 있을 수도 있습니다. 참고: 객체 소유권 및 ACL 문제는 일반적으로 계정 간에 AWS 서비스 로그를 복사할 때 발생합니다. 서비스 로그의 예로는 AWS CloudTrail 로그와 Elastic Load Balancing 액세스 로그가 있습니다.

다음 단계에 따라 객체를 소유한 계정을 찾습니다.

1.    Amazon S3 콘솔을 엽니다.

2.    버킷 간에 복사할 수 없는 객체로 이동합니다.

3.    객체의 [권한] 탭을 선택합니다.

4.    [객체 소유자의 액세스 권한] 및 [다른 AWS 계정에 대한 액세스] 아래 값을 검토합니다.

  • 사용자 계정이 객체를 소유한 경우 [객체 소유자의 액세스 권한(Access for object owner)] 아래 [정식 ID(Canonical ID)]에 **(사용자의 AWS 계정)**이 포함됩니다.
  • 다른 계정이 객체를 소유하고 있고 사용자가 이 객체에 액세스할 수 있는 경우 다음이 적용됩니다.
    [객체 소유자의 액세스 권한(Access for object owner)] 아래 [정식 ID(Canonical ID)]에 **(외부 계정)**이 포함됩니다.
    [다른 AWS 계정의 액세스 권한(Access for other AWS accounts)] 아래 [정식 ID(Canonical ID)]에 **(사용자의 AWS 계정)**이 포함됩니다.
  • 다른 계정이 객체를 소유하고 있고 사용자가 이 객체에 액세스할 수 없는 경우 다음이 적용됩니다.
    [객체 소유자의 액세스 권한(Access for object owner)] 및 [다른 AWS 계정의 액세스 권한(Access for other AWS accounts)]에 대한 [정식 ID(Canonical ID)] 필드가 비어 있습니다.

버킷 간에 복사할 수 없는 객체를 다른 계정에서 소유한 경우 객체 소유자는 다음 중 하나를 수행할 수 있습니다.

  • 객체 소유자가 버킷 소유자에게 객체의 전체 제어 권한을 부여합니다. 버킷 소유자가 객체를 소유한 후에는 버킷 정책이 객체에 적용됩니다.
  • 객체 소유자는 객체의 소유권을 유지할 수 있지만, 사용 사례에 필요한 설정으로 ACL을 변경해야 합니다.

AWS KMS 암호화

객체가 AWS KMS 키를 사용하여 암호화된 경우 IAM 자격 증명이 키에 대한 올바른 권한을 가지고 있는지 확인합니다. IAM 자격 증명과 AWS KMS 키가 동일한 계정에 속하는 경우 키 정책이 필요한 AWS KMS 권한을 부여하는지 확인합니다.

IAM 자격 증명과 AWS KMS 키가 다른 계정에 속하는 경우 키 정책과 IAM 정책이 모두 필요한 권한을 부여하는지 확인합니다.

예를 들어 두 버킷 간에 객체를 복사하고 각 버킷에 고유한 KMS 키가 있는 경우 IAM 자격 증명으로 다음을 지정해야 합니다.

  • kms:Decrypt 권한(첫 번째 KMS 키 참조)
  • kms:GenerateDataKeykms:Decrypt 권한(두 번째 KMS 키 참조)

자세한 내용은 AWS KMS에서 키 정책 사용AWS Key Management Service의 작업, 리소스 및 조건 키를 참조하세요.

Amazon S3 Glacier 스토리지 클래스

Amazon S3 Glacier 스토리지 클래스에서는 객체를 복사할 수 없습니다. 객체를 복사하려면 먼저 Amazon S3 Glacier에서 객체를 복원해야 합니다. 관련 지침은 아카이브된 S3 객체를 복원하려면 어떻게 해야 합니까?를 참조하십시오.

버킷에 요청자 지불이 활성화됨

소스 또는 대상 버킷에 요청자 지불이 활성화되어 있고 다른 계정에서 버킷에 액세스하는 경우 요청을 확인합니다. 요청에 올바른 요청자 지불 파라미터가 포함되어 있는지 확인합니다.

  • AWS 명령줄 인터페이스(AWS CLI) 명령의 경우 --request-payer 옵션을 포함합니다.
    참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.
  • GET, HEAD 및 POST 요청의 경우 x-amz-request-payer : requester를 포함해야 합니다.
  • 서명된 URL의 경우 x-amz-request-payer=requester를 포함해야 합니다.

AWS Organizations 서비스 제어 정책

AWS Organizations을 사용하는 경우 서비스 제어 정책을 검토하여 Amazon S3에 대한 액세스가 허용되는지 확인하십시오.

예를 들어, 다음 정책은 명시적으로 액세스를 거부하므로 Amazon S3를 액세스하려고 할 때 403 금지 오류를 생성합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "S3:*",
            "Resource": "*"
        }
    ]
}

AWS Organizations의 기능에 대한 자세한 내용은 조직 내 모든 기능 활성화를 참조하십시오.

Amazon S3의 VPC 종단점과 교차 리전 요청 문제

Amazon S3의 VPC 엔드포인트는 현재 교차 리전 요청을 지원하지 않습니다. 예를 들어 리전 A에 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 있고 연결된 라우팅 테이블에 VPC 엔드포인트가 구성되어 있다고 가정합니다. Amazon EC2 인스턴스는 리전 B에서 리전 A의 버킷으로 객체를 복사할 수 없으며 대신 다음과 유사한 오류 메시지가 나타납니다.

"An error occurred (AccessDenied) when calling the CopyObject operation: VPC endpoints do not support cross-region requests"

이러한 교차 리전 요청 문제를 해결하려면 다음을 시도할 수 있습니다.

  • 라우팅 테이블에서 VPC 엔드포인트를 제거합니다. VPC 종단점을 제거할 경우, 반드시 인스턴스가 인터넷에 대신 연결할 수 있어야 합니다.
  • VPC 종단점을 사용하지 않는 다른 인스턴스에서 copy 명령을 실행합니다. 또는 리전 A나 리전 B에 있지 않은 인스턴스에서 copy 명령을 실행합니다.
  • VPC 종단점을 사용해야 하는 경우 GET 요청을 보내 소스 버킷에서 EC2 인스턴스로 객체를 복사합니다. 그런 다음, PUT 요청을 전송하여 객체를 EC2 인스턴스에서 대상 버킷으로 복사합니다.

관련 정보

객체 복사

Amazon S3의 403 Access Denied 오류를 해결하려면 어떻게 해야 합니까?

AWS 공식
AWS 공식업데이트됨 2년 전