Cloud/Amazon Web Services

AWS Technical Essentials; Module 4

체원 2022. 6. 7. 17:24

모듈 4 : AWS 스토리지

모듈 4 : AWS 스토리지

4-1) 스토리지 유형

데이터를 위한 여러 유형의 스토리지 필요

앱의 운영 체제 ➡ S/W 시스템 파일 저장 (Block 스토리지 추천)
정적 자산 (Object 스토리지 추천)
정형 데이터 ➡ DB 필요

AWS 스토리지 서비스

블록 스토리지
- 고정 크기의 데이터 청크로 분할된 후 저장
- 자주 업데이트 되는 데이터
- 트랜잭션 속도가 높은 데이터
파일 스토리지
- 중앙 집중식 액세스 필요한 경우
- 파일 시스템 통신 프로토콜과 통합 필요
객체 스토리지
- 각 파일을 단일 데이터 단위처럼 취급
- 종종 WORM(wirte once, read many / 수정은 없지만 접근은 많은) 모델에 사용

파일 스토리지

파일 → 폴더, 하위 폴더로 구성된 트리 같은 계층 구성
예) Cat_photos 폴더 생성 → 이미지 폴더 안 배치, 정리 가능
- 이미지는 애플리케이션에서 사용되므로, Cat_photos 폴더는 Application_files라는 다른 폴더 내부에 위치 가능

파일 메타데이터 : 파일 이름, 파일 크기, 파일이 생성된 날짜 등
파일 경로 : 예) computer/Application_files/Cat_p→hotos/cats-03.png
파일 검색해야 하는 경우 → 시스템에서 경로 사용, 파일 계층 구조에서 파일 검색 가능

파일 스토리지 선택

여러 호스트 컴퓨터에서 쉽게 공유, 관리해야 하는 파일에 대한 중앙 집중식 액세스가 필요한 경우에 적합
일반적으로 여러 호스트에 탑재, 파일 잠금 및 기존 파일 시스템 통신 프로토콜과의 통합 필요

파일 스토리지 사용 사례

대규모 콘텐츠 리포지토리
개발 환경
사용자 홈 디렉터리

블록 스토리지

파일 스토리지 : 파일을 단일 단위로 취급
블록 스토리지 : 파일을 고유한 주소를 가진 블록이라는 고정 크기의 데이터 청크로 파일 분할
블록 : 고정 크기의 데이터 청크, 주소 지정 가능 → 블록 효율적으로 검색 가능

데이터 요청시 스토리지 시스템에서 주소를 사용하여 블록을 올바른 순서로 구성, 요청자에게 반환할 전체 파일을 구성

주소 외부에서는 각 블록에 추가 메타데이터가 연결되지 ❌
따라서 파일의 문자를 변경하려는 경우 해당 문자가 포함된 블록, 즉 파일 조각을 변경하기만 하면 된다.

이러한 액세스 용이성 → 블록 스토리지 솔루션이 빠르고, 대역폭을 적게 사용하는 이유

블록 스토리지 선택

대기 시간 짧은 작업에 최적화
데이터베이스, 전사적 자원 관리(ERP) 시스템과 같은 고성능 엔터프라이즈 워크로드를 위한 일반적인 스토리지 선택
대기 시간이 짧은 스토리지가 필요

객체 스토리지

저장될 때 단일 데이터 단위로 처리
- 파일 스토리지 : 계층 구조로 저장
- 객체 스토리지 : 평면 구조로 저장
객체 : 고유 식별자를 가진 파일
- 식별자 → 데이터와 번들(추가 메타데이터 포함)로 제공, 저장❌

한 문자만 변경하는 경우, 블록 스토리지보다 어렵다.
개체 스토리지에서 파일 한 문자를 변경하려면 전체 파일을 업데이트 필요

객체 스토리지 선택

거의 모든 유형의 데이터 저장 가능
저장된 객체 수에는 제한 ❌ → 쉽게 확장 가능
일반적으로 정적 자산을 저장할 때 유용 → 대용량 데이터 집합, 미디어 자산과 같은 비정형 파일, 사진 등등

기존 스토리지 시스템과 다시 연결

온프레미스 스토리지에서 작업한 적이 있다면 이미 블록, 파일 및 개체 스토리지에 익숙할 수 있습니다.

다음 기술과 이전에 보았던 시스템이 어떤 관련이 있는지 생각해 보십시오.

클라우드 블록 스토리지 → 직접 연결 스토리지(DAS), 스토리지 영역 네트워크(SAN)와 유사
파일 스토리지 시스템 → 네트워크 연결 스토리지(NAS) 서버에서 지원되는 경우가 대부분

기존 데이터 센터 : 스토리지 추가는 매우 까다로운 프로세스 → 스토리지 솔루션 구입, 설치, 구성 필요

클라우드 컴퓨팅 : 프로세스 훨씬 유연 → 단 몇 분 만에 스토리지 솔루션 생성, 삭제, 수정 가능

리소스

4-2) Amazon EC2 인스턴스 스토리지 및 Amazon Elastic Block Store

블록 스토리지는

운영 체제의 부팅 볼륨이나
별도의 데이터 볼륨으로 사용 가능

Amazon EC2 인스턴스 스토어

AWS 설명서 참조

EC2 인스턴스 내 존재
직접 연결된 스토리지의 한 형태
기본 물리적 서버에 하나 이상의 스토리지 유닛이 직접 연결
직접 연결 ➡ 물리적 서버에 매우 가까워, 매우 빠르고 신속하게 응답 가능

단점 : 인스턴스 스토어는 EC2 인스턴스에 직접 연결되기 때문에 직접 연결로 인해 해당 수명 주기가 인스턴스 생명 주기와 연결
즉, 인스턴스 다운되면 모든 데이터 사라짐

Amazon EC2 인스턴스 스토어는 인스턴스에 임시 블록 수준 스토리지 제공
- 임시 블록 수준 스토리지 → 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치
데이터 수명 주기가 EC2 인스턴스의 수명 주기와 연동
인스턴스 삭제 ⇢ 인스턴스 스토어도 삭제 따라서, 인스턴스 스토어는 임시 스토리지로 간주됨

Amazon EC2 인스턴스 스토어 사용

데이터를 다른 EC2 인스턴스로 복제하는 애플리케이션을 호스팅하는 경우에 적합
- 다른 EC2 인스턴스로 복제하는 애플리케이션 : Hadoop 클러스터 등등
이러한 클러스터 기반 워크로드의 경우,
- 로컬로 연결된 볼륨의 속도와
- 복제된 데이터의 복원력을 통해 고성능으로 데이터 배포 달성 가능
버퍼, 캐시, 스크래치 데이터, 기타 임시 콘텐츠와 같이 자주 변경되는 정보를 임시로 저장하는 데에도 적합

Amazon Elastic Block Storage(Amazon EBS)

인스턴스 스토어 단점 보안 ➡ 인스턴스 다운되더라도 데이터 남아있음 ➡ 영구 스토리지
EC2 인스턴스와 별개
네트워크 연결 스토리지 ➡ 직접 통신 회선으로 안전
쉽게 생각하면 외장 하드
대부분의 EBS 볼륨은 EC2 인스턴스와 1:1 관계
EBS 다중연결 가능

Amazon EBS : Amazon EC2 인스턴스에 연결할 수 있는 블록 수준 스토리지 디바이스
- Amazon EBS 볼륨 : 이러한 스토리지 디바이스
EBS 볼륨
- 기본적으로 외장 드라이브를 랩톱에 연결하는 방법과 유사하게 EC2 인스턴스에 연결되는 사용자 구성 크기의 드라이브
- 여러 가지 측면에서 외장 드라이브와 유사하게 작동

대부분의 Amazon EBS 볼륨은 한 번에 한 대의 컴퓨터와만 연결 가능
- 대부분의 EBS 볼륨은 EC2 인스턴스와 일대일 관계 → 한 번에 여러 인스턴스에서 공유하거나 연결 ❌
- 최근에 AWS는 볼륨을 한 번에 여러 EC2 인스턴스에 연결할 수 있는 Amazon EBS 다중 연결 기능을 발표
- 이 기능은 일부 인스턴스 유형에서는 사용할 수 없으며, 모든 인스턴스가 동일한 가용 영역에 있어야함
한 EC2 인스턴스에서 EBS 볼륨을 분리하고, 동일한 가용 영역의 다른 EC2 인스턴스에 연결하여 해당 인스턴스의 데이터에 액세스 가능
외장 드라이브는 컴퓨터와 분리
- 즉, 사고가 발생하여 컴퓨터가 다운되더라도 외장 드라이브에 데이터 존재 → EBS 볼륨도 동일한 구조
확장 가능성에 일정한 제한 → 외장 드라이브 크기로 제한
- 예) 2TB 외장 드라이브가 있다면, 2TB의 콘텐츠만 저장 가능
- EBS도 동일 → 볼륨에 저장할 수 있는 콘텐츠의 양 최대 제한 존재

Amazon EBS 볼륨 크기 조정

최대 크기 제한을 초과하지 않는 한 볼륨 크기를 늘립니다.
- EBS 볼륨의 경우 보유할 수 있는 최대 스토리지 용량은 16TB입니다.
- 5TB EBS 볼륨을 프로비저닝하는 경우 16TB가 될 때까지 볼륨 크기를 늘릴 수 있습니다.
여러 볼륨을 단일 Amazon EC2 인스턴스에 연결합니다.
- EC2는 EBS 볼륨과 일대다 관계가 있습니다.
- EC2 인스턴스 생성 중 또는 이후에 이러한 볼륨을 추가하여 호스트에 더 많은 스토리지 용량을 제공할 수 있습니다.

Amazon EBS 사용 사례

Amazon EBS는 데이터를 빠르게 검색, 데이터 장기간 유지해야 하는 경우 유용

볼륨은 다음과 같은 시나리오에서 흔히 사용 된다.

운영 체제
운영 체제를 저장할 부트/루트 볼륨
Amazon Machine Image(AMI)에서 시작된 인스턴스의 루트 디바이스는 일반적으로 Amazon EBS 볼륨
(이를 일반적으로 EBS 지원 AMI라고 합니다.)

데이터베이스
트랜잭션 읽기 및 쓰기에 의존하는 Amazon EC2에서 실행되는 데이터베이스용 스토리지 계층

엔터프라이즈 애플리케이션
Amazon EBS는 비즈니스 크리티컬 애플리케이션을 실행할 수 있는 안정적인 블록 스토리지를 제공

처리량 집약적 애플리케이션
길고 연속적인 읽기 및 쓰기를 수행하는 애플리케이션

Amazon EBS 볼륨 유형

솔리드 스테이트 드라이브(SSD) 백업 볼륨 → 랜덤 입력/출력(I/O)에 강력한 성능을 제공
하드 디스크 드라이브(HDD) 백업 볼륨 → 순차적 I/O에 강력한 성능을 제공

Amazon EBS 이점

고가용성: EBS 볼륨 생성 ⇢ 단일 장애 지점으로 인한 데이터 손실을 방지하기 위해 볼륨이 가용 영역에 자동으로 복제
데이터 지속성: 인스턴스가 없는 경우에도 스토리지가 유지
데이터 암호화: 모든 EBS 볼륨은 암호화를 지원
유연성: 즉시 변경 지원 ⇢ 인스턴스를 중지하지 않고도 볼륨 유형, 볼륨 크기, IOPS(초당 입출력 작업 수) 용량 수정
백업: Amazon EBS는 모든 EBS 볼륨의 백업을 생성할 수 있는 기능 제공

데이터 백업

EBS 볼륨 백업 ➡ 스냅샷 (중복 저장 증분 백업)
데이터를 안전한 상태로 복원 가능

Amazon EBS 스냅샷

데이터 백업 ❌ = 손실 → 방지 위해 AWS에서도 데이터 백업 수행
EBS 스냅샷 : Amazon EC2 인스턴스의 데이터로 구성된 EBS 볼륨 백업

EBS 스냅샷은 증분 백업 → 가장 최근 스냅샷 이후에 변경된 볼륨에 블록만 저장
- 예) 볼륨에 10GB의 데이터가 있고, 마지막 스냅샷 이후 2GB의 데이터만 수정된 경우 → 변경된 2GB만 Amazon Simple Storage Service(Amazon S3)에 기록

EBS 볼륨 스냅샷 생성 → Amazon S3 사용, 백업 여러 가용 영역에 중복 저장
Amazon S3에 백업 저장하는 부분은 AWS에서 처리
- EBS 스냅샷 대한 작업 수행 위해 Amazon S3와 상호 작용할 필요 ❌
- Amazon EC2 콘솔의 일부인 Amazon EBS 콘솔에서 관리
동일한 가용 영역, 다른 가용 영역 관계없이 여러 개의 새 볼륨 생성하는 데 사용 가능
스냅샷에서 새로운 볼륨 생성하는 경우 → 새로 생성된 스냅샷 생성될 시점의 원본 볼륨 사본과 정확히 일치

리소스

4-3) Amazon Simple Storage Service(S3)를 사용하는 객체 스토리지

정적 자산 데이터를 EBS에 저장 하지 않는 이유?

대부분 EBS 볼륨은 한 번에 하나의 EC2 인스턴스에만 연결
- 앱이 확장됨에 따라 모든 인스턴스에서 데이터에 액세스 하는 방법 찾아야함
EBS 볼륨에 크기 제한 존재 ➡ 확장성이 뛰어난 솔루션 필요

대안 → Amazon Simple Storage Service(S3)

Amazon S3

컴퓨팅에 연결되지 않은 독립형 스토리지 솔루션으로 설계 → 웹의 어느 곳에서나 데이터 검색 가능
EC2에 탑재 ❌ 스토리지
URL 통해 데이터에 액세스 가능 (HTTP/HTTPS 연결)
객체는 메타데이터와 결합된 파일로, 객체를 원하는 만큼 저장 가능
개별 개체 크기 제한 5TB
온라인 스토리지 서비스 사용하여 로컬 시스템의 데이터 백업한 경우 → Amazon S3와 유사한 서비스 사용했을 가능성 큼
온라인 스토리지 서비스 ↔️ Amazon S3 가장 큰 차이점 : 스토리지 유형
Amazon S3 기본 스토리지 유형 : 객체 스토리지
- 객체 스토리지의 모든 특성 = Amazon S3의 특성
객체 스토리지 : 고유한 식별자 사용하여 요청 시 객체 조회하는 평면 구조로 데이터 저장
- 플랫 구조 사용 ➡ 요청시 고유 식별자 사용하여 객체 조회
분산 스토리지로 분류 ➡ 데이터를 여러 시설에 걸쳐 저장
매우 높은 가용성, 내구성

Amazon S3 저장 방법

버킷에 객체를 저장
버킷에 폴더 생성 가능

Amazon S3 개념

Amazon S3에서는 버킷이라는 컨테이너에 객체 저장
버킷 먼저 생성 ❌ ➡ 객체를 Amazon S3에 업로드할 수 ❌

버킷을 생성할 때 최소한 두 가지 세부 정보 필요

버킷이 상주할 AWS 리전
버킷 이름

리전 선택 시 → 일반적으로 컴퓨팅과 같은 다른 리소스에 사용한 리전 선택
버킷 리전 선택 시, 버킷 내 배치된 모든 객체가 여러 가용 영역에 걸쳐 여러 디바이스에 중복 저장
중복성 통해 높은 내구성, 가용성 제공 설계
버킷 이름은 모든 AWS 계정에서 고유해야함
AWS 버킷 이름 → 객체 식별자 일부로 사용

S3에서 각 객체는 URL 사용하여 식별

http:// + 버킷 이름 + 식별자 (서비스 이름, 서비스 공급자) + 묵시적 폴더 + 객체 (키 이름)

버킷의 이름 : doc
식별자는
- 서비스 이름 : s3
- 서비스 공급자 : amazonaws 사용

버킷 안에 묵시적 폴더 : 2006-03-01
폴더 안에 객체 : AmazonS3.html (객체 이름을 키 이름이라고 하는 경우가 많습니다.)

버킷 내부에 폴더 배치 가능 → 객체 구성에 도움 위함
BUT 백엔드에서 실제 파일 계층 구조 지원 ❌
- 대신 모든 파일과 폴더가 동일한 수준에 있는 평면 구조
버킷과 폴더 사용 → 사용자가 이해할 수 있는 조직을 만드는 계층 포함

Amazon S3 사용 사례

백업 및 스토리지
Amazon S3는 중복성이 매우 높기 때문에 파일을 백업하는 자연스러운 장소입니다.
마지막 단원에서 언급했듯이 AWS는 EBS 스냅샷을 S3에 저장하여 고가용성을 활용합니다.

미디어 호스팅
객체를 무제한으로 저장할 수 있고 각 객체는 최대 5TB까지 가능하므로 Amazon S3는 비디오, 사진 및 음악 업로드를 호스팅하기에 이상적인 장소입니다.

소프트웨어 제공
Amazon S3를 사용하여 고객이 다운로드할 수 있는 소프트웨어 애플리케이션을 호스팅할 수 있습니다.

데이터 레이크
AmazonS3는 사실상 무제한의 확장성으로 인해 데이터 레이크를 위한 최적의 토대입니다.
스토리지를 기가바이트 규모에서 페타바이트 규모의 콘텐츠로 늘릴 수 있으며, 사용한 만큼만 비용을 지불할 수 있습니다.

정적 웹 사이트
HTML, CSS 및 클라이언트 측 스크립트의 정적 웹 사이트를 호스팅하도록 S3 버킷을 구성할 수 있습니다.

정적 콘텐츠
무제한 크기 조정, 대용량 파일 지원, 그리고 언제든지 웹을 통해 모든 객체에 액세스한다는 사실 때문에 Amazon S3는 정적 콘텐츠를 저장하기에 완벽한 장소입니다.

리소스에 적합한 연결 옵션 선택

S3리소스는 기본적으로 비공개 객체

액세스 거부가 기본, 처음부터 보호

버킷, 폴더, 객체 공개하도록 선택 가능

객체 공객하고 싶다면 작업 필요 ➡ make public
공개 리소스 : 인터넷상의 모든 사람이 볼 수 있음

리소스에 대한 액세스 제어 기능 제공

Amazon S3 리소스로 작업을 수행할 수 있는 사용자를 보다 구체적으로 지정 가능

IAM 정책
S3 버킷 정책

IAM 정책

JSON 형식으로 정의

IAM 정책 : IAM 사용자, 그룹, 역할에 연결되면 정책이 수행할 수 있는 작업 정의
어느 한 AWS 서비스에 연결되지 않으며, 거의 모든 AWS 작업에 대한 액세스 정의에 사용 가능

프라이빗 버킷에 IAM 정책 사용해야하는 2가지 시나리오

권한 요구 사항이 서로 다른 버킷이 많이 있습니다. 다양한 S3 버킷 정책을 정의하는 대신 IAM 정책을 사용할 수 있습니다.
모든 정책이 중앙 집중식 위치에 있어야 합니다. IAM 정책을 사용하면 한 위치에서 모든 정책 정보를 관리할 수 있습니다.

S3 버킷 정책

JSON 형식으로 정의
IAM 정책 : 사용자, 그룹, 역할에 연결 ↔️ S3 버킷 정책 : S3 버킷에만 연결
버킷에서 허용되거나 거부되는 작업 지정
버킷에만 배치 → 폴더 또는 객체에는 사용 ❌
버킷에 배치된 정책은 해당 버킷의 모든 객체에 적용

S3 버킷 정책을 사용해야하는 2가지 시나리오

IAM 역할을 사용하지 않고 S3에 대한 교차 계정 액세스를 수행하는 간단한 방법이 필요합니다.
IAM 정책이 정의된 크기 제한에 도달합니다. S3 버킷 정책의 크기 제한이 더 큽니다.

요약

S3는 버킷이라는 컨테이너를 사용하며 객체 저장
이러한 객체에 대한 액세스를 제어하기 위해 IAM 정책 및 버킷 정책을 사용하는 몇 가지 옵션 존재

Amazon S3 암호화

Amazon S3는 전송 중(Amazon S3에서 송수신할 때), 저장 중 암호화를 강화

서버 측 암호화
- Amazon S3가 데이터를 데이터 센터의 디스크에 저장하기 전에 객체를 암호화
- 객체를 다운로드할 때 해독
클라이언트 측 암호화
- 클라이언트 측에서 데이터를 암호화한 다음 암호화된 데이터를 Amazon S3에 업로드
- 이 경우 사용자가 암호화 프로세스, 암호화 키 및 모든 관련 도구를 관리

전송 중 데이터를 암호화하려면 → 클라이언트 측 암호화 또는 보안 소켓 계층(SSL) 사용

Amazon S3 버전 관리

Amazon S3는 부분적으로 객체 이름 사용하여 객체 식별
Amazon S3 버전 관리 사용하지 ❌ 경우 → 객체를 폴더에 업로드할 때마다 원본 파일을 덮어씀

버전 관리
- 동일한 객체의 여러 버전을 동일한 버킷에 보관
- 다른 이름 사용하지 않고도 객체의 이전 버전 보존 가능
- 우발적 삭제, 우발적 덮어쓰기, 애플리케이션 오류에서 파일 복구 가능

예를 들어
직원 사진을 Amazon S3에 업로드할 때 객체의 이름을 employee.jpg로 지정하고 employees라는 폴더에 저장할 수 있습니다.
Amazon S3 버전 관리를 사용하지 않는 경우, employee.jpg라는 객체를 employees 폴더에 업로드할 때마다 원본 파일을 덮어씁니다.
이 문제는 다음과 같은 여러 이유로 발생할 수 있습니다.

employee.jpg 파일 이름은 직원 사진 객체의 공통 이름입니다.
사용자 또는 버킷에 액세스할 수 있는 다른 사람이 버킷을 덮어쓸 의도가 없었을 수도 있지만, 덮어쓴 경우에는 원본 파일에 액세스할 수 없습니다.

여러 버전의 employee.jpg를 보존하고자 할 수 있습니다.
버전 관리를 사용하지 않고 새 버전의 employee.jpg를 만들려면 객체를 업로드하고 다른 이름을 선택해야 합니다. 이름 지정에 약간의 차이만 있는 객체가 여러 개 있으면 S3 버킷에서 혼동과 혼란을 야기할 수 있습니다.

이러한 문제를 해결하기 위해 S3 버전 관리 사용 가능

버킷에 대한 버전 관리 활성화 → Amazon S3는 객체에 대해 고유한 버전 ID를 자동으로 생성

예를 들어
한 버킷에 employeephoto.gif(버전 111111), employeephoto.gif(버전 121212) 같이 키는 동일하지만, 버전 ID가 다른 두 개의 객체를 가질 수 있습니다.

버전 관리를 사용하는 버킷에서는 실수로 삭제했거나 덮어쓴 객체 복구 가능

객체를 삭제해도 객체가 영구적으로 제거 ❌
- 대신, Amazon S3는 객체를 삭제하려고 시도했음을 보여주는 마커를 객체에 지정
- 객체를 복원하려는 경우 마커를 제거하면 개체를 복원 가능
객체를 덮어쓰면 버킷에 새 객체 버전이 생성. 여전히 이전 버전의 객체에 액세스 가능

버전 관리 상태

버킷은 3가지 상태로 존재

버전 관리되지 않음(기본값): 버킷의 새 객체 및 기존 객체에 버전이 없습니다.
버전 관리 사용: 버킷의 모든 객체에 대해 버전 관리가 활성화됩니다.
버전 관리 일시 중단됨: 새 객체에 대해 버전 관리가 일시 중단됩니다. 버킷의 새 객체는 모두 버전이 없습니다. 그러나 모든 기존 객체는 객체 버전을 유지합니다.

버전 관리 상태는 버킷 내의 모든 객체에 적용
모든 버전을 포함하여 버킷의 모든 객체에 대해 스토리지 비용 발생
Amazon S3 요금 줄이기 위해 → 더 이상 필요하지 않은 이전 버전의 객체 삭제 권고

Amazon S3 스토리지 클래스

Amazon S3에 객체를 업로드하고, 스토리지 클래스를 지정하지 ❌ 경우 → 기본 스토리지 클래스에 업로드
기본 스토리지 클래스를 흔히 표준 스토리지라고 함

Amazon S3 스토리지 클래스 사용 → 데이터 특성이 변경될 때 스토리지 티어를 변경 가능
- 예) 오래된 사진에 자주 액세스하지 않는 경우, 비용을 절감하기 위해 사진의 스토리지 클래스를 변경해야 할 수 있습니다.

6개의 Amazon S3 스토리지 클래스

참고 : Amazon S3 스토리지 클래스 https://aws.amazon.com/ko/s3/storage-classes/

Amazon S3 Standard	클라우드 애플리케이션, 동적 웹 사이트, 콘텐츠 배포, 모바일 및 게임 애플리케이션, 빅 데이터 분석 위한 범용 스토리지로 간주
Amazon S3 Intelligent-Tiering	데이터 액세스 패턴을 알 수 없거나 바뀌는 경우 유용 객체를 두 티어인 Frequent Access 티어, Infrequent Access 티어에 저장 Amazon S3는 데이터의 액세스 패턴을 모니터링 하고 액세스 빈도에 따라 데이터를 가장 비용 효율적인 스토리지 티어로 자동 이동
Amazon S3 Standard-Infrequent Access(S3 Standard-IA)	자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합 S3 Standard의 뛰어난 내구성, 높은 처리량 및 짧은 대기 시간을 저렴한 GB당 스토리지 요금과 GB당 검색 요금으로 제공 저렴한 비용과 높은 성능의 조합을 제공하며 장기 스토리지, 백업 및 재해 복구 파일용 등을 저장하는 경우에 적합
Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)	최소 3개의 가용 영역(AZ)에 데이터를 저장하는 다른 S3 스토리지 클래스와는 달리, 단일 AZ에 데이터를 저장하며 비용이 S3 Standard-IA보다 20% 적게 듬 자주 액세스하지 않는 데이터에 대한 저렴한 옵션을 원하지만 S3 Standard 또는 S3 Standard-IA 스토리지와 같은 가용성 및 복원력이 필요 없는 고객에게 적합 온프레미스 데이터 또는 쉽게 다시 생성할 수 있는 데이터의 보조 백업 복사본을 저장하는 경우 좋은 선택
Amazon S3 Glacier	데이터 보관을 위한 안전하고 내구력 있으며 저렴한 스토리지 클래스 온프레미스 솔루션과 비슷하거나 더 저렴한 비용으로 원하는 양의 데이터를 안정적으로 저장 가능 비용을 낮게 유지하면서 동시에 다양한 요구를 지원하기 위해 몇 분에서 몇 시간까지 소요되는 3가지 검색 옵션 제공
Amazon S3 Glacier Deep Archive	Amazon S3에서 가장 저렴한 비용의 스토리지 클래스이며 1년에 한두 번 정도 액세스할 수 있는 데이터의 장기 보관 및 디지털 보존을 지원 규제 규정 준수 요건을 충족하기 위해 7~10년 이상 데이터 집합을 보관하는 고객(특히 금융 서비스, 의료, 공공 부문과 같이 엄격하게 규제되는 산업의 고객)을 위해 설계

객체 수명 주기 관리를 통한 티어 전환 자동화

객체를 스토리지 티어 사이에서 계속 수동으로 변경하는 경우 → 수명 주기 정책 사용하여 프로세스 자동화

객체 수명 주기 정책 구성 정의 시 2가지 작업 자동화 선택

전환 작업은 객체가 다른 스토리지 클래스로 전환해야 하는 시기를 정의합니다.
만료 작업은 객체가 만료되는 시점을 정의하며 영구적으로 삭제해야 하는 시점을 정의합니다.

수명 주기 관리에 적합한 사용 사례

주기적 로그: 주기적으로 로그를 버킷에 업로드하는 경우 애플리케이션이 로그를 일주일 또는 1개월 동안 필요할 수 있습니다. 그런 다음 삭제할 수 있습니다.
액세스 빈도가 변경되는 데이터: 일부 문서는 제한된 기간 동안 자주 액세스됩니다. 그 이후로는 문서가 가끔 액세스됩니다. 어느 시점이 되면 이러한 문서에 실시간으로 액세스할 필요가 없지만, 조직 또는 규정에서 특정 기간 동안 해당 문서를 보관할 것을 요구할 수도 있습니다. 그 후에는 이를 삭제할 수 있습니다.

리소스

4-4) 적합한 스토리지 서비스 선택

Amazon EC2 인스턴스 스토어

인스턴스 스토어 : 임시 블록 스토리지
EC2 인스턴스를 호스팅하는 동일한 물리적 서버에 존재하며, Amazon EC2에서 분리할 수 없는 미리 구성된 스토리지
EC2 인스턴스를 위한 기본 제공 드라이브라고 생각
인스턴스 스토어는 일반적으로 버퍼, 캐시 및 스크래치 데이터와 같이 끊임없이 변화하는 정보의 임시 저장에 적합
지속적이거나 장기적인 데이터에는 적합 ❌
EBS에 비해 비용 저렴 → 인스턴스 스토어 비용은 EC2 비용에 포함되어 있음
Amazon EC2에서 분리할 수 있고, 볼륨 크기 증가 또는 스냅샷 생성과 같은 관리 유연성을 제공하는 영구 장기 블록 스토리지가 필요한 경우 → Amazon EBS 사용

Amazon EBS

자주 변경되고 인스턴스 중지, 종료 또는 하드웨어 장애 발생 시 유지되어야 하는 데이터를 위한 것
데이터의 지속성과 내구성이 중요한 경우에 사용
EC2 인스턴스에만 연결 가능 → Lambda 함수 등 사용 ❌
Amazon EBS 두 가지 유형 볼륨
1. SSD 지원 볼륨
2. HDD 지원 볼륨❌

SSD 지원 볼륨의 특징

성능은 IOPS(초당 입/출력 작업)에 따라 다릅니다.
데이터베이스 및 부트 볼륨과 같은 트랜잭션 워크로드에 적합

HDD 지원 볼륨의 특징

성능은 MB/s에 따라 다릅니다.
빅 데이터, 데이터 웨어하우스, 로그 처리 및 순차 데이터 I/O 같은 처리량 집약적 워크로드에 적합

Amazon EBS를 다른 서비스와 비교할 때 알아야 할 몇 가지 중요한 특징

블록 스토리지
프로비저닝한 금액에 대한 비용을 지불 (스토리지를 미리 프로비저닝해야 함)
EBS 볼륨은 단일 가용 영역의 여러 서버에 복제됨
대부분의 EBS 볼륨은 한 번에 한 EC2 인스턴스에만 연결 가능

Amazon S3

데이터가 자주 변경되지 않는 경우, Amazon S3가 비용 효율적이고 확장 가능한 스토리지 솔루션
Amazon S3는 정적 웹 콘텐츠 및 미디어, 백업 및 아카이빙, 분석을 위한 데이터를 저장하는 데 적합
사용자 지정 도메인 이름으로 전체 정적 웹 사이트를 호스팅 가능

Amazon S3를 다른 서비스와 비교할 때 알아야 할 몇 가지 중요한 특징

객체 스토리지
사용한 만큼만 비용을 지불(스토리지를 미리 프로비저닝할 필요가 없음).
Amazon S3는 단일 리전의 여러 가용 영역에 객체를 복제
Amazon S3는 컴퓨팅에 연결된 스토리지가 ❌

Amazon Elastic File System(Amazon EFS) 및 Amazon FSx

S3 : 플랫 네임스페이스를 사용하며, 독립 실행형 파일 시스템으로 사용 ❌
- 일반적으로 생각할때 여러 인스턴스가 액세스 할 수 있는 공유 스토리지 시스템

대부분 EBS 볼륨 : 한 번에 하나의 EC2 인스턴스에만 연결

AWS에서 파일 스토리지가 필요한 경우 서비스?

여러 EC2 인스턴스에 탑재할 수 있는 파일 스토리지의 경우,
Amazon Elastic File System(Amazon EFS) 또는 Amazon FSx 사용 가능

서비스	설명	FAQ
Amazon Elastic File System(Amazon EFS)	완전관리형 NFS 파일 시스템	EFS FAQ
Amazon FSx for Windows File Server	SMB 프로토콜을 지원하는 Windows Server에 구축된 완전관리형 파일 서버	FSx for Windows File Server FAQ
Amazon FSx for Lustre	S3와 통합되는 완전관리형 Lustre 파일 시스템	FSx for Lustre FAQ

Amazon EFS 및 Amazon FSx를 다른 서비스와 비교할 때 알아야 할 몇 가지 중요한 특징

파일 스토리지
사용한 만큼만 비용을 지불 (스토리지를 미리 프로비저닝할 필요가 없음).
Amazon EFS와 Amazon FSx는 여러 EC2 인스턴스에 탑재 가능

리소스

모듈 4 지식 확인

#1 다음 중 Amazon Simple Storage Service(Amazon S3)의 일반적인 사용 사례는 무엇입니까?

✅ 미디어 호스팅용 객체 스토리지

Amazon S3는 미디어 파일과 같은 대용량 객체에 사용될 수 있도록 설계된 객체 스토리지 서비스입니다.
객체를 무제한으로 저장할 수 있고 각 개별 객체를 최대 5TB까지 저장할 수 있으므로 Amazon S3는 동영상, 사진 및 음악 업로드를 호스팅하는 데 적합한 서비스입니다.

#2 버킷 이름은 모든 AWS 계정에 대해 고유해야 합니다.

✅ 참

Amazon S3는 리전 서비스입니다.
그러나 네임스페이스는 모든 AWS 계정에서 공유되므로 버킷 이름이 전역적으로 고유해야 합니다.

#3 의료 시설에 근무하는 한 직원은 거의 액세스하지 않는 환자 정보를 7년 간 저장하는 업무를 맡았습니다. 어떤 스토리지 티어를 사용해야 합니까?

✅ S3 Glacier Deep Archive

Amazon Glacier Deep Archive는 Amazon S3에서 가장 저렴한 비용의 스토리지 클래스이며 1년에 한두 번 정도 액세스할 수 있는 데이터의 장기 보관 및 디지털 보존을 지원합니다.
규정 준수 요구 사항을 충족하기 위해 7~10년 또는 그 이상 데이터 집합을 보존하는 고객(특히 금융 서비스, 의료 서비스 및 공공 부문과 같이 규제가 엄격한 산업의 고객)을 위해 설계되었습니다.