AWS Certified Solutions Architect - Associate(SAA) 오답 및 해설 2024-09-08

한 회사에서 새 Amazon EC2 인스턴스에 새 데이터베이스를 배포하고 있습니다. 이 데이터베이스의 워크로드에는 최대 20,000IOPS를 지원할 수 있는 단일 Amazon Elastic Block Store(Amazon EBS) 볼륨이 필요합니다.

이 요구 사항을 충족하는 EBS 볼륨 유형은 무엇인가요?

 

문제는 이런 상황이에요:

당신은 웹 애플리케이션에서 새로운 서버를 세팅해서, 데이터베이스를 연결하려고 해요. 근데, 이 데이터베이스가 데이터를 빠르게 읽고 쓰기 위해서 엄청나게 많은 처리량(최대 20,000 IOPS)이 필요해요. 여기서 IOPS는 초당 입력/출력 작업 수를 말하는데, 쉽게 말해 데이터에 얼마나 빨리 접근할 수 있는지를 나타내요.

 

선택지 설명:

1. 프로비저닝된 IOPS SSD (정답):
   • 최고 성능을 낼 수 있는 드라이브라고 생각하면 돼요. 64,000 IOPS까지 지원되니까, 당신이 요구하는 20,000 IOPS를 충분히 만족시켜요. 고성능 데이터 처리에 적합한 옵션이에요.
   • **프로비저닝(provisioning)**은 쉽게 말해 필요한 리소스를 미리 준비해 놓는 것을 뜻해요. 컴퓨팅 리소스, 저장소, 네트워크 등 필요한 자원을 사전에 할당하는 개념이죠.
2. 처리량 최적화 HDD:
   • 이건 느려요. 500 IOPS밖에 안 돼서, 요구사항인 20,000 IOPS와는 거리가 멀어요. 대용량 데이터를 천천히 처리하는데 적합해요.
3. 범용 SSD:
   • 범용 SSD는 보통 수준의 성능을 제공해요. 최대 16,000 IOPS까지 지원하지만, 문제에서 필요한 20,000 IOPS를 못 따라가요. 일반적인 작업에 적합하지만, 고성능이 필요한 상황에선 부족해요.
4. 콜드 HDD:
   • 이건 저비용의 느린 스토리지에요. 거의 사용하지 않는 데이터를 저장해두는 용도로 적합해요. IOPS보다는 대용량 파일을 저장하는 데 초점이 맞춰져 있어요.

요약:

당신의 데이터베이스는 빠른 속도로 많은 양의 데이터를 처리해야 하니까, 가장 빠르고 강력한 성능을 제공하는 프로비저닝된 IOPS SSD가 정답이에요.

 

---

한 회사에서 솔루션스 아키텍트에게 기존 온프레미스 애플리케이션에 대한 파일럿 라이트 재해 복구(DR) 전략을 구현하도록 요청합니다. 애플리케이션은 독립적으로 실행되며 데이터베이스에 액세스할 필요가 없습니다.

다음 중 파일럿 라이트 DR 전략을 구현하는 솔루션은 무엇입니까?

 

 

이 문제에서 정답은 B. Amazon EC2 인스턴스를 사용하여 AWS에 애플리케이션 호스팅 환경을 다시 생성하고 EC2 인스턴스를 중지하는 옵션입니다. 파일럿 라이트 DR 전략과 다른 선택지가 왜 오답인지 쉽게 풀어서 설명해볼게요.

정답:

B. Amazon EC2 인스턴스를 사용하여 AWS에 애플리케이션 호스팅 환경을 다시 생성하고 EC2 인스턴스를 중지

• 파일럿 라이트 DR 전략의 핵심은 AWS에 미리 중요한 인프라를 준비해 두고, 평소에는 최소한의 리소스만 실행시키며, 문제가 발생할 때만 전체 시스템을 가동하는 방식이에요.
• 즉, 미리 AWS에 애플리케이션 환경을 설정해두고, 장애가 생기면 EC2 인스턴스를 빠르게 켜서 애플리케이션을 정상적으로 돌리면 돼요. 복구 시간도 짧고, 비상시에만 자원을 사용해서 비용도 절감할 수 있어요.

오답:

A. 온프레미스 애플리케이션, 구성 및 데이터를 Amazon S3 버킷에 백업

• 이건 백업 및 복원 DR 전략이에요. S3에 데이터를 백업하는 건 좋지만, 장애가 발생하면 AWS에서 새 환경을 구축하고 데이터를 복원하는 데 시간이 오래 걸려요. 복구 시간이 몇 시간에서 며칠 걸릴 수 있어요. 비용은 적지만 속도가 느려서 긴급 상황에 적합하지 않아요.

C. EC2 인스턴스에서 애플리케이션 트래픽의 10%를 처리

• 이건 웜 스탠바이 DR 전략이에요. 이미 AWS에서 애플리케이션의 일부 트래픽을 처리하고 있어서 장애가 발생하면 바로 전체 트래픽을 AWS로 넘길 수 있지만, 리소스가 계속 실행 중이라 비용이 높아요. 파일럿 라이트보다는 비용이 더 들지만 복구는 빠릅니다.

D. 온프레미스 환경을 다시 구축하고 S3에서 복원

• 이 역시 백업 및 복원 DR 전략이에요. 온프레미스 인프라를 다시 설정하고 S3에서 데이터를 복원하는 건 시간이 오래 걸려요. 온프레미스 환경에서 복구하는 데 시간이 많이 소요되므로 긴급한 상황에서는 부적합해요.

요약:

파일럿 라이트 DR 전략은 AWS에 미리 애플리케이션을 설정해 두고, 문제가 생기면 빠르게 가동하는 방법이에요. 필요한 리소스만 최소한으로 유지하면서도, 빠르게 복구할 수 있어서 비용 절감과 속도를 모두 고려한 방식입니다.

 

---

엄격한 데이터 보호 요구 사항이 있는 한 회사가 있습니다. 솔루션스 아키텍트는 인터넷에서 백엔드 Amazon RDS DB 인스턴스에 액세스할 수 없도록 VPC에 대한 보안을 구성해야 합니다. 또한 솔루션스 아키텍트는 애플리케이션 티어에서 지정된 포트를 통해서만 DB 인스턴스에 액세스할 수 있는지 확인해야 합니다.

솔루션스 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 조치를 취해야 하나요? (정답은 2개입니다.)

 

이 문제의 정답은 A. DB 인스턴스를 프라이빗 서브넷에 배치와 E. 애플리케이션 티어의 요청을 허용하는 인바운드 규칙을 설정입니다. 이제 각각의 이유와 다른 선택지가 왜 오답인지 쉽게 설명해볼게요.

정답:

A. DB 인스턴스에 대한 프라이빗 서브넷만 포함하는 DB 서브넷 그룹을 지정

• 프라이빗 서브넷은 인터넷과 연결되지 않은 내부 네트워크 공간이에요. 데이터베이스를 프라이빗 서브넷에 배치하면 외부에서 직접 접근할 수 없게 되기 때문에, 보안이 강화돼요. 인터넷으로부터 DB를 보호하는 첫 번째 조치입니다.

E. 애플리케이션 티어의 보안 그룹에서 특정 포트를 통한 인바운드 요청 허용

• 보안 그룹은 네트워크의 방화벽 역할을 해요. 여기서는 데이터베이스 포트에 대해서만 애플리케이션 티어에서 들어오는 요청을 허용하고, 그 외의 트래픽은 차단하는 방식으로 설정해요. 이를 통해 애플리케이션에서만 DB에 접근할 수 있게 하고, 허용되지 않은 트래픽을 막아 보안을 강화할 수 있어요.

오답:

B. 프라이빗 IPv4 주소를 사용한 탄력적 네트워크 인터페이스 연결

• **탄력적 네트워크 인터페이스(ENI)**는 네트워크 설정을 유연하게 변경할 수 있게 도와주는 도구이지만, 여기서는 DB 인스턴스를 보호하는 방법과 직접적인 관련이 없어요. 네트워크 카드와 관련된 기능일 뿐, DB 보안을 크게 향상시키지 않습니다.

C. VPC에서 AWS Shield를 구성하고 서브넷의 라우팅 테이블 업데이트

• AWS Shield는 DDoS(분산 서비스 거부) 공격을 막는 서비스지만, 라우팅 테이블과 관련된 설정은 이 문제에서 요구하는 데이터베이스 보안과는 거리가 있어요. DDoS 공격에 대한 보호는 DB 액세스 제어와 관련이 없어요.

D. Direct Connect 연결 구성

• AWS Direct Connect는 온프레미스 데이터 센터와 AWS 클라우드 간에 전용 네트워크 연결을 제공하는 서비스에요. 하지만 문제에서는 애플리케이션과 DB 간의 액세스 제어에 대해 묻고 있으며, Direct Connect는 여기서 요구하는 보안 문제와 관련이 없어요.

요약:

• 프라이빗 서브넷에 DB를 배치하면 외부에서 접근할 수 없어서 보안이 강화됩니다.
• 보안 그룹 규칙을 통해 애플리케이션 티어만 DB에 접근할 수 있도록 특정 포트를 제한하면 보안이 더 높아져요.

이 두 가지 조치가 인터넷 접근 차단과 애플리케이션만 접근 가능하도록 제한하는 보안 요구 사항을 충족시키는 방법입니다.

 

 

---

한 회사에서 Amazon CloudFront 배포를 위한 원본으로 구성된 Application Load Balancer를 사용하여 Amazon EC2 인스턴스에서 웹 사이트를 실행합니다. 이 회사는 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격으로부터 보호하려고 합니다.

이러한 요구 사항을 충족하기 위해 솔루션스 아키텍트가 추천해야 하는 접근 방식은 무엇인가요?

이 문제에서 정답은 D. CloudFront 배포에서 AWS WAF를 설정하고 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하는 조건 및 규칙을 사용입니다. 각 선택지가 왜 정답 또는 오답인지 자세히 설명해볼게요.

정답:

D. CloudFront 배포에서 AWS WAF를 설정하고 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하는 조건 및 규칙을 사용

• **AWS WAF(Web Application Firewall)**는 웹 애플리케이션을 보호하는 데 사용되는 서비스로, **크로스 사이트 스크립팅(XSS)**이나 SQL 삽입과 같은 악의적인 공격을 감지하고 차단할 수 있어요.
• WAF를 CloudFront와 함께 사용하면, 웹 트래픽을 필터링하고 보안 규칙을 설정하여 이런 종류의 공격을 방어할 수 있습니다.
• 따라서, WAF를 사용해 해당 요구 사항을 가장 잘 충족시킬 수 있어요.

오답:

A. AWS Shield Advanced를 활성화하고 CloudFront 배포를 보호된 리소스로 나열

• AWS Shield Advanced는 DDoS(분산 서비스 거부) 공격으로부터 보호하는 서비스입니다. 하지만 **크로스 사이트 스크립팅(XSS)**이나 SQL 삽입 공격을 방어하지는 않아요.
• Shield는 트래픽 볼륨을 기반으로 한 공격에 집중하기 때문에, XSS나 SQL 삽입 같은 애플리케이션 계층의 공격에는 적합하지 않습니다.

B. AWS Firewall Manager에서 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하도록 AWS Shield Advanced 정책을 정의

• AWS Firewall Manager는 여러 계정과 리소스에서 WAF, Shield Advanced 등을 중앙에서 관리할 수 있는 도구예요. 그러나 여기서도 Shield Advanced는 DDoS 방어에만 집중하므로 XSS나 SQL 삽입에 대한 방어는 제공하지 않습니다.
• 따라서 Firewall Manager 자체는 이런 요구 사항을 해결하지 못해요.

C. EC2 인스턴스에 AWS Firewall Manager를 배포하고 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하는 조건 및 규칙을 생성

• AWS Firewall Manager는 AWS 관리형 서비스로, EC2 인스턴스에 설치하는 방식이 아닙니다. 또한 Firewall Manager는 AWS WAF나 Shield Advanced 같은 도구를 관리하는 용도이기 때문에, 이 방식으로는 직접적인 보안을 제공할 수 없어요.
• 이 옵션은 기술적으로 잘못된 방식입니다.

요약:

• AWS WAF는 크로스 사이트 스크립팅(XSS) 및 SQL 삽입 공격을 막을 수 있는 도구로, 문제의 요구 사항을 가장 적절하게 충족합니다.
• 다른 서비스들, 특히 AWS Shield Advanced는 주로 DDoS 공격 방어에 초점을 맞추고 있어, 애플리케이션 계층에서 발생하는 보안 문제(예: XSS, SQL 삽입)를 해결하는 데 적합하지 않습니다

---

한 회사가 EC2 Auto Scaling 그룹의 일부인 대규모 범용 Amazon EC2 인스턴스 유형에서 실행되는 애플리케이션을 보유하고 있습니다. 이 회사는 이 애플리케이션과 관련된 향후 비용을 줄이려고 합니다. 회사는 Amazon CloudWatch의 지표와 로그를 검토한 후, 애플리케이션이 무작위로 하루에 수회 실행되어 데이터를 검색하고 관리한다는 사실을 알게 되었습니다. CloudWatch에 따르면 각 요청의 최대 런타임은 10분이고 메모리 사용량은 4GB이며 인스턴스는 항상 실행 상태입니다.

 

 

 

이 문제에서 가장 비용을 절감할 수 있는 솔루션은 B. 애플리케이션 코드를 리팩터링하여 AWS Lambda 함수로 실행입니다. 각 선택지에 대해 설명해 드릴게요.

정답:

B. 애플리케이션 코드를 리팩터링하여 AWS Lambda 함수로 실행합니다.

• AWS Lambda는 서버리스 컴퓨팅 서비스로, 요청이 있을 때만 실행되며 실행 시간이 끝나면 자동으로 종료됩니다. 이 애플리케이션은 짧은 시간 동안 불규칙하게 실행되므로, 항상 실행 상태인 EC2 인스턴스를 사용하는 것보다 Lambda로 리팩터링하면 비용을 크게 절감할 수 있습니다. Lambda는 필요한 만큼만 실행되기 때문에 EC2 인스턴스 상시 실행으로 발생하는 불필요한 비용을 절감할 수 있습니다.

오답:

A. 용량 확장이 가능한 대규모 EC2 인스턴스에 애플리케이션을 배포합니다.

• EC2 인스턴스는 항상 실행 상태여야 하므로 비용 절감에 효과적이지 않습니다. 사용량이 불규칙한 경우에는 EC2 인스턴스 상시 실행이 불필요한 비용을 초래할 수 있습니다.

C. Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하여 애플리케이션을 컨테이너화합니다. EC2 인스턴스에서 컨테이너를 호스팅합니다.

• EKS는 애플리케이션을 컨테이너화할 수 있지만, EC2 인스턴스가 상시 실행되어야 하므로 비용 절감에는 적합하지 않습니다. 이 경우 컨테이너화로 얻는 이점이 크지 않고, 서버리스 아키텍처가 더 나은 선택입니다.

D. AWS Instance Scheduler를 사용하여 로그의 런타임을 기반으로 인스턴스를 시작 및 중지합니다.

• Instance Scheduler는 미리 정의된 시간에 맞춰 인스턴스를 시작/중지하는 방식이므로, 무작위로 실행되는 애플리케이션에는 적합하지 않습니다. 이 솔루션은 정확한 실행 시간을 예측할 수 없을 때 효과적이지 않으며, 인스턴스를 너무 자주 시작/중지하면 비용 절감 효과가 미미할 수 있습니다.

요약:

Lambda는 필요할 때만 실행되고 짧은 실행 시간에 적합한 서버리스 서비스이기 때문에, 이 시나리오에서 비용을 가장 절감할 수 있습니다.

 

---

한 회사에서 애플리케이션 계층과 온라인 트랜잭션 처리(OLTP) 관계형 데이터베이스로 구성될 새 애플리케이션을 배포하고 있다. 이 애플리케이션은 항상 사용 가능해야 한다. 하지만 애플리케이션에는 예측할 수 없는 트래픽 패턴이 존재할 수 있다. 회사는 이러한 유휴 기간 동안 발생하는 컴퓨팅 비용을 최소화하고자 한다.

다음 중 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇인가?

 

 

이 문제에서 가장 비용 효율적인 솔루션은 D. AWS Fargate에서 Amazon Elastic Container Service(Amazon ECS)를 사용하는 컨테이너를 통해 애플리케이션을 실행한다. 데이터베이스에 Amazon Aurora Serverless를 사용한다입니다.

정답:

D. AWS Fargate에서 Amazon ECS를 사용하는 컨테이너를 통해 애플리케이션을 실행하고, 데이터베이스에 Amazon Aurora Serverless를 사용합니다.

• AWS Fargate는 서버리스 컨테이너 서비스로, 애플리케이션이 실행 중일 때만 리소스를 사용하므로, 유휴 상태일 때 발생하는 비용을 최소화할 수 있습니다.
• Amazon Aurora Serverless는 자동으로 확장하고, 유휴 상태일 때는 비용이 발생하지 않으므로, 트래픽 패턴이 예측 불가능한 환경에서도 효율적인 비용 관리가 가능합니다. 이 솔루션은 필요할 때만 리소스를 사용하고, 유휴 시간에는 비용을 줄일 수 있기 때문에 비용 효율적입니다.

**ECS (Amazon Elastic Container Service)**는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스입니다. ECS를 사용하면 컨테이너화된 애플리케이션을 쉽게 배포, 관리, 확장할 수 있습니다. 사용자가 관리하는 EC2 인스턴스 또는 AWS에서 제공하는 서버리스 방식으로 컨테이너를 실행할 수 있습니다.

Fargate는 ECS나 EKS에서 컨테이너를 실행할 때, 서버를 관리할 필요 없이 자동으로 리소스를 할당하는 서버리스 컴퓨팅 엔진입니다. 즉, 인프라 관리 없이 애플리케이션의 컨테이너만 실행하면 되며, AWS가 필요한 컴퓨팅 자원을 자동으로 관리해줍니다. 이를 통해 유휴 리소스 비용을 줄이고, 서버 관리 부담을 덜 수 있습니다.

오답:

A. 버스트 가능 인스턴스 유형을 사용하여 Amazon EC2 인스턴스에서 애플리케이션을 실행한다. 데이터베이스에 Amazon Redshift를 사용한다.

• EC2 버스트 가능 인스턴스는 트래픽이 증가할 때만 성능이 일시적으로 향상되지만, 트래픽이 적을 때도 유휴 리소스 비용이 발생합니다. 또한, Amazon Redshift는 OLTP 용도가 아닌 OLAP(온라인 분석 처리)에 최적화되어 있어 적합하지 않습니다.

B. AWS CloudFormation을 사용하여 Amazon EC2 인스턴스에 애플리케이션과 MySQL 데이터베이스를 배포한다. 유휴 기간이 시작될 때 인스턴스를 삭제한다.

• CloudFormation은 인프라를 자동으로 관리할 수 있지만, 유휴 상태에서 인스턴스를 삭제하는 것은 항상 사용 가능해야 하는 요구 사항에 부합하지 않으며, 데이터베이스 삭제 시 데이터 손실 위험이 있습니다.

C. Application Load Balancer 기반의 Auto Scaling 그룹에 속한 Amazon EC2 인스턴스에서 애플리케이션을 배포한다. 데이터베이스에 Amazon RDS for MySQL을 사용한다.

• 이 솔루션은 Auto Scaling을 통해 트래픽에 따라 인스턴스를 동적으로 조정할 수 있지만, 항상 최소한 하나의 EC2 인스턴스와 RDS 인스턴스가 실행되어야 하므로 유휴 시간 동안 비용 절감이 어렵습니다.

요약:

AWS Fargate와 Amazon Aurora Serverless 조합은 트래픽 변화에 유연하게 대응할 수 있으며, 유휴 상태에서는 비용이 거의 발생하지 않으므로 비용 효율성 면에서 가장 적합한 선택입니다.

 

단점으로 Cold Start Latency (냉시작 지연), 비용 예측의 어려움, 컨테이너 상태 관리, 데이터베이스 연결 제한 등이 있을 수 있음

 

---

한 회사가 Amazon EC2 기반 MariaDB 데이터베이스를 Amazon RDS로 전환하고 있다. 이 회사는 자사의 CPU 및 메모리 요구 사항을 충족할 데이터베이스 인스턴스 유형을 이미 파악했다. 데이터베이스는 최소 40GiB의 스토리지 용량과 1,000IOPS를 제공해야 한다.

다음 중 가장 비용 효율적인 Amazon RDS for MariaDB 인스턴스 스토리지 구성은 무엇인가?

 

여기서 주어진 요구 사항에 맞는 가장 비용 효율적인 Amazon RDS for MariaDB 인스턴스 스토리지 구성은 다음과 같습니다:

정답: B

RDS 인스턴스에 50GiB의 범용 SSD(gp3) 스토리지를 프로비저닝한다.

이유:

• 범용 SSD(gp3) 스토리지는 IOPS를 볼륨 크기와 관계없이 3,000 IOPS를 지원합니다.
• 이 스토리지 타입은 IOPS와 스토리지 용량의 관계가 단순하여 예측 가능한 비용을 제공합니다.
• 비용 효율적으로 높은 IOPS를 지원하며, 필요한 1,000 IOPS를 초과하는 성능을 제공하면서도 추가 비용이 발생하지 않습니다.

오답 이유:

• A (350GiB의 마그네틱 스토리지): 마그네틱 스토리지는 IOPS를 직접적으로 프로비저닝할 수 없으며, 성능이 일관되지 않아서 요구 사항을 충족할 수 없습니다.
• C (334GiB의 범용 SSD(gp2) 스토리지): gp2는 IOPS가 볼륨 크기에 따라 비례하여 증가하며, 필요한 1,000 IOPS를 만족시키기 위해 334GiB의 스토리지가 필요합니다. 이는 gp3보다 더 비쌉니다.
• D (1,000IOPS의 50GiB 프로비저닝된 IOPS 스토리지): 프로비저닝된 IOPS 스토리지는 IOPS를 정확히 제공하지만, gp3 스토리지보다 비용이 비쌉니다.

---

최소 5년 동안 데이터 레코드를 유지 관리해야 하는 한 회사가 있습니다. 데이터는 저장된 후에 거의 액세스되지 않습니다. 데이터는 2시간 이내에 액세스할 수 있어야 합니다.

 

이러한 요구 사항을 가장 비용 효율적으로 충족할 수 있는 솔루션은 무엇인가요?

 

 

이 시나리오에서 요구 사항에 가장 적합한 솔루션은 Amazon S3와 S3 Glacier Instant Retrieval입니다.

정답: D

Amazon S3 버킷에 데이터를 저장하고 S3 수명 주기 정책을 사용하여 데이터를 S3 Glacier Instant Retrieval로 이동합니다.

이유:

• Amazon S3는 데이터 저장을 위한 경제적이고 확장 가능한 기본 스토리지 솔루션을 제공합니다.
• S3 Glacier Instant Retrieval은 데이터가 거의 액세스되지 않지만 2시간 이내에 액세스해야 하는 경우에 적합한 비용 효율적인 아카이브 스토리지 솔루션입니다.
• 이 조합은 데이터 보관과 접근 요구 사항을 충족하며, 비용을 최적화합니다.

오답 이유:

• A (Amazon EFS와 AWS Direct Connect): Amazon EFS는 파일 시스템 접근을 필요로 할 때 유용하지만, 장기 데이터 보관과 비용 효율성 측면에서 S3보다 비쌉니다. AWS Direct Connect는 네트워크 연결을 위한 옵션일 뿐, 데이터 보관과는 직접적인 연관이 없습니다.
• B (Amazon EBS와 스냅샷): EBS는 일반적으로 블록 스토리지로 사용되며, 스냅샷을 S3로 이동하더라도 EBS는 비용 효율적인 데이터 장기 보관 솔루션이 아닙니다. S3와 비교할 때 비싼 옵션입니다.
• C (S3 Standard-IA): S3 Standard-IA는 데이터가 자주 액세스되지 않는 경우에 적합하지만, 더 긴 검색 시간이 필요한 경우에 비해 비용 효율적인 선택이 아닙니다. S3 Glacier Instant Retrieval이 이러한 요구 사항을 더 잘 충족합니다.

---

 

위성 이미지를 처리하는 한 회사에 AWS에서 실행되는 애플리케이션이 있습니다. 이 회사에서는 Amazon S3 버킷에 이미지를 저장합니다. 규정 준수를 위해 이 회사는 한 달에 한 번 모든 데이터를 온프레미스 위치로 복제해야 합니다. 회사에서 전송해야 하는 평균 데이터 양은 60TB입니다.

이 데이터를 전송하는 가장 비용 효율적인 방법은 무엇인가요?

 

 

위성 이미지를 온프레미스 위치로 전송하는 가장 비용 효율적인 방법은 AWS Snowball Edge Storage Optimized 디바이스를 사용하는 것입니다.

정답: A

기존 S3 버킷에서 AWS Snowball Edge Storage Optimized 디바이스로 매월 데이터를 내보냅니다. 그런 다음 온프레미스 위치로 디바이스를 배송하고 데이터를 전송합니다. 일주일 후에 디바이스를 반환합니다.

이유:

• AWS Snowball Edge Storage Optimized는 대용량 데이터 전송을 위해 설계된 장비로, 60TB의 데이터를 경제적으로 전송하는 데 적합합니다.
• Snowball Edge는 데이터 전송 비용을 줄이는 데 도움을 주며, 온프레미스 위치로 데이터를 직접 전송할 수 있어 비용을 절감할 수 있습니다.

오답 이유:

• B (S3 버킷 복제와 AWS Storage Gateway File Gateway 사용): S3 버킷 복제는 추가 비용이 발생하며, AWS Storage Gateway는 온프레미스와 클라우드 간 데이터 전송에 대한 추가 비용이 발생할 수 있습니다. Snowball Edge는 이러한 전송과 관련된 비용을 줄일 수 있습니다.
• C (S3 버킷 복제와 S3 데이터 전송): S3 Standard-IA 스토리지를 사용하는 새 버킷으로 복제한 후 온프레미스 위치로 전송하는 것은 추가 복제와 전송 비용이 발생하며, Snowball Edge는 이러한 복제와 전송을 효율적으로 처리할 수 있습니다.
• D (CloudFront 배포): CloudFront는 데이터 전송을 위한 캐싱과 배포 네트워크를 제공하지만, 대량의 데이터를 온프레미스 위치로 전송하는 데 드는 비용이 Snowball Edge보다 훨씬 더 비쌀 수 있습니다.

Snowball Edge는 대량의 데이터 전송을 위한 경제적이고 효율적인 솔루션을 제공합니다.

 

 

---

한 회사가 하나의 AWS 계정을 사용하여 프로덕션 워크로드를 실행한다. 이 회사는 별도의 보안 팀용 AWS 계정을 가지고 있다. 보안 팀은 프로덕션 워크로드를 실행하는 AWS 계정의 특정 계정 설정 및 리소스 구성을 정기 감사 중에 확인해야 한다. 솔루션스 아키텍트는 AWS 보안 모범 사례를 따르는 솔루션을 설계하여 보안 팀에 필요한 액세스 권한을 제공해야 한다.

다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

 

정답: B 프로덕션 계정에 IAM 역할을 생성한다. 보안 팀에서 요구하는 권한을 제공하는 권한 정책을 연결한다. 보안 팀 계정을 신뢰 정책에 추가한다.

 

이유:

• IAM 역할과 신뢰 정책을 사용하는 것은 AWS의 보안 모범 사례를 따릅니다. 이 접근 방식은 보안 팀이 필요할 때만 프로덕션 계정의 리소스에 접근할 수 있도록 허용하며, 권한을 세밀하게 제어할 수 있습니다.
• 역할을 사용하면 최소 권한 원칙을 유지하며, 보안 팀이 필요한 권한만을 임시로 부여받아 접근할 수 있도록 합니다. 이를 통해 장기적으로 불필요한 권한 부여를 피할 수 있습니다.

오답 이유:

• A (IAM 사용자 생성 및 권한 부여): IAM 사용자를 직접 생성하여 권한을 부여하는 방식은 보안 모범 사례를 따르지 않으며, 역할을 사용하여 권한을 위임하는 방식보다 관리가 어렵습니다.
• C (IAM 사용자에 관리 권한 부여): IAM 사용자에게 관리 권한을 부여하는 것은 보안 원칙에 어긋나며, 관리 권한은 최소한으로 유지해야 합니다.
• D (IAM 사용자와 IAM 그룹을 통한 권한 부여): IAM 그룹을 사용하는 방식은 역할을 사용하는 방식보다 세밀한 권한 관리가 어려울 수 있으며, 역할을 사용하는 방법이 더 적합합니다.

이 솔루션은 AWS에서 보안 및 권한 관리의 모범 사례를 따르며, 보안 팀이 프로덕션 환경에 안전하고 효율적으로 접근할 수 있도록 합니다.

 

---

보고 애플리케이션이 Application Load Balancer 기반의 Amazon EC2 인스턴스에서 실행된다. 인스턴스는 다수의 가용 영역에 속한 Amazon EC2 Auto Scaling 그룹에서 실행된다. 복잡한 보고서의 경우 애플리케이션이 요청에 응답하는 데 최대 15분이 걸릴 수 있다. 한 솔루션스 아키텍트가 축소 이벤트 중에 보고서 요청이 처리될 경우 사용자에게 HTTP 5xx 오류가 발생할 수 있다는 점을 우려하고 있다.

 

인스턴스 종료 전에 사용자 요청이 완료되도록 하려면 솔루션스 아키텍트는 어떻게 해야 하는가?

 

 

정답: D 대상 인스턴스 그룹의 등록 취소 지연의 제한 시간을 900초보다 크게 늘린다.

이유:

• 등록 취소 지연(deregistration delay)은 인스턴스가 Auto Scaling 그룹에서 종료되기 전에 인스턴스에서 진행 중인 요청을 완료할 수 있도록 대기하는 시간을 설정합니다. 기본값은 300초(5분)이며, 이를 900초(15분)으로 늘리면 요청이 완료될 때까지 인스턴스를 계속 유지하여 사용자에게 HTTP 5xx 오류가 발생하지 않도록 할 수 있습니다.
• 이 설정을 통해 인스턴스 종료 전에 진행 중인 요청이 완료될 시간을 확보하여 사용자 요청이 성공적으로 처리될 수 있도록 보장합니다.

오답 이유:

• A (스티키 세션 사용): 스티키 세션은 동일한 사용자 요청을 동일한 인스턴스로 라우팅하지만, 인스턴스가 종료되기 전에 진행 중인 요청을 완료하도록 보장하지는 않습니다.
• B (인스턴스 크기 증가): 인스턴스 크기를 늘리는 것은 요청 처리 속도를 개선할 수 있지만, 인스턴스 종료 전 진행 중인 요청을 완료하는 문제를 직접적으로 해결하지는 않습니다.
• C (휴지 기간 연장): 휴지 기간은 인스턴스가 종료되기 전에 추가 인스턴스를 시작하거나 종료할 때의 영향을 관리하는데, 요청 완료 보장을 위한 등록 취소 지연과는 관련이 없습니다.

등록 취소 지연을 적절히 설정하면, 애플리케이션이 사용자 요청을 처리하는 동안 인스턴스 종료로 인한 서비스 중단을 방지할 수 있습니다.

 

---

한 회사에서 AWS에 배포할 채팅 애플리케이션을 개발하고 있습니다. 이 애플리케이션은 키 값 데이터 모델을 사용하여 메시지를 저장합니다. 일반적으로 사용자 그룹은 메시지를 여러 번 읽습니다. 솔루션스 아키텍트는 높은 비율의 읽기를 지원하도록 확장되고 마이크로초 단위 대기 시간으로 메시지를 전달하는 데이터베이스 솔루션을 선택해야 합니다.

 

이러한 요구 사항을 충족하는 데이터베이스 솔루션은 무엇인가요?

 

 

 

정답: B DynamoDB Accelerator(DAX)가 포함된 Amazon DynamoDB

이유:

• Amazon DynamoDB는 키-값 데이터 모델을 지원하는 NoSQL 데이터베이스로, 높은 읽기 성능을 제공합니다.
• **DynamoDB Accelerator (DAX)**는 DynamoDB의 인메모리 캐싱 서비스로, 마이크로초 단위의 응답 시간을 제공합니다. 이는 높은 비율의 읽기 작업을 처리하는 데 매우 적합합니다.
• 이 조합은 메시지를 빠르게 읽어야 하는 요구 사항을 충족하며, 대기 시간을 최소화할 수 있습니다.

오답 이유:

• A (Aurora 복제본이 포함된 Amazon Aurora): Aurora는 관계형 데이터베이스이며, 키-값 데이터베이스 모델을 사용하지 않습니다. 또한, 마이크로초 단위의 대기 시간을 제공하지 않습니다.
• C (Amazon ElastiCache for Memcached가 포함된 Amazon Aurora): Aurora는 여전히 관계형 데이터베이스로, ElastiCache를 사용하더라도 마이크로초 단위 대기 시간을 일관되게 제공하기 어렵습니다.
• D (Amazon ElastiCache for Memcached가 포함된 Amazon Neptune): Neptune은 그래프 데이터베이스로, 키-값 데이터베이스에 최적화되어 있지 않으며, ElastiCache를 사용하더라도 요구하는 대기 시간을 보장하기 어렵습니다.

DynamoDB와 DAX의 조합은 키-값 모델을 지원하고 마이크로초 단위의 대기 시간을 제공하므로, 이 시나리오에 가장 적합한 솔루션입니다.