EBS

• 가장 중요
• Elastic Block Store
• 인스턴스가 실행되는 동안 연결할 수 있는 네트워크 드라이브
• 인스턴스가 종료된 후에도 데이터를 지속할 수 있게해줌
• CCP level에서 한번에 한 인스턴스에만 마운트 될 수있음.
  - 특정 AZ에 바운딩됨
• 네트워크 드라이브 이기 때문에 인스턴스에서 빠르게 분리되어 다른 인스턴스에 연결 될 수 있다.
• 특정 AZ에 바운딩 되어있기 대문에다른 AZ에는 붙을 수 없음.
  - 스냅샷 찍으면 가능
• 볼륨이라서 용량을 미리 프로비전해야함.
• 인스턴스하나에 EBS 두개를 연결할 수 있음.
• Delete on Termination
  - ebs 만들때 선택할 수 있는 옵션
  • 인스턴스가 종료될 때 ebs 볼륨이 삭제됨
  • root EBS는 디폴트로 체크되어있음.
  • 다른 것들은 기본값으로 체크가 되어있지 않음.

EBS snapshot

• 꼭 할 필요는 없지만 권장됨.
• 다른 AZ나 region으로 복사할 수 있음.
• 기능
  - Archive
  - 아카이브 티어로 스냅샷 이동 -> 75% 더 저렴
  - 24~72시간이내로 아카이브를 복원할 수 이씅ㅁ
  • Recycle bin for ebs snapshot
    • 영구삭제 대신 휴지통으로 들어감
      • 1일~1년사이로 설정 가능
    • Fast Snapshot Restore (FSR)
      • 전체 초기화를 강제함
      • 첫번째 사용에 대기시간이 없도록
      • 스냅샷이 아주 큰 경우 도움됨.
      • 비용이 많이듬

AMI

• Amazon Machine Image
• EC2 커스터마이징
• 부팅시간, 구성시간이 빨라짐
  - AMI를 통해 미리 패키지화 하기 때문에
• 기본적으로 AWS가 제공하는 AMI를 사용함.

Instance Store

• 하드웨어 디스크의 퍼포먼스를 원하면 EC2 instance store을 사용함
• 물리적 서버에 연결된 하드 드라이브
• I/O 성능이 더 좋음
• EC2 인스턴스에는 저장소가 있는데 이는 멈추거나 종료하면 저장소가 사라짐
• 장기저장소에서는 EBS가 더 좋음
• IOPS 성능이 매우 좋음

EBS Volume Type

gp2/gp3(ssd)

• 비용과 성능의 균형

io1/io2

• 지연시간 낮고 처리량 높은 작업에 사용

st1(hdd)

• 저가 HDD 볼륨.
• 처리량 집약적인 작업에서 자주 접근하도록 설계

sc1(hdd)

• 가장 비용이 적은 hdd 볼륨.
• 액세스 빈도가 적은 작업

EBS볼륨은 크기, 처리량, IOPS 로 구분됨

• EC2는 gp2,gp3,io1,io2만 부팅볼륨으로 사용될 수 있음.

GP2

• 대기시간이 적은 비용 효율적 저장소
• 시스템 부팅, 가상 데스크톱, 개발, 테스트환경
• 1Gib ~ 16Tib
• gp3
  - 새로운 세대
  • 3000IOPS
  • 125 MiB/s
  • 16000 IPOS까지 가능, 1000 MiB/s 까지 독립적으로 가능
• gp2
  - old version
  • 서로 연결되어있음

Provisioned IOPS

• 지속적인 IOPS 성능이 필요한 앱에서 사용
• 또는 16000IOPS 이상의 성능이 필요할 때 사용
• database 워크로드에 아주 좋음
• io1/io2 (4 Gib - 16Tib):
  - 64000IPOS까지 가능함 (Nitro Ec2에서) 아니면 32000
  • gp3와 같이 스토리지 사이즈로부터 독립적임
  • gp3보다 내구성이 더 높고 같은가격에 IOPS per Gib가 높음
• io2 Block Express (4 Gib - 64 Tib):
  - 밀리초 이하의 대기시간
  • 매우 높은 IOPS

Hard Disk Drives (HDD)

• 실행 볼륨으로는 불가능
• 125 GIB ~ 16TiB
• 처리량을 최적화한 HDD (st1)
  - 빅데이터, 데이터창고, 로그
  • 초당 최대 처리량이 500 MiB/s ~ IOPS 500
• Codl Hdd (sc1):
  - 주기적이지 않은 데이터 (아카이빙된 데이터)
  • 최소비용을 필요로할 때 사용

시험에서는 SSD vs IOPS라고 생각하면 됨

• 데이터베이스와 st1, sc1과 비교함
• 32000IOPS를 넘기고 싶다면 EC2 Nitro + io1 or io2가 필요함

EBS Multi-Attach

• 다중 연결기능
• 같은 EBS 볼륨을 여러개의 EC2 인스턴스에 연결 (같은 AZ여야함)
• io1, io2 볼륨에서만 가능함.
• 각 인스턴스는 고성능 볼륨을 위한 읽기, 쓰기 권한을 가짐 -> 동시에 접근 가능하다는 뜻
• 최대 16개의 인스턴스를 같은 볼륨에 붙힐 수 있음.

EBS 암호화

• 암호화 되는 것
  - 볼륨 안에 있는 데이터
  • 인스턴스와 볼륨사이의 모든 데이터
  • 모든 스냅샷
  • 스냅샷으로부터 만들어지는 모든 볼륨
• 대기시간에 영향을 거의 주지 않기 때문에 무조건 해야함
• KMS의 키를 사용함
  - AES-256
• 사용방법
  - 스냅샷 생성
  • 복사기능을 이용해 EBS 스냅샷을 암호화 (생략 가능)
  • 스냅샷에서 새 EBS 볼륨을 생성함
  • 원본 인스턴스에 암호화된 볼륨을 연결

EFS

• Elastic FIle System
• network file system
• 다수의 EC2인스턴스에 마운트 될 수 있음.
  - 다수의 AZ에 있을 수 있음.
• 가용성이 높고 확장 가능 -> 비쌈
• gp2 ebs 볼륨의 3배..
• 보안그룹에 둘러싸여있음.
• 사용 사례
  - 콘텐츠 관리
  • 웹 서브데이터 공유
  • 워드프레스
• 내부에서 NFS 프로토콜 사용
• EFS 액세스를 제어하려면 보안 그룹을 설정해야함.
• 리눅스 기반 AMI와만 호환됨
• KMS를 이용해 암호화 가능함.
• 용량을 미리 계획할 필요 없음 -> 자동 확장, 비용은 On-demand
• 스케일
  - 수천개의 NFS 클라이언트와 10GB/s 처리량을 얻을 수 있음
  • petabyte 수준의 NFS까지 자동으로 확장 가능
• Performance Mode
  - general Purpose (default)
  - 대기시간이 민감한 사용사례에 사용됨
  - 웹서버, CMS
  - Max I/O
  - 처리량을 극대화 하고싶을 때 사용
  - 지연시간은 길지만 처리량은 높고 병렬적임
  - 빅데이터, 미디어 프로세싱에 사용
• Throughput Mode
  - Bursting
  - 50MiB/s + burst하면 100MiB/s
  • 프로비전
    • 스토리지 크기와는 관계없이 처리량을 설정함
      - Elastic
    • 처리량을 자동으로 늘렸다 줄였다 할 수 있는 기능
      • 3Gib/s read, 1GiB/writes
      • 예측하기 힘든 작업이 있을 때 사용
• Storage Tiers
  - Standard
  - 파일에 자주 접근할 때
  - Infrequent access (EFS-IA)
  - 접근계층이 별로 없음.
  - 파일을 복구하는데 비용을 지불함
  - 비용이 적게듬
  - 수명주기 정책을 사용해야함.
  - EFS Standard에 자주 사용되는 파일이 있을때, 60일 이상 액세스가 안되었다면 수명주기 정책으로 인해 EFS IA로 이동함 -> 비용절감
• 가용성과 내구성
  - Standard
  - Multi Az, 제품사용에 매우 좋음
  - One Zone
  - 하나의 AZ
  - 개발,백업 EFS-IA와 잘 맞음
  - 비용 절감
• EFS One Zone-IA
  - 비용절감 90퍼정도.

EBS vs EFS

• EBS
  - 1개의 인스턴스에만 붙음
  - io1,io2의 multi-attach 제외
  • AZ에서 잠김 -> 다른 AZ로 연결안됨
  • gp2: disk size 증가 -> io 증가
  • io1: 위의 예시와는 다르게 IO를 독립적으로 증가시킬 수 있음
  • 다른 AZ로 마이그레이션하려면
    • snapshot -> 다른 AZ로 볼륨 생성
      • EBS volume 백업은 io를 사용하기 때문에 응용프로그램이 많은트래픽을 처리하고 있다면 실행하면 안됨 -> 성능에 영향
  • Root EBS 볼륨은 EC2 인스턴스가 종료되면 같이 종료됨 (default)
• EFS
  - AZ 여러개에 걸쳐서 수백개의 인스턴스에 연결 가능함
  • 리눅스 인스턴스를 위함
  • EBS보다 가격이 좋지만 EFS-IA로 비용을 절감시킬 수 있음
• Instance Store
  - 인스턴스에 물리적으로 연결되어 있어서 EC2가 없어지면 같이 없어짐