EBS
- Elastic Block Store Volume
- 인스턴스가 실행되는 동안에는 인스턴스에 연결할 수 없는 네트워크 드라이브
- 인스턴스와 EBS 볼륨 간의 통신을 위해 네트워크 사용(지연 있음)
- EC2인스턴스에서 분리하여 다른 인스턴스에 매우 빠르게 연결할 수 있음(장애 조치할 때 편리)
- 인스턴스가 종료된 후에도 데이터 유지 가능(인스턴스를 다시 생성하고 이전과 동일한 EBS 볼륨을 마운트하면 데이터를 다시 가져올 수 있음)
- CCP 레벨의 EBS 볼륨은 한 번에 하나의 인스턴스에만 마운트 할 수 있음
- 특정 가용성 영역에 고정되어 있음 (us-east 1a에 생성된 EBS 볼륨을 us-east 1b의 인스턴스에 연결할 수 없음)
- 스냅샷을 수행하면 다른 가용성 영역에서 볼륨을 이동할 수 있음
- 미리 용량을 프로비저닝해야함
- 원하는 기가바이트 수와 초당IO, 작업 수인 IOPS를 미리 알려줘야함
- 해당 프로비저닝 용량에 대한 요금이 청구되며, 더 나은 성능이나 더 큰 용량을 원할 경우 늘릴 수 있음

US-EAST-1A
- 해당 EC2 인스턴스에 하나의 EBS 볼륨을 연결할 수 있음
- 다른 EC2 인스턴스를 생성하는 경우, 따로 EBS 볼륨을 만들어줘야함
- 하나의 인스턴스에 두 개의 EBS볼륨이 연결될 수 있음
US-EAST-1B와 같은 다른 AZ에서 다른 EBS 볼륨을 사용하려면
다른 가용성 영역에서 별도로 생성해야함.(연결 안한 볼륨도 존재 가능)
EBS 볼륨 종료시 삭제 속성

기본적으로
Root볼륨에는 체크
새 EBS 볼륨에는 체크되어있지 않음
따라서 EC2인스턴스가 종료될 때 EBS 동작을 제어함
Root EBS 볼륨은 인스턴스가 종료되는 것과 함께 삭제됨(다른 EBS볼륨은 삭제 되지 않음)
AWS 콘솔에서 위의 사진과 같이 종료 시 삭제를 활성화할지 비활성화할지 선택할 수 있음
EBS Snapshots
- EBS 볼륨의 백업
- EBS볼륨과 EC2 인스턴스를 분리할 필요는 없지만 권장
- 이런 EBS 스냅샷을 다양한 사용 가능성 존이나 다른 지역으로 복사할 수 있음

EBS 스냅샷 기능
- EBS Snapshot Archive 아카이브

- 'archive tier' : 스냅샷을 이동시키는 기능 (75퍼 저렴)
- 스냅샷을 'archive tier' 로 옮기면 24시간 이내에서 72시간 이내로 아카이브를 복원할 수 있음
- Recycle Bin 재활용
- EBS 스냅샷을 영구 삭제하는 대신 삭제하면 Recycle Bin에 들어감
- 우연히 삭제된 파일을 복구할 수 있음
- 저장기간은 하루에서 일년 사이로 설정 가능
- Fast Snapshot Restore(FSR) 빠른 스냅샷 복원
- 스냅샷의 전체 초기화 강제(첫 번째 사용에 대기 시간이 없도록)
- 스냅샷이 큰 경우 특히 도움이 됨
- 비용이 많이 듦
AMI
- Amazon 머신 이미지
- EC2 인스턴스의 사용자 지정
- 자신만의 소프트웨어 구성(운영체제) 정의 및 셋업 가능
- 자신만의 AMI를 만들면 부팅 시간과 구성 시간이 더 빨라짐
- AMI는 특정 지역에 맞게 만들어서 그 지역에 걸쳐 복사 가능
- 다양한 AMI로부터 EC2 인스턴스를 보낼 수 있음
- A Public AMI: AWS provided (ex. Amazon Linux 2 AMI)
- Own AMI: 직접 만든 AMI
- An AWS Marketplace AMI : 사고 팔 수 있음
EC2의 AMI 작동 과정
- EC2 인스턴스 시작해 사용자 지정
- 데이터 무결성을 확인하기 위해 인스턴스를 멈춤
- AMI를 구축 (EBS스냅샷도 생성 예정)
- 다른 AMI의 인스턴스를 실행 가능
EC2 인스턴스 STORE
EBS Volume은 성능이 제한되어있고,
더 높은 성능을 원할때는 ec2에 하드웨어 디스크를 연결할 수 있음
성능 높은 하드웨어 디스크를 원할 때 EC2 인스턴스 스토어를 활용
- 더 좋은 I/O 성능
- 인스턴스 스토어가 있는 EC2 인스턴스를 중지하거나 종료하면 스토리지가 손실됨(장기 사용은 EBS)
- 따라서 인스턴스 스토어는 장기적으로 저장할 수 있는 내구성 있는 장소로 사용할 수 없음
- 버퍼, 캐시, 스크래치 데이터, 임시 콘텐츠가 필요할 경우 사용
- EC2 서버에 장애가 발생하는 경우 EC2 인스턴스에 연결된 하드웨어도 장애가 발생하므로 큰 손실 발생 가능
- 따라서 EC2 인스턴스 스토어를 사용하기로 결정했으면 백업, 복제해야함
EBS Volume Type
- gp2/ gp3 (SSD) : 성능의 균형을 맞출 수 이쓴 범용 SSD
- 지연시간이 짧은 비용 효율적인 스토리지
- 시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경 등에 사용할 수 있음
- 1기가바이트 - 16테라 바이트까지 다양
- gp3 :
- 최신세대
- 3000 IOPS와 초당 125 메가바이트의 처리량을 기본으로 제공
- 독립적으로 16000까지 IOPS와 초당 1000메가바이트의 처리량을 늘릴 수 있음
- gp2:
- 크기와 IOPS가 비례적(GB당 3 IOPS)
- 볼륨 크기과 IOPS가 연동되어 있음
- 5334GB크기 일때 최대 IOPS 사용
- io1 / io2 Block Express(SSD) : 미션 크리티컬한 저지연 및 고처리량 워크로드에 사용되는 최고성능의 SSD볼륨
- st1 (HDD): 자주 엑세스하는 처리량 집약적인 워크로드를 위해 설계된 저비용 HDD 볼륨
- 빅데이터, 데이터웨어하우징, 로그 처리
- 초당 최대 처리량 500MB, 최대 500 IOPS
- 125GB ~ 16TB 크기
- sc1(HDD): 엑세스 빈도가 낮은 워크로드를 위해 설계될 예정
- 초당 최대 처리량 250 MB, 최대 250 IOPS
- 125GB ~ 16TB 크기
- 가장 비용이 낮음
EBS볼륨은 크기, 처리량, 초당 입출력 작업(IOPS) 등 으로 정의됨
EC2 인스턴스의 경우 gp2 및 gp3, io1 및 io2만 부팅 볼륨으로 사용할 수 있음
이는 루트 OS가 실행될 위치를 의미
프로비저닝된 IOPS볼륨(PIOPS)
- 용도
- 일관된 IOPS 성능이나 16000이상 IOPS 필요한 경우
- 스토리지 성능과 일관성에 매우 민감한 DB
- io1의 경우
- 최대 PIOPS는 Nitro 인스턴스의 경우 64000, 타 인스턴스는 32000
- 볼륨 크기에 관계없이 PIOPS 늘릴 수 있음
- io2 Block Express의 경우
- IOPS 용량 = 1000: 1 비율로 최대 256,000 IOPS

EBS Multi-attach 기능 지원
- 다중 연결 기능은 같은 EBS 볼륨을 다중 EC2 인스턴스에 같은 사용 가능성 존에 연결하게 함
- 각 인스턴스는 고성능 볼륨을 위한 읽기 및 쓰기 권한을 갖게 됨
- 사용사례:
- 클러스터된 Linux 응용 프로그램의 경우 더 높은 응용 프로그램 가용성을 갖는 것(ex. Teradata 사용 or 동시 작성 작업을 관리해야할 경우)
- 다중 연결 기능은 지정된 사용 가능성 존에서만 사용 가능
- 한번에 최대 16개의 EC2 인스턴스를 같은 볼륨 첨부 가능
- 클러스터 인식을 하는 파일 시스템 사용
EFS
- Elastic File System
- 여러 EC2에서 사용될 수 있는 네트워크 파일 시스템(NFS), EC2들은 다른 AZ에 있어도 됨
- 높은 가용성과 확장성, 그러나 비싸고 사용량에 따른 지불
- 사용 예시: 콘텐츠 관리, 웹 서빙, 데이터 공유, 워드 프레스
- 내부적으로 NFSv4.1 프로토콜 사용
- EFS 접근 관리를 위해 보안 그룹 사용
- 리눅스 기반 AMI에만 호환됨(Windows 불가)
- KMS를 이용한 암호화 가능
- POSIX 파일 시스템 사용, 표준 파일 API 가짐
- 사용에 따라 스케일 자동 확장
성능
- 수천 개의 클라이언트 동시 처리 및 10GB 이상 처리량
- 자동으로 PB 수준의 네트워크 파일 시스템 가능
- 퍼포먼스 모드(EFS 생성 시 설정)
- 일반(기본): 웹 서버, CMS같은 지연 시간에 민감한 서비스
- 최대 I/O: 지연 시간은 높으나 최대 처리량(빅데이터, 미디어처리)
- 처리량 모드
- Bursting: 1TB용량이라면 초당 50 MB + 버스팅으로 최대 100MB
- Provisioned: 스토리지 용량에 상관없이 처리량 증가 가능
- Elastic: 작업에 따라 처리량 자동으로 설정
용량
- 스토리지 계층
- 수명주기 관리 기능, 일정 시간 지나면 타 계층으로 파일을 옮길 수 있음
- 스토리지 티어 간 자동으로 파일을 이동하려면 수명 주기 정책을 구현하면 됨
- 종류
- 표준 계층:자주 엑세스 되는 파일용
- Infrequent Access(EFS-IA) 계층: 파일 검색에는 비용이 들지만 저장에는 적게 듦
- 아카이브 계층: 거의 액세스되지 않는 데이터용 50% 저렴
- 가용성, 내구성
- 스탠다드: 여러 AZ에 걸쳐 존재할 때, 프로덕션 환경일 때 용이
- One Zone: 하나의 AZ에만 존재, 개발환경이고 저렴한걸 원할때, 스토리지의 IA와 호환되며 기본적으로 백업 존재
EBS vs EFS
- EBS
- 한 ec2 인스턴스에만 연결됨(io1/io2 특수 경우 빼고)
- 특정 AZ에 구속됨(이동하려면 스냅샷 찍어야)
- gp2의 경우 디스크 용량과 IO가 비례적으로 증가하나 gp3, io1에서는 독립적으로 증가 가능
- 백업 시 IO를 사용하기 때문에 애플리케이션이 많은 트래픽을 처리중이라면 사용하면 안됨
- EFS
- 여러 AZ에 걸쳐 수백 개의 인스턴스에 연결될 수 있음
- EBS에 비해 가격대 더 높으나 비용 절감을 위해 스토리지 계측 사용 가능