AWS, DynamoDB 일괄 항목 쓰기 정식 출시: 별도 용량으로 S3 파일을 기존 테이블에 적재, 미국 동부 GB당 0.10달러부터이지만 조건 없는 레코드는 덮어쓰고 스트림 소비자에게는 쓰기가 보이며 글로벌 테이블은 미지원

2026년 11월 5일 AWS는 Amazon DynamoDB의 일괄 항목 쓰기(bulk put items)가 정식 출시됐다고 발표했습니다. Amazon S3의 데이터를 기존 테이블에 쓰는 완전 관리형 기능입니다. 지금까지는 다른 시스템이 만든 파일을 운영 중인 테이블에 넣으려면 직접 만든 파이프라인, AWS Glue나 Amazon EMR 작업, 그리고 테이블 용량의 세심한 관리가 필요했습니다. 이제는 DynamoDB에 입력 파일의 S3 위치를 알려 주고, 보고서를 둘 출력 위치를 지정하고, 계층을 고르면 됩니다. 발표는 기존 워크로드에 영향을 주지 않는다고 하고, 출시 블로그와 개발자 가이드는 별도 용량을 쓰며 테이블의 읽기·쓰기 용량을 소비하지 않는다고 설명합니다.

입력 파일은 줄 단위로 구분된 DynamoDB JSON이나 Amazon Ion이며 gzip이나 zstd로 압축할 수 있습니다. 각 레코드는 PutItem과 같은 문법의 자체 조건식을 가질 수 있습니다. 파티션 키에 attribute_not_exists를 쓰면 삽입 전용 쓰기가 되고, 버전 속성을 비교하면 들어오는 사본이 더 새로울 때만 씁니다. 한 파일에 무조건 쓰기, 삽입 전용, 버전 보호 레코드를 섞을 수 있습니다. 주의할 점이 두 가지 있습니다. 조건이 없는 레코드는 무조건 쓰이며 같은 키의 기존 항목을 덮어씁니다. 그리고 모든 항목이 같은 조건을 지켜야 한다면 그 조건을 파일의 모든 레코드에 반복해 적어야 합니다. 조건 때문에 건너뛴 항목은 실패가 아니며, 처리된 것으로 세어지고 조건 확인 실패를 요청하면 보고서에 나옵니다.

작업은 비동기입니다. 시작 호출은 작업 ARN을 돌려주고 클라이언트 토큰이 붙어 있어 시작을 다시 시도해도 중복 가져오기가 시작되지 않습니다. 처음 몇 분은 준비에 쓰이므로 카운터가 처음에는 0일 수 있습니다. 시작하는 ID에는 계정 수준과 테이블 수준 권한, 입력 버킷 읽기, 보고서 버킷 쓰기, 관련 AWS KMS 키 접근이 필요합니다. 작업은 COMPLETED, COMPLETED_WITH_ERRORS, FAILED, CANCELLED 중 하나로 끝납니다. 취소해도 이미 쓴 항목은 되돌려지지 않아 취소한 가져오기는 테이블을 부분적으로 갱신된 상태로 남깁니다. 보고서에는 쓰지 못한 레코드가 원본 객체, 객체 안의 위치, 이유와 함께 나오고, 조건 실패에서는 새 항목과 기존 항목이 모두 표시됩니다. 블로그는 COMPLETED_WITH_ERRORS를 정상 경로로 다루고 오류 레코드를 고친 뒤 그것만 다시 가져오라고 권합니다.

계층은 두 가지입니다. Standard는 기본값이며 더 저렴하고, 정기적인 데이터 보강과 백필처럼 시간이 유연한 작업에 맞습니다. Accelerated는 더 높은 처리량을 목표로 하며 마이그레이션과 복구처럼 기한이 있는 작업에 맞습니다. 테이블이 충분히 확장돼 있고 카디널리티가 높은 파티션 키 공간에 고르게 분포하고 입력을 크기가 비슷한 여러 S3 객체로 나누며 글로벌 보조 인덱스로 복제하지 않는다는 전제에서 AWS는 Accelerated의 추정치를 제시합니다. 1KB 항목 1,000만 개는 10분 미만, 1억 개는 1시간 미만, 10억 개는 2~4시간입니다. AWS는 이를 설명용 출발점이라고 부릅니다. 또 초기 실행은 테이블 확장보다 앞설 수 있고, 같은 형태의 파일을 세 번에서 다섯 번 실행해야 소요 시간이 안정된다고 경고합니다.

요금은 바이트 단위입니다. 미국 동부(버지니아 북부)에서 블로그는 Standard가 GB당 0.10달러, Accelerated가 GB당 0.20달러이며 항목당 최소 1KB로 계산하고 테이블과 각 인덱스에 따로 적용된다고 적습니다. 실패한 조건 확인은 요금이 부과되고, 검증에서 거부된 항목은 부과되지 않습니다. 같은 글에는 1KB 항목 1억 개를 Standard 10.00달러, Accelerated 20.00달러로 계산한 예가 있습니다. 이 기사는 이 리전의 수치만 전하며, 다른 리전은 발표가 요금 페이지를 안내합니다.

제한은 구체적입니다. 테이블당 한 번에 하나의 일괄 쓰기 작업만 실행할 수 있고, 인덱스를 만드는 동안에는 실행할 수 없습니다. 계정마다 Standard와 Accelerated 작업이 각각 최대 5개까지 동시에 진행될 수 있습니다. 한 작업은 Standard에서 최대 100GB, Accelerated에서 최대 1TB를 다룰 수 있고 대상 테이블은 활성 상태여야 합니다. 출시 시점에는 글로벌 테이블을 지원하지 않으며 작업 중에는 복제본을 추가할 수 없습니다. 벡터 인덱스가 있는 테이블은 Standard만 지원합니다. 이 기능은 항목 전체를 쓰며 개별 속성은 갱신하지 않으므로, 그런 경우에는 UpdateItem을 씁니다. Standard는 모든 상용 리전과 AWS GovCloud(US) 리전에서 쓸 수 있지만 Accelerated는 별도 페이지에 나온 리전에서만 가능하므로, Standard의 제공 범위를 Accelerated의 것으로 읽어서는 안 됩니다.

우리의 판단입니다. 영향이 없다는 말은 테이블 용량과 애플리케이션 읽기·쓰기 지표에 대해서는 맞지만, 블로그 스스로 다른 영향도 적고 있습니다. 가져온 항목은 DynamoDB Streams와 Kinesis 출력에서 애플리케이션 쓰기처럼 보이므로, 큰 가져오기는 추가 처리량에 맞춰 소비자를 준비하거나 MaxWriteRequestUnits로 작업의 쓰기 속도에 상한을 두지 않으면 스트림 소비자에게 부담을 줄 수 있습니다. 블로그는 상한이 너무 낮으면 실행이 시간 제한을 넘겨 실패할 수 있다고 경고하지만, 저장한 어느 페이지에도 그 시간 제한의 값은 적혀 있지 않습니다. 항목에 진행 중인 트랜잭션이 있으면 그쪽이 우선합니다. 일괄 쓰기는 소비 용량 지표에 나타나지 않으므로 테이블 경보는 가져오기 문제를 알려 주지 않으며, 봐야 할 신호는 작업 상태입니다. 항목 몇 개를 넣을 때는 PutItem과 BatchWriteItem이 여전히 맞는 도구입니다.