[AWS - SAA] 개념정리 및 문제풀이 14일차

개념정리

프록시(Proxy)

• 개념 : 클라이언트와 서버 사이에 위치하여, 클라이언트의 요청을 서버로 전달하고 서버의 응답을 클라이언트로 전달하는 중개 서버를 의미합니다. 프록시는 중개 역할을 하면서 보안, 성능, 접근 제어, 트래픽 관리 등의 다양한 기능을 제공합니다.
• 프록시의 주요 기능
  • 보안 강화: 프록시 서버를 통해 IP 주소를 숨기거나 방화벽을 설정하여 보안을 강화할 수 있습니다. 예를 들어, 외부 웹사이트에 접근할 때 클라이언트의 실제 IP 주소가 아닌 프록시 서버의 IP 주소가 노출됩니다.
  • 트래픽 제어 및 로드 밸런싱: 프록시 서버는 여러 클라이언트의 요청을 분산시켜 서버의 부하를 줄이고, 네트워크 트래픽을 효율적으로 관리할 수 있습니다. 이를 통해 서비스의 성능을 개선하고, 네트워크 병목 현상을 방지할 수 있습니다.
  • 캐싱: 프록시 서버는 클라이언트가 자주 요청하는 데이터를 캐싱하여 저장할 수 있습니다. 이렇게 하면 동일한 요청이 있을 때 서버에 다시 요청할 필요 없이 프록시에서 데이터를 빠르게 제공할 수 있습니다.
  • 콘텐츠 필터링: 기업이나 학교에서는 프록시를 사용하여 특정 웹사이트나 콘텐츠에 대한 접근을 제한할 수 있습니다. 이를 통해 사용자들이 비업무적이거나 유해한 사이트에 접근하는 것을 방지할 수 있습니다.
  • 접근 제어: 프록시는 어떤 클라이언트가 서버에 접근할 수 있는지 제어할 수 있습니다. 이를 통해 불필요한 접근을 차단하고, 필요한 클라이언트에게만 서버 자원을 제공할 수 있습니다.

• 프록시의 종류
  • 포워드 프록시 (Forward Proxy): 클라이언트 쪽에 위치하여 클라이언트의 요청을 외부 서버로 전달합니다. 주로 IP 주소를 숨기거나, 접근 제어 및 필터링 목적으로 사용됩니다.
  • 리버스 프록시 (Reverse Proxy): 서버 쪽에 위치하여 클라이언트의 요청을 여러 내부 서버로 분배하고, 서버의 응답을 클라이언트로 전달합니다. 로드 밸런싱과 캐싱을 통해 서버의 성능을 개선하는 데 유용합니다.
  • 웹 프록시 (Web Proxy): 주로 웹 트래픽을 중개하며, 사용자가 특정 웹사이트에 접근할 때 IP 주소를 숨기거나 차단된 사이트에 우회 접속하는 데 사용할 수 있습니다.
  • 투명 프록시 (Transparent Proxy): 클라이언트가 프록시를 사용하고 있다는 사실을 인지하지 못하도록 하며, 클라이언트와 서버 사이의 트래픽을 자동으로 중개합니다.

Amazon RDS 프록시

• 개념 : Amazon RDS 데이터베이스와 애플리케이션 사이에 위치하는 관리형 데이터베이스 프록시 서비스입니다. 이 프록시는 데이터베이스 연결을 효율적으로 관리하여 애플리케이션의 성능과 확장성을 높이고, 보안을 강화하는 역할을 합니다. Amazon RDS 프록시는 MySQL, PostgreSQL, 그리고 RDS의 Aurora와 호환됩니다.
• 주요 기능 및 장점
  • 연결 관리: RDS 프록시는 애플리케이션의 데이터베이스 연결 풀을 관리하여, 연결을 재사용하고 최적화합니다. 이를 통해 데이터베이스에 대한 과도한 연결 요청을 줄이고, 데이터베이스의 안정성을 높입니다.
  • 자동 확장성: 트래픽 증가에 따라 자동으로 연결을 확장할 수 있습니다. 이는 서버리스 환경에서 특히 유용하며, 확장성 문제를 최소화해 애플리케이션의 성능을 안정적으로 유지할 수 있습니다.
  • 보안 강화: AWS Secrets Manager와 통합하여 데이터베이스 자격 증명을 안전하게 관리하고, AWS Identity and Access Management (IAM)과 연동해 인증 및 권한 관리를 쉽게 할 수 있습니다. 애플리케이션이 데이터베이스 자격 증명을 직접적으로 알 필요가 없게 됩니다.
  • 지속적인 연결: RDS 프록시는 세션 핸드오버를 통해 데이터베이스 연결을 유지합니다. 이를 통해 애플리케이션이 데이터베이스 연결을 끊지 않고도 지속적으로 데이터베이스에 액세스할 수 있도록 합니다.
  • 비용 절감: 연결을 효율적으로 관리하여 데이터베이스 인스턴스의 리소스 사용을 최적화함으로써 비용 절감 효과를 얻을 수 있습니다.
• 사용 사례
  • 서버리스 애플리케이션: Lambda 함수가 대규모로 데이터베이스에 접근해야 할 때, RDS 프록시를 사용하여 연결 관리를 개선할 수 있습니다.
  • 고가용성 요구사항이 높은 애플리케이션: 데이터베이스 재시작이나 재구성을 수행하는 동안, RDS 프록시는 애플리케이션에 중단 없는 연결을 제공합니다.
  • 보안이 중요한 환경: AWS Secrets Manager 및 IAM 통합으로 애플리케이션의 데이터베이스 자격 증명을 보다 안전하게 관리할 수 있습니다.

 

용어정리

Amazon RDS 프록시 : 데이터베이스에 대한 연결을 효과적으로 관리하여 성능을 높이고, 보안을 강화하며, 애플리케이션의 복잡한 데이터베이스 연결 요구를 단순화하는 데 도움을 줍니다.

프록시 : 클라이언트와 서버 사이에서 중개 역할을 하며, 다양한 기능을 통해 보안, 성능 및 관리 효율성을 높이는 데 중요한 역할을 합니다.

문제풀이

 

문제 1 : 솔루션 설계자가 애플리케이션을 위한 새로운 Amazon CloudFront 배포를 생성하고 있습니다. 사용자가 제출한 정보 중 일부는 민감한 정보입 니다. 애플리케이션은 HTTPS를 사용하지만 다른 보안 계층이 필요합니다. 민감한 정보는 전체 애플리케이션 스택에서 보호되어야 하며 정보에 대한 액세스는 특정 애플리케이션으로 제한되어야 합니다. 솔루션 아키텍트는 어떤 조치를 취해야 합니까?

 

A. CloudFront 서명된 URL을 구성합니다.

• CloudFront 서명된 URL은 접근을 제한하고 인증된 사용자만 콘텐츠에 접근할 수 있도록 합니다. 특정 애플리케이션에서만 접근해야 하는 상황에 유용합니다.
• 콘텐츠에 대한 만료기간, 액세스 가능한 IP 등을 지정하는 기능

B. CloudFront 서명 쿠키를 구성합니다.

• 서명 쿠키는 서명된 URL과 유사하게 인증된 사용자만 접근할 수 있도록 하며, 브라우저에 설정된 쿠키를 통해 접근을 제어할 수 있습니다.
• 콘텐츠에 대한 만료기간, 액세스 가능한 IP 등을 지정하는 기능

C. CloudFront 필드 수준 암호화 프로파일(field-level encryption profile)을 구성합니다.

• 필드 수준 암호화는 애플리케이션에서 특정 필드의 데이터를 암호화하여, CloudFront가 전달할 때도 민감한 정보가 보호되도록 합니다. 특히 민감한 정보가 포함된 데이터를 암호화해야 할 때 유용합니다.

D. CloudFront를 구성하고 뷰어 프로토콜 정책에 대해 오리진 프로토콜 정책 설정을 HTTPS 전용으로 설정합니다.

• HTTPS 전용 설정을 통해 모든 요청이 암호화된 HTTPS 프로토콜을 통해 전달되도록 합니다. 민감한 정보가 전송될 때 HTTPS를 사용하면 보안을 강화할 수 있습니다.
• 이미 질문에서 HTTPS 사용 중이라고 언급되었습니다.

문제 2 :회사는 AWS Organizations를 사용하여 각 사업부에 대한 전용 AWS 계정을 생성하여 요청 시 각 사업부의 계정을 독립적으로

관리합니다. 루 트 이메일 수신자가 한 계정의 루트 사용자 이메일 주소로 전송된 알림을 놓쳤습니다. 회사는 향후 모든 알림을 놓치지 않기를 원합니다. 향후 알림은 계정 관리자(account administrators)로 제한되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

A. 모든 AWS 계정 루트 사용자 이메일 메시지가 알림을 모니터링하고 해당 알림을 적절한 그룹에 전달할 책임이 있는 한 명의 관리자에게 전달되도록 구성합니다.

• 이 선택지는 모든 알림을 모니터링하여 하나의 관리자에게만 전달하는 것을 의미하므로, 각 계정의 루트 사용자에게 동일한 이메일 주소를 사용하도록 설정하지 않습니다. 따라서 요구 사항을 충족하지 않습니다.

B. AWS 계정 루트 사용자 이메일 주소로 전송되는 알림 이메일 메시지를 조직의 모든 사용자에게 전달하도록 회사 이메일 서버를 구성합니다.

• 이 선택지는 이메일 서버를 구성하여 조직의 모든 사용자에게 알림을 보내는 방법을 제안합니다. 하지만 이는 계정 관리자를 특정하지 않고 모든 사용자에게 전달하므로 요구 사항을 충족하지 않습니다.

C. 기존의 모든 AWS 계정과 새로 생성된 모든 계정이 동일한 루트 사용자 이메일 주소를 사용하도록 구성합니다. AWS Organizations 콘솔에서 또는 프로그래밍 방식으로 AWS 계정 대체 연락처를 구성합니다.

• 이 선택지는 모든 계정이 동일한 루트 사용자 이메일을 사용하도록 제안합니다. 이는 각 사업부에 대해 별도의 AWS 계정을 생성하라는 회사의 의도와 맞지 않습니다.

D. 모든 AWS 계정 루트 사용자 이메일 주소를 알림에 응답할 수 있는 소수의 관리자에게 전달되는 배포 목록으로 구성합니다. AWS Organizations 콘솔에서 또는 프로그래밍 방식으로 AWS 계정 대체 연락처를 구성합니다.

• 이 선택지는 알림을 특정 관리자들에게 전달하기 위한 배포 목록을 설정하므로 요구 사항을 충족할 수 있습니다. 각 계정의 루트 사용자 이메일 주소를 대체하여 소수의 관리자에게 알림이 가도록 설정할 수 있기 때문입니다.

문제 3 : 회사가 Amazon S3 버킷에 민감한 사용자 정보를 저장하고 있습니다. 회사는 VPC 내부의 Amazon EC2 인스턴스에서 실행되는 애플리케이션 계층에서 이 버킷에 대한 보안 액세스를 제공하려고 합니다. 작업 수행을 위해 솔루션 설계자는 어떤 조합의 단계를 취해야 하나요? (2개를 선택하십시오.)

 

A. VPC 내 Amazon S3용 VPC 게이트웨이 엔드포인트 구성

• 이 옵션은 필수적입니다. VPC 게이트웨이 엔드포인트를 사용하면 VPC 내부의 EC2 인스턴스가 인터넷을 통하지 않고 직접 S3에 안전하게 접근할 수 있습니다. 이는 데이터 전송 비용을 줄이고 보안을 강화합니다.

B. S3 버킷에 대한 객체를 퍼블릭으로 만들기 위한 버킷 정책 생성

• 이 옵션은 부적절합니다. 문제에서 언급한 '민감한 사용자 정보'를 퍼블릭으로 만드는 것은 보안상 위험합니다.

C. VPC에서 실행되는 애플리케이션 계층으로만 액세스를 제한하는 버킷 정책 생성

• 이 옵션도 중요합니다. S3 버킷 정책을 설정하여 특정 VPC 내의 애플리케이션에서만 접근을 허용함으로써, 데이터에 대한 접근을 더욱 제한하고 보안을 강화할 수 있습니다.

D. S3 액세스 정책으로 IAM 사용자를 생성하고 IAM 자격 증명을 EC2 인스턴스에 복사

•  IAM 자격 증명을 EC2 인스턴스에 직접 복사하는 것은 보안 모범 사례가 아닙니다. 대신 IAM 역할을 사용해야 합니다.
• 자격 증명 복사가 아닌 S3 액세스 역할을 만들어 EC2에 연결

E. NAT 인스턴스를 생성하고 EC2 인스턴스가 NAT 인스턴스를 사용하여 S3 버킷에 액세스하도록 구성

• NAT 인스턴스는 프라이빗 서브넷의 리소스가 인터넷에 접근할 때 사용되지만, S3 접근을 위해서는 불필요하며 비용이 추가됩니다. VPC 엔드포인트를 사용하는 것이 더 효율적입니다.

문제 4 : 회사는 Amazon Route 53에 도메인 이름을 등록했습니다. 이 회사는 ca-central-1 리전의 Amazon API Gateway를 백엔드 마이크로서비스 API 의 공용 인터페이스로 사용합니다. 타사 서비스는 API를 안전하게 사용합니다. 회사는 타사 서비스에서 HTTPS를 사용할 수 있도록 회사의 도 메인 이름 및 해당 인증서로 API 게이트웨이 URL을 설계하려고 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

A. API Gateway에서 Name=“Endpoint-URL” 및 Value=“Company Domain Name”으로 단계 변수를 생성하여 기본 URL을 덮어씁니다. 회사의 도메인 이름과 연결된 공인 인증서를 AWS Certificate Manager(ACM)로 가져옵니다.

• 이 선택지는 단계 변수로 URL을 설정하는 방법을 설명하고 있으나, 기본 URL 덮어쓰기 및 인증서 연결이 적절히 설명되어 있지 않아, 문제의 요구 사항을 완전히 충족하지 않을 수 있습니다.

B. 회사의 도메인 이름으로 Route 53 DNS 레코드를 생성합니다. 별칭 레코드가 리전 API 게이트웨이 단계 엔드포인트를 가리키도록 합니다. 회사의 도메인 이름과 연결된 공인 인증서를 us-east-1 리전의 AWS Certificate Manager(ACM)로 가져옵니다.

• ca-central-1 리전의 API Gateway를 사용한다고 했기 때문에, 인증서를 us-east-1 리전에 가져오는 것은 리전이 맞지 않아 문제의 요구 사항과 다릅니다. 리전별로 적절한 ACM 인증서를 사용해야 합니다.

C. 리전 API 게이트웨이 엔드포인트를 생성합니다. API Gateway 엔드포인트를 회사의 도메인 이름과 연결된 공인 인증서를 동일한 리전의 AWS Certificate Manager(ACM)로 가져옵니다. API Gateway 엔드포인트로 트래픽을 라우팅하도록 Route 53을 구성합니다.

• 이 선택지는 API Gateway와 동일한 리전에서 인증서를 사용하고 있으며, Route 53을 통해 트래픽 라우팅을 설정하여 문제의 요구 사항을 충족합니다. 리전 일치 및 도메인 연결이 잘 설명되어 있습니다.

D. 리전 API 게이트웨이 엔드포인트를 생성합니다. API Gateway 엔드포인트를 회사의 도메인 이름과 연결된 공인 인증서를 us-east-1 리전의 AWS Certificate Manager(ACM)로 가져옵니다. API에 인증서를 연결합니다. 회사의 도메인 이름으로 Route 53 DNS 레코드를 생성합니다.

• 선택지 (B)와 유사하게, 인증서를 us-east-1 리전에 가져오므로 ca-central-1 리전과 일치하지 않아 문제 요구 사항을 충족하지 못합니다.

문제 5 : 이미지 처리 회사에는 사용자가 이미지를 업로드하는 데 사용하는 웹 응용 프로그램이 있습니다. 애플리케이션은 이미지를 Amazon S3 버킷에 업로드합니다. 회사는 객체 생성 이벤트를 Amazon Simple Queue Service(Amazon SQS) 표준 대기열에 게시하도록 S3 이벤트 알림을 설정했습니다. SQS 대기열은 이미지를 처리하고 결과를 이메일을 통해 사용자에게 보내는 AWS Lambda 함수의 이벤트 소스 역할을 합니다. 사용자 는 업로드된 모든 이미지에 대해 여러 이메일 메시지를 수신하고 있다고 보고합니다. 솔루션 설계자는 SQS 메시지가 Lambda 함수를 두 번 이 상 호출하여 여러 이메일 메시지를 생성한다고 판단합니다. 솔루션 설계자는 이 문제를 최소한의 운영 오버헤드로 문제를 해결하기 위해 무엇을 해야 합니까?

 

A. ReceiveMessage 대기 시간을 30초로 늘려 SQS 대기열에서 긴 폴링을 설정합니다.

• 긴 폴링은 빈 응답 수를 제거하여 효율성 향상 및 메시지 처리 지연을 줄일 수 있지만, 중복 처리 문제를 직접적으로 해결하지는 않습니다.

B. SQS 표준 대기열을 SQS FIFO 대기열로 변경합니다. 메시지 중복 제거 ID를 사용하여 중복 메시지를 버리십시오.

• FIFO 대기열은 메시지 순서와 중복 제거를 보장하지만, 기존 시스템의 대규모 변경이 필요하며 처리량에 제한이 있을 수 있습니다.

C. SQS 대기열의 가시성 제한 시간(visibility timeout)을 함수 제한 시간(function timeout)과 일괄 처리 윈도우 제한 시간(batch window timeout)의 합계보다 큰 값으로 늘립니다.

• 설명: 이 방법이 가장 적절합니다. 가시성 제한 시간을 늘리면 Lambda 함수가 메시지를 처리하는 동안 다른 인스턴스가 같은 메시지를 처리하지 않도록 보장합니다. 이는 중복 처리를 방지하는 가장 효과적인 방법입니다.

D. 처리 전에 메시지를 읽은 직후 SQS 대기열에서 각 메시지를 삭제하도록 Lambda 함수를 수정합니다.

• 이 방법은 메시지 처리 실패 시 메시지 손실 위험이 있어 신뢰성 있는 해결책이 아닙니다.

문제 6 : 한 회사는 us-west-2 리전의 NLB(Network Load Balancer) 뒤에 있는 3개의 Amazon EC2 인스턴스에 자체 관리형 DNS 솔루션을 구현했습니다. 회사 사용자의 대부분은 미국과 유럽에 있습니다. 회사는 솔루션의 성능과 가용성을 개선하기를 원합니다. 회사는 eu-west-1 리전에서 3개의 EC2 인스턴스를 시작 및 구성하고 EC2 인스턴스를 새 NLB의 대상으로 추가합니다. 회사에서 트래픽을 모든 EC2 인스턴스로 라우팅하는 데 사용할 수 있는 솔루션은 무엇입니까?

A. 두 NLB 중 하나로 요청을 라우팅하는 Amazon Route 53 지리적 위치 라우팅 정책을 생성합니다. Amazon CloudFront 배포를 생성합니다. Route 53 레코드를 배포의 오리진으로 사용합니다.

• 이 방법은 지리적 위치 기반 라우팅을 제공하지만, 글로벌 트래픽 관리에 최적화되어 있지 않습니다.

B. AWS Global Accelerator에서 표준 액셀러레이터를 생성합니다. us-west-2 및 eu-west-1에서 엔드포인트 그룹을 생성합니다. 엔드포인트 그룹에 대한 엔드포인트로 두 개의 NLB를 추가합니다.

• 이 방법이 가장 적합합니다. Global Accelerator는 글로벌 트래픽을 최적화하고, 여러 리전의 엔드포인트를 효과적으로 관리합니다. 또한 자동 장애 조치와 고가용성을 제공합니다.

C. 6개의 EC2 인스턴스에 탄력적 IP 주소를 연결합니다. 6개의 EC2 인스턴스 중 하나로 요청을 라우팅하는 Amazon Route 53 지리적 위치 라우팅 정책을 생성합니다. Amazon CloudFront 배포를 생성합니다. Route 53 레코드를 배포의 오리진으로 사용합니다.

• 이 방법은 복잡하고 관리가 어려우며, NLB의 이점을 활용하지 않습니다.
• 지리적 라우팅을 사용하면 사용자 지리적 위치만을 가지고 라우팅하므로 두 NLB에 트래픽이 적절히 분산되지 않을 수 있습니다./

D. 두 개의 NLB를 두 개의 ALB(Application Load Balancer)로 교체합니다. 두 ALB 중 하나로 요청을 라우팅하는 Amazon Route 53 지연 시간 라우팅 정책을 생성합니다. Amazon CloudFront 배포를 생성합니다. Route 53 레코드를 배포의 오리진으로 사용합니다

• NLB를 ALB로 교체하는 것은 불필요한 변경이며, 지연 시간 기반 라우팅은 글로벌 트래픽 관리에 Global Accelerator만큼 효과적이지 않습니다.
• 지연시간 라우팅은 EC2의 트래픽이 아닌 AWS데이터센터의 트래픽을 기반으로 지연시간이 가장 낮은 데이터센터로 라우팅되므로 두 NLB에 트래픽이 적절히 분산되지 않을 수 있습니다.

 

문제 7 : 회사는 MySQL 데이터베이스로 구동되는 온프레미스 애플리케이션을 실행합니다. 회사는 애플리케이션의 탄력성과 가용성을 높이기 위해 애 플리케이션을 AWS로 마이그레이션하고 있습니다. 현재 아키텍처는 정상 작동 시간 동안 데이터베이스에서 많은 읽기 활동을 보여줍니다. 4시 간마다 회사의 개발 팀은 프로덕션 데이터베이스의 전체 내보내기를 가져와 스테이징 환경(staging environment)에 데이터베이스를 채웁니다. 이 시간동안 사용자가 허용할 수 없는 애플리케이션 대기 시간을 경험합니다. 개발 팀은 절차가 완료될 때까지 스테이징 환경을 사용할 수 없 습니다. 솔루션 설계자는 애플리케이션 대기 시간 문제를 완화하는 대체 아키텍처를 권장해야 합니다. 대체 아키텍처는 또한 개발 팀이 스테이 징 환경을 계속 사용할 수 있는 능력을 개발 팀에 제공해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

A. 프로덕션용 멀티 AZ Aurora 복제본과 함께 Amazon Aurora MySQL을 사용합니다. mysqldump 유틸리티를 사용하는 백업 및 복원 프로세스를 구현하여 스테이징 데이터베이스를 채웁니다.

• mysqldump는 데이터베이스 백업에 유용하지만, 대규모 데이터베이스에서는 시간이 오래 걸리며 프로덕션 성능에 영향을 줄 수 있습니다. 따라서 실시간으로 스테이징 환경을 채워야 하는 요구 사항에 적합하지 않습니다.

B. 프로덕션용 멀티 AZ Aurora 복제본과 함께 Amazon Aurora MySQL을 사용합니다. 데이터베이스 복제를 사용하여 온디맨드 스테이징 데이터베이스를 생성합니다.

• Amazon Aurora의 Database Cloning 기능을 사용하면 기존 클러스터에 영향을 미치지 않고 스테이징 데이터베이스를 신속하게 생성할 수 있습니다. 이는 스테이징 환경에서 신속하게 데이터를 사용할 수 있어 요구 사항에 부합합니다.

C. MySQL용 Amazon RDS 멀티 AZ 배포와 함께 프로덕션용 읽기 전용 복제본을 사용합니다. 스테이징 데이터베이스에 대기 인스턴스를 사용합니다.

• 대기 인스턴스는 장애 조치를 위한 용도로 사용되며, 스테이징 환경에 적합하지 않습니다. 읽기 전용 복제본은 사용할 수 있지만, 대기 인스턴스 자체는 스테이징 용도에 맞지 않습니다.

D. MySQL용 Amazon RDS 멀티 AZ 배포와 함께 프로덕션용 읽기 전용 복제본을 사용합니다. mysqldump 유틸리티를 사용하는 백업 및 복원 프로세스를 구현하여 스테이징 데이터베이스를 채웁니다.

• 이 선택지도 mysqldump를 사용하는 방법을 제안하고 있는데, 이는 데이터베이스 백업과 복원에 시간이 오래 걸리기 때문에 신속한 복제가 요구되는 환경에 적합하지 않습니다.