# 객체 메타데이터 작업
Amazon S3에는 *시스템 정의 메타데이터*와 *사용자 정의 메타데이터*라는 두 가지 종류의 객체 메타데이터가 있습니다. 시스템 정의 메타데이터에는 객체의 생성 날짜, 크기 및 스토리지 클래스와 같은 메타데이터가 포함됩니다. 사용자 정의 메타데이터는 객체를 업로드할 때 설정할 수 있는 메타데이터입니다. 이 사용자 정의 메타데이터는 이름-값 페어의 집합입니다. 자세한 내용은 [시스템 정의 객체 메타데이터](#SysMetadata) 및 [사용자 정의 객체 메타데이터](#UserMetadata)(을)를 참조하세요.
객체를 만들 때 Amazon S3 버킷 내 객체를 고유하게 식별하는 *객체 키*(또는 *키 이름*)을 지정합니다. 자세한 내용은 [Amazon S3 객체 이름 지정](object-keys.md) 섹션을 참조하세요. 또한 객체를 업로드할 때 Amazon S3에서 [사용자 정의 메타데이터](#UserMetadata)를 설정할 수 있습니다.
객체를 업로드한 후에는 이 사용자 정의 메타데이터를 수정할 수 없습니다. 이 메타데이터를 수정할 수 있는 유일한 방법은 객체 복사본을 만든 후 메타데이터를 설정하는 것입니다. Amazon S3 콘솔을 사용한 메타데이터 편집에 대한 자세한 내용은 [Amazon S3 콘솔에서 객체 메타데이터 편집](add-object-metadata.md) 섹션을 참조하세요.
**S3 메타데이터를 사용하여 메타데이터 쿼리 및 데이터 검색 가속화**
S3 객체에 대한 메타데이터를 쉽게 찾고 저장하고 쿼리하려면 S3 메타데이터를 사용할 수 있습니다. S3 메타데이터를 사용하면 비즈니스 분석, 콘텐츠 검색, 인공 지능 및 기계 학습(AI/ML) 모델 훈련 등에 사용할 데이터를 빠르게 준비할 수 있습니다.
S3 메타데이터는 범용 버킷의 객체에 대한 메타데이터를 자동으로 캡처하고, 쿼리할 수 있는 읽기 전용 완전관리형 Apache Iceberg 테이블에 저장하여 데이터 검색을 가속화합니다. 이러한 읽기 전용 테이블을 *메타데이터 테이블*이라고 합니다. 객체가 범용 버킷에 추가, 업데이트 및 제거되면 S3 메타데이터는 해당 메타데이터 테이블을 자동으로 새로 고쳐 최신 변경 사항을 반영합니다.
기본적으로 S3 메타데이터는 객체의 생성 시간 및 스토리지 클래스와 같은 [시스템 정의 객체 메타데이터](#SysMetadata)와 객체 업로드 중에 포함된 태그 및 [사용자 정의 메타데이터](#UserMetadata)와 같은 사용자 지정 메타데이터를 제공합니다. 또한 S3 메타데이터는 객체가 업데이트되거나 삭제되는 시기 및 요청을 수행한 AWS 계정과 같은 이벤트 메타데이터를 제공합니다.
메타데이터 테이블은 테이블 형식 데이터에 최적화된 스토리지를 제공하는 S3 테이블 버킷에 저장됩니다. 메타데이터를 쿼리하려면 테이블 버킷을 Amazon Athena, Amazon Redshift, Amazon Quick과 같은 AWS 분석 서비스와 통합하면 됩니다.
S3 메타데이터에 대한 자세한 정보는 [S3 메타데이터 테이블을 사용하여 데이터 검색](metadata-tables-overview.md) 섹션을 참조하세요.
## 시스템 정의 객체 메타데이터
버킷에 저장된 각 객체에 대해 Amazon S3는 시스템 메타데이터의 조합을 유지합니다. Amazon S3는 필요할 경우 이 시스템 메타데이터를 처리합니다. 예를 들어 Amazon S3는 객체 생성 날짜와 크기 메타데이터를 유지하며 객체 관리의 일환으로 이 정보를 사용합니다.
시스템 메타데이터에는 다음 2가지 카테고리가 있습니다.
+ **시스템이 제어함** - 객체 생성 날짜와 같은 메타데이터는 시스템이 제어하므로 Amazon S3만 날짜 값을 수정할 수 있습니다.
+ **사용자가 제어함** - 그 외, 객체에 대해 구성된 스토리지 클래스, 객체의 서버 측 암호화 사용 여부와 같은 시스템 메타데이터는 사용자가 값을 제어할 수 있는 시스템 메타데이터의 예입니다. 웹 사이트로 구성된 버킷의 경우 다른 페이지 또는 외부 URL 중 하나로 페이지 요청을 리디렉션해야 할 때가 있습니다. 이 경우 웹 페이지는 버킷의 객체가 됩니다. Amazon S3는 페이지 리디렉션 값을 시스템 메타데이터로 저장하며, 이것을 사용자가 제어합니다.
객체를 만들 때 이러한 시스템 메타데이터 항목의 값을 구성하고, 언제든지 필요할 때마다 값을 업데이트할 수 있습니다. 스토리지 클래스에 대한 자세한 정보는 [Amazon S3 스토리지 클래스 이해 및 관리](storage-class-intro.md)를 참조하십시오.
Amazon S3는 AWS KMS 키를 사용하여 Amazon S3 객체를 암호화합니다. AWS KMS는 객체 데이터만 암호화합니다. 체크섬과 지정된 알고리즘은 객체 메타데이터의 일부로 저장됩니다. 객체에 서버 측 암호화가 요청된 경우 체크섬은 암호화된 형식으로 저장됩니다. 서버 측 암호화에 대한 자세한 정보는 [암호화로 데이터 보호](UsingEncryption.md) 섹션을 참조하십시오.
**참고**
`PUT` 요청 헤더는 크기가 8KB 이하여야 합니다. `PUT` 요청 헤더에 포함되는 시스템 정의 메타데이터의 크기는 2KB 이하여야 합니다. 시스템 정의 메타데이터의 크기는 US-ASCII로 인코딩된 각 키와 값의 바이트 수를 더하여 측정됩니다.
다음 표에 시스템 정의 메타데이터의 목록과 사용자의 업데이트 여부가 정리되어 있습니다.
| 이름 | 설명 | 사용자의 값 수정 여부 |
| --- | --- | --- |
| Date | 현재 날짜 및 시간. | 아니요 |
| Cache-Control | 캐싱 정책을 지정하는 데 사용되는 일반 헤더 필드입니다. | 예 |
| Content-Disposition | 객체 표현 정보입니다. | 예 |
| Content-Encoding | 객체의 데이터에 적용된 콘텐츠 인코딩(예: 압축) | 예 |
| Content-Length | 객체 크기(바이트). | 아니요 |
| Content-Type | 객체 유형입니다. | 예 |
| Last-Modified | 객체 생성일 또는 최종 수정일 중 최근 날짜. 멀티파트 업로드의 경우 객체 생성 날짜는 멀티파트 업로드 시작 날짜입니다. | 아니요 |
| ETag | 객체의 특정 버전을 나타내는 엔터티 태그(ETag). 멀티파트 업로드로 업로드되지 않고 암호화되지 않거나 Amazon S3 관리형 키(SSE-S3)를 사용하는 서버 측 암호화를 통해 암호화된 객체의 경우 ETag는 데이터의 MD5 다이제스트입니다. | 아니요 |
| x-amz-server-side-encryption | 객체에 대한 서버 측 암호화 사용 여부 및 해당 암호화 유형이 AWS Key Management Service(AWS KMS) 키(SSE-KMS)와 Amazon S3 관리형 암호화 키(SSE-S3)중 무엇인지를 나타내는 헤더. 자세한 내용은 [서버 측 암호화를 사용하여 데이터 보호](serv-side-encryption.md) 섹션을 참조하세요. | 예 |
| x-amz-checksum-crc64nvme, x-amz-checksum-crc32, x-amz-checksum-crc32c, x-amz-checksum-sha1, x-amz-checksum-sha256 | 객체의 체크섬 또는 다이제스트를 포함하는 헤더. 대부분의 경우 Amazon S3에서 사용하도록 하는 체크섬 알고리즘에 따라 이러한 헤더 중 하나가 한 번에 설정됩니다. 체크섬 알고리즘 선택에 대한 자세한 내용은 [Amazon S3에서 객체 무결성 확인](checking-object-integrity.md) 단원을 참조하십시오. | 아니요 |
| x-amz-checksum-type | 멀티파트 객체에 대한 객체 수준 체크섬을 생성하기 위해 파트 수준 체크섬을 결합하는 방법을 결정하는 체크섬 유형입니다. | 예 |
| x-amz-version-id | 객체 버전. 버전 관리를 사용하는 버킷의 경우 Amazon S3는 버킷에 추가된 객체에 버전 ID를 지정합니다. 자세한 내용은 [S3 버전 관리로 여러 버전의 객체 유지](Versioning.md) 섹션을 참조하세요. | 아니요 |
| x-amz-delete-marker | 객체가 삭제 마커인지를 나타내는 부울 마커. 이 마커는 버전 관리가 활성화된 버킷에서만 사용됩니다. | 아니요 |
| x-amz-storage-class | 객체 저장에 사용된 스토리지 클래스. 자세한 내용은 [Amazon S3 스토리지 클래스 이해 및 관리](storage-class-intro.md) 섹션을 참조하세요. | 예 |
| x-amz-website-redirect-location | 관련 객체에 대한 요청을 동일한 버킷의 다른 객체 또는 외부 URL로 리디렉션하는 헤더. 자세한 내용은 [(선택 사항) 웹 페이지 리디렉션 구성](how-to-page-redirect.md) 섹션을 참조하세요. | 예 |
| x-amz-server-side-encryption-aws-kms-key-id | 객체를 암호화하는 데 사용된 AWS KMS 대칭 암호화 KMS 키의 ID를 나타내는 헤더. 이 헤더는 x-amz-server-side-encryption 헤더가 존재하고 값이 aws:kms인 경우에만 사용됩니다. | 예 |
| x-amz-server-side-encryption-customer-algorithm | 고객 제공 암호화 키(SSE-C)를 사용하는 서버 측 암호화가 활성화되었는지를 나타내는 헤더. 자세한 내용은 [고객 제공 키(SSE-C)로 서버 측 암호화 사용](ServerSideEncryptionCustomerKeys.md) 섹션을 참조하세요. | 예 |
| x-amz-tagging | 객체에 대한 태그 집합입니다. 태그 집합은 URL 쿼리 매개 변수로 인코딩되어야 합니다. | 예 |
## 사용자 정의 객체 메타데이터
객체를 업로드할 때 객체에 메타데이터를 지정할 수 있습니다. 객체를 생성하기 위해 `PUT` 또는 `POST` 요청을 전송할 때 필요할 경우 이름-값(키-값)의 페어로 이 정보를 제공할 수 있습니다. REST API를 사용하여 객체를 업로드할 때 선택 사항으로 제공되는 사용자 정의 메타데이터의 이름은 다른 HTTP 헤더와 구분할 수 있도록 `x-amz-meta-`로 시작해야 합니다. REST API를 사용하여 객체를 검색하면 이 접두사가 반환됩니다. SOAP API를 사용하여 객체를 업로드할 때는 접두사가 필요 없습니다. SOAP API를 사용하여 객체를 검색하면 객체 업로드 시 사용한 API에 관계없이 접두사가 제거됩니다.
**참고**
Amazon S3용 SOAP API는 신규 고객에게 제공되지 않으며 2025년 8월 31일에 서비스 종료(EOL)됩니다. REST API 또는 AWS SDK를 사용하는 것이 좋습니다.
REST API를 통해 메타데이터를 검색할 때 Amazon S3는 동일한 이름(대소문자 무시)을 가진 헤더를 쉼표로 구분되는 목록으로 결합합니다. 일부 메타데이터에 인쇄되지 않는 문자가 포함될 경우 반환되지 않습니다. 대신 인쇄할 수 없는 메타데이터 항목의 수를 나타내는 값과 함께 `x-amz-missing-meta` 헤더가 반환됩니다. `HeadObject` 작업은 객체 자체를 반환하지 않고 객체에서 메타데이터를 검색합니다. 이 작업은 객체의 메타데이터에만 관심이 있는 경우에 유용합니다. `HEAD`를 사용하려면 객체에 대한 `READ` 액세스 권한이 있어야 합니다. 자세한 내용은 [Amazon Simple Storage Service API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadObject.html)의 *HeadObject*를 참조하십시오.
사용자 정의 메타데이터는 키-값 페어의 집합입니다. Amazon S3는 사용자 정의 메타데이터 키를 소문자로 저장합니다.
Amazon S3는 메타데이터 값에 임의의 유니코드 문자를 허용합니다.
이러한 메타데이터 값 표시와 관련한 문제를 방지하려면 REST를 사용할 경우 US-ASCII 문자를 사용하고, SOAP를 사용하거나 `POST`를 통해 브라우저 기반 업로드를 사용할 경우 UTF-8을 사용해야 합니다.
메타데이터 값에 US-ASCII 문자가 아닌 문자를 사용하는 경우, 제공된 유니코드 문자열에서 US-ASCII 문자가 아닌 문자가 있는지 검사합니다. 이러한 헤더의 값은 저장 및 인코딩하기 전에 [RFC 2047](https://datatracker.ietf.org/doc/html/rfc2047)에 따라 문자 디코딩되고, 반환되기 전에 메일이 안전하도록 [RFC 2047](https://datatracker.ietf.org/doc/html/rfc2047)에 따라 인코딩됩니다. 문자열에 US-ASCII 문자만 포함되어 있으면 그대로 표시됩니다.
다음은 예입니다.
```
PUT /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-nonascii: ÄMÄZÕÑ S3
HEAD /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-nonascii: =?UTF-8?B?w4PChE3Dg8KEWsODwpXDg8KRIFMz?=
PUT /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-ascii: AMAZONS3
HEAD /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-ascii: AMAZONS3
```
**참고**
`PUT` 요청 헤더는 크기가 8KB 이하여야 합니다. `PUT` 요청 헤더에 포함되는 사용자 정의 메타데이터의 크기는 2KB 이하여야 합니다. 사용자 정의 메타데이터의 크기는 UTF-8로 인코딩된 각 키와 값의 바이트 수를 더하여 계산합니다.
객체를 업로드한 이후에 객체의 복사본을 만들어서 수정하고 이전 객체를 교체하거나 새 버전을 만드는 방법으로 객체의 메타데이터를 변경하는 내용은 [Amazon S3 콘솔에서 객체 메타데이터 편집](add-object-metadata.md) 섹션을 참조하십시오.
# Amazon S3 콘솔에서 객체 메타데이터 편집
Amazon S3 콘솔에서 **복사** 작업을 사용하여 기존 S3 객체의 메타데이터를 편집할 수 있습니다. 메타데이터를 편집하려면 객체를 동일한 대상으로 복사하고 적용하려는 새 메타데이터를 지정하면 객체의 이전 메타데이터가 대체됩니다. 일부 메타데이터는 객체를 업로드할 때 Amazon S3에서 설정합니다. 예를 들어 `Content-Length` 및 `Last-Modified`는 사용자가 수정할 수 없는 시스템 정의 객체 메타데이터 필드입니다.
객체를 업로드할 때 사용자 정의 메타데이터를 설정하고 필요에 따라 변경할 수도 있습니다. 예를 들어 처음에 `STANDARD` 스토리지 클래스에 객체 세트를 저장했습니다. 시간이 지나면 이 데이터의 고가용성이 더 이상 필요하지 않을 수도 있습니다. 따라서 `x-amz-storage-class` 키의 값을 `STANDARD`에서 `GLACIER`로 바꾸면 스토리지 클래스를 `GLACIER`로 변경할 수 있습니다.
**참고**
Amazon S3에서 객체 메타데이터를 바꿀 때는 다음 사항을 고려해야 합니다.
유지하려는 기존 메타데이터, 추가하려는 메타데이터 및 편집하려는 메타데이터를 지정해야 합니다.
객체가 5GB 미만인 경우 S3 콘솔에서 **복사** 작업을 사용하여 객체 메타데이터를 바꿀 수 있습니다. 객체가 5GB보다 큰 경우, [AWS CLI](mpu-upload-object.md#UsingCLImpUpload) 또는 [AWS SDK](CopyingObjectsMPUapi.md)를 사용하여 여러 부분으로 업로드하는 객체를 복사할 때 객체 메타데이터를 대체할 수 있습니다. 자세한 내용은 [멀티파트 업로드를 사용한 객체 복사](CopyingObjectsMPUapi.md) 섹션을 참조하세요.
자세한 내용은 멀티파트 업로드를 사용하여 [Amazon S3 API 작업에 필요한 권한](using-with-s3-policy-actions.md)를 참조하세요. 이 권한을 부여하는 정책의 예시는 [Amazon S3의 ID 기반 정책 예시](example-policies-s3.md) 단원을 참조하세요.
이 작업을 수행하면 업데이트된 설정과 마지막 수정 날짜가 포함된 객체의 *복사본*이 만들어집니다. S3 버전 관리가 사용 설정된 경우 객체의 새 버전이 생성되고 기존 객체는 이전 버전이 됩니다. S3 버전 관리가 활성화되지 않은 경우 객체의 새 복사본이 원본 객체를 대체합니다. 또한 속성을 변경하는 IAM 역할과 연결된 AWS 계정도 새 객체(또는 객체 버전)의 소유자가 됩니다.
메타데이터를 편집하면 기존 키 이름의 값이 바뀝니다
고객 제공 암호화 키(SSE-C)로 암호화된 객체는 콘솔을 사용하여 복사할 수 없습니다. AWS CLI, AWS SDK 또는 Amazon S3 REST API를 사용해야 합니다.
Amazon S3 콘솔을 사용하여 객체를 복사할 때 "복사된 메타데이터를 확인할 수 없습니다."라는 오류 메시지가 표시될 수 있습니다. 콘솔은 헤더를 사용하여 객체에 대한 메타데이터를 검색하고 설정합니다. 네트워크 또는 브라우저 구성이 네트워크 요청을 수정하면 이 동작으로 인해 복사된 객체에 의도하지 않은 메타데이터(수정된 `Cache-Control` 헤더 등)가 기록될 수 있습니다. Amazon S3는 이 의도하지 않은 메타데이터를 확인할 수 없습니다.
이 문제를 해결하려면 네트워크 및 브라우저 구성을 확인하여 `Cache-Control`과 같은 헤더를 수정하지 않는지 확인하세요. 자세한 내용은 [The Shared Responsibility Model](https://docs.aws.amazon.com/whitepapers/latest/applying-security-practices-to-network-workload-for-csps/the-shared-responsibility-model.html)을 참조하세요.
**주의**
폴더의 메타데이터를 바꿀 때는 **복사** 작업이 완료될 때까지 기다렸다가 폴더에 새 객체를 추가하세요. 그렇지 않으면 새 객체도 편집될 수 있습니다.
다음 주제에서는 Amazon S3 콘솔에서 **복사** 작업을 사용하여 객체의 메타데이터를 바꾸는 방법에 대해 설명합니다.
## 시스템 정의 메타데이터 바꾸기
S3 객체에 대해 몇 가지 시스템 정의 메타데이터를 바꿀 수 있습니다. 시스템 정의 메타데이터 및 수정할 수 있는 값 목록은 [시스템 정의 객체 메타데이터](UsingMetadata.md#SysMetadata)를 참조하세요.
**객체의 시스템 정의 메타데이터 바꾸기**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷** 또는 **디렉터리 버킷**을 선택합니다.
1. 버킷 목록에서 변경할 객체가 들어 있는 버킷 이름을 선택합니다.
1. 변경하려는 객체의 확인란을 선택합니다.
1. **작업** 메뉴에 표시되는 옵션 목록에서 **복사**를 선택합니다.
1. 대상 경로를 지정하려면 **S3 찾아보기**를 선택하고 소스 객체와 동일한 대상으로 이동한 다음 대상 확인란을 선택합니다. 오른쪽 하단 모서리에서 **대상 선택(Choose destination)**을 선택합니다.
또는 대상 경로를 입력합니다.
1. 버킷 버전 관리를 사용 설정하지 않은 경우,** 의도치 않게 객체를 덮어쓰거나 삭제하는 것을 방지하기 위해 버킷 버전 관리를 사용하도록 권장하는 경고 메시지가 표시됩니다. 객체의 모든 버전을 이 버킷에 보관하려면 **버킷 버전 관리 사용(Enable Bucket Versioning)**을 선택합니다. **대상 세부 사항**에서 기본 암호화 및 Object Lock 속성을 볼 수도 있습니다.
1. **추가 복사 설정** 아래에서 **설정 지정**을 선택하여 **메타데이터**에 대한 설정을 지정합니다.
1. **메타데이터** 섹션으로 스크롤한 다음 **모든 메타데이터 바꾸기**를 선택합니다.
1. [**메타데이터 추가(Add metadata)**]를 선택합니다.
1. 메타데이터 **유형(Type)**에서 **시스템 정의(System-defined)**를 선택합니다.
1. 고유 **키** 및 메타데이터 **값**을 지정합니다.
1. 추가 메타데이터를 편집하려면 **메타데이터 추가(Add metadata)**를 선택합니다. [**제거(Remove)**]를 선택하여 유형-키-값 세트를 제거할 수도 있습니다.
1. **복사**를 선택합니다. Amazon S3는 메타데이터 변경 사항을 저장합니다.
## 사용자 정의 메타데이터 바꾸기
메타데이터 접두사 `x-amz-meta-`와 사용자 지정 키를 만들기 위해 선택한 이름을 결합하여 객체의 사용자 정의 메타데이터를 바꿀 수 있습니다. 예를 들어, `alt-name`을 사용자 이름으로 추가하면 메타데이터 키는 `x-amz-meta-alt-name`이 됩니다.
사용자 정의 메타데이터의 최대 크기는 총 2KB입니다. 사용자 정의 메타데이터의 총 크기를 계산하려면 각 키와 값에 대한 UTF-8 인코딩의 바이트 수를 합산합니다. 키와 값 모두 US-ASCII 표준에 부합해야 합니다. 자세한 내용은 [사용자 정의 객체 메타데이터](UsingMetadata.md#UserMetadata) 섹션을 참조하세요.
**객체의 사용자 정의 메타데이터 바꾸기**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 탐색 창에서 **버킷**을 선택한 다음 **범용 버킷** 또는 **디렉토리 버킷** 탭을 선택합니다. 변경할 객체가 포함된 Amazon S3 버킷 또는 폴더로 이동합니다.
1. 변경하려는 객체의 확인란을 선택합니다.
1. **작업** 메뉴에 표시되는 옵션 목록에서 **복사**를 선택합니다.
1. 대상 경로를 지정하려면 **S3 찾아보기**를 선택하고 소스 객체와 동일한 대상으로 이동한 다음 대상 확인란을 선택합니다. **목적지 선택(Choose destination)**을 선택합니다.
또는 대상 경로를 입력합니다.
1. 버킷 버전 관리를 사용 설정하지 않은 경우,** 의도치 않게 객체를 덮어쓰거나 삭제하는 것을 방지하기 위해 버킷 버전 관리를 사용하도록 권장하는 경고 메시지가 표시됩니다. 객체의 모든 버전을 이 버킷에 보관하려면 **버킷 버전 관리 사용(Enable Bucket Versioning)**을 선택합니다. **대상 세부 사항**에서 기본 암호화 및 Object Lock 속성을 볼 수도 있습니다.
1. **추가 복사 설정** 아래에서 **설정 지정**을 선택하여 **메타데이터**에 대한 설정을 지정합니다.
1. **메타데이터** 섹션으로 스크롤한 다음 **모든 메타데이터 바꾸기**를 선택합니다.
1. [**메타데이터 추가(Add metadata)**]를 선택합니다.
1. 메타데이터의 [**유형(Type)**]에 대해 [**사용자 정의(User-defined)**]를 선택합니다.
1. `x-amz-meta-` 다음에 고유한 사용자 지정 **키**를 입력합니다. 메타데이터 **값**도 입력합니다.
1. 메타데이터를 추가하려면 **메타데이터 추가(Add metadata)**를 선택합니다. [**제거(Remove)**]를 선택하여 유형-키-값 세트를 제거할 수도 있습니다.
1. **복사**를 선택합니다. Amazon S3는 메타데이터 변경 사항을 저장합니다.
# S3 메타데이터 테이블을 사용하여 데이터 검색
Amazon S3 Metadata는 범용 버킷의 객체에 대한 메타데이터를 자동으로 캡처하고, 쿼리할 수 있는 읽기 전용 완전관리형 Apache Iceberg 테이블에 저장하여 데이터 검색을 가속화합니다. 이러한 읽기 전용 테이블을 *메타데이터 테이블*이라고 합니다. 객체가 범용 버킷에 추가, 업데이트 및 제거되면 S3 Metadata는 해당 메타데이터 테이블을 자동으로 새로 고쳐 최신 변경 사항을 반영합니다.
기본적으로 S3 메타데이터는 세 가지 유형의 메타데이터를 제공합니다.
+ 객체의 생성 시간 및 스토리지 클래스와 같은 [시스템 정의 메타데이터](UsingMetadata.md#SysMetadata)
+ 객체 업로드 중에 포함된 태그 및 [사용자 정의 메타데이터](UsingMetadata.md#UserMetadata)와 같은 사용자 지정 메타데이터
+ 객체가 업데이트되거나 삭제되는 시기 및 요청을 수행한 AWS 계정과 같은 이벤트 메타데이터
S3 메타데이터를 사용하면 S3 객체에 대한 메타데이터를 쉽게 찾고 저장하고 쿼리할 수 있으므로 비즈니스 분석, 콘텐츠 검색, 인공 지능 및 기계 학습(AI/ML) 모델 훈련 등에 사용할 데이터를 빠르게 준비할 수 있습니다.
각 범용 버킷에 대해 두 개의 보완적 메타데이터 테이블이 포함된 메타데이터 테이블 구성을 만들 수 있습니다.
+ **저널 테이블** - 기본적으로 메타데이터 테이블 구성에는 버킷의 객체에 대해 발생하는 이벤트를 캡처하는 *저널 테이블*이 포함되어 있습니다. 저널 테이블은 거의 실시간으로 데이터에 대한 변경 사항을 기록하므로 버킷에 업로드된 새 데이터를 식별하고, 최근에 삭제된 객체를 추적하고, 수명 주기 전환을 모니터링하는 등의 작업을 수행할 수 있습니다. 저널 테이블은 새 객체를 기록하고 객체 및 해당 메타데이터를 업데이트합니다(`PUT` 또는 `DELETE` 작업이 필요한 업데이트).
저널 테이블은 메타데이터 테이블 구성을 만든 후에 발생하는 변경 이벤트(예: 업로드, 업데이트 및 삭제)에 대한 메타데이터만 캡처합니다. 이 테이블은 쿼리가 가능하므로 간단한 SQL 쿼리를 통해 버킷의 변경 사항을 감사할 수 있습니다.
저널 테이블은 각 메타데이터 테이블 구성에 필요합니다. (S3 Metadata의 최초 릴리스에서는 저널 테이블을 "메타데이터 테이블"이라고 했습니다.)
저널 테이블에 저장되는 데이터에 대한 자세한 내용은 [S3 Metadata 저널 테이블 스키마](metadata-tables-schema.md) 섹션을 참조하세요.
스토리지 비용을 최소화하려면 저널 테이블 레코드 만료를 활성화하도록 선택할 수 있습니다. 자세한 내용은 [저널 테이블 레코드 만료시키기](metadata-tables-expire-journal-table-records.md) 섹션을 참조하세요.
+ **라이브 인벤토리 테이블** - 선택적으로 메타데이터 테이블 구성에 *라이브 인벤토리 테이블*을 추가할 수 있습니다. 라이브 인벤토리 테이블은 버킷의 모든 객체와 해당 버전에 대한 간단하고 쿼리 가능한 인벤토리를 제공하므로 데이터의 최신 상태를 확인할 수 있습니다.
라이브 인벤토리 테이블을 사용하면 다양한 워크로드에 대해 처리하려는 객체를 식별하여 비즈니스 워크플로와 빅 데이터 작업을 간소화하고 속도를 높일 수 있습니다. 예를 들어 라이브 인벤토리 테이블을 쿼리하여 특정 스토리지 클래스에 저장된 모든 객체, 특정 태그가 있는 모든 객체, AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 암호화되지 않은 모든 객체 등을 찾을 수 있습니다.
메타데이터 테이블 구성에 대해 라이브 인벤토리 테이블을 활성화하면 테이블은 *채우기*라는 프로세스를 거치며, 이 과정에서 Amazon S3는 범용 버킷을 스캔하여 버킷에 있는 모든 객체의 초기 메타데이터를 검색합니다. 버킷의 객체 수에 따라 이 프로세스는 몇 분(최소 15분)에서 몇 시간이 걸릴 수 있습니다. 채우기 프로세스가 완료되면 라이브 인벤토리 테이블의 상태가 **채우기**에서 **활성**으로 변경됩니다. 채우기가 완료되면 객체에 대한 업데이트는 일반적으로 1시간 이내에 라이브 인벤토리 테이블에 반영됩니다.
인벤토리 테이블 채우기에 대한 요금이 부과됩니다. 범용 버킷에 10억 개 이상의 객체가 있는 경우 라이브 인벤토리 테이블에 대한 월별 요금도 부과됩니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
라이브 인벤토리 테이블에 저장되는 데이터에 대한 자세한 내용은 [S3 Metadata 라이브 인벤토리 테이블 스키마](metadata-tables-inventory-schema.md) 섹션을 참조하세요.
메타데이터 테이블은 테이블 형식 데이터에 최적화된 스토리지를 제공하는 AWS 관리형 S3 테이블 버킷에 저장됩니다. 메타데이터를 쿼리하기 위해 테이블 버킷을 Amazon SageMaker Lakehouse와 통합할 수 있습니다. AWS Glue Data Catalog 및 AWS Lake Formation을 사용하는 이 통합을 통해 AWS 분석 서비스는 테이블 데이터를 자동으로 검색하고 액세스할 수 있습니다.
테이블 버킷이 AWS Glue Data Catalog와 통합되면 Amazon Athena, Amazon EMR, Amazon Redshift와 같은 AWS 분석 서비스를 사용하여 메타데이터 테이블을 직접 쿼리할 수 있습니다. 여기에서 Amazon Quick을 사용하여 쿼리 데이터로 대화형 대시보드를 만들 수 있습니다. AWS 관리형 S3 테이블 버킷을 Amazon SageMaker Lakehouse와 통합하는 방법에 대한 자세한 내용은 [AWS 분석 서비스와 Amazon S3 Tables 통합](s3-tables-integrating-aws.md) 섹션을 참조하세요.
AWS Glue Iceberg REST 엔드포인트, Amazon S3 Tables Iceberg REST 엔드포인트 또는 Apache Iceberg 클라이언트 카탈로그용 Amazon S3 Tables Catalog를 사용하여 Apache Iceberg 형식을 지원하는 Apache Spark, Apache Trino 및 기타 애플리케이션을 사용하여 메타데이터 테이블을 쿼리할 수도 있습니다. 메타데이터 테이블에 액세스하는 방법에 대한 자세한 내용은 [테이블 데이터에 액세스](s3-tables-access.md) 섹션을 참조하세요.
S3 메타데이터 요금은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
## 메타데이터 테이블 작동 방식
메타데이터 테이블은 Amazon S3에서 관리하며 Amazon S3 외부의 IAM 위탁자는 수정할 수 없습니다. 하지만 메타데이터 테이블을 삭제할 수 있습니다. 따라서 메타데이터 테이블은 읽기 전용이므로 범용 버킷의 콘텐츠를 올바르게 반영할 수 있습니다.
AWS 관리형 메타데이터 테이블에 객체 메타데이터를 생성하고 저장하려면 범용 버킷에 대한 메타데이터 테이블 구성을 만듭니다. Amazon S3는 범용 버킷에서 구성이 활성 상태인 한 메타데이터 테이블을 지속적으로 업데이트하여 데이터에 대한 최신 변경 사항을 반영하도록 설계되었습니다.
메타데이터 테이블 구성을 만들려면 메타데이터 테이블을 만들고 관리하는 데 필요한 AWS Identity and Access Management(IAM) 권한이 있는지 확인하세요. 자세한 내용은 [메타데이터 테이블 구성에 대한 권한 설정](metadata-tables-permissions.md) 섹션을 참조하세요.
**메타데이터 테이블 스토리지, 구성 및 암호화**
메타데이터 테이블 구성을 만들 때 메타데이터 테이블이 AWS 관리형 테이블 버킷에 저장됩니다. 계정 및 동일한 리전의 모든 메타데이터 테이블 구성은 단일 AWS 관리형 테이블 버킷에 저장됩니다. 이러한 AWS 관리형 테이블 버킷의 이름은 `aws-s3`이며 다음 Amazon 리소스 이름(ARN) 형식을 갖습니다.
`arn:aws:s3tables:region:account_id:bucket/aws-s3`
예를 들어 계정 ID가 123456789012이고 범용 버킷이 미국 동부(버지니아 북부)(`us-east-1`)에 있는 경우 AWS 관리형 테이블 버킷도 미국 동부(버지니아 북부)(`us-east-1`)에서 만들어지며 ARN은 다음과 같습니다.
`arn:aws:s3tables:us-east-1:123456789012:bucket/aws-s3`
기본적으로 AWS 관리형 테이블 버킷은 Amazon S3 관리형 암호화 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 암호화됩니다. 첫 번째 메타데이터 구성을 만든 후 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)를 사용하도록 AWS 관리형 테이블 버킷의 기본 암호화 설정을 지정할 수 있습니다. 자세한 내용은 [Encryption for AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html#aws-managed-buckets-encryption) 및 [테이블 버킷에서 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화 지정](s3-tables-kms-specify.md) 섹션을 참조하세요.
AWS 관리형 테이블 버킷 내에서 구성의 메타데이터 테이블은 일반적으로 다음 이름 지정 형식의 네임스페이스에 저장됩니다.
`b_general-purpose-bucket-name`
**참고**
범용 버킷 이름에 마침표가 포함된 경우 네임스페이스 이름에서 마침표가 밑줄(`_`)로 변환됩니다.
범용 버킷이 2018년 3월 1일 이전에 만들어진 경우 이름에 대문자와 밑줄이 포함될 수 있으며 최대 255자일 수 있습니다. 버킷 이름에 이러한 특성이 있는 경우 메타데이터 테이블 네임스페이스의 형식이 다릅니다. 범용 버킷 이름에는 `b_` 접두사가 붙고, 63자로 잘리고, 모두 소문자로 변환되고, 해시 접미사가 붙습니다.
메타데이터 테이블에는 메타데이터 테이블의 테이블 ID를 포함하는 다음과 같은 Amazon 리소스 이름(ARN) 형식이 있습니다.
`arn:aws:s3tables:region-code:account-id:bucket/aws-s3/table/table-id`
예를 들어 미국 동부(버지니아 북부) 리전의 메타데이터 테이블에는 다음과 같은 ARN이 있습니다.
`arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/a12bc345-67d8-912e-3456-7f89123g4h56`
저널 테이블의 이름은 `journal`이고 라이브 인벤토리 테이블의 이름은 `inventory`입니다.
메타데이터 테이블 구성을 만들 때 AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화로 AWS 관리형 메타데이터 테이블을 암호화하도록 선택할 수 있습니다. SSE-KMS를 사용하기로 선택한 경우 범용 버킷과 동일한 리전에 고객 관리형 KMS 키를 제공해야 합니다. 테이블을 만드는 중에만 테이블에 대한 암호화 유형을 설정할 수 있습니다. AWS 관리형 테이블이 만들어진 후에는 암호화 설정을 변경할 수 없습니다. 메타데이터 테이블에 SSE-KMS를 지정하려면 특정 권한이 있어야 합니다. 자세한 내용은 [Permissions for SSE-KMS](metadata-tables-permissions.md#metadata-kms-permissions)를 참조하세요.
메타데이터 테이블의 암호화 설정이 기본 버킷 수준 암호화 설정보다 우선합니다. 테이블에 암호화 설정을 지정하지 않으면 버킷의 기본 암호화 설정을 상속합니다.
AWS 관리형 테이블 버킷은 S3 Tables 할당량에 포함되지 않습니다. AWS 관리형 테이블 버킷 및 AWS 관리형 테이블 작업에 대한 자세한 내용은 [Working with AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html)를 참조하세요.
메타데이터 테이블 구성에 대한 업데이트를 모니터링하려면 AWS CloudTrail을 사용할 수 있습니다. 자세한 내용은 [CloudTrail 로깅을 통해 추적되는 Amazon S3 버킷 수준 작업](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking) 섹션을 참조하세요.
**메타데이터 테이블 유지 관리 및 레코드 만료**
메타데이터 테이블 성능을 최상의 상태로 유지하기 위해 Amazon S3는 테이블에 대해 압축 및 참조되지 않은 파일 제거와 같은 유지 관리 활동을 정기적으로 수행합니다. 이러한 유지 관리 활동은 메타데이터 테이블 저장 비용을 최소화하고 쿼리 성능을 최적화하는 데 도움이 됩니다. 이 테이블 유지 관리는 자동으로 수행되므로 사용자가 옵트인하거나 지속적으로 관리할 필요가 없습니다.
**참고**
저널 테이블 또는 인벤토리 테이블 스냅샷의 만료를 제어할 수 없습니다. 각 테이블에 대해 Amazon S3는 최대 24시간 동안 최소 1개의 스냅샷을 저장합니다.
비용을 최소화하기 위해 저널 테이블 레코드 만료를 구성할 수 있습니다. 기본적으로 저널 테이블 레코드는 만료되지 않으며, 저널 테이블 레코드는 최소 7일 동안 유지되어야 합니다. 자세한 내용은 [저널 테이블 레코드 만료시키기](metadata-tables-expire-journal-table-records.md) 섹션을 참조하세요.
**Topics**
+ [메타데이터 테이블 작동 방식](#metadata-tables-how-they-work)
+ [메타데이터 테이블의 한계 및 제한](metadata-tables-restrictions.md)
+ [S3 Metadata 저널 테이블 스키마](metadata-tables-schema.md)
+ [S3 Metadata 라이브 인벤토리 테이블 스키마](metadata-tables-inventory-schema.md)
+ [메타데이터 테이블 구성](metadata-tables-configuring.md)
+ [메타데이터 테이블 쿼리](metadata-tables-querying.md)
+ [S3 Metadata 문제 해결](metadata-tables-troubleshooting.md)
# 메타데이터 테이블의 한계 및 제한
Amazon S3 Metadata에는 다음과 같은 한계와 제한이 있습니다.
+ S3 메타데이터는 현재 특정 리전에서만 사용할 수 있습니다. 자세한 내용은 [S3 메타데이터 AWS 리전](#metadata-tables-regions) 섹션을 참조하세요.
+ S3 Metadata는 범용 버킷에서 지원하는 모든 스토리지 클래스를 지원합니다. S3 Intelligent-Tiering 스토리지 클래스의 경우 메타데이터 테이블에 특정 티어가 표시되지 않습니다.
+ 메타데이터 테이블 구성을 만들 때 메타데이터 테이블이 AWS 관리형 테이블 버킷에 저장됩니다. 고객 관리형 테이블 버킷에는 구성을 저장할 수 없습니다.
+ 디렉터리 버킷, 테이블 버킷 또는 벡터 버킷에는 S3 Metadata가 지원되지 않습니다. 범용 버킷에 대해서만 메타데이터 테이블 구성을 생성할 수 있습니다. 저널 테이블은 메타데이터 테이블 구성을 만든 후에 발생하는 변경 이벤트(예: 업로드, 업데이트 및 삭제)에 대한 메타데이터만 캡처합니다.
+ 저널 테이블 또는 인벤토리 테이블 스냅샷의 만료를 제어할 수 없습니다. 각 테이블에 대해 Amazon S3는 최대 24시간 동안 최소 1개의 스냅샷을 저장합니다.
비용을 최소화하기 위해 저널 테이블 레코드 만료를 구성할 수 있습니다. 기본적으로 저널 테이블 레코드는 만료되지 않으며, 저널 테이블 레코드는 최소 7일 동안 유지되어야 합니다. 자세한 내용은 [저널 테이블 레코드 만료시키기](metadata-tables-expire-journal-table-records.md) 섹션을 참조하세요.
+ 전체 범용 버킷에 대해서만 메타데이터 테이블 구성을 생성할 수 있습니다. 접두사 수준에서는 메타데이터 테이블 구성을 적용할 수 없습니다.
+ 메타데이터 테이블에 대한 업데이트를 일시 중지하고 재개할 수 없습니다. 그러나 저널 또는 라이브 인벤토리 테이블에 대한 관련 메타데이터 구성을 삭제할 수 있습니다. 구성을 삭제해도 연결된 저널 또는 인벤토리 테이블은 삭제되지 않습니다. 구성을 다시 만들려면 먼저 이전 저널 또는 인벤토리 테이블을 삭제해야 하며, 그러면 Amazon S3에서 새 저널 또는 인벤토리 테이블을 만들 수 있습니다. 인벤토리 테이블을 다시 활성화하면 Amazon S3가 새 인벤토리 테이블을 생성하고 새 인벤토리 테이블을 채우는 데 따른 요금이 다시 청구됩니다.
+ 메타데이터 테이블에는 S3 인벤토리 또는 Amazon S3 REST API를 통해 사용할 수 있는 메타데이터와 동일한 메타데이터가 모두 포함되어 있지는 않습니다. 예를 들어 메타데이터 테이블에서는 다음 정보를 사용할 수 없습니다.
+ S3 수명 주기 만료 자격 또는 전환 상태
+ Object Lock 보존 기간 또는 거버넌스 모드
+ 객체 액세스 제어 목록(ACL) 정보
+ 복제 상태
+ Amazon Athena 또는 Amazon Redshift를 사용하여 메타데이터 테이블을 쿼리하는 경우, 메타데이터 테이블 네임스페이스 이름을 따옴표(`"`) 또는 백틱(```)으로 묶어야 합니다. 그러지 않으면 쿼리가 작동하지 않을 수 있습니다. 예시는 [메타데이터 테이블 쿼리 예시](metadata-tables-example-queries.md) 섹션을 참조하세요.
+ Amazon EMR 또는 기타 타사 엔진에서 Apache Spark를 사용하여 메타데이터 테이블을 쿼리하는 경우 Amazon S3 Tables Iceberg REST 엔드포인트를 사용하는 것이 좋습니다. 이 엔드포인트를 사용하지 않으면 쿼리가 성공적으로 실행되지 않을 수 있습니다. 자세한 내용은 [Amazon S3 Tables Iceberg REST 엔드포인트를 사용하여 테이블에 액세스](s3-tables-integrating-open-source.md) 섹션을 참조하세요.
## S3 메타데이터 AWS 리전
S3 메타데이터는 현재 다음 AWS 리전에서 사용 가능합니다.
| AWS 리전 이름 | AWS 리전 코드 |
| --- | --- |
| 아프리카(케이프타운) | `af-south-1` |
| 아시아 태평양(홍콩) | `ap-east-1` |
| 아시아 태평양(자카르타) | `ap-southeast-3` |
| 아시아 태평양(멜버른) | `ap-southeast-4` |
| 아시아 태평양(뭄바이) | `ap-south-1` |
| 아시아 태평양(오사카) | `ap-northeast-3` |
| 아시아 태평양(서울) | `ap-northeast-2` |
| 아시아 태평양(싱가포르) | `ap-southeast-1` |
| 아시아 태평양(시드니) | `ap-southeast-2` |
| 아시아 태평양(도쿄) | `ap-northeast-1` |
| 캐나다(중부) | `ca-central-1` |
| 캐나다 서부(캘거리) | `ca-west-1` |
| 유럽(프랑크푸르트) | `eu-central-1` |
| 유럽(취리히) | `eu-central-2` |
| 유럽(아일랜드) | `eu-west-1` |
| 유럽(런던) | `eu-west-2` |
| 유럽(밀라노) | `eu-south-1` |
| 유럽(파리) | `eu-west-3` |
| 유럽(스페인) | `eu-south-2` |
| 유럽(스톡홀름) | `eu-north-1` |
| 이스라엘(텔아비브) | `il-central-1` |
| 중동(바레인) | `me-south-1` |
| 중동(UAE) | `me-central-1` |
| 남아메리카(상파울루) | `sa-east-1` |
| 미국 동부(버지니아 북부) | `us-east-1` |
| 미국 동부(오하이오) | `us-east-2` |
| 미국 서부(캘리포니아 북부) | `us-west-1` |
| 미국 서부(오리건) | `us-west-2` |
# S3 Metadata 저널 테이블 스키마
저널 테이블은 거의 실시간으로 데이터에 대한 변경 사항을 기록하므로 버킷에 업로드된 새 데이터를 식별하고, 최근에 삭제된 객체를 추적하고, 수명 주기 전환을 모니터링하는 등의 작업을 수행할 수 있습니다. 저널 테이블은 새 객체를 기록하고 객체 및 해당 메타데이터를 업데이트합니다(`PUT` 또는 `DELETE` 작업이 필요한 업데이트). 이 테이블은 쿼리가 가능하므로 간단한 SQL 쿼리를 통해 버킷의 변경 사항을 감사할 수 있습니다.
저널 테이블을 보안, 감사 및 규정 준수 사용 사례에 사용하여 버킷에서 업로드, 삭제 및 변경된 객체를 추적할 수 있습니다. 예를 들어 저널 테이블을 쿼리하여 다음과 같은 질문에 답할 수 있습니다.
+ 지난 24시간 동안 S3 수명 주기에 의해 삭제된 객체는 무엇인가?
+ 가장 최근 `PUT` 요청은 어떤 IP 주소에서 제출되었는가?
+ 지난 7일 동안 `PUT` 요청에 사용된 AWS Key Management Service(AWS KMS) 키는 무엇인가?
+ 지난 5일 동안 Amazon Bedrock에 의해 만들어진 버킷의 객체는 무엇인가?
Amazon S3 Metadata 저널 테이블에는 행과 열이 포함됩니다. 각 행은 범용 버킷에서 객체를 생성, 업데이트 또는 삭제한 변형 이벤트를 나타냅니다. 이러한 이벤트의 대부분은 사용자 작업의 결과이지만, 이러한 이벤트 중 일부는 Amazon S3 수명 주기 만료 또는 스토리지 클래스 전환과 같이 Amazon S3가 사용자를 대신하여 수행한 작업의 결과입니다.
S3 Metadata 저널 테이블은 범용 버킷에서 발생한 변경 사항과 최종적으로 일치합니다. 경우에 따라 객체가 만들어지거나 업데이트되었다는 알림이 S3 Metadata에 수신될 때쯤에는 해당 객체가 버킷에서 이미 덮어쓰였거나 삭제되었을 수 있습니다. 이러한 경우 객체를 더 이상 검색할 수 없으며, 일부 열에는 누락된 메타데이터 스키마를 나타내는 Null 값이 표시될 수 있습니다.
다음은 `amzn-s3-demo-bucket:`이라는 범용 버킷에 대한 저널 테이블의 예입니다.
```
bucket key sequence_number record_type record_timestamp version_id is_delete_marker size last_modified_date e_tag storage_class is_multipart encryption_status is_bucket_key_enabled kms_key_arn checksum_algorithm object_tags user_metadata requester source_ip_address request_id
amzn-s3-demo-bucket Finance/statement1.pdf 80e737d8b4d82f776affffffffffffffff006737d8b4d82f776a00000000000000000000000000000000000000000000000072 CREATE 2024-11-15 23:26:44.899 FALSE 6223 11/15/2024 23:26 e131b86632dda753aac4018f72192b83 STANDARD FALSE SSE-KMS FALSE arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890df SSECRC32 {} {count -> Asia, customs -> false, family -> true, location -> Mary, name -> football, user -> United States} 111122223333 192.0.2.1 CVK8FWYRW0M9JW65
amzn-s3-demo-bucket s3-dg.pdf 80e737d8b4e39f1dbdffffffffffffffff006737d8b4e39f1dbd00000000000000000000000000000000000000000000000072 CREATE 2024-11-15 23:26:44.942 FALSE 3554 11/15/2024 23:26 9bb49efc2d92c05558ddffbbde8636d5 STANDARD FALSE DSSE-KMS FALSE arn:aws:kms:us-east-1:936810216292:key/0dcebce6-49fd-4cae-b2e2-5512ad281afd SSESHA1 {} {} 111122223333 192.0.2.1 CVKAQDRAZEG7KXAY
amzn-s3-demo-bucket Development/Projects.xls 80e737d8b4ed9ac5c6ffffffffffffffff006737d8b4ed9ac5c600000000000000000000000000000000000000000000000072 CREATE 2024-11-15 23:26:44.966 FALSE 7746 11/15/2024 23:26 729a6863e47fb9955b31bfabce984908 STANDARD FALSE SSE-S3 FALSE NULL SSECRC32 {} {count -> Asia, customs -> Canada, family -> Billiards, filter -> true, location -> Europe, name -> Asia, user -> United States} 111122223333 192.0.2.1 CVK7Z6XQTQ90BSRV
```
저널 테이블에는 다음과 같은 스키마가 있습니다.
| 열 이름 | 필수 | 데이터 유형 | |
| --- | --- | --- | --- |
| `bucket` | 예 | 문자열 | 범용 버킷 이름입니다. 자세한 내용은 [범용 버킷 이름 지정 규칙](bucketnamingrules.md) 섹션을 참조하세요. |
| `key` | 예 | 문자열 | 버킷에 있는 객체를 고유하게 식별하는 객체 키 이름(또는 키)입니다. 자세한 내용은 [Amazon S3 객체 이름 지정](object-keys.md) 섹션을 참조하세요. |
| `sequence_number` | 예 | 문자열 | 주어진 객체의 레코드에 포함된 서수인 시퀀스 번호입니다. 동일한 버킷 및 키의 레코드를 정렬하려면 `sequence_number`를 기준으로 정렬할 수 있습니다. 주어진 버킷과 키에서 사전을 기준으로 `sequence_number` 값이 크면 레코드가 더 최근에 버킷에 기록되었음을 의미합니다. |
| `record_type` | 예 | 문자열 | 이 레코드의 유형으로, `CREATE`, `UPDATE_METADATA` 또는 `DELETE` 중 하나입니다. `CREATE` 레코드는 새 객체(또는 객체의 새 버전)가 버킷에 기록되었음을 나타냅니다. `UPDATE_METADATA`는 스토리지 클래스 또는 태그와 같은 기존 객체의 변경 가능한 메타데이터에 대한 변경 사항을 캡처합니다. `DELETE`는 이 객체(또는 객체의 이 버전)가 삭제되었음을 나타냅니다. 버전 관리가 활성화된 경우 `DELETE`는 삭제 마커 또는 영구 삭제를 나타냅니다. 선택 사항인 `is_delete_marker` 열을 참조하여 더 명확하게 구분할 수 있습니다. 자세한 내용은 [버전 관리가 사용 설정된 버킷에서 객체 버전 삭제](DeletingObjectVersions.md) 섹션을 참조하세요. 영구 삭제는 `bucket`, `key`, `sequence_number`, `record_type`, `record_timestamp` 및 `version_id`(즉, 필수로 표시된 열)를 *제외한* 모든 열에서 `NULL`을 포함합니다. |
| `record_timestamp` | 예 | 타임스탬프 NTZ(표준 시간대 없음) | 이 레코드와 연결된 타임스탬프입니다. |
| `version_id` | 아니요 | 문자열 | 객체의 버전 ID입니다. 버전 관리를 사용하는 버킷의 경우 Amazon S3는 버킷에 추가된 객체에 버전 번호를 지정합니다. 자세한 내용은 [S3 버전 관리로 여러 버전의 객체 유지](Versioning.md) 섹션을 참조하세요. 버전 관리 상태를 설정하기 전에 버킷에 저장된 객체의 버전 ID는 Null입니다. |
| `is_delete_marker` | 아니요 | 부울 | 객체의 삭제 마커 상태입니다. 삭제 마커인 DELETE 레코드의 경우 이 값은 `TRUE`입니다. 영구 삭제의 경우 이 값은 생략됩니다(`NULL`). 다른 레코드 유형(CREATE 및 UPDATE\$1METADATA)의 값은 `FALSE`입니다. 자세한 내용은 [삭제 마커를 통한 작업](DeleteMarker.md) 섹션을 참조하세요. 삭제 마커에 추가된 행의 `record_type` 값은 `UPDATE_METADATA`가 아니라 `DELETE`입니다. S3 수명 주기 만료의 결과로 삭제 마커가 생성된 경우 `requester` 값은 `s3.amazonaws.com`입니다. |
| `size` | 아니요 | Long | 객체 크기(바이트)를 나타내며, 불완전한 멀티파트 업로드 또는 객체 메타데이터의 크기는 포함되지 않습니다. `is_delete_marker`가 `TRUE`인 경우 크기는 `0`입니다. 자세한 내용은 [시스템 정의 객체 메타데이터](UsingMetadata.md#SysMetadata) 섹션을 참조하세요. |
| `last_modified_date` | 아니요 | 타임스탬프 NTZ(표준 시간대 없음) | 객체 생성일 또는 최종 수정일 중 최근 날짜. 멀티파트 업로드의 경우 객체 생성 날짜는 멀티파트 업로드 시작 날짜입니다. 자세한 내용은 [시스템 정의 객체 메타데이터](UsingMetadata.md#SysMetadata) 섹션을 참조하세요. |
| `e_tag` | 아니요 | 문자열 | 엔터티 태그(ETag)로, 객체의 해시입니다. ETag는 객체의 콘텐츠에 대한 변경 사항만 반영하고 메타데이터에 대한 변경을 반영하지 않습니다. ETag는 객체 데이터의 MD5 다이제스트일 수 있습니다. ETag가 MD5 다이제스트인지는 객체 생성 방식 및 암호화 방식에 달려 있습니다. 자세한 내용은 **Amazon S3 API 참조의 [https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html) 섹션을 참조하세요. |
| `storage_class` | 아니요 | 문자열 | 객체 저장에 사용된 스토리지 클래스입니다. `STANDARD`, `REDUCED_REDUNDANCY`, `STANDARD_IA`, `ONEZONE_IA`, `INTELLIGENT_TIERING`, `GLACIER`, `DEEP_ARCHIVE` 또는 `GLACIER_IR` 중 하나입니다. 자세한 내용은 [Amazon S3 스토리지 클래스 이해 및 관리](storage-class-intro.md) 섹션을 참조하세요. |
| `is_multipart` | 아니요 | 부울 | 객체의 업로드 유형입니다. 객체가 멀티파트 업로드로 업로드된 경우 이 값은 `TRUE`입니다. 그렇지 않은 경우 `FALSE`입니다. 자세한 내용은 [Amazon S3에서 멀티파트 업로드를 사용한 객체 업로드 및 복사](mpuoverview.md) 섹션을 참조하세요. |
| `encryption_status` | 아니요 | 문자열 | Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3), AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS), AWS KMS keys KMS 키를 사용한 이중 계층 서버 측 암호화(DSSE-KMS), 고객 제공 키를 사용한 서버 측 암호화(SSE-C) 등 사용되는 암호화 키의 종류에 따른 객체의 서버 측 암호화 상태입니다. 객체가 암호화되지 않은 경우 이 값은 Null입니다. 가능한 값은 `SSE-S3`, `SSE-KMS`, `DSSE-KMS`, `SSE-C` 또는 Null입니다. 자세한 내용은 [암호화로 데이터 보호](UsingEncryption.md) 섹션을 참조하세요. |
| `is_bucket_key_enabled` | 아니요 | 부울 | 객체의 S3 버킷 키 활성화 상태입니다. 객체가 SSE-KMS에 S3 버킷 키를 사용하는 경우 이 값은 `TRUE`입니다. 그렇지 않은 경우 `FALSE`입니다. 자세한 내용은 [객체 수준에서 S3 버킷 키 구성](configuring-bucket-key-object.md) 섹션을 참조하세요. |
| `kms_key_arn` | 아니요 | 문자열 | 객체 암호화에 사용된 KMS 키의 Amazon 리소스 이름(ARN)으로, `encryption_status`가 `SSE-KMS` 또는 `DSSE-KMS`인 행의 경우에 해당합니다. 객체가 SSE-KMS 또는 DSSE-KMS로 암호화되지 않은 경우 값은 Null입니다. 자세한 내용은 [AWS KMS 키를 사용한 서버 측 암호화(SSE-KMS) 사용](UsingKMSEncryption.md) 및 [AWS KMS 키를 사용한 이중 계층 서버 측 암호화(DSSE-KMS) 사용](UsingDSSEncryption.md)(을)를 참조하세요. 행이 삭제 또는 덮어쓰기 이벤트가 처리된 시점에 더 이상 존재하지 않았던 객체 버전을 나타내는 경우 `encryption_status` 열 값이 `SSE-KMS` 또는 `DSSE-KMS`인 경우에도 `kms_key_arn`에는 Null 값이 포함됩니다. |
| `checksum_algorithm` | 아니요 | 문자열 | 객체에 대한 체크섬을 생성하는 데 사용되는 알고리즘으로, `CRC64NVME`, `CRC32`, `CRC32C`, `SHA1` 또는 `SHA256` 중 하나입니다. 체크섬이 없는 경우 이 값은 Null입니다. 자세한 내용은 [지원되는 체크섬 알고리즘 사용](checking-object-integrity-upload.md#using-additional-checksums) 섹션을 참조하세요. |
| `object_tags` | 아니요 | Map | 객체와 연결된 객체 태그입니다. 객체 태그는 키-값 페어의 맵으로 저장됩니다. 객체에 객체 태그가 없는 경우 빈 맵(`{}`)이 저장됩니다. 자세한 내용은 [태그를 사용하여 객체 분류](object-tagging.md) 섹션을 참조하세요. `record_type` 값이 `DELETE`이면 `object_tags` 열에 Null 값이 포함됩니다. `record_type` 값이 `CREATE` 또는 `UPDATE_METADATA`인 경우 삭제 또는 덮어쓰기 이벤트가 처리된 시점에 더 이상 존재하지 않았던 객체 버전을 나타내는 행에는 `object_tags` 열에 Null 값이 포함됩니다. |
| `user_metadata` | 아니요 | Map | 객체와 연결된 사용자 메타데이터입니다. 사용자 메타데이터는 키-값 페어의 맵으로 저장됩니다. 객체에 사용자 메타데이터가 없는 경우 빈 맵(`{}`)이 저장됩니다. 자세한 내용은 [사용자 정의 객체 메타데이터](UsingMetadata.md#UserMetadata) 섹션을 참조하세요. `record_type` 값이 `DELETE`이면 `user_metadata` 열에 Null 값이 포함됩니다. `record_type` 값이 `CREATE` 또는 `UPDATE_METADATA`인 경우 삭제 또는 덮어쓰기 이벤트가 처리된 시점에 더 이상 존재하지 않았던 객체 버전을 나타내는 행에는 `user_metadata` 열에 Null 값이 포함됩니다. |
| `requester` | 아니요 | 문자열 | 요청을 수행한 요청자 또는 AWS 서비스 위탁자의 AWS 계정 ID입니다. 예를 들어, 요청자가 S3 수명 주기인 경우 이 값은 `s3.amazonaws.com`입니다. |
| `source_ip_address` | 아니요 | 문자열 | 요청의 소스 IP 주소입니다. 사용자 요청에 의해 생성된 레코드의 경우 이 열에는 요청의 소스 IP 주소가 포함됩니다. 사용자를 대신해 Amazon S3 또는 다른 AWS 서비스가 수행한 작업의 경우 이 열에는 Null 값이 포함됩니다. |
| `request_id` | 아니요 | 문자열 | 요청과 연결된 요청 ID입니다. |
# S3 Metadata 라이브 인벤토리 테이블 스키마
라이브 인벤토리 테이블은 버킷의 모든 객체와 해당 버전에 대한 간단하고 쿼리 가능한 인벤토리를 제공하므로 데이터의 최신 상태를 확인할 수 있습니다. 객체에 대한 업데이트는 일반적으로 1시간 이내에 인벤토리 테이블에 반영됩니다.
이 표를 사용하여 다양한 워크로드에 대해 처리하려는 객체를 식별하여 비즈니스 워크플로와 빅 데이터 작업을 간소화하고 속도를 높일 수 있습니다. 예를 들어 인벤토리 테이블을 쿼리하여 다음을 수행할 수 있습니다.
+ S3 Glacier Deep Archive 스토리지 클래스에 저장된 모든 객체를 찾습니다.
+ 객체 태그 배포를 생성하거나 태그가 없는 객체를 찾습니다.
+ AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)를 사용하여 암호화되지 않은 모든 객체를 찾습니다.
메타데이터 테이블 구성에 대해 인벤토리 테이블을 활성화하면 테이블은 *채우기*라는 프로세스를 거치며, 이 과정에서 Amazon S3는 범용 버킷을 스캔하여 버킷에 있는 모든 객체의 초기 메타데이터를 검색합니다. 버킷의 객체 수에 따라 이 프로세스는 몇 분(최소 15분)에서 몇 시간이 걸릴 수 있습니다. 채우기 프로세스가 완료되면 인벤토리 테이블의 상태가 **채우기**에서 **활성**으로 변경됩니다. 채우기가 완료되면 객체에 대한 업데이트는 일반적으로 1시간 이내에 인벤토리 테이블에 반영됩니다.
**참고**
인벤토리 테이블 채우기에 대한 요금이 부과됩니다. 범용 버킷에 10억 개 이상의 객체가 있는 경우 인벤토리 테이블에 대한 월별 요금도 부과됩니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
Amazon S3 Metadata 인벤토리 테이블에는 행과 열이 포함됩니다. 각 행은 범용 버킷에 있는 객체의 현재 상태를 나타냅니다. 인벤토리 테이블은 버킷의 모든 객체에 대한 간단하고 쿼리 가능한 인벤토리를 제공하므로 데이터의 현재 상태를 확인할 수 있습니다.
다음은 `amzn-s3-demo-bucket:`이라는 범용 버킷에 대한 인벤토리 테이블의 예입니다.
```
bucket key sequence_number version_id is_delete_marker size last_modified_date e_tag storage_class is_multipart encryption_status is_bucket_key_enabled kms_key_arn checksum_algorithm object_tags user_metadata
amzn-s3-demo-bucket Finance/statement1.pdf 80e737d8b4d82f776affffffffffffffff006737d8b4d82f776a00000000000000000000000000000000000000000000000072 FALSE 6223 11/15/2024 23:26 e131b86632dda753aac4018f72192b83 STANDARD FALSE SSE-KMS FALSE arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890df SSECRC32 {} {count -> Asia, customs -> false, family -> true, location -> Mary, name -> football, user -> United States}
amzn-s3-demo-bucket s3-dg.pdf 80e737d8b4e39f1dbdffffffffffffffff006737d8b4e39f1dbd00000000000000000000000000000000000000000000000072 FALSE 3554 11/15/2024 23:26 9bb49efc2d92c05558ddffbbde8636d5 STANDARD FALSE DSSE-KMS FALSE arn:aws:kms:us-east-1:936810216292:key/0dcebce6-49fd-4cae-b2e2-5512ad281afd SSESHA1 {} {}
amzn-s3-demo-bucket Development/Projects.xls 80e737d8b4ed9ac5c6ffffffffffffffff006737d8b4ed9ac5c600000000000000000000000000000000000000000000000072 FALSE 7746 11/15/2024 23:26 729a6863e47fb9955b31bfabce984908 STANDARD FALSE SSE-S3 FALSE NULL SSECRC32 {} {count -> Asia, customs -> Canada, family -> Billiards, filter -> true, location -> Europe, name -> Asia, user -> United States}
```
인벤토리 테이블에는 다음과 같은 스키마가 있습니다.
| 열 이름 | 필수 | 데이터 유형 | |
| --- | --- | --- | --- |
| `bucket` | 예 | 문자열 | 범용 버킷 이름입니다. 자세한 내용은 [범용 버킷 이름 지정 규칙](bucketnamingrules.md) 섹션을 참조하세요. |
| `key` | 예 | 문자열 | 버킷에 있는 객체를 고유하게 식별하는 객체 키 이름(또는 키)입니다. 자세한 내용은 [Amazon S3 객체 이름 지정](object-keys.md) 섹션을 참조하세요. |
| `sequence_number` | 예 | 문자열 | 주어진 객체의 레코드에 포함된 서수인 시퀀스 번호입니다. 동일한 버킷 및 키의 레코드를 정렬하려면 `sequence_number`를 기준으로 정렬할 수 있습니다. 주어진 버킷과 키에서 사전을 기준으로 `sequence_number` 값이 크면 레코드가 더 최근에 버킷에 기록되었음을 의미합니다. |
| `version_id` | 아니요 | 문자열 | 객체의 버전 ID입니다. 버전 관리를 사용하는 버킷의 경우 Amazon S3는 버킷에 추가된 객체에 버전 번호를 지정합니다. 자세한 내용은 [S3 버전 관리로 여러 버전의 객체 유지](Versioning.md) 섹션을 참조하세요. 버전 관리 상태를 설정하기 전에 버킷에 저장된 객체의 버전 ID는 Null입니다. |
| `is_delete_marker` | 아니요 | 부울 | 객체의 삭제 마커 상태입니다. 객체가 삭제 마커인 경우 이 값은 `True`입니다. 그렇지 않은 경우 `False`입니다. 자세한 내용은 [삭제 마커를 통한 작업](DeleteMarker.md) 섹션을 참조하세요. 삭제 마커에 추가된 행의 `record_type` 값은 `UPDATE_METADATA`가 아니라 `DELETE`입니다. S3 수명 주기 만료의 결과로 삭제 마커가 생성된 경우 `requester` 값은 `s3.amazonaws.com`입니다. |
| `size` | 아니요 | Long | 객체 크기(바이트)를 나타내며, 불완전한 멀티파트 업로드 또는 객체 메타데이터의 크기는 포함되지 않습니다. `is_delete_marker`가 `True`인 경우 크기는 `0`입니다. 자세한 내용은 [시스템 정의 객체 메타데이터](UsingMetadata.md#SysMetadata) 섹션을 참조하세요. |
| `last_modified_date` | 아니요 | 타임스탬프 NTZ(표준 시간대 없음) | 객체 생성일 또는 최종 수정일 중 최근 날짜. 멀티파트 업로드의 경우 객체 생성 날짜는 멀티파트 업로드 시작 날짜입니다. 자세한 내용은 [시스템 정의 객체 메타데이터](UsingMetadata.md#SysMetadata) 섹션을 참조하세요. |
| `e_tag` | 아니요 | 문자열 | 엔터티 태그(ETag)로, 객체의 해시입니다. ETag는 객체의 콘텐츠에 대한 변경 사항만 반영하고 메타데이터에 대한 변경을 반영하지 않습니다. ETag는 객체 데이터의 MD5 다이제스트일 수 있습니다. ETag가 MD5 다이제스트인지는 객체 생성 방식 및 암호화 방식에 달려 있습니다. 자세한 내용은 **Amazon S3 API 참조의 [https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html) 섹션을 참조하세요. |
| `storage_class` | 아니요 | 문자열 | 객체 저장에 사용된 스토리지 클래스입니다. `STANDARD`, `REDUCED_REDUNDANCY`, `STANDARD_IA`, `ONEZONE_IA`, `INTELLIGENT_TIERING`, `GLACIER`, `DEEP_ARCHIVE` 또는 `GLACIER_IR` 중 하나입니다. 자세한 내용은 [Amazon S3 스토리지 클래스 이해 및 관리](storage-class-intro.md) 섹션을 참조하세요. |
| `is_multipart` | 아니요 | 부울 | 객체의 업로드 유형입니다. 객체가 멀티파트 업로드로 업로드된 경우 이 값은 `True`입니다. 그렇지 않은 경우 `False`입니다. 자세한 내용은 [Amazon S3에서 멀티파트 업로드를 사용한 객체 업로드 및 복사](mpuoverview.md) 섹션을 참조하세요. |
| `encryption_status` | 아니요 | 문자열 | Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3), AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS), AWS KMS keys KMS 키를 사용한 이중 계층 서버 측 암호화(DSSE-KMS), 고객 제공 키를 사용한 서버 측 암호화(SSE-C) 등 사용되는 암호화 키의 종류에 따른 객체의 서버 측 암호화 상태입니다. 객체가 암호화되지 않은 경우 이 값은 Null입니다. 가능한 값은 `SSE-S3`, `SSE-KMS`, `DSSE-KMS`, `SSE-C` 또는 Null입니다. 자세한 내용은 [암호화로 데이터 보호](UsingEncryption.md) 섹션을 참조하세요. |
| `is_bucket_key_enabled` | 아니요 | 부울 | 객체의 S3 버킷 키 활성화 상태입니다. 객체가 SSE-KMS에 S3 버킷 키를 사용하는 경우 이 값은 `True`입니다. 그렇지 않은 경우 `False`입니다. 자세한 내용은 [객체 수준에서 S3 버킷 키 구성](configuring-bucket-key-object.md) 섹션을 참조하세요. |
| `kms_key_arn` | 아니요 | 문자열 | 객체 암호화에 사용된 KMS 키의 Amazon 리소스 이름(ARN)으로, `encryption_status`가 `SSE-KMS` 또는 `DSSE-KMS`인 행의 경우에 해당합니다. 객체가 SSE-KMS 또는 DSSE-KMS로 암호화되지 않은 경우 값은 Null입니다. 자세한 내용은 [AWS KMS 키를 사용한 서버 측 암호화(SSE-KMS) 사용](UsingKMSEncryption.md) 및 [AWS KMS 키를 사용한 이중 계층 서버 측 암호화(DSSE-KMS) 사용](UsingDSSEncryption.md)(을)를 참조하세요. 행이 삭제 또는 덮어쓰기 이벤트가 처리된 시점에 더 이상 존재하지 않았던 객체 버전을 나타내는 경우 `encryption_status` 열 값이 `SSE-KMS` 또는 `DSSE-KMS`인 경우에도 `kms_key_arn`에는 Null 값이 포함됩니다. |
| `checksum_algorithm` | 아니요 | 문자열 | 객체에 대한 체크섬을 생성하는 데 사용되는 알고리즘으로, `CRC64-NVME`, `CRC32`, `CRC32C`, `SHA1` 또는 `SHA256` 중 하나입니다. 체크섬이 없는 경우 이 값은 Null입니다. 자세한 내용은 [지원되는 체크섬 알고리즘 사용](checking-object-integrity-upload.md#using-additional-checksums) 섹션을 참조하세요. |
| `object_tags` | 아니요 | Map | 객체와 연결된 객체 태그입니다. 객체 태그는 키-값 페어의 맵으로 저장됩니다. 객체에 객체 태그가 없는 경우 빈 맵(`{}`)이 저장됩니다. 자세한 내용은 [태그를 사용하여 객체 분류](object-tagging.md) 섹션을 참조하세요. `record_type` 값이 `DELETE`이면 `object_tags` 열에 Null 값이 포함됩니다. `record_type` 값이 `CREATE` 또는 `UPDATE_METADATA`인 경우 삭제 또는 덮어쓰기 이벤트가 처리된 시점에 더 이상 존재하지 않았던 객체 버전을 나타내는 행에는 `object_tags` 열에 Null 값이 포함됩니다. |
| `user_metadata` | 아니요 | Map | 객체와 연결된 사용자 메타데이터입니다. 사용자 메타데이터는 키-값 페어의 맵으로 저장됩니다. 객체에 사용자 메타데이터가 없는 경우 빈 맵(`{}`)이 저장됩니다. 자세한 내용은 [사용자 정의 객체 메타데이터](UsingMetadata.md#UserMetadata) 섹션을 참조하세요. `record_type` 값이 `DELETE`이면 `user_metadata` 열에 Null 값이 포함됩니다. `record_type` 값이 `CREATE` 또는 `UPDATE_METADATA`인 경우 삭제 또는 덮어쓰기 이벤트가 처리된 시점에 더 이상 존재하지 않았던 객체 버전을 나타내는 행에는 `user_metadata` 열에 Null 값이 포함됩니다. |
# 메타데이터 테이블 구성
Amazon S3 메타데이터는 범용 버킷의 객체에 대한 메타데이터를 자동으로 캡처하고, 쿼리할 수 있는 읽기 전용 완전관리형 Apache Iceberg 테이블에 저장하여 데이터 검색을 가속화합니다. 이러한 읽기 전용 테이블을 *메타데이터 테이블*이라고 합니다. 객체가 범용 버킷에 추가, 업데이트 및 제거되면 S3 메타데이터는 해당 메타데이터 테이블을 자동으로 새로 고쳐 최신 변경 사항을 반영합니다.
S3 메타데이터를 사용하면 S3 객체에 대한 메타데이터를 쉽게 찾고 저장하고 쿼리할 수 있으므로 비즈니스 분석, 인공 지능 및 기계 학습(AI/ML) 모델 훈련 등에 사용할 데이터를 빠르게 준비할 수 있습니다.
AWS 관리형 메타데이터 테이블에 객체 메타데이터를 생성하고 저장하려면 범용 버킷에 대한 메타데이터 테이블 구성을 만듭니다. Amazon S3는 버킷에서 구성이 활성 상태인 한 메타데이터 테이블을 지속적으로 업데이트하여 데이터에 대한 최신 변경 사항을 반영하도록 설계되었습니다. 또한 Amazon S3는 메타데이터 테이블을 지속적으로 최적화하여 스토리지 비용을 줄이고 분석 쿼리 성능을 개선하는 데 도움을 줍니다.
메타데이터 테이블 구성을 생성하려면 메타데이터 테이블을 생성하고 관리하는 데 필요한 AWS Identity and Access Management (IAM) 권한이 있는지 확인하세요.
메타데이터 테이블 구성에 대한 업데이트를 모니터링하려면 AWS CloudTrail을 사용할 수 있습니다. 자세한 내용은 [CloudTrail 로깅을 통해 추적되는 Amazon S3 버킷 수준 작업](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking) 섹션을 참조하세요.
**Topics**
+ [메타데이터 테이블 구성에 대한 권한 설정](metadata-tables-permissions.md)
+ [메타데이터 테이블 구성 생성](metadata-tables-create-configuration.md)
+ [메타데이터 테이블에 대한 액세스 제어](metadata-tables-access-control.md)
+ [저널 테이블 레코드 만료시키기](metadata-tables-expire-journal-table-records.md)
+ [라이브 인벤토리 테이블 활성화 또는 비활성화](metadata-tables-enable-disable-inventory-tables.md)
+ [메타데이터 테이블 구성 보기](metadata-tables-view-configuration.md)
+ [메타데이터 테이블 구성 삭제](metadata-tables-delete-configuration.md)
+ [메타데이터 테이블 삭제](metadata-tables-delete-table.md)
# 메타데이터 테이블 구성에 대한 권한 설정
메타데이터 테이블 구성을 만들려면 메타데이터 테이블 구성을 만들고 관리하며 메타데이터 테이블이 저장되는 메타데이터 테이블과 테이블 버킷을 만들고 관리하는 데 필요한 AWS Identity and Access Management(IAM) 권한이 있어야 합니다.
메타데이터 테이블 구성을 생성하고 관리하려면 다음 권한이 있어야 합니다.
+ `s3:CreateBucketMetadataTableConfiguration` - 이 권한을 사용하면 범용 버킷에 대한 메타데이터 테이블 구성을 생성할 수 있습니다. 메타데이터 테이블 구성을 만들려면 다음 섹션에 설명된 대로 S3 테이블 권한을 포함한 추가 권한이 필요합니다. 필요한 권한 목록의 요약은 [버킷 작업 및 권한](using-with-s3-policy-actions.md#using-with-s3-policy-actions-related-to-buckets) 섹션을 참조하세요.
+ `s3:GetBucketMetadataTableConfiguration` - 이 권한을 사용하면 메타데이터 테이블 구성에 대한 정보를 검색할 수 있습니다.
+ `s3:DeleteBucketMetadataTableConfiguration` - 이 권한을 사용하면 메타데이터 테이블 구성을 삭제할 수 있습니다.
+ `s3:UpdateBucketMetadataJournalTableConfiguration` - 이 권한을 사용하면 저널 테이블 구성을 업데이트하여 저널 테이블 레코드를 만료시킬 수 있습니다.
+ `s3:UpdateBucketMetadataInventoryTableConfiguration` - 이 권한을 사용하면 인벤토리 테이블 구성을 업데이트하여 인벤토리 테이블을 활성화하거나 비활성화할 수 있습니다. 인벤토리 테이블 구성을 업데이트하려면 S3 테이블 권한을 포함한 추가 권한이 필요합니다. 필요한 권한 목록은 [버킷 작업 및 권한](using-with-s3-policy-actions.md#using-with-s3-policy-actions-related-to-buckets) 섹션을 참조하세요.
**참고**
`s3:CreateBucketMetadataTableConfiguration`, `s3:GetBucketMetadataTableConfiguration` 및 `s3:DeleteBucketMetadataTableConfiguration` 권한은 V1 및 V2 S3 Metadata 구성 모두에 사용됩니다. V2의 경우 해당 API 작업의 이름은 `CreateBucketMetadataConfiguration`, `GetBucketMetadataConfiguration` 및 `DeleteBucketMetadataConfiguration`입니다.
테이블 및 테이블 버킷을 생성하고 작업하려면 특정 `s3tables` 권한이 있어야 합니다. 메타데이터 테이블 구성을 생성하려면 최소한 다음 `s3tables` 권한이 있어야 합니다.
+ `s3tables:CreateTableBucket` - 이 권한을 사용하면 AWS 관리형 테이블 버킷을 만들 수 있습니다. 계정 및 동일한 리전의 모든 메타데이터 테이블 구성은 `aws-s3`라는 단일 AWS 관리형 테이블 버킷에 저장됩니다. 자세한 내용은 [메타데이터 테이블 작동 방식](metadata-tables-overview.md#metadata-tables-how-they-work) 및 [Working with AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html)를 참조하세요.
+ `s3tables:CreateNamespace` - 이 권한을 사용하면 테이블 버킷에 네임스페이스를 생성할 수 있습니다. 메타데이터 테이블은 보통 `b_general_purpose_bucket_name` 네임스페이스를 사용합니다. 메타데이터 테이블 네임스페이스에 대한 자세한 내용은 [메타데이터 테이블 작동 방식](metadata-tables-overview.md#metadata-tables-how-they-work) 섹션을 참조하세요.
+ `s3tables:CreateTable` - 이 권한을 사용하면 메타데이터 테이블을 만들 수 있습니다.
+ `s3tables:GetTable` - 이 권한을 사용하면 메타데이터 테이블에 대한 정보를 검색할 수 있습니다.
+ `s3tables:PutTablePolicy` - 이 권한을 사용하면 메타데이터 테이블 정책을 추가하거나 업데이트할 수 있습니다.
+ `s3tables:PutTableEncryption` - 이 권한을 사용하면 메타데이터 테이블에 대한 서버 측 암호화를 설정할 수 있습니다. AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 메타데이터 테이블을 암호화하려면 추가 권한이 필요합니다. 자세한 내용은 [Permissions for SSE-KMS](#metadata-kms-permissions)를 참조하세요.
+ `kms:DescribeKey` - 이 권한을 사용하면 KMS 키에 대한 정보를 검색할 수 있습니다.
+ `s3tables:PutTableBucketPolicy` - 이 권한을 사용하면 새 테이블 버킷 정책을 생성하거나 업데이트할 수 있습니다.
모든 테이블 및 테이블 버킷 권한에 대한 자세한 내용은 [Access management for S3 Tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-setting-up.html)을 참조하세요.
**중요**
또한 메타데이터 테이블을 쿼리할 수 있도록 테이블 버킷을 AWS 분석 서비스와 통합하려면 추가 권한이 필요합니다. 자세한 내용은 [Integrating Amazon S3 Tables with AWS analytics services](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)를 참조하세요.
**SSE-KMS에 대한 권한**
AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 메타데이터 테이블을 암호화하려면 추가 권한이 있어야 합니다.
1. 사용자 또는 AWS Identity and Access Management(IAM) 역할에 다음 권한이 필요합니다. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 사용해 이러한 권한을 부여할 수 있습니다.
1. 테이블 암호화 구성: `s3tables:PutTableEncryption`
1. 사용된 AWS KMS 키의 `kms:DescribeKey`
1. KMS 키에 대한 리소스 정책에는 다음 권한이 필요합니다. AWS KMS 콘솔([https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms))을 사용하여 이러한 권한을 부여할 수 있습니다.
1. `metadata.s3.amazonaws.com` 및 `maintenance.s3tables.amazonaws.com`에 `kms:GenerateDataKey` 권한 부여
1. `metadata.s3.amazonaws.com` 및 `maintenance.s3tables.amazonaws.com`에 `kms:Decrypt` 권한 부여
1. AWS 위탁자 간접 호출에 대한 `kms:DescribeKey` 권한
이러한 권한 외에도 테이블을 암호화하는 데 사용되는 고객 관리형 KMS 키가 여전히 존재하고 활성 상태이며 범용 버킷과 동일한 리전에 있는지 확인합니다.
**예제 정책**
메타데이터 테이블 및 테이블 버킷을 생성하고 작업하려면 다음 예시 정책을 사용할 수 있습니다. 이 정책에서는 메타데이터 테이블 구성을 적용하는 범용 버킷을 `amzn-s3-demo-bucket`이라고 합니다. 이 정책을 사용하려면 `user input placeholders`를 사용자의 정보로 대체합니다.
메타데이터 테이블 구성을 만들 때 메타데이터 테이블이 AWS 관리형 테이블 버킷에 저장됩니다. 계정 및 동일한 리전의 모든 메타데이터 테이블 구성은 `aws-s3`라는 단일 AWS 관리형 테이블 버킷에 저장됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionsToWorkWithMetadataTables",
"Effect": "Allow",
"Action": [
"s3:CreateBucketMetadataTableConfiguration",
"s3:GetBucketMetadataTableConfiguration",
"s3:DeleteBucketMetadataTableConfiguration",
"s3:UpdateBucketMetadataJournalTableConfiguration",
"s3:UpdateBucketMetadataInventoryTableConfiguration",
"s3tables:*",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/*"
]
}
]
}
```
------
메타데이터 테이블을 쿼리하려면 다음 예제 정책을 사용할 수 있습니다. 메타데이터 테이블이 SSE-KMS로 암호화된 경우 표시된 대로 `kms:Decrypt` 권한이 필요합니다. 이 정책을 사용하려면 `user input placeholders`를 사용자의 정보로 대체합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionsToQueryMetadataTables",
"Effect": "Allow",
"Action": [
"s3tables:GetTable",
"s3tables:GetTableData",
"s3tables:GetTableMetadataLocation",
"kms:Decrypt"
],
"Resource": [
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/*"
]
}
]
}
```
------
# 메타데이터 테이블 구성 생성
완전관리형 Apache Iceberg 메타데이터 테이블에 Amazon S3 Metadata를 생성하고 저장하려면 범용 버킷에 대한 메타데이터 테이블 구성을 만듭니다. Amazon S3는 버킷에서 구성이 활성 상태인 한 메타데이터 테이블을 지속적으로 업데이트하여 데이터에 대한 최신 변경 사항을 반영하도록 설계되었습니다. 또한 Amazon S3는 메타데이터 테이블을 지속적으로 최적화하여 스토리지 비용을 줄이고 분석 쿼리 성능을 개선하는 데 도움을 줍니다.
각 범용 버킷에 대해 두 개의 보완적 메타데이터 테이블이 포함된 메타데이터 테이블 구성을 만들 수 있습니다.
+ **저널 테이블** - 기본적으로 메타데이터 테이블 구성에는 버킷의 객체에 대해 발생하는 이벤트를 캡처하는 *저널 테이블*이 포함되어 있습니다. 저널 테이블은 거의 실시간으로 데이터에 대한 변경 사항을 기록하므로 버킷에 업로드된 새 데이터를 식별하고, 최근에 삭제된 객체를 추적하고, 수명 주기 전환을 모니터링하는 등의 작업을 수행할 수 있습니다. 저널 테이블은 새 객체를 기록하고 객체 및 해당 메타데이터를 업데이트합니다(`PUT` 또는 `DELETE` 작업이 필요한 업데이트).
저널 테이블은 메타데이터 테이블 구성을 만든 후에 발생하는 변경 이벤트(예: 업로드, 업데이트 및 삭제)에 대한 메타데이터만 캡처합니다. 이 테이블은 쿼리가 가능하므로 간단한 SQL 쿼리를 통해 버킷의 변경 사항을 감사할 수 있습니다.
저널 테이블은 각 메타데이터 테이블 구성에 필요합니다. (S3 Metadata의 최초 릴리스에서는 저널 테이블을 "메타데이터 테이블"이라고 했습니다.)
저널 테이블에 저장되는 데이터에 대한 자세한 내용은 [S3 Metadata 저널 테이블 스키마](metadata-tables-schema.md) 섹션을 참조하세요.
스토리지 비용을 최소화하려면 저널 테이블 레코드 만료를 활성화하도록 선택할 수 있습니다. 자세한 내용은 [저널 테이블 레코드 만료시키기](metadata-tables-expire-journal-table-records.md) 섹션을 참조하세요.
+ **라이브 인벤토리 테이블** - 선택적으로 메타데이터 테이블 구성에 *라이브 인벤토리 테이블*을 추가할 수 있습니다. 라이브 인벤토리 테이블은 버킷의 모든 객체와 해당 버전에 대한 간단하고 쿼리 가능한 인벤토리를 제공하므로 데이터의 최신 상태를 확인할 수 있습니다.
라이브 인벤토리 테이블을 사용하면 다양한 워크로드에 대해 처리하려는 객체를 식별하여 비즈니스 워크플로와 빅 데이터 작업을 간소화하고 속도를 높일 수 있습니다. 예를 들어 라이브 인벤토리 테이블을 쿼리하여 특정 스토리지 클래스에 저장된 모든 객체, 특정 태그가 있는 모든 객체, AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 암호화되지 않은 모든 객체 등을 찾을 수 있습니다.
메타데이터 테이블 구성에 대해 라이브 인벤토리 테이블을 활성화하면 테이블은 *채우기*라는 프로세스를 거치며, 이 과정에서 Amazon S3는 범용 버킷을 스캔하여 버킷에 있는 모든 객체의 초기 메타데이터를 검색합니다. 버킷의 객체 수에 따라 이 프로세스는 몇 분(최소 15분)에서 몇 시간이 걸릴 수 있습니다. 채우기 프로세스가 완료되면 라이브 인벤토리 테이블의 상태가 **채우기**에서 **활성**으로 변경됩니다. 채우기가 완료되면 객체에 대한 업데이트는 일반적으로 1시간 이내에 라이브 인벤토리 테이블에 반영됩니다.
라이브 인벤토리 테이블 채우기에 대한 요금이 부과됩니다. 범용 버킷에 10억 개 이상의 객체가 있는 경우 라이브 인벤토리 테이블에 대한 월별 요금도 부과됩니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
라이브 인벤토리 테이블에 저장되는 데이터에 대한 자세한 내용은 [S3 Metadata 라이브 인벤토리 테이블 스키마](metadata-tables-inventory-schema.md) 섹션을 참조하세요.
메타데이터 테이블에는 메타데이터 테이블의 테이블 ID를 포함하는 다음과 같은 Amazon 리소스 이름(ARN) 형식이 있습니다.
`arn:aws:s3tables:region-code:account-id:bucket/aws-s3/table/table-id`
예를 들어 미국 동부(버지니아 북부) 리전의 메타데이터 테이블에는 다음과 같은 ARN이 있습니다.
`arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/a12bc345-67d8-912e-3456-7f89123g4h56`
저널 테이블의 이름은 `journal`이고 라이브 인벤토리 테이블의 이름은 `inventory`입니다.
메타데이터 테이블 구성을 만들 때 메타데이터 테이블이 AWS 관리형 테이블 버킷에 저장됩니다. 계정 및 동일한 리전의 모든 메타데이터 테이블 구성은 단일 AWS 관리형 테이블 버킷에 저장됩니다. 이러한 AWS 관리형 테이블 버킷의 이름은 `aws-s3`이며 다음 Amazon 리소스 이름(ARN) 형식을 갖습니다.
`arn:aws:s3tables:region:account_id:bucket/aws-s3`
예를 들어 계정 ID가 123456789012이고 범용 버킷이 미국 동부(버지니아 북부)(`us-east-1`)에 있는 경우 AWS 관리형 테이블 버킷도 미국 동부(버지니아 북부)(`us-east-1`)에서 만들어지며 ARN은 다음과 같습니다.
`arn:aws:s3tables:us-east-1:123456789012:bucket/aws-s3`
기본적으로 AWS 관리형 테이블 버킷은 Amazon S3 관리형 암호화 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 암호화됩니다. 첫 번째 메타데이터 구성을 만든 후 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)를 사용하도록 AWS 관리형 테이블 버킷의 기본 암호화 설정을 지정할 수 있습니다. 자세한 내용은 [Encryption for AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html#aws-managed-buckets-encryption) 및 [테이블 버킷에서 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화 지정](s3-tables-kms-specify.md) 섹션을 참조하세요.
AWS 관리형 테이블 버킷 내에서 구성의 메타데이터 테이블은 일반적으로 다음 이름 지정 형식의 네임스페이스에 저장됩니다.
`b_general-purpose-bucket-name`
메타데이터 테이블 네임스페이스에 대한 자세한 내용은 [메타데이터 테이블 작동 방식](metadata-tables-overview.md#metadata-tables-how-they-work) 섹션을 참조하세요.
메타데이터 테이블 구성을 만들 때 AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화로 AWS 관리형 메타데이터 테이블을 암호화하도록 선택할 수 있습니다. SSE-KMS를 사용하기로 선택한 경우 범용 버킷과 동일한 리전에 고객 관리형 KMS 키를 제공해야 합니다. 테이블을 만드는 중에만 테이블에 대한 암호화 유형을 설정할 수 있습니다. AWS 관리형 테이블이 만들어진 후에는 암호화 설정을 변경할 수 없습니다. 메타데이터 테이블에 SSE-KMS를 지정하려면 특정 권한이 있어야 합니다. 자세한 내용은 [Permissions for SSE-KMS](metadata-tables-permissions.md#metadata-kms-permissions)를 참조하세요.
메타데이터 테이블의 암호화 설정이 기본 버킷 수준 암호화 설정보다 우선합니다. 테이블에 암호화 설정을 지정하지 않으면 버킷의 기본 암호화 설정을 상속합니다.
AWS 관리형 테이블 버킷은 S3 Tables 할당량에 포함되지 않습니다. AWS 관리형 테이블 버킷 및 AWS 관리형 테이블 작업에 대한 자세한 내용은 [Working with AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html)를 참조하세요.
Amazon S3 콘솔, AWS Command Line Interface(AWS CLI), AWS SDK 또는 Amazon S3 REST API를 사용하여 메타데이터 테이블 구성을 생성할 수 있습니다.
**참고**
2025년 7월 15일 이전에 S3 Metadata 구성을 만든 경우 저널 테이블 레코드를 만료시키고 인벤토리 테이블을 만들 수 있도록 구성을 삭제하고 다시 만드는 것이 좋습니다. 자세한 내용은 [2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화](#metadata-tables-migration) 섹션을 참조하세요.
메타데이터 테이블 구성을 삭제하고 동일한 범용 버킷에 대한 구성을 다시 만들려면 먼저 AWS 관리형 테이블 버킷에서 이전 저널 및 인벤토리 테이블을 수동으로 삭제해야 합니다. 그러지 않으면 새 메타데이터 테이블 구성 만들기에 실패합니다. 해당 테이블이 이미 존재하기 때문입니다. 메타데이터 테이블을 삭제하려면 [메타데이터 테이블 삭제](metadata-tables-delete-table.md#delete-metadata-table-procedure) 섹션을 참조하세요.
메타데이터 테이블 구성을 삭제하면 구성만 삭제됩니다. 메타데이터 테이블 구성을 삭제하더라도 AWS 관리형 테이블 버킷과 메타데이터 테이블은 여전히 존재합니다.
**사전 조건**
메타데이터 테이블 구성을 만들기 전에 다음 사전 조건을 충족하는지 확인합니다.
+ 메타데이터 테이블 구성을 만들려면 메타데이터 테이블을 만들고 관리하는 데 필요한 AWS Identity and Access Management(IAM) 권한이 있는지 확인하세요. 자세한 내용은 [메타데이터 테이블 구성에 대한 권한 설정](metadata-tables-permissions.md) 섹션을 참조하세요.
+ Amazon Athena 또는 다른 AWS 쿼리 엔진을 사용하여 메타데이터 테이블을 쿼리하려는 경우 AWS 관리형 테이블 버킷을 AWS 분석 서비스와 통합해야 합니다. 자세한 내용은 [AWS 분석 서비스와 Amazon S3 Tables 통합](s3-tables-integrating-aws.md) 섹션을 참조하세요.
이 리전에 기존 테이블 버킷을 이미 통합한 경우, AWS 관리형 테이블 버킷도 자동으로 통합됩니다. 이 리전의 테이블 버킷에 대한 통합 상태를 확인하려면 Amazon S3 콘솔을 열고 왼쪽 탐색 창에서 **테이블 버킷**을 선택합니다. **AWS 분석 서비스와의 통합**에서 리전을 확인하고 통합 상태가 **활성화됨**인지 확인합니다.
## 메타데이터 테이블 구성 생성
### S3 콘솔 사용
**메타데이터 테이블 구성을 생성하는 방법**
메타데이터 테이블 구성을 생성하기 전에 [사전 조건](#metadata-table-config-prereqs)을 검토하고 충족했는지 확인하고 [메타데이터 테이블의 한계 및 제한](metadata-tables-restrictions.md) 섹션을 검토합니다.
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.
1. 메타데이터 테이블 구성을 생성할 범용 버킷을 선택합니다.
**참고**
이 범용 버킷이 테이블 버킷을 사용할 수 있는 AWS 리전인지 확인합니다. 테이블 버킷은 미국 동부(버지니아 북부), 미국 동부(오하이오) 및 미국 서부(오리건) 리전에서만 사용할 수 있습니다.
1. 버킷의 세부 정보 페이지에서 **메타데이터** 탭을 선택합니다.
1. **메타데이터** 탭에서 **메타데이터 구성 생성**을 선택합니다.
1. **메타데이터 구성 생성** 페이지의 **저널 테이블**에서 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 테이블을 암호화할지 여부를 선택할 수 있습니다. 기본적으로 저널 테이블은 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 암호화됩니다.
SSE-KMS를 사용하기로 선택한 경우 범용 버킷과 동일한 리전에 고객 관리형 KMS 키를 제공해야 합니다.
**중요**
테이블을 만드는 중에만 메타데이터 테이블에 대한 암호화 유형을 설정할 수 있습니다. AWS 관리형 테이블이 만들어진 후에는 암호화 설정을 변경할 수 없습니다.
+ SSE-S3(기본값)로 저널 테이블을 암호화하려면 **암호화 유형을 지정하지 않음**을 선택합니다.
+ SSE-KMS로 저널 테이블을 암호화하려면 **암호화 유형 지정**을 선택합니다. **암호화 유형**에서 **AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)**를 선택합니다. **AWS KMS 키**에서 기존 KMS 키 중에 선택하거나 KMS 키 ARN을 입력합니다. 아직 KMS 키가 없는 경우 **KMS 키 ARN 입력**을 선택한 다음 **KMS 키 생성**을 선택합니다.
SSE-KMS에 필요한 권한을 설정했는지 확인합니다. 자세한 내용은 [Permissions for SSE-KMS](metadata-tables-permissions.md#metadata-kms-permissions)를 참조하세요.
1. (선택 사항) 기본적으로 저널 테이블의 레코드는 만료되지 않습니다. 저널 테이블의 스토리지 비용을 최소화하려면 **레코드 만료**에서 **활성화**를 선택합니다.
저널 테이블 레코드 만료를 활성화하면 저널 테이블 레코드를 보존할 일수를 설정할 수 있습니다. **레코드가 만료되는 일수** 값을 설정하려면 `7`\$1`2147483647` 사이의 정수를 지정할 수 있습니다. 예를 들어 저널 테이블 레코드를 1년 동안 유지하려면 이 값을 `365`로 설정합니다.
레코드는 만료 대상이 된 후 24\$148시간 이내에 만료됩니다.
**중요**
저널 테이블 레코드가 만료된 후에는 복구할 수 없습니다.
**저널 테이블 레코드가 지정된 일수 후에 만료됨**에서 확인란을 선택합니다.
1. (선택 사항) 메타데이터 테이블 구성에 인벤토리 테이블을 추가하려면 **라이브 인벤토리 테이블**에서 **구성 상태**에 대해 **활성화됨**을 선택합니다.
AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 테이블을 암호화할지 여부를 선택할 수 있습니다. 기본적으로 인벤토리 테이블은 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 암호화됩니다.
SSE-KMS를 사용하기로 선택한 경우 범용 버킷과 동일한 리전에 고객 관리형 KMS 키를 제공해야 합니다.
**중요**
테이블을 만드는 중에만 메타데이터 테이블에 대한 암호화 유형을 설정할 수 있습니다. AWS 관리형 테이블이 만들어진 후에는 암호화 설정을 변경할 수 없습니다.
+ SSE-S3(기본값)로 인벤토리 테이블을 암호화하려면 **암호화 유형을 지정하지 않음**을 선택합니다.
+ SSE-KMS로 인벤토리 테이블을 암호화하려면 **암호화 유형 지정**을 선택합니다. **암호화 유형**에서 **AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)**를 선택합니다. **AWS KMS 키**에서 기존 KMS 키 중에 선택하거나 KMS 키 ARN을 입력합니다. 아직 KMS 키가 없는 경우 **KMS 키 ARN 입력**을 선택한 다음 **KMS 키 생성**을 선택합니다.
SSE-KMS에 필요한 권한을 설정했는지 확인합니다. 자세한 내용은 [Permissions for SSE-KMS](metadata-tables-permissions.md#metadata-kms-permissions)를 참조하세요.
1. **메타데이터 테이블 구성 생성**을 선택합니다.
메타데이터 테이블 구성이 성공하면 메타데이터 테이블의 이름과 ARN이 AWS 관리형 테이블 버킷 및 네임스페이스의 이름과 함께 **메타데이터** 탭에 표시됩니다.
메타데이터 테이블 구성에 인벤토리 테이블을 활성화하도록 선택한 경우 테이블은 *채우기*라는 프로세스를 거치며,이 과정에서 Amazon S3는 범용 버킷을 스캔하여 버킷에 있는 모든 객체의 초기 메타데이터를 검색합니다. 버킷의 객체 수에 따라 이 프로세스는 몇 분(최소 15분)에서 몇 시간이 걸릴 수 있습니다. 채우기 프로세스가 완료되면 인벤토리 테이블의 상태가 **채우기**에서 **활성**으로 변경됩니다. 채우기가 완료되면 객체에 대한 업데이트는 일반적으로 1시간 이내에 인벤토리 테이블에 반영됩니다.
메타데이터 테이블 구성에 대한 업데이트를 모니터링하려면 AWS CloudTrail을 사용할 수 있습니다. 자세한 내용은 [CloudTrail 로깅을 통해 추적되는 Amazon S3 버킷 수준 작업](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking) 섹션을 참조하세요.
### AWS CLI 사용
다음 명령을 실행하려면 AWS CLI를 설치하고 구성해야 합니다. AWS CLI를 설치하지 않은 경우 *AWS Command Line Interface 사용 설명서*에서 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)를 참조하세요.
또는 AWS CloudShell을 사용하여 콘솔에서 AWS CLI 명령을 실행할 수 있습니다. AWS CloudShell은 브라우저 기반의 사전 인증된 쉘로, AWS Management Console에서 직접 시작할 수 있습니다. 자세한 내용은 *AWS CloudShell 사용 설명서*에서 [CloudShell이란 무엇인가요?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) 및 [AWS CloudShell 시작하기](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)를 참조하세요.
**AWS CLI를 사용하여 메타데이터 테이블 구성을 생성하는 방법**
메타데이터 테이블 구성을 생성하기 전에 [사전 조건](#metadata-table-config-prereqs)을 검토하고 충족했는지 확인하고 [메타데이터 테이블의 한계 및 제한](metadata-tables-restrictions.md) 섹션을 검토합니다.
다음 예제 명령을 사용하려면 `user input placeholders`를 사용자의 정보로 대체하세요.
1. 메타데이터 테이블 구성이 포함된 JSON 파일을 생성하고 저장합니다(예: `metadata-config.json`). 다음은 샘플 구성입니다.
저널 테이블 레코드 만료를 활성화할지 또는 비활성화할지 지정해야 합니다. 레코드 만료를 활성화하도록 선택한 경우 저널 테이블 레코드가 만료되기 전의 일수도 지정해야 합니다. `Days` 값을 설정하려면 `7` 및 `2147483647` 사이의 정수를 지정할 수 있습니다. 예를 들어 저널 테이블 레코드를 1년 동안 유지하려면 이 값을 `365`로 설정합니다.
선택적으로 인벤토리 테이블을 구성하도록 선택할 수 있습니다.
저널 테이블과 인벤토리 테이블 모두에 대해 선택적으로 암호화 구성을 지정할 수 있습니다. 기본적으로 메타데이터 테이블은 `SseAlgorithm`을 `AES256`으로 설정하여 지정할 수 있는 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)로 암호화됩니다.
AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 메타데이터 테이블을 암호화하려면 `SseAlgorithm`을 `aws:kms`로 설정합니다. 또한 범용 버킷이 위치한 동일한 리전에서 고객 관리형 KMS 키의 ARN으로 `KmsKeyArn`을 설정해야 합니다.
```
{
"JournalTableConfiguration": {
"RecordExpiration": {
"Expiration": "ENABLED",
"Days": 10
},
"EncryptionConfiguration": {
"SseAlgorithm": "AES256"
}
},
"InventoryTableConfiguration": {
"ConfigurationState": "ENABLED",
"EncryptionConfiguration": {
"SseAlgorithm": "aws:kms",
"KmsKeyArn": "arn:aws:kms:us-east-2:account-id:key/key-id"
}
}
}
```
1. 다음 명령을 사용하여 메타데이터 테이블 구성을 범용 버킷에 적용합니다(예: `amzn-s3-demo-bucket`).
```
aws s3api create-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--metadata-configuration file://./metadata-config.json \
--region us-east-2
```
1. 구성이 추가되었는지 확인하려면 다음 명령을 사용합니다.
```
aws s3api get-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
메타데이터 테이블 구성에 대한 업데이트를 모니터링하려면 AWS CloudTrail을 사용할 수 있습니다. 자세한 내용은 [CloudTrail 로깅을 통해 추적되는 Amazon S3 버킷 수준 작업](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking) 섹션을 참조하세요.
### REST API 사용
REST 요청을 전송하여 메타데이터 테이블 구성을 생성할 수 있습니다. 자세한 내용은 **Amazon S3 API 참조의 [https://docs.aws.amazon.com//AmazonS3/latest/API/API_CreateBucketMetadataConfiguration.html](https://docs.aws.amazon.com//AmazonS3/latest/API/API_CreateBucketMetadataConfiguration.html) 섹션을 참조하세요.
### AWS SDK 사용
AWS SDK를 사용하여 Amazon S3에서 메타데이터 테이블 구성을 생성할 수 있습니다. 자세한 내용은 *Amazon S3 API 참조*의 [지원되는 SDK 목록](https://docs.aws.amazon.com//AmazonS3/latest/API/API_CreateBucketMetadataConfiguration.html#API_CreateBucketMetadataConfiguration_SeeAlso)을 참조하세요.
## 2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화
2025년 7월 15일 이전에 S3 Metadata 구성을 만든 경우 저널 테이블 레코드를 만료시키고 인벤토리 테이블을 만들 수 있도록 구성을 삭제하고 다시 만드는 것이 좋습니다. 이전 구성을 삭제하고 새 구성을 만드는 사이에 발생하는 범용 버킷의 변경 사항은 저널 테이블 중 하나에 기록되지 않습니다.
이전 메타데이터 구성에서 새 구성으로 마이그레이션하려면 다음을 수행합니다.
1. 기존 메타데이터 테이블 구성을 삭제합니다. 단계별 지침은 [메타데이터 테이블 구성 삭제](metadata-tables-delete-configuration.md)섹션을 참조하세요.
1. 메타데이터 테이블 구성을 만듭니다. 단계별 지침은 [메타데이터 테이블 구성 생성](#metadata-tables-create-configuration)섹션을 참조하세요.
구성 마이그레이션에 도움이 필요한 경우 AWS Support에 문의하세요.
새 메타데이터 구성을 만든 후에는 두 개의 저널 테이블이 있게 됩니다. 이전 저널 테이블이 더 이상 필요하지 않은 경우 삭제할 수 있습니다. 단계별 지침은 [메타데이터 테이블 삭제](metadata-tables-delete-table.md)섹션을 참조하세요. 이전 저널 테이블을 유지하고 새 테이블과 조인하려는 경우 [S3 메타데이터 테이블과 사용자 지정 메타데이터 조인](metadata-tables-join-custom-metadata.md) 섹션에서 두 테이블을 조인하는 방법에 대한 예를 참조하세요.
마이그레이션 후 다음을 수행할 수 있습니다.
1. 이제 `GetBucketMetadataConfiguration` API 작업을 사용하여 구성을 볼 수 있습니다. 구성이 이전 구성인지 새 구성인지 확인하려면 `GetBucketMetadataConfiguration` API 응답의 다음 속성을 볼 수 있습니다. AWS 관리형 버킷 유형(`"aws"`)은 새 구성을 나타내고 고객 관리형 버킷 유형(`"customer"`)은 이전 구성을 나타냅니다.
```
"MetadataTableConfigurationResult": {
"TableBucketType": ["aws" | "customer"]
```
자세한 내용은 [메타데이터 테이블 구성 보기](metadata-tables-view-configuration.md) 섹션을 참조하세요.
**참고**
`GetBucketMetadataConfiguration` 및 `DeleteBucketMetadataConfiguration` API 작업을 이전 또는 새 메타데이터 테이블 구성과 함께 사용할 수 있습니다. 그러나 새 구성에서 `GetBucketMetadataTableConfiguration` 및 `DeleteBucketMetadataTableConfiguration` API 작업을 사용하려고 하면 HTTP `405 Method Not Allowed` 오류가 발생합니다.
이전 API 작업 대신 새 API 작업(`CreateBucketMetadataConfiguration`, `GetBucketMetadataConfiguration` 및 `DeleteBucketMetadataConfiguration`)을 사용하도록 프로세스를 업데이트해야 합니다.
1. Amazon Athena 또는 다른 AWS 쿼리 엔진을 사용하여 메타데이터 테이블을 쿼리하려는 경우 AWS 관리형 테이블 버킷을 AWS 분석 서비스와 통합해야 합니다. 이 리전에 기존 테이블 버킷을 이미 통합한 경우, AWS 관리형 테이블 버킷도 자동으로 통합됩니다. 자세한 내용은 [AWS 분석 서비스와 Amazon S3 Tables 통합](s3-tables-integrating-aws.md) 섹션을 참조하세요.
# 메타데이터 테이블에 대한 액세스 제어
Amazon S3 메타데이터 테이블에 대한 액세스를 제어하기 위해 테이블 버킷 및 메타데이터 테이블에 연결된 AWS Identity and Access Management(IAM) 리소스 기반 정책을 사용할 수 있습니다. 즉, 테이블 버킷 수준과 테이블 수준 모두에서 메타데이터 테이블에 대한 액세스를 제어할 수 있습니다.
테이블 버킷 및 테이블에 대한 액세스 제어에 대한 자세한 내용은 [Access management for S3 Tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-setting-up.html)을 참조하세요.
**중요**
테이블 버킷 또는 테이블 정책을 만들거나 업데이트할 때 Amazon S3 위탁자 `metadata.s3.amazonaws.com` 및 `maintenance.s3tables.amazonaws.com`이 테이블 버킷 또는 메타데이터 테이블에 쓰는 것을 제한하지 않아야 합니다.
Amazon S3가 테이블 버킷 또는 메타데이터 테이블에 쓸 수 없는 경우 메타데이터 구성을 삭제하고 메타데이터 테이블을 삭제한 다음 새 구성을 만들어야 합니다. 구성에 인벤토리 테이블이 있는 경우 새 인벤토리 테이블을 만들어야 하며 새 인벤토리 테이블을 채우면 요금이 다시 청구됩니다.
AWS Lake Formation을 통해 메타데이터 테이블의 행 및 열에 대한 액세스를 제어할 수도 있습니다. 자세한 내용은 *AWS Lake Formation 개발자 안내서*의 [Managing Lake Formation permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html) 및 [Data filtering and cell-level security in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/data-filtering.html)을 참조하세요.
# 저널 테이블 레코드 만료시키기
기본적으로 저널 테이블의 레코드는 만료되지 않습니다. 저널 테이블의 스토리지 비용을 최소화하기 위해 저널 테이블 레코드 만료를 활성화할 수 있습니다.
**참고**
2025년 7월 15일 이전에 S3 Metadata 구성을 만든 경우 해당 구성에서 저널 테이블 레코드 만료를 활성화할 수 없습니다. 저널 테이블 레코드를 만료시키고 인벤토리 테이블을 만들 수 있도록 구성을 삭제하고 다시 만드는 것이 좋습니다. 자세한 내용은 [2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화](metadata-tables-create-configuration.md#metadata-tables-migration) 섹션을 참조하세요.
저널 테이블 레코드 만료를 활성화하면 저널 테이블 레코드를 보존할 일수를 설정할 수 있습니다. 이 값을 설정하려면 `7` 및 `2147483647` 사이의 정수를 지정합니다. 예를 들어 저널 테이블 레코드를 1년 동안 유지하려면 이 값을 `365`로 설정합니다.
**중요**
저널 테이블 레코드가 만료된 후에는 복구할 수 없습니다.
레코드는 만료 대상이 된 후 24\$148시간 이내에 만료됩니다. 저널 레코드는 최신 스냅샷에서 제거됩니다. 삭제된 레코드의 데이터 및 스토리지는 테이블 유지 관리 작업을 통해 제거됩니다.
저널 테이블 레코드 만료를 활성화한 경우 언제든지 비활성화하여 저널 테이블 레코드 만료를 중지할 수 있습니다.
Amazon S3 콘솔, AWS Command Line Interface(AWS CLI), AWS SDK 또는 Amazon S3 REST API를 사용하여 저널 테이블 레코드를 만들 수 있습니다.
## 저널 테이블 레코드를 만료시키는 방법
### S3 콘솔 사용
**저널 테이블 레코드 만료시키기**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.
1. 레코드를 만료시키려는 저널 테이블이 있는 메타데이터 테이블 구성이 포함된 범용 버킷을 선택합니다.
1. 버킷의 세부 정보 페이지에서 **메타데이터** 탭을 선택합니다.
1. **메타데이터** 탭에서 **편집**을 선택한 다음 **저널 테이블 레코드 만료 편집**을 선택합니다.
1. **저널 테이블 레코드 만료 편집** 페이지의 **레코드 만료**에서 **활성화됨**을 선택합니다.
1. 저널 테이블 레코드를 유지할 일수를 설정합니다. **레코드가 만료되는 일수** 값을 설정하려면 `7`\$1`2147483647` 사이의 정수를 지정합니다. 예를 들어 저널 테이블 레코드를 1년 동안 유지하려면 이 값을 `365`로 설정합니다.
**중요**
저널 테이블 레코드가 만료된 후에는 복구할 수 없습니다.
1. **저널 테이블 레코드가 지정된 일수 후에 만료됨**에서 확인란을 선택합니다.
1. **변경 사항 저장**을 선택합니다.
저널 테이블 레코드 만료를 비활성화하려면 이전 단계를 반복하되 6단계에서 **활성화됨** 대신 **비활성화됨**을 선택합니다.
### AWS CLI 사용
다음 명령을 실행하려면 AWS CLI를 설치하고 구성해야 합니다. AWS CLI를 설치하지 않은 경우 *AWS Command Line Interface 사용 설명서*의 [Install or update to the latest version of the AWS CLI](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)를 참조하세요.
AWS CloudShell을 사용하여 콘솔에서 AWS CLI 명령을 실행할 수도 있습니다. AWS CloudShell은 브라우저 기반의 사전 인증된 쉘로, AWS Management Console에서 직접 시작할 수 있습니다. 자세한 내용은 *AWS CloudShell 사용 설명서*에서 [CloudShell이란 무엇인가요?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) 및 [AWS CloudShell 시작하기](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)를 참조하세요.
**AWS CLI를 사용하여 저널 테이블 레코드 만료시키기**
다음 예제 명령을 사용하려면 `user input placeholders`를 사용자의 정보로 대체하세요.
1. 저널 테이블 구성이 포함된 JSON 파일을 만들고 저장합니다(예: `journal-config.json`). 다음은 샘플 구성입니다.
`Days` 값을 설정하려면 `7` 및 `2147483647` 사이의 정수를 지정합니다. 예를 들어 저널 테이블 레코드를 1년 동안 유지하려면 이 값을 `365`로 설정합니다.
```
{
"RecordExpiration": {
"Expiration": "ENABLED",
"Days": 10
}
}
```
저널 테이블 레코드 만료를 비활성화하려면 대신 다음 샘플 구성을 만듭니다. `Expiration`가 `DISABLED`로 설정된 경우 구성에서 `Days` 값을 지정해서는 안 됩니다.
```
{
"RecordExpiration": {
"Expiration": "DISABLED"
}
}
```
1. 다음 명령을 사용하여 범용 버킷의 저널 테이블에서 레코드를 만료시킵니다(예: `amzn-s3-demo-bucket`).
```
aws s3api update-bucket-metadata-journal-table-configuration \
--bucket amzn-s3-demo-bucket \
--journal-table-configuration file://./journal-config.json \
--region us-east-2
```
### REST API 사용
REST 요청을 전송하여 저널 테이블 레코드를 만료시킬 수 있습니다. [자세한 내용은 UpdateBucketMetadataJournalTableConfiguration 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataJournalTableConfiguration.html)
### AWS SDK 사용
AWS SDK를 사용하여 Amazon S3에서 저널 테이블 레코드를 만료시킬 수 있습니다. 자세한 내용은 [지원되는 SDK 목록](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataJournalTableConfiguration.html#API_UpdateBucketMetadataJournalTableConfiguration_SeeAlso)을 참조하세요.
# 라이브 인벤토리 테이블 활성화 또는 비활성화
기본적으로 메타데이터 테이블 구성에는 버킷의 객체에 대해 발생하는 이벤트를 기록하는 *저널 테이블*이 포함되어 있습니다. 저널 테이블은 각 메타데이터 테이블 구성에 필요합니다.
선택적으로 메타데이터 테이블 구성에 *라이브 인벤토리 테이블*을 추가할 수 있습니다. 라이브 인벤토리 테이블은 버킷의 모든 객체와 해당 버전에 대한 간단하고 쿼리 가능한 인벤토리를 제공하므로 데이터의 최신 상태를 확인할 수 있습니다.
**참고**
2025년 7월 15일 이전에 S3 Metadata 구성을 만든 경우 해당 구성에서 인벤토리 테이블을 활성화할 수 없습니다. 인벤토리 테이블을 만들고 저널 테이블 레코드를 만료시킬 수 있도록 구성을 삭제하고 다시 만드는 것이 좋습니다. 자세한 내용은 [2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화](metadata-tables-create-configuration.md#metadata-tables-migration) 섹션을 참조하세요.
인벤토리 테이블에는 버킷의 모든 객체에 대한 최신 메타데이터가 포함되어 있습니다. 이 표를 사용하여 다양한 워크로드에 대해 처리하려는 객체를 식별하여 비즈니스 워크플로와 빅 데이터 작업을 간소화하고 속도를 높일 수 있습니다. 예를 들어 인벤토리 테이블을 쿼리하여 다음을 수행할 수 있습니다.
+ S3 Glacier Deep Archive 스토리지 클래스에 저장된 모든 객체를 찾습니다.
+ 객체 태그 배포를 생성하거나 태그가 없는 객체를 찾습니다.
+ AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)를 사용하여 암호화되지 않은 모든 객체를 찾습니다.
+ 서로 다른 두 시점의 인벤토리 테이블을 비교하여 특정 태그가 있는 객체의 증가를 파악합니다.
메타데이터 테이블 구성에 인벤토리 테이블을 활성화하도록 선택한 경우 테이블은 *채우기*라는 프로세스를 거치며,이 과정에서 Amazon S3는 범용 버킷을 스캔하여 버킷에 있는 모든 객체의 초기 메타데이터를 검색합니다. 버킷의 객체 수에 따라 이 프로세스는 몇 분(최소 15분)에서 몇 시간이 걸릴 수 있습니다. 채우기 프로세스가 완료되면 인벤토리 테이블의 상태가 **채우기**에서 **활성**으로 변경됩니다. 채우기가 완료되면 객체에 대한 업데이트는 일반적으로 1시간 이내에 인벤토리 테이블에 반영됩니다.
**참고**
인벤토리 테이블 채우기에 대한 요금이 부과됩니다. 범용 버킷에 10억 개 이상의 객체가 있는 경우 인벤토리 테이블에 대한 월별 요금도 부과됩니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
인벤토리 테이블에 대한 업데이트를 일시 중지한 다음 재개할 수 없습니다. 그러나 인벤토리 테이블 구성을 비활성화할 수는 있습니다. 인벤토리 테이블을 비활성화해도 삭제되지는 않습니다. 인벤토리 테이블은 삭제하기로 결정할 때까지 레코드에 유지됩니다.
인벤토리 테이블을 비활성화한 후 나중에 다시 활성화하려면 먼저 AWS 관리형 테이블 버킷에서 이전 인벤토리 테이블을 삭제해야 합니다. 인벤토리 테이블 구성을 다시 활성화하면 Amazon S3가 새 인벤토리 테이블을 만들고 새 인벤토리 테이블을 채우는 데 따른 요금이 다시 청구됩니다.
Amazon S3 콘솔, AWS Command Line Interface(AWS CLI), AWS SDK 또는 Amazon S3 REST API를 사용하여 인벤토리 테이블을 활성화 또는 비활성화할 수 있습니다.
**사전 조건**
인벤토리 테이블을 비활성화한 후 다시 활성화하려면 먼저 AWS 관리형 테이블 버킷에서 이전 인벤토리 테이블을 수동으로 삭제해야 합니다. 그러지 않으면 인벤토리 테이블이 테이블 버킷에 이미 존재하기 때문에 인벤토리 테이블을 다시 활성화하지 못합니다. 인벤토리 테이블을 삭제하려면 [메타데이터 테이블 삭제](metadata-tables-delete-table.md#delete-metadata-table-procedure) 섹션을 참조하세요.
인벤토리 테이블 구성을 다시 활성화하면 Amazon S3가 새 인벤토리 테이블을 만들고 새 인벤토리 테이블을 채우는 데 따른 요금이 다시 청구됩니다.
## 인벤토리 테이블 활성화 또는 비활성화
### S3 콘솔 사용
**인벤토리 테이블 활성화 또는 비활성화**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.
1. 인벤토리 테이블을 활성화하거나 비활성화하려는 메타데이터 테이블 구성이 있는 범용 버킷을 선택합니다.
1. 버킷의 세부 정보 페이지에서 **메타데이터** 탭을 선택합니다.
1. **메타데이터** 탭에서 **편집**을 선택한 다음 **인벤토리 테이블 구성 편집**을 선택합니다.
1. **인벤토리 테이블 구성 편집** 페이지의 **인벤토리 테이블**에서 **활성화됨** 또는 **비활성화됨**을 선택합니다.
**참고**
**활성화됨**을 선택하기 전에 [사전 조건](#inventory-table-config-prereqs)을 검토하고 충족했는지 확인합니다.
+ **활성화됨**을 선택한 경우 AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화로 테이블을 암호화할지 여부를 선택할 수 있습니다. 기본적으로 인벤토리 테이블은 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 암호화됩니다.
SSE-KMS를 사용하기로 선택한 경우 범용 버킷과 동일한 리전에 고객 관리형 KMS 키를 제공해야 합니다.
**중요**
테이블을 만드는 중에만 메타데이터 테이블에 대한 암호화 유형을 설정할 수 있습니다. AWS 관리형 테이블이 만들어진 후에는 암호화 설정을 변경할 수 없습니다.
+ SSE-S3(기본값)로 인벤토리 테이블을 암호화하려면 **암호화 유형을 지정하지 않음**을 선택합니다.
+ SSE-KMS로 인벤토리 테이블을 암호화하려면 **암호화 유형 지정**을 선택합니다. **암호화 유형**에서 **AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)**를 선택합니다. **AWS KMS 키**에서 기존 KMS 키 중에 선택하거나 KMS 키 ARN을 입력합니다. 아직 KMS 키가 없는 경우 **KMS 키 ARN 입력**을 선택한 다음 **KMS 키 생성**을 선택합니다.
+ **비활성화**를 선택한 경우 **인벤토리 테이블이 비활성화된 후 테이블이 더 이상 업데이트되지 않고 업데이트를 재개할 수 없음** 아래의 확인란을 선택합니다.
1. **변경 사항 저장**을 선택합니다.
### AWS CLI 사용
다음 명령을 실행하려면 AWS CLI를 설치하고 구성해야 합니다. AWS CLI를 설치하지 않은 경우 *AWS Command Line Interface 사용 설명서*에서 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)를 참조하세요.
또는 AWS CloudShell을 사용하여 콘솔에서 AWS CLI 명령을 실행할 수 있습니다. AWS CloudShell은 브라우저 기반의 사전 인증된 쉘로, AWS Management Console에서 직접 시작할 수 있습니다. 자세한 내용은 *AWS CloudShell 사용 설명서*에서 [CloudShell이란 무엇인가요?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) 및 [AWS CloudShell 시작하기](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)를 참조하세요.
**AWS CLI를 사용하여 인벤토리 테이블 활성화 또는 비활성화**
다음 예제 명령을 사용하려면 `user input placeholders`를 사용자의 정보로 대체하세요.
**참고**
인벤토리 구성을 활성화하기 전에 [사전 조건](#inventory-table-config-prereqs)을 검토하고 충족했는지 확인합니다.
1. 인벤토리 테이블 구성이 포함된 JSON 파일을 만들고 저장합니다(예: `inventory-config.json`). 다음은 새 인벤토리 테이블을 활성화하기 위한 샘플 구성입니다.
인벤토리 테이블을 활성화하는 경우 선택적으로 암호화 구성을 지정할 수 있습니다. 기본적으로 메타데이터 테이블은 `SseAlgorithm`을 `AES256`으로 설정하여 지정할 수 있는 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)로 암호화됩니다.
AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 인벤토리 테이블을 암호화하려면 `SseAlgorithm`을 `aws:kms`로 설정합니다. 또한 범용 버킷이 위치한 동일한 리전에서 고객 관리형 KMS 키의 ARN으로 `KmsKeyArn`을 설정해야 합니다.
```
{
"ConfigurationState": "ENABLED",
"EncryptionConfiguration": {
"SseAlgorithm": "aws:kms",
"KmsKeyArn": "arn:aws:kms:us-east-2:account-id:key/key-id"
}
}
```
기존 인벤토리 테이블을 비활성화하려면 다음 구성을 사용합니다.
```
{
"ConfigurationState": "DISABLED" }
}
```
1. 다음 명령을 사용하여 인벤토리 테이블 구성을 범용 버킷에 업데이트합니다(예: `amzn-s3-demo-bucket`).
```
aws s3api update-bucket-metadata-inventory-table-configuration \
--bucket amzn-s3-demo-source-bucket \
--inventory-table-configuration file://./inventory-config.json \
--region us-east-2
```
### REST API 사용
REST 요청을 전송하여 인벤토리 테이블을 활성화하거나 비활성화할 수 있습니다. [자세한 내용은 UpdateBucketMetadataInventoryTableConfiguration 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataInventoryTableConfiguration.html)
### AWS SDK 사용
AWS SDK를 사용하여 Amazon S3에서 인벤토리 테이블을 활성화하거나 비활성화할 수 있습니다. 자세한 내용은 [지원되는 SDK 목록](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataInventoryTableConfiguration.html#API_UpdateBucketMetadataInventoryTableConfiguration_SeeAlso)을 참조하세요.
# 메타데이터 테이블 구성 보기
범용 버킷에 대한 메타데이터 테이블 구성을 만든 경우, 인벤토리 테이블이 활성화되었는지 여부 또는 저널 테이블 레코드 만료가 활성화되었는지 여부와 같은 구성에 대한 정보를 볼 수 있습니다. 저널 및 인벤토리 테이블의 상태를 볼 수도 있습니다.
Amazon S3 콘솔, AWS Command Line Interface(AWS CLI), AWS SDK 또는 Amazon S3 REST API를 사용하여 범용 버킷에 대한 메타데이터 테이블 구성을 볼 수 있습니다.
## 메타데이터 테이블 구성 보기
### S3 콘솔 사용
**메타데이터 테이블 구성 보기**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.
1. 보려는 메타데이터 테이블 구성이 포함된 범용 버킷을 선택합니다.
1. 버킷의 세부 정보 페이지에서 **메타데이터** 탭을 선택합니다.
1. **메타데이터** 탭에서 **메타데이터 구성** 섹션까지 아래로 스크롤합니다. **저널 테이블** 및 **인벤토리 테이블** 섹션에서 Amazon 리소스 이름(ARN), 테이블 상태, 저널 테이블 레코드 만료 또는 인벤토리 테이블 활성화 여부 등 이러한 구성에 대한 다양한 정보를 볼 수 있습니다.
### AWS CLI 사용
다음 명령을 실행하려면 AWS CLI를 설치하고 구성해야 합니다. AWS CLI를 설치하지 않은 경우 *AWS Command Line Interface 사용 설명서*에서 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)를 참조하세요.
또는 AWS CloudShell을 사용하여 콘솔에서 AWS CLI 명령을 실행할 수 있습니다. AWS CloudShell은 브라우저 기반의 사전 인증된 쉘로, AWS Management Console에서 직접 시작할 수 있습니다. 자세한 내용은 *AWS CloudShell 사용 설명서*에서 [CloudShell이란 무엇인가요?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) 및 [AWS CloudShell 시작하기](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)를 참조하세요.
**AWS CLI를 사용하여 메타데이터 테이블 구성을 보는 방법**
다음 예시 명령을 사용하려면 `user input placeholders`를 실제 정보로 대체하세요.
1. 다음 명령을 사용하여 범용 버킷에 대한 메타데이터 테이블 구성을 봅니다(예: `amzn-s3-demo-bucket`).
```
aws s3api get-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
1. 이 명령의 출력을 보고 메타데이터 테이블 구성의 상태를 확인합니다. 예제:
```
{
"GetBucketMetadataConfigurationResult": {
"MetadataConfigurationResult": {
"DestinationResult": {
"TableBucketType": "aws",
"TableBucketArn": "arn:aws:s3tables:us-east-2:111122223333:bucket/aws-managed-s3-111122223333-us-east-2",
"TableNamespace": "b_general-purpose-bucket-name"
},
"JournalTableConfigurationResult": {
"TableStatus": "ACTIVE",
"TableName": "journal",
"TableArn": "arn:aws:s3tables:us-east-2:111122223333:bucket/aws-managed-s3-111122223333-us-east-2/table/0f01234c-fe7a-492f-a4c7-adec3864ea85",
"EncryptionConfiguration": {
"SseAlgorithm": "AES256"
},
"RecordExpiration": {
"Expiration": "ENABLED",
"Days": 10
}
},
"InventoryTableConfigurationResult": {
"ConfigurationState": "ENABLED",
"TableStatus": "BACKFILL_COMPLETE",
"TableName": "inventory",
"TableArn": "arn:aws:s3tables:us-east-2:111122223333:bucket/aws-managed-s3-111122223333-us-east-2/table/e123456-b876-4e5e-af29-bb055922ee4d",
"EncryptionConfiguration": {
"SseAlgorithm": "AES256"
}
}
}
}
}
```
### REST API 사용
REST 요청을 전송하여 메타데이터 테이블 구성을 볼 수 있습니다. [자세한 내용은 GetBucketMetadataTableConfiguration 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketMetadataTableConfiguration.html)
**참고**
V1 또는 V2 메타데이터 테이블 구성으로 V2 `GetBucketMetadataConfiguration` API 작업을 사용할 수 있습니다. 그러나 V2 구성으로 V1 `GetBucketMetadataTableConfiguration` API 작업을 사용하려고 하면 HTTP `405 Method Not Allowed` 오류가 발생합니다.
### AWS SDK 사용
AWS SDK를 사용하여 Amazon S3에서 메타데이터 테이블 구성을 삭제할 수 있습니다. 자세한 내용은 [지원되는 SDK 목록](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketMetadataTableConfiguration.html#API_GetBucketMetadataTableConfiguration_SeeAlso)을 참조하세요.
# 메타데이터 테이블 구성 삭제
Amazon S3 범용 버킷에 대한 메타데이터 테이블 구성 업데이트를 중지하려면 버킷에 연결된 메타데이터 테이블 구성을 삭제하면 됩니다. 메타데이터 테이블 구성을 삭제하면 구성만 삭제됩니다. 메타데이터 테이블 구성을 삭제하더라도 AWS 관리형 테이블 버킷과 메타데이터 테이블은 여전히 존재합니다. 그러나 메타데이터 테이블은 더 이상 업데이트되지 않습니다.
**참고**
메타데이터 테이블 구성을 삭제하고 동일한 범용 버킷에 대한 구성을 다시 만들려면 먼저 AWS 관리형 테이블 버킷에서 이전 저널 및 인벤토리 테이블을 수동으로 삭제해야 합니다. 그러지 않으면 새 메타데이터 테이블 구성 만들기에 실패합니다. 해당 테이블이 이미 존재하기 때문입니다. 메타데이터 테이블을 삭제하려면 [메타데이터 테이블 삭제](metadata-tables-delete-table.md) 섹션을 참조하세요.
메타데이터 테이블을 삭제하려면 [메타데이터 테이블 삭제](metadata-tables-delete-table.md#delete-metadata-table-procedure) 섹션을 참조하세요. 테이블 버킷을 삭제하려면 [Deleting table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-buckets-delete.html) 및 *Amazon S3 API 참조*의 [https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html) 섹션을 참조하세요.
Amazon S3 콘솔, AWS Command Line Interface(AWS CLI), AWS SDK 또는 Amazon S3 REST API를 사용하여 메타데이터 테이블 구성을 삭제할 수 있습니다.
## 메타데이터 테이블 구성 삭제
### S3 콘솔 사용
**메타데이터 테이블 구성을 삭제하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.
1. 메타데이터 테이블 구성을 제거할 범용 버킷을 선택합니다.
1. 버킷의 세부 정보 페이지에서 **메타데이터** 탭을 선택합니다.
1. **메타데이터** 탭에서 **삭제**를 선택합니다.
1. **메타데이터 구성 삭제** 대화 상자에서 **confirm**을 입력하여 구성 삭제를 확정합니다. 그런 다음 **삭제**를 선택합니다.
### AWS CLI 사용
다음 명령을 실행하려면 AWS CLI를 설치하고 구성해야 합니다. AWS CLI를 설치하지 않은 경우 *AWS Command Line Interface 사용 설명서*에서 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)를 참조하세요.
또는 AWS CloudShell을 사용하여 콘솔에서 AWS CLI 명령을 실행할 수 있습니다. AWS CloudShell은 브라우저 기반의 사전 인증된 쉘로, AWS Management Console에서 직접 시작할 수 있습니다. 자세한 내용은 *AWS CloudShell 사용 설명서*에서 [CloudShell이란 무엇인가요?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) 및 [AWS CloudShell 시작하기](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)를 참조하세요.
**AWS CLI를 사용하여 메타데이터 테이블 구성을 삭제하는 방법**
다음 예제 명령을 사용하려면 `user input placeholders`를 사용자의 정보로 대체하세요.
1. 다음 명령을 사용하여 메타데이터 테이블 구성을 범용 버킷에서 삭제합니다(예: `amzn-s3-demo-bucket`).
```
aws s3api delete-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
1. 구성이 삭제되었는지 확인하려면 다음 명령을 사용합니다.
```
aws s3api get-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
### REST API 사용
REST 요청을 전송하여 메타데이터 테이블 구성을 삭제할 수 있습니다. [자세한 내용은 DeleteBucketMetadataConfiguration 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketMetadataConfiguration.html)
**참고**
V1 또는 V2 메타데이터 테이블 구성으로 V2 `DeleteBucketMetadataConfiguration` API 작업을 사용할 수 있습니다. 그러나 V2 구성으로 V1 `DeleteBucketMetadataTableConfiguration` API 작업을 사용하려고 하면 HTTP `405 Method Not Allowed` 오류가 발생합니다.
### AWS SDK 사용
AWS SDK를 사용하여 Amazon S3에서 메타데이터 테이블 구성을 삭제할 수 있습니다. 자세한 내용은 [지원되는 SDK 목록](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketMetadataConfiguration.html#API_DeleteBucketMetadataConfiguration_SeeAlso)을 참조하세요.
# 메타데이터 테이블 삭제
Amazon S3 범용 버킷에 대해 만든 메타데이터 테이블을 삭제하려면 AWS 관리형 테이블 버킷에서 메타데이터 테이블을 삭제하면 됩니다.
**중요**
테이블 삭제는 영구적이며 취소할 수 없습니다. 테이블 삭제 전에 중요한 데이터를 백업하세요.
메타데이터 테이블을 삭제하려면 먼저 범용 버킷에서 연결된 메타데이터 테이블 구성을 삭제하는 것이 좋습니다. 자세한 내용은 [메타데이터 테이블 구성 삭제](metadata-tables-delete-configuration.md) 섹션을 참조하세요.
AWS 관리형 테이블 버킷을 삭제하려면 *Amazon S3 API 참조*의 [Deleting table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-buckets-delete.html) 및 [https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html)을 참조하세요. AWS 관리형 테이블 버킷을 삭제하기 전에 먼저 이 버킷과 연결된 모든 메타데이터 테이블 구성을 삭제하는 것이 좋습니다. 또한 먼저 버킷의 모든 메타데이터 테이블을 삭제해야 합니다.
AWS Command Line Interface(AWS CLI), AWS SDK 또는 Amazon S3 REST API를 사용하여 메타데이터 테이블을 삭제할 수 있습니다.
## 메타데이터 테이블 삭제
### AWS CLI 사용
다음 명령을 실행하려면 AWS CLI를 설치하고 구성해야 합니다. AWS CLI를 설치하지 않은 경우 *AWS Command Line Interface 사용 설명서*에서 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)를 참조하세요.
또는 AWS CloudShell을 사용하여 콘솔에서 AWS CLI 명령을 실행할 수 있습니다. AWS CloudShell은 브라우저 기반의 사전 인증된 쉘로, AWS Management Console에서 직접 시작할 수 있습니다. 자세한 내용은 *AWS CloudShell 사용 설명서*에서 [CloudShell이란 무엇인가요?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) 및 [AWS CloudShell 시작하기](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)를 참조하세요.
**AWS CLI를 사용하여 메타데이터 테이블 구성을 삭제하는 방법**
다음 예제 명령을 사용하려면 `user input placeholders`를 사용자의 정보로 대체하세요.
1. 다음 명령을 사용하여 메타데이터 테이블을 AWS 관리형 테이블 버킷에서 삭제합니다.
```
aws s3tables delete-table \
--table-bucket-arn arn:aws:s3tables:us-east-2:111122223333:bucket/aws-s3 \
--namespace b_general-purpose-bucket-name \
--name journal \
--region us-east-2
```
1. 테이블이 삭제되었는지 확인하려면 다음 명령을 사용합니다.
```
aws s3tables get-table \
--table-bucket-arn arn:aws:s3tables:us-east-2:111122223333:bucket/aws-s3 \
--namespace b_general-purpose-bucket-name \
--name journal \
--region us-east-2
```
### REST API 사용
REST 요청을 전송하여 메타데이터 테이블 구성을 삭제할 수 있습니다. 자세한 내용은 **Amazon S3 API 참조의 [https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTable.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTable.html) 섹션을 참조하세요.
### AWS SDK 사용
AWS SDK를 사용하여 Amazon S3에서 메타데이터 테이블 구성을 삭제할 수 있습니다. 자세한 내용은 *Amazon S3 API 참조*의 [지원되는 SDK 목록](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTable.html#API_s3TableBuckets_DeleteTable_SeeAlso)을 참조하세요.
# 메타데이터 테이블 쿼리
Amazon S3 Metadata 테이블은 테이블 형식 데이터에 최적화된 스토리지를 제공하는 AWS 관리형 S3 테이블 버킷에 저장됩니다. 메타데이터를 쿼리하기 위해 테이블 버킷을 Amazon SageMaker Lakehouse와 통합할 수 있습니다. AWS Glue Data Catalog 및 AWS Lake Formation을 사용하는 이 통합을 통해 AWS 분석 서비스는 테이블 데이터를 자동으로 검색하고 액세스할 수 있습니다.
테이블 버킷이 AWS Glue Data Catalog와 통합되면 Amazon Athena, Amazon EMR, Amazon Redshift와 같은 AWS 분석 서비스를 사용하여 메타데이터 테이블을 직접 쿼리할 수 있습니다. 여기에서 Amazon Quick을 사용하여 쿼리 데이터로 대화형 대시보드를 만들 수 있습니다.
AWS 관리형 S3 테이블 버킷을 Amazon SageMaker Lakehouse와 통합하는 방법에 대한 자세한 내용은 [AWS 분석 서비스와 Amazon S3 Tables 통합](s3-tables-integrating-aws.md) 섹션을 참조하세요.
AWS Glue Iceberg REST 엔드포인트, Amazon S3 Tables Iceberg REST 엔드포인트 또는 Apache Iceberg 클라이언트 카탈로그용 Amazon S3 Tables Catalog를 사용하여 Apache Iceberg 형식을 지원하는 Apache Spark, Apache Trino 및 기타 애플리케이션을 사용하여 메타데이터 테이블을 쿼리할 수도 있습니다. 메타데이터 테이블에 액세스하는 방법에 대한 자세한 내용은 [테이블 데이터에 액세스](s3-tables-access.md) 섹션을 참조하세요.
Apache Iceberg 형식을 지원하는 쿼리 엔진을 사용하여 메타데이터 테이블을 분석할 수 있습니다. 예를 들어 메타데이터 테이블을 쿼리하여 다음을 수행할 수 있습니다.
+ 스토리지 사용 패턴 및 추세 알아보기
+ 객체 전반에서 AWS Key Management Service(AWS KMS) 암호화 키 사용량 감사
+ 사용자 정의 메타데이터 및 객체 태그로 객체 검색
+ 시간 경과에 따른 객체 메타데이터 변경 사항 이해
+ 요청을 수행한 AWS 계정 ID 또는 IP 주소를 포함하여 객체가 업데이트되거나 삭제되는 시점 알아보기
S3 관리형 메타데이터 테이블과 사용자 지정 메타데이터 테이블을 조인하여 여러 데이터세트를 쿼리할 수도 있습니다.
## 쿼리 요금 고려 사항
메타데이터 테이블에서 쿼리를 실행하는 경우 추가 요금이 적용됩니다. 자세한 내용은 사용 중인 쿼리 엔진의 요금 정보를 참조하세요.
쿼리의 비용 효과를 높이는 방법에 대한 자세한 내용은 [메타데이터 테이블 쿼리 성능 최적화](metadata-tables-optimizing-query-performance.md) 섹션을 참조하세요.
**Topics**
+ [쿼리 요금 고려 사항](#metadata-tables-querying-pricing)
+ [메타데이터 테이블 쿼리에 대한 권한](metadata-tables-bucket-query-permissions.md)
+ [AWS 분석 서비스를 사용하여 메타데이터 테이블 쿼리](metadata-tables-bucket-integration.md)
+ [오픈 소스 쿼리 엔진을 사용하여 메타데이터 테이블 쿼리](metadata-tables-bucket-integration-open-source.md)
+ [메타데이터 테이블 쿼리 성능 최적화](metadata-tables-optimizing-query-performance.md)
+ [메타데이터 테이블 쿼리 예시](metadata-tables-example-queries.md)
# 메타데이터 테이블 쿼리에 대한 권한
S3 Metadata 저널 및 라이브 인벤토리 테이블을 쿼리하려면 먼저 특정 S3 Tables 권한이 있어야 합니다. 메타데이터 테이블이 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 암호화된 경우 테이블 데이터를 해독할 수 있는 `kms:Decrypt` 권한도 있어야 합니다.
메타데이터 테이블 구성을 만들 때 메타데이터 테이블이 AWS 관리형 테이블 버킷에 저장됩니다. 계정 및 동일한 리전의 모든 메타데이터 테이블 구성은 `aws-s3`라는 단일 AWS 관리형 테이블 버킷에 저장됩니다.
메타데이터 테이블을 쿼리하려면 다음 예제 정책을 사용할 수 있습니다. 이 정책을 사용하려면 `user input placeholders`를 사용자의 정보로 대체합니다.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"PermissionsToQueryMetadataTables",
"Effect":"Allow",
"Action":[
"s3tables:GetTable",
"s3tables:GetTableData",
"s3tables:GetTableMetadataLocation",
"kms:Decrypt"
],
"Resource":[
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/*",
"arn:aws:kms:us-east-1:111122223333:key/01234567-89ab-cdef-0123-456789abcdef"
]
}
]
}
```
# AWS 분석 서비스를 사용하여 메타데이터 테이블 쿼리
Amazon Athena, Amazon Redshift 및 Amazon EMR과 같은 AWS 분석 서비스를 사용하여 S3 관리형 메타데이터 테이블을 쿼리할 수 있습니다.
쿼리를 실행하려면 먼저 AWS 계정 및 리전의 [AWS 관리형 S3 테이블 버킷을 AWS 분석 서비스와 통합](s3-tables-integrating-aws.md)해야 합니다.
## Amazon Athena를 사용하여 메타데이터 테이블 쿼리
[AWS 관리형 S3 테이블 버킷을 AWS 분석 서비스와 통합](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)한 후 Athena에서 메타데이터 테이블 쿼리를 시작할 수 있습니다. 쿼리에서 다음을 수행합니다.
+ 카탈로그를 `s3tablescatalog/aws-s3`로 지정하고 데이터베이스를 `b_general_purpose_bucket_name`(보통 메타데이터 테이블의 네임스페이스)으로 지정합니다.
+ 메타데이터 테이블 네임스페이스 이름을 따옴표(`"`) 또는 백틱(```)으로 묶어야 합니다. 그러지 않으면 쿼리가 작동하지 않을 수 있습니다.
자세한 내용은 [Querying Amazon S3 tables with Athena](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-athena.html)를 참조하세요.
Amazon S3 콘솔을 통해 Athena에서 쿼리를 실행할 수도 있습니다.
### S3 콘솔 및 Amazon Athena 사용
다음 절차에서는 Amazon S3 콘솔을 사용하여 Athena 쿼리 편집기에 액세스하여 Amazon Athena로 테이블을 쿼리할 수 있습니다.
**메타데이터 테이블을 쿼리하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.
1. **범용 버킷** 탭에서 쿼리하려는 메타데이터 테이블에 대한 메타데이터 구성이 포함된 버킷을 선택합니다.
1. 버킷 세부 정보 페이지에서 **메타데이터** 탭을 선택합니다.
1. **Athena를 사용하여 테이블 쿼리**를 선택한 다음 저널 또는 인벤토리 테이블에 대한 샘플 쿼리 중 하나를 선택합니다.
1. Amazon Athena 콘솔이 열리고 Athena 쿼리 편집기가 샘플 쿼리가 로드된 상태로 나타납니다. 사용 사례에 맞게 이 쿼리를 수정합니다.
쿼리 편집기에서 **카탈로그** 필드는 **s3tablescatalog/aws-s3**로 채워져야 합니다. **데이터베이스** 필드는 테이블이 저장된 네임스페이스(예: **b\$1*general-purpose-bucket-name***)로 채워야 합니다.
**참고**
**카탈로그** 및 **데이터베이스** 필드에 이러한 값이 표시되지 않는 경우 AWS 관리형 테이블 버킷을 이 리전의 AWS 분석 서비스와 통합했는지 확인합니다. 자세한 내용은 [AWS 분석 서비스와 Amazon S3 Tables 통합](s3-tables-integrating-aws.md) 섹션을 참조하세요.
1. 그런 다음 **실행(Run)**을 선택하여 쿼리를 실행합니다.
**참고**
Athena에서 쿼리를 실행하려고 할 때 “쿼리를 실행할 권한이 충분하지 않습니다. 위탁자는 지정된 리소스에 대한 권한이 없습니다." 오류가 표시되면 테이블에서 필요한 Lake Formation 권한이 부여되어야 합니다. 자세한 내용은 [테이블 또는 데이터베이스에 대한 Lake Formation 권한 부여](grant-permissions-tables.md#grant-lf-table) 섹션을 참조하세요.
또한 메타데이터 테이블을 쿼리할 수 있는 적절한 AWS Identity and Access Management(IAM) 권한이 있는지 확인합니다. 자세한 내용은 [메타데이터 테이블 쿼리에 대한 권한](metadata-tables-bucket-query-permissions.md) 섹션을 참조하세요.
쿼리를 실행하려고 할 때 "Iceberg가 요청된 리소스에 액세스할 수 없음" 오류가 표시되면 AWS Lake Formation 콘솔로 이동하여 생성한 테이블 버킷 카탈로그 및 데이터베이스(네임스페이스)에 대한 권한을 자신에게 부여했는지 확인합니다. 이러한 권한을 부여할 때 테이블을 지정하지 마십시오. 자세한 내용은 [테이블 또는 데이터베이스에 대한 Lake Formation 권한 부여](grant-permissions-tables.md#grant-lf-table) 섹션을 참조하세요.
## Amazon Redshift를 사용하여 메타데이터 테이블 쿼리
[AWS 관리형 S3 테이블 버킷을 AWS 분석 서비스와 통합](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)한 후 다음을 수행합니다.
+ 메타데이터 테이블 네임스페이스(일반적으로 `b_general_purpose_bucket_name`)에 대한 [리소스 링크를 만듭니다](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html#database-link-tables).
+ 메타데이터 테이블 네임스페이스 이름을 따옴표(`"`) 또는 백틱(```)으로 묶어야 합니다. 그러지 않으면 쿼리가 작동하지 않을 수 있습니다.
완료되면 Amazon Redshift 콘솔에서 메타데이터 테이블 쿼리를 시작할 수 있습니다. 자세한 내용은 [Accessing Amazon S3 tables with Amazon Redshift](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-redshift.html)를 참조하세요.
## Amazon EMR을 사용하여 메타데이터 테이블 쿼리
Amazon EMR을 사용하여 메타데이터 테이블을 쿼리하려면 Apache Iceberg용으로 구성된 Amazon EMR 클러스터를 만들고 Apache Spark를 사용하여 메타데이터 테이블에 연결합니다. AWS 관리형 S3 테이블 버킷을 AWS 분석 서비스와 통합하거나 오픈 소스 Amazon S3 Tables Catalog for Iceberg 클라이언트 카탈로그를 사용하여 이를 설정할 수 있습니다.
**참고**
Amazon EMR 또는 기타 타사 엔진에서 Apache Spark를 사용하여 메타데이터 테이블을 쿼리하는 경우 Amazon S3 Tables Iceberg REST 엔드포인트를 사용하는 것이 좋습니다. 이 엔드포인트를 사용하지 않으면 쿼리가 성공적으로 실행되지 않을 수 있습니다. 자세한 내용은 [Amazon S3 Tables Iceberg REST 엔드포인트를 사용하여 테이블에 액세스](s3-tables-integrating-open-source.md) 섹션을 참조하세요.
자세한 내용은 [Accessing Amazon S3 tables with Amazon EMR](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-emr.html)을 참조하세요.
# 오픈 소스 쿼리 엔진을 사용하여 메타데이터 테이블 쿼리
Apache Spark와 같은 오픈 소스 쿼리 엔진을 사용하여 S3 관리형 메타데이터 테이블을 쿼리할 수 있습니다. Amazon EMR 또는 기타 타사 엔진에서 Apache Spark를 사용하여 메타데이터 테이블을 쿼리하는 경우 Amazon S3 Tables Iceberg REST 엔드포인트를 사용하는 것이 좋습니다. 이 엔드포인트를 사용하지 않으면 쿼리가 성공적으로 실행되지 않을 수 있습니다. 자세한 내용은 [Amazon S3 Tables Iceberg REST 엔드포인트를 사용하여 테이블에 액세스](s3-tables-integrating-open-source.md) 섹션을 참조하세요.
# 메타데이터 테이블 쿼리 성능 최적화
S3 Metadata는 Apache Iceberg 테이블 형식을 기반으로 하므로 특정 시간 범위를 사용하여 저널 테이블 쿼리의 성능과 [비용](#metadata-tables-optimizing-query-performance)을 최적화할 수 있습니다.
예를 들어 다음 SQL 쿼리는 S3 범용 버킷에 있는 새 객체의 민감도 수준을 제공합니다.
```
SELECT key, object_tags['SensitivityLevel']
FROM "b_general-purpose-bucket-name"."journal"
WHERE record_type = 'CREATE'
GROUP BY object_tags['SensitivityLevel']
```
이 쿼리는 전체 저널 테이블을 스캔하므로 실행하는 데 시간이 오래 걸릴 수 있습니다. 성능을 개선하기 위해 `record_timestamp` 열을 포함하여 특정 시간 범위에 집중할 수 있습니다. 또한 Amazon S3 콘솔에서 범용 버킷에 대한 **메타데이터** 탭의 메타데이터 구성 세부 정보 페이지에 있는 정규화된 테이블 이름을 사용하는 것이 좋습니다. 다음은 지난 달의 새 객체를 살펴보는 이전 쿼리의 업데이트된 버전입니다.
```
SELECT key, object_tags['SensitivityLevel']
FROM b_general-purpose-bucket-name"."aws-s3.b_general-purpose-bucket-name.journal"
WHERE record_type = 'CREATE'
AND record_timestamp > (CURRENT_TIMESTAMP – interval '1' month)
GROUP BY object_tags['SensitivityLevel']
```
인벤토리 테이블에 대한 쿼리 성능을 개선하려면 필요한 최소 열에서만 쿼리해야 합니다.
# 메타데이터 테이블 쿼리 예시
다음 예시에서는 표준 SQL 쿼리를 사용하여 S3 메타데이터 테이블에서 다양한 유형의 정보를 가져오는 방법을 보여줍니다.
다음 예시를 사용할 때는 다음 사항에 유의하세요.
+ 이 예시는 Amazon Athena에서 작동하도록 작성되었습니다. 다른 쿼리 엔진으로 작업하려면 예시를 수정해야 할 수 있습니다.
+ [쿼리를 최적화](metadata-tables-optimizing-query-performance.md)하는 방법을 이해해야 합니다.
+ `b_general-purpose-bucket-name`을 네임스페이스의 이름으로 바꿉니다.
+ 지원되는 열의 전체 목록은 [S3 Metadata 저널 테이블 스키마](metadata-tables-schema.md) 및 [S3 Metadata 라이브 인벤토리 테이블 스키마](metadata-tables-inventory-schema.md) 섹션을 참조하세요.
**Contents**
+ [저널 테이블 예제 쿼리](#metadata-tables-example-queries-journal-tables)
+ [파일 확장명으로 객체 찾기](#metadata-tables-example-query-object-pattern)
+ [객체 삭제 나열](#metadata-tables-example-query-delete-events)
+ [객체에서 사용하는 AWS KMS 암호화 키 나열](#metadata-tables-example-query-objects-using-kms-key)
+ [KMS 키를 사용하지 않는 객체 나열](#metadata-tables-example-query-objects-not-using-kms-key)
+ [지난 7일 동안 `PUT` 작업에 사용된 AWS KMS 암호화 키 나열](#metadata-tables-example-query-objects-using-kms-key-puts)
+ [S3 수명 주기별로 지난 24시간 동안 삭제된 객체 나열](#metadata-tables-example-query-objects-deleted-lifecycle)
+ [Amazon Bedrock에서 제공하는 메타데이터 보기](#metadata-tables-example-query-bedrock)
+ [현재 객체 상태의 이해](#metadata-tables-example-query-current-state)
+ [인벤토리 테이블 예제 쿼리](#metadata-tables-example-queries-inventory-tables)
+ [특정 태그를 사용하는 데이터세트 검색](#metadata-tables-example-query-datasets-specific-tags)
+ [SSE-KMS로 암호화되지 않은 객체 나열](#metadata-tables-example-query-objects-not-kms-encrypted)
+ [암호화되지 않은 객체 나열](#metadata-tables-example-query-objects-not-encrypted)
+ [Amazon Bedrock에서 생성한 객체 나열](#metadata-tables-example-query-objects-generated-bedrock)
+ [인벤토리 테이블과 저널 테이블 조정](#metadata-tables-example-query-generate-latest-inventory)
+ [객체의 현재 버전 찾기](#metadata-tables-example-query-latest-version)
+ [S3 메타데이터 테이블과 사용자 지정 메타데이터 조인](metadata-tables-join-custom-metadata.md)
+ [Amazon Quick을 사용하여 메타데이터 테이블 데이터 시각화](metadata-tables-quicksight-dashboards.md)
## 저널 테이블 예제 쿼리
다음 예제 쿼리를 사용하여 저널 테이블을 쿼리할 수 있습니다.
### 파일 확장명으로 객체 찾기
다음 쿼리는 특정 파일 확장명(이 경우 `.jpg`)이 있는 객체를 반환합니다.
```
SELECT key FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE key LIKE '%.jpg'
AND record_type = 'CREATE'
```
### 객체 삭제 나열
다음 쿼리는 요청을 제출한 AWS 계정 ID 또는 AWS 서비스 위탁자를 포함하여 객체 삭제 이벤트를 반환합니다.
```
SELECT DISTINCT bucket, key, sequence_number, record_type, record_timestamp, requester, source_ip_address, version_id
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE record_type = 'DELETE';
```
### 객체에서 사용하는 AWS KMS 암호화 키 나열
다음 쿼리는 객체를 암호화하는 AWS Key Management Service(AWS KMS) 키의 ARN을 반환합니다.
```
SELECT DISTINCT kms_key_arn
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal";
```
### KMS 키를 사용하지 않는 객체 나열
다음 쿼리는 AWS KMS 키로 암호화되지 않은 객체를 반환합니다.
```
SELECT DISTINCT kms_key_arn
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE encryption_status NOT IN ('SSE-KMS', 'DSSE-KMS')
AND record_type = 'CREATE';
```
### 지난 7일 동안 `PUT` 작업에 사용된 AWS KMS 암호화 키 나열
다음 쿼리는 객체를 암호화하는 AWS Key Management Service(AWS KMS) 키의 ARN을 반환합니다.
```
SELECT DISTINCT kms_key_arn
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE record_timestamp > (current_date - interval '7' day)
AND kms_key_arn is NOT NULL;
```
### S3 수명 주기별로 지난 24시간 동안 삭제된 객체 나열
다음 쿼리는 S3 수명 주기에 의해 마지막 날에 만료된 객체를 나열합니다.
```
SELECT bucket, key, version_id, last_modified_date, record_timestamp, requester
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE requester = 's3.amazonaws.com'
AND record_type = 'DELETE'
AND record_timestamp > (current_date - interval '1' day)
```
### Amazon Bedrock에서 제공하는 메타데이터 보기
일부 AWS 서비스(예: [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/APIReference/welcome.html))는 Amazon S3에 객체를 업로드합니다. 이러한 서비스에서 제공하는 객체 메타데이터를 쿼리할 수 있습니다. 예를 들어, 다음 쿼리에는 Amazon Bedrock에서 범용 버킷에 업로드한 객체가 있는지 확인하는 `user_metadata` 열이 포함됩니다.
```
SELECT DISTINCT bucket, key, sequence_number, record_type, record_timestamp, user_metadata
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE record_type = 'CREATE'
AND user_metadata['content-source'] = 'AmazonBedrock';
```
Amazon Bedrock이 버킷에 객체를 업로드한 경우 쿼리 결과에 객체와 연결된 다음 메타데이터가 `user_metadata` 열에 표시됩니다.
```
user_metadata
{content-additional-params -> requestid="CVK8FWYRW0M9JW65", signedContentSHA384="38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b", content-model-id -> bedrock-model-arn, content-source -> AmazonBedrock}
```
### 현재 객체 상태의 이해
다음 쿼리는 객체의 현재 상태를 판단하는 데 도움이 될 수 있습니다. 쿼리는 각 객체의 최신 버전을 식별하고, 삭제된 객체를 필터링하고, 시퀀스 번호를 기반으로 각 객체의 최신 버전을 표시합니다. 결과는 `bucket`, `key` 및 `sequence_number` 열별로 정렬됩니다.
```
WITH records_of_interest as (
-- Start with a query that can narrow down the records of interest.
SELECT * from "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
),
version_stacks as (
SELECT *,
-- Introduce a column called 'next_sequence_number', which is the next larger
-- sequence_number for the same key version_id in sorted order.
LEAD(sequence_number, 1) over (partition by (bucket, key, coalesce(version_id, '')) order by sequence_number ASC) as next_sequence_number
from records_of_interest
),
-- Pick the 'tip' of each version stack triple: (bucket, key, version_id).
-- The tip of the version stack is the row of that triple with the largest sequencer.
-- Selecting only the tip filters out any row duplicates.
-- This isn't typical, but some events can be delivered more than once to the table
-- and include rows that might no longer exist in the bucket (since the
-- table contains rows for both extant and extinct objects).
-- In the next subquery, eliminate the rows that contain deleted objects.
current_versions as (
SELECT * from version_stacks where next_sequence_number is NULL
),
-- Eliminate the rows that are extinct from the bucket by filtering with
-- record_type. An object version has been deleted from the bucket if its tip is
-- record_type==DELETE.
existing_current_versions as (
SELECT * from current_versions where not (record_type = 'DELETE' and is_delete_marker = FALSE)
),
-- Optionally, to determine which of several object versions is the 'latest',
-- you can compare their sequence numbers. A version_id is the latest if its
-- tip's sequencer is the largest among all other tips in the same key.
with_is_latest as (
SELECT *,
-- Determine if the sequence_number of this row is the same as the largest sequencer for the key that still exists.
sequence_number = (MAX(sequence_number) over (partition by (bucket, key))) as is_latest_version
FROM existing_current_versions
)
SELECT * from with_is_latest
ORDER BY bucket, key, sequence_number;
```
## 인벤토리 테이블 예제 쿼리
다음 예제 쿼리를 사용하여 인벤토리 테이블을 쿼리할 수 있습니다.
### 특정 태그를 사용하는 데이터세트 검색
다음 쿼리는 지정된 태그를 사용하는 데이터세트를 반환합니다.
```
SELECT *
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE object_tags['key1'] = 'value1'
AND object_tags['key2'] = 'value2';
```
### SSE-KMS로 암호화되지 않은 객체 나열
다음 쿼리는 SSE-KMS로 암호화되지 않은 객체를 반환합니다.
```
SELECT key, encryption_status
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE encryption_status != 'SSE-KMS';
```
### 암호화되지 않은 객체 나열
다음 쿼리는 암호화되지 않은 객체를 반환합니다.
```
SELECT bucket, key, version_id
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE encryption_status IS NULL;
```
### Amazon Bedrock에서 생성한 객체 나열
다음 쿼리는 Amazon Bedrock에서 생성된 객체를 나열합니다.
```
SELECT DISTINCT bucket, key, sequence_number, user_metadata
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE user_metadata['content-source'] = 'AmazonBedrock';
```
### 인벤토리 테이블과 저널 테이블 조정
다음 쿼리는 버킷의 현재 콘텐츠를 반영한 인벤토리 테이블 형식의 최신 목록을 생성합니다. 더 정확히 말하면, 결과 목록은 인벤토리 테이블의 최신 스냅샷과 저널 테이블의 최신 이벤트를 결합합니다.
이 쿼리가 가장 정확한 결과를 생성하려면 저널과 인벤토리 테이블이 모두 활성 상태여야 합니다.
10억 개(10^9) 미만의 객체를 포함하는 범용 버킷에 이 쿼리를 사용하는 것이 좋습니다.
이 예제 쿼리는 목록 결과에 다음과 같은 단순화를 적용합니다(인벤토리 테이블과 비교 시).
+ **열 누락** – `bucket`, `is_multipart`, `encryption_status`, `is_bucket_key_enabled`, `kms_key_arn` 및 `checksum_algorithm` 등의 열은 최종 결과에 포함되지 않습니다. 선택적 열 세트를 최소화하면 성능이 향상됩니다.
+ **모든 레코드 포함** – 쿼리는 null 버전(버전이 지정되지 않았거나 버전 관리가 일시 중지된 버킷) 및 삭제 마커를 포함하여 모든 객체 키와 버전을 반환합니다. 관심 있는 키만 표시하도록 결과를 필터링하는 방법에 대한 예제는 쿼리 끝부분의 `WHERE` 절을 참조하세요.
+ **조정 가속화** – 드문 경우지만 쿼리가 버킷에 더 이상 존재하지 않는 객체를 일시적으로 보고할 수 있습니다. 이러한 불일치는 인벤토리 테이블의 다음 스냅샷이 제공되는 즉시 해소됩니다. 이 동작으로 인해 성능이 높아지는 대신 정확도가 일시적으로 낮아질 수 있습니다.
Amazon Athena에서 이 쿼리를 실행하려면 저널 및 인벤토리 테이블이 포함된 범용 버킷 메타데이터 구성의 `s3tablescatalog/aws-s3` 카탈로그와 `b_general-purpose-bucket-name` 데이터베이스를 선택해야 합니다.
```
WITH inventory_time_cte AS (
SELECT COALESCE(inventory_time_from_property, inventory_time_default) AS inventory_time FROM
(
SELECT * FROM
(VALUES (TIMESTAMP '2024-12-01 00:00')) AS T (inventory_time_default)
LEFT OUTER JOIN
(
SELECT from_unixtime(CAST(value AS BIGINT) / 1000.0) AS inventory_time_from_property FROM "journal$properties"
WHERE key = 'aws.s3metadata.oldest-uncoalesced-record-timestamp' LIMIT 1
)
ON TRUE
)
),
working_set AS (
SELECT
key,
sequence_number,
version_id,
is_delete_marker,
size,
COALESCE(last_modified_date, record_timestamp) AS last_modified_date,
e_tag,
storage_class,
object_tags,
user_metadata,
(record_type = 'DELETE' AND NOT COALESCE(is_delete_marker, FALSE)) AS _is_perm_delete
FROM journal j
CROSS JOIN inventory_time_cte t
WHERE j.record_timestamp > (t.inventory_time - interval '15' minute)
UNION ALL
SELECT
key,
sequence_number,
version_id,
is_delete_marker,
size,
last_modified_date,
e_tag,
storage_class,
object_tags,
user_metadata,
FALSE AS _is_perm_delete
FROM inventory i
),
updated_inventory AS (
SELECT * FROM (
SELECT *,
MAX(sequence_number) OVER (PARTITION BY key, version_id) AS _supremum_sn
FROM working_set
)
WHERE sequence_number = _supremum_sn
)
SELECT
key,
sequence_number,
version_id,
is_delete_marker,
size,
last_modified_date,
e_tag,
storage_class,
object_tags,
user_metadata
FROM updated_inventory
-- This filter omits only permanent deletes from the results. Delete markers will still be shown.
WHERE NOT _is_perm_delete
-- You can add additional filters here. Examples:
-- AND object_tags['department'] = 'billing'
-- AND starts_with(key, 'reports/')
ORDER BY key ASC, sequence_number DESC;
```
### 객체의 현재 버전 찾기
다음 쿼리는 인벤토리 테이블을 사용하여 최신 객체 버전을 보여주는 새 출력 테이블을 생성합니다. 출력 테이블은 의도적으로 S3 인벤토리 보고서와 유사합니다. 출력 테이블에는 객체가 현재 버전인지 여부를 나타내는 `is_latest` 필드가 포함되어 있습니다. `is_latest` 필드는 [S3 인벤토리 보고서](storage-inventory.md#storage-inventory-contents)의 **IsLatest** 필드와 동일합니다.
이 쿼리는 버전 관리가 활성화되거나 버전 관리가 일시 중지된 상태의 [S3 버전 관리](Versioning.md)가 있는 범용 버킷에서 작동합니다.
**사전 조건**
쿼리는 결과를 새 S3 테이블에 출력하여 추가 쿼리를 지원하고 화면에 행을 출력하는 것보다 성능이 뛰어납니다. 따라서 이 쿼리를 실행하기 전에 다음 조건이 충족됐는지 확인하세요. 결과를 새 테이블에 출력하지 않도록 선택한 경우에는 해당 단계를 건너뛸 수 있습니다.
+ 새 테이블을 출력하려면 기존 네임스페이스가 있는 기존 고객 관리형 테이블 버킷이 있어야 합니다. 자세한 내용은 [테이블 버킷 생성](s3-tables-buckets-create.md) 및 [네임스페이스 생성](s3-tables-namespace-create.md)(을)를 참조하세요.
+ 새 출력 테이블을 쿼리하려면 테이블을 쿼리하기 위한 액세스 방법을 설정해야 합니다. 자세한 내용은 [테이블 데이터에 액세스](s3-tables-access.md) 섹션을 참조하세요. Amazon Athena와 같은 AWS 분석 서비스로 출력 테이블을 쿼리하려면 고객 관리형 테이블 버킷을 AWS 분석 서비스와 통합해야 합니다. 자세한 내용은 [AWS 분석 서비스와 Amazon S3 Tables 통합 개요](s3-tables-integration-overview.md) 섹션을 참조하세요.
이 쿼리를 사용하려면 `amzn-s3-demo-table-bucket`을 새 출력 테이블을 생성할 기존 고객 관리형 테이블 버킷의 이름으로 대체합니다. *`existing_namespace`*를 테이블 버킷에서 출력 테이블을 생성할 네임스페이스의 이름으로 대체합니다. *`new_table`*을 출력 테이블에 사용할 이름으로 대체합니다. 출력 테이블의 이름이 [테이블 명명 규칙](s3-tables-buckets-naming.md#naming-rules-table)을 따르는지 확인합니다.
Amazon Athena에서 이 쿼리를 실행하려면 인벤토리 테이블이 포함된 범용 버킷 메타데이터 구성의 `s3tablescatalog/aws-s3` 카탈로그와 `b_general-purpose-bucket-name` 데이터베이스를 선택해야 합니다.
```
-- If you don't want to output the results to a new table, remove the following two lines
-- (everything before the WITH clause).
CREATE TABLE "s3tablescatalog/amzn-s3-demo-table-bucket"."existing_namespace"."new_table"
as (
WITH
my_inventory AS (
SELECT
bucket,
key,
version_id,
sequence_number,
is_delete_marker,
size,
last_modified_date,
storage_class
FROM inventory
-- For prefix filtering, use a WHERE clause with % at the end.
-- WHERE key LIKE 'prefix%'
),
inventory_with_is_latest as (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY key
ORDER BY sequence_number DESC
) = 1 AS is_latest
FROM my_inventory
)
SELECT
bucket,
key,
version_id,
sequence_number,
is_delete_marker,
size,
last_modified_date,
storage_class,
is_latest
FROM inventory_with_is_latest
-- If you want only the current version of each key, uncomment the following WHERE clause.
-- WHERE is_latest = TRUE
-- If you aren't outputting the results to a new table, remove the next line:
);
```
# S3 메타데이터 테이블과 사용자 지정 메타데이터 조인
AWS 관리형 메타데이터 테이블과 고객(자체관리형) 메타데이터 테이블의 데이터를 분석할 수 있습니다. 표준 SQL `JOIN` 연산자를 사용하여 이러한 여러 소스에서 데이터를 쿼리할 수 있습니다.
다음 예시 SQL 쿼리는 AWS 관리형 저널 테이블(`"journal"`)과 자체관리형 메타데이터 테이블(`my_self_managed_metadata_table`) 간에 일치하는 레코드를 찾습니다. 또한 쿼리는 새 객체(또는 객체의 새 버전)가 버킷에 작성되었음을 나타내는 `CREATE` 이벤트를 기반으로 정보를 필터링합니다. 자세한 내용은 [S3 Metadata 저널 테이블 스키마](metadata-tables-schema.md) 단원을 참조하십시오.
```
SELECT *
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal" a
JOIN "my_namespace"."my_self_managed_metadata_table" b
ON a.bucket = b.bucket AND a.key = b.key AND a.version_id = b.version_id
WHERE a.record_type = 'CREATE';
```
다음 예시 SQL 쿼리는 AWS 관리형 인벤토리 테이블(`"inventory"`)과 자체관리형 메타데이터 테이블(`my_self_managed_metadata_table`) 간에 일치하는 레코드를 찾습니다.
```
SELECT *
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory" a
JOIN "my_namespace"."my_self_managed_metadata_table" b
ON a.bucket = b.bucket AND a.key = b.key AND a.version_id = b.version_id;
```
# Amazon Quick을 사용하여 메타데이터 테이블 데이터 시각화
Amazon Quick을 사용하면 대화형 대시보드를 생성하여 S3 관리형 메타데이터 테이블에 대한 SQL 쿼리 결과를 분석하고 시각화할 수 있습니다. Quick 대시보드를 통해 통계를 모니터링하고, 변경 사항을 추적하고, 메타데이터 테이블에 대한 운영 인사이트를 얻을 수 있습니다.
저널 테이블에 대한 대시보드에서 다음을 확인할 수 있습니다.
+ 삭제 대비 객체 업로드의 비율
+ 지난 24시간 동안 S3 수명 주기에 의해 삭제된 객체는 무엇인가?
+ 가장 최근 `PUT` 요청은 어떤 IP 주소에서 제출되었는가?
인벤토리 테이블에 대한 대시보드에서 다음을 확인할 수 있습니다.
+ 서로 다른 스토리지 클래스에 있는 객체의 수
+ 스토리지 데이터에 있는 객체 중 상대적으로 작은 객체의 비율은 무엇인가?
+ 버킷에 있는 객체의 유형
[S3 테이블 버킷을 AWS 분석 서비스와 통합](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)한 후 메타데이터 테이블에서 데이터세트를 만들고 SPICE를 사용하거나 쿼리 엔진에서 직접 SQL 쿼리를 사용하여 Amazon Quick에서 작업할 수 있습니다. Quick은 Amazon Athena 및 Amazon Redshift를 데이터 소스로 지원합니다.
자세한 내용은 [Visualizing table data with Amazon Quick](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-quicksight.html) 섹션을 참조하세요.
# S3 Metadata 문제 해결
다음 정보를 사용하여 Amazon S3 Metadata로 작업할 때 발생할 수 있는 일반적인 문제를 진단하고 수정할 수 있습니다.
## AWS 관리형 테이블 버킷 및 메타데이터 테이블을 삭제할 수 없음
메타데이터 테이블을 삭제하려면 먼저 범용 버킷에서 연결된 메타데이터 테이블 구성을 삭제해야 합니다. 자세한 내용은 [메타데이터 테이블 구성 삭제](metadata-tables-delete-configuration.md) 섹션을 참조하세요.
AWS 관리형 테이블 버킷을 삭제하려면 먼저 이 버킷과 연결된 모든 메타데이터 테이블 구성과 버킷의 모든 메타데이터 테이블을 삭제해야 합니다. 자세한 내용은 [메타데이터 테이블 구성 삭제](metadata-tables-delete-configuration.md) 및 [메타데이터 테이블 삭제](metadata-tables-delete-table.md)(을)를 참조하세요.
## AWS 관리형 메타데이터 테이블에 대한 암호화 설정을 지정하거나 변경할 수 없음
메타데이터 테이블 구성을 만들 때 AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화로 AWS 관리형 메타데이터 테이블을 암호화하도록 선택할 수 있습니다. SSE-KMS를 사용하기로 선택한 경우 범용 버킷과 동일한 리전에 고객 관리형 KMS 키를 제공해야 합니다. 테이블을 만드는 중에만 테이블에 대한 암호화 유형을 설정할 수 있습니다. AWS 관리형 테이블이 만들어진 후에는 암호화 설정을 변경할 수 없습니다. 메타데이터 테이블에 SSE-KMS를 지정하려면 특정 권한이 있어야 합니다. 자세한 내용은 [Permissions for SSE-KMS](metadata-tables-permissions.md#metadata-kms-permissions)를 참조하세요.
메타데이터 테이블의 암호화 설정이 기본 버킷 수준 암호화 설정보다 우선합니다. 테이블에 암호화 설정을 지정하지 않으면 버킷의 기본 암호화 설정을 상속합니다.
기본적으로 AWS 관리형 테이블 버킷은 Amazon S3 관리형 암호화 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 암호화됩니다. 첫 번째 메타데이터 구성을 만든 후 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)를 사용하도록 AWS 관리형 테이블 버킷의 기본 암호화 설정을 지정할 수 있습니다. 자세한 내용은 [Encryption for AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html#aws-managed-buckets-encryption) 및 [테이블 버킷에서 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화 지정](s3-tables-kms-specify.md) 섹션을 참조하세요.
## 메타데이터 테이블 구성을 다시 만들려고 하면 오류가 발생함
메타데이터 테이블 구성을 삭제하면 구성만 삭제됩니다. 메타데이터 테이블 구성을 삭제하더라도 AWS 관리형 테이블 버킷과 메타데이터 테이블은 여전히 존재합니다.
메타데이터 테이블 구성을 삭제하고 동일한 범용 버킷에 대한 구성을 다시 만들려면 먼저 AWS 관리형 테이블 버킷에서 이전 저널 및 인벤토리 테이블을 수동으로 삭제해야 합니다. 그러지 않으면 새 메타데이터 테이블 구성 만들기에 실패합니다. 해당 테이블이 이미 존재하기 때문입니다.
메타데이터 테이블을 삭제하려면 [메타데이터 테이블 삭제](metadata-tables-delete-table.md) 섹션을 참조하세요.
## 구성에서 인벤토리 테이블을 활성화할 수 없음
2025년 7월 15일 이전에 S3 Metadata 구성을 만든 경우 해당 구성에서 인벤토리 테이블을 활성화할 수 없습니다. 인벤토리 테이블을 만들고 저널 테이블 레코드를 만료시킬 수 있도록 구성을 삭제하고 다시 만드는 것이 좋습니다. 자세한 내용은 [2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화](metadata-tables-create-configuration.md#metadata-tables-migration) 섹션을 참조하세요.
## 구성에서 저널 테이블 레코드 만료를 활성화할 수 없음
2025년 7월 15일 이전에 S3 Metadata 구성을 만든 경우 해당 구성에서 저널 테이블 레코드 만료를 활성화할 수 없습니다. 저널 테이블 레코드를 만료시키고 인벤토리 테이블을 만들 수 있도록 구성을 삭제하고 다시 만드는 것이 좋습니다. 자세한 내용은 [2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화](metadata-tables-create-configuration.md#metadata-tables-migration) 섹션을 참조하세요.
## 메타데이터 테이블을 쿼리할 수 없음
메타데이터 테이블을 쿼리할 수 없는 경우 다음을 확인하세요.
+ Amazon Athena 또는 Amazon Redshift를 사용하여 메타데이터 테이블을 쿼리하는 경우, 메타데이터 테이블 네임스페이스 이름을 따옴표(`"`) 또는 백틱(```)으로 묶어야 합니다. 그러지 않으면 쿼리가 작동하지 않을 수 있습니다.
+ Amazon EMR 또는 기타 타사 엔진에서 Apache Spark를 사용하여 메타데이터 테이블을 쿼리하는 경우 Amazon S3 Tables Iceberg REST 엔드포인트를 사용하는 것이 좋습니다. 이 엔드포인트를 사용하지 않으면 쿼리가 성공적으로 실행되지 않을 수 있습니다. 자세한 내용은 [Amazon S3 Tables Iceberg REST 엔드포인트를 사용하여 테이블에 액세스](s3-tables-integrating-open-source.md) 섹션을 참조하세요.
+ 메타데이터 테이블을 쿼리할 수 있는 적절한 AWS Identity and Access Management(IAM) 권한이 있는지 확인합니다. 자세한 내용은 [메타데이터 테이블 쿼리에 대한 권한](metadata-tables-bucket-query-permissions.md) 섹션을 참조하세요.
+ Amazon Athena를 사용하고 쿼리를 실행하려고 할 때 오류가 발생하는 경우 다음을 수행합니다.
+ Athena에서 쿼리를 실행하려고 할 때 “쿼리를 실행할 권한이 충분하지 않습니다. 위탁자는 지정된 리소스에 대한 권한이 없습니다." 오류가 표시되면 테이블에서 필요한 Lake Formation 권한이 부여되어야 합니다. 자세한 내용은 [테이블 또는 데이터베이스에 대한 Lake Formation 권한 부여](grant-permissions-tables.md#grant-lf-table) 섹션을 참조하세요.
+ 쿼리를 실행하려고 할 때 "Iceberg가 요청된 리소스에 액세스할 수 없음" 오류가 표시되면 AWS Lake Formation 콘솔로 이동하여 생성한 테이블 버킷 카탈로그 및 데이터베이스(네임스페이스)에 대한 권한을 자신에게 부여했는지 확인합니다. 이러한 권한을 부여할 때 테이블을 지정하지 마십시오. 자세한 내용은 [테이블 또는 데이터베이스에 대한 Lake Formation 권한 부여](grant-permissions-tables.md#grant-lf-table) 섹션을 참조하세요.
## 특정 S3 Metadata AWS CLI 명령 및 API 작업을 사용하려고 하면 405 오류가 발생함
V1 `GetBucketMetadataTableConfiguration` API 작업을 직접적으로 호출하거나 V2 메타데이터 테이블 구성을 기준으로 `get-bucket-metadata-table-configuration` AWS Command Line Interface(AWS CLI) 명령을 사용하면 HTTP `405 Method Not Allowed` 오류가 발생합니다. 마찬가지로 V1 `DeleteBucketMetadataTableConfiguration` API 작업을 직접적으로 호출하거나 `delete-bucket-metadata-table-configuration` AWS CLI 명령을 사용해도 405 오류가 발생합니다.
V1 또는 V2 메타데이터 테이블 구성을 기준으로 V2 `GetBucketMetadataConfiguration` API 작업 또는 `get-bucket-metadata-configuration` AWS CLI 명령을 사용할 수 있습니다. 마찬가지로 V1 또는 V2 메타데이터 테이블 구성을 기준으로 V2 `DeleteBucketMetadataConfiguration` API 작업 또는 `delete-bucket-metadata-configuration` AWS CLI 명령을 사용할 수 있습니다.
V1 API 작업 대신 새 V2 API 작업(`CreateBucketMetadataConfiguration`, `GetBucketMetadataConfiguraion` 및 `DeleteBucketMetadataConfiguration`)을 사용하도록 프로세스를 업데이트하는 것이 좋습니다. S3 Metadata의 V1에서 V2로 마이그레이션하는 방법에 대한 자세한 내용은 [2025년 7월 15일 이전에 만들어진 메타데이터 구성에 대한 인벤토리 테이블 활성화](metadata-tables-create-configuration.md#metadata-tables-migration) 섹션을 참조하세요.
구성이 V1인지 V2인지 확인하려면 `GetBucketMetadataConfiguration` API 응답의 다음 속성을 볼 수 있습니다. AWS 관리형 버킷 유형(`"aws"`)은 V2 구성을 나타내고 고객 관리형 버킷 유형(`"customer"`)은 V1 구성을 나타냅니다.
```
"MetadataTableConfigurationResult": {
"TableBucketType": ["aws" | "customer"]
```
자세한 내용은 [메타데이터 테이블 구성 보기](metadata-tables-view-configuration.md) 섹션을 참조하세요.