S3에 대해서 알아보자

(Stephane Maarek의 Udemy AWS Certified Solutions Architect Associate 강의를 참고했습니다.)

 

Amazon S3(Simple Storage Service)는 AWS에서 제공하는 대표적인 객체 스토리지 서비스로, 뛰어난 확장성을 가지고 있어 사실상 무제한에 가까운 저장 공간을 제공하며, 전 세계 수많은 웹사이트와 애플리케이션의 핵심 저장소로 활용되고 있다. 또한 AWS의 다양한 서비스와 쉽게 연동되어 클라우드 환경에서 가장 많이 사용되는 스토리지 서비스 중 하나이다.  S3는 백업 및 데이터 저장, 재해 복구, 장기 데이터 보관, 하이브리드 클라우드 스토리지, 애플리케이션 호스팅, 이미지 및 동영상 등의 미디어 호스팅, 데이터 레이크 및 빅데이터 분석, 소프트웨어 배포, 정적 웹사이트 호스팅 등의 용도로 사용된다.

 

S3는 버킷(Bucket)과 객체(Object)로 구성된다. 버킷은 객체를 저장하는 최상위 컨테이너로, 리전 단위로 생성되며, 전 세계적으로 고유한 버킷 이름을 사용해야 한다. 일부 환경에서는 리전별로 동일한 이름을 재사용할 수 있는 계정 기반 네임스페이스를 지원한다.

 

버킷 이름 생성 시에는 다음과 같은 규칙을 따라야 한다.

 

• 대문자와 밑줄(_)은 사용할 수 없다.
• IP 주소 형식은 사용할 수 없다.
• 소문자 또는 숫자로 시작해야 한다.
• xn-으로 시작할 수 없다.
• -s3alias로 끝날 수 없다.

S3에 저장되는 실제 데이터를 객체​라고 한다. 객체는 파일 자체 뿐만 아니라 다양한 부가 정보를 함께 포함한다. 우선, 모든 객체는 Key라는 고유한 이름을 가지며, 이는 객체의 전체 경로를 의미한다. Key는 Prefix(경로)와 Object Name(파일명)으로 구성된다. S3에서 실제로는 디렉터리라는 개념이 존재하지 않는다. 이는 그저 슬래시를 포함한 긴 Key를 계층 구조처럼 표현한 것 뿐이다.

 

Object Value는 실제 저장되는 파일의 내용이다. 객체 하나의 최대 크기는 50TB이며, 5GB를 초과하는 파일을 업로드하는 경우 반드시 Multipart Upload 기능을 사용해야 한다. 또한 객체에는 파일 외에도 다양한 Metadata를 저장할 수 있다. Metadata는 시스템이 자동으로 관리하는 정보 뿐 아니라, 사용자가 직접 추가하는 Key-Value 형태의 텍스트 데이터도 포함할 수 있다. 더불어 객체에는 최대 10개까지 유니코드 기반의 Key-Value 형태로 Tag를 추가할 수 있다. 이는 접근 제어, 수명 주기 관리, 비용 관리 등의 목적으로 사용된다. 마지막으로 버킷에서 Versioning 기능을 활성화하면 객체마다 Version ID가 생성된다. 만약 동일한 키를 업로드하고 해당 파일을 덮어쓰는 경우 새로운 버전이 생성되는 방식인데, 이 방법은 파일의 의도치 않 삭제 등으로부터 보호해주며 롤백이 가능하다.

1) S3 보안 및 버킷 정책

Amazon S3는 데이터를 안전하게 보호하기 위해 접근 권한 관리와 데이터 암호화 기능을 제공한다.

 

접근 권한 관리는 크게 사용자 기반과 리소스 기반으로 나뉜다. 사용자 기반은 IAM 정책을 사용해 특정 사용자나 역할이 S3에서 어떤 작업을 수행할 수 있는지 설정한다. 리소스 기반은 버킷 정책과 ACL(Access Control List)을 사용한다. 버킷 정책은 버킷 전체에 적용되는 정책으로, 다른 AWS 계정에도 접근 권한을 부여할 수 있다. ACL은 객체나 버킷 단위로 세부 권한을 설정하는 기능이지만, 현재는 버킷 정책을 주로 사용하기에 사용 빈도는 낮다. S3 객체에 접근하려면 IAM 정책 또는 리소스 정책에서 접근이 허용되어야 하며 명시적인 거부가 없어야 한다. 즉, 허용보다 거부가 우선 적용된다.

 

또한 데이터 암호화 기능을 통해 저장되는 객체를 암호화 키로 보호한다.

Amazon S3 버킷 정책 예시

 

Amazon S3 버킷 정책은 JSON 형식의 정책을 사용하며, Resource(적용 대상), Effect(허용 또는 거부), Action(수행 가능한 작업), Principal(정책이 적용될 사용자 또는 계정)으로 구성된다. 이를 통해 특정 사용자나 AWS 계정이 S3 버킷에서 수행할 수 있는 작업을 세부적으로 제어할 수 있다. 버킷 정책을 통해 버킷을 공개하여 누구나 접근할 수 있도록 설정하거나, 객체 업로드 시 반드시 암호화를 적용하도록 강제할 수 있다. 또한 다른 AWS 계정에 버킷 접근 권한을 부여하는 Cross Account Access를 구현할 때도 사용된다.

2) Amazon S3 복제

Amazon S3는 데이터를 다른 버킷으로 복제할 수 있는 기능을 제공한다. 이 기능을 사용하면 동일한 데이터를 다른 리전이나 동일한 리전의 버킷에도 저장하여 데이터의 가용성과 안정성을 높일 수 있다.

 

복제 기능을 사용하기 위해서는 원본 버킷과 대상 버킷 모두에서 Versioning을 활성화해야 하며, S3가 복제를 수행할 수 있도록 적절한 IAM 권한을 부여해야 한다. 또한 복제는 실시간이 아닌 비동기식으로 이루어지므로, 원본 버킷에 저장된 데이터가 대상 버킷에 복제되기까지 약간의 시간이 소요될 수 있다. 복제 대상 버킷은 동일한 AWS 계정뿐만 아니라 다른 AWS 계정에 생성된 버킷도 사용할 수 있다.

 

S3 복제는 CRR(Cross-Region Replication)과 SRR(Same-Region Replication) 두 가지 방식으로 제공된다. CRR은 서로 다른 AWS 리전 간에 데이터를 복제하는 방식으로, 규정 준수, 지연 시간 감소, 그리고 계정 간 데이터 복제와 같은 용도로 활용된다. 반면 SRR은 동일한 리전 내에서 데이터를 복제하는 방식으로, 로그를 한곳에 수집하거나 운영 환경 및 테스트 환경 간 데이터를 실시간에 가깝게 동기화하는 데 주로 사용된다.

 

S3 복제 기능을 사용할 때 알아두어야 할 몇 가지 동작 방식 및 제한 사항이 있다.

 

우선, 복제를 설정했다고 해서 기존에 저장되어 있던 모든 객체가 자동으로 복제되는 것이 아니라 설정 이후 새로 업로드되거나 변경된 객체만 복제된다. 또한 이미 버킷에 저장되어 있던 기존 객체는 S3 Batch Replication으로 복제 가능하다. 이 기능은 기존에 저장된 객체를 복제하거나 복제에 실패했던 객체를 다시 복제할 때 활용된다.

 

Versioning이 활성화된 버킷에서는 객체 삭제 시에 바로 삭제되지 않고 Delete Marker가 생성되는데, 이 Delete Marker를 대상 버킷으로 복제할지 선택적으로 설정할 수 있다. 즉, Source에서 삭제하면 Destination에서도 동일하게 삭제된 것처럼 만들지를 선택할 수 있다.

 

또한 Version ID를 이용한 삭제는 복제되지 않는다. 예를 들어, 하나의 파일이 3가지의 버전이 있을 때, Version 2를 지정하여 삭제했다고 해도 그것이 복제되지는 않는다. 마지막으로 복제는 연쇄적으로 이루어지지 않는다는 특징을 가진다.

3) Amazon S3 스토리지 클래스

Amazon S3는 저장하는 데이터의 접근 빈도, 보관 기간, 비용에 따라 여러 가지 스토리지 클래스를 제공한다. 자주 사용하는 데이터는 빠르게 접근할 수 있는 스토리지 클래스를 사용하고, 거의 사용하지 않는 데이터는 비용이 저렴한 스토리지 클래스를 사용하여 저장 비용을 절감할 수 있다. S3에서 제공하는 대표적인 스토리지 클래스는 다음과 같다.

• S3 Standard
• S3 Standard-Infrequent Access(Standard-IA)
• S3 One Zone-Infrequent Access(One Zone-IA)
• S3 Glacier Instant Retrieval
• S3 Glacier Flexible Retrieval
• S3 Glacier Deep Archive
• S3 Intelligent-Tiering

저장된 객체는 필요에 따라 직접 다른 스토리지 클래스로 변경할 수도 있고, S3 Lifecycle 정책을 이용하여 일정 기간이 지나면 자동으로 다른 스토리지 클래스로 이동하도록 설정할 수도 있다.

 

S3 스토리지 클래스를 이해하기 위해서는 Durability(내구성)과 Availability(가용성)의 차이를 알아야 한다. 내구성은 데이터가 손실되지 않을 확률을 의미한다. S3의 모든 스토리지 클래스는 99% 이상의 매우 높은 내구성을 제공한다. 예를 들어 S3에 1,000만 개의 객체를 저장했다면 평균적으로 1만 년에 하나 정도만 손실될 정도로 매우 안전하게 데이터를 보관할 수 있다. 즉, 내구성은 데이터가 얼마나 안전하게 저장되는지를 나타내는 지표이다.

 

가용성은 필요할 때 데이터를 사용할 수 있는 확률을 의미한다. 내구성과 달리 가용성은 스토리지 클래스마다 다르다. 예를 들어 S3 Standard는 99.99%의 가용성을 제공하며, 이는 1년 동안 약 53분 정도만 서비스를 사용할 수 없을 수 있다는 의미이다. 즉, 가용성은 접근할 때 서비스를 이용할 수 있는 가능성을 나타내는 지표이다.

 

이제 스토리지를 하나씩 차례로 살펴보면 우선 S3 Standard는 가장 기본적인 스토리지 클래스이다. 자주 접근하는 데이터를 저장하며, 낮은 지연 시간과 높은 처리량이 특징이다. 동시에 2개의 시설에 장애가 발생해도 데이터를 안전하게 유지한다. 빅데이터 분석이나 모바일 및 게임 애플리케이션, 컨텐츠 배포 등에 사용된다.

 

S3 Standard-IA (Infrequent Access)는 평소에는 거의 접근하지 않지만 필요할 때 즉시 접근해야 하는 데이터를 위한 스토리지 클래스이다. S3 Standard보다 저장 비용이 저렴하며 빠른 접근이 가능하다. Standard와 마찬가지로 99.9%의 가용성을 보여준다. 백업 파일이나 재해 복구 등의 용도로 사용한다.

 

S3 One Zone-IA는 Standard-IA와 거의 동일하지만 데이터를 하나의 가용 구역에만 저장한다. 따라서 저장 비용이 더욱 저렴하지만 AZ 자체가 손실되면 데이터도 함께 손실될 수 있다. 온프레미스 데이터의 보조 백업 혹은 필요하면 다시 생성 가능한 데이터 등의 용도로 사용된다.

 

Glacier 계열은 장기 보관을 위한 저렴한 스토리지 클래스이다. 대신 데이터를 읽을 때 검색 비용이 발생하며, 일부 클래스는 데이터를 가져오는 데 시간이 걸린다. S3 Glacier Instant Retrieval은 가끔 접근하지만 거의 대부분 보관만 하는 데이터를 위한 스토리지로, 최소 저장 기간은 90일이다. Glacier 중 가장 빠른 접근 속도를 가진다. 분기마다 한 번 정도 조회하는 데이터나 장기 보관 문서에 적합하다. Glacier Flexible Retrieval에서는 데이터를 얼마나 빨리 가져올지를 Expedited(1~5분), Standard(3~5시간), Bulk(5~12시간; 무료)로 구성된 조회 방식에서 선택할 수 있다. 마찬가지로 최소 저장 기간은 90일이며, 백업이나 재해 복구 등의 용도로 사용한다. 마지막 Glacier 계열인 S3 Glacier Deep Archive는 가장 저렴한 스토리지이지만 데이터를 가져오는 시간이 가장 오래 걸린다. 최소 저장 기간은 180일이며, 조회 방식은 Standard(약 12시간)과 Bulk(약 48시간)이 있다. 법적 보관 문서처럼 거의 접근하지 않는 데이터를 저장하기 위해 사용된다.

 

마지막으로 S3 Intelligent-Tiering은 어떤 데이터를 자주 사용할지 예측하기 어려운 경우에 사용하는 스토리지 클래스이다. AWS가 객체의 접근 패턴을 지속적으로 모니터링하여 가장 적절한 계층으로 자동 이동시킨다. 이때 계층은 기본 계층인 Frequent Access, 30일동안 접근이 없는 경우 이동하는 Infrequent Access, 90일동안 접근이 없는 경우 이동하는 Archive Instant Access로 구성된다. 필요 시 90~700일 이상 접근하지 않은 데이터를 저장하는 Archive Access와 180~700일 이상 접근하지 않은 데이터를 저장하는 Deep Archive Access 계층도 활성화할 수 있다. 소액의 모니터링 및 자동 계층 이동 비용이 발생한다는 것이 특징이며 검색 비용은 없다.

스토리지 클래스 이동

 

객체들이 저장되는 스토리지 클래스를 이동시키는 것도 가능하다. 스토리지 클래스 전환을 자동화하기 위해 사용하는 것이 S3 생명주기 규칙(S3 Lifecycle Rule)이다. 생명주기 규칙은 객체의 나이에 따라 자동으로 저장 클래스를 변경하거나 삭제하는 정책으로 크게 2가지 기능으로 나뉜다. Transition Action(저장 클래스 변경)은 객체를 일정 기간이 지나면 더 저렴한 스토리지 클래스로 이동시키는 기능이고, Expiration Action(객체 삭제)는 일정 기간이 지나면 객체를 자동 삭제하는 기능이다. 객체 삭제 기능은 오래된 버전의 파일을 삭제하거나 완료되지 않은 Multipart Upload 파일을 삭제하는 데에 사용될 수 있다.

 

생명주기 규칙은 Prefix 기반으로 특정 폴더에만 적용되도록 할 수 있다. 예를 들어, 's3://mybucket/mp3/*'라면 mp3 폴더만 생명주기가 적용되도록 설정한 것이다. 또한 객체의 Tag에 따라 적용할 수도 있다.

 

생명주기 규칙을 만들기 전에 언제 스토리지 클래슬르 변경하변 좋은지 분석해 주는 S3 Storage Class Analysis (S3 Analytics) 기능이 있다. 이 기능은 객체의 접근 패턴을 분석해서 매일 보고서를 업데이트하고, Standard → Standard-IA로의 전환 시점을 추천한다. 분석 시작 후 24~48시간이 지나야 데이터가 쌓여 추천을 제공한다. 다만, Standard와 Standard-IA 이외의 스토리지 클래스에 대해서는 추천을 지원하지 않는다.

4) S3 Requester Pays

S3 Requester Pays

 

Requester Pays는 S3 버킷의 데이터 다운로드, 즉 Request 비용을 버킷 소유자가 아니라 데이터를 요청한 사용자가 부담하도록 하는 기능이다. 보통 S3에서는 버킷 소유자가 대부분의 비용을 부담하지만, Requester Pays를 활성화하면 일부 비용의 부담 주체가 바껴서 버킷 소유자는 스토리지 비용을 계속 부담하지만 요청 사용자가 GET/PUT 등의 Request 비용과 다운로드 비용을 지불한다.

 

이 기능을 사용하면 대용량 데이터를 여러 사람과 공유할 때 버킷 소유자의 비용 부담을 크게 줄일 수 있다는 장점이 있다. 이때, 반드시 AWS 계정으로 인증된 사용자만이 Requester Pays 버킷에 접근할 수 있어야 한다.

5) S3 Event Notification

S3 Event Notification은 S3 버킷에서 특정 이벤트(파일 업로드, 삭제, 복제 등)가 발생했을 때 다른 AWS 서비스에 자동으로 알림을 보내는 기능입니다. Object Name Filtering 기능으로 특정 파일에 대해서만 이벤트를 발생시킬 수도 있다. 사용 예시로는, S3의 특정 이벤트에 자동으로 반응하려는 경우, 가령 S3에 업로드된 모든 이미지의 썸네일을 생성하려 할 경우 활용할 수 있다. S3 이벤트는 원하는 만큼 만들 수 있으며, 원하는 타깃에 전공할 수도 있다. 또한 이벤트 알림이 작동하려면 IAM 권한을 가지고 있어야 한다. SNS와 SQS, Lambda Function을 직접 대상으로 사용할 수 있다.

EventBridge가 포함된 Event Notification

 

기본 Event Notification보다 더 강력한 기능이 필요하면 Amazon EventBridge와 연결할 수 있다. EventBridge는 JSON 규칙을 이용해 더 세밀한 필터링을 제공하며, 하나의 이벤트를 여러 곳에 보내는 기능, 발생 이벤트 저장, 이벤트 재발생, 안정적인 이벤트 전달 등의 기능을 제공한다. 지원 대상도 거의 모든 AWS 서비스로 확대된다.

6) S3의 성능

S3는 기본적으로 매우 높은 성능과 자동 확장 기능을 제공하는 스토리지 서비스다. 사용량이 증가하면 자동으로 확장되는데, 평균 지연 시간은 100~200ms이다. AWS는 Prefix 단위로 요청 처리량을 보장한다. Prefix란 객체 키의 앞부분, 즉 경로를 의미하는데 가령 'bucket/folder1/sub1/file'의 객체가 있으면 Prefix는 '/folder1/sub1/', 'bucket/1/file'의 Prefix는 '/1/'인 것이다. 하나의 Prefix에서는 PUT/COPY/POST/DELETE는 초당 최소 3,500 요청, GET/HEAD는 초당 최소 5,500 요청을 처리할 수 있다. 따라서 Prefix가 많을수록 더 많은 요청 처리가 가능하다.

 

큰 파일을 여러 조각으로 나누어 동시에 업로드하는 Multipart Upload 기능은 업로드 속도 향상 및 쉬운 실패 복구를 위해 사용한다. 100MB 이상의 파일에 대해서 사용이 권장되며, 5GB를 초과하는 파일은 반드시 사용되어야 한다. 또한 S3 Transfer Acceleration은 전 세계에서 S3로 업로드 시 속도를 높여주는 기능이다. 예를 들어, 한국에서 미국 리전의 S3에 업로드하려면 먼 거리를 직접 전송해야 하는데, 이 기능을 통해 가장 가까운 Edge Location까지는 인터넷을 이용하고 그 이후 AWS 전용 글로벌 네트워크를 사용해 속도를 높일 수 있다. Multipart Upload와 함께 사용할 수 있다.

 

Byte-Range Fetches는 큰 파일을 다운로드할 때 필요한 부분만 가져오는 기능이다. 병렬 다운로드로 속도를 높이거나 원하는 일부분의 파일만 읽어올 때 사용할 수 있다. 장애가 발생하더라도 가져오지 못한 부분만 요청하면 되기 때문에 복구에 용이하다.

7) S3 Batch Operation

Batch Operation

 

S3 Batch Operation는 많은 S3 객체에 동일한 작업을 한 번에 수행하는 서비스이다. 예를 들어, 백만 개의 객체에 Tag를 추가할 때 일일이 설정하는 것이 아닌 AWS가 자동으로 처리하도록 하는 것이다. 대표적으로 할 수 있는 작업으로는 Metadata 수정, 객체 복사, 암호화, ACL 및 Tag 수정, Glacier 객체 복원, 객체마다 Lambda를 호출하여 사용자 정의 작업 수행 등이 있다.

 

Batch Operation에서는 Job이라는 단위를 사용한다. Job은 객체 목록, 수행할 작업(Action), 옵션(Parameter)로 구성된다. 처리할 객체 목록은 주로 S3 Inventory를 사용한다. S3 Inventory는 버킷 내의 객체 목록을 담은 객체를 정기적으로 생성해주는 기능이다.

 

객체가 너무 많다면 Athena로 Inventory를 조회하여 원하는 객체만 선택할 수 있다. 예를 들어, 다음의 SQL 문을 통해 특정 객체들만 Batch Job 대상으로 만들 수 있다.

SELECT *

FROM inventory

WHERE Size > 100MB

 

AWS에서는 Batch Operations를 통해 자동으로 실패한 객체는 재시도하고, 현재 진행 상황 안내, 완료 알림 전송, 보고서 생성 등을 수행한다.

8) S3 스토리지 렌즈 (Storage Lens)

스토리지 렌즈 기능을 통해 AWS 전체에서 S3 스토리지를 이해, 분석 및 최적화할 수 있다. 이 기능은 S3를 분석하여 이상 징후를 발견하고, 비용 절감 기회를 식별하며, 데이터 보호 모범 사례를 적용하도록 한다. 스토리지 렌즈는 최근 30일간의 활동 지표 기반으로 분석하며, 이때 지표는 매일 CSV나 Parquet 형식으로 S3 버킷에 Export하도록 설정할 수 있다.

 

스토리지 렌즈에서 데이터를 집계할 수 있는 범위는 조직 전체부터 특정 AWS 계정, 특정 리전, 특정 버킷, 특정 Prefix까지 다양하다. AWS에서 제공하는 기본 대시보드를 활용하거나 사용자 커스텀 대시보드를 사용하는 것도 가능한데, 대시보드에서는 무료 및 고급 지표에 대한 요약 정보와 추세를 시각화할 수 있다. 기본 대시보드는 여러 리전과 여러 계정에 걸쳐 데이터를 보여주며 삭제는 불가하지만 비활성화는 가능하다.

 

지표의 종류는 아래와 같다.

• 요약 지표(Summary Metrics): S3 스토리지에 대한 일반적인 정보를 제공한다. 가장 빠르게 증가하는 버킷(또는 Prefix)을 찾거나 거의 사용되지 않는 버킷(또는 Prefix)을 찾는 등의 용도로 사용할 수 있다.
• 비용 최적화 지표(Cost-Optimization Metrics): 스토리지 비용을 관리하고 최적화하기 위한 정보를 제공한다. 더 저렴한 스토리지 클래스로 전환할 수 있는 객체를 찾거나 7일 이상 완료되지 않은 Multipart Upload가 있는 버킷 찾기 등의 용도로 사용 가능하다.
• 데이터 보호 지표(Data-Protection Metrics): 버킷의 데이터 보호 기능 사용 현황을 보여주는 정보를 제공한다. Versioning, MFA Delete, SSE-KMS 암호화, Cross-Region Replication(CRR) 등의 설정 여부를 확인할 수 있으며, 데이터 보호 모범 사례를 따르지 않는 버킷을 찾는 데 활용된다.
• 접근 관리 지표(Access-Management Metrics): S3 Object Ownership 및 접근 관리 설정에 대한 정보를 제공한다. 각 버킷에서 어떤 Object Ownership 설정을 사용하는지 확인하고, 접근 관리 정책이 올바르게 적용되고 있는지 파악하는 데 활용된다.
• 이벤트 지표(Event Metrics): S3 Event Notification 설정 현황에 대한 정보를 제공한다. Event Notification이 활성화된 버킷을 식별하여 이벤트 기반 자동화가 적용된 버킷을 확인하는 데 활용된다.
• 성능 지표(Performance Metrics): S3 성능 관련 기능의 사용 현황을 보여주는 정보를 제공한다. Transfer Acceleration이 활성화된 버킷을 식별하여 성능 최적화 기능의 사용 여부를 확인하는 데 활용된다.
• 활동 지표(Activity Metrics): S3 스토리지에 대한 요청 활동 정보를 제공한다. GET, PUT, LIST 요청 수와 다운로드된 데이터 등을 분석하여 버킷의 사용량과 트래픽 패턴을 파악하는 데 활용된다.
• 상세 상태 코드 지표(Detailed Status Code Metrics): S3 요청에 대한 HTTP 응답 상태 코드 정보를 제공한다. 200(성공), 403(권한 없음), 404(객체 없음) 등의 응답 횟수를 분석하여 권한 문제나 잘못된 요청, 존재하지 않는 객체에 대한 접근 등의 운영 이슈를 파악하는 데 활용된다.

모든 AWS 고객에게 무료로 제공되는 지표는 약 28개의 사용량 지표를 포함하며, 14일동안 조회 가능하다.

 

추가 비용을 지불하면 Activity Metrics, Advanced Cost Optimization Metrics 등과 같은 고급 지표를 제공한다. 또한 이러한 고급 지표들은 CloudWatch에 퍼블리쉬되어 추가 비용 없이 접근 가능하다. 추가적으로 S3 버킷 내의 Prefix 수준에서 지표를 수집할 수 있다. 데이터는 15개월동안 조회 가능하다.

9) S3의 보안

Amazon S3는 저장되는 객체를 보호하기 위해 다양한 암호화 방식을 제공하며, 사용 목적과 키 관리 방식에 따라 다음 네 가지 방법을 사용할 수 있다.

• Server-Side Encryption(SSE): 객체가 Amazon S3에 업로드된 후 S3 서버에서 암호화되는 방식이다. 키를 누가 관리하는지에 따라 SSE-S3, SSE-KMS, SSE-C로 구분된다.
  • Server-Side Encryption with Amazon S3-Managed Keys(SSE-S3): AWS가 암호화 키를 생성, 관리, 소유하는 기본 암호화 방식이다. 객체는 서버 측에서 AES-256 알고리즘으로 암호화되며, 업로드 시 x-amz-server-side-encryption: AES256 헤더를 지정하여 사용할 수 있다. 현재는 새로운 S3 버킷과 객체에 대해 기본적으로 활성화되어 있다.
  • Server-Side Encryption with AWS KMS Keys(SSE-KMS): AWS Key Management Service(AWS KMS)를 이용하여 암호화 키를 관리하는 방식이다. 객체는 서버 측에서 암호화되며, 업로드 시 x-amz-server-side-encryption: aws:kms 헤더를 지정한다. 사용자가 암호화 키에 대한 접근 권한을 직접 제어할 수 있고, 키 사용 내역을 CloudTrail을 통해 감사할 수 있다는 장점이 있다. 다만 객체 업로드 시에는 GenerateDataKey API, 다운로드 시에는 Decrypt API를 호출하므로 KMS 요청 한도의 영향을 받을 수 있으며, 필요 시 한도 증가를 요청할 수 있다.
  • Server-Side Encryption with Customer-Provided Keys(SSE-C): 고객이 직접 생성하고 관리하는 암호화 키를 사용하는 방식이다. AWS는 암호화 키를 저장하지 않으며, 객체를 업로드하거나 다운로드할 때마다 HTTPS를 통해 암호화 키를 HTTP 헤더에 포함하여 전달해야 한다.
• Client-Side Encryption: 데이터를 Amazon S3에 업로드하기 전에 클라이언트에서 직접 암호화하고, 다운로드한 후에도 클라이언트에서 직접 복호화하는 방식이다. Amazon S3는 이미 암호화된 데이터만 저장하며 암호화 과정에 관여하지 않는다. 일반적으로 Amazon S3 Client-Side Encryption Library와 같은 라이브러리를 사용하며, 암호화 키 관리와 암호화·복호화 과정 모두를 고객이 직접 책임진다.

더불어 전송 중의 암호화 방식을 SSL/TLS라 부른다. S3 버킷에는 기본적으로 암호화가 제공되지 않는 HTTP 엔드포인트와 전송 중 암호화를 제공하는 HTTPS 엔드포인트, 2개의 엔드포인트가 존재한다. 따라서 HTTPS를 사용하는 것이 권장되며 SSE-C 타입 메커니즘을 사용한다면 반드시 HTTPS 프로토콜을 사용해야 한다. 전송 중 암호화는 버킷 정책을 통해 강제할 수 있다.

 

암호화 정책은 기본값으로 SSE-S3로 제공된다. 버킷 정책을 선제적으로 적용하면 원하는 암호화 방식으로 변경 가능하다.

 

한편, CORS(Cross-Origin Resource Sharing)는 웹 브라우저에서 현재 웹 페이지와 다른 Origin의 리소스에 접근할 수 있도록 허용하는 보안 메커니즘이다. Origin은 HTTP, HTTPS와 같은 Scheme(프로토콜), 호스트(도메인), 포트 번호로 구성된다. 브라우저에서는 기본적으로 동일 출처 정책을 적용해 다른 Origin으로의 요청을 제한한다. 만약 다른 Origin으로, 즉 프로토콜, 도메인, 포트 중 하나라도 다른 곳으로 요청을 보내면, 요청 대상 서버가 이를 허용하지 않을 시 브라우저는 응답을 차단한다. 따라서 서버는 CORS 헤더를 통해 다른 Origin의 접근을 허용해야 하며, 대표적으로 Access-Control-Allow-Origin 헤더를 사용하여 접근 가능한 Origin을 지정한다.

 

S3 버킷의 객체를 다른 Origin의 웹 애플리케이션에서 접근할 때에도 CORS를 설정해야 한다. 예를 들어, 웹 애플리케이션이 https://www.example.com에서 실행되고, 이미지나 파일은 S3 버킷에 저장되어 있는 경우 브라우저는 이를 Cross-Origin 요청으로 인식한다. 이때 S3 버킷에 적절한 CORS 설정이 없으면 브라우저가 요청을 차단하여 객체를 정상적으로 사용할 수 없다. 따라서 S3 버킷에는 CORS 규칙을 추가하여 어떤 Origin의 요청을 허용할 것인지 지정해야 한다. CORS 설정에서는 다음과 같은 방식으로 접근을 허용할 수 있다.

• 특정 Origin 허용: 예를 들어 https://www.example.com에서 오는 요청만 허용한다.
• 모든 Origin 허용(*): 모든 도메인에서의 요청을 허용한다. 다만 보안상 필요한 경우에만 사용하는 것이 권장된다.

또 다른 주요한 S3의 보안 기능은 MFA(Multi-Factor Authentication) Delete 기능이다. Amazon S3에서 중요한 삭제 작업을 수행할 때 다중 인증을 요구하여 객체를 더욱 안전하게 보호하는 기능으로, 사용자는 비밀번호뿐만 아니라 모바일 인증 앱이나 하드웨어 토큰에서 생성된 일회용 인증 코드를 함께 입력해야 작업을 수행할 수 있다. MFA Delete를 활성화하면, 객체의 버전을 영구적으로 삭제하거나 버킷의 Versioning을 비활성화할 때 MFA 인증을 필수로 요구한다. 따라서 MFA Delete를 사용하려면 버킷에서 Versioning 기능을 반드시 활성화해야 한다. MFA Delete의 활성화 및 비활성화는 버킷 소유자의 AWS 루트 계정만 수행할 수 있다.

 

S3 버킷에 대한 모든 접근 요청을 다른 S3 버킷에 저장하는 Access Log 기능은 감사, 보안 분석 및 접근 패턴 분석에 활용할 수 있다. 로그는 접근이 허용된 요청뿐만 아니라 거부된 요청도 포함되며, 요청을 보낸 AWS 계정, 요청 시간, 요청한 작업, 응답 상태 등의 정보가 기록된다. 로그를 저장하는 버킷은 원본 버킷과 동일한 리전에 있어야 한다. 이때 로그 저장 버킷과 원본 버킷을 동일한 버킷으로 지정하면 무한 로그 루프가 발생하여 버킷의 저장용량이 기하급수적으로 증가하므로 둘을 분리하도록 주의해야 한다.

 

S3 객체에 접근 권한이 없는 사용자에게 일정 시간 동안만 특정 객체에 접근할 수 있도록 Pre-signed URL을 제공한다. 이 URL을 통해 사용자는 AWS 자격 증명 없이도 객체를 다운로드하거나 업로드할 수 있다. Pre-signed URL은 S3 콘솔, AWS CLI 또는 AWS SDK를 이용해 생성할 수 있으며, 생성 시 URL의 유효 기간을 지정할 수 있다. S3 콘솔로는 1분~12시간, AWS CLI는 초 단위로 최대 7일까지 지정 가능하며, AWS SDK로는 프로그래밍 방식으로 원하는 만료 시간을 지정할 수 있다. Pre-signed URL을 사용하는 사용자는 URL을 생성한 사용자의 권한을 상속받는다.

 

S3 Glacier Vault Lock은 WORM(Write Once Read Many) 모델을 적용하여 한 번 잠그면 더 이상 정책을 수정하거나 삭제할 수 없도록 하는 것이 핵심이다. 이를 통해 데이터 보관 규정을 강제로 준수할 수 있도록 하며, 금용, 의료, 공공기관 등 규제 준수가 중요한 환경에서 많이 사용된다.

 

마찬가지로 WORM 모델을 적용한 S3 Object Lock은 개별 객체 버전에 대해 보호를 수행하는 방식으로, 버전 관리(Versioning)가 활성화되어 있어야 한다. 2가지 모드가 존재하는데, Compliance Mode는 가장 강력한 보호 모드로, 누구도 객체를 삭제하거나 변경할 수 없도록 하는 방식이며, Governance Mode는 관리 목적의 보호 모드로 특별한 IAM 권한을 가진 관리자만 예외적으로 보존 기간을 변경하거나 객체를 삭제할 수 있도록 허용한다.

 

Glacier Vault Lock과 Object Lock 모두 Retention Period에서 보호 기간을 설정할 수 있으며 연장 가능하다. 만약 소송 진행 중이거나 법적 조사를 받을 때처럼 언제까지 보호해야할 지 모르는 경우, Legal Hold를 사용할 수 있다.

S3 Access Points

 

추가적으로 S3 버킷을 여러 사용자나 애플리케이션이 사용할 때 접근 권한을 보다 간편하고 효율적으로 관리할 수 있도록 S3 액세스 포인트 기능을 사용할 수 있다. 각 액세스 포인트는 인터넷이나 VPC를 통해 접근할 수 있는 고유한 DNS 이름과 버킷 정책과 유사하여 액세스 포인트 별로 접근 권한을 독립적으로 관리할 수 있는 액세스 포인트 정책으로 구성되어 있다. VPC 전용 액세스 포인트를 사용하기 위해선 게이트웨이 엔드포인트와 인터페이스 엔드포인트에 접근할 수 있는 VPC 엔드포인트를 생성해야 한다. 이때, VPC 엔드포인트 정책에는 대상 S3 버킷과 액세스 포인트에 대한 접근 권한이 허용되어 있어야 한다.

S3 객체 람다

 

S3 액세스 포인트의 또 다른 활용 사례로 S3 객체 람다가 있다. 이 기능은 원본 객체를 수정하지 않고도 요청하는 사용자나 애플리케이션의 요구에 맞는 데이터를 동적으로 제공할 수 있도록 한다. S3 객체 람다는 기존 S3 버킷 위에 S3 액세스 포인트와 S3 객체 람다 액세스 포인트를 생성하여 사용한다. 애플리케이션은 S3 버킷이 아닌 S3 오브젝트 객체 람다 액세스 포인트를 통해 객체를 요청하며, 요청이 들어오면 지정된 람다 함수가 실행되어 객체를 가공한 뒤 결과를 반환한다. 따라서 주로 개인 식별 정보를 마스킹해서 제공하거나 데이터 형식 변환, 이미지 실시간 가공 등으로 활용된다.