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

개념정리

AWS WAF (Web Application Firewall)

 

• 개념 : 웹 애플리케이션 방화벽으로, 주로 웹 애플리케이션 계층 (7계층)에서 발생할 수 있는 공격을 방어하는 데 사용됩니다.
• 주요 기능:
  • SQL Injection 및 XSS 방어: AWS WAF는 SQL Injection, 크로스 사이트 스크립팅(XSS)과 같은 웹 애플리케이션에 대한 애플리케이션 계층 공격을 방어할 수 있습니다.
  • IP 차단: 특정 IP 주소나 IP 범위를 차단하거나 허용할 수 있습니다.
  • HTTP 요청 필터링: HTTP 요청의 URI, 헤더, 본문 등을 기반으로 규칙을 정의하여 특정 패턴이나 규칙에 맞는 요청을 허용하거나 차단할 수 있습니다.
  • 규칙 자동화: AWS WAF는 AWS Managed Rules를 통해 이미 준비된 보안 규칙을 제공하며, 사용자는 이를 적용하여 빠르게 보안을 강화할 수 있습니다.
  • 로그 및 모니터링: WAF를 통해 웹 애플리케이션으로 들어오는 요청을 모니터링하고 로그를 남길 수 있어 보안 분석에 유용합니다.
  • API Gateway와 연동: API Gateway와의 통합을 통해 API 호출 시 발생할 수 있는 보안 위협을 차단할 수 있습니다.
• 주 사용 사례:
  • 웹 애플리케이션 보안: 주로 SQL Injection, XSS, 악성 봇과 같은 웹 위협을 방어.
  • API 보안: AWS API Gateway와 통합하여 API에 대한 공격을 방어.

AWS Shield

• 개념 : DDoS (Distributed Denial of Service) 공격을 방어하기 위한 AWS의 관리형 보안 서비스입니다. 두 가지 버전이 있습니다: AWS Shield Standard와 AWS Shield Advanced.
• AWS Shield Standard
  • 기본적인 DDoS 방어 기능을 제공하며, 모든 AWS 고객에게 추가 비용 없이 자동으로 적용됩니다.
  • 일반적인 DDoS 공격 패턴을 자동으로 감지하고 완화합니다.
  • 주로 네트워크 계층 및 전송 계층(4계층)의 DDoS 공격에 대해 보호를 제공합니다.

• AWS Shield Advanced
  • 더욱 강화된 DDoS 방어를 제공하며, 특히 대규모 DDoS 공격에 대해 효과적입니다.
  • 비용 보호: DDoS 공격으로 발생한 추가적인 리소스 비용을 방어해주는 비용 보호 기능을 포함.
  • 실시간 모니터링: AWS Security Response 팀과 협력하여 실시간으로 보안 대응을 할 수 있는 서비스를 제공합니다.
  • 보호 범위 확대: AWS WAF와 함께 연동하여 웹 애플리케이션을 종합적으로 보호할 수 있습니다. AWS Global Accelerator, Amazon CloudFront, Route 53, ELB, EC2와 같은 서비스도 Shield Advanced의 보호 범위에 들어갑니다.
  • 대시보드 제공: DDoS 공격에 대한 통계 데이터를 실시간으로 제공하고, 이를 통해 공격에 대해 더 나은 통찰을 제공.
• 주 사용 사례:
  • DDoS 공격 방어: 네트워크 및 애플리케이션 계층에서 발생할 수 있는 대규모의 DDoS 공격을 방어.
  • 비용 보호: DDoS 공격으로 인해 발생할 수 있는 추가 비용을 방어.

 

AWS WAF와 AWS Shield의 차이점

 

• AWS WAF는 웹 애플리케이션 계층 (Layer 7) 공격을 방어하며, SQL Injection, XSS와 같은 애플리케이션 계층 위협을 방어합니다.
• AWS Shield는 DDoS 공격에 대한 방어에 중점을 둡니다. 네트워크 계층 및 전송 계층 (Layer 3, Layer 4)에서 발생하는 공격을 방어하며, Shield Advanced는 더 강력한 보호와 비용 보상을 제공합니다.

 

AWS Config

• 개념 : AWS 리소스의 구성을 지속적으로 모니터링하고 평가할 수 있는 서비스입니다. 이를 통해 AWS 리소스가 설정된 규정이나 규칙에 따라 적절하게 구성되고 있는지 확인하고, 설정 변경 내역을 기록하며, 리소스 간 관계를 추적할 수 있습니다.
• AWS Config의 주요 기능:
  • 리소스 상태 기록 (Configuration Recorder):
    • AWS Config는 AWS 리소스의 상태를 지속적으로 기록합니다. EC2, RDS, S3, Lambda 등 다양한 AWS 서비스의 리소스 구성을 기록하며, 리소스 간의 관계를 추적합니다. 이를 통해 리소스의 현재 구성 상태를 확인할 수 있습니다.
  • 구성 변경 모니터링:
    • AWS 리소스에서 변경이 발생하면 그 즉시 해당 변경 사항을 감지하고 기록합니다. 이를 통해 리소스가 언제, 누구에 의해, 어떤 방식으로 변경되었는지를 추적할 수 있습니다.
  • 규칙 기반 규정 준수 평가:
    • AWS Config는 사용자 지정 규칙 또는 AWS 제공 규칙을 설정하여 리소스의 구성 상태가 규정 준수를 준수하는지 평가합니다. 예를 들어, 리소스에 태그가 없거나 특정 보안 그룹이 적용되지 않은 경우 알림을 받을 수 있습니다.
  • 구성 스냅샷 및 기록:
    • AWS Config는 특정 시점의 구성 상태를 스냅샷으로 저장할 수 있습니다. 이를 통해 과거의 리소스 구성 상태를 확인하거나, 감사 및 보안 목적을 위해 과거의 구성 변경 내역을 참조할 수 있습니다.
  • 자동화된 대응:
    • AWS Config 규칙에 따라 리소스의 비정상적인 상태나 규정 위반을 감지하면 자동으로 대응할 수 있습니다. 예를 들어, Lambda 함수를 사용하여 자동으로 리소스를 수정하거나, 보안 위반을 해결할 수 있습니다.
• AWS Config의 활용 사례:
  • 보안 및 규정 준수:
    • AWS 리소스가 보안 규정을 준수하는지 모니터링할 수 있습니다. 예를 들어, S3 버킷이 퍼블릭으로 열려 있는지, 리소스가 필수 태그를 가지고 있는지 등을 실시간으로 평가할 수 있습니다.
  • 감사 및 변경 관리:
    • AWS 환경의 변경 사항을 추적하고, 특정 시점에서의 리소스 구성 상태를 확인할 수 있어, 규정 준수 감사에 유용합니다.
  • 리소스 관계 시각화:
    • AWS 리소스 간의 관계를 시각화할 수 있어, 리소스 간의 의존성을 쉽게 파악할 수 있습니다. 예를 들어, EC2 인스턴스와 연결된 보안 그룹, IAM 역할 등의 관계를 확인할 수 있습니다.

Amazon RDS 프록시(Amazon Relational Database Service Proxy)

• 개념 : AWS Lambda와 같은 서버리스 애플리케이션에서 데이터베이스 연결을 효율적으로 관리하기 위해 사용되는 서비스입니다. 특히, 연결 수 제한 문제를 해결하고 성능을 최적화하는 데 매우 유용합니다.
• RDS 프록시의 주요 기능과 이점
  • 데이터베이스 연결 풀링:
    • Lambda 함수와 같은 서버리스 애플리케이션은 단기적인 트래픽 급증 시 많은 수의 데이터베이스 연결을 생성할 수 있습니다. 이러한 연결이 폭발적으로 늘어나면 데이터베이스의 CPU와 메모리 리소스를 소모하게 되어 성능 저하나 연결 실패가 발생할 수 있습니다.
    • RDS 프록시는 이러한 연결을 미리 풀링(pooling)하여, 기존 연결을 재사용하거나 필요한 경우 새로운 연결을 효율적으로 생성하여 데이터베이스의 부하를 줄여줍니다.
  • 고가용성 및 장애 조치:
    • RDS 프록시는 자동으로 다중 가용 영역(AZ)에서 동작하여 고가용성을 보장합니다. 또한, 데이터베이스 장애가 발생하면 프록시가 자동으로 장애 조치(failover)를 수행하여 연결을 유지합니다.
  • 자동 인증 및 보안:
    • RDS 프록시는 IAM 인증을 지원하며, 애플리케이션이 별도로 데이터베이스 자격 증명을 관리할 필요 없이 안전하게 데이터베이스에 연결할 수 있도록 돕습니다.
    • AWS Secrets Manager와 통합하여 안전한 자격 증명 관리를 제공합니다.
  • 서버리스 환경에 최적화:
    • Lambda와 같은 서버리스 애플리케이션은 동시성 문제가 있을 수 있습니다. Lambda 함수가 호출될 때마다 데이터베이스와 새로운 연결을 생성하면 데이터베이스의 성능에 영향을 줄 수 있는데, RDS 프록시는 이러한 연결을 관리하여 트래픽 급증 시에도 데이터베이스에 무리 없이 동작하게 합니다.
  • 지연 시간 감소:
    • RDS 프록시는 애플리케이션이 요청할 때마다 새로 연결을 생성하지 않고, 기존의 연결을 재사용하므로 연결 생성 및 종료에서 발생하는 지연 시간을 줄일 수 있습니다.
• RDS 프록시가 필요한 경우
  • 서버리스 애플리케이션: Lambda와 같은 서버리스 환경에서는 함수가 동시에 여러 번 호출될 수 있는데, 이때 각 호출이 데이터베이스와 새로운 연결을 열면 데이터베이스 리소스가 과부하될 수 있습니다. RDS 프록시는 이러한 문제를 해결하여 연결을 효율적으로 관리합니다.
  • 연결 관리가 필요한 대규모 애플리케이션: 데이터베이스에 대한 많은 수의 연결을 효율적으로 관리하고자 할 때 유용합니다.
  • 고가용성이 중요한 경우: 프록시는 데이터베이스 장애 발생 시 빠르게 장애 조치를 수행해 연결을 유지할 수 있도록 돕습니다.

풀링(Pooling)

• 개념 : 자원을 효율적으로 재사용하기 위해 미리 준비해 두고 필요할 때마다 사용하는 기술을 말합니다. 데이터베이스 연결 풀링(Database Connection Pooling)의 경우, 데이터베이스와 애플리케이션 간의 연결을 미리 만들어 두고, 새로운 연결을 생성하는 대신 기존의 연결을 재사용하는 방식을 의미합니다.
• 데이터베이스 연결 풀링의 동작 원리
  • 초기화: 애플리케이션이 시작되면, 미리 설정된 수만큼 데이터베이스 연결을 풀(pool)에 만들어 둡니다. 이 풀은 데이터베이스와의 연결 객체들의 집합입니다.
  • 연결 요청: 애플리케이션이 데이터베이스에 연결하려고 할 때, 새로운 연결을 매번 생성하지 않고, 풀에 있는 기존 연결을 재사용합니다. 이로 인해 새로운 연결을 맺고 해제하는 데 소요되는 시간과 비용을 줄일 수 있습니다.
  • 연결 해제: 애플리케이션이 데이터베이스 작업을 완료하면, 해당 연결을 풀에 반환합니다. 반환된 연결은 다른 요청에서 재사용됩니다.
  • 추가 연결 생성: 만약 동시 연결 요청이 너무 많아 풀에 사용 가능한 연결이 없다면, 추가로 새로운 연결을 생성하여 풀에 넣을 수 있습니다. 하지만, 풀의 크기는 설정된 최대 값으로 제한됩니다.
• 풀링의 장점
  • 연결 생성 비용 절감: 데이터베이스 연결을 새로 생성하는 것은 시간이 걸리고 자원을 소모합니다. 풀링을 사용하면, 이미 생성된 연결을 재사용함으로써 새로운 연결을 생성하는 데 드는 비용을 절감할 수 있습니다.
  • 성능 향상: 각 요청마다 연결을 새로 열고 닫는 대신, 이미 만들어진 연결을 재사용하므로 연결 설정에 걸리는 시간을 줄여 응답 속도를 빠르게 할 수 있습니다.
  • 자원 절약: 풀링을 통해 애플리케이션과 데이터베이스 간의 불필요한 연결 생성을 줄이고 필요한 연결만 유지하므로 CPU와 메모리 자원을 절약할 수 있습니다.
  • 데이터베이스 부하 감소: 데이터베이스는 매번 새로운 연결을 열고 닫는 데 리소스를 사용합니다. 풀링을 통해 데이터베이스 연결 수를 효율적으로 관리하면 데이터베이스의 과부하를 방지할 수 있습니다.
• 예시
  • 풀링 없이: 웹 애플리케이션에서 사용자 요청이 들어올 때마다 새로운 데이터베이스 연결을 생성하고, 작업이 끝나면 연결을 닫습니다. 동시 요청이 많으면 매번 연결을 열고 닫는 작업이 데이터베이스에 큰 부하를 줍니다.
  • 풀링 사용: 웹 애플리케이션은 미리 설정된 수만큼의 데이터베이스 연결을 만들어 두고, 요청이 들어오면 기존 연결을 재사용합니다. 동시 요청이 많아도 새로운 연결을 만드는 대신 풀에 있는 연결을 재사용하므로 성능이 크게 향상됩니다.
• RDS 프록시에서의 풀링
  • RDS 프록시는 이러한 연결 풀링을 자동으로 관리하여, Lambda 함수 같은 서버리스 환경에서 동시 실행 시 많은 연결이 생성되는 문제를 해결합니다. Lambda 함수가 동시에 실행될 때마다 데이터베이스에 새로운 연결을 맺으면 데이터베이스에 큰 부하가 걸리기 때문에, RDS 프록시는 이러한 연결을 풀에서 관리하고, 필요한 경우에만 새로운 연결을 생성하여 성능을 최적화합니다.
  • 정리하자면, 풀링은 데이터베이스와의 연결을 효율적으로 관리하기 위해 미리 연결을 준비하고 재사용하는 기법입니다. 이를 통해 애플리케이션의 성능을 높이고, 데이터베이스에 과도한 부하가 걸리는 것을 방지할 수 있습니다.

용어정리

• WAF는 주로 웹 애플리케이션 계층을 보호하며, SQL Injection 및 XSS 공격을 막는 데 사용됩니다.
• Shield는 DDoS 방어에 중점을 두며, 주로 네트워크 및 전송 계층 공격을 방어합니다. Shield Advanced는 더 강화된 DDoS 보호 기능을 제공하고 AWS WAF와 함께 종합적인 보안 솔루션을 구축할 수 있습니다.

단일 프로비저닝된 IOPS SSD:

• 단일 프로비저닝된 IOPS SSD는 Amazon EBS(Elastic Block Store)에서 제공하는 스토리지 유형으로, 프로비저닝된 IOPS(초당 입출력 작업 수)를 미리 설정하여 성능을 보장하는 스토리지입니다.
• IOPS란 Input/Output Operations Per Second의 약자로, 스토리지 디바이스가 1초에 처리할 수 있는 입출력 작업 수를 의미합니다. 고성능 애플리케이션에서는 높은 IOPS가 필요합니다.
• 프로비저닝된 IOPS는 사용자가 특정한 IOPS 수치를 미리 설정할 수 있도록 하여, 예측 가능한 성능을 보장합니다. 이는 트랜잭션 처리나 고성능 데이터베이스와 같은 애플리케이션에서 필수적인 기능입니다.
• 단일 프로비저닝된 IOPS SSD는 단일 EBS 볼륨을 여러 인스턴스가 동시에 연결할 수 있도록 하여, 여러 인스턴스가 동일한 스토리지에 접근하면서도 높은 성능을 유지하도록 지원합니다. 이는 HPC(고성능 컴퓨팅) 환경에서 중요한 요구 사항 중 하나입니다.

문제풀이

 

문제 1 :글로벌 회사는 Amazon API Gateway를 사용하여 us-east-1 리전 및 ap-southeast-2 리전에 로열티 클럽 사용자를 위한 REST API를 설계하고 있습니다. 솔루션 설계자는 SQL injection 및 교차 사이트 스크립팅 공격으로부터 여러 계정에서 이러한 API Gateway 관리 REST API를 보호하는 솔루션을 설계해야 합니다.

최소한의 관리 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

문제 분석 포인트:

• SQL Injection 및 크로스 사이트 스크립팅(XSS)과 같은 보안 위협으로부터 API를 보호하는 것이 요구됨.
• 최소한의 관리 노력으로 여러 리전에서 보호 솔루션을 구현해야 함.

A. 두 리전에 AWS WAF를 설정합니다. 리전 웹 ACL을 API 단계와 연결합니다.

• 분석:
  • AWS WAF는 웹 애플리케이션 방화벽으로, SQL Injection 및 크로스 사이트 스크립팅과 같은 공격을 방어하는데 효과적입니다. 하지만, 두 리전에 각각 AWS WAF를 설정해야 하므로 관리 부담이 클 수 있습니다. 또한 각 리전에 별도로 규칙을 적용해야 하기 때문에 중앙 관리가 어렵습니다.
  • 하나만 생성하면 여러 리전의 리소스를 보호할 수 있습니다.
  • 결론: 적절한 보안을 제공하지만 관리 측면에서 비효율적일 수 있습니다.

B. 두 리전에 AWS Firewall Manager를 설정합니다. AWS WAF 규칙을 중앙에서 구성합니다.

• 분석:
  • AWS Firewall Manager는 여러 리전에 분산된 AWS WAF 설정을 중앙에서 관리할 수 있는 서비스입니다. 이를 사용하면 모든 리전의 WAF 설정을 일관성 있게 관리할 수 있으며, 중앙 집중식 관리가 가능합니다. 따라서 최소한의 관리 노력으로 SQL Injection 및 XSS와 같은 위협으로부터 API를 보호할 수 있습니다.
  • 결론: 중앙 관리가 가능하며, 여러 리전의 보안 설정을 쉽게 관리할 수 있는 가장 적합한 솔루션입니다.

C. 두 리전에 AWS Shield를 설정합니다. 리전 웹 ACL을 API 단계와 연결합니다.

• 분석:
  • AWS Shield는 주로 DDoS 공격을 방어하기 위한 서비스입니다. DDoS 공격에 대해서는 보호할 수 있지만, SQL Injection이나 XSS와 같은 애플리케이션 레벨의 공격을 방어하지는 않습니다. 따라서 SQL Injection 및 XSS에 대한 요구사항을 충족하지 못합니다.
  • 결론: DDoS 공격에 대해서는 보호 가능하지만, 문제에서 요구하는 보안 위협에 적합하지 않음.

D. 리전 중 하나에서 AWS Shield를 설정합니다. 리전 웹 ACL을 API 단계와 연결합니다.

• 분석:
  • 이 옵션도 AWS Shield를 사용하는 방식이므로 C와 마찬가지로 애플리케이션 레벨의 보안 요구사항을 충족하지 못합니다. 따라서 SQL Injection 및 XSS에 대한 방어가 부족합니다.
• 결론: SQL Injection과 XSS에 대한 보호가 불충분함.

 

문제 2 :한 회사에서 API로 구동되는 클라우드 커뮤니케이션 플랫폼을 설계하고 있습니다. 애플리케이션은 NLB(Network Load Balancer) 뒤의 Amazon EC2 인스턴스에서 호스팅 됩니다. 이 회사는 Amazon API Gateway를 사용하여 API를 통해 애플리케이션에 대한 액세스 권한을 외부 사용자에게 제공합니다. 이 회사는 SQL injection 과 같은 웹 위협으로부터 플랫폼을 보호하고 대규모의 정교한 DDoS 공격을 탐지하고 완화하기를 원합니다.

어떤 솔루션 조합이 가장 보호 기능을 제공합니까? (2개를 선택하십시오.)

 

문제 분석 포인트:

• 웹 위협 (예: SQL Injection)과 DDoS 공격 모두를 방어해야 함.
• AWS WAF와 AWS Shield 등의 보안 솔루션이 관련됨.

A. AWS WAF를 사용하여 NLB를 보호합니다.

• 분석:
  • AWS WAF는 웹 애플리케이션 방화벽으로, SQL Injection과 같은 애플리케이션 계층의 공격을 방어하는데 효과적입니다. 하지만, NLB는 전통적으로 4계층(Network Layer)의 로드 밸런서로, WAF는 주로 7계층(애플리케이션 계층)에서 작동하기 때문에 NLB에 적용하는 것은 적합하지 않습니다.
  • 결론: 적절하지 않은 선택입니다.

B. NLB와 함께 AWS Shield Advanced를 사용합니다.

• 분석:
  • AWS Shield Advanced는 DDoS 공격을 방어하기 위한 고급 솔루션입니다. NLB와 함께 사용할 경우, DDoS 공격을 완화하는 데 매우 효과적이며, Shield Advanced는 AWS WAF와 함께 동작하여 더 강력한 보안을 제공합니다.
  • Shield는 DDoS 보호 솔루션으로 ELB, CloudFront, Route53, Global Accelerator, EC2 연결가능
  • 결론: DDoS 공격 방어를 위한 적절한 솔루션입니다.

C. AWS WAF를 사용하여 Amazon API Gateway를 보호합니다.

• 분석:
  • AWS WAF는 SQL Injection과 같은 웹 위협을 방어할 수 있으며, API Gateway와 함께 사용하면 API에 대한 애플리케이션 계층의 공격을 차단할 수 있습니다. 이 조합은 SQL Injection과 같은 웹 공격을 방어하는 데 매우 효과적입니다.
  • WAF는 ALB, API Gateway, CloudFront 연결 가능
  • 결론: 애플리케이션 계층의 보안을 위해 적합한 솔루션입니다.

D. AWS Shield Standard와 함께 Amazon GuardDuty를 사용합니다.

• 분석:
  • AWS Shield Standard는 기본적인 DDoS 방어를 제공하지만, Shield Advanced만큼 강력하지 않습니다. GuardDuty는 보안 위협을 탐지하는 서비스로, 네트워크 트래픽 분석을 통해 의심스러운 활동을 모니터링합니다. 그러나 이 조합은 SQL Injection과 같은 웹 위협을 차단하는 데 직접적인 도움을 주지 않습니다.
  • 결론: 적절한 선택이 아닙니다.

E. Amazon API Gateway와 함께 AWS Shield Standard를 사용합니다.

• 분석:
  • AWS Shield Standard는 DDoS 공격을 방어하는 기본적인 보호를 제공하지만, SQL Injection과 같은 웹 공격에는 대응하지 못합니다. 또한, Shield Advanced와 비교했을 때 DDoS 방어의 깊이가 부족할 수 있습니다.
  • 결론: SQL Injection과 같은 웹 위협을 방어하기에는 적절하지 않음.

 

문제 3 : 회사는 AWS에서 호스팅되는 서비스 솔루션으로서 고성능 컴퓨팅(HPC) 워크로드를 구축할 계획입니다. 16개의 AmazonEC2 Linux 인스턴스 그룹은 노드 간 통신에 가장 낮은 지연 시간이 필요합니다. 인스턴스에는 고성능 스토리지를 위한 공유 블록 장치 볼륨도 필요합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

A. 클러스터 배치 그룹을 사용합니다. Amazon EBS 다중 연결을 사용하여 단일 프로비저닝된 IOPS SSD Amazon Elastic Block Store(Amazon EBS) 볼륨을 모든 인스턴스에 연결

• 클러스터 배치 그룹은 동일한 가용 영역 내에서 EC2 인스턴스를 가깝게 배치하여 저지연 네트워킹을 보장하는 옵션입니다. 이는 고성능 컴퓨팅 환경에서 중요합니다.
• Amazon EBS 다중 연결을 통해 여러 인스턴스가 동일한 프로비저닝된 IOPS SSD EBS 볼륨에 동시에 접근할 수 있어 고성능의 공유 스토리지가 가능합니다.

B. 클러스터 배치 그룹을 사용합니다. Amazon Elastic File System(Amazon EFS)을 사용하여 인스턴스 간에 공유 파일 시스템 생성

• Amazon EFS는 네트워크 파일 시스템으로, 여러 EC2 인스턴스 간의 공유 스토리지를 제공합니다. 하지만, EBS 다중 연결보다 높은 지연 시간이 발생할 수 있기 때문에 고성능 컴퓨팅 환경에서 최적의 선택이 아닙니다.

C. 파티션 배치 그룹을 사용합니다. Amazon EFS를 사용하여 인스턴스 간에 공유 파일 시스템 생성

• 파티션 배치 그룹은 인스턴스 간의 장애 격리를 제공합니다. 이는 고가용성을 위한 구조이며, 저지연 통신을 위한 구조가 아니므로, 이 상황에서는 적합하지 않습니다. 또한, EFS는 고성능 컴퓨팅 환경에서 지연 시간이 적합하지 않습니다.

D. 스프레드 배치 그룹을 사용합니다. Amazon EBS 다중 연결을 사용하여 단일 프로비저닝된 IOPS SSD Amazon EBS 볼륨을 모든 인스턴스에 연결

• 스프레드 배치 그룹은 인스턴스를 서로 격리하여 가용성을 높이는 방식입니다. 하지만 이는 HPC 워크로드에서 필요한 저지연 통신을 제공하지 않으므로, 적합하지 않습니다.

문제 4 : 회사는 AWS 클라우드에서 호스팅되는 미디어 애플리케이션을 위한 공유 스토리지 솔루션을 구현하고 있습니다. 회사는 SMB 클라이언트를 사용하여 데이터에 액세스할 수 있는 기능이 필요합니다. 솔루션은 완전 관리형이어야 합니다.

이러한 요구 사항을 충족하는 AWS 솔루션은 무엇입니까?

 

A. AWS Storage Gateway 볼륨 게이트웨이를 사용

• 볼륨 게이트웨이는 온프레미스에서 사용하는 스토리지를 클라우드에 연결해주는 서비스입니다. 이 옵션은 공유 파일 시스템보다는 블록 스토리지를 클라우드에 확장하는 데 더 적합합니다.
• 하지만 SMB 클라이언트를 직접 지원하지 않습니다, 따라서 이 옵션은 적합하지 않습니다.

B. AWS Storage Gateway 테이프 게이트웨이

• 테이프 게이트웨이는 기존의 물리적 테이프 백업을 가상 테이프로 교체하고, 데이터를 S3에 저장하는 백업 용도로 주로 사용됩니다. 이는 공유 파일 시스템과는 관련이 없으므로 이 요구사항에 적합하지 않습니다.

C. Amazon EC2 Windows 인스턴스 생성 후 파일 공유 역할 설정

• EC2에서 Windows 인스턴스를 생성하고 직접 파일 서버를 구성할 수 있지만, 이 경우 완전 관리형이 아니며, 파일 서버의 운영 및 유지 관리를 수동으로 해야 합니다. 따라서 완전 관리형을 요구하는 문제 요구사항에 적합하지 않습니다.

D. Amazon FSx 파일 시스템 생성

• Amazon FSx for Windows File Server는 SMB 프로토콜을 완벽하게 지원하고, 완전 관리형 서비스로서 파일 서버 관리 및 유지보수를 AWS가 처리합니다. 온프레미스 클라이언트나 애플리케이션 서버가 FSx에 쉽게 연결할 수 있으며, Windows 파일 시스템과의 호환성도 매우 뛰어납니다. SMB 클라이언트 지원을 요구하는 요구사항과 정확히 맞아떨어집니다.

문제 5 :AWS에서 웹 애플리케이션을 호스팅하는 회사는 모든 Amazon EC2 인스턴스, Amazon RDS DB 인스턴스. Amazon Redshift 클러스터가 태그로 구성되었는지 보장하기를 원합니다. 회사는 이 검사를 구성하고 운영하는 노력을 최소화하기를 원합니다.

솔루션 설계자는 이를 달성하기 위해 무엇을 해야 합니까?

 

A. AWS Config 규칙을 사용하여 태그가 제대로 지정되지 않은 리소스를 정의하고 감지합니다.

• AWS Config는 리소스의 구성을 기록하고 규정 준수 여부를 모니터링할 수 있는 서비스입니다. 태그 지정 규칙을 설정하여 리소스에 태그가 지정되지 않은 경우 이를 감지하고 보고할 수 있습니다. 이 방식은 자동화된 방법으로 리소스 태그를 감시할 수 있어 운영을 최소화하는 데 적합합니다.

B. 비용 탐색기를 사용하여 제대로 태그가 지정되지 않은 리소스를 표시합니다. 해당 리소스에 수동으로 태그를 지정합니다.

• 비용 탐색기는 리소스별 비용을 추적하는 도구입니다. 태그를 통해 비용을 분류할 수 있지만, 태그가 없는 리소스는 수동으로 찾아야 하고 이를 일일이 수동으로 태그 지정해야 합니다. 수동 작업이 많아 관리 효율성이 떨어질 수 있습니다.

C. 적절한 태그 할당을 위해 모든 리소스를 확인하는 API 호출을 작성합니다. EC2 인스턴스에서 주기적으로 코드를 실행합니다.

• 이 방법은 API 호출을 통해 태그 상태를 확인하고 리소스의 태그가 누락되었을 때 코드를 실행하여 이를 수정하는 방법입니다. 그러나 EC2 인스턴스에서 주기적으로 코드를 실행하는 방식은 추가적인 유지보수와 관리가 필요하며, 자동화 수준이 낮아 이 문제의 요구 사항을 충족하기 어렵습니다.

D. 적절한 태그 할당을 위해 모든 리소스를 확인하는 API 호출을 작성합니다. Amazon CloudWatch를 통해 AWS Lambda 함수를 예약하여 코드를 주기적으로 실행합니다.

• Lambda와 CloudWatch Events를 이용해 주기적으로 태그 확인 코드를 실행하는 방식입니다. 이 방법은 자동화된 방식으로 태그가 잘 유지되고 있는지 모니터링할 수 있지만, Lambda 함수를 주기적으로 실행하여 태그를 확인하는 방식은 태그 상태를 실시간으로 모니터링하는 데 한계가 있을 수 있습니다.

문제 6 :최근에 AWS로 마이그레이션한 회사가 프로덕션 VPC로 들어오고 나가는 트래픽을 보호하는 솔루션을 구현하려고 합니다. 이 회사는 사내 데이터 센터에 검사 서버를 가지고 있었습니다. 검사 서버는 트래픽 흐름 검사 및 트래픽 필터링과 같은 특정 작업을 수행했습니다. 회사는 AWS 클라우드에서 동일한 기능을 갖기를 원합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

A. Amazon GuardDuty 사용:

• GuardDuty는 AWS에서 제공하는 위협 탐지 서비스로, 악성 트래픽과 보안 위협을 탐지하는 데 유용합니다. 하지만, GuardDuty는 주로 위협 감지에 초점이 맞춰져 있고 트래픽 필터링에는 적합하지 않으므로 이 문제에 적합한 답이 아닙니다.

B. 트래픽 미러링 사용:

• 트래픽 미러링은 VPC 트래픽을 복제하여 모니터링 및 분석 목적으로 사용됩니다. 실제로 미러링된 트래픽을 검사할 수 있지만, 트래픽 필터링은 제공되지 않으므로 이 답변도 적합하지 않습니다.

C. AWS Network Firewall 사용:

• AWS Network Firewall은 VPC 트래픽을 검사하고 필터링하는 데 특화된 서비스입니다. 다양한 보안 규칙을 설정하여 들어오고 나가는 트래픽을 필터링할 수 있습니다. 따라서 이 선택지는 요구사항을 충족시킬 수 있는 최적의 솔루션입니다.

D. AWS Firewall Manager 사용:

• Firewall Manager는 여러 AWS 계정 및 리소스에서 보안 정책을 중앙에서 관리하는 서비스입니다. AWS Network Firewall과 WAF 규칙을 관리할 수 있지만, 직접적인 트래픽 검사와 필터링보다는 관리와 정책 적용에 더 적합한 서비스입니다. 따라서 이 문제에서 요구하는 트래픽 검사 및 필터링 기능에 적합하지 않습니다.

문제 7 : 솔루션 설계자는 2계층 웹 애플리케이션을 설계하고 있습니다. 애플리케이션은 퍼블릭 서브넷의 Amazon EC2에서 호스팅되는 공개 웹 계층으로 구성됩니다. 데이터베이스 계층은 프라이빗 서브넷의 Amazon EC2에서 실행되는 Microsoft SQL Server로 구성됩니다.

회사 이 상황에서 보안 그룹을 어떻게 구성해야 합니까? (2개 선택)

 

A. 0.0.0.0/0에서 포트 443의 인바운드 트래픽을 허용하도록 웹 계층에 대한 보안 그룹을 구성합니다.

• 포트 443은 HTTPS 트래픽을 처리하는 포트입니다. 웹 계층은 외부 인터넷 사용자들이 접근할 수 있어야 하기 때문에 이 규칙이 필요합니다.
• 0.0.0.0/0은 모든 IP 주소에서 접근을 허용한다는 의미입니다. 웹 서버는 일반적으로 전 세계에서 접근할 수 있어야 하므로, 이 인바운드 규칙을 통해 웹 계층으로의 HTTPS 트래픽을 허용합니다.
• 따라서 이 규칙은 올바른 설정입니다. 외부에서 웹 서버에 접근할 수 있도록 해야 하기 때문입니다.

B. 0.0.0.0/0에서 포트 443의 아웃바운드 트래픽을 허용하도록 웹 계층에 대한 보안 그룹을 구성합니다.

• 아웃바운드 트래픽은 서버에서 외부로 나가는 트래픽입니다. 웹 서버가 외부와 통신할 때 나가는 트래픽을 제한할 필요는 거의 없으므로 기본적으로 아웃바운드 트래픽은 허용되는 경우가 많습니다.
• 하지만 문제의 상황에서는 주로 인바운드 트래픽(외부에서 서버로 들어오는 트래픽)이 중요하기 때문에 이 규칙은 핵심이 아닙니다.
• 이 설정은 필수적이지 않으며, 이 경우에서는 선택 사항에 가깝습니다.

C. 웹 계층의 보안 그룹에서 포트 1433의 인바운드 트래픽을 허용하도록 데이터베이스 계층의 보안 그룹을 구성합니다.

• 포트 1433은 Microsoft SQL Server가 사용하는 기본 포트입니다. 웹 계층은 데이터베이스 서버에 연결해야 하기 때문에, 이 포트를 열어주는 것이 필요합니다.
• 데이터베이스 계층은 프라이빗 서브넷에 있으므로 외부로부터는 접근이 차단되어 있어야 하지만, 웹 계층에서 데이터베이스로의 접근은 허용해야 합니다.
• 따라서 이 규칙은 웹 계층이 데이터베이스와 통신할 수 있도록 올바르게 설정된 규칙입니다.

D. 데이터베이스 계층에 대한 보안 그룹을 구성하여 포트 443 및 1433에서 웹 계층에 대한 아웃바운드 트래픽을 허용합니다.

• 데이터베이스 계층은 주로 웹 계층에서 접근을 받아야 하기 때문에, 아웃바운드 트래픽 규칙은 중요하지 않습니다. 데이터베이스는 외부로 나가는 트래픽보다는 인바운드 트래픽 설정이 더 중요합니다.
• 특히, 포트 443(HTTPS)는 데이터베이스 서버와 관련이 없으므로 이 설정은 적절하지 않습니다.
• 포트 1433만 웹 계층에서 데이터베이스로의 연결에 필요하므로, 이 규칙은 불필요한 설정입니다.

E. 웹 계층의 보안 그룹에서 포트 443 및 1433의 인바운드 트래픽을 허용하도록 데이터베이스 계층에 대한 보안 그룹을 구성합니다.

• 이 규칙은 데이터베이스 계층에 포트 443(HTTPS)와 1433(SQL Server) 트래픽을 모두 허용하는 설정을 의미합니다.
• 하지만 데이터베이스 서버는 외부에서 직접적으로 접근할 필요가 없으며, 웹 계층에서만 접근 가능해야 합니다. 따라서 포트 443을 허용하는 것은 적절하지 않습니다.
• 이 규칙도 적절하지 않으며, 데이터베이스는 웹 계층에서의 포트 1433 접근만 허용하면 됩니다.

문제 8 : 전자 상거래 회사에 Amazon API Gateway와 AWS Lambda 함수를 사용하는 주문 처리 애플리케이션이 있습니다. 애플리케이션은 Amazon Aurora PostgreSQL 데이터베이스에 데이터를 저장합니다. 최근 판매 이벤트 중에 고객 주문이 갑자기 급증했습니다. 일부 고객은 시간 초과를 경험했으며 애플리케이션은 해당 고객의 주문을 처리하지 않았습니다. 솔루션 설계자는 많은 수의 열린 연결로 인해 데이터베이스에서 CPU 사용률과 메모리 사용률이 높다고 판단했습니다. 솔루션 설계자는 응용 프로그램에 대한 가능한 최소한의 변경으로 작업을 수행하는 동안 시간 초과 오류를 방지해야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

A. Lambda 함수에 대한 프로비저닝된 동시성 구성. 여러 AWS 리전에서 글로벌 데이터베이스가 되도록 데이터베이스 수정

• Lambda의 프로비저닝된 동시성은 특정한 수의 함수를 미리 준비해 두어 높은 트래픽에 대응할 수 있도록 하는 기능입니다. 이는 애플리케이션 성능을 개선하는 데 유용할 수 있습니다.
• 그러나 여러 AWS 리전에서 글로벌 데이터베이스로 설정하는 것은 성능 문제를 해결하는 데 있어 과도한 변경일 수 있으며, 데이터베이스의 복잡성을 증가시킵니다.
• 이 옵션은 비효율적이며 요구 사항을 충족하지 않습니다.

B. Amazon RDS 프록시를 사용하여 데이터베이스에 대한 프록시 생성. 데이터베이스 대신 RDS 프록시 엔드포인트를 사용하도록 Lambda 함수 수정

• RDS 프록시는 Lambda 함수가 데이터베이스와 연결을 보다 효율적으로 관리할 수 있도록 도와줍니다. 데이터베이스와의 연결을 풀링하여 CPU와 메모리 사용량을 줄이고, 연결 초과로 인한 과부하를 방지할 수 있습니다.
• 또한 Lambda 함수가 데이터베이스 대신 프록시 엔드포인트를 사용하도록 하면, 연결 수가 줄어들고 성능이 개선됩니다.
• 이 옵션은 데이터베이스의 과부하 문제를 해결하는 데 매우 효과적입니다.

C. 다른 AWS 리전의 데이터베이스에 대한 읽기 전용 복제본 생성. API Gateway의 쿼리 문자열 파라미터를 사용하여 트래픽을 읽기 전용 복제본으로 라우팅

• 읽기 전용 복제본을 생성하여 읽기 트래픽을 처리하는 것은 성능을 분산하는 데 유용합니다. 하지만 이 문제는 주문 처리와 관련된 데이터베이스의 쓰기 작업에 초점을 두고 있으므로 읽기 전용 복제본만으로는 문제를 완전히 해결하지 못합니다.
• API Gateway의 쿼리 문자열 파라미터를 통해 트래픽을 복제본으로 라우팅하는 방식은 적절하지 않으며, 이 문제 해결에 맞지 않는 솔루션입니다.

D. AWS Database Migration Service(AWS DMS)를 이용해 Aurora PostgreSQL에서 Amazon DynamoDB로 데이터 마이그레이션. DynamoDB 테이블을 사용하도록 Lambda 함수 수정

• DynamoDB로의 마이그레이션은 Aurora PostgreSQL의 성능 문제를 해결할 수 있지만, 이는 대규모의 구조적 변경을 의미합니다. 문제에서 요구하는 ‘최소한의 변경’이라는 조건과 맞지 않으며, 주문 처리 애플리케이션의 데이터 구조에 큰 영향을 미칩니다.
• 이 옵션은 비효율적이며 과도한 수정이 필요합니다.