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

개념정리

Amazon Athena

• S3 데이터를 쿼리하기 위한 용도로 사용되고, 서버리스 방식으로 작동하기 때문에 서버를 설정하거나 관리할 필요가 없음
• 표준 SQL을 사용해 데이터를 분석할 수 있으며, 사용한 만큼만 요금이 부과
• 비정형 데이터 분석에 적합하며, 로그 분석, 클릭스트림 분석 등에 자주 사용

Amazon Redshift

• 데이터 웨어하우스 서비스로, 대규모 데이터 분석을 위한 빠르고 확장 가능한 솔루션 제공
• 대량의 데이터를 분석하고 쿼리하는 데 최적화된 구조로, 대규머 데이터 처리와 분석이 필요할 때 사용

Amazon QuickSight

• 클라우드 기반의 비즈니스 인텔리전스 서비스로, 데이터를 시각화하고 대시보드를 쉽게 생성할 수 있음

Amazon Kinesis Data Analytics

• 실시간으로 데이터를 처리하고 분석할 수 있는 서버리스 스트리밍 데이터 분석 서비스
• 실시간으로 데이터를 수진, 처리, 분석하여 즉각적인 인사이트를 제공

 Amazon S3에서 제공하는 객체 잠금 기능

• 거버넌스 모드
  • 해당 객체를 일반 사용자나 애플리케이션이 삭제하거나 수정할 순 없지만, 특별한 권한을 가진 계정은 이러한 보호를 무시하고 객체를 삭제할 수 있음
• 규정 준수 모드
  • 어떠한 사용자나 계정도 객체를 삭제하거나 수정할 수 없음
  • 규정 준수 요구사항을 충족하기 위해 데이터가 특정 기간 동안 반드시 보존되어야 하는 경우에 사용
  • 일단 설정되면, 잠금 기간이 끝나기 전까지는 데이터는 완전히 보호 

AWS Load Balancer

• Application Load Balancer [ALB]
  • 레벨 7 로드 밸런싱 : ALB는 OSI 모델의 애플리케이션에서 작동. 이를 통해 HTTP, HTTPS 요청의 내용을 기반으로 트래픽을 분산할 수 있음.
  • 정교한 라우팅 : 경로 기반 라우팅, 호스트 기반 라우팅, HTTP 헤더, 메소드, 쿠키 등을 기반으로 한 세분화된 트래픽 분산이 가능.
  • 웹 애플리케이션에 최적화 : ALB는 웹 애플리케이션과 마이크로서비스 아키텍처에 적합. 특히, 여러 서비스로 구성된 애플리케이션의 트래픽을 효율적으로 관리할 수 있음.
  • WebSocket 및 HTTP/2 지원 : 현대적인 웹 애플리케이션을 위한 기능 제공
  • 사용 사례 :
    • 경로 기반 또는 호스트 기반 라우팅이 필요한 웹 애플리케이션
    • 마이크로서비스 아키텍처에서의 서비스 간 통신
    • 사용자 요청을 특정 서비스나 컨테이너로 라우팅하는 경우
• Network Load Balancer [NLB]
  • 레벨 4 로드 밸런싱 : NLB는 OSI 모델의 전송 계층[4계층]에서 작동. TCP/UDP 트래픽을 처리하며, IP 주소와 포트 번호를 기반으로 트래픽을 분산.
  • 초저지연 : 매우 낮은 지연 시간으로 트래픽 처리 가능
  • 고성능 : 초당 수백만 개의 요청 처리 가능 및 고속의 트래픽 분산을 요구하는 애플리케이션에 적합
  • 고정 IP : Elastic IP와의 통합을 통해 고정 IP 주소 사용 가능
  • TLS 종료 : NLB는 TLS[TCP 기반의 SSL]를 해제하여 로드 밸런서에서 트래픽을 암호화 및 복호화 가능
  • 사용 사례 :
    • 높은 처리량이 요구되는 애플리케이션
    • TCP/UDP 기반 애플리케이션
    • 고정 IP 주소가 필요한 경우
    • 실시간 데이터 처리 애플리케이션
• Gateway Load Balancer [GWLB]
  • 패킷 인스펙션 : 게이트웨이 로드 밸런스는 네트워크 패킷을 검사하고 그에 따라 트래픽을 제어하는 역할을 함
  • 네트워크 서비스 통합 : 방화벽, 침입 탐지 시스템, 침입 방지 시스템 등 네트워크 기반 서비스와 통합하기에 적합
  • 레이어3 로드 밸런싱 : OSI 모델의 네트워크 계층[3계층]에서 작동
  • 사용 사례 :
    • 네트워크 보안 서비스와의 통합
    • 패킷 수준에서 트래픽을 관리해야 하는 네트워크 애플리케이션
    • VPC에서 외부 네트워크 보안 어플라이언스와의 연동
• Classic Load Balancer [CLB]
  • 레거시 서비스 : CLB는 이전 세대의 로드 밸런서로, EC2-Classic 네트워크에서 주로 사용
  • 레벨 4 및 레벨 7 로드 밸런싱 : HTTP, HTTPS, TCP, SSL 트래픽을 지원하며, 기본적인 로드 밸런싱 기능을 제공
  • 기본적인 로드 밸런싱 : 새로운 애플리케이션보다는 기존 애플리케이션에 주로 사용
  • 사용 사례 :
    • 기존의 레거시 애플리케이션
    • 최신 기능이 필요 없는 간단한 로드 밸런싱 환경

인메모리 데이터 구조 저장소 

• 데이터를 디스크 대신 메모리[RAM]에 저장하고 관리하는 시스템
• 이 방식은 데이터에 대한 엑세스 속도가 빠르기 때문에, 실시간 애플리케이션이나 고속 데이터 처리에 매우 유리함
• 고속 엑세스, 데이터 구조 지원, 고가용성 및 확장성, 데이터 지속성
• 사용 사례 : 캐싱, 세션 관리, 실시간 분석, 메시지 큐

문제 풀이

A. CloudFront 배포에서 네트워크 ACL을 수정하여 악성 IP 주소에 대한 거부 규칙을 추가합니다.

• CloudFront 배포에 대한 네트워크 ACL을 수정하는 것은 CloudFront 자체에 대한 접근을 제어할 수 있지만, AWS WAF를 통해 보다 세밀하게 제어할 수 있는 옵션이 있으므로, WAF를 사용하는 것이 더 나은 선택일 수 있습니다.

B. 악성 IP 주소를 차단하는 IP 일치 조건을 추가하도록 AWS WAF 구성 수정

• AWS WAF(웹 애플리케이션 방화벽)는 SQL 주입 공격과 같은 애플리케이션 레벨의 위협뿐만 아니라, IP 기반의 접근 제어도 제공합니다. 따라서 악성 IP를 차단하려면 AWS WAF에 IP 일치 조건을 추가하는 것이 가장 직접적이고 효율적인 방법입니다.

ALB 뒤의 대상 그룹에서 EC2 인스턴스에 대한 네트워크 ACL을 수정하여 악성 IP 주소를 거부합니다.

• 이 방법은 특정 네트워크 레벨에서 IP 차단을 수행할 수 있지만, 이는 애플리케이션 레벨에서의 공격 방어보다는 더 낮은 수준에서 제어됩니다. WAF를 사용하는 것보다는 덜 적합할 수 있습니다.

D. ALB 뒤의 대상 그룹에서 EC2 인스턴스의 보안 그룹을 수정하여 악성 IP 주소를 거부합니다.

• 보안 그룹은 네트워크 트래픽을 제어하는 데 사용되지만, WAF를 통해 더 정교한 접근 제어를 할 수 있는 상황에서 사용하기에는 덜 효율적입니다.

문제 : 온프레미스 데이터 센터와 AWS VPC 간의 연결을 최적화하여 매일 수 기가바이트의 데이터를 Amazon Kinesis Data Firehose로 전송하는 데 필요한 최적의 솔루션을 찾는 것이다. -> 중요한 고려 사항은 연결 속도와 안전성

 

A. 온프레미스 네트워크와 VPC 간에 VPC 피어링 연결을 생성합니다. VPC 피어링 연결을 사용하여 온프레미스 네트워크에 대한 라우팅을 구성합니다.

• VPC 피어링은 AWS 내의 두 VPC 간의 통신에 주로 사용되며, 온프레미스 네트워크와의 연결에는 적합하지 않습니다. 

B. AWS Snowball Edge Storage Optimized 장치를 조달합니다. 며칠 분량의 데이터가 누적된 후 데이터를 디바이스에 복사하고 Kinesis Data Firehose로의 신속한 전송을 위해 AWS로 디바이스를 배송하여 필요에 따라 반복합니다.

• Snowball Edge는 대량의 데이터를 물리적으로 AWS로 전송할 때 사용됩니다. 그러나 이 방법은 실시간 데이터 전송이 필요한 경우 적합하지 않으며, 매일 수 기가바이트의 데이터를 전송해야 하는 시나리오에서는 부적절합니다.

C. 온프레미스 네트워크와 VPC 간에 AWS Site-to-Site VPN 연결을 생성합니다. 고객 게이트웨이와 프라이빗 게이트웨이 간에 BGP 라우팅을 구성합니다. VPN 연결을 사용하여 온프레미스에서 Kinesis Data Firehose로 데이터를 보냅니다.

• Site-to-Site VPN은 온프레미스 네트워크와 AWS VPC 간의 안전한 연결을 제공하지만, 100Mbps 인터넷 연결에서는 대량의 데이터를 전송하는 데 성능이 제한될 수 있습니다.
• 온프레미스 네트워크와 AWS VPC 간에 Site-to-Site VPN을 설정할 때 BGP를 사용하여 양쪽 네트워크가 라우팅 정보를 자동으로 교환할 수 있도록 합니다. 이로 인해 네트워크 연결이 더 유연해지고, 라우팅 테이블을 수동으로 관리할 필요가 줄어듭니다. 

D. AWS PrivateLink를 사용하여 VPC에서 Kinesis Data Firehose용 인터페이스 VPC 엔드포인트를 생성합니다. 온프레미스 네트워크와 AWS 간에 1Gbps AWS Direct Connect 연결 설정. PrivateLink 엔드포인트를 사용하여 온프레미스에서 Kinesis Data Firehose로 데이터를 보냅니다.

• 이 옵션은 Direct Connect를 사용해 전용 회선으로 AWS와 온프레미스 간의 연결을 설정하는 것으로, 1Gbps의 높은 대역폭을 제공하여 대량의 데이터를 안정적이고 빠르게 전송할 수 있습니다. 또한 PrivateLink를 통해 VPC 내부의 서비스에 안전하게 접근할 수 있어 성능과 보안을 동시에 확보할 수 있습니다.

문제 : Amazon DynamoDB를 사용하는 애플리케이션에서 데이터를 복구하기 위한 솔루션을 설계할 때, 15분의 RPO(복구 시점 목표)와 1시간의 RTO(복구시간 목표)를 충족해야한다.

 

A. DynamoDB 글로벌 테이블을 구성합니다. RPO 복구의 경우 애플리케이션이 다른 AWS 리전을 가리키도록 합니다.

• DynamoDB 글로벌 테이블은 여러 리전에 걸쳐 데이터를 자동으로 복제하여 고가용성과 재해 복구를 지원합니다. 하지만 글로벌 테이블은 주로 여러 리전에 걸친 고가용성 및 저지연성을 위해 사용되며, RPO와 RTO 요건을 직접적으로 충족시키는 옵션으로 적합하지는 않을 수 있습니다.

B. DynamoDB 지정 시간 복구(Point-in-Time Recovery)를 구성합니다. RPO 복구의 경우 원하는 시점으로 복원합니다.

• DynamoDB의 Point-in-Time Recovery(PITR)는 지정된 시간 동안 테이블을 복원할 수 있는 기능입니다. 이 기능은 데이터 손실 발생 시, 특정 시점으로 테이블을 복구할 수 있도록 해주므로, 15분의 RPO와 1시간의 RTO 요구를 충족하는 데 매우 적합합니다.

C. DynamoDB 데이터를 매일 Amazon S3 Glacier로 내보냅니다. RPO 복구의 경우 S3 Glacier에서 DynamoDB로 데이터를 가져옵니다.

• S3 Glacier는 장기 데이터 보관을 위해 설계된 저렴한 스토리지 옵션입니다. 그러나 Glacier에서 데이터를 복구하는 데 시간이 오래 걸릴 수 있으며, 특히 RTO가 1시간인 경우 이 방식은 적합하지 않습니다.

D. 15분마다 DynamoDB 테이블에 대한 Amazon Elastic Block Store(Amazon EBS) 스냅샷을 예약하여 DynamoDB 테이블을 복원합니다.

• EBS 스냅샷은 EBS 볼륨의 백업을 생성하는 방법이지만, DynamoDB 테이블에 직접적으로 적용되지는 않습니다. 또한, 15분마다 스냅샷을 생성하는 것은 비용 효율적이지 않을 수 있으며, 데이터 복구 시간이 길어질 수 있습니다.

문제 : 이 문제는 온프레미스에서 운영 중인 MySQL 데이터베이스를 AWS로 마이그레이션할 때, 다운타임을 최소화하고 미래의 확장성을 고려하여 적합한 AWS 서비스를 선택하는 것입니다. 데이터베이스 관리자는 특정 인스턴스 유형을 선택하지 않고 유연성을 원하고 있습니다.

A. Amazon Aurora MySQL:

• Amazon Aurora는 고성능, 고가용성의 MySQL 및 PostgreSQL 호환 데이터베이스 서비스입니다. Aurora는 최대 15개의 읽기 복제본을 지원하고, 자동으로 장애 복구를 제공합니다. 그러나 서버리스가 아닌 일반 Aurora는 특정 인스턴스 유형을 선택해야 하며, 사용 패턴에 따른 유연성은 덜할 수 있습니다.

B. MySQL을 위한 Amazon Aurora Serverless:

• Aurora Serverless는 Amazon Aurora의 서버리스 옵션으로, 사용량에 따라 자동으로 확장하거나 축소할 수 있습니다. 데이터베이스 인스턴스가 항상 실행되지 않고 필요할 때만 시작되므로, 사용량이 예측 불가능하거나 간헐적인 경우에 적합합니다. 특정 인스턴스 유형을 선택할 필요가 없으며, 다운타임 없이 자동으로 조정됩니다.

C. Amazon Redshift 스펙트럼:

• Redshift 스펙트럼은 대규모 데이터 분석 작업에 사용되는 서비스로, S3에 저장된 데이터를 직접 쿼리할 수 있습니다. 이 옵션은 MySQL 데이터베이스 마이그레이션과는 관련이 없습니다.

D. MySQL용 Amazon RDS:

• Amazon RDS는 관리형 관계형 데이터베이스 서비스로, MySQL을 포함한 여러 데이터베이스 엔진을 지원합니다. 하지만 RDS에서는 특정 인스턴스 유형을 선택해야 하며, 자동 확장성이 제공되지 않기 때문에 Aurora Serverless에 비해 유연성이 떨어질 수 있습니다.

문제 : 이 문제는 파일을 다루는 온프레미스 애플리케이션을 AWS로 마이그레이션할 때, 스토리지의 확장성과 내구성을 유지하면서 애플리

케이션의 코드를 변경하지 않고 파일 시스템 권한을 관리하는 방법을 찾는 것입니다.

 

A. Amazon S3 버킷으로 파일 마이그레이션 EC2 인스턴스에 S3 버킷 탑재:

• Amazon S3는 객체 스토리지로, 주로 데이터 백업, 아카이빙, 정적 웹 호스팅 등에 사용됩니다. 그러나 S3는 파일 시스템 인터페이스를 제공하지 않기 때문에, 기존의 파일 시스템 권한을 활용할 수 없습니다. 따라서 이 옵션은 적합하지 않습니다.

B. 파일을 Amazon EC2 인스턴스 스토어 볼륨 세트로 마이그레이션 EC2 인스턴스에 인스턴스 스:

• 인스턴스 스토어는 EC2 인스턴스에 직접 연결된 임시 스토리지로, EC2 인스턴스가 종료되면 데이터가 사라집니다. 따라서 데이터 내구성이 요구되는 경우에 적합하지 않으며, 파일 스토리지로 사용하기에는 부적합합니다.

C. 파일을 Amazon Elastic Block Store(Amazon EBS) 볼륨 세트로 마이그레이션 EC2 인스턴스에 EBS 볼륨 탑재:

• Amazon EBS는 블록 스토리지로, EC2 인스턴스에 연결하여 사용됩니다. EBS는 파일 시스템으로 마운트하여 기존의 Linux 파일 시스템 권한을 그대로 사용할 수 있습니다. 그러나 EBS는 단일 EC2 인스턴스에만 연결할 수 있어 다수의 인스턴스에서 공유 스토리지를 사용해야 하는 경우에는 적합하지 않을 수 있습니다.

D. 파일을 Amazon Elastic File System(Amazon EFS) 파일 시스템으로 마이그레이션 EC2 인스턴스에 EFS 파일 시스템 탑재:

• Amazon EFS는 완전 관리형 네트워크 파일 시스템으로, 여러 EC2 인스턴스에서 동시에 접근할 수 있습니다. EFS는 NFS(Network File System) 프로토콜을 사용하여 기존의 Linux 파일 시스템 권한을 그대로 사용할 수 있으며, 확장성과 내구성 측면에서도 매우 유리합니다. 따라서 이 옵션은 기존의 애플리케이션 코드를 변경하지 않고도 요구 사항을 충족시킬 수 있습니다.

문제 : 이 문제는 EC2 인스턴스와 Amazon S3 간에 비공개 보안 연결을 설정해야 하는 상황에서 적절한 솔루션을 찾는 것입니다. 즉, 인터넷을 통하지 않고 VPC 내에서 직접 S3와 통신할 수 있는 방법을 설정하는 것이 목표입니다.

 

A. VPC 엔드 포인트에서의 액세스를 허용하도록 S3 버킷 정책을 설정합니다.

• VPC 엔드포인트는 VPC 내부에서 Amazon S3와 같은 AWS 서비스에 직접 접근할 수 있도록 해주는 기능입니다. 이를 통해 EC2 인스턴스가 인터넷을 거치지 않고 S3와 통신할 수 있으며, 이는 매우 안전한 방법입니다. S3 버킷 정책을 통해 VPC 엔드포인트에서의 액세스를 허용하면 VPC 내에서만 S3에 접근할 수 있습니다.

B. S3 버킷에 대한 읽기-쓰기 액세스 권한을 부여하는 IAM 정책을 설정합니다.

• IAM 정책은 사용자나 역할에 권한을 부여하지만, EC2 인스턴스와 S3 간의 네트워크 연결 방식은 제어하지 않습니다. 따라서 이 방법은 보안 연결을 설정하는 데 적합하지 않습니다.

C. 프라이빗 서브넷 외부의 리소스에 액세스하도록 NAT 게이트웨이를 설정합니다.

• NAT 게이트웨이는 프라이빗 서브넷의 인스턴스가 인터넷에 접근할 수 있도록 해줍니다. 그러나 NAT 게이트웨이는 인터넷 접근을 제공하는 것이므로, 비공개 보안 연결을 설정하려는 목적과는 맞지 않습니다.

D. S3 버킷에 액세스 하기 위한 액세스 키 ID 및 보안 액세스 키 설정

• 액세스 키와 보안 키는 인증 및 권한 부여를 위한 것이지, 네트워크 레벨의 보안 연결을 설정하는 데 직접적인 역할을 하지 않습니다.

문제 : 이 문제는 온프레미스에서 AWS S3로 지속적으로 대량의 데이터를 전송해야 하는 상황에서, 데이터 전송이 안정적이고 중단 없이 이

루어질 수 있는 솔루션을 선택하는 것입니다.

 

A. AWS Data Sync:

• AWS DataSync는 온프레미스 스토리지와 AWS 클라우드 간에 데이터 전송을 자동화하고 가속화하는 서비스입니다. 지속적인 데이터 전송을 지원하며, 네트워크의 간헐적인 중단에 대비해 데이터 전송을 자동으로 재개할 수 있는 기능을 제공합니다. 또한 DataSync는 데이터 전송 속도를 최적화하고, 대량의 데이터를 효율적으로 AWS로 전송할 수 있는 매우 적합한 솔루션입니다.

B. AWS Migration Hub:

• AWS Migration Hub는 다양한 AWS 마이그레이션 서비스와 도구를 관리하고 추적하는 데 사용됩니다. 이 서비스 자체는 데이터 전송을 직접 수행하지 않으며, 따라서 이 문제에 대한 적합한 솔루션이 아닙니다.

C. AWS Snowball Edge 스토리지 최적화:

• AWS Snowball Edge는 대량의 데이터를 물리적으로 AWS로 전송하는 장비입니다. 인터넷 연결 없이 대량 데이터를 이동시킬 수 있지만, 지속적인 데이터 전송을 자동화하거나 네트워크 중단을 처리하는 데에는 적합하지 않습니다. Snowball은 주로 한 번에 많은 양의 데이터를 마이그레이션할 때 사용됩니다.

D. AWS Transfer for SFTP:

• AWS Transfer for SFTP는 SFTP 프로토콜을 사용해 파일을 Amazon S3로 전송할 수 있게 해줍니다. 이 서비스는 FTP나 SFTP를 통해 데이터를 전송하는 데 적합하지만, 지속적인 데이터 동기화와 네트워크 중단 시 자동 복구 기능을 제공하는 것은 아닙니다.

문제 : 이 문제는 미디어 스트리밍 회사가 실시간 데이터를 처리하고 저장하는 데이터베이스 시스템에서 성능 문제를 겪고 있는 상황에서, 더 빠른 성능과 고가용성을 제공하는 인메모리 데이터베이스 솔루션을 찾고자 하는 것입니다.

 

A. MySQL용 Amazon RDS:

• Amazon RDS는 관리형 관계형 데이터베이스 서비스로, MySQL을 포함한 여러 데이터베이스 엔진을 지원합니다. 하지만 이 옵션은 디스크 기반 저장소를 사용하며, 문제에서 요구하는 인메모리 데이터베이스 솔루션은 아닙니다.

B. PostgreSQL용 Amazon RDS:

• 이 선택지도 MySQL용 Amazon RDS와 마찬가지로 디스크 기반 저장소를 사용하는 관계형 데이터베이스 서비스입니다. 실시간 데이터 처리에 필요한 인메모리 처리 능력은 제공하지 않습니다.

C. Redis용 Amazon ElastiCache:

• Redis는 인메모리 데이터 구조 저장소로, 매우 빠른 읽기 및 쓰기 성능을 제공합니다. 또한, Redis는 복제를 통해 고가용성을 지원하며, 실시간 데이터 처리에 매우 적합합니다. 이 솔루션은 문제에서 요구하는 인메모리 데이터베이스 솔루션에 가장 적합합니다.

D. Memcached용 Amazon ElastiCache:

• Memcached는 캐시 솔루션으로, Redis와 마찬가지로 인메모리 데이터베이스로 사용할 수 있습니다. 그러나 Memcached는 데이터 지속성을 제공하지 않으며, 복제와 같은 고급 기능이 부족하여 고가용성 요구사항을 충족하기에 적합하지 않을 수 있습니다.