Amazon EBS FAQ

프로비저닝된 IOPS SSD(io2 Block Express 및 io1) 볼륨은 EBS 최적화 인스턴스에 연결될 경우, 연중 99.9%의 기간 동안 프로비저닝된 IOPS 성능을 10% 이내의 오차로 제공하도록 설계되었습니다. 정확한 성능은 애플리케이션의 I/O 요구 사항에 따라 달라집니다.

EBS 최적화 인스턴스에 연결하면 프로비저닝된 IOPS io2 Block Express 볼륨은 밀리초 미만의 지연 시간을 달성할 수 있고, io1 볼륨은 한 자릿수 밀리초의 지연 시간을 달성할 수 있습니다. 정확한 성능은 애플리케이션의 I/O 요구 사항에 따라 달라집니다.

예. 그렇습니다. io2 Block Express 볼륨의 IOPS를 프로비저닝할 때, IOPS 속도는 애플리케이션의 읽기 및 쓰기의 I/O 크기에 따라 달라집니다. 프로비저닝된 IOPS 볼륨의 기본 I/O 크기는 16KB입니다. 따라서 16KB의 I/O 크기에 대해 40,000 IOPS로 볼륨을 프로비저닝하면, 이 크기에서 최대 40,000 IOPS를 달성할 수 있습니다. I/O 크기가 256KB로 증가하면 16,000 IOPS에서 최대 처리량이 4000MiB/초에 달하므로 최대 16,000 IOPS를 달성할 수 있습니다. 자세한 내용은 프로비저닝된 IOPS 볼륨에 대한 기술 설명서를 참조하세요. Amazon CloudWatch를 사용하여 처리량과 I/O 크기를 모니터링할 수 있습니다.

프로비저닝된 IOPS SSD(io2 Block Express 및 io1) 볼륨은 EBS 최적화 인스턴스에 연결할 경우 연중 99.9%의 기간 동안에 프로비저닝된 IOPS 성능을 10% 이내의 오차로 제공하는 일관된 성능을 유지하도록 설계되었습니다. 스냅샷에서 생성된 새 볼륨의 성능 일관성을 극대화하려면, 스냅샷에서 빠른 스냅샷 복원(FSR)을 활성화할 것을 권장합니다. FSR 활성 스냅샷에서 복원된 EBS 볼륨은 전체 성능을 즉시 가져옵니다.

애플리케이션에서 충분한 I/O 요청을 보내고 있지 않을 경우 이 역시 성능에 영향을 줄 수 있습니다. 이는 볼륨의 대기열 깊이를 살피면서 모니터링할 수 있습니다. 대기열 깊이는 애플리케이션에서 볼륨으로 보내는 I/O 요청 중 대기 중인 요청의 수입니다. 프로비저닝된 IOPS 볼륨에서 일관성을 극대화하려면 가장 가까운 정수로 반올림한 평균 대기열 깊이가 분당 프로비저닝된 1000IOPS당 1 수w준으로 유지되어야 합니다. 예를 들어, 3000IOPS로 프로비저닝된 볼륨의 경우 평균 대기열 깊이는 3입니다. 볼륨의 일관된 성능 보장에 대한 자세한 내용은 EBS 성능 개선을 참조하십시오.

EBS 최적화 인스턴스에 연결되는 경우, 처리량 최적화 HDD(st1) 및 콜드 HDD(sc1) 볼륨은 연중 99%의 기간 동안 기대 처리량 성능을 10% 이내의 오차로 제공하도록 설계되었습니다. 정확한 성능은 애플리케이션의 I/O 요구 사항과 EC2 인스턴스의 성능에 따라 달라집니다.

예. 처리량 속도는 애플리케이션 읽기 및 쓰기의 I/O 크기에 따라 달라집니다. HDD 지원 볼륨은 1MB의 I/O 크기로 읽기 및 쓰기를 처리합니다. 순차적 I/O는 1MB 단위로 병합되어 처리되는 반면에 각 비순차적 I/O는 실제 I/O 크기가 1MB보다 작더라도 1MB로 처리됩니다. 따라서 데이터베이스처럼 작은 랜덤 I/O의 트랜잭션 워크로드는 HDD 지원 볼륨에서 좋은 성능을 발휘하지 못하지만, 순차적 I/O 및 큰 I/O 크기는 장기적으로 st1와 sc1에서 제시하는 성능을 달성할 수 있습니다.

EBS 최적화 인스턴스에 연결된 처리량 최적화 HDD(st1) 및 콜드 HDD(sc1) 볼륨은 일관된 성능을 제공하도록 설계되어, 연중 99%의 시간 동안 기대 처리량 성능을 10% 이내의 오차로 제공합니다. 여러 요인이 일관성 수준에 영향을 줄 수 있습니다. 예를 들어 볼륨에서 임의 I/O와 순차적 I/O 작업 간의 상대적 균형이 성능에 영향을 줄 수 있습니다. 작은 임의 I/O 작업이 너무 많으면 I/O 크레딧이 빠르게 소진되어 기준 속도로 성능이 떨어지게 됩니다. 또한, 처리량 속도는 선택한 인스턴스에 따라 더 낮아질 수 있습니다. st1은 최대 500MB/초의 처리량을 제공할 수 있지만, 성능은 EBS 트래픽에 대한 개별 인스턴스 수준 제한에 따라 제한될 수 있습니다. 또 다른 요소는 스냅샷 생성으로, 스냅샷이 완료될 때까지 기대 쓰기 성능을 기준 속도까지 떨어뜨립니다. 이 요소는 st1과 sc1에만 해당합니다.

애플리케이션에서 충분한 I/O 요청을 보내지 않을 경우에도 성능에 영향을 줄 수 있습니다. 볼륨의 대기열 깊이와 I/O 크기를 살펴보는 것으로 모니터링할 수 있습니다. 대기열 깊이는 애플리케이션에서 볼륨으로 보내는 I/O 요청 중 대기 중인 요청의 수입니다. HDD 지원 볼륨에서 일관성을 극대화하려면 가장 가까운 정수로 반올림한 평균 대기열 깊이가 1MB의 순차 I/O당 4 이상의 수준으로 유지되어야 합니다. 볼륨의 일관된 성능 보장에 대한 자세한 내용은 EBS 성능 개선을 참조하십시오.

예. 더 큰 EC2 인스턴스에 연결된 경우, 여러 볼륨을 함께 스트라이프하여 최대 400,000 IOPS 또는12,500MB/초를 달성할 수 있습니다. 여러 볼륨을 스트라이핑하는 운영 관리 없이 성능 요구 사항을 높이려면 io2 Block Express 볼륨을 사용하는 것이 좋습니다. st1 및 sc1의 성능은 볼륨 크기에 따라 선형적으로 증가하므로, 이러한 볼륨은 함께 스트라이프해도 큰 효과는 없을 수 있습니다.

EBS는 멀티 테넌트 블록 스토리지 서비스입니다. AWS는 리소스 경합을 피하기 위해 속도 제한을 메커니즘으로 사용합니다. 먼저, 볼륨에 대해 성능 기준을 정의하는 것부터 시작합니다. AWS 볼륨 유형(gp2, PIOPS, st1 및 sc1)에는 IOPS 및 처리량 관점에서 성능 특성이 모두 정의되어 있습니다. 다음 단계는, 인스턴스 수준에서 성능을 정의하는 것입니다. 각 EBS 최적화 인스턴스에는 인스턴스에 연결된 EBS 볼륨 세트에 대해 성능(처리량 및 IOPS 모두)이 정의되어 있습니다. 따라서 고객은 원하는 성능 수준을 얻기 위해 인스턴스 및 볼륨 크기를 조정할 수 있습니다. 또한 고객은 보고된 지표를 사용하여 인스턴스 수준 및 볼륨 수준 성능을 관찰할 수 있습니다. 나타나는 수치가 예상 성능과 일치하지 않는지 확인하기 위해 경보를 설정할 수 있으며, 이러한 지표는 고객에게 볼륨 수준에서 올바른 성능으로 올바른 유형의 인스턴스가 구성되었는지 여부를 확인하는 데도 도움을 줄 수 있습니다. AWS는 EBS 측에서 볼륨을 지원하기 위해 적절한 인스턴스 및 EBS 인프라를 할당하는 방법을 알리도록 구성된 성능을 사용합니다. 인프라를 적절히 할당하면 리소스 경합을 피할 수 있습니다. 또한 AWS는 지속적으로 인프라를 모니터합니다. 이러한 모니터링을 통해 인프라 장애(또는 임박한 인프라 장애)를 감지하므로, 사전에 볼륨을 작동하는 하드웨어로 이전하는 동시에 기본 인프라의 복구 또는 교체(해당되는 경우)를 수행할 수 있습니다.

범용 SSD(gp3 및 gp2) 볼륨은 EBS 최적화 인스턴스에 연결될 경우, 연중 99%의 기간 동안 프로비저닝된 IOPS 성능을 10% 이내의 오차로 제공하도록 설계되었습니다. 정확한 성능은 애플리케이션의 I/O 요구 사항에 따라 달라집니다.

EBS 최적화 인스턴스에 연결하는 경우 범용 SSD (gp3 및 gp2) 볼륨은 한 자리 수 밀리초 미만의 지연 시간을 달성할 수 있습니다. 정확한 성능은 애플리케이션의 I/O 요구 사항에 따라 달라집니다.

아니오, 모든 범용 SSD(gp3) 볼륨은 추가 비용 없이 3,000 IOPS 및 125MB/초의 지속적인 성능을 포함합니다. 볼륨은 무기한으로 전체 3,000 IOPS 및 125MB/초를 유지할 수 있습니다.

범용 SSD (gp2) 볼륨은 1,000GB 미만일 때 30분 이상의 지속적 성능을 위해 최대 3,000 IOPS의 버스트 IOPS 성능을 제공합니다. 추가로 gp2 볼륨은 프로비저닝된 GB 당 3 IOPS의 지속적인 성능을 제공합니다. 예를 들어 500GB 볼륨은 지속적으로 1,500 IOPS를 주도할 수 있으며, 60분 동안 3,000 IOPS로 버스트할 수 있습니다 (3,000 IOPS * 60초 * 30분 / 1,500 IOPS / 60초).

io2 볼륨은 모든 EC2 인스턴스에 고성능 블록 스토리지를 제공합니다. 더 높은 성능을 필요로 하는 애플리케이션의 경우, Block Express에서 실행되고 io2보다 4배 높은 성능을 제공하는 이러한 Amazon EC2 인스턴스에 io2 볼륨을 연결할 수 있습니다. 이렇게 하면 단일 io2 볼륨에서 최대 64TiB 용량, 25만 6,000 IOPS 및 4,000MB/s의 스루풋과 밀리초 미만의 평균 IO 지연 시간을 달성할 수 있습니다.

EBS Block Express는 밀리초 미만의 지연 시간으로 최고 수준의 성능을 제공하도록 특별히 구축된 클라우드 규모의 블록 저장소용 차세대 Amazon EBS 스토리지 서버 아키텍처입니다. Block Express은 고성능 저대기시간 네트워크 프로토콜인 Scalable Reliable Datagrams (SRD)를 사용하여 이를 수행하고, Nitro System-based EC2 인스턴스와 소통합니다. 이는 고성능 컴퓨팅 (HPC) 및 기계 학습 (ML) 워크로드를 위한 Elastic Fabric Adapter (EFA)의 인스턴스 간 통신에 사용되는 것과 동일한 고성능 및 짧은 지연 시간 네트워크 인터페이스입니다. 또한 Block Express는 다양한 방법으로 조합할 수 있는 모듈식 소프트웨어 및 하드웨어 빌딩 블록을 제공하여 향상된 성능과 새로운 기능을 보다 빠른 속도로 설계 및 제공할 수 있는 탄력성을 제공합니다.

io2 Block Express는 단일 볼륨에서 지연 시간 단축, IOPS 향상, 스루풋 증가 또는 용량 증가 등의 이점을 제공하는 성능 및 용량 집약적인 워크로드에 적합합니다. 이러한 워크로드는 관계형 및 NoSQL 데이터베이스(SAP HANA, Oracle, MS SQL, PostgreSQL, MySQL, MongoDB, Cassandra), 그리고 크리티컬 비즈니스 운영 워크로드(SAP Business Suite, NetWeaver, Oracle eBusiness, PeopleSoft, Siebel)와 ERP 워크로드(Infor LN 및 Infor M3)를 포함합니다.

io2 볼륨을 이러한 Amazon EC2 인스턴스에 연결한 경우 Block Express에서 실행됩니다. Block Express는 1밀리초 미만의 지연 시간을 제공하고 최대 25만 6,000 IOPS 및 4,000MB/s 처리량까지 구동할 수 있으며 단일 볼륨에서 최대 64TiB 크기를 제공합니다. 다른 모든 인스턴스에 연결된 io2 볼륨은 Block Express에서 실행되지 않으며 10밀리초 미만의 지연 시간을 제공하고 64K IOPS 및 1GB/s 처리량까지 구동할 수 있으며 단일 볼륨에서 최대 16TiB 크기를 제공합니다.
 

이 기능은 AWS CLI를 사용하거나 AWS SDK를 통해 호출할 수 있는 API를 통해 사용할 수 있습니다. API의 예는 다음과 같습니다.

• 스냅샷 블록 나열하기: ListSnapshotBlocks API 작업은 지정된 스냅샷의 블록에 대한 블록 인덱스와 블록 토큰을 반환합니다.
• 변경된 블록 나열하기: The ListChangedBlocks API 작업은 동일한 볼륨/스냅샷 계보를 갖고 있는 두 개의 지정된 스냅샷 간에 차이가 있는 블록에 대한 블록 토큰과 블록 인덱스를 반환합니다.
• 스냅샷 블록 가져오기: GetSnapshotBlock API 작업은 지정된 스냅샷 ID, 블록 인덱스 및 블록 토큰에 대한 블록의 데이터를 반환합니다.
• 스냅샷 시작: StartSnapshot 작업은 기존 스냅샷의 증분 스냅샷 또는 새 스냅샷으로 스냅샷을 시작합니다. 시작된 스냅샷은 CompleteSnapshot 작업 사용을 마칠 때까지 대기 중 상태로 유지됩니다.
• 스냅샷 블록 추가: PutSnapshot 작업은 데이터를 개별 블록 형태로, 대기 상태인 시작된 스냅샷에 추가합니다. 전송되는 데이터의 블록에 대해 Base64 인코딩 SHA256 체크섬을 지정해야 합니다. 이 서비스는 전송이 완료되고 나면 체크섬을 검증합니다. 서비스에서 계산된 체크섬이 지정한 체크섬과 일치하지 않으면 요청이 실패합니다.
• 스냅샷 완료: CompleteSnapshot 작업은 대기 상태인 시작된 스냅샷을 완료합니다. 그러면 스냅샷이 완료됨 상태로 바뀝니다.

자세한 내용은 기술 설명서를 참조하십시오.

GetSnapshotBlock 및 PutSnapshotBlock API는 512KiB 블록 크기를 지원합니다.

아니요. 스냅샷은 Amazon EC2 API를 통해서만 사용할 수 있습니다.

아니요, 스냅샷은 볼륨이 연결되어 사용되고 있는 중에도 실시간으로 실행할 수 있습니다. 그러나 스냅샷은 Amazon EBS 볼륨에 기록된 데이터만 캡처할 수 있으므로 사용자의 애플리케이션 또는 OS를 사용해 로컬로 캐싱한 데이터는 제외될 수 있습니다. 한 인스턴스에 연결된 볼륨의 스냅샷이 일관성을 유지하도록 하려면 볼륨을 완전히 분리하고 스냅샷 명령을 실행한 다음 볼륨을 다시 연결하는 것이 좋습니다. 루트 디바이스로 사용되는 Amazon EBS 볼륨의 경우 깨끗한 스냅샷을 만들려면 시스템을 종료하는 것이 좋습니다.

16TB 볼륨의 전체 EBS 스냅샷을 만드는 시간이 1TB 볼륨의 전체 스냅샷을 만드는 시간보다 오래 걸리지 않도록 설계되었습니다. 하지만 실제로 스냅샷을 만드는 데 걸리는 시간은 마지막으로 EBS 볼륨의 스냅샷을 만든 뒤에 변경된 데이터 등 여러 요인에 따라 달라집니다.

각 스냅샷에는 고유한 식별자가 지정되므로 고객은 기존 스냅샷을 기준으로 볼륨을 만들 수 있습니다.

AWS Management Console의 [Snapshots] 섹션에 있는 목록에서 [Private Snapshots]을 선택하여 본인에게 공유된 스냅샷을 찾을 수 있습니다. 이 섹션에는 본인이 보유한 스냅샷과 본인에게 공유된 스냅샷이 모두 나열됩니다.

AWS Management Console의 Snapshots 섹션에 있는 목록에서 Public Snapshots를 선택하여 전역으로 공유되는 스냅샷을 찾을 수 있습니다. 또한 EBS 스냅샷에 대해 퍼블릭 액세스 차단을 활성화하여 계정의 스냅샷에 대한 퍼블릭 액세스를 제한할 수 있습니다.

AWS Management Console을 사용하여 Amazon EBS 스냅샷에 저장된 퍼블릭 데이터 세트를 찾을 수 있습니다. 콘솔에 로그인하고, [Amazon EC2 Service]를 선택하고, [Snapshots]을 선택한 후, [Public Snapshots]으로 필터링합니다. 퍼블릭 데이터 세트에 관한 모든 정보는 AWS 퍼블릭 데이터 세트 리소스 센터에서 확인할 수 있습니다.

스냅샷에서 볼륨으로 데이터를 복원할 때 데이터 액세스의 지연 시간이 걱정되거나 초기화 중 초기 성능 히트를 피하려는 경우 스냅샷에서 FSR을 활성화해야 합니다. FSR은 VDI(가상 데스크톱 인프라), 백업 및 복원, 테스트/개발 볼륨 사본 및 사용자 지정 AMI에서 부팅 등의 사용 사례에 도움이 되도록 만들어졌습니다. 스냅샷에서 FSR을 사용하면 해당 스냅샷에서 데이터를 복원해야 할 때마다 예측 가능하며 향상된 성능을 확인할 수 있습니다.

아니요. FSR 활성 스냅샷은 스냅샷에서 볼륨으로 백업 데이터 복원을 개선합니다. FSR 활성 스냅샷이 스냅샷 생성 속도를 높이지는 않습니다.

이 기능을 사용하려면 초기화된 볼륨을 복원할 AZ(가용 영역) 내의 스냅샷에서 새 enable-fast-snapshot-restores API를 호출합니다.

FSR 활성 스냅샷은 enabling, optimizing, enabled, disabling, disabled 상태 중 하나일 수 있습니다. 상태 전환이 CloudWatch 이벤트로 게시되며 describe-fast-snapshot-restores API를 통해 FSR 상태를 확인할 수 있습니다.

스냅샷에서 FSR을 사용해도 기존 스냅샷 API 상호 작용이 변경되지 않으며 기존 워크플로를 변경할 필요도 없습니다. 계정 소유 스냅샷에서만 FSR을 활성화하거나 비활성화할 수 있습니다. 공유 스냅샷에는 FSR을 적용할 수 없습니다. API나 콘솔을 통해 FSR 활성 스냅샷의 목록을 볼 수 있습니다.

FSR 활성 스냅샷에서 만든 볼륨은 완전히 초기화됩니다. 그러나 즉시 전체 성능으로 만들 수 있는 볼륨 수에는 제한이 있습니다. 이러한 제한은 지정된 AZ의 FSR 활성 스냅샷과 연결된 크레딧 버킷의 형식으로 표현됩니다. 클라이언트에 대해 알아야 할 중요 사항:

1. 단일 볼륨 만들기 작업은 단일 크레딧을 소비합니다.
2. 크레딧 수는 FSR 활성 스냅샷 크기의 함수입니다.
3. 크레딧은 시간별로 다시 채워집니다.
4. 최대 크레딧 버킷 크기는 10입니다.

대략적인 크레딧 버킷 크기와 채우기 비율을 계산하려면 1,024를 스냅샷 크기로 나눕니다. 예를 들어, 100GiB FSR 활성 스냅샷의 최대 밸런스는 크레딧 10개이고 채우기 비율은 1시간당 크레딧 10개입니다. 4TiB 스냅샷의 최대 밸런스는 크레딧 1개이고 채우기 비율은 4시간당 크레딧 1개입니다.

크레딧 버킷 크기가 생성되는 볼륨의 크기가 아닌 FSR 활성 스냅샷 크기의 함수임을 기억해야 합니다. 예를 들어, 100GiB 스냅샷에서 한 번에 최대 10개의 1TiB 볼륨을 만들 수 있습니다.

마지막으로 스냅샷에서 FSR이 활성화된 각 AZ는 다른 AZ에 독립적인 자체 크레딧 버킷을 갖고 있습니다.

만들기 크레딧 버킷의 크기는 최대 크기를 나타내고, 크레딧 버킷의 밸런스는 사용 가능한 만들기 수를 나타냅니다. 채워진 경우 FSR 활성 스냅샷에서 한 번에 최대 10개의 초기화된 볼륨을 만들 수 있습니다. 크레딧 버킷의 최대 크기와 크레딧 버킷 밸런스는 CloudWatch 지표로 게시됩니다. 제한을 초과하여 볼륨을 만들면 스냅샷에서 FSR이 활성화되지 않은 것처럼 진행됩니다.

FSR을 사용하면 EBS 관련 속성(fastRestored)이 DescribeVolumes API에 추가되어 만드는 시점의 상태를 표시합니다. 충분한 volume-create 크레딧 없이 FSR 활성 스냅샷에서 볼륨을 만들 경우 만들기는 성공하지만 볼륨은 초기화되지 않습니다.

스냅샷을 삭제하면 스냅샷에 대한 FSR이 자동으로 비활성화되고 해당 스냅샷에 대한 FSR 요금 청구가 종료됩니다.

예. 퍼블릭 스냅샷뿐만 아니라, 귀하의 계정과 공유된 모든 프라이빗 스냅샷에 대해 FSR을 활성화할 수 있습니다. 공유된 스냅샷에 대해 FSR을 활성화하려면, 현재 가지고 있는 스냅샷에 대해 FSR을 활성화하는 데 사용하는 API 호출 집합과 동일한 집합을 사용하면 됩니다.

공유된 스냅샷에서 FSR을 활성화하면, 표준 FSR 요율로 청구됩니다(요금 페이지 참조). 귀하의 계정으로만 공유된 스냅샷의 FSR 요금이 청구됩니다. 공유된 스냅샷에서 FSR을 활성화할 경우 스냅샷 소유자에게는 요금이 청구되지 않습니다.

공유된 스냅샷 소유자가 스냅샷을 삭제하거나, 이 스냅샷에서 볼륨을 생성하는 귀하의 권한을 취소함으로써 귀하와의 스냅샷 공유를 중지하면, 공유된 스냅샷에 대한 FSR이 자동으로 비활성화되고 해당 스냅샷에 대한 FSR 요금 청구가 종료됩니다.

Amazon Data Lifecycle Manager 및 AWS Systems Manager(SSM)를 사용하여 애플리케이션 또는 데이터베이스의 고정, I/O 플러시, 고정 해제와 EBS 스냅샷의 초기화를 조정할 수 있습니다. 애플리케이션 또는 데이터베이스와 관련한 작업을 수행하는 명령을 제공해야 합니다. 또한 AWS 제공 코드에 대한 설명서와 MySQL, PostgreSQL 및 Windows 애플리케이션에 대한 SSM 문서를 참조할 수 있습니다.

Amazon EBS 암호화는 EBS 데이터 볼륨, 부팅 볼륨 및 스냅샷에 대한 원활한 암호화를 제공하므로, 보안 키 관리 인프라를 구축하고 유지 관리할 필요가 없습니다. EBS 암호화는 Amazon 관리 키 또는 AWS Key Management Service (KMS)를 사용하여 생성 및 관리하는 키로 데이터를 암호화하여 저장 데이터 보안을 활성화합니다. EC2 인스턴스를 호스팅하는 서버에서 암호화가 이루어지기 때문에, EC2 인스턴스와 EBS 스토리지 사이에서 이동하는 데이터의 암호화도 제공합니다. 자세한 내용은 Amazon EC2 사용 설명서의 Amazon EBS 암호화를 참조하십시오.

AWS KMS는 데이터 암호화에 사용되는 암호화 키를 손쉽게 생성 및 제어할 수 있는 관리형 서비스입니다. AWS Key Management Service는 Amazon EBS, Amazon S3, Amazon Redshift를 포함한 다른 AWS 서비스와 통합되어 사용자가 관리하는 암호화 키로 데이터를 간단하게 암호화할 수 있게 지원합니다. 또한, AWS Key Management Service는 AWS CloudTrail과도 통합되어 모든 키 사용에 관한 로그를 제공함으로써 각종 규제 및 규정 준수 요구사항을 충족할 수 있게 지원합니다. KMS에 대해 자세히 알아보려면 AWS Key Management Service 제품 페이지를 방문하십시오.

클라우드의 저장 데이터 암호화에 대한 보안 및 암호화 규제 준수 요구 사항을 충족하기 위해 Amazon EBS 암호화를 사용할 수 있습니다. 암호화를 기존 IAM 액세스 제어 정책과 함께 사용하면 회사의 심층방어 전략을 더욱 강화할 수 있습니다.

Amazon EBS 암호화가 대신 키 관리를 처리합니다. 새로 생성된 볼륨마다 고유한 256비트 AES 키가 있으며, 암호화된 스냅샷에서 생성된 볼륨은 해당 키를 공유합니다. 이러한 키는 강력한 논리적, 물리적 보안 제어를 구현하여 무단 액세스를 방지하는 AWS 고유의 키 관리 인프라를 통해 보호됩니다. 데이터 및 이와 연결된 키는 산업 표준 AES-256 알고리즘을 사용하여 암호화됩니다.

예.

예. AWS 관리형 또는 고객 관리형의 CMK(고객 마스터 키)를 사용하면 됩니다. BlockDeviceMapping 파라미터를 포함하는 RunInstances API 호출 또는 EC2 콘솔에서 시작 마법사를 통해 볼륨 세부 정보 및 암호화를 지정할 수 있습니다.

예. 인스턴스를 시작할 때 기본 또는 사용자 지정 CMK 암호화를 사용해 암호화된 데이터 볼륨을 생성할 수 있습니다. RunInstances API 호출에서 BlockDeviceMapping 객체를 통해 또는 EC2 콘솔에서 시작 마법사를 통해 볼륨 세부 정보 및 암호화를 지정할 수 있습니다.

예. 자세한 내용은 기술 설명서를 참조하십시오.

예. 고객이 관리하는 CMK(고객 마스터 키)를 사용하여 암호화된 스냅샷 및 AMI를 다른 AWS 계정과 공유할 수 있습니다. 자세한 내용은 기술 설명서를 참조하십시오.

예. 이제는 리전당 단일 설정을 사용하여 EBS 암호화를 기본적으로 활성화할 수 있습니다. 그리고 이렇게 하면 모든 새 볼륨이 항상 암호화됩니다. 자세한 내용은 기술 설명서를 참조하십시오. 

예. 인스턴스에서 연결 해제된 경우 프로비저닝된 IOPS에 대해 요금이 청구됩니다. 볼륨의 연결이 해제된 경우 비용을 줄이려면 스냅샷을 만들고 볼륨을 삭제하는 것이 좋습니다. 자세한 내용은 Trusted Advisor에서 "사용률이 낮은 Amazon EBS 볼륨"에 대한 비용 최적화 검사를 참조하십시오. 이 항목은 Amazon Elastic Block Store(Amazon EBS) 볼륨 구성을 검사하며 볼륨이 사용되지 않는 것으로 보이는 경우 경고합니다.

달리 명시하지 않는 한 가격에는 VAT 및 해당 판매세를 포함한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보기.

아니요. 다중 연결은 EBS의 프로비저닝된 IOPS 볼륨에서 사용할 수 있으며, 프로비저닝된 스토리지(GB-월) 및 IOPS(IOPS-월)에 대한 비용이 부과됩니다.

아니요.

볼륨의 deleteOnTermination 동작은 종료된 상태의 마지막 연결된 인스턴스의 구성으로 결정됩니다. 종료 동작에서 예측 가능한 삭제를 보장하기 위해 볼륨이 연결된 모든 인스턴스에 대해 'deleteOnTermination'을 활성화 또는 비활성화합니다.

연결된 인스턴스가 종료될 때 볼륨을 삭제하려면 볼륨이 연결된 모든 인스턴스에 대해 ‘deleteOnTermination’을 활성화합니다. 연결된 인스턴스가 종료된 후에도 볼륨을 유지하려면 연결된 모든 인스턴스에 대해 ‘deleteOnTermination’을 비활성화합니다. 자세한 내용은 다중 연결 기술 설명서를 참조하세요.

애플리케이션이 Windows Server 장애 조치 클러스터를 기반으로 구축되었거나, NVMe 예약을 사용하여 공유 스토리지에 대한 안전한 액세스를 조정하거나, 애플리케이션 수준에서 안전한 액세스를 조정하는 경우 다중 연결을 사용할 수 있습니다.