Amazon EC2 Instance Storage

EBS (Elastic Block Store)

EBS는 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브입니다. EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터를 지속할 수 있습니다. 우리가 인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하면 데이터를 다시 복구할 수 있습니다. 그리고 CCP 레벨의 EBS 볼륨은 (CCP 레벨: 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능 / Associate 레벨: 일부 EBS 다중 연결) 한 번에 하나의 인스턴스에만 마운트 할 수 있습니다. 또한 EBS 볼륨을 생성할 때는 특정 가용 영역에서만 가능합니다. 예를 들어 EBS 볼륨이 us-east-1a에서 생성된 경우 us-east-1b에는 연결이 불가능합니다. 즉 EBS 볼륨이란 네트워크 USB 스틱처럼 한 컴퓨터에서 꺼내 다른 컴퓨터에 꽂는 그런 장치는 맞지만 실제 물리적 연결은 없으며 네트워크를 통해 연결되는 것입니다. 무료 등급으로는 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공됩니다. 인스턴스와 EBS 볼륨이 서로 통신을 하기 위해서는 네트워크를 필요로 합니다. 그리고 네트워크가 사용되기 때문에 컴퓨터가 다른 서버에 도달할 때 지연이 생길 수 있습니다. EBS 볼륨은 네트워크 드라이브이므로 EC2 인스턴스에서 분리될 수 있고 매우 빠르게 다른 인스턴스로 연결될 수 있습니다. 이 때문에 대체 작동 등의 경우에 매우 유용합니다. EBS 볼륨은 특정 가용 영역에 고정되어 있으므로 us-east-1a에 생성된 볼륨은 us-east-1b로 연결이 불가능합니다. 마지막으로 EBS 볼륨을 생성한 후 연결하지 않고 그대로 둘 수도 있습니다. 꼭 EC2 인스턴스에 연결될 필요는 없습니다. 필요한 경우에만 연결이 가능한 아주 강력한 기능입니다.

하지만 스냅샷을 이용하면 다른 가용 영역으로도 볼륨을 옮길 수 있습니다. 또한 볼륨이기 때문에 용량을 미리 결정해야 합니다. 따라서 원하는 양의 GB 및 IOPS, 즉 단위 초당 전송 수를 미리 지정해야 합니다. 기본적으로 여러분이 원하는 EBS 볼륨의 성능을 미리 정의하는 겁니다. 그러면 해당 프로비전 용량에 따라 요금이 청구되고 더 좋은 성능이나 큰 사이즈가 필요하면 이후에 용량을 늘릴 수도 있습니다. us-east-1a에는 EC2 인스턴스 하나가 있고 EBS 볼륨 하나를 EC2 인스턴스를 하나 더 생성한다면 앞서 말했듯이 CCP 레벨의 EBS 볼륨은 한 번에 두 개의 인스턴스와 연결될 수 없습니다. 따라서 이 경우 두 번째 EC2 인스턴스는 고유한 EBS 볼륨이 따로 연결되어야 합니다. 하지만 인스턴스 하나에 두 개의 EBS 볼륨이 연결되는 건 문제없이 가능합니다. 네트워크 USB 스틱 두 개가 머신 하나에 연결되는 상황을 생각하면 됩니다. 이제 EBS 볼륨이 가용 영역에 연결되었습니다. 마지막으로 EC2 인스턴스를 통해 EBS 볼륨을 생성하는 경우 종료 시 삭제라고 하는 속성이 있습니다. 기본 설정으로는 루트 볼륨에 체크되어 있고 새로운 EBS 볼륨에는 체크가 되어 있지 않습니다. 이 옵션을 통해 EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있습니다. 기본적으로 루트 EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 설정이 되어 있습니다. 실제 사용 예시로는 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우 데이터를 저장하고자 하는 등의 경우에는 루트 볼륨의 종료 시 삭제 속성을 비활성화하면 됩니다.

EBS 스냅샷

언제든 원하는 시점에 EBS 볼륨을 가지고 와서 백업이라고 불리기도 하는 스냅샷(Snapshot)을 생성할 수 있습니다. 즉 추후에 EBS 볼륨을 삭제하더라도 해당 시점에 대한 백업으로 복원할 수 있습니다. 스냅샷을 생성하는 이유는 복원 목적도 있으나 가용 영역(AZ) 또는 리전(Region)에 걸친 스냅샷을 복사할 수 있기 때문입니다. 더불어서 AWS의 다른 리전에 데이터를 전송하여 글로벌 인프라를 활용하는 것입니다.

AMI (Amazon Machine Image)

AMI란 각자의 소프트웨어 구성에 대해 운영 체제를 정의 및 설정하며 모니터링 도구를 설정할 수도 있는데 이때 자체적으로 AMI를 생성하면 부팅과 구성에 시간이 단축됩니다. 이는 여러분의 EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징되기 때문입니다. 따라서 AMI를 자체적으로 구성하고 특정 리전에 맞도록 구축함으로써 이들을 원하는 리전에 복사해 놓거나 AWS 글로벌 인프라를 활용할 수 있는 겁니다. 따라서 여러 종류의 AMI에 EC2 인스턴스를 실행할 수 있습니다. AWS 마켓 플레이스 AMI에서도 EC2 인스턴스의 실행이 가능합니다. 이는 다른 사용자가 만들어서 판매하는 AMI로 자주 찾아볼 수 있습니다. AWS의 공급 업체가 자체적으로 AMI나 구성이 훌륭한 소프트웨어를 생성하고 여러분은 시간 절약을 위해 마켓 플레이스 AMI에서 이들을 구매할 수 있습니다. 또한 사용자인 여러분도 AWS 마켓 플레이스에서 AMI를 직접 판매할 수 있습니다.

EC2 인스턴스 스토어

지금까지 EC2 인스턴스에 네트워크 드라이브를 연결하는 방법까지 알아봤으나 그 성능은 제한됩니다. 제한된다는 뜻은 성능 자체는 뛰어나지만 이보다 더 높은 성능을 요구할 때가 있고 이때는 EC2 인스턴스에 연결된 하드웨어 디스크 성능이 향상되어야 합니다. EC2 인스턴스는 가상 머신이지만 실제로는 하드웨어 서버에 물리적으로 연결된 디스크 공간을 갖습니다. 따라서 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불리며 이는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가리킵니다. 이 EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용할 수 있습니다. 이들이 훌륭한 처리량을 갖추고 있어서 매우 향상된 디스크 성능을 요할 때에 활용할 수 있도록 확보할 필요가 있습니다. 이때 주의할 점은 여러분이 EC2 인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실된다는 것입니다. 이 같은 이유로 이를 임시 스토리지라고 부르며 EC2 인스턴스 스토어가 장기적으로 데이터를 보관할 만한 장소가 될 수 없음을 보여줍니다.

그러면 언제 사용하는 것이 좋을까요 ?

버퍼나 캐시 스크래치 데이터 또는 임시 콘텐츠를 사용하려는 경우 이들을 보관할 좋은 장소가 되지만 장기적인 스토리지는 될 수 없습니다. 장기 스토리지의 경우에는 EBS가 적합합니다. 마지막으로 EC2 인스턴스의 기본 서버에 장애가 발생할 시에는 해당 EC2 인스턴스가 연결된 하드웨어에도 장애가 발생하므로 데이터 손실에 대한 위험이 존재합니다. 따라서 EC2 인스턴스 스토어를 사용할 때에는 여러분의 필요에 따라 데이터를 백업해 두거나 복제해 둬야 합니다.

EBS 볼륨 유형

EBS 볼륨에 대해서는 총 6개의 유형이 있고 이들을 여러 범주로 나눌 수 있습니다.

• 첫째로는 gp2/gp3가 있는데 이는 범용 SSD 볼륨으로 다양한 워크로드에 대해 가격과 성능의 절충안이 되어 줍니다.
• 다음으로는 io1과 io2가 있습니다. 최고 성능을 자랑하는 SSD 볼륨으로 미션 크리티컬이자 지연 시간이 낮고 대용량의 워크로드에 쓰입니다.
• 그리고 st1 볼륨이 있는데 이는 저비용의 HDD 볼륨으로 잦은 접근과 처리량이 많은 워크로드에 쓰입니다.
• sc1 볼륨은 가장 비용이 적게 드는 HDD 볼륨으로 접근 빈도가 낮은 워크로드를 위해 설계되었습니다.

EBS 볼륨을 정의하는 데에는 크기, 처리량, IOPS가 있습니다. IOPS는 초당 I/O 작업 수를 뜻합니다. EC2 인스턴스에는 gp2/gp3와 io1/io2만이 부팅 볼륨으로 사용될 수 있습니다. 루트 OS가 실행될 위치에 해당합니다. gp2는 짧은 지연 시간을 자랑하며 효율적인 비용의 스토리지입니다. 시스템 부팅 볼륨에서 가상 데스크톱, 개발, 테스트 환경에서 사용할 수 있습니다. 크기는 1GB에서 16TB까지 다양합니다. gp2와 gp3에는 차이가 있는데 gp3는 최신 세대의 볼륨으로 기본 성능으로 3,000 IOPS와 초당 125MB의 처리량을 제공합니다. 각각 IOPS는 최대 16,000 IOPS, 처리량은 1,000MB/S까지 증가시킬 수 있습니다. 이는 연결되어 있지 않다는 뜻입니다. gp2는 좀 더 오래된 버전으로 볼륨이 더 작습니다. 최대 3,000 IOPS, 볼륨과 IOPS가 연결되어 있어서 IOPS가 증가할 때면 즉 볼륨의 GB 수를 늘릴 때에 세 배 더 증가한 16,000 IOPS가 된다는 의미입니다.

가령 5,334GB라고 한다면 최대 용량인 16,000 IOPS를 초과하는 상황이 발생합니다. gp2/gp3가 비용 효과적인 스토리지이며 gp3에서는 IOPS와 처리량을 독자적으로 설정할 수 있는 반면 gp2에서는 그 둘이 연결되어 있다는 점입니다. 중요한 내용은 프로비저닝을 마친 IOPS로 이는 IOPS 성능을 유지할 필요가 있는 주요 비즈니스 애플리케이션이나 16,000 IOPS 이상을 요하는 애플리케이션에 적합합니다. 일반적으로 데이터베이스 워크로드에 알맞습니다.

스토리지를 이용하는 경우에는 스토리지 성능과 일관성에 아주 민감하여 gp2 또는 gp3 볼륨에서 io1 또는 io2 볼륨으로 바꾸는 것이 해답입니다. io1/io2 중에서는 최신 세대를 고르는 것이 좋습니다. 4 ~ 16TB에 달하며 Nitro EC2 인스턴스에서는 최대 64,000 IOPS까지 가능합니다. Nitro EC2 인스턴스의 경우 이를 통해 더 높은 IOPS까지 이용할 수 있습니다. Nitro EC2 인스턴스가 아닌 경우에는 최대 32,000 IOPS까지 지원됩니다. 또한 io1/io2를 이용하면 gp3 볼륨처럼 프로비저닝된 IOPS 스토리지 크기와 독자적으로 증가시킬 수 있습니다.
io2는 io1과 동일한 비용으로 내구성과 기가 당 IOPS의 수가 더 높습니다. 현재까지는 io2를 사용하는 것이 더 합리적입니다.

다음은 st1과 sc1에 대해 이야기해보겠습니다. 이 둘은 부팅 볼륨일 수 없습니다. 이전 유형의 볼륨에 해당합니다. 최대 16TB까지 확장되며 두 가지 종류의 볼륨을 제공합니다. 하나는 st1인 처리량 최적화 HDD로 빅 데이터나 데이터 웨어하우징 로그 처리에 적합합니다. 최대 처리량은 초당 500MB 그리고 최대 IOPS는 500 IOPS에 달합니다. 다음으로는 sc1인 콜드 HDD가 있는데 이는 아카이브 데이터용으로 접근 빈도가 낮은 데이터에 적합합니다. 최저 비용으로 데이터를 저장할 때에 사용합니다. 최대 처리량은 초당 250MB 그리고 최대 IOPS도 250 IOPS입니다.

EBS 다중 연결

io1/io2 제품군에 대한 내용입니다. 앞서 EBS 볼륨은 단일한 EC2 인스턴스에만 연결할 수 있다고 했습니다. EBS 다중 연결을 제외한 경우에 말입니다. 다중 연결로 동일한 EBS 볼륨을 동일한 가용 영역 내의 여러 EC2 인스턴스에 연결하여 사용할 수 있습니다. 예들 들어, 세 개의 EC2 인스턴스가 있고 다중 연결이 각능한 io2 볼륨이 있다고 가정해 봅시다. 이 볼륨은 한 번에 총 세 개의 EC2 인스턴스에 연결할 수 있습니다. 이때 각 EC2 인스턴스는 볼륨에 대한 전체 읽기 및 쓰기 권한을 갖습니다. 모든 애플리케이션에서 가능하지는 않으나 해당 애플리케이션 내에서는 동일한 볼륨에서의 동시 쓰기 작업을 관리할 수 있어야 합니다. 따라서 이는 특정 워크 로드에만 해당되며 특정 유형의 EBS 볼륨에 대해서만 가능합니다. 이를 위해서는 반드시 클러스터 인식 파일 시스템을 사용해야 합니다. XFS나 EX4 등은 사용할 수 없습니다. 또한 EBS는 io1이나 io2 제품군일 때만 여러 EC2 인스턴스에 연결이 가능합니다.

EBS 볼륨 암호화

암호화된 EBS 볼륨을 생성하는 즉시 볼륨 내에서 암호화된 저장 데이터를 가져오고 인스턴스와 볼륨 간에 전송되는 모든 데이터는 암호화됩니다. 모든 스냅샷이 암호화되고 스냅샷에서 생성된 모든 볼륨은 암호화 됩니다. 즉 모든 곳이 암호화 되는 셈입니다. 그리고 기존 암호화와 해독 매커니즘이 투명하게 처리되므로 사용자는 할 작업이 없습니다. 모든 작업은 뒷단에서 EC2와 EBS에서 처리됩니다. 전반적으로 암호화는 지연 시간에 미치는 영향도 거의 없고 KMS 즉 AES-256의 키를 활용합니다. 그래서 암호화되지 않은 스냅샷을 복사할 때 암호화를 활성화합니다. 암호화되지 않은 EBS 볼륨을 어떻게 암호화하는지에 대해 얘기해보겠습니다. 이는 아주 중요한 사항입니다. 암호화되지 않은 EBS 볼륨을 암호화하려면 먼저 볼륨의 EBS 스냅샷을 생성하고 복사로 EBS 스냅샷을 암호화합니다. 그런 다음 스냅샷에서 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화되게 됩니다. 이제 암호화된 볼륨을 원본 인스턴스에 연결할 수 있습니다.

EFS (Elastic File System)

다양한 가용 영역에 걸쳐 다수의 EC2 인스턴스에 마운트할 수 있는 관리형 NFS 혹은 네트워크 파일 시스템입니다. 즉 다중 AZ에서 동작하며 이 점이 EFS와 EBS의 가장 큰 차이를 보여줍니다. EBS는 단일 가용 영역에 묶여 있는 반면 EFS는 다중 가용 영역에 걸쳐서 마운트가 가능합니다. 따라서 가용성이 매우 높습니다. 확장성도 높으며 비용도 많이 듭니다. gp2 드라이브 비용의 약 세 배에 달하지만 쓴 만큼만 내면 됩니다. 따라서 너무 많은 데이터를 저장하지 않는 경우 EBS보다 EFS가 저렴할 수 있습니다. EBS는 한 번에 하나의 EC2 인스턴스에만 연결되어 있어서 데이터가 다중의 EC2 인스턴스 간 공유되지 않지만 이 경우 EFS에서는 네트워크 파일 시스템으로 EFS 드라이브의 모든 EC2 인스턴스가 동일한 파일에 대한 접근 권한을 갖습니다. EFS는 콘텐츠 관리, 웹 서비스, 데이터 공유 또는 WordPress 웹사이트에서 쓰입니다. 표준 NFSv4.1 프로토콜이 사용되며 이는 네트워크 드라이브 마운트 시 기본적인 방법입니다. 또한 EFS 파일 시스템에 접근하려면 네트워크 보안인 보안 그룹을 이용해야 합니다. EFS는 Windows가 아닌 Linux 기반 AMI에서만 작동합니다. Windows 인스턴스는 파일 시스템에 EFS를 마운트할 수 없습니다. KMS 키를 사용하여 EFS 유휴 시 암호화를 설정할 수 있습니다. EFS는 POSIX 파일 시스템, 즉 Linux에서만 사용 가능하며 표준 파일 API를 갖습니다. 파일 시스템은 자동으로 확장되며 쓰는 만큼 비용을 내는 방식으로 용량에 구애받지 않고 사용이 가능합니다.

EFS 성능 모드

범용 성능 모드

성능 모드에는 두 가지가 존재합니다. 웹 서버 운영이나 지연 시간에 민감한 파일이 있는 경우 범용 성능 모드를 사용합니다. 예시로 WordPress를 운영할 때에 범용 EFS 파일 시스템을 사용하는 것처럼 말입니다. 이 경우에는 여러 작은 파일에 신속히 접근해야 하는데 EFS가 바로 해당 경우를 위해 제작되었습니다.

Max I/O 성능 모드

EFS에서 대규모 데이터 워크로드를 처리하는 경우 Max I/O 성능 모드가 적합합니다. 지연 시간은 더 길겠지만 처리량은 더 향상됩니다. 이는 훨씬 더 병렬적이므로 빅데이터나 미디어 처리에도 훌륭한 성능을 보입니다.

처리량 모드

처리량 모드는 기본적으로 버스팅(Bursting) 처리량 모드로 설정되어 있습니다. 1TB 스토리지에 대해 초당 50MB를 저장할 수 있으며 여기에 초당 100MB까지 확장이 가능하다는 것입니다. 일반적으로는 파일 시스템의 크기에 따라 처리량이 증가하므로 EFS 파일 시스템의 크기는 줄이면서 처리량을 높이기 위해서는 프로비저닝된 처리량 모드로 설정을 바꿀 수 있습니다. 이 모드에서는 스토리지 크기와 상관없이 처리량을 설정할 수 있습니다. 1TB의 스토리지에 불과하더라도 초당 1GB의 처리량을 요청할 수 있습니다. 파일 시스템 자체는 작으나 높은 처리량을 요구할 때에는 EFS의 프로비저닝 된 처리량 모드로 변경할 필요가 있는 것입니다.

스토리지 계층

마지막으로 시험에 출제될 내용으로는 스토리지 계층을 꼽을 수 있습니다. 이는 파일에 대한 수명 주기 관리 기능으로 30일이 지난 후 새로운 계층으로 파일을 이동시키는 기능입니다. 접근 빈도가 높은 파일에 대해 표준으로 설정되어 있으며 EFS-IA라고 부르며 저비용의 빈도가 낮은 접근에 대한 티어가 있습니다. 이와 같은 파일을 저장할 저비용의 장소인 것입니다. 하지만 해당 파일을 가져올 때마다 관련된 비용이 발생합니다.

EBS vs EFS

EBS 볼륨은 한 번에 하나의 인스턴스에만 연결이 가능하고 특정 가용 영역에 한정됩니다. 예를 들면, EC2 인스턴스가 첫 번째 AZ에 연결됐고 EBS 볼륨은 실제로 해당 AZ 안에 있을 때 EBS는 한 번에 EC2 인스턴스 하나에만 연결이 가능합니다. EBS의 gp2 볼륨에서는 디스크 크기가 늘어나면 IO도 함께 증가합니다. io1은 IO를 볼륨 크기와 관계 없이 독립적으로 증가시킬 수 있습니다. 중요한 데이터베이스를 실행할 때 좋은 방법입니다. EBS를 다른 가용 영역으로 옮기고자 할 때는 가장 먼저 스냅샷을 찍어야 합니다. 스냅샷을 찍었다면 다른 AZ에서 그 스냅샷을 복원시키면 됩니다. 그러면 해당 AZ에 EBS 볼륨이 생성됩니다. EBS의 스냅샷이나 백업을 만들 때에는 EBS 볼륨 내의 IO를 전부 사용하게 되니 인스턴스가 EBS를 사용 중이 아닐 때에만 실행해야 합니다. 그렇지 않으면 성능에 문제가 발생할 수 있습니다. EC2 인스턴스가 종료되면 인스턴스 내의 루트 EBS 볼륨도 기본적으로 종료됩니다. 원할 경우 이 동작은 비활성화할 수 있습니다. 하지만 EFS는 이와 완전히 다릅니다. EFS는 일래스틱 파일 시스템으로 여러 개의 가용 영역에 걸쳐 무수히 많은 인스턴스들에 연결될 수 있습니다. EFS Mount Target을 사용해 특정 AZ에서 EC2 인스턴스들과 EFS 드라이브를 연결해 줄 수도 있습니다. WordPress 같은 웹 사이트 파일을 공유할 때도 EFS를 씁니다. 이는 Linux 인스턴스에서만 가능한데 POSIX 파일 시스템이라 Windows에서는 구동되지 않기 때문입니다. 또한 EFS는 EBS보다 훨씬 비쌉니다. 거의 세 배 정도 더 비싸죠. 하지만 비용을 절약하고 싶은 경우에는 스토리지 티어로 EFS-IA를 사용하고 제품 수명 정책을 사용하면 비용을 절감할 수 있습니다. EFS 사용 시에 또 기억해야 할 점은 EFS는 사용한 만큼만 비용이 청구된다는 점입니다. EBS의 경우에는 실제 사용한 양이 아니라 EBS 드라이브의 크기에 따라 실제 사용량이 아니라 정해진 사용량을 지불한는 식이었습니다. EFS는 다수의 인스턴스에 걸쳐 연결해야 하는 네트워크 파일 시스템에 적합하다는 것을 알아두면 됩니다. 반면 EBS는 네트워크 볼륨을 한 번에 하나의 인스턴스에 연결할 수 있고 특정 AZ 내로 한정됩니다. 인스턴스 스토어는 EC2 인스턴스에 IO를 최대로 사용하게끔 해주지만 인스턴스가 망가지면 함께 망가지는 임시 드라이브가 됩니다.

1. 루트 볼륨 유형과 데이터 저장을 위한 기타 EBS 볼륨 유형, 두 개의 EBS 볼륨으로 EC2 인스턴스를 실행했습니다. EC2 인스턴스는 한 달 후에 종료할 예정입니다. 각 EBS 볼륨에 기본적으로 나타날 행위 특성은 무엇일까요 ?

• A. 루트 볼륨 유형과 EBS 볼륨 유형이 모두 삭제됨
• B. 루트 볼륨 유형은 삭제되지만, EBS 볼륨 유형은 삭제되지 않음
• C. 루트 볼륨 유형은 삭제되지 않고, EBS 볼륨 유형은 삭제됨
• D. 루트 볼륨 유형과 EBS 볼륨 유형 모두 삭제되지 않음

✅ 루트 볼륨의 경우 '종료시 삭제' 속성이 기본으로 활성화되어 있기 때문에 기본적으로 삭제되게 됩니다. 기타 EBS 볼륨 유형의 경우 '종료시 삭제' 속성이 기본적으로 비활성화되어 있으므로 삭제되지 않습니다.

2. 노스버지니아 리전 us-east-1에서 AMI를 사용하면 어떤 AWS 리전에 있는 EC2 인스턴스라도 실행할 수 있습니다.

• A. 맞습니다.
• B. 아닙니다.

✅ AMI는 특정 AWS 리전에 국한되며, 각 AWS 리전에는 고유한 AMI가 있습니다. 다른 AWS 리전에서 AMI를 사용해 EC2 인스턴스를 실행하는 것은 불가능하지만 대상 AWS 리전으로 AMI를 복사해 EC2 인스턴스를 생성하는 것은 가능합니다.

3. 다음 중 EC2 인스턴스를 생성할 때 부팅 볼륨으로 사용할 수 있는 EBS 볼륨 유형은 무엇인가요 ?

• A. gp2, gp3, st1, sc1
• B. gp2, gp3, io1, io2
• C. io1, io2, st1, sc1

✅ EC2 인스턴스를 생성할 때, 부팅 볼륨으로는 다음의 EBS 볼륨 유형만을 사용할 수 있습니다. gp2, gp3, io1, io2 Magnetic(표준)

4. us-east-1a에서의 EC2 인스턴스를 종료하여, 이 인스턴스에 연결된 EBS 볼륨을 사용할 수 있게 되었습니다. 팀원이 us-east-1b의 EC2 인스턴스에 이 볼륨을 연결하려 했으나, 연결이 불가능한 상태입니다. 이 경우, 가능성이 있는 원인은 무엇일까요 ?

• A. IAM 권한이 없음
• B. EBS 볼륨은 AWS 리전으로 제한되어 있음
• C. EBS 볼륨은 가용 영역으로 제한되어 있음

✅ EBS 볼륨은 특정 AZ에 맞춰 생성됩니다. EBS 스냅샷을 활용하면 다른 AZ 간의 이전이 가능합니다.

5. EBS 다중 연결이란 무엇일까요 ?

• A. 동일한 EBS 볼륨을 다수의 AZ에 있는 다수의 EC2 인스턴스에 연결
• B. 다수의 EBS 볼륨을 동일한 AZ에 있는 동일한 EC2 인스턴스에 연결
• C. 동일한 EBS 볼륨을 동일한 AZ에 있는 다수의 EC2 인스턴스에 연결
• D. 다수의 EBS 볼륨을 다수의 AZ에 있는 동일한 EC2 인스턴스에 연결

✅ EBS 다중 연결을 사용하면 동일한 EBS 볼륨을 동일 AZ 상에 있는 다수의 EC2 인스턴스에 연결할 수 있습니다. 각 EC2 인스턴스는 완전한 읽기/쓰기 권한을 갖게 됩니다.

6. EC2 인스턴스에 연결되어 있는 암호화되지 않은 EBS 볼륨을 암호화하려 합니다. 어떻게 해야 할까요 ?
   - A. EBS 볼륨의 EBS 스냅샷을 생성하고 스냅샷을 복사한 뒤 복사된 스냅샷을 암호화하는 옵션을 체크합니다. 그 후, 암호화된 스냅샷을 사용해 새로운 EBS 볼륨을 생성합니다.

• B. EBS 볼륨을 선택하고, Edit 속성을 선택한 후, KMS 옵션을 사용해 암호화 옵션을 체크합니다.
• C. 암호화된 EBS 볼륨을 새로 생성한 후, 암호화되지 않은 EBS 볼륨의 데이터를 새로운 EBS 볼륨으로 복사합니다.
• D. AWS 지원센터에 EBS 볼륨 암호화를 요청합니다.

7. 대량의 데이터 세트를 처리하는, 다수의 AZ에 걸친 EC2 인스턴스 플릿이 있습니다. 동일한 데이터가 NFS 드라이브로서 모든 EC2 인스턴스에서 액세할 수 있게 만들기 위해서는 어떤 방법을 추천할 수 있을까요 ?

• A. EBS 사용
• B. EFS 사용
• C. 인스턴스 스토어 사용

8. EC2 인스턴스에 호스팅된 애플리케이션에 고성능 로컬 캐시를 포함시키려 합니다. EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황입니다. 이런 경우, 솔루션 아키텍트로서 어떤 스토리지 매커니즘을 추천할 수 있을까요 ?

• A. EBS
• B. EFS
• C. 인스턴스 스토어

✅ EC2 인스턴스 스토어는 최적의 디스크 I/O 성능을 제공합니다.

9. 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행하고 있습니다. 어떤 방법을 추천할 수 있을까요 ?

• A. EBS gp2 드라이브 사용
• B. EBS io1 드라이브 사용
• C. EC2 인스턴스 스토어 사용
• D. EBS io2 Block Express 드라이브 사용

✅ EC2 인스턴스에서 데이터베이스를 인스턴스 스토어를 사용하여 실행 가능하지만, EC2 인스턴스가 중지 시 데이터가 손실된다는 문제가 있습니다. 한 가지 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 매커니즘을 설정하여 대기 복사본을 가질 수 있다는 것입니다. 또 다른 솔루션은 데이터에 대한 백업 매커니즘을 설정하는 것입니다. 요구 사항을 검증하기 위해 아키텍처를 설정하는 방법은 모두 사용자에게 달려 있습니다. 이 사용 사례에서는 IOPS 기준이므로 EC2 인스턴스 스토어를 선택해야 합니다.