특정 가용 영역에서만 가능(us-east-1a에서 생성된 경우 us-east-1b 연결X)
네트워크 USB 장치(물리적 드라이브X)
무료 등급으로는 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공
스냅샷 이용시 다른 가용 영역으로도 볼륨을 옮길 수 있음
GB, IOPS를 미리 정해야 함
인스턴스의 스토리지에서 EBS 볼륨 확인 가능볼륨 생성(가용 영역은 연결할 인스턴스와 동일하게 설정)EBS 볼륨이 2개가 된 것을 확인 가능
EBS 스냅샷
EBS 볼륨의 특정 시점에 대한 백업
EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 없지만 권장 사항
다른 가용 영역이나 다른 리전에도 복사할 수 있음
EBS Snapshot Archive
최대 75% 저렴한 아카이브 티어로 스냅샷을 옮길 수 있는 기능
복원하는데 24시간에서 최대 72시간 걸림
EBS 스냅샷 휴지통
EBS 스냅샷을 삭제하는 경우 영구 삭제하는 대신에 휴지통에 넣을 수 있음
휴지통 복원 가능
보관 기간: 1일 - 1년 사이
Fast Snapshot Restore(FSR) 빠른 스냅샷 복원
스냅샷을 완전 초기화해 첫 사용에서의 지연 시간을 없애는 기능
스냅샷이 아주 크고 EBS 볼륨 또는 EC2 인스턴스를 빠르게 초기화해야 할 때 유용
비용이 비쌈
EBS 스냅샷 생성
재해 복구 전략이 필요한 경우 매우 유용
AWS의 다른 리전에 데이터를 백업하고 싶은 경우
스냅샷에서 볼륨을 다시 생성하는 방법휴지통 기능스냅샷 삭제 시 휴지통에서 복구 가능
AMI(Amazon Machine Image)
EC2 인스턴스를 통해 만든 이미지
AMI로 AWS 구축 가능, 커스터마이징 가능(소프트웨어, 설정 파일 추가 및 운영 체제 설치 및 모니터링 툴 추가 등)
부팅 및 설정에 드는 시간 단축 가능(EC2 인스턴스에 설치하고자 하는 모든 소프트웨어를 AMI가 미리 패키징 해줘서)
특정 지역에 구축한 다음 다른 지역으로 복사해서 AWS의 글로벌 인프라 활용 가능
EC2 인스턴스를 여러 종류의 AMI에서 실행 가능
AWS 마켓플레이스 AMI에서 EC2 인스턴스 실행 가능(다른 사람이 구축한 이미지 사용)
AMI가 EC2 인스턴스에서 처리 되는 과정
EC2 인스턴스 설정
데이터 무결성 확보를 위한 인스턴스 중지
인스턴스를 바탕으로 AMI 구축 - 해당 과정에서 EBS 스냅샷 생성
사용자 지정 AMI를 다른 regions에서 실행 -> EC2 인스턴스 복사본 생성
AMI 생성AMI 생성된 화면사용자가 생성한 AMI로 인스턴스 생성 가능사용자 데이터를 다시 쓸 때 httpd 설치를 다시 안 해도 됨
부팅 속도가 매우 빠름
EC2 인스턴스 스토어
I/O 성능 향상을 위해 활용 가능
EC2 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실
장기적으로 데이터를 보관 불가능
버퍼, 캐시, 스크래치 데이터 또는 임시 콘텐츠를 사용하려는 경우에 사용
장기 스토리지의 경우에는 EBS가 적합
EBS 볼륨 타입
gp2 / gp3 (SSD) : 다양한 워크로드에 대해 가격과 성능의 균형을 맞추는 범용 SSD 볼륨
io 1 / io 2 Block Express (SSD) : 가장 높은 성능의 SSD 볼륨, 미션 크리티컬, 저지연, 고처리량 작업에 사용
st 1 (HDD) : 저비용 대용량 볼륨으로, 자주 액세스하고 처리량이 많은 작업을 위해 설계
sc 1 (HDD) : 가장 저렴한 HDD 볼륨으로, 액세스 빈도가 낮은 작업을 위해 설계
EBS 볼륨 타입 비교(gp2 vs gp3)
비용 효율적인 스토리지로, 낮은 대기 시간을 제공
시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경에 사용
gp2
크기 : 1GB - 16TB
볼륨은 최대 3,000 IO
볼륨의 GB 수 와 IOP를 비례(IOP와 처리량이 연관됨)
gp3
최신 세대 볼륨
기본적으로 3,000 IOP와 초당 125MB의 처리량 제공
IOP는 최대 16,000 까지, 처리량은 초당 최대 1,000MB까지 독립적으로 증가 가능
EBS 볼륨 타입 비교(io1 vs io2)
지속적인 IOPS 성능이 필요한 중요한 비즈니스 애플리케이션에 사용
16,000개 이상의 IOP가 필요한 애플리케이션에 사용
스토리지 성능과 일관성에 매우 민감한 경우 적합
EBS 다중 연결 가능
최대 16개의 EC2 인스턴스 연결 가능, 반드시 클러스터 인식 파일 시스템을 사용
동일한 EBS 볼륨을 동일한 AZ에 있는 다수의 EC2 인스턴스에 연결
io1
4TB - 16TB 지원하며 최대 IOP를 프로비저닝 가능
최대 IOP는 Nitro EC2 인스턴스의 경우 약 64,000이고 다른 종류의 인스턴스의 경우 32,000
io1 유형 볼륨은 스토리지 크기와 별도로 프로비저닝된 IOPS를 늘릴 수 있음
io2 Block Express
최대 64TB 사용 가능
256,000 IOP 제공되는데, IOPS : 기가바이트 = 1,000 : 1
EBS 볼륨 타입 비교(st1 vs sc1)
부팅 볼륨이 될 수 없음
이전 유형의 볼륨에서만 사용
125GB - 16TB
st1
처리량 최적화 HDD
빅데이터, 데이터 웨어하우징, 로그 처리에 적합
초당 최대 500MB 처리량과 최대 500 IOPS 제공
sc1
Cold HDD
아카이브 데이터용(장기간 보관이 필요하지만 자주 접근하지 않는 데이터를 저장하는 것)
자주 액세스되지 않는 데이터용
가능한 가장 낮은 비용이 필요할 때 사용
초당 최대 250MB 처리량과 최대 IOPS 250 제공
EBS 볼륨 암호화
EBS 볼륨 생성 시 발생하는 것
저장 데이터가 볼륨 내부에 암호화
인스턴스와 볼륨 간의 전송 데이터 암호화
스냅샷 + 스냅샷으로 생성한 볼륨 모두 암호화
백그라운드에서 EC2와 EBS가 암호화 및 복호화
지연 시간에는 영향이 거의 없고, KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 가짐
EBS 볼륨 암호화 및 복호화
볼륨의 EBS 스냅샷 생성 -> 복사 기능을 통해 EBS 스냅샷을 암호화
스냅샷을 이용해 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화
암호화된 볼륨을 인스턴스 원본에 연결
EFS(Elastic File System)
네트워크 파일 시스템
많은 EC2 인스턴스에 마운트 가능
EC2 인스턴스는 서로 다른 가용 영역에 있어도 됨
가용성 높고, 확장성 뛰어나며, 비쌈
gp2 EBS 볼륨의 약 3배
사용에 따라 비용 지불(GB 사용량) -> 프로비저닝X
콘텐츠 관리, 웹 서빙, 데이터 공유, wordpress
내부적으로 NFS 프로토콜 사용하며, EFS에 대한 액세스를 제어하려면 보안 그룹 설정해야 함
윈도우 호환 X, Linux기반 AMI만 호환
KMS 사용해서 EFS 드라이브에서 미사용 암호화 활성화 -> Linux 표준 파일 시스템(Posix 시스템), 표준 파일 API 존재
자동 확장 가능
EFS 성능 및 스토리지 클래스
EFS Scale
동시 NFS(Network File System) 클라이언트 수천 개와 10GB 이상의 처리량 확보
PB(1,024TB) 규모의 NFS로 자동 확장 가능
NFS 생성 시 성능 모드를 설정 가능
범용(Performance Mode)
지연 시간에 민감한 사용 사례에 사용. 예 : 웹 서버, CMS
처리량을 최대화하려면 최대 I/O 모드를 선택
지연 시간이 더 긴 NFS지만, 처리량이 높고 병렬성 높음
빅데이터 애플리케이션이나 미디어 처리가 필요한 경우 유용
처리량 모드(Throughput Mode)
버스팅 - 1TB = 50Mib/s + 100MilB 버스트
프로비저닝 - 스토리지 크기에 관계없이 처리량을 설정(스토리지와 처리량을 분리)
엘라스틱 - 워크로드에 따라 처리량을 자동 조절(Read : 초당 최대 3GiB, Write: 초당 최대 1GiB)
EFS - 스토리지 클래스
스토리지 티어
스탠다드 : 자주 액세스하는 파일을 위한 티어
EFS-IA : 자주 액세스하지 않는 용도, 파일을 검색할 경우 비용이 발생. But, 저장하면 비용 감소
아카이브 : 거의 액세스하지 않는 데이터(1년에 몇 번만 데이터에 액세스 하는 경우)
스토리지 티어 간에 파일을 자동으로 이동하시 위해 수명 주기 정책을 구현하여 며칠 후에 파일을 어느 계층으로 이동해야 하는지 정의 가능
가용성과 내구성
스탠다드 : 다중 AZ 설정이 있는 경우
One Zone : 개발만 하고 싶고 더 저렴한 옵션을 원할 때. 하나의 AZ에만 있고 백업은 기본적으로 활성화
올바른 EFS 스토리지 클래스를 사용하면 최대 90%의 비용 절감 가능
EFS 생성EFS 생성된 화면파일 시스템 EC2 인스턴스에 마운트efs-demo, efs-sg-1, efs-sg-2(EC2 콘솔이 대신 생성하여 EFS 파일 시스템에 연결)Instance B에서 hello.txt 생성한 화면Instance A에서 hello.txt 확인한 화면
두 EC2 인스턴스 모두 EFS 파일 시스템이 네트워크 드라이브로 마운트 된 것을 확인
서로 다른 AZ지만 같은 EFS 공유
EBS vs EFS
EBS
한 번에 하나의 인스턴스에 연결(io1, io2 제외)
gp2 : 디스크 크기가 증가하면 IO가 증가
gp3 및 io1 : 디스크 크기와 관계없이 IO 증가 가능
EBS 볼륨을 AZ 간에 마이그레이션하려면 스냅샷을 찍어 EBS 스냅샷에 넣은 후 다른 AZ에 복원해야 함
EBS 볼륨 백업은 IO를 사용하므로, 애플리케이션이 많은 트래픽을 처리하는 동안에는 성능에 영향을 줄 수 있으므로 실행X
