💝 Amazon S3
✅ S3
✅ 버킷 Buckets
✅ 객체 Object
✅ S3 보안
✅ S3 버킷 정책
✅ S3 버전 관리
✅ S3 복제 기능
✅ 내구성 & 가용성
✅ S3 스토리지 클래스 종류
- S3 Standard - S3 Glacier - S3 Intelligent Tiering
✅ 데이터 저장 방식
- 객체 스토리지 - 블록 스토리지 - 파일 스토리지
🚨 S3 개요
✤ Amazon Simple Storage Service
✤ AWS 의 주요 구성 요소
✤ 무한하게 확장할 수 있는 객체(Object) 스토리지 서비스 "infinitely scaling" storage
✤ 많은 웹사이트들이 S3 를 중추로 사용
✤ 많은 AWS 서비스들이 S3 를 통합하기 위해 사용
✤ 최소 3개의 가용영역에 데이터를 자동 분산 저장하기에 성능, 확장성, 가용성, 내구성이 높음
✤ 사용 사례
• 백업(backup)과 저장공간(storage)으로 사용
• 재배 복구의 용도로 사용
• 아카이브 용으로 사용
• 하이브리드 클라우드 스토리지 에 사용
• 애플리케이션 호스팅에 사용
• 미디어 호스팅(동영상, 파일, 이미지 등)
• 데이터 저장소(Data Lakes) 를 보유하여 다량의 데이터를 저장하기 위해 사용
• 빅 데이터 분석을 수행하기 위해 사용
• 정적 웹사이트 호스팅에 사용
🚨 버킷 Buckets
✤ S3 파일을 저장하는 공간 (오브젝트 저장 공간)
✤ S3 파일을 객체(Objects) 라고 하고, 객체를 버킷에 저장한다
✤ 버킷은 계정 안에 생성된다
✤ 버킷의 이름은 고유해야 함. 이름은 계정에 있는 모든 리전과 AWS 에 존재하는 모든 계정에서 고유해야함 (다른 AWS 사용자와 중복되지 않아야 함)
✤ 버킷은 AWS 리전에서 정의되어야 한다(리전 단위로 생성). 리전에서 생성
✤ 명명규칙 : 대문자X, 밑줄X, 길이 3~63자, IP 여서는 안됨, 소문자 및 숫자로 시작, 문자, 숫자, 하이픈(-) 만 사용
🚨 Object 객체
✤ 오브젝트(파일)
✤ 객체나 파일은 Key 를 가진다
✤ S3 의 키는 파일의 전체 경로
✤ 키 : 접두사(prefix) + 객체이름(object name) 으로 구성. 접두사와 객체이름으로 만들어짐
✤ 버킷 내에는 “디렉토리” 라는 개념이 없다 (UI 는 당신이 다르게 생각하도록 속일 것 이지만!)
✤ 길이가 굉장히 길다. 슬래시 포함.
✤ 값은 본문의 내용이다
✤ 파일 등 원하는 것은 뭐든지 S3 에 업로드 가능
✤ 최대 객체 크기는 5TB
✤ 5TB 보다 크면 멀티파트 업로드를 사용해서 여러부분으로 나누어 업로드 (5TB 파일을 가지고 있다면 최소 1000개 부분으로 나눠서 업로그 해야함)
✤ 메타데이터 (객체의 키-값 쌍 리스트)
✤ 태그 (유니코드 키-값 쌍은 최대 10까지 가능) - 보안과 수명 주기에 유용
✤ 버전 ID (객체는 버전 ID 를 갖기도 한다)
🚨 S3 보안
✤ 사용자 기반
✤ 리소스 기반
✤ IAM 원칙이 어떤 상황에서 S3 객체에 액세스 할 수 있는지?
✤ 암호화
사용자 기반
• IAM 정책이 사용자에게 주어짐 - 어떤 API 호출이 특정 IAM 사용자를 위해 허용해야 하는지를 승인
리소스 기반
• 버킷 정책 : S3 콘솔에서 직접 할당 가능한 전체 버킷 규칙 - 교차 계정 허용 (특정 사용자나 다른 계정 사용자 허용)
• 객체 액세스 제어 목록(ACL) : 세밀한 보안. 비활성화 가능
• 버킷 액세스 제어 목록(ACL) : 더 일반적. 비활성화 가능
IAM 원칙이 어떤 상황에서 S3 객체에 액세스 할 수 있는지?
• IAM 권한이 이를 허용하거나 리소스 정책이 이를 허용하는 경우
• 명백한 거부는 없다
• IAM 정책 내의 명시적인 부인(DENY) 은 S3 버킷 정책보다 우선적으로 고려된다
암호화
• S3 보안관리를 할 수 있는 방법이다. 암호화 키 사용하여 객체를 암호화 하는 것
🚨 S3 버킷 정책
✤ JSON 기반의 정책
• Resources
• Effect
• Actions
• Principal
✤ S3 버킷 액세스 제어 정책 사용
• 조건에 따라 버킷에 액세스를 부여하고 제한하는 기능으로 사용
• 필요한 정책을 사용해서 버킷에 대한 공개 액세스 권한 허용 가능
• 업로드 시 객체를 강제로 암호화
• 다른 AWS 계정에 버킷 액세스 권한을 부여 가능 (교차 계정(크로스 계정) 액세스 권한)
• 특정 AWS 리소스에서만 S3 버킷에 액세스 허용 가능
공개 액세스 차단을 위한 버킷 설정
• 버킷과 객체에 대한 공개 액세스를 차단하거나 허용할 수 있다
• 회사 데이터 유출을 방지하기 위해 사용
• 데이터 보호를 위해 기본적으로 공개 액세스를 차단을 켜두어야 함
• 계정 수준에서 설정 가능
액세스 제어 목록 (ACL)
• AWS 계정에 버킷이나 객체에 읽기/쓰기 권한을 부여하는 기능
• 버킷 레벨에서 ACL 을 적용하거나 객체 레벨에서 ACL 을 적용 가능
🚨 S3 정적 웹사이트 호스팅 (Static Website Hosting)
✤ S3 에서 정적 웹사이트를 호스팅 가능하고 인터넷에서 액세스 가능함
✤ 정적 웹사이트 : 언제 접속해도 항상 같은 내용을 보여주는 변하지 않는 사이트 (예, 회사 소개 홈페이지)
✤ 동적 웹사이트 : 접속할 때마다 다른 내용이 변하는 사이트 (커뮤니티 홈페이지, SNS 홈페이지, 쇼핑몰 등)
✤ S3 에서 웹사이트 호스팅을 하면 EC2 등의 별도의 웹서버 운영을 하지 않아도 됨
✤ 웹사이트 주소는 리전에 따라 다음과 같은 형식을 갖는다 : 버킷이름.s3-website-리전.amazonaws.com 형식
✤ 사이트 접속 시 403 에러가 나오면 버킷의 퍼블릭 액세스 허용이 되어있는지 확인필요!
🚨 S3 버전 관리 (Versioning)
✤ S3 에서는 파일을 버전 관리 할 수 있다
✤ 버킷 수준에서 활성화 해야 하는 설정이다
✤ 버킷이 주어졌고, 버전 관리로 활성화된 상태
✤ 사용자가 파일을 업로드할 때마다 선택키에서 해당 파일의 버전이 생성됨. 동일한 키(파일이름)를 업로드하고 해당 파일을 덮어쓰는 경우 버전2, 버전3 등을 생성한다
✤ 버킷의 버전을 관리하는게 좋다
✤ 의도하지 않게 삭제되는 것을 보호해줌 - MFA Delete 옵션을 추가 가능 (버전관리 + MFA Delete 를 조합하면 삭제 방지가 더 강력함)
✤ 이전 버전 복구 가능. 이전 버전으로 쉽게 롤백 가능
✤ 유의사항 : 버전 관리를 활성화하기 전에 버전 관리가 적용되지 않은 모든 파일은 널(null) 버전을 갖게 된다. 버전 관리를 중단해도 이전 버전을 삭제하지 않는다
✤ 버전관리는 안전한 작업
🚨 S3 복제 기능
✤ S3 버킷 간에 객체를 자동으로 복제하는 기능
✤ 2가지 복제 유형 : CRR & SRR
• 교차 리전 복제 : CRR (Cross Region Replication)
- 서로 다른 두 AWS 리전의 S3 버킷으로 객체를 복사
- 사용사례 : 지리적으로 가까운 액세스가 필요한 경우, 재해 복구(DR), 컴플라이언스, 즉 규정 준수나 내부 체제 관리, 데이터가 다른 리전에 있어 발생할 수 있는 지연 시간을 줄일 경우 사용, 계정 간 복제에도 사용
• 동일 리전 복제 : SRR (Same Region Replication)
- 같은 AWS 리전의 S3 버킷으로 객체를 복사
- 사용사례 : 동일한 데이터를 사용하는 프로덕션과 테스트계정 간의 복제, 법적 준수사항으로 같은 리전안에 데이터 복사본을 만들어야 하는 경우, 다수의 S3 버킷간의 로그를 통합, 개발 환경이 별도로 있어 운영 환경과 개발 환경간의 실시간 복제를 필요로 할 때 사용
✤ 소스 버킷과 복제 대상 버킷 둘 다 모든 버전 관리 기능이 활성화되어야 한다
✤ 버킷은 서로 다른 AWS 계정 간에도 사용 가능
✤ 복제는 비동기식으로 이루어짐
✤ 복제 과정은 백그라운드에서 이루어짐
✤ 복제 기능이 정상적으로 실행되려면, S3 에 올바른 IAM 권한, 즉 읽기쓰기 권한을 S3 에 부여해야 한다
✤ 복제를 활성화한 후에는 새로운 객체만 복제 대상이 된다
✤ 기존 객체를 복제하려면 S3 배치 복제 기능을 사용해야 한다 - 기존 객체부터 복제에 실패한 객체까지 복제할 수 있는 기능
✤ 작업을 삭제하려면 소스 버킷에서 대상 버킷으로 삭제 마커를 복제하면 가능 (설정에서 선택 가능)
✤ 버전 ID 를 삭제하는 경우 버전 ID 는 복제되지 않는다 (이는 영구적인 삭제로 누군가 악의를 품고 한 버킷에서 다른 버킷으로 ID 삭제 마커를 복제하면 안되기 때문)
✤ 체이닝 복제는 불가하다. 1번 버킷이 2번 버킷에 복제되어 있고 2번 버킷이 3번 버킷에 복제돼 있어도 1번 버킷의 객체가 3번 버킷으로 복제되지 않는다
🚨 S3 내구성 & 가용성
✤ 내구성 (Durability)
• S3 로 인해 객체가 손실되는 횟수
• S3 는 띄어난 내구성을 제공한다
• 손실이 적은 경우 내구성이 높음
• S3 는 평균적으로 10,000년에 한번 객체 손실이 예상된다
• S3 에서 모든 스토리지 클래스의 내구성은 동일하다
✤ 가용성 (Availability)
• 서비스가 얼마나 용이하게 제공되는지를 나타냄
• 스토리지 클래스에 따라 다름
• 1년에 약 53분 동안에는 서비스를 사용할 수 없다
• 서비스를 사용할 때 몇가지 에러가 발생한다
🚨 S3 스토리지 클래스 종류
✤ S3 에서 객체를 생성할 때 클래스를 선택할 수도 있고 스토리지 클래스를 수동으로 수정할 수도 있다. 혹은 S3 수명주기(LifeCycle) 구성을 사용해 스토리지 클래스 간에 객체를 자동으로 이동 가능
✤ 객체가 저장되어 삭제될 때까지 수명주기를 비용효율적으로 저장 되도록 관리하는 기능
✤ 버전 관리가 활성화되어 있을 경우 객체의 버전별로 수명 주기 정책을 적용할 수 있음
S3 Standard (범용)
• 짧은 지연 시간과 많은 처리량을 제공
• 일반적인 용도의 다양한 사용 사례에 적합
S3 Standard - Infrequent Access (S3 Standard-IA)
• 빈번하지 않은 액세스용
• 자주 액세스하진 않지만 필요한 경우 빠르게 액세스 해야하는 데이터에 사용
• S3 Standard 보다 비용이 적게 발생. 그러나 검색 비용 발생됨
• 99.9% 가용성 (S3 Standard 보다 떨어짐)
• 최소 과금 기간 30일 (30일이 끝나기 전에 객체를 삭제하면 30일 요금이 부과)
• 사용사례 : 재해 복구와 백업
S3 One Zone - Infrequent Access (S3 Standard Zone-IA)
• 빈번하지 않은 액세스용
• 단일 AZ 내에서는 높은 내구성을 갖지만 AZ 가 파괴된 경우 데이터를 잃게 된다
• 최소 3개의 가용영역(AZ)에 데이터를 저장하는 다른 S3 스토리지와는 달리 단일 AZ 에 데이터를 저장함
• 가용성은 더 낮은 수준이 99.5%. S3 Standard-IA 보다 저렴
• 최소 과금 기간 30일 (30일이 끝나기 전에 객체를 삭제하면 30일 요금이 부과)
• 사용사례 : 온프로미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장하는데 사용
S3 Glacier Storage Classes
• 콜드 스토리지. 아카이빙과 백업을 위한 저비용 객체 스토리지
• 비용은 스토리지 비용 + 검색 비용
S3 Glacier Instant Retrieval - 즉시 처리
• 아카이브용
• 저렴한 비용으로 장기 보과나는 백업 용도
• 밀리초 단위로 검색 가능. 분기에 한 번 액세스하는 데이터에 적합
• 최소 보관 기관은 90일. 백업이지만 밀리초 이내에 액세스해야 하는 경우 적합
S3 Glacier Flexible Retrieval - 기다려야 함
• 아카이브용
• 저렴한 비용으로 장기 보관하는 백업 용도
• 일 년에 한번 액세스하는 오래된 아카이브 데이터 용도
• 3가지 옵션
- Expedited : 데이터를 돌려받는 데 1~5분 소요
- Standart : 데이터를 돌려받는 데 3~5시간 소요
- Bulk : 데이터를 돌려받는 데 5~12시간 소요
• 무료
• 최소 과금 기간 90일
S3 Glacier Deep Archive
• 아카이브용
• 가장 저렴한 비용의 스토리지 클래스
• 장기 보관을 위한 스토리지 - 일 년에 한 번 미만으로 액세스하는 오래된 아카이브 데이터 용도
• 최소 보관 기간은 180일
• 두가지 검색 티어 :
- Standard : 데이터 검색 시 12 시간 소요
- Bulk : 데이터 검색 시 48시간 소요 - 오래 걸리지만 비용 가장 저렴
S3 Intelligent Tiering
• 액세스 패턴을 알 수 없거나 예측할 수 없는 데이터용
• 사용자 패턴에 따라 액세스된 티어 간에 객체 이동 가능
• 소액의 월별 모니터링 비용가 티어링 비용 발생. 검색 비용은 없다
• 알아서 객체를 이동시켜 주기 떄문에 편하게 스토리지를 관리할 수 있다
• 액세스 패턴을 모니터링하고, 액세스하지 않은 객체를 저렴한 액세스 계층으로 자동으로 이동
• 액세스 패턴을 알 수 없거나 액세스 패턴이 변화하는 데이터에 대한 스토리지 비용을 최적화하려는 경우에 사용
• 액세스 계층 이동
- Frequent Access tier : 자동. 기본 티어.
- Infrequent Access tier : 자동. 30일 동안 액세스하지 않는 객체 전용 티어. 30일 동안 액세스하지 않는 객체를 이 계층으로 이동
- Archive Instant Access tier : 자동. 90일 동안 액세스하지 않는 객체를 이 계층으로 이동
- Archive Access tier : 선택사항. 90일에서 700일 이상까지 구성가능
- Deep Archive Access tier : 선택사항. 180일에서 700일 이상 액세스하지 않는 객체에 구성 가능
🚨 데이터 저장 방식
✤ Amazon Simple Storage Service
✤ AWS 의 주요 구성 요소
✤ 무한하게 확장할 수 있는 스토리지 "infinitely scaling" storage
오브젝트 스토리지
• 오브젝트라고 불리는 개별 유닛에 데이터를 저장하는 스토리지 포맷
• 각 유닛에는 고유의 식별자 혹은 키가 있어서 분산된 시스템 내 어디에 저장되어 있든지 상관없이 데이터를 찾을 수 있음
• 각각의 오브젝트에는 키, 데이터 및 옵션 메타데이터가 포함
• Amazon S3
블록 스토리지
• 데이터를 고정된 사이즈의 블록으로 나누어 각각 고유한 식별자와 함께 저장하는 방식
• 각 데이터 블록은 고유 식별자를 부여 받아 스토리지 시스템이 데이터 조각을 원하는 곳에 배치 가능
• 예, 일부 데이터는 리눅스 환경에 저장하고 일부는 Windows 장치에 저장
• Amazon EBS
파일 스토리지
• 데이터는 계층적 파일 디렉토리 내의 폴더에서 파일로 저장
• 해당 데이터에 액세스해야 하는 경우, 컴퓨터는 그 데이터를 찾기 위해 경로를 알아야 함
• 파일에 저장된 데이터는 제한된 양의 메타데이터(해당 파일 자체가 보관된 정확한 위치를 알려주는 데이터)를 사용해 구성 및 검색
• Amazon EFS, Amazon FSx
'🌦 Cloud' 카테고리의 다른 글
[AWS/SAA-03] Route 53 (0) | 2023.05.05 |
---|---|
[AWS/SAA-03] ElastiCache (0) | 2023.05.02 |
[AWS/SAA-03] Aurora (0) | 2023.04.28 |
[AWS/SAA-03] RDS (관계형 데이터베이스 서비스) (0) | 2023.04.25 |
[AWS/SAA-03] 오토 스케일링 그룹 (Auto Scaling Group) (0) | 2023.04.24 |