S3
사용사례
- 백업과 스토리지
- 재배 복구 용도
- 아카이브
- 하이브리드 클라우드 스토리지
- 애플리케이션 호스팅
- 빅 데이터 분석
- 정적 웹사이트 호스팅 등
1. Bucket
- S3는 파일을 버켓에 저장하는데, 버켓은 상위 레벨 디렉토리로 표시된다
- S3 버켓의 파일은 객체라고 한다
- 버켓의 이름은 모든 리전과 AWS에 존재하는 이름 중에 고유해야 한다 (유일무이)
- 리전 수준에서 정의되기 때문에 리전에 종속되어 있다
- 이름 규칙
- 버켓 이름에는 대문자나 밑줄이 없어야 한다
- 3 ~ 63사이의 길이
- IP주소는 안된다
- 소문자나 숫자로 시작해야 한다
- 문자와 숫자, 하이픈만 사용하면 된다
2. 객체
- S3 자체로는 디렉토의 개념이 없다
- 키의 개념이라
s3://my-bucket/my_file.txt는 my_file.txt가 키이다
s3://my-bucket/my_folder1/another_folder/my_file.txt에서 my_folder1과 another_folder는 prefix의 개념이다
- 원하는건 모두 업로드할 수 있고 최대 크기는 5TB이다
- 5GB이상 업로드할 때는
multi-part upload로 여러 부분으로 나눠 업로드해야한다
3. 보안
- 사용자 기반
- 사용자에게 IAM 정책을 줘서, 특정 사용자가 특정 API를 호출할 수 있는지 허용한다
- 리소스 기반
- 버켓 정책: S3 버켓 정책으로 특정 사용자나 다른 계정 사용자를 허용할 수 있다
- Object Access Control List (ACL): 보다 세밀한 보안이다
- Bucket Access Control List (ACL): 일반적이지 않다
- 암호화
1). 버켓 정책
- JSON 기반 정책
- Resources: 이 정책이 적용되는 객체와 버켓을 적는다
- Effect: 작업을 거부할 것인지 허용할 것인지 적는다
- Principal: 사용자를 적는다.
*이면 모든 사용자를 말한다
- 버켓정책을 통해 업로드 시 객체를 강제 암호화시키거나 또 다른 계정으로의 액세스를 허용할 수 있다
2). Block Public Access (퍼블릭 액세스 차단)
- 버켓을 생성할 때 설정하는 것이다
- 기업 데이터 유출을 방지하기 위한 추가 보안계층이다
- S3 버켓 정책을 설정하여 공개로 만들더라도 이 설정이 활성화되어 있다면 버켓은 결코 공개되지 않는다
- 버켓을 공개하면 안되는 경우, 이 설정을 적용하면 S3 버켓 정책을 잘못설정 하더라도 공개되지 않아 보안을 지킬 수 있다
4. Versioning
- 버켓수준에서 사용되는 설정이다
- 같은 키 (이름)을 업로드하고 덮어쓰려는 경우, 버전1, 버전2, 버전3.. 등으로 생성된다
- 버전관리를 활성화하기 전 버전 관리가 적용되지 않은 모든 파일은 Null 버전을 갖게 된다
- 버전 관리를 중단해도 이전 버전을 삭제하지 않는다
5. 복제 (CRR & SRR)
- 비동기 버켓 복제가 필요한 상황에서 사용한다
- 소스 버켓과 복제 대상 버켓 모두 버전 관리 기능을 활성화해야 한다
- 버켓은 서로 다른
AWS 계정간에도 사용할 수 있다
- IAM 권한을 통해 S3 쓰기, 읽기 권한을 줘야한다
- Cross Region Replica: 교차리전 복제
- Same Region Replica: 같은 리전으로 복제
1). 복제방법
- 새로운 객체만 복제 대상이 된다
- 기존의 객체를 복제하려면 S3 배치 복제 기능을 사용해야 한다
- 기본 객체부터 복제에 실패한 객체까지 복제할 수 있는 기능이다
- 작업을 삭제하려면 소스 버켓에서 대상 버켓으로 삭제 마커를 복제하면 된다
- 체이닝 복제 불가: 1 -> 2 -> 3로 버켓이 복제되어 있다고 할 때 1번 버켓의 객체가 3번 버켓으로 복제되지 않는다
6. 스토리지 클래스 종류
- Standard: 범용
- 99.99% 가용성을 가지고 있고, 자주 액세스하는 데이터에 사용된다
- 지연 시간이 짧고, 처리량이 높으며 AWS에서 두 개의 기능 장애를 동시 버틸 수 있다
- 빅 데이터 분석, 모바일, 게임 애플리케이션 등에 사용된다
- Standard - Infrequent Access (IA)
- 99.99% 가용성을 가지고 있다
- 자주 액세스하지 않지만 필요한 경우 빠르게 액세스가 필요한 데이터에 사용된다
- 비용이 적지만 검색 비용이 발생한다
- 재해 복구와 백업에 사용된다
- One Zone_Infrequent Access
- 99.5% 가용성을 가지고 있다
- 단일 AZ에서는 높은 내구성을 가지만 AZ가 파괴된 경우 데이터를 잃게 된다
- 온프레미스 데이터 2차 백업에 사용된다
- Intellight Tiering
- 사용 패턴에 따라 액세스 티어간 이동할 수 있도록 한다
- 소액의 월별 모니터링 비용과 티어링 비용이 발생하지만 검색 비용이 없다
- Frequent Access Tier: 기본 티어
- Infrequent Access Tier: 30일 동안 액세스 하지 않는 객체 전용 티어이다
- Archive Instant Access Tier: 90일 동안 액세스하지 않는 티어이다
- Archive Access Tier (옵션): 90일에서 700일 700일 이상 액세스하지 않은 객체에 구성할 수 있다
- Deep Archive Access Tier (옵션): 180일에서 700일 이상 액세스하지 않은 객체에 구성할 수 있다
1). Glacier Storage Class
- 아카이빙과 백업을 위한 저비용 객체 스토리지이다
- 스토리지 비용과 검색 비용이 들어간다
- Glacier Instant Retrieval
- 밀리초 단위로 검색이 가능하다
- 분기에 한 번 액세스하는 데이터에 적합하다
- 최소 보관 기간이 90일이기 때문에 백업이지만 밀리초 이내에 액세스해야 하는 경우에 좋다
- Glacier Flexible Retrieval
- 3가지 옵션이 있다
- Expedited: 데이터를 1~5분 이내로 받을 수 있다
- Standard: 데이터를 3 ~ 5 시간 이내로 받을 수 있다
- Bulk: 무료지만 데이터를 5 ~ 12시간이내로 받을 수 있다
- 최소 보관 기간이 90일이다
- Glacier Deep Archive
- Standard(12시간), Bulk(48시간)이 있다
- 데이터를 검색하는데 오래 걸리지만 가장 싸다
- 최소 보관 기간도 180일이다
7. 요청자 지불 (Requester Pays)
- 일반적으로 버켓 소유자가 스토리지 및 데이터 전송 비용을 지불한다
- 요청자가 버켓으로부터 파일을 다운로드하는데 네트워킹 비용역시 소유자에게 청구된다
- 요청자 지불 버켓을 활성화하면 대형파일이 있고 일부 고객이 이를 다운로드하려고 하면 요청자가 돈을 낸다
8. 이벤트 알림
- 객체 생성, 삭제, 복구, 복제 등 이벤트가 발생하면 AWS 서비스에 발송할 수 있다
- 원하는 만큼 S3 이벤트를 만들 수 있고, 필터링을 걸어 원하는 객체가 들어왔을 때만 적용할 수도 있다
- IAM 권한이 있어야 이벤트 알림이 작동한다
- 이벤트를 EventBridge를 통하게 할 수도 있고, S3에서 처리할 수도 있다
- EventBridge에서 규칙을 설정하고 AWS 서비스에 전송할 수 있다
- 다양한 서비스에 전송할 수 있고, 향상된 필터링을 걸 수 있다
9. 성능
- S3는 매우 높은 요청수로 자동으로 스케일링되며 100~200ms의 매우 짧은 지연시간을 갖는다
- 버켓의 접두사 숫자에는 한계가 없다
- 접두사 하나당 3,500개의 put과 5,550번의 가져오기를 할 수 있다
- Prefix:
bucket/folder1/sub1/file => /folder1/sub1/을 prefix라 한다
- Multi-Part upload
- 100MB가 넘는 파일은 멀티파트 업로드를 사용하는 것이 좋다
- 5GB가 넘는 파일에는 반드시 사용해야 한다
- 업로드를 병렬화하므로 전송 속도를 높여 대역폭을 최대화하는데 도움이 된다
- S3 Transfer Accesleration
- 파일을 AWS edge location으로 전송하여 전송 속도를 높이는 것이다
- 해당 데이터가 대상 지역의 s3 버켓으로 전달된다
- 200개가 넘는 엣지 위치가 있고 점점 늘어나고 있다
- 전송가속화는 Multi-art upload와 호환된다
1). S3 Byte - 범위 가져오기(Range Fetches)
- 파일을 특정 바이트 범위를 가져와 Get을 병렬화하는 것이다
- 실패한 경우에도 더 작은 바이트 범위를 다시 시도할 수 있다
- 헤더만 가져오거나, 병렬적으로 처리하기에 좋다
10. Batch Operations
- 단일 요청으로 S3 객체에서 대량 작업을 수행하는 서비스이다
- 한번에 많은 메타데이터와 속성을 수정할 수 있고 버켓간 복사할 수 있다
- 암호화되지 않은 모든 객체를 암호화할 수 있다
- ACL이나 태그를 수정하고, S3 Glacier에서 한번에 많은 객체를 복원할 수 있다
- Lambda 함수를 호출해 Batch Operations의 모든 객체에서 수용자 지정 작업을 수행할 수 있다
- 재시도, 진행 상황 추적, 보고서 작성 등을 할 수 있다
작동원리
- S3 Inventroy 기능을 사용해 객체 목록을 가져온다
- S3 Select를 사용해 객체를 필터링 한다
- 배치 작업에 포함하려는 필터링된 객체 목록을 얻은 후 작업을 수행한다
11. Storage Lens
- 이상 징후를 발견하고 비용 효율성을 파악할 수 있다
- 30일 사용량 및 메트릭이 제공된다
- 대시보드를 만들거나 기본 대시보드를 사용해 메트릭과 리포트를 csv 등으로 내보낼 수 있다
12. S3 암호화
- 4가지 방법을 이용해 S3 버켓에 있는 객체들을 암호화할 수 있다
- 서버 측 암호화 (SSE): S3에서 관리하는 키를 이용한 서버 측 암호화이다
- 버켓과 객체에 대해 기본값으로 활성화되어 있다
- SSE KMS: KMS키를 이용해서 암호화 키를 관리한다
- SSE-C: 우리가 가진 키를 제공한다
- 클라이언트 측 암호화: 클라이언트 측의 모든 걸 암호화한 다음에 S3에 업로드한다
1). SSE-S3
- AWS가 처리하고 관리하고 소유한 키를 이용해서 암호화를 한다
- 객체는 AWS에 의해 서버 측에서 암호화가 될 거고, 암호화의 보안 유형은 AES-256이다
- 헤더에
x-amz-server-side-encryption: AES 256을 적고 요청해야한다
- 새로운 버켓과 새로운 객체에 대해서 기본값으로 설정되어 있다
- 처리량은 너무 많은 쓰로틀링이 생길 수 있다
2). SSE-KMS
- KMS서비스 즉 키 관리 서비스를 이용해서 직접 자신의 키를 관리한다
- KMS를 사용할 경우 사용자가 키를 통제할 수 있고, 직접 키를 생성할 수 있다
- CloudTrail을 통해 키를 검사할 수 있다
- 누군가 KMS에서 키를 사용할 때마다 로깅이 된다
x-amz-server-side-encryption: aws:kms라는 헤더가 있어야 한다
3). SSE-C
- 키가 AWS외부에서 관리되지만 여전히 서버 측 암호화이다
- 키를 서버로 전송하기 때문이다. 하지만 AWS에서는 키를 저장하지는 않는다
- 반드시 HTTPS를 사용해야 하고 헤더의 일부로 키를 전달해야 한다
4). Client-Side 암호화
- 라이브러리를 사용하면 쉽게 구현할 수 있다
- 간단하게 직접 데이터를 암호화한 다음에 S3에 전송하는 개념이다
5). 암호화를 강제하는 방법
- 버켓정책을 통해
aws:SecureTransport: false를 하게 되면 HTTP를 사용하는 유저들을 블록이 된다
