안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
한 회사가 AWS에서 2계층 웹 애플리케이션을 개발하고 있습니다.
이 회사의 개발자는 백엔드 Amazon RDS 데이터베이스에 직접 연결되는 Amazon EC2 인스턴스에 애플리케이션을 배포했습니다.
회사는 애플리케이션에 데이터베이스 자격 증명을 하드코딩해서는 안 됩니다.
또한 회사는 정기적으로 데이터베이스 자격 증명을 자동으로 교체하는 솔루션을 구현해야 합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 인스턴스 메타데이터에 데이터베이스 자격 증명을 저장합니다. Amazon EventBridge(Amazon CloudWatch Events) 규칙을 사용하여 RDS 자격 증명과 인스턴스 메타데이터를 동시에 업데이트하는 예약된 AWS Lambda 함수를 실행합니다.
B. 암호화된 Amazon S3 버킷의 구성 파일에 데이터베이스 자격 증명을 저장합니다. Amazon EventBridge(Amazon CloudWatch Events) 규칙을 사용하여 RDS 자격 증명과 구 성 파일의 자격 증명을 동시에 업데이트하는 예약된 AWS Lambda 함수를 실행합니다. S3 버전 관리를 사용하여 이전 값으로 폴백할 수 있습니다.
C. 데이터베이스 자격 증명을 AWS Secrets Manager에 비밀로 저장합니다. 보안 비밀에 대해 자동 회전을 켭니다. 암호에 대한 액세스 권한을 부여하려면 EC2 역할에 필요한 권한을 연결합니다.
D. 데이터베이스 자격 증명을 AWS Systems Manager Parameter Store에 암호화된 파라미터로 저장합니다. 암호화된 매개변수에 대해 자동 회전을 켭니다. 암호화된 매개변수에 대 한 액세스 권한을 부여하려면 필요한 권한을 EC2 역할에 연결하십시오.
풀이
AWS Secrets Manager를 사용하여 데이터베이스 자격 증명을 안전하게 저장하고 자동으로 회전시킬 수 있습니다. EC2 인스턴스 역할을 통해 Secrets Manager에 대한 액세스 권한을 부여하면 인스턴스에서 자격 증명을 쉽게 검색할 수 있어 운영 오버헤드를 최소화할 수 있습니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 웹 애플리케이션에 데이터베이스 자격 증명을 하드코딩하지 않아야 함
- 데이터베이스 자격 증명을 정기적으로 자동 교체
2. 관련 AWS 서비스 생각하기
- AWS Secrets Manager는 데이터베이스 자격 증명, API 키, OAuth 토큰과 같은 민감한 정보를 안전하게 저장하고 관리하기 위해 특별히 설계된 서비스입니다. 가장 큰 장점은 자격 증명의 자동 교체 기능이 기본적으로 내장되어 있다는 점입니다. 데이터베이스 자격 증명의 경우, AWS Secrets Manager는 자동으로 암호를 업데이트하고 관련된 데이터베이스도 함께 업데이트할 수 있습니다. 또한 EC2 인스턴스 역할을 통해 필요한 권한만 부여하여 안전하게 자격 증명을 검색할 수 있어, 운영 팀의 수동 개입을 최소화할 수 있습니다.
- AWS Systems Manager Parameter Store는 구성 데이터, 암호화된 문자열 등을 저장하는 데 적합한 서비스입니다. 암호화된 파라미터를 저장할 수는 있지만, 자동 교체 기능은 기본으로 제공하지 않습니다. 자격 증명을 교체하려면 추가적인 Lambda 함수나 다른 자동화 메커니즘을 구현해야 하며, 이는 운영 오버헤드를 증가시킬 수 있습니다.
3. 선택지 분석하기
A. 인스턴스 메타데이터에 데이터베이스 자격 증명을 저장합니다. Amazon EventBridge 규칙을 사용하여 RDS 자격 증명과 인스턴스 메타데이터를 동시에 업데이트하는 예약된 AWS Lambda 함수를 실행합니다.
→ 인스턴스 메타데이터에 저장하면 보안 위험이 있고, EventBridge와 Lambda 함수를 사용하여 자격 증명 교체를 구현하는 것은 복잡한 사용자 정의 로직이 필요하므로 운영 오버헤드가 증가합니다.
B. 암호화된 Amazon S3 버킷의 구성 파일에 데이터베이스 자격 증명을 저장합니다. Amazon EventBridge 규칙을 사용하여 RDS 자격 증명과 구성 파일의 자격 증명을 동시에 업데이트하는 예약된 AWS Lambda 함수를 실행합니다.
→ S3 버킷을 사용하는 방식은 버킷 암호화 설정, 적절한 접근 권한 구성, 버전 관리 설정 등 복잡한 보안 구성이 필요합니다. 게다가 Lambda 함수를 통해 자격 증명 교체를 구현하고, EventBridge로 이를 스케줄링하는 것은 추가적인 개발과 유지보수 부담을 발생시킵니다.
C. 데이터베이스 자격 증명을 AWS Secrets Manager에 비밀로 저장합니다. 보안 비밀에 대해 자동 회전을 켭니다. EC2 역할에 필요한 권한을 연결합니다.
D. 데이터베이스 자격 증명을 AWS Systems Manager Parameter Store에 암호화된 파라미터로 저장합니다. 암호화된 매개변수에 대해 자동 회전을 켭니다. EC2 역할에 필요한 권한을 연결합니다.
→ AWS Systems Manager Parameter Store는 기본적으로 구성 데이터를 관리하는 데 적합한 서비스입니다. 하지만 이 서비스는 자동 회전 기능을 기본으로 제공하지 않으며, 이를 구현하기 위해서는 추가적인 개발이 필요합니다.
이어서 다음 문제입니다.
문제2
회사가 AWS 클라우드에서 애플리케이션을 구축하고 있습니다.
애플리케이션은 두 AWS 리전의 Amazon S3 버킷에 데이터를 저장합니다.
회사는 AWS Key Management Service (AWS KMS) 고객 관리형 키를 사용하여 S3 버킷에 저장된 모든 데이터를 암호화해야 합니다.
두 S3 버킷의 데이터는 동일한 KMS 키로 암호화 및 암호 해독되어야 합니다. 데이터와 키는 두 지역 각각에 저장되어야 합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 각 리전에서 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
B. 고객 관리 다중 리전 KMS 키를 생성합니다. 각 리전에서 S3 버킷을 생성합니다. S3 버킷 간의 복제를 구성합니다. 클라이언트 측 암호화와 함께 KMS 키를 사용하도록 애플리케이션을 구성합니다.
C. 각 리전에서 고객 관리형 KMS 키와 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구 성합니다.
D. 각 리전에서 고객 관리형 KMS 키와 S3 버킷을 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
풀이
두 리전의 S3 버킷 데이터를 동일한 KMS 키로 암호화하고, 키와 데이터를 각 리전에 저장하려면 다중 리전 KMS 키를 생성해야 합니다. 다중 리전 KMS 키는 여러 AWS 리전에서 동일한 키 값을 공유하는 키로, 한 리전에서 생성한 후 다른 리전으로 복제하여 사용할 수 있습니다. 또한 클라이언트 측 암호화를 활용하면 데이터 암호화와 해독에 동일한 키를 사용할 수 있습니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 두 AWS 리전의 S3 버킷에 데이터 저장
- 데이터와 키를 각 리전에 저장
- 두 S3 버킷 데이터는 동일한 KMS 키로 암호화 및 암호 해독
2. 관련 AWS 서비스 생각하기
- AWS KMS는 데이터 암호화에 사용되는 암호화 키를 안전하게 생성하고 관리할 수 있는 완전관리형 서비스입니다. KMS는 다중 리전 키를 지원하는데, 이는 여러 AWS 리전에서 동일한 키 값을 사용할 수 있게 해주는 기능입니다. 다중 리전 키는 한 리전에서 생성한 후 다른 리전으로 복제할 수 있어, 여러 지역에 분산된 시스템에서 일관된 암호화를 가능하게 합니다.
- Amazon S3는 확장성이 뛰어난 객체 스토리지 서비스로, 데이터를 버킷이라는 컨테이너에 저장합니다. S3는 데이터 암호화를 위해 두 가지 방식을 지원합니다. 서버 측 암호화는 데이터가 S3 서버에 저장될 때 자동으로 암호화되는 방식이며, 클라이언트 측 암호화는 데이터가 S3에 업로드되기 전에 사용자의 애플리케이션에서 암호화되는 방식입니다. 두 방식 모두 KMS에서 관리하는 키를 사용하여 데이터를 안전하게 보호할 수 있습니다.
3. 선택지 분석하기
A. 각 리전에서 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
→ SSE-S3(S3 관리형 암호화 키) 방식은 Amazon S3가 자동으로 키를 관리하는 서버 측 암호화 방식입니다. 이 방식에서는 각 리전의 S3가 독립적으로 자체 키를 생성하고 관리하기 때문에, 서로 다른 리전의 데이터는 서로 다른 키로 암호화될 수밖에 없습니다. 또한 고객이 직접 키를 관리하지 않으므로, 고객 관리형 KMS 키 사용이라는 요구사항도 충족하지 못합니다.
B. 고객 관리 다중 리전 KMS 키를 생성합니다. 각 리전에서 S3 버킷을 생성합니다. S3 버킷 간의 복제를 구성합니다. 클라이언트 측 암호화와 함께 KMS 키를 사용하도록 애플리케이션을 구성합니다.
C. 각 리전에서 고객 관리형 KMS 키와 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
→ 각 리전에서 별도의 KMS 키를 사용하므로, 두 S3 버킷의 데이터가 동일한 키로 암호화되지 않습니다. 또한 SSE-S3는 S3 관리형 키를 사용합니다.
D. 각 리전에서 고객 관리형 KMS 키와 S3 버킷을 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
→ 각 리전에서 별도의 KMS 키를 사용하므로, 두 S3 버킷의 데이터가 동일한 키로 암호화되지 않습니다.
마지막 문제 살펴볼게요.
문제3
한 전자상거래 회사가 AWS에서 하루에 하나의 거래 웹사이트를 시작하려고 합니다. 매일 24시간 동안 정확히 하나의 제품이 판매됩니다.
이 회사는 사용량이 많은 시간에 밀리초 대기 시간 으로 시간당 수백만 건의 요청을 처리할 수 있기를 원합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. Amazon S3를 사용하여 다른 S3 버킷에서 전체 웹 사이트를 호스팅합니다. Amazon CloudFront 배포를 추가합니다. S3 버킷을 배포의 원본으로 설정합니다. 주문 데이터를 Amazon S3에 저장합니다.
B. 여러 가용 영역의 Auto Scaling 그룹에서 실행되는 Amazon EC2 인스턴스에 전체 웹 사이트를 배포합니다. ALB(Application Load Balancer)를 추가하여 웹 사이트 트래픽을 분 산합니다. 백엔드 API에 대해 다른 ALB를 추가하십시오. MySQL용 Amazon RDS에 데이터를 저장합니다.
C. 전체 애플리케이션을 마이그레이션하여 컨테이너에서 실행합니다. Amazon Elastic Kubernetes Service(Amazon EKS)에서 컨테이너를 호스팅합니다. Kubernetes Cluster Autoscaler를 사용하여 팟(Pod) 수를 늘리거나 줄여 트래픽의 버스트를 처리합니다. MySQL용 Amazon RDS에 데이터를 저장합니다.
D. Amazon S3 버킷을 사용하여 웹 사이트의 정적 콘텐츠를 호스팅합니다. Amazon CloudFront 배포를 배포합니다. S3 버킷을 오리진으로 설정합니다. 백엔드 API에 Amazon API Gateway 및 AWS Lambda 함수를 사용합니다. Amazon DynamoDB에 데이터를 저장합니다.
풀이
서버리스 아키텍처를 구축하면 자동 확장성과 고가용성을 확보하고 운영 오버헤드를 최소화할 수 있습니다. Amazon S3로 정적 웹사이트를 호스팅하고, CloudFront로 전 세계 사용자에게 밀리초 단위의 지연 시간으로 콘텐츠를 제공할 수 있습니다. API Gateway와 Lambda를 사용하여 백엔드 API를 구현하면 수백만 건의 요청을 자동으로 처리할 수 있으며, DynamoDB는 대규모 트래픽에도 일관된 성능을 제공합니다. 이러한 서버리스 서비스들은 AWS가 인프라를 관리하므로 운영 부담이 최소화됩니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 매일 24시간 동안 하나의 제품이 판매되는 전자상거래 웹사이트 개발
- 시간당 수백만 건의 요청을 밀리초 대기 시간으로 처리
2. 관련 AWS 서비스 생각하기
- Amazon S3는 확장성이 뛰어난 객체 스토리지 서비스로, 웹사이트의 HTML, CSS, JavaScript 등 정적 콘텐츠를 호스팅하는 데 이상적입니다. 정적 웹사이트 호스팅 기능을 제공하여 별도의 웹 서버 없이도 웹사이트를 운영할 수 있으며, 99.999999999%의 내구성을 제공하여 콘텐츠의 안정적인 저장을 보장합니다.
- Amazon CloudFront는 전 세계에 분산된 엣지 로케이션을 통해 콘텐츠를 제공하는 CDN 서비스입니다. S3에 저장된 콘텐츠를 전 세계 사용자들에게 밀리초 단위의 지연 시간으로 전송할 수 있으며, 캐싱을 통해 원본 서버의 부하를 줄이고 사용자 경험을 개선합니다.
- Amazon API Gateway는 API를 생성하고 관리하는 완전관리형 서비스입니다. REST API를 쉽게 생성할 수 있으며, 트래픽에 따라 자동으로 확장되어 시간당 수백만 건의 API 호출을 처리할 수 있습니다. Lambda 함수와 원활하게 통합되어 서버리스 백엔드를 구현하는 데 적합합니다.
- AWS Lambda는 서버 관리 없이 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. API Gateway의 요청에 응답하여 자동으로 실행되며, 실제 사용량에 따라 자동으로 확장되므로 트래픽이 급증하는 상황에서도 안정적인 성능을 제공합니다.
- Amazon DynamoDB는 어떤 규모에서도 일관된 밀리초 단위의 응답 시간을 제공하는 NoSQL 데이터베이스 서비스입니다. 완전관리형 서비스이므로 서버 관리나 데이터베이스 확장에 대한 걱정 없이 대규모 트래픽을 처리할 수 있으며, 자동 확장 기능으로 수요 변화에 자동으로 대응합니다.
3. 선택지 분석하기
A. Amazon S3를 사용하여 다른 S3 버킷에서 전체 웹 사이트를 호스팅합니다. CloudFront 배포를 추가합니다. S3 버킷을 배포의 원본으로 설정합니다. 주문 데이터를 S3에 저장합니다.
→ S3와 CloudFront만으로는 동적 웹사이트 운영에 필요한 핵심 기능들이 부족합니다. S3에 주문 데이터를 직접 저장하는 방식은 실시간 트랜잭션 처리가 필요한 전자상거래 사이트에 적합하지 않으며, 특히 밀리초 단위의 응답 시간과 대규모 동시 접속 처리라는 요구사항을 충족할 수 없습니다.
B. 여러 가용 영역의 Auto Scaling 그룹에서 실행되는 EC2 인스턴스에 전체 웹 사이트를 배포합니다. Application Load Balancer를 추가하여 웹 사이트 트래픽을 분산합니다. 백엔드 API에 대해 다른 ALB를 추가합니다. MySQL용 Amazon RDS에 데이터를 저장합니다.
→ EC2 인스턴스와 RDS를 사용하는 전통적인 아키텍처는 서버 패치, 확장 관리, 데이터베이스 백업 및 유지보수 등 많은 운영 작업이 필요합니다. Auto Scaling을 사용하더라도 기본 인프라에 대한 모니터링과 관리가 지속적으로 필요하므로, '최소한의 운영 오버헤드'라는 요구사항에 부합하지 않습니다.
C. 전체 애플리케이션을 마이그레이션하여 컨테이너에서 실행합니다. Amazon EKS에서 컨테이너를 호스팅합니다. Kubernetes Cluster Autoscaler를 사용하여 Pod 수를 조정합니다. MySQL용 Amazon RDS에 데이터를 저장합니다.
→ 컨테이너화된 애플리케이션과 EKS는 확장성은 제공하지만, Kubernetes 클러스터 관리, 컨테이너 이미지 관리, 보안 패치, 업그레이드 등 복잡한 운영 작업이 요구됩니다. RDS도 여전히 관리가 필요하여, '최소한의 운영 오버헤드'라는 요구사항에 부합하지 않습니다.
D. S3 버킷을 사용하여 웹 사이트의 정적 콘텐츠를 호스팅합니다. CloudFront 배포를 생성하고 S3 버킷을 원본으로 설정합니다. 백엔드 API에 API Gateway 및 Lambda 함수를 사용합니다. DynamoDB에 데이터를 저장합니다.
감사합니다. 다음 글에서 만나요! 😊
'AWS > SAA 준비' 카테고리의 다른 글
AWS SAA 합격으로 가는 길 #44 (1) | 2024.12.22 |
---|---|
AWS SAA 합격으로 가는 길 #43 (0) | 2024.12.16 |
AWS SAA 합격으로 가는 길 #41 (1) | 2024.12.09 |
AWS SAA 합격으로 가는 길 #40 (0) | 2024.12.06 |
AWS SAA 합격으로 가는 길 #39 (0) | 2024.12.02 |