UpdateObjectEncryption API의 최근 출시는 대규모 데이터 보안 관리 방식에 중대한 변화를 가져왔다. 기존에는 S3 객체의 암호화를 변경하는 것이 "물리적" 작업이었다. 비트를 이동해야 했다. 이제는 "논리적" 메타데이터 작업이다.

기술적 심층 분석: 데이터 이동 없는 재암호화

이 업데이트의 "마법"은 Envelope Encryption에 있다. 기존 CopyObject 워크플로우에서는 S3가 기존 키로 실제 데이터를 복호화하고 새 키로 재암호화해야 했으며, 이는 사실상 새 파일을 생성하는 것이었다.

UpdateObjectEncryption API를 사용하면 S3는 기본 데이터 블록을 전혀 건드리지 않는다. 대신 Data Key (DK)와만 상호작용한다.

  1. S3는 객체 메타데이터에 저장된 암호화된 Data Key를 조회한다.
  2. 기존 Master Key를 사용하여 해당 Data Key를 복호화한다.
  3. 즉시 동일한 Data Key를 새 KMS Master Key로 재암호화한다.
  4. 객체 메타데이터가 새로운 암호화된 Data Key로 원자적으로 업데이트된다.

데이터 자체(암호문)는 동일하게 유지되므로, 데이터의 해시인 ETag와 생성 날짜가 정확히 동일하게 보존된다.

장단점

장점

  • 데이터 제로 레이턴시: 데이터가 이동되지 않으므로, 1KB에서 5TB까지 파일 크기에 관계없이 작업이 밀리초 단위로 완료된다.
  • 스토리지 무결성: Last-Modified 날짜, ETag, Version ID가 보존된다. 이는 캐시 검증에 ETag를 사용하는 애플리케이션에 매우 중요하다.
  • 아카이브 친화적: Glacier 객체를 먼저 "복원"하지 않고도 암호화를 업그레이드할 수 있다. 콜드 스토리지에 그대로 유지된다.
  • 비용 효율성: 복사와 관련된 데이터 조회 요금(GET)과 데이터 전송 요금을 피할 수 있다. API 호출(PUT 가격)에 대해서만 비용을 지불한다.
  • Intelligent-Tiering 안전성: S3 Intelligent-Tiering의 객체가 Frequent Access 티어로 "재설정"되지 않아 비용 최적화 진행 상태가 보존된다.

단점

  • KMS 전용: SSE-KMS로만 업데이트할 수 있다. SSE-C나 DSSE-KMS는 지원하지 않는다.
  • "비암호화" 미지원: 소스 객체가 반드시 이미 암호화되어 있어야 한다(SSE-S3 또는 SSE-KMS). 드문 레거시 "Plaintext" 객체인 경우 이 API는 실패한다.
  • Object Lock 장벽: 객체가 Legal Hold 또는 Retention Mode 하에 있는 경우, 잠금이 해제될 때까지 암호화를 업데이트할 수 없다.
  • KMS ARN 요구사항: KMS Key Alias를 사용할 수 없으며, 전체 Amazon Resource Name(ARN)을 제공해야 한다.

비교: UpdateObjectEncryption vs. CopyObject

기능UpdateObjectEncryption (신규)CopyObject (레거시)
데이터 이동없음 (메타데이터 업데이트만)전체 데이터 복사
객체 메타데이터보존 (ETag, 생성 날짜)재설정 (새 ETag, 새 날짜)
Glacier 지원아카이브 상태에서 작동먼저 "복원" 필요
처리량높음 (Atomic/즉시)객체 크기/대역폭에 의해 제한
비용PUT 요청만 ($0.005/1k)GET + PUT + 데이터 조회 요금
Object Lock차단됨새 버전 생성 (버전 관리 활성화 시)

결정 가이드: 어떤 것을 선택해야 하는가?

1. 다음과 같은 경우 UpdateObjectEncryption 사용:

  • 상황: 컴플라이언스 감사. 규제 요구사항을 충족하기 위해 AWS 관리 키(SSE-S3)에서 고객 관리 키(SSE-KMS)로 전환해야 하는 경우.
  • 상황: 아카이브된 데이터. Glacier Deep Archive에 페타바이트 규모의 데이터가 있고, 복원의 막대한 비용 없이 암호화 업그레이드가 필요한 경우.
  • 상황: 대용량 객체. 복사 작업에 몇 시간이 걸리고 타임아웃 위험이 있는 5TB 객체가 있는 경우.
  • 상황: ETag 의존적. 애플리케이션 로직이 동기화/캐싱을 위해 ETag가 일정하게 유지되는 것에 의존하는 경우.

2. 다음과 같은 경우 CopyObject 사용:

  • 상황: 비암호화 소스. 암호화가 전혀 없는 아주 오래된 객체를 다루는 경우.
  • 상황: 리전/계정 간. 암호화를 변경하면서 데이터를 다른 버킷이나 리전으로 이동해야 하는 경우.
  • 상황: SSE-C 요구사항. 새 API가 지원하지 않는 고객 제공 키(SSE-C)를 사용해야 하는 경우.
  • 상황: 잠긴 객체. 영구적으로 잠긴 객체(Compliance Mode)의 암호화를 업데이트해야 하는 경우. 이 상황에서는 새 복사본/버전이 유일한 경로다.

규모에 관한 참고: 수백만 개의 객체를 다루는 경우, 이 API를 루프로 호출하지 마라. S3 Batch Operations를 사용하라. AWS는 이 새 API를 Batch 콘솔에 직접 통합하여, 몇 번의 클릭만으로 전체 버킷에 걸쳐 "재암호화" 작업을 실행할 수 있다.

AWS 공식 뉴스는 https://aws.amazon.com/about-aws/whats-new/2026/01/change-the-server-side-encryption-type-of-s3-objects/에서 읽을 수 있다.

기존 데이터의 서버 측 암호화 업데이트에 대한 공식 AWS 문서는 여기에서 확인할 수 있다.