- 1 . 질문
대규모 미디어 사이트에는 Amazon ECS에서 실행되는 여러 애플리케이션이 있습니다. 솔루션 아키텍트는 콘텐츠 메타 데이터를 사용하여 트래픽을 특정 서비스로 라우팅해야합니다.
이 요구 사항을 충족하는 가장 효율적인 방법은 무엇입니까?
- 호스트 기반 라우팅 규칙과 함께 AWS Classic Load Balancer를 사용하여 트래픽을 올바른 서비스로 라우팅
- 경로 기반 라우팅 규칙과 함께 AWS Application Load Balancer를 사용하여 트래픽을 올바른 서비스로 라우팅
- Amazon CloudFront를 사용하여 트래픽을 관리하고 올바른 서비스로 라우팅
- AWS CLI를 사용하여 서비스가 업데이트 될 때 트래픽을 라우팅하도록 Amazon Route 53 호스팅 영역을 업데이트합니다.
설명:
ELB Application Load Balancer는 URL의 호스트 이름 부분과 URL의 경로를 포함하여 요청에 포함 된 데이터를 기반으로 트래픽을 라우팅 할 수 있습니다. 경로의 정보를 기반으로 트래픽을 라우팅하는 규칙을 생성하면이 솔루션에서 작동하고 ALB는 Amazon ECS에서 잘 작동합니다.
아래 다이어그램은 리스너가 URL에서 / orders로 들어오는 트래픽을 두 번째 대상 그룹으로 보내고 다른 모든 트래픽을 첫 번째 대상 그룹으로 보내는 구성을 보여줍니다.
정답 : "경로 기반 라우팅 규칙과 함께 AWS Application Load Balancer를 사용하여 트래픽을 올바른 서비스로 라우팅"하는 것이 정답입니다.
올바르지 않음 : "호스트 기반 라우팅 규칙과 함께 AWS Classic Load Balancer를 사용하여 트래픽을 올바른 서비스로 라우팅"이 올바르지 않습니다. ELB Classic Load Balancer는 호스트 또는 경로 기반을 포함한 컨텐츠 기반 라우팅을 지원하지 않습니다.
올바르지 않음 : "AWS CLI를 사용하여 Amazon Route 53 호스팅 영역을 업데이트하여 서비스가 업데이트 될 때 트래픽을 라우팅합니다."가 올바르지 않습니다. AWS CLI를 사용하여 Route 53을 업데이트하여 트래픽을 라우팅하는 방법은 작동 할 수 있지만 확실히이 문제를 해결하는 가장 효율적인 방법은 아닙니다.
올바르지 않음 : "Amazon CloudFront를 사용하여 트래픽을 관리하고 올바른 서비스로 라우팅"이 올바르지 않습니다. Amazon CloudFront에는 콘텐츠 메타 데이터를 기반으로 트래픽을 다른 Amazon ECS 서비스로 라우팅하는 기능이 없습니다.
참고 문헌 :
시험 관련 치트 시트로 시간 절약 :
- 2 . 질문
솔루션 아키텍트는 여러 Amazon EC2 인스턴스에서 실행되는 분산 데이터베이스의 아키텍처를 마무리하고 있습니다. 데이터는 모든 인스턴스에 복제되므로 인스턴스가 손실 되어도 데이터가 손실되지 않습니다. 데이터베이스에는 서버 당 초당 최대 수백만 트랜잭션을 지원하는 낮은 대기 시간과 처리량을 가진 블록 스토리지가 필요합니다.
솔루션 아키텍트는 어떤 스토리지 솔루션을 사용해야합니까?
- Amazon EBS
- Amazon EC2 인스턴스 스토어
- Amazon EFS
- 아마존 S3
설명:
인스턴스 저장소는 인스턴스 임시 블록 레벨 스토리지를 제공합니다. 이 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 있습니다. 인스턴스 스토어는 버퍼, 캐시, 스크래치 데이터 및 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 저장 또는로드 밸런싱 된 웹 서버 풀과 같은 인스턴스 집합에 복제되는 데이터에 이상적입니다.
일부 인스턴스 유형은 NVMe 또는 SATA 기반 솔리드 스테이트 드라이브 (SSD)를 사용하여 높은 임의 I / O 성능을 제공합니다. 지연 시간이 매우 짧은 스토리지가 필요하지만 인스턴스가 종료 될 때 데이터를 유지할 필요가 없거나 내결함성 아키텍처를 활용할 수있는 경우 좋은 옵션입니다.
이 시나리오에서는 데이터가 복제되고 내결함성이 있으므로 필요한 성능 수준을 제공하는 가장 좋은 방법은 인스턴스 스토어 볼륨을 사용하는 것입니다.
정답 : “Amazon EC2 인스턴스 스토어”가 정답입니다.
올바르지 않음 : “Amazon EBS”가 올바르지 않습니다. Elastic Block Store (EBS)는 블록 저장 장치이지만 데이터가 분산되고 내결함성이 있으므로 성능을위한 더 나은 옵션은 인스턴스 저장소를 사용하는 것입니다.
올바르지 않음 : "Amazon EFS"는 EFS가 블록 디바이스가 아니고 NFS 프로토콜을 사용하여 액세스되는 파일 시스템이므로 올바르지 않습니다.
잘못된 : S3는 오브젝트 기반 스토리지 시스템이 아닌 블록 기반 스토리지 시스템으로서 "아마존 S3"이 올바르지 않습니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
시험 관련 치트 시트로 시간 절약 :
- 삼 . 질문
솔루션 아키텍트는 다중 계층 서버리스 애플리케이션을위한 설계를 작성하고 있습니다. AWS 서버리스 인프라의 애플리케이션 대면 서비스를 구성하는 두 가지 서비스는 무엇입니까? (2 개를 선택하십시오.)
- AWS Cognito
- API 게이트웨이
- Amazon ECS
- Elastic Load Balancer
- AWS Lambda
설명:
여기에서 유일한 애플리케이션 서비스는 API Gateway 및 Lambda이며 이들은 서버리스 서비스로 간주됩니다.
정답 : 'API 게이트웨이'가 정답입니다.
정답 : “AWS Lambda”도 정답입니다.
올바르지 않음 : "AWS Cognito"가 올바르지 않습니다. AWS Cognito는 웹 및 모바일 앱에 대한 인증 서비스를 제공하는 데 사용됩니다.
올바르지 않음 : "Amazon ECS"가 올바르지 않습니다. ECS는 컨테이너 실행을위한 플랫폼을 제공하고 Amazon EC2 인스턴스를 사용합니다.
올바르지 않음 : "Elastic Load Balancer"가 올바르지 않습니다. ELB는 수신 네트워크 연결 배포를 제공하고 Amazon EC2 인스턴스도 사용합니다.
참고 문헌 :
https://aws.amazon.com/serverless/
시험 관련 치트 시트로 시간 절약 :
- 4 . 질문
한 회사에서 ALB (Application Load Balancer) 뒤의 Amazon EC2 Auto Scaling 그룹을 사용하여 금융 애플리케이션을 실행합니다. 매월 특정 날짜와 시간에 월말 보고서를 실행하면 응용 프로그램이 너무 느려집니다. Amazon CloudWatch 지표는 CPU 사용률이 100 %에 도달했음을 보여줍니다.
솔루션 아키텍트는 애플리케이션이 워크로드를 처리하고 다운 타임을 방지 할 수 있도록 무엇을 권장해야합니까?
- ALB 앞에 Amazon CloudFront 배포 구성
- CPU 사용률을 기반으로 EC2 Auto Scaling 단순 조정 정책 구성
- 월별 일정을 기반으로 EC2 Auto Scaling 예약 조정 정책 구성
- EC2 인스턴스에서 일부 워크로드를 제거하도록 Amazon ElastiCache 구성
설명:
예약 된 조정을 사용하면 자체 조정 일정을 설정할 수 있습니다. 이 경우 조정 작업은 매월 보고서가 실행되기 직전에 발생하도록 예약 할 수 있습니다. 크기 조정 작업은 시간 및 날짜의 함수로 자동으로 수행됩니다. 이렇게하면 수요를 처리하기에 충분한 EC2 인스턴스가 있고 애플리케이션 속도가 느려지는 것을 방지 할 수 있습니다.
정답 : "월간 일정을 기반으로 EC2 Auto Scaling 예약 조정 정책 구성"이 정답입니다.
잘못된 예 : 이 캐싱 내용으로 글로벌 사용자에 대한 액세스를 제공하는 더 적합 할 것 같은 "구성 ALB의 앞에 아마존 CloudFront를 분배"가 올바르지 않습니다.
INCORRECT : 이것은 메트릭 존재가보고 된 CPU가 100 % 안타 때 사이에 지연이있을 것으로 발생에서 다운 느리고 추가 인스턴스를 방지 할 것처럼 "구성은 CPU 사용률을 기반으로 EC2 자동 스케일링 간단한 스케일링 정책은"잘못 시작됩니다.
INCORRECT : ElastiCache는 데이터베이스 캐시와 같이 잘못 "구성 아마존 ElastiCache는 EC2 인스턴스에서 작업 부하의 일부를 제거하는"그것이 EC2 인스턴스의 컴퓨팅 기능을 대체 할 수 없습니다.
참고 문헌 :
https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html
시험 관련 치트 시트로 시간 절약 :
- 5 . 질문
솔루션 아키텍트는 주 5 일, 밤 4 시간 동안 재무 데이터에 대한 분석을 실행하는 시스템을 만들고 있습니다. 분석은 동일한 기간 동안 실행될 것으로 예상되며 일단 시작되면 중단 할 수 없습니다. 시스템은 최소 1 년 동안 필요합니다.
시스템 비용을 줄이기 위해 어떤 유형의 Amazon EC2 인스턴스를 사용해야합니까?
- 표준 예약 인스턴스
- 예약 된 예약 인스턴스
- 스팟 인스턴스
- 온 디맨드 인스턴스
설명:
정기 예약 인스턴스 (정기 인스턴스)를 사용하면 1 년 기간 동안 지정된 시작 시간과 기간으로 매일, 매주 또는 매월 반복되는 용량 예약을 구매할 수 있습니다. 용량을 미리 예약하여 필요할 때 사용할 수 있음을 알 수 있습니다. 인스턴스를 사용하지 않더라도 인스턴스가 예약 된 시간에 대해 비용을 지불합니다.
예약 된 인스턴스는 지속적으로 실행되지 않지만 정기적으로 실행되는 워크로드에 적합한 선택입니다. 예를 들어 업무 시간 동안 실행되는 애플리케이션이나 주말에 실행되는 일괄 처리에 대해 예약 된 인스턴스를 사용할 수 있습니다.
정답 : “예약 된 예약 인스턴스”가 정답입니다.
잘못된 예 : 작업 부하는 하루에 4 시간 동안 실행이 더 비싼 것처럼 "표준 예약 인스턴스는"올바르지 않습니다.
올바르지 않음 : "온 디맨드 인스턴스"는 할인이 적용되지 않으므로 훨씬 더 비싸기 때문에 올바르지 않습니다.
INCORRECT : 시작되면 작업이 중단 될 수 없기 때문에 "스팟 인스턴스는"올바르지 않습니다. 스팟 인스턴스를 사용하면 스팟 가격이 변경되거나 용량이 필요한 경우 워크로드를 종료 할 수 있습니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-scheduled-instances.html
시험 관련 치트 시트로 시간 절약 :
- 6 . 질문
VPC에 배포 할 애플리케이션에는 하드웨어 노드 장애의 영향을 줄이기 위해 별개의 기본 하드웨어에 배치해야하는 14 개의 EC2 인스턴스가 필요합니다. 인스턴스는 다양한 인스턴스 유형을 사용합니다. 비용 효율성을 고려하여 이러한 요구 사항을 충족하는 구성은 무엇입니까?
- 두 개의 AZ에서 분산 배치 그룹 사용
- 인스턴스가 배치되는 노드를 제어 할 수 없습니다.
- 전용 호스트를 사용하고 전용 호스트에 각 인스턴스를 배포합니다.
- 단일 AZ 내에서 클러스터 배치 그룹 사용
설명:
분산 배치 그룹은 각각 고유 한 기본 하드웨어에 배치되는 인스턴스 그룹입니다. 분산 배치 그룹은 서로 분리해야하는 중요 인스턴스 수가 적은 애플리케이션에 권장됩니다. 분산 배치 그룹에서 인스턴스를 시작하면 인스턴스가 동일한 기본 하드웨어를 공유 할 때 발생할 수있는 동시 오류 위험이 줄어 듭니다.
정답 : "두 개의 AZ에 분산 배치 그룹 사용"이 정답입니다.
INCORRECT : 당신이 배치 그룹을 사용할 수 있습니다로 잘못 "당신은 당신의 인스턴스에 배치 할 노드를 제어 할 수 있습니다."
올바르지 않음 : "전용 호스트를 사용하고 각 인스턴스를 전용 호스트에 배포"가 올바르지 않습니다. 각 전용 호스트에서 단일 인스턴스를 사용하는 것은 매우 비쌉니다.
올바르지 않음 : "단일 AZ 내에서 클러스터 배치 그룹 사용"이 올바르지 않습니다. 클러스터 배치 그룹은 단일 가용 영역 내에있는 인스턴스의 논리적 그룹입니다. 클러스터 배치 그룹은 낮은 네트워크 지연 시간, 높은 네트워크 처리량 또는 둘 모두의 이점을 누리는 애플리케이션 및 대부분의 네트워크 트래픽이 그룹의 인스턴스 사이에있는 경우에 권장됩니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
시험 관련 치트 시트로 시간 절약 :
- 7 . 질문
Solutions Architect는 Elastic Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행되는 웹 애플리케이션을 설계하고 있습니다. 전송중인 모든 데이터는 암호화되어야합니다.
암호화 요구 사항을 충족하는 솔루션 옵션은 무엇입니까? (2 개를 선택하십시오.)
- 패스 스루 모드에서 Application Load Balancer (ALB)를 사용한 다음 EC2 인스턴스에서 SSL 종료
- TCP 리스너와 함께 Application Load Balancer (ALB)를 사용한 다음 EC2 인스턴스에서 SSL 종료
- TCP 리스너와 함께 NLB (Network Load Balancer)를 사용한 다음 EC2 인스턴스에서 SSL 종료
- HTTPS 리스너와 함께 Application Load Balancer (ALB)를 사용한 다음 ALB 및 EC2 인스턴스에 SSL 인증서를 설치합니다.
- HTTPS 리스너와 함께 NLB (Network Load Balancer)를 사용한 다음 NLB 및 EC2 인스턴스에 SSL 인증서를 설치합니다.
설명:
NLB를 사용하여 암호화 된 트래픽을 통과하고 EC2 인스턴스에서 SSL을 종료 할 수 있으므로 이것이 유효한 대답입니다.
ALB와 함께 HTTPS 리스너를 사용하고 ALB 및 EC2 인스턴스 모두에 인증서를 설치할 수 있습니다. 이것은 패스 스루를 사용하지 않고 대신 ALB에서 첫 번째 SSL 연결을 종료 한 다음 트래픽을 다시 암호화하고 EC2 인스턴스에 연결합니다.
정답 : "TCP 리스너와 함께 NLB (Network Load Balancer)를 사용한 다음 EC2 인스턴스에서 SSL 종료"가 정답입니다.
정답 : "HTTPS 리스너와 함께 Application Load Balancer (ALB)를 사용한 다음 ALB 및 EC2 인스턴스에 SSL 인증서 설치"가 정답입니다.
올바르지 않음 : "패스 스루 모드에서 Application Load Balancer (ALB)를 사용한 다음 EC2 인스턴스에서 SSL 종료"가 올바르지 않습니다. ALB와 함께 패스 스루 모드를 사용하고 EC2 인스턴스에서 SSL을 종료 할 수 없습니다.
올바르지 않음 : "HTTPS 리스너와 함께 NLB (Network Load Balancer)를 사용한 다음 NLB 및 EC2 인스턴스에 SSL 인증서 설치"가 올바르지 않습니다. NLB와 함께 HTTPS 리스너를 사용할 수 없습니다.
올바르지 않음 : "TCP 리스너와 함께 Application Load Balancer (ALB)를 사용한 다음 EC2 인스턴스에서 SSL 종료"가 올바르지 않습니다. ALB와 함께 TCP 리스너를 사용할 수 없습니다.
참고 문헌 :
https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
시험 관련 치트 시트로 시간 절약 :
- 8 . 질문
Elastic Block Store (EBS) 볼륨이있는 Amazon EC2 인스턴스에서 새 애플리케이션이 시작됩니다. 솔루션 아키텍트는 가장 비용 효율적인 스토리지 옵션을 결정해야합니다. 이 응용 프로그램은 아침과 저녁에 두 시간 동안 트래픽이 가장 많기 때문에 자주 사용되지 않습니다. 디스크 I / O는 최대 3,000 IOPS까지 가변적입니다.
솔루션 아키텍트는 어떤 솔루션을 권장해야합니까?
- Amazon EBS Cold HDD (sc1)
- Amazon EBS 프로비저닝 된 IOPS SSD (io1)
- Amazon EBS 범용 SSD (gp2)
- Amazon EBS 처리량 최적화 HDD (st1)
설명:
범용 SSD (gp2) 볼륨은 광범위한 워크로드에 이상적인 비용 효율적인 스토리지를 제공합니다. 이러한 볼륨은 한 자릿수 밀리 초의 지연 시간과 장시간 동안 3,000 IOPS까지 버스트 할 수있는 기능을 제공합니다.
최소 100IOPS (33.33GiB 이하)와 최대 16,000IOPS (5,334GiB 이상) 사이에서 기준 성능은 볼륨 크기의 GiB 당 3IOPS로 선형 적으로 확장됩니다. AWS는 99 %의 시간 동안 프로비저닝 된 성능을 제공하도록 gp2 볼륨을 설계합니다. gp2 볼륨의 크기는 1GiB ~ 16TiB입니다.
이 경우 볼륨의 기본 성능은 3 x 200 = 600 IOPS입니다. 또한 볼륨은 오랜 기간 동안 3,000 IOPS까지 버스트 할 수 있습니다. I / O가 다양하므로 이것이 적합해야합니다.
정답 : “Amazon EBS 범용 SSD (gp2)”가 정답입니다.
올바르지 않음 : "Amazon EBS 프로비저닝 된 IOPS SSD (io1)"는 더 비싼 옵션이며이 워크로드의 성능 특성에 필요하지 않으므로 올바르지 않습니다.
올바르지 않음 : "Amazon EBS Cold HDD (sc1)"는 HDD 볼륨에 대한 IOPS SLA가없고이 워크로드에 대해 충분히 잘 수행되지 않을 가능성이 있으므로 올바르지 않습니다.
올바르지 않음 : "Amazon EBS 처리량 최적화 HDD (st1)"는 HDD 볼륨에 대한 IOPS SLA가없고이 워크로드에 대해 충분히 잘 수행되지 않을 가능성이 높기 때문에 올바르지 않습니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html
시험 관련 치트 시트로 시간 절약 :
- 9 . 질문
회사의 애플리케이션이 단일 리전의 Amazon EC2 인스턴스에서 실행되고 있습니다. 재해가 발생하는 경우 솔루션 설계자는 리소스를 두 번째 지역에도 배포 할 수 있는지 확인해야합니다.
이를 달성하기 위해 솔루션 아키텍트는 어떤 조치 조합을 취해야합니까? (2 개를 선택하십시오.)
- 두 번째 리전에서 새 EC2 인스턴스를 시작하고 Amazon S3에서 새 인스턴스로 볼륨 복사
- EC2 인스턴스에서 볼륨을 분리하고 두 번째 리전의 Amazon S3 버킷에 복사
- Amazon S3에서 Amazon Elastic Block Store (Amazon EBS) 볼륨을 복사하고 해당 EBS 볼륨을 사용하여 두 번째 리전에서 EC2 인스턴스를 시작합니다.
- 두 번째 리전의 Amazon 머신 이미지 (AMI)에서 새 EC2 인스턴스 시작
- EC2 인스턴스의 Amazon 머신 이미지 (AMI)를 복사하고 대상에 대한 두 번째 리전을 지정합니다.
설명:
CopyImage 작업을 지원하는 AWS Management Console, AWS Command Line Interface 또는 SDK 또는 Amazon EC2 API를 사용하여 AWS 리전 내부 또는 전체에서 Amazon 머신 이미지 (AMI)를 복사 할 수 있습니다.
그러면 솔루션 아키텍트는 복사 된 AMI를 사용하여 두 번째 리전의 동일한 EBS 볼륨에서 인스턴스를 시작할 수 있습니다.
참고 : AMI는 Amazon S3에 저장되지만 S3 관리 콘솔에서 보거나 S3 API를 사용하여 프로그래밍 방식으로 작업 할 수 없습니다.
정답 : “EC2 인스턴스의 Amazon 머신 이미지 (AMI)를 복사하고 대상에 대한 두 번째 리전을 지정하십시오.”가 정답입니다.
정답 : "두 번째 리전의 Amazon 머신 이미지 (AMI)에서 새 EC2 인스턴스 시작"도 정답입니다.
올바르지 않음 : "EC2 인스턴스에서 볼륨을 분리하고 두 번째 리전의 Amazon S3 버킷에 복사"가 올바르지 않습니다. EBS에서 Amazon S3로 직접 EBS 볼륨을 복사 할 수 없습니다.
올바르지 않음 : "두 번째 리전에서 새 EC2 인스턴스를 시작하고 Amazon S3에서 새 인스턴스로 볼륨 복사"가 올바르지 않습니다. Amazon S3에서 직접 EBS 볼륨을 생성 할 수 없습니다.
올바르지 않음 : "Amazon S3에서 Amazon Elastic Block Store (Amazon EBS) 볼륨을 복사하고 해당 EBS 볼륨을 사용하여 두 번째 리전에서 EC2 인스턴스 시작"이 올바르지 않습니다. Amazon S3에서 직접 EBS 볼륨을 생성 할 수 없습니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html
시험 관련 치트 시트로 시간 절약 :
- 10 . 질문
새로운 HPC (고성능 컴퓨팅) 클러스터를 배포하라는 요청을 받았습니다. 근접성, 짧은 지연 시간 및 높은 네트워크 처리량을 보장하는 EC2 인스턴스 용 설계를 생성해야합니다.
비용을 고려하면서이 요구 사항을 달성하는 데 도움이되는 AWS 기능은 무엇입니까? (2 개를 선택하십시오.)
- 전용 호스트 사용
- AZ의 하나의 프라이빗 서브넷에서 I / O 최적화 EC2 인스턴스 시작
- 향상된 네트워킹과 함께 EC2 인스턴스 사용
- 프로비저닝 된 IOPS EBS 볼륨 사용
- 배치 그룹 사용
틀 렸습니다.
설명:
새 EC2 인스턴스를 시작할 때 EC2 서비스는 모든 인스턴스가 기본 하드웨어에 분산되어 상호 관련된 장애를 최소화하는 방식으로 인스턴스를 배치하려고합니다. 배치 그룹 을 사용 하여 워크로드의 요구 사항을 충족하기 위해 상호 종속적 인 인스턴스 그룹의 배치에 영향을 줄 수 있습니다 . 워크로드 유형에 따라 다음 배치 전략 중 하나를 사용하여 배치 그룹을 생성 할 수 있습니다.
- 클러스터 – 가용 영역 내에서 인스턴스를 서로 가깝게 압축합니다. 이 전략을 사용하면 워크로드가 HPC 애플리케이션의 일반적인 노드 간 통신에 필요한 지연 시간이 짧은 네트워크 성능을 달성 할 수 있습니다.
- 파티션 – 한 파티션의 인스턴스 그룹이 다른 파티션의 인스턴스 그룹과 기본 하드웨어를 공유하지 않도록 논리 파티션에 인스턴스를 분산합니다. 이 전략은 일반적으로 Hadoop, Cassandra 및 Kafka와 같은 대규모 분산 및 복제 워크로드에서 사용됩니다.
- 확산 – 상호 관련된 장애를 줄이기 위해 별개의 기본 하드웨어에 소규모 인스턴스 그룹을 엄격하게 배치합니다.
클러스터 배치 그룹은 낮은 네트워크 대기 시간, 높은 네트워크 처리량 또는 둘 모두의 이점을 누리는 애플리케이션에 권장됩니다. 네트워크 트래픽의 대부분이 그룹의 인스턴스 사이에있을 때도 권장됩니다. 배치 그룹에 대해 가장 낮은 지연 시간과 가장 높은 초당 패킷 네트워크 성능을 제공하려면 향상된 네트워킹 을 지원하는 인스턴스 유형을 선택하십시오 .
정답 : “향상된 네트워킹과 함께 EC2 인스턴스 사용”이 정답입니다.
정답 : “배치 그룹 사용”이 정답입니다.
올바르지 않음 : "프로비저닝 된 IOPS EBS 볼륨 사용"이 올바르지 않습니다.
잘못된 예 : "는 AZ의 한 사설 서브넷에서 실행 I / O 최적화 된 EC2 인스턴스가"올바르지 않습니다. I / O 최적화 인스턴스 및 프로비저닝 된 IOPS EBS 볼륨은 네트워크 성능보다 스토리지 성능에 더 적합합니다.
올바르지 않음 : "전용 호스트 사용"이 올바르지 않습니다. 전용 호스트는 인스턴스의 근접성을 보장 할 수 있지만 비용 효율적이지 않습니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
시험 관련 치트 시트로 시간 절약 :
'AWS Associate: Solution Architect > AWS computing' 카테고리의 다른 글
| EC2 인스턴스 상태 전환 (0) | 2021.03.04 |
|---|---|
| 클라우딩 컴퓨팅 스택 종류 : IaaS, PaaS, SaaS (0) | 2021.03.02 |
| AWS Auto Scaling (0) | 2021.02.24 |
| Amazon EBS(Elastic Block Store) (0) | 2021.02.24 |
| AWS Elastic Beanstalk (0) | 2021.02.24 |
댓글