반응형
S3 수명 주기 규칙
- S3 버킷 내부의 객체는 수명 주기 규칙을 이용해서 객체의 이동을 자동화할 수 있다.
- 수명 주기 규칙은 여러 가지로 구성된다.
- 전환 작업
- 다른 스토리지 클래스로 객체를 전환하도록 구성한다.
- 생성 60일 후에 Standard IA로 이동하도록 설정하거나 6개월 후에 Glacier에 아카이빙 되도록 설정할 수 있다.
- 만료 작업 설정
- 만료 작업을 설정할 수 있어 일정 시간이 지나면 객체가 삭제 또는 만료되게 할 수 있다.
- 365일 후에 액세스 로그 파일을 삭제하도록 하거나 버저닝을 활성화한 경우 이전 버전의 파일을 삭제하도록 설정할 수 있다.
- 규칙에는 특정 접두사를 사용하여 전체 버킷이나 버킷의 일부 경로에만 적용할 수 있고 특정 객체 태그에만 지정할 수도 있습니다
한 클래스에서 다른 클래스로 객체를 전환하는 최적의 기간을 선택하는 방법은 Amazon S3 Analytics를 이용해서 결정하면 된다.
S3 요청자 지불
- 일반적으로는 버킷 소유자가 버킷과 관련된 모든 Amazon S3 스토리지 및 데이터 전송 비용을 지불한다.
- 요청자 지불 버킷을 활성화해 버킷 소유자가 아닌 요청자가 객체 다운로드와 관련된 네트워크 비용을 지불하게 할 수 있다.
- 요청자는 AWS에서 인증을 받아야만 한다.
S3 이벤트 알림
- S3에서 발생하는 특정 이벤트에 자동으로 반응하게 할 수 있다.
- 이벤트 알림을 만들어서 몇 가지 수신자로 보낸다.
- SNS 토픽
- SQS 큐
- 람다 함수
- Amazon EventBridge
- 원하는 만큼 S3 이벤트를 생성하고 원하는 대상으로 보낼 수 있다.
S3 퍼포먼스
- 기본적으로 Amazon S3는 요청이 아주 많을 때 자동으로 확장된다.
- S3로부터 첫 번째 바이트를 수신하는 데 지연 시간도 100~200밀리초 사이로 아주 짧다,
- 접두사당(prefix) 초당 3,500개의 PUT/COPY/POST/DELETE 초당 5,500개의 GET/HEAD 요청을 지원한다.
멀티파트 업로드
- 100MB가 넘는 파일은 멀티파트 업로드를 사용하는 것이 좋고 5GB가 넘는 파일은 반드시 사용해야 한다.
- 멀티파트 업로드는 업로드를 병렬화하므로 전송 속도를 높여 대역폭을 최대화할 수 있다.
전송 속도 가속화
- 파일을 AWS 엣지 로케이션으로 전송해서 전송 속도를 높이고 데이터를 대상 리전에 있는 S3 버킷으로 전달한다.
- 퍼블릭 인터넷의 사용량을 최소화하고 프라이빗 AWS 네트워크의 사용량을 최대화
바이트 범위 가져오기
- 파일에서 특정 바이트 범위를 가져와서 GET 요청을 병렬화한다.
- 특정 바이트 범위를 가져오는 데 실패한 경우에도 더 작은 바이트 범위에서 재시도하므로 실패의 경우에도 복원력이 높다.
- 사용 사례는 다운로드 속도를 높일 때다. GET 요청을 병렬화해서 다운로드 속도를 높인다.
- 두 번째 사용 사례는 파일의 일부만 검색하는 것이다. 바이트 범위를 이용해서 원하는 정보만 빠르게 검색한다.
S3 Select & Glacier Select
- S3 Select를 사용하면 Amazon S3가 대신 파일을 필터링해 주고 필요한 데이터만 검색할 수 있다.
- 클라이언트의 부담이 줄어든다. 간단한 필터링에는 S3 Select나 Glacier Select를 추천한다.
- Amazon S3 Select를 사용하면 속도는 400% 빨라지고 비용은 80% 줄어든다.
S3 Batch Operations
단일 요청으로 기존 S3 객체에서 대량 작업을 수행하는 서비스다.
- 한 번에 많은 S3 객체의 메타데이터와 프로퍼티를 수정할 수 있고 배치 작업으로 S3 버킷 간에 객체를 복사할 수 있다.
- S3 Inventory를 사용해 암호화되지 않은 모든 객체를 찾은 다음 S3 Batch Operations를 사용해 한 번에 모두 암호화할 수 있다.
- ACL이나 태그를 수정할 수 있고 S3 Glacier에서 한 번에 많은 객체를 복원할 수 있다.
- Lambda 함수를 호출해 S3 Batch Operations의 모든 객체에서 사용자 지정 작업을 수행할 수도 있다.
- 작업은 객체의 목록, 수행할 작업 옵션 매개 변수로 구성된다. 객체 목록에서 원하는 작업은 무엇이든지 수행할 수 있다.
- S3 Batch Operations를 사용하면 재시도를 관리할 수 있고 진행 상황을 추적하고 작업 완료 알림을 보내고 보고서 생성 등을 할 수 있다.
S3 암호화
S3 버킷 내 객체를 암호화하는 방법은 4가지가 있다.
암호화는 객체의 특정 버전 id에 적용된다.
버킷 정책을 사용해 암호화 헤더가 없으면 api 호출이 불가능하게 설정이 가능하다.
S3 기본 암호화 옵션을 사용해 객체가 암호화되지 않은 채로 올려도 S3에 의해 암호화 시키는 것도 가능하다.
서버 측 암호화
SSE-S3
- Amazon S3 관리형 키를 사용하는 서버 측 암호화인 SSE-S3가 있다.
- 사용자는 이 키에 접근할 수 없다.
- AES-256 보안 유형으로 암호화가 이루어진다.
- 헤더(header)를 "x-amz-server-side-encryption": "AES256"로 설정해서 SSE-S3 메커니즘으로 객체를 암호화하도록 Amazon S3에 요청해야 한다.
SSE-KMS
- KMS 키를 사용해서 암호화 키를 관리하는 SSE-KMS가 있다.
- KMS 내에서 직접 키를 생성하고 CloudTrail을 사용해서 사용량을 감사할 수 있다. 즉 키를 사용자가 직접 관리한다.
- 헤더는 "x-amz-server-side-encryption": "aws:kms"로 지정해야 하면 서버에서 객체를 암호화한다.
- S3 버킷에서 해당 파일을 읽으려면 객체 자체에 대한 액세스뿐만 아니라 객체를 암호화하는 데 사용된 KMS 키에 대한 액세스도 필요하다. 이를 통해 보안이 더욱 강화된다.
- KMS 키에는 GenerateDataKey 같은 자체 API가 있고 복호화할 때는 복호화 API를 호출한다.
- 따라서 KMS 서비스에 API 호출을 수행해야 하는데 각 API 호출은 초당 KMS 할당량에 포함된다.
- 리전에 따라 초당 5,500-30,000개의 요청을 처리할 수 있지만 서비스 할당량 콘솔로 한도를 늘릴 수 있다.
- 따라서 처리량이 매우 높은 S3 버킷이 있고 모든 파일이 KMS 키로 암호화 되었다면 스로틀링 오류 등의 사례가 발생할 수 있다.
SSE-C
- 고객이 제공하는 키를 사용하는 SSE-C가 있다. 이 경우에는 스스로 암호화 키를 제공해야 한다.
- 제공된 암호화 키는 Amazon S3에 저장되지 않고 사용 후 폐기된다.
- 암호화된 해당 파일을 다시 읽으려면 암호화에 사용한 키가 필요하다.
클라이언트 측 암호화
- 클라이언트 측에서 모든 것을 암호화한 다음에 Amazon S3에 업로드 한다. 복호화도 클라이언트에서 수행한다.
전송 중 암호화 (SSL & TLS)
S3 CORS
- Cross-Origin Resource Sharing == CORS
- Origin = scheme (프로토콜) + host (domain) + port
- CORS는 웹 브라우저 기반 보안 메커니즘으로 메인 오리진을 방문하는 동안 다른 오리진에 대한 요청을 허용하거나 거부한다.
- 클라이언트가 S3 버킷에서 교차 오리진 요청을 하면 정확한 CORS 헤더를 활성화해야 한다.
참고로 체계, 호스트, 포트가 동일할 때 오리진이 같다고 말한다.
MFA Delete
- 멀티 팩터 인증을 의미한다.
- MFA Delete는 버킷에서 버저닝을 중단하거나, 객체 버전을 영구적으로 삭제할 때 영구 삭제에 대한 보호 설정으로 필요하다.
- MFA Delete를 사용하려면 먼저 버킷에서 버저닝을 활성화하고, 루트 계정이 MFA Delete를 활성화 해야 한다.
- MFA Delete는 추가 보호 기능이며 특정 객체 버전의 영구 삭제를 방지하는 역할을 한다는 점이 중요하다.
액세스 로그
- 감사 목적으로 S3 목적에 대한 모든 액세스를 기록할 수 있다.
- 해당 데이터는 Amazon Athena 같은 데이터 분석 도구로 분석할 수 있다.
- 대상 로깅 버킷은 같은 AWS 리전에 있어야 한다.
- 절대로 로깅 버킷을 모니터링하는 버킷과 동일하게 설정하면 안된다.
- 동일하게 설정하면 로깅 루프가 생성되고 무한 반복되어 버킷의 크기가 기하급수적으로 증가한다.
미리 서명된 URL
- S3 콘솔, CLI, SDK를 사용해 생성할 수 있는 URL
- URL에는 만료 기한이 있는데 S3 콘솔을 사용하면 최대 12시간이고 CLI를 하면 168시간까지 사용할 수 있다.
- 미리 서명된 URL을 생성할 때 URL을 받는 사용자는 URL을 생성한 사용자의 GET 또는 PUT에 대한 권한을 상속한다.
- 프라이빗 버킷의 사용자가 공개할 파일을 가지고 미리 서명된 URL을 만들고, 파일에 대한 액세스 권한을 부여할 대상 사용자에게 보내면 사용자는 만료 기간 전에 URL을 사용해서 S3 버킷의 파일에 액세스한다.
- 특정 파일에 임시로 액세스 할때 널리 사용되는 방법이다.
객체 잠금 정책 및 Glacier Vault Lock
글래시어 볼트 락
- WORM 모델을 채용하기 위해 Glacier 볼트를 잠근다.
- WORM(Write Once Read Many Model) → 한 번 쓰고 여러 번 읽는다는 뜻
- 객체를 가져와서 S3 Glacier 볼트에 넣은 다음 수정하거나 삭제할 수 없도록 잠그는 것이다.
- 먼저 Glacier 위에 볼트 잠금 정책을 생성한 다음 향후 편집을 위해 정책을 잠근다.
- 누구도 변경 X, 삭제 X
객체 잠금
- 객체 잠금을 활성화하려며 먼저 버저닝을 활성화해야 한다.
- WORM 모델 채택 가능
- 버킷 내의 모든 객체에 각각 적용할 수 있는 잠금
- S3 객체 잠금을 사용하면 특정 객체 버전이 특정 시간 동안 삭제되는 걸 차단할 수 있다.
- 규정 준수 모드: 사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나 삭제할 수 없다.
- 거버넌스 보존 모드: 규정 준수 모드 보다 유연함. 관리자와 일부 사용자에게 IAM을 통해 부여 받은 특별 권한으로 보존 기간을 변경하거나 객체를 바로 삭제 가능
- 규정 준수 모드, 거버넌스 보존 모드 두 가지 모드 모두 보존 기간을 설정해야 한다.
- 보존 기간을 설정해 적용하면 고정된 기간 동안 객체를 보호할 수 있고 원하는 만큼 기간을 연장할 수 있다.
법적 보존 상태
- 참고로 법적 보존 상태를 설정할 수 있다.
- 법적 보존을 설정하면 S3 버킷 내 모든 객체를 무기한으로 보호한다.
- 보존 기간과는 무관하기 때문에 아주 중요한 객체에 법적 보존을 설정
- 대개 재판에서 사용될 수 있는 중요한 객체에 법적 보존을 설정한다.
액세스 포인트
- 그룹에 따라 액세스할 액세스 포인트를 정의하는 특정 정책을 액세스 포인트마다 연결할 수 있다.
- 최종적으로는 S3 버킷에 액세스한다.
- 각 액세스 포인트마다 고유의 DNS와 정책이 있다. 이를 통해 사용자나 그룹의 액세스를 제한할 수 있다.
- 액세스 포인트마다 하나의 정책만 가지니까 복잡하고 고유한 버킷 정책보다 훨씬 다루기 쉽다.
S3 Object 람다
- S3 객체 Lambda의 사용 목적은 S3 버킷의 객체를 호출한 애플리케이션이 회수하기 전에 수정하기 위함이다.
- 쉽게 말하면 데이터를 가공, 필터링하는 곳에 쓰인다.
반응형
댓글