Amazon S3 FAQ

벡터 버킷은 벡터를 저장하고 쿼리하기 위해 특별히 구축되었습니다. 벡터 버킷 내에서는 S3 객체 API가 아니라 전용 벡터 API를 사용하여 벡터 데이터를 작성하고 의미 체계 의미와 유사성을 기반으로 쿼리합니다. 버킷 및 IAM 정책을 비롯한 Amazon S3의 기존 액세스 제어 메커니즘을 사용하여 벡터 데이터에 대한 액세스를 제어할 수 있습니다. 벡터 버킷에 대한 모든 쓰기는 매우 일관적이므로 가장 최근에 추가된 벡터에 즉시 액세스할 수 있습니다. 시간이 지남에 따라 벡터를 작성, 업데이트 및 삭제하면 S3 벡터 버킷은 데이터세트가 확장되고 변경되더라도 버킷에 저장된 벡터 데이터를 자동으로 최적화하여 최적의 가격 대비 성능을 제공합니다.

버킷은 Amazon S3에 저장된 객체 및 테이블의 컨테이너이며, 버킷에 원하는 수의 객체를 저장할 수 있습니다. 범용 버킷은 원래 S3 버킷 유형이며, 단일 범용 버킷에는 S3 Express One Zone을 제외한 모든 스토리지 클래스에 저장된 객체가 포함될 수 있습니다. 대부분의 사용 사례와 액세스 패턴에 권장됩니다. S3 디렉토리 버킷은 단일 가용 영역 내에서 더 빠른 데이터 처리를 제공하는 S3 Express One Zone 스토리지 클래스에 객체만 저장할 수 있습니다. 지연 시간이 짧은 사용 사례에 권장됩니다. 각 S3 디렉터리 버킷은 버킷 내 디렉터리 수에 관계없이 최대 2백만 TPS(초당 트랜잭션)를 지원할 수 있습니다. S3 테이블 버킷은 일일 구매 트랜잭션, 스트리밍 센서 데이터 또는 광고 노출과 같은 테이블 형식 데이터를 S3에 저장하기 위해 특별히 구축되었습니다. 테이블 버킷을 사용하면 데이터가 S3에 Iceberg 테이블로 저장되고, S3에서 모두 관리하는 행 수준 트랜잭션, 쿼리 가능한 테이블 스냅샷 등과 같은 분석 기능을 사용하여 해당 데이터와 상호 작용할 수 있습니다. 또한 테이블 버킷은 지속적인 테이블 유지 관리를 수행하여 시간 경과에 따라 데이터 레이크가 확장되고 진화하더라도 쿼리 효율성이 자동으로 최적화하도록 설계되었습니다. S3 벡터 버킷은 벡터를 저장하고 쿼리하기 위해 특별히 구축되었습니다. 벡터 버킷 내에서 전용 벡터 API를 사용하여 벡터 데이터를 작성하고 의미 체계 의미와 유사성을 기반으로 쿼리합니다. 버킷 및 IAM 정책을 비롯한 Amazon S3의 기존 액세스 제어 메커니즘을 사용하여 벡터 데이터에 대한 액세스를 제어할 수 있습니다. 시간이 지남에 따라 벡터를 작성, 업데이트 및 삭제하면 S3 벡터 버킷은 데이터세트가 확장되고 변경되더라도 버킷에 저장된 벡터 데이터를 자동으로 최적화하여 최적의 가격 대비 성능을 제공합니다.

S3 Tables는 정형 데이터를 Apache Parquet, Avro 및 ORC 형식으로 저장하기 위해 특별히 구축된 S3 스토리지를 제공합니다. 테이블 버킷 내에서 S3에 직접 최고 수준의 리소스로 테이블을 생성할 수 있습니다. 이러한 테이블은 ID 또는 리소스 기반 정책에 정의된 테이블 수준 권한으로 보호할 수 있으며, Apache Iceberg 표준을 지원하는 애플리케이션 또는 도구에서 액세스할 수 있습니다. 테이블 버킷에 테이블을 생성하면 S3의 기본 데이터가 Parquet, Avro 또는 ORC 파일로 저장됩니다. 그런 다음 S3는 Apache Iceberg 표준을 사용하여 데이터를 애플리케이션에서 쿼리할 수 있도록 하는 데 필요한 메타데이터를 저장합니다. S3 Tables에는 쿼리 엔진이 테이블 버킷에 있는 테이블의 Iceberg 메타데이터를 탐색하고 업데이트하는 데 사용하는 클라이언트 라이브러리가 포함되어 있습니다. 이 라이브러리를 테이블 작업을 위해 업데이트된 S3 API와 함께 사용하면 여러 클라이언트가 테이블에서 데이터를 안전하게 읽고 쓸 수 있습니다. 시간 경과에 따라 S3는 객체를 다시 쓰거나 ‘압축’하여 기본 Parquet, Avro 또는 ORC 데이터를 자동으로 최적화합니다. 압축은 S3의 데이터를 최적화하여 쿼리 성능을 개선합니다.

S3 외부에서 인프라를 구축할 필요 없이 간단히 몇 단계만 거치면 S3 Tables를 시작할 수 있습니다. 먼저 S3 콘솔에서 테이블 버킷을 생성합니다. 콘솔을 통해 첫 번째 테이블 버킷을 생성할 때 AWS Analytics 서비스와의 통합이 자동으로 이루어지므로, S3가 AWS Glue Data Catalog의 계정과 리전에 있는 모든 테이블 버킷과 테이블을 자동으로 채울 수 있습니다. 그러면 Amazon Athena, EMR 및 Redshift와 같은 AWS 쿼리 엔진에서 S3 Tables에 액세스할 수 있게 됩니다. 다음으로, S3 콘솔에서 클릭하면 Amazon Athena를 사용하여 테이블이 생성됩니다. Athena에 도달하면 새 테이블을 빠르게 채우고 쿼리를 시작할 수 있습니다.

또는 AWS Glue Data Catalog를 통해 Iceberg REST Catalog 엔드포인트를 사용하여 S3 Tables에 액세스할 수 있습니다. 그러면 모든 테이블 리소스를 포함한 전체 데이터 자산을 검색할 수 있게 됩니다. 또한 개별 테이블 버킷 엔드포인트에 직접 연결하여 해당 버킷 내의 모든 S3 Tables 리소스를 검색할 수 있습니다. 이를 통해 Apache Iceberg REST 카탈로그 사양을 지원하는 모든 애플리케이션 또는 쿼리 엔진에서 S3 Tables를 사용할 수 있습니다.

범용 Amazon S3 버킷에 Iceberg 테이블을 저장하는 것에 비해 최대 3배 더 빠른 쿼리 성능과 최대 10배 더 많은 초당 트랜잭션(TPS)을 제공합니다. 이는 테이블 버킷이 테이블의 기본 Parquet, Avro 또는 ORC 데이터를 자동으로 압축하여 쿼리 성능을 최적화하고, 전용 스토리지는 기본적으로 최대 10배의 TPS를 지원하기 때문입니다.

테이블 버킷을 사용하면 전체 버킷 또는 개별 테이블에 리소스 정책을 적용할 수 있습니다. 테이블 버킷 정책은 PutTablePolicy 및 PutTableBucketPolicy API를 사용하여 적용할 수 있습니다. 테이블 수준 정책을 사용하면 개별 Parquet, Avro 또는 ORC 파일의 물리적 위치를 파악하지 않고도 연결된 논리적 테이블을 기반으로 테이블 버킷의 테이블에 대한 권한을 관리할 수 있습니다. 또한 S3 Block Public Access는 항상 테이블 버킷에 적용됩니다.

테이블 버킷은 Parquet, Avro 또는 ORC 데이터를 포함하는 Apache Iceberg 테이블 형식을 지원합니다.

Amazon S3 외부에서 인프라를 설정할 필요 없이 간단한 4단계로 S3 Vectors를 시작할 수 있습니다. 먼저, CreateVectorBucket API 또는 S3 콘솔을 통해 특정 AWS 리전에 벡터 버킷을 생성합니다. 둘째, 벡터 버킷에 벡터 데이터를 정리할 수 있도록 CreateIndex API 또는 S3 콘솔에서 벡터 인덱스를 생성해야 합니다. 벡터 인덱스를 생성할 때 거리 측정법(코사인 또는 유클리드)과 벡터가 가져야 하는 차원 수(최대 4,092)를 지정합니다. 가장 정확한 결과를 얻으려면 임베딩 모델에서 권장하는 거리 측정법을 선택하세요. 셋째, PutVector API를 사용하여 벡터 인덱스에 벡터 데이터를 추가합니다. 선택적으로, 메타데이터를 각 벡터에 키 값 페어로 첨부하여 쿼리를 필터링할 수 있습니다. 넷째, QueryVector API를 사용하여 유사성 쿼리를 수행하고 검색할 벡터와 반환할 가장 유사한 결과의 수를 지정합니다.

S3 콘솔 또는 CreateIndex API를 사용하여 벡터 인덱스를 생성할 수 있습니다. 인덱스 생성 시, 유사성 쿼리 중에 필터링에서 제외하려는 벡터 버킷, 인덱스, 거리 지표, 차원, 그리고 선택적으로 메타데이터 필드 목록을 지정합니다. 예를 들어 벡터와 연결된 데이터를 순전히 참조용으로 저장하려는 경우 이러한 데이터를 필터링 불가능한 메타데이터 필드로 지정할 수 있습니다. 생성 시에 각 인덱스에는 고유한 Amazon 리소스 이름(ARN)이 할당됩니다. 이후에 쓰기 또는 쿼리 요청을 하면 이를 벡터 버킷 내의 벡터 인덱스로 전달합니다.

PutVectors API를 사용하여 벡터 인덱스에 벡터를 추가할 수 있습니다. 각 벡터는 벡터 인덱스의 각 벡터를 고유하게 식별하는 키로 구성됩니다(예: 프로그래밍 방식으로 UUID를 생성할 수 있음). 쓰기 처리량을 최대화하려면 최대 요청 크기까지 대량으로 벡터를 삽입하는 것이 좋습니다. 또한 메타데이터(예: 연도, 작성자, 장르, 위치)를 각 벡터에 키 값 페어로 첨부할 수 있습니다. 메타데이터를 포함하면 벡터 인덱스 생성 시 필터링할 수 없는 메타데이터로 지정하지 않는 한, 기본적으로 모든 필드를 유사성 쿼리의 필터로 사용할 수 있습니다. 비정형 데이터의 새로운 벡터 임베딩을 생성하려면 Amazon Bedrock의 InvokeModel API를 사용하여 사용하려는 임베딩 모델의 모델 ID를 지정하면 됩니다.

GetVectors API를 사용하여 벡터 키로 벡터 및 관련 메타데이터를 조회하고 반환할 수 있습니다.

QueryVectors API를 사용하여 쿼리 벡터, 반환할 관련 결과 수(가장 가까운 이웃 상위 k개), 인덱스 ARN을 지정하여 유사성 쿼리를 실행할 수 있습니다. 쿼리 벡터를 생성할 때는 벡터 인덱스에 저장된 초기 벡터를 생성하는 데 사용된 것과 동일한 임베딩 모델을 사용해야 합니다. 예를 들어 Amazon Bedrock에서 Amazon Titan Text Embeddings v2를 사용하여 문서의 임베딩을 생성하는 경우, 동일한 모델을 사용하여 질문을 벡터로 변환하는 것이 좋습니다. 또한 쿼리에서 메타데이터 필터를 사용하여 필터와 일치하는 벡터를 검색할 수 있습니다. 유사성 쿼리를 실행하면 기본적으로 벡터 키가 반환됩니다. 선택적으로, 응답에 거리와 메타데이터를 포함할 수 있습니다.

S3 Vectors는 내구성과 가용성이 뛰어난 벡터 스토리지를 제공합니다. S3 Vectors에 기록된 데이터는 99.999999999%의 데이터 내구성을 보장하도록 설계된 S3에 저장됩니다. S3 Vectors는 99.9%의 가용성 SLA로 99.99%의 가용성을 제공하도록 설계되었습니다.

S3 Vectors는 1초 미만의 쿼리 지연 시간을 제공합니다. Amazon S3의 탄력적인 처리량을 사용하여 수백만 개의 벡터에 대한 검색을 처리하며, 자주 사용하지 않는 쿼리 워크로드에 적합합니다.

벡터 임베딩에 대한 유사성 쿼리를 수행할 때 임베딩 모델, 벡터 데이터셋의 크기(벡터 및 차원 수), 쿼리 분포 등 여러 요인이 평균 리콜에 영향을 미칠 수 있습니다. S3 Vectors는 대부분의 데이터 세트에 대해 평균 90% 이상의 리콜을 제공합니다. 평균 리콜은 쿼리 결과의 품질을 측정합니다. 즉, 90%는 인덱스에 저장된 쿼리 벡터와 가장 가까운 실측 벡터의 90%가 응답에 포함되어 있음을 의미합니다. 단, 실제 성능은 특정 사용 사례에 따라 다를 수 있으므로 대표 데이터 및 쿼리로 자체 테스트를 수행하여 S3 벡터 인덱스가 리콜 요구 사항을 충족하는지 확인하는 것이 좋습니다.

ListVectors API를 사용하여 벡터 인덱스의 벡터 목록을 볼 수 있습니다. 이 API는 응답이 잘린 경우 표시기와 함께 한 번에 최대 1,000개의 벡터를 반환합니다. 응답에는 마지막 수정 날짜, 벡터 키, 벡터 데이터 및 메타데이터가 포함됩니다. 또한 ListVectors API를 사용하여 지정된 벡터 인덱스에서 벡터 데이터를 쉽게 내보낼 수 있습니다. ListVectors 연산은 매우 일관적입니다. 따라서 쓰기 후 변경 사항이 반영된 벡터를 즉시 나열할 수 있습니다.

S3 Vectors를 사용하면 스토리지와 모든 해당 쓰기 및 읽기 요청(예: 벡터 삽입 및 벡터 인덱스의 벡터에 대한 쿼리 작업 수행)에 대한 요금을 지불하게 됩니다. 요금 세부 정보를 보려면 S3 요금 페이지를 참조하세요.

예. Bedrock 콘솔 또는 API를 통해 Bedrock 지식 기반을 생성할 때 기존 S3 벡터 인덱스를 벡터 저장소로 구성하여 RAG 사용 사례의 벡터 스토리지 비용을 절감할 수 있습니다. Bedrock에서 벡터 인덱스를 자동으로 생성하고 관리하도록 하려면 Bedrock 콘솔의 빠른 생성 워크플로를 사용하세요. 또한 Amazon SageMaker Unified Studio에서 RAG 워크플로를 위한 벡터 저장소로 새 S3 벡터 인덱스를 구성할 수 있습니다.

예. 두 가지 방법으로 Amazon OpenSearch Service에 S3 Vectors를 사용할 수 있습니다. 먼저, S3 고객은 S3 또는 OpenSearch 콘솔을 사용하여 S3 벡터 인덱스의 모든 벡터를 OpenSearch Serverless에 새로운 서버리스 컬렉션으로 내보낼 수 있습니다. 기본적으로 S3 Vectors를 기반으로 구축하면 실시간 쿼리가 필요한 워크로드에 OpenSearch Serverless를 선택적으로 사용할 수 있다는 이점이 있습니다. 둘째, 관리형 OpenSearch 고객인 경우 이제 1초 미만의 지연 시간으로 쿼리할 수 있는 벡터 데이터의 엔진으로 S3 Vectors를 선택할 수 있습니다. 그러면 OpenSearch가 자동으로 S3 Vectors를 벡터의 기본 엔진으로 사용하므로, OpenSearch API를 사용하여 벡터 데이터를 업데이트하고 검색할 수 있습니다. 애플리케이션을 변경하지 않고도 S3 Vectors의 비용 혜택을 누릴 수 있습니다.

Amazon S3 Access Points는 S3와 함께 작동하는 모든 애플리케이션 또는 AWS 서비스의 데이터 액세스 관리를 간소화하는 엔드포인트입니다. S3 액세스 포인트는 S3 버킷 및 Amazon FSx for OpenZFS 파일 시스템과 함께 작동합니다. 각 애플리케이션 또는 사용자에 맞는 이름과 권한을 가진 액세스 포인트를 생성하여, 다양한 애플리케이션 또는 사용자가 데이터에 액세스하는 방법을 제어하고 간소화할 수 있습니다.

S3 액세스 포인트와 S3 버킷을 사용하면 더 이상 수백 개의 서로 다른 권한 규칙을 작성하며, 읽고, 추적하며, 감사해야 하는 하나의 복잡한 버킷 정책을 관리하지 않아도 됩니다. 대신, 각각 액세스 포인트는 고유한 호스트 이름과 액세스 포인트를 통해 생성된 모든 요청에 대해 특정 권한 및 네트워크 제어를 적용하는 액세스 정책을 사용하여 버킷으로의 사용자 지정된 경로를 제공하는 액세스 포인트를 버킷당 수백 개 생성할 수 있습니다.

FSx for OpenZFS와 함께 S3 액세스 포인트를 사용하면 데이터가 S3에 있는 것처럼 S3 API를 사용하여 FSx 데이터에 액세스할 수 있습니다. 이 기능을 통해 FSx for OpenZFS 파일 시스템에 파일 데이터를 그대로 유지하면서, S3와 연동되는 다양한 인공 지능, 기계 학습, 분석 서비스 및 애플리케이션에서 FSx for OpenZFS의 파일 데이터에 액세스할 수 있습니다.

S3 액세스 포인트를 사용하면 데이터를 S3로 이동하지 않고도 S3 API를 사용하여 Amazon FSx for OpenZFS의 파일 데이터에 액세스할 수 있습니다. FSx for OpenZFS 파일 시스템에 연결된 S3 액세스 포인트는 S3 버킷에 연결된 S3 액세스 포인트의 작동 방식과 유사하게 작동하며, 액세스 정책에 따라 제어되는 액세스와 함께 S3를 통한 데이터 액세스를 제공합니다. 반면 데이터는 FSx for OpenZFS 파일 시스템용 또는 S3 버킷에 계속 저장됩니다. 예를 들어 S3 액세스 포인트가 FSx for OpenZFS 파일 시스템에 연결되면 고객은 S3와 함께 작동하는 생성형 AI, 기계 학습, 분석 서비스 및 애플리케이션에 액세스 포인트를 사용하여 FSx for OpenZFS 데이터에 액세스할 수 있습니다.

디렉토리 버킷을 생성한 후 가져오기 옵션을 사용하여 S3 콘솔을 통해 동일한 AWS 리전 내에서 S3 Express One Zone 스토리지 클래스로 데이터를 가져올 수 있습니다. 가져오기를 사용하면 복사할 모든 객체를 개별적으로 지정하지 않고도 데이터를 가져올 접두사 또는 버킷을 선택할 수 있으므로 S3 디렉토리 버킷에 데이터를 간단하게 복사할 수 있습니다. S3 배치 작업은 선택한 접두사 또는 범용 버킷의 객체를 복사하며, S3 배치 작업 세부 정보 페이지를 통해 가져오기 복사 작업의 진행 상황을 모니터링할 수 있습니다.

3개월 이상 요청 활동이 없는 S3 디렉터리 버킷은 비활성 상태로 전환됩니다. 비활성 상태에서는 읽기 및 쓰기를 위해 디렉터리 버킷에 일시적으로 액세스할 수 없습니다. 비활성 버킷에는 모든 스토리지, 객체 메타데이터 및 버킷 메타데이터가 보관됩니다. 비활성 버킷에는 기존 스토리지 요금이 적용됩니다. 비활성 버킷에 대한 액세스 요청 시 버킷은 일반적으로 몇 분 내에 활성 상태로 전환됩니다. 이 전환 기간 동안 읽기 및 쓰기는 503 SlowDown 오류 코드를 반환합니다.

SQL을 사용하여 S3 객체에 대한 정보를 쿼리하여 생성형 AI, 분석 및 기타 사용 사례의 특정 데이터세트를 빠르게 식별하려면 Amazon S3 Metadata를 사용해야 합니다. S3 Metadata는 메타데이터를 거의 실시간으로 최신 상태로 업데이트하므로, Iceberg와 호환되는 모든 클라이언트를 사용하여 SQL 쿼리를 실행함으로써 객체 메타데이터로 객체를 찾을 수 있습니다. 예를 들어 SQL 쿼리를 사용하여 특정 필터와 일치하는 객체(예: 모든 버킷에서 지난 30일 동안 추가된 객체)의 목록을 반환할 수 있습니다.

S3 메타데이터는 버킷에 업로드된 객체에 대한 추가 정보를 제공하는 메타데이터를 자동으로 생성하고, 읽기 전용 테이블에서 해당 메타데이터를 쿼리할 수 있도록 설계되었습니다. 이러한 메타데이터 테이블은 Apache Iceberg에 구축된 Amazon S3 Tables에 저장되며 S3 내에서 테이블 형식 데이터를 저장하고 쿼리하는 관리형 방법을 제공합니다. S3 Metadata는 객체 크기와 같은 시스템 수준 메타데이터, 객체 업로드 시 태그 및 사용자 정의 메타데이터와 같은 사용자 지정 메타데이터, 요청을 보낸 IP 주소와 같은 이벤트 메타데이터를 생성하고 유지 관리합니다. 버킷의 데이터가 변경되면 S3 Metadata가 거의 실시간으로 업데이트하여 최신 변경 사항을 반영합니다. 그런 다음 Amazon Athena, Amazon QuickSight 및 Apache Spark를 비롯한 다양한 Iceberg 호환 AWS 분석 서비스 및 오픈 소스 도구를 사용하여 메타데이터 테이블을 쿼리할 수 있습니다.

S3 콘솔에서 클릭 몇 번으로 S3 Metadata를 시작할 수 있습니다. S3 메타데이터를 활성화하려는 범용 S3 버킷을 선택하면 S3가 버킷의 데이터를 분석하고 모든 객체에 대한 메타데이터를 포함하는 완전관리형 Apache Iceberg 테이블을 구축합니다. 몇 분 만에 Apache Iceberg를 지원하는 쿼리 엔진 또는 도구를 사용하여 메타데이터를 쿼리할 수 있습니다.

S3 메타데이터 테이블은 aws-s3라는 AWS 계정의 AWS 관리형 테이블 버킷에 저장됩니다. 테이블은 읽기 전용이며 S3만 메타데이터를 작성, 업데이트 또는 삭제할 수 있습니다. 

S3 Metadata는 계정의 두 관리 테이블, 즉 저널 테이블과 라이브 인벤토리 테이블에 메타데이터를 저장합니다. 

S3 Metadata 저널 테이블은 버킷 내에서 변경한 내용을 보여줍니다. 범용 S3 버킷에 객체가 추가, 업데이트 및 제거되면 해당 변경 사항이 거의 실시간으로 저널 테이블에 반영됩니다. 저널 테이블은 애플리케이션의 동작을 이해하고 데이터세트에 적용된 변경 사항을 식별하는 데 유용합니다. 예를 들어 저널 테이블에 대한 SQL 쿼리를 작성하여 지난 30일 동안 추가된 객체, 활성 요청자가 추가한 객체, 지난 주에 메타데이터가 변경된 객체 등, 필터와 일치하는 S3 객체를 찾을 수 있습니다.

S3 Metadata 라이브 인벤토리 테이블에는 버킷에 있는 모든 객체의 전체 목록이 포함되어 있습니다. 실시간 인벤토리 테이블은 매시간 업데이트되며, S3가 객체에 대해 알고 있는 모든 정보를 포함합니다. 라이브 인벤토리 테이블은 객체 메타데이터에서 생성된 특성을 기반으로 버킷의 데이터세트를 검색하거나 식별하는 데 유용합니다. 예를 들어 라이브 인벤토리 테이블을 사용하여 기계 학습용 훈련 데이터세트를 식별하거나, 스토리지 비용 최적화 연습에 사용하거나, 거버넌스 제어를 적용할 수 있습니다.

버킷에 새 객체를 추가하면 몇 분 내에 저널 테이블에 항목이 표시되고, 다음 시간별 새로 고침에서는 실시간 인벤토리 테이블에 항목이 표시됩니다. 기존 버킷에서 S3 메타데이터를 활성화하면 S3가 자동으로 백필 작업을 시작하여 모든 기존 객체에 대한 메타데이터를 생성합니다. 이 백필은 일반적으로 몇 분 안에 완료되지만 기존 데이터세트에 수백만 또는 수십억 개의 S3 객체가 포함된 경우 몇 시간이 걸릴 수도 있습니다.

S3 Inventory 보고서는 Amazon S3의 동기식 List API에 대한 예약된 대안을 제공합니다. 일 또는 주 단위로 S3 버킷이나 접두사에 대한 객체 및 해당 메타데이터를 CSV, ORC 또는 Parquet 파일 출력으로 제공하도록 S3 Inventory를 구성할 수 있습니다. S3 Inventory를 통해 비즈니스 워크플로와 빅 데이터 작업을 간소화 및 가속화할 수 있습니다. S3 인벤토리를 사용해 객체의 암호화 및 복제 상태를 확인함으로써 비즈니스, 규정 준수 및 규제 요구 사항을 충족할 수 있습니다. 자세한 내용은 Amazon S3 Inventory 사용 설명서를 참조하세요.

S3 Tables는 정형 데이터를 Apache Parquet, Avro 및 ORC 형식으로 저장하기 위해 특별히 구축된 S3 스토리지를 제공합니다. 테이블 버킷 내에서 S3에 직접 최고 수준의 리소스로 테이블을 생성할 수 있습니다. 이러한 테이블은 ID 또는 리소스 기반 정책에 정의된 테이블 수준 권한으로 보호할 수 있으며, Apache Iceberg 표준을 지원하는 애플리케이션 또는 도구에서 액세스할 수 있습니다. 테이블 버킷에 테이블을 생성하면 S3의 기본 데이터가 Parquet, Avro 또는 ORC 파일로 저장됩니다. 그런 다음 S3는 Apache Iceberg 표준을 사용하여 데이터를 애플리케이션에서 쿼리할 수 있도록 하는 데 필요한 메타데이터를 저장합니다. S3 Tables에는 쿼리 엔진이 테이블 버킷에 있는 테이블의 Iceberg 메타데이터를 탐색하고 업데이트하는 데 사용하는 클라이언트 라이브러리가 포함되어 있습니다. 이 라이브러리를 테이블 작업을 위해 업데이트된 S3 API와 함께 사용하면 여러 클라이언트가 테이블에서 데이터를 안전하게 읽고 쓸 수 있습니다. 시간 경과에 따라 S3는 객체를 다시 쓰거나 ‘압축’하여 기본 Parquet, Avro 또는 ORC 데이터를 자동으로 최적화합니다. 압축은 S3의 데이터를 최적화하여 쿼리 성능을 개선합니다.

S3 외부에서 인프라를 구축할 필요 없이 간단히 몇 단계만 거치면 S3 Tables를 시작할 수 있습니다. 먼저 S3 콘솔에서 테이블 버킷을 생성합니다. 콘솔을 통해 첫 번째 테이블 버킷을 생성할 때 AWS Analytics 서비스와의 통합이 자동으로 이루어지므로, S3가 AWS Glue Data Catalog의 계정과 리전에 있는 모든 테이블 버킷과 테이블을 자동으로 채울 수 있습니다. 그러면 Amazon Athena, EMR 및 Redshift와 같은 AWS 쿼리 엔진에서 S3 Tables에 액세스할 수 있게 됩니다. 다음으로, S3 콘솔에서 클릭하면 Amazon Athena를 사용하여 테이블이 생성됩니다. Athena에 도달하면 새 테이블을 빠르게 채우고 쿼리를 시작할 수 있습니다.

또는 AWS Glue Data Catalog를 통해 Iceberg REST Catalog 엔드포인트를 사용하여 S3 Tables에 액세스할 수 있습니다. 그러면 모든 테이블 리소스를 포함한 전체 데이터 자산을 검색할 수 있게 됩니다. 또한 개별 테이블 버킷 엔드포인트에 직접 연결하여 해당 버킷 내의 모든 S3 Tables 리소스를 검색할 수 있습니다. 이를 통해 Apache Iceberg REST 카탈로그 사양을 지원하는 모든 애플리케이션 또는 쿼리 엔진에서 S3 Tables를 사용할 수 있습니다.

범용 Amazon S3 버킷에 Iceberg 테이블을 저장하는 것에 비해 최대 3배 더 빠른 쿼리 성능과 최대 10배 더 많은 초당 트랜잭션(TPS)을 제공합니다. 이는 테이블 버킷이 테이블의 기본 Parquet, Avro 또는 ORC 데이터를 자동으로 압축하여 쿼리 성능을 최적화하고, 전용 스토리지는 기본적으로 최대 10배의 TPS를 지원하기 때문입니다.

테이블 버킷을 사용하면 전체 버킷 또는 개별 테이블에 리소스 정책을 적용할 수 있습니다. 테이블 버킷 정책은 PutTablePolicy 및 PutTableBucketPolicy API를 사용하여 적용할 수 있습니다. 테이블 수준 정책을 사용하면 개별 Parquet, Avro 또는 ORC 파일의 물리적 위치를 파악하지 않고도 연결된 논리적 테이블을 기반으로 테이블 버킷의 테이블에 대한 권한을 관리할 수 있습니다. 또한 S3 Block Public Access는 항상 테이블 버킷에 적용됩니다.

테이블 버킷은 Parquet, Avro 또는 ORC 데이터를 포함하는 Apache Iceberg 테이블 형식을 지원합니다.