Amazon S3 고급
S3 생애 주기 규칙
여러 스토리지 클래스 간에 객체를 이동할 수 있음
- 객체에 잘 자주 엑세스 하지 않을 것을 알고 있다면 Standard IA로 이동
- 객체를 아카이브할 예정임을 알고 있다면 Glacier / Glacier Deep Archive로 이동
수명 주기 규칙을 사용해 자동화할 수도 있음
수명 주기 규칙(Lifecycle Rules)
- 전환 작업 : 객체를 구성해 다른 스토리지 클래스로 위한 전환 작업
- 예시
- 생성한지 60일 후에는 표준 클래스로 이동
- 6개월 후에는 아키이빙을 위해 Glacier로 이동
- 만료 작업 : 일정 기간이 지나면 객체가 삭제되어 만료되도록 구성
- 예시
- 엑세스 로그 파일의 경우 365일 후 삭제할 수도 있음
- 버전 관리를 활성화 했다면 만료 작업을 사용해 모든 파일을 삭제할 수 있음
- 완료되지 않은 멀티 파트 업로드를 삭제할 수 있음 (2주 이상 지났다면 완료 되어야 함)
- 특정 접두사에 규칙을 지정하여 전체 버킷이나 버킷 내의 특정 경로에 적용되도록 할 수도 있음
- 특정 객체 태그에 지정할 수도 있음
예시
EC2에 애플리케이션이 있고 Amazon S3에 프로필 사진이 업로드된 후 이미지, 썸네일을 만들지만 이 썸네일은 원본 사진에서 쉽게 만들 수 있고 60일만 보관하면 된다. 하지만 원본 이미지는 이 60일 동안 즉시 검색할 수 있어야 하며 그 후 사용자는 6시간까지 기다릴 수 있다.
- S3 원본 이미지는 수명 주기 설정을 통해 60일 후 Glcier로 전환되도록 표준 클래스에 있을 수 있음
- 썸네일은 One-Zone-IA에 두어 수명 주기 설정을 통해 60일 후 만료되도록 하거나 삭제할 수 있음(자주 엑세스 하지 않고 쉽게 다시 만들 수 있기 때문에)
- 썸네일 이미지는 접두사를 사용해 원본과 썸네일을 구분할 수 있음
회사 규칙에 따라 30일동안 삭제된 S3 객체를 즉시 복구할 수 있어야 한다. 최대 365일 동안 삭제된 객체를 48시간 내에 복구할 수 있어야 한다.
- 객체 버전을 유지하고 관리하도록 S3 버전 관리를 활성화하여 삭제된 객체는 삭제 마커를 통해 숨기고 복구할 수 있도록 해야 함
- 최신 버전이 아닌 버전, 즉 최상위 버전이 아닌 버전을 표준 IA로 전환하는 규칙을 만듦
- 이 최신이 아닌 버전을 아카이브를 위해 Glacier Deep Archive로 전환할 수 있음
Amazon S3 분석
- 객체의 클래스를 전환하는데 가장 적합한 일 수를 결정하는 데에 도움을 줌
- 표준이나 표준 IA를 권장
- One-Zone IA, Glacier에서는 사용 불가능
- 보고서는 매일 업데이트 됨
- 데이터 분석을 보기 시작하는데까진 24 ~ 48시간이 걸림
S3 이벤트 알림
이벤트란?
객체가 생성되거나 삭제되거나 복제되거나 복원이 일어나는 것
객체 이름을 필터링 할 수 있음 (ex. 확장자가 .jpg)
원하는 만큼 S3 이벤트를 생성할 수 있음
S3 이벤트는 원하는 대상으로 보낼 수 있으며 즉시 전달됨, 때로는 몇 분 걸림
IAM 권한
이벤트 알림이 작동하기 위해서는 IAM 권한이 필요함
- SNS 리소스 접근 정책 : S3 버킷 > SNS 주제로 메시지
- SQS 리소스 접근 정책 : S3 버킷 > SQS 큐에 데이터를 보낼 수 있도록 인증
- Lambda 리소스 정책 : Amazon S3가 함수를 호출할 권리가 있는지 확인
Amazon EventBridge
이벤트는 모두 S3 버킷으로 가서 모두 Amazon EventBridge으로 감
Amazon EventBridge에서는 규칙을 설정할 수 있고, 이 규칙 덕분에 18 종류의 aws 서비스를 목적지로 해서 이벤트를 보낼 수 있음
JSON 규칙을 통해 고급 필터링 옵션을 사용할 수 있음(메타 데이터, 객체 크기, 이름, ...)
여러 개의 목적지로 보낼 수 있음
EventBridge에서 직접 제공하는 기능 : 아카이브, 이벤트 재현, 안정적 전달
S3 퍼포먼스
S3는 매우 높은 요청 수로 자동으로 스케일링되며 S3에서 첫 번째 바이트를 가져오는데 100 ~ 200 밀리초의 매우 짧은 지연 시간을 가짐
버킷 내에서 prefix 당 초당 3500개의 넣기(PUT), 복사(COPY), 올리기(POST), 또는 삭제를(DELETE) 하거나 5500개의 가져오기(GET) 또는 헤드(HEAD) 요청을 가져옴
- 버킷의 접두사 수에는 제한이 없음
- 예시) file이라는 이름의 객체 4개
bucket/folder1/sub1/file=> 접두사 :/folder1/sub1bucket/folder1/sub2/file=> 접두사 :/folder1/sub2bucket/1/file=> 접두사 :/1/bucket/2/file=> 접두사 :/2/
=> 하나의 접두사에 대해 3500개의 넣기와 5500개의 가져오기를 얻음- 위의 4개 접두사 모두에 균등하게 읽기를 분산하면 22000개의 헤드 및 가져오기 요청이 가능
최적화
멀티 파트(Multi-Part) 업로드
100MB가 넘는 파일에 권장
5GB 이상은 반드시 사용
업로드를 병렬화 => 전송 속도를 높여 대역폭을 최적화
S3 전송 가속화
업로드 및 다운로드를 위함
파일을 aws 엣지 로케이션으로 전송하여 전송 속도를 높임 => 해당 데이터가 대상 지역의 S3 버킷으로 전달
멀티파트 업로드와 호환됨
공공 인터넷을 사용하여 파일을 한 지역의 엣지 로케이션을 통해 업로드 할 수 있음
그 다음 해당 엣지 로케이션에서 타 지역의 aws S3 버킷으로 빠른 프라이빗 aws 네트워크를 통해 파일을 전송
S3 Byte-Range Fetches
파일을 가져올 때 파일의 특정 바이트 범위를 가져와 가져오기를 병렬화 하는 것
따라서 특정 바이트 범위를 가져오는데 실패한 경우라도 더 작은 바이트 범위를 다시 시도 가능
실패 시 복원력이 향상됨
병렬로 처리 + 다운로드 속도를 높이는데 사용할 수 있음
파일의 일부만 검색하여 사용할 수 있음
S3 사용자 정의 객체 메타데이터, S3 객체 태그
- S3 사용자 정의 객체 메타데이터 (S3 User-Defined Object Metadata)
- 객체를 만들고 객체를 업로드할 때 메타데이터도 할당할 수 있음
- 메타데이터는 객체에 연결된 키 값 쌍에 대한 이름
- 사용자 정의 메타데이터를 업로드하면
x-amz-meta-로 시작하는 이름을 부여해야 함 - aws S3는 사용자 정의 메타데이터 키를 소문자로 저장함
- 메타데이터는 객체를 검색할 때 검색할 수 있으며, 객체 자체에 대한 정보를 제공함
- S3 객체 태그(S3 Object Tags)
- S3 객체에 대한 키 값 쌍이 있음
- 태그를 이용해 권한 등을 세분화하거나 aws 내의 특정 태그가 있는 특정 객체에 엑세스를 부여할 수 있음
- S3 분석과 같은 솔루션을 사용할 경우 태그로 검색 결과를 그룹화할 수 있음
- S3에서 메타데이터와 태그를 검색할 수 없음(메타데이터나 태그를 통해 필터링 X)
- S3 버킷에서 검색을 사용하려면 외부 데이터베이스에 인덱스를 구축해야 함(ex. DynamoDB)
Amazon S3 보안
S3 암호화
S3 버킷의 객체를 암호화할 수 있는 방법
- 서버 측 암호화(Server-Side Encryption, SSE)
- SSE-S3은 Amazon S3-Managed Keys로 암호화 하며 버킷과 객체에 기본적으로 활성화 되어 있음
- aws에 의해 관리됨
- KMS 키로 암호화 키를 관리해서 암호화하는 SSE-KMS가 있음
- 사용자 제공 키를 사용하는 SSE-C
- 직접 암호화 키를 제공
- 클라이언트 측 암호화 : 클라이언트 측에서 암호화한 다음 S3에 업로드
SSE-S3
이 암호화에서 사용되는 키는 aws에서 관리하고 소유함
aws 서버 측에서 객체를 암호화
암호화 보안 유형은 AES-256
헤더에 반드시 "x-amz-server-side-encryption":"AES256"을 설정해야 함
새로운 버킷과 객체에는 기본적으로 SSE-S3가 활성화됨
SSE-KMS (Key Management Service)
aws의 KMS 서비스를 사용해 자신의 키를 직접 관리함
KMS에서 키를 생성하고 CloudTrail을 사용하여 사용을 감시할 수 있음
- aws에서 일어나는 일을 모두 로그로 남기는 것을 CloudTrail이라 함
헤더에 반드시 "x-amz-server-side-encryption":"aws:kms"을 설정해야 함
서버 측에서 객체가 암호화 됨
KMS 키는 자체 api가 있음, 예를 들면 GenerateDataKey
따라서 KMS 서비스에 api를 호출해야 함
이러한 api 호출은 KMS의 초당 api 호출 할당량에 포함됨(리전에 따라 초당 5000 ~ 30000 요청을 처리할 수 있음)
콘솔에서 서비스 할당량을 늘릴 수 있음
처리량이 많은 S3 버킷이 있다면 KMS 키를 사용하여 모든 것이 암호화 되므로 주의가 필요함
SSE-C
aws에 키를 보내기 때문에 키는 aws 외부에서 관리되지만 서버 측 암호화에 포함됨
aws S3는 제공한 키를 저장하지 않음
aws에 키를 보내기 때문에 HTTPS 통신을 사용해야 하며, 모든 HTTP 요청의 헤더에 키를 전달해야 함
클라이언트 측 암호화
클라이언트 암호화 라이브러리를 사용할 수 있음
S3에 데이터를 전송하기 전에 클라이언트가 데이터를 직접 암호화 함
데이터 복호화는 S3 외부 클라이언트에서 발생함
클라이언트가 키를 비롯한 암호화 주기 전체를 관리함
전송 중 암호화(SSL/TLS)
S3에는 두 개의 엔드포인트가 있음
- HTTP 엔드포인트 : 암호화되지 않음
- HTTPS 엔드포인트 : 암호화됨
S3를 사용할 때 데이터를 안전하게 전송하기 위해 HTTPS를 사용하길 권장함
SSE-C 유형의 메커니즘을 사용하는 경우 HTTPS 프로토콜 사용이 필수
대부분의 클라이언트는 기본적으로 HTTPS를 기본적으로 사용함
전송 중에 암호화를 강제하는 방법 => 버킷 정책을 사용하면 됨(객체를 가져오는 작업을 거부)
기본 암호화 vs 버킷 정책
- **모든 버킷은 기본 암호화인 SSE-S3를 사용하며 새로운 버킷에 저장된 새로운 객체에 자동으로 적용됨
- 버킷 정책을 통해 올바른 암호화 헤더가 없는 S3 객체에 적용되는 api 호출을 거부하도록 하여 암호화를 강제로 적용할 수도 있음 (SSE-KMS, SSE-C)
- 버킷 정책은 항상 기본 암호화 설정 이전에 평가됨
S3 CORS
CORS란?
CORS : Cross Origin Resource Sharing, 교차 오리진 리소스 공유
Origin : 프로토콜 + 호스트(도메인) + 포트
CORS는 기존 오리진에 방문할 때 다른 오리진에 대한 요청을 허용하거나 거부하는 웹 브라우저 기반 보안 메커니즘
오리진이 동일하다는 것 => 동일한 호스트, 동일한 포트
http://example.com/app1 & http://example.com/app2
오리진이 다름 => http://www.example.com & http://other.example.com
오리진이 다를 때 다른 오리진에서 CORS 헤더를 사용한 요청을 허용하지 않는 한 충족되지 않음 (ex. Access-Control-Allow-Origin
Amazon S3 - CORS
클라이언트가 S3 버킷에 교차 오리진 요청을 보내는 경우 올바른 CORS 헤더를 활성화 해야 함
특정 오리진을 허용하거나 모든 오리진(*)을 허용하는 방법이 있음
S3 MFA 삭제
버전 관리를 활성화해야함
루트 계정은 MFA 삭제를 활성화하거나 비활성화 할 수 있음
MFA 삭제(옵션?설정?)는 특정 객체 버전이 영구적으로 삭제되지 않도록 하는 추가 보호
S3 엑세스 로그
감사를 위해 S3 버킷에 보낸 모든 엑세스를 기록하고자 할 수 있음
모든 계정에서 S3 버킷에 보낸 모든 요청이 승인/거부되든 다른 버킷에 파일로 기록됨
모인 데이터는 데이터 분석 도구를 통해 분석 가능
대상 로그 버킷은 동일한 aws 영역에 있어야 함
로깅 버킷과 모니터링하는 버킷을 동일한 버킷으로 설정하면 안됨
=> 무한한 로깅 루프가 생기고 버킷의 크기가 기하급수적으로 증가함
S3 사전 로그인된(presigned) URL
퍼블릭 url이 열리지 않는 이유는 버킷이 비공개이기 때문
S3 콘솔, aws CLI, SDK를 사용해 생성할 수 있는 url
만료기간이 있음
- S3 콘솔 : 12시간
- aws CLI : 최대 168시간
미리 서명된 url을 생성하면 해당 url을 받게 되는 사용자에게 GET이나 PUT 작업에서 생성된 url의 사용자 권한이 상속됨
미리 서명된 url은 특정 파일을 다운로드하거나 업로드하기 위한 일시적인 엑세스가 필요할 때 주로 사용
- 사례
- 로그인한 사용자만 S3 버킷에 있는 프리미엄 비디오를 다운로드할 수 있도록 함
- url을 동적으로 생성하여 파일을 다운로드할 사용자의 목록을 계속 변경되도록 함
- S3 버킷을 프라이빗으로 유지하면서 일시적으로 S3 버킷의 구체적인 위치에 사용자가 파일을 업로드하도록 함
S3 엑세스 포인트
엑세스 포인트를 사용하면 S3 버킷의 보안 관리를 간단하게 할 수 있음
각 엑세스 포인트에는 각각의 DNS 이름이 있음(VPC(프라이빗 트래픽) 오리진이나 인터넷 오리진)
각 엑세스 포인트에는 버킷 정책과 매우 유사힌 엑세스 포인트 정책을 연결할 수 있으며 대규모로 보안을 관리할 수 있음
VPC Origin
S3 엑세스 포인트의 VPC Origin의 경우 프라이빗 엑세스로 정의할 수 있음
VPC 오리진에 대한 엑세스 권한을 얻으려면 엑세스 포인트에 엑세스하려 할 때 VPC 엔드포인트라고 하는 것을 만들어야 함(게이트웨이 혹은 인터페이스 엔드포인트)
VPC 엔드포인트라는 정책이 있으며 이 정책은 대상 버킷과 엑세스 포인트에 대한 엑세스를 허용해야 함
S3 Object Lambda
S3 버킷을 사용 중인데 애플리케이션에서 검색하기 전에 객체를 수정하려는 경우
=> 버킷을 복제해 각 객체를 여러 버전으로 만들지 않기 위해 S3 Object Lambda를 사용함
=> S3 엑세스 포인트 사용
PII 데이터, 개인 식별 정보를 분석이나 비생산 환경용으로 편집하는 경우에 사용
XML에서 JSON으로 데이터 형식을 변환하는 경우
즉시 이미지 크기를 조정하고 워터마크를 추가하는 등의 변환 작업을 하는 경우
특히 워터마크는 객체를 요청하는 사용자별로 지정하기 때문에 S3 Object Lambda 활용 사례로 유용함
