개념정리
Amazon SNS[Simple Notification Service]
- 개념 : Amazon SNS [Simple Notification Service]는 AWS에서 제공하는 완전 관리형 메시징 서비스로, 발행/구독 모델(Pub/Sub)을 기반으로 합니다. 이 서비스는 메시지를 여러 애플리케이션이나 사용자들에게 동시에 전송하는 것을 목적으로 설계되었습니다.
- 주요 기능:
- 발행/구독 모델:
- 발행자 [Publisher]는 SNS 주제(Topic)에 메시지를 발행하고, 구독자 [Subscriber]는 그 주제를 구독하여 메시지를 받습니다.
- 여러 구독자가 동일한 주제를 구독할 수 있으며, 발행자가 주제에 메시지를 발행하면 구독자들에게 동시에 전송됩니다.
- 알림 전송:
- 이메일, SMS(문자 메시지), 푸시 알림(모바일 기기로), HTTP/HTTPS, AWS Lambda, SQS 같은 다양한 형식으로 메시지를 전송할 수 있습니다.
- 예를 들어, 특정 이벤트가 발생하면 관련 알림을 여러 채널을 통해 자동으로 전송할 수 있습니다.
- 확장성:
- SNS는 AWS의 관리형 서비스로, 사용자는 인프라를 관리할 필요 없이 서비스의 확장성을 활용할 수 있습니다. 수백만 건의 메시지도 쉽게 전송 가능하며, 트래픽의 증가에 따라 자동으로 확장됩니다.
- 다양한 통합:
- SNS는 AWS Lambda, Amazon SQS 등 다른 AWS 서비스와 쉽게 통합할 수 있어 유연한 아키텍처를 구성할 수 있습니다. 예를 들어, SNS를 통해 발송된 메시지를 SQS에서 큐로 받아 대기시키거나 Lambda를 통해 실시간으로 처리할 수 있습니다.
- 사용 예시:
- 알림 시스템:
- 애플리케이션에서 오류가 발생하거나, 새로운 이벤트가 발생했을 때 관리자나 사용자에게 즉시 알림을 보내는 데 사용됩니다.
- 모바일 푸시 알림:
- 모바일 애플리케이션의 사용자에게 새로운 업데이트나 뉴스 알림을 전송하는 데 사용할 수 있습니다.
- 이벤트 중심 아키텍처:
- 애플리케이션 간의 메시지 전달에 SNS를 사용해 이벤트 기반으로 동작하는 아키텍처를 구성할 수 있습니다. 예를 들어, SNS 주제를 구독한 여러 시스템이 메시지를 받고 작업을 수행하게 할 수 있습니다.
- 멀티 채널 알림:
- 하나의 SNS 주제에 여러 구독 채널을 설정해 이메일, SMS, HTTP 등 다양한 방식으로 메시지를 동시에 전송할 수 있습니다.
- 알림 시스템:
- 발행/구독 모델:
AD[Active Directory]
- 개념 : Microsoft에서 개발한 디렉터리 서비스로, 조직 내의 네트워크 리소스(사용자, 컴퓨터, 그룹, 프린터 등)를 관리하고 보안 및 접근 제어를 제공하는 중앙 집중식 관리 시스템입니다.
- 주요 기능 :
- 사용자 및 그룹 관리
- AD는 사용자 계정을 생성, 수정, 삭제하고 권한을 부여하는 역할을 합니다. 이 계정들은 하나의 중앙 서버에서 관리되며, 그룹화하여 권한을 설정할 수 있습니다.
- 도메인 서비스 (Active Directory Domain Services, AD DS)
- AD DS는 네트워크의 기본적인 디렉터리 서비스로, 사용자 인증 및 권한 부여를 제공합니다. 도메인에 가입한 사용자들은 자신이 속한 네트워크 내에서 하나의 사용자 이름과 비밀번호로 여러 리소스에 접근할 수 있습니다.
- 그룹 정책 관리 (Group Policy)
- Active Directory를 통해 조직 내 컴퓨터와 사용자들에게 적용되는 보안 설정 및 관리 규칙을 중앙에서 설정할 수 있습니다. 이를 그룹 정책(Group Policy)이라 하며, 조직의 보안 규정이나 컴퓨터 사용 정책을 일관성 있게 적용하는 데 유용합니다.
- LDAP 지원
- AD는 LDAP(Lightweight Directory Access Protocol)을 지원하여 디렉터리 서비스에 대한 표준화된 접근 방법을 제공합니다. 이를 통해 다른 애플리케이션 및 시스템과 통합이 가능하며, 다양한 플랫폼에서 AD를 사용할 수 있게 합니다.
- 도메인 컨트롤러
- 도메인 컨트롤러(Domain Controller, DC)는 AD 데이터베이스를 호스팅하고, 사용자 인증 및 권한 관리를 수행하는 서버입니다. 여러 DC를 구성하여 고가용성과 부하 분산을 제공할 수 있습니다.
- SSO(싱글 사인 온)
- 온프레미스 AD는 SSO 기능을 제공하여, 한 번의 로그인으로 동일 네트워크 내의 다양한 리소스에 접근할 수 있게 합니다. 이를 통해 사용자 경험을 개선하고 보안성을 높일 수 있습니다.
- 사용자 및 그룹 관리
- 온프레미스 Active Directory의 장점
- 중앙 집중식 관리: 모든 사용자, 컴퓨터, 리소스를 한 곳에서 관리할 수 있어 조직 규모가 커질수록 관리 효율성이 향상됩니다.
- 보안 강화: 사용자 권한을 중앙에서 제어하고, 그룹 정책을 통해 보안 설정을 일관되게 적용할 수 있습니다.
- 내부망에서 동작: 온프레미스 AD는 내부 네트워크에서 운영되므로, 클라우드에 비해 인터넷 기반 위협에 덜 노출됩니다.
- 온프레미스 Active Directory의 단점
- 유지 관리 비용: 물리적 서버 설치, 유지 보수, 소프트웨어 업데이트 및 백업 관리에 대한 비용이 발생합니다.
- 확장성 제한: 클라우드 기반 AD와 비교했을 때, 물리적 인프라의 한계로 인해 대규모 확장이 복잡하거나 비효율적일 수 있습니다.
- 원격 근무 환경 지원 부족: 원격 근무자들이 사무실 외부에서 네트워크에 접근하려면 VPN 같은 추가적인 인프라를 구축해야 하므로 클라우드 기반 디렉터리 서비스에 비해 불편할 수 있습니다.
엣지 로케이션[Edge Location]
- 개념 :
- Amazon Web Services[AWS]에서 제공하는 데이터 전송 가속을 위한 물리적 인프라 위치로, 주로 Amazon CloudFront나 AWS Global Accelerator 같은 서비스와 함께 사용됩니다.
- 엣지 로케이션은 전 세계에 분산되어 있으며, 사용자와 가까운 곳에서 콘텐츠를 캐싱하고 요청을 처리하여 웹사이트나 애플리케이션의 응답 속도를 크게 개선하는 역할을 합니다.
- 엣지 로케이션의 주요 기능
- 콘텐츠 캐싱:
- Amazon CloudFront와 함께 엣지 로케이션은 자주 요청되는 정적 콘텐츠(예: 이미지, CSS 파일, JavaScript 파일 등)를 캐싱합니다. 이 캐싱된 콘텐츠는 사용자가 엣지 로케이션에 요청할 때마다 빠르게 제공되어, 원본 서버에 요청하지 않고도 빠른 응답을 받을 수 있습니다.
- 지연 시간 감소:
- 엣지 로케이션은 사용자와 가까운 물리적 위치에 있기 때문에, 사용자는 인터넷을 통해 멀리 있는 원본 서버에 요청을 보내지 않아도 됩니다. 이를 통해 지연 시간이 줄어들고, 사용자 경험이 향상됩니다.
- Lambda@Edge와의 통합:
- Lambda@Edge는 엣지 로케이션에서 서버리스 코드를 실행할 수 있게 해줍니다. 이를 통해 엣지에서 사용자 요청을 처리하고, 실시간으로 콘텐츠를 변경하거나 데이터 변환 작업을 수행할 수 있습니다.
- 전송 속도 최적화:
- 엣지 로케이션은 AWS Global Accelerator와도 통합되어 전 세계적으로 사용자에게 더 빠른 네트워크 경로를 제공함으로써 전송 속도를 최적화할 수 있습니다.
- DDoS 보호 및 보안 강화:
- AWS의 AWS Shield와 AWS WAF(Web Application Firewall)는 엣지 로케이션과 통합되어, DDoS 공격이나 악의적인 트래픽을 엣지 로케이션에서 차단할 수 있습니다. 이를 통해 클라우드 인프라가 더 안전해지고, 공격으로 인한 피해를 줄일 수 있습니다.
- 콘텐츠 캐싱:
- 엣지 로케이션의 활용 사례
- 콘텐츠 전송 네트워크 (CDN):
- 엣지 로케이션은 CDN으로 활용됩니다. CloudFront를 사용하여 웹사이트나 애플리케이션의 정적 콘텐츠를 전 세계 엣지 로케이션에 배포하면, 사용자와 가까운 위치에서 캐싱된 데이터를 제공할 수 있어 빠른 로딩 속도를 보장합니다.
- 비디오 스트리밍:
- 비디오 스트리밍 서비스는 엣지 로케이션을 통해 사용자에게 더 빠르고 일관된 스트리밍 품질을 제공합니다. 사용자가 엣지 로케이션을 통해 비디오 콘텐츠를 받기 때문에, 원본 서버에서 직접 데이터를 받는 것보다 지연 시간이 적습니다.
- 실시간 분석 및 처리:
- Lambda@Edge를 활용해 실시간으로 분석 및 처리를 수행할 수 있습니다. 예를 들어, 엣지 로케이션에서 사용자의 요청을 처리하고, 요청 데이터를 기반으로 실시간 개인화된 콘텐츠를 제공할 수 있습니다.
- 지리적 제약을 둔 콘텐츠 제공:
- 엣지 로케이션을 통해 사용자 지역에 따라 콘텐츠를 다르게 제공할 수 있습니다. 예를 들어, 특정 지역의 사용자에게만 특정 콘텐츠를 제공하는 방식으로 활용할 수 있습니다.
- 콘텐츠 전송 네트워크 (CDN):
Lambda@Edge
- 개념 :
- Amazon Web Services(AWS)에서 제공하는 서버리스 컴퓨팅 서비스로, Amazon CloudFront와 통합되어 엣지 로케이션(Edge Location)에서 코드를 실행할 수 있는 기능을 제공합니다.
- 이를 통해 사용자 요청에 가까운 위치에서 코드가 실행되므로, 전 세계적으로 사용자에게 더 빠르고 개인화된 콘텐츠를 제공할 수 있습니다.
- Lambda@Edge의 주요 기능
- 엣지 로케이션에서의 코드 실행:
- Lambda@Edge는 AWS의 글로벌 엣지 네트워크에서 코드가 실행됩니다. CloudFront 엣지 로케이션에서 코드를 실행하므로, 사용자와 가까운 위치에서 트래픽을 처리할 수 있어 응답 시간이 단축됩니다.
- 사용자 요청 처리:
- Lambda@Edge는 CloudFront가 전송하는 HTTP 요청 또는 응답을 수정할 수 있는 기능을 제공합니다. 사용자는 요청에 대한 응답을 조정하거나 콘텐츠를 개인화할 수 있습니다. 이를 통해 동적으로 콘텐츠를 생성하거나, 특정 요청을 캐싱에서 제외하는 등의 작업이 가능합니다.
- 데이터 변환 및 콘텐츠 조작:
- Lambda@Edge는 요청 및 응답을 처리하면서 실시간으로 데이터를 변환하거나 콘텐츠를 조작할 수 있습니다. 예를 들어, 요청된 이미지의 해상도를 변경하거나, 텍스트 파일을 압축해 전송할 수 있습니다.
- 전 세계적인 가용성:
- Lambda@Edge는 AWS의 엣지 로케이션에서 동작하므로, 글로벌 사용자들에게 일관된 성능을 제공합니다. 콘텐츠가 사용자와 가까운 위치에서 처리되기 때문에, 지리적으로 분산된 사용자에게도 빠른 응답 시간을 제공합니다.
- 서버리스 환경:
- Lambda@Edge는 서버리스 환경이기 때문에 사용자는 서버를 관리할 필요 없이 코드 실행에만 집중할 수 있습니다. AWS에서 자동으로 인프라를 관리하고, 코드 실행에 따른 비용만 지불하면 됩니다. 코드가 실행되지 않는 시간 동안에는 비용이 발생하지 않으므로 매우 효율적입니다.
- 엣지 로케이션에서의 코드 실행:
- Lambda@Edge의 활용 사례
- 실시간 콘텐츠 개인화:
- 사용자의 위치, 브라우저 정보, 쿠키 등에 기반해 동적으로 콘텐츠를 생성하거나 수정할 수 있습니다. 예를 들어, 사용자의 언어 설정에 따라 웹사이트의 언어를 자동으로 변경할 수 있습니다.
- 보안 강화:
- CloudFront 엣지에서 보안 관련 로직을 적용할 수 있습니다. 예를 들어, 요청을 필터링하여 특정 조건을 만족하지 않는 요청을 차단하거나, HTTP 헤더를 추가 또는 수정하여 보안을 강화할 수 있습니다.
- 이미지 및 파일 변환:
- 요청된 이미지의 해상도를 줄이거나 파일을 압축하여 전송할 수 있어 대역폭을 절약하고 전송 비용을 줄일 수 있습니다. 예를 들어, 모바일 사용자에게는 저해상도 이미지를 제공하고, 데스크탑 사용자에게는 고해상도 이미지를 제공할 수 있습니다.
- A/B 테스트 및 리다이렉션:
- 웹사이트에서 A/B 테스트를 실행하거나 사용자를 다른 페이지로 리다이렉트하는 로직을 엣지에서 처리할 수 있습니다. 이를 통해 서버 부하를 줄이고, 빠른 결과를 제공할 수 있습니다.
- 실시간 콘텐츠 개인화:
- Lambda@Edge의 장점
- 저지연 응답: 사용자와 가까운 엣지에서 코드가 실행되므로, 요청 처리 시간이 크게 줄어듭니다.
- 서버리스: 인프라를 관리할 필요 없이 코드 실행에만 집중할 수 있으며, 트래픽에 따라 자동으로 확장됩니다.
- 유연한 데이터 처리: HTTP 요청 및 응답을 실시간으로 조작할 수 있어 매우 유연하게 데이터를 처리할 수 있습니다.
- 글로벌 확장성: AWS의 글로벌 엣지 네트워크를 통해 전 세계적으로 사용자에게 빠른 서비스를 제공할 수 있습니다.
- Lambda@Edge의 제한 사항
- 제한된 실행 시간: Lambda@Edge 함수는 최대 5초 동안만 실행될 수 있습니다.
- 런타임 제한: 일부 AWS Lambda의 런타임 언어 및 기능이 Lambda@Edge에서는 제한될 수 있습니다.
- Cold Start 지연: Lambda 함수가 처음 호출될 때 발생하는 “콜드 스타트” 시간이 있을 수 있습니다. 다만, 이는 대부분의 서버리스 서비스에서 공통적으로 발생하는 현상입니다.
Amazon Aurora Serverless는
- 개념 :
- Amazon Aurora의 서버리스 버전으로, 자동으로 확장되고 축소되는 관계형 데이터베이스 서비스입니다.
- 기존 Aurora는 사용자가 고정된 크기의 인스턴스를 설정하고 관리해야 하지만, Aurora Serverless는 애플리케이션의 트래픽 변화에 따라 자동으로 데이터베이스의 용량을 조정해 줍니다.
- 이를 통해 사용자는 애플리케이션의 부하에 맞게 DB 인프라를 관리할 필요가 없어집니다.
- Amazon Aurora Serverless의 주요 특징:
- 자동 확장 (Auto-scaling):
- 트래픽 양에 따라 자동으로 용량을 확장하거나 축소합니다. 데이터베이스 연결 요청이 증가하면 필요한 만큼 용량을 자동으로 확장하고, 요청이 적어지면 용량을 축소하여 비용을 절감할 수 있습니다.
- 비동기적 컴퓨팅 모델:
- 서버리스 아키텍처는 데이터베이스의 특정 트리거에 반응하여 확장하는 방식이므로 사용자가 직접 서버나 인프라를 관리할 필요가 없습니다.
- 즉, 데이터베이스가 활성 상태일 때만 컴퓨팅 리소스를 소비하고, 비활성 상태일 때는 리소스를 사용하지 않으며 이에 대한 비용이 청구되지 않습니다.
- 유지 관리와 패치:
- Aurora Serverless는 관리형 서비스로, AWS가 백그라운드에서 패치, 백업, 복구 등을 자동으로 처리합니다. 사용자는 이러한 유지 관리 작업에 신경 쓰지 않고 데이터베이스의 성능에 집중할 수 있습니다.
- 사용 기반 과금:
- Aurora Serverless는 사용한 만큼만 비용을 지불합니다. 즉, DB가 활성 상태일 때만 Aurora Capacity Unit(ACU)이라는 단위로 비용이 청구됩니다. 필요할 때만 리소스를 사용하기 때문에 불필요한 비용 지출을 줄일 수 있습니다.
- 빠른 시작과 자동 일시 정지:
- 요청이 없는 동안에는 데이터베이스를 자동으로 일시 정지시킬 수 있으며, 새 요청이 들어오면 빠르게 다시 시작됩니다. 이를 통해 비용을 효율적으로 절감할 수 있습니다.
- PostgreSQL 및 MySQL 호환성:
- Aurora Serverless는 PostgreSQL과 MySQL을 지원하며, Aurora의 고성능 및 고가용성 기능을 서버리스 환경에서도 사용할 수 있습니다.
- 자동 확장 (Auto-scaling):
- Amazon Aurora Serverless의 사용 사례:
- 간헐적인 트래픽을 처리하는 애플리케이션:
- 애플리케이션의 트래픽이 일정하지 않고, 간헐적으로 폭발적으로 증가하는 경우(Aurora Serverless는 필요할 때 자동으로 확장하기 때문에 비용 효율적).
- 개발 및 테스트 환경:
- 개발 환경이나 테스트 환경에서는 항상 고성능 DB가 필요하지 않기 때문에, 서버리스 DB는 사용하지 않을 때 비용을 절약할 수 있어 적합합니다.
- 스타트업 및 스몰 비즈니스:
- 초기 단계의 애플리케이션에서는 DB 트래픽이 크게 변화할 수 있는데, 이 경우 서버 인프라를 유연하게 관리할 수 있습니다.
- 이벤트 기반 애플리케이션:
- 예를 들어, 특정 시간대에만 트래픽이 몰리는 이벤트 기반 애플리케이션에서 적합합니다. 이벤트가 발생할 때만 DB가 활성화되고, 그렇지 않을 때는 비활성 상태로 비용을 줄일 수 있습니다.
- 간헐적인 트래픽을 처리하는 애플리케이션:
- 장점:
- 자동 확장 및 축소로 트래픽 변화에 유연하게 대응.
- 사용한 만큼만 비용을 지불하기 때문에 비용 효율적.
- 관리형 서비스로 인프라 유지 관리 부담이 없음.
- 개발 환경이나 간헐적 트래픽 패턴을 가진 애플리케이션에 최적화.
- 단점:
- 대기 시간(Latency): Aurora Serverless가 대기 상태에서 다시 활성화될 때 약간의 대기 시간이 발생할 수 있습니다.
- 복잡한 트랜잭션 처리: Aurora Serverless는 고정된 성능을 보장하지 않으므로, 매우 복잡한 트랜잭션을 처리하는 대규모 데이터베이스에는 적합하지 않을 수 있습니다.
용어정리
Amazon EBS (Elastic Block Store)
- EBS는 고성능, 고신뢰성 블록 스토리지로, EC2 인스턴스에 연결하여 사용합니다.
- 인스턴스가 중지되거나 재부팅되더라도 데이터는 그대로 유지됩니다.
- SSD 기반(고성능 IOPS)과 HDD 기반(저비용 대용량) 옵션을 제공하여 다양한 워크로드에 맞출 수 있습니다.
- 주로 데이터베이스, ERP 시스템, 고성능 애플리케이션 등에 사용됩니다.
Amazon EC2 인스턴스 스토어
- EC2 인스턴스에 연결된 로컬 스토리지입니다.
- 매우 빠른 읽기/쓰기 성능을 제공하지만, 인스턴스가 중지되면 데이터는 소실됩니다.
- 주로 캐시, 임시 파일 저장소 등에 사용되며, 장기적인 데이터 보존이 필요하지 않은 경우에 적합합니다.
Amazon EFS (Elastic File System)
- 여러 EC2 인스턴스 간에 공유 가능한 파일 스토리지를 제공합니다.
- 자동 확장 기능이 있어 파일 시스템 크기를 동적으로 확장할 수 있습니다.
- 주로 웹 서버, 컨테이너 환경에서 여러 인스턴스가 동일한 파일에 접근해야 하는 워크로드에 적합합니다.
Amazon S3 (Simple Storage Service)
- 객체 스토리지로, 대규모 비정형 데이터를 저장하는 데 적합합니다.
- 파일이나 백업 데이터를 저장하기 위한 저비용의 신뢰성 높은 스토리지로 사용됩니다.
- 데이터베이스나 실시간 워크로드에는 적합하지 않습니다.
Amazon Inspector: 애플리케이션과 네트워크의 보안 취약점을 스캔하여 보안성을 높입니다.
Amazon Macie: 민감한 데이터를 자동으로 탐지하고, 데이터 보안 및 규제 준수를 돕습니다.
Amazon GuardDuty: AWS 환경에서 발생하는 이상 징후와 위협을 실시간으로 탐지하고 경고하여 보안 사고를 방지합니다.
문제풀이
문제 1 : 회사에 들어오는 메시지를 수집하는 응용 프로그램이 있습니다. 수십 개의 다른 응용 프로그램과 마이크로서비스가 이러한 메시지를 빠르게 소비합니다. 메시지 수는 급격히 줄어들고 때로는 초당 100,000개로 갑자기 증가합니다. 회사는 솔루션을 분리하고 확장성을 높이고자 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까? D
A. Amazon Kinesis Data Analytics
- Amazon Kinesis Data Analytics는 실시간 데이터를 처리할 수 있는 강력한 솔루션이지만, 여기서는 메시지 수가 급격히 증가하고 분리된 여러 애플리케이션에서 메시지를 소비할 필요가 있는 시나리오이므로, 메시지의 처리량과 확장성을 충분히 고려하지 않았습니다.
B. Auto Scaling 그룹의 Amazon EC2 인스턴스 수집 애플리케이션
- Auto Scaling을 사용하여 EC2 인스턴스를 확장하면 CPU 지표에 따라 처리 용량을 자동으로 늘릴 수 있습니다. 하지만 이는 확장성은 제공하지만 메시지 소비의 동시성 문제와 복잡성을 해결하는 데 제한적일 수 있습니다. 특히 마이크로서비스 환경에서는 다소 비효율적일 수 있습니다.
- EC2로 초당 10만개의 메시지 처리 불가능
C. 단일 샤드로 Amazon Kinesis Data Streams에 메시지 쓰기
- Amazon Kinesis Data Streams와 AWS Lambda를 사용한 이 구성은 확장성과 빠른 메시지 처리를 제공합니다. Lambda 함수를 이용하면 메시지를 사전 처리하고, DynamoDB에 저장함으로써 메시지의 손실을 막고 실시간으로 처리할 수 있습니다. 또한 샤드 기반의 확장성 덕분에 높은 트래픽을 처리할 수 있습니다.
D. Amazon SQS와 SNS를 사용하여 메시지 게시 및 소비
- SNS와 SQS를 사용하면 메시지를 다양한 소비자에게 브로드캐스트할 수 있고, 메시지 처리가 독립적으로 이루어질 수 있습니다. 이는 확장성과 분산된 시스템 구성에서 매우 적합합니다. 메시지 수가 급증할 때도 효과적으로 확장하여 여러 소비자 애플리케이션에서 메시지를 동시에 처리할 수 있습니다.
문제 2 : 회사에서 사용자에게 AWS 리소스에 대한 액세스 권한을 제공하려고 합니다. 회사는 1,500명의 사용자를 보유하고 있으며 회사 네트워크의 Active Directory 사용자 그룹을 통해 온-프레미스 리소스에 대한 액세스를 관리합니다. 그러나 회사는 사용자가 리소스에 액세스하기 위해 다른 ID를 유지해야 하는 것을 원하지 않습니다. 솔루션 설계자는 온프레미스 리소스에 대한 액세스를 유지하면서 AWS 리소스 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까? D
A. 회사 내 사용자별로 IAM 사용자를 생성하고 적절한 정책을 첨부
- 이 방법은 각 사용자를 개별적으로 IAM 사용자로 설정하는 방식으로, 1,500명 규모의 사용자를 가진 회사에서 비효율적일 수 있으며, 다중 ID 문제를 해결하지 못합니다. 이는 회사의 요구 사항을 충족하지 않습니다.
B. Active Directory 사용자 풀과 함께 Amazon Cognito 사용 적절한 정책이 연결된 역할 생성
- Amazon Cognito는 주로 웹 및 모바일 애플리케이션의 사용자 인증에 적합하며, 여기서의 요구 사항은 온프레미스 AD와 AWS 리소스를 통합 관리하는 것이므로 적합하지 않습니다.
C. 적절한 정책이 연결된 교차 계정 역할 정의 및 Active Directory 그룹에 역할 매핑
- 이 방법은 AD 그룹과 IAM 역할을 연계하여 AWS 리소스에 액세스할 수 있게 하는 방식입니다. 이를 통해 AD 그룹의 역할에 따라 AWS 액세스를 제어할 수 있으며, 온프레미스 ID를 유지하면서 AWS 리소스를 통합적으로 관리할 수 있습니다. 이 방법은 적절하지만 더 효율적인 방식이 있습니다.
- 온프레미스 AD와 통합 불가
D. SAML(Security Assertion Markup Language) 2.0 기반 페더레이션 구성, 적절한 정책이 연결된 역할 생성, Active Directory 그룹에 역할 매핑
- SAML 2.0을 사용한 페더레이션 방식은 온프레미스 Active Directory와 AWS를 통합하는 가장 표준적이고 효율적인 방식입니다. 이 방식은 AD에서 인증된 사용자가 AWS에 액세스할 때 추가적인 ID를 만들지 않고도 단일 로그인(SSO)을 통해 AWS 리소스를 접근할 수 있게 합니다. Active Directory 그룹과 역할을 매핑하여 정책을 설정할 수 있어 확장성과 관리가 용이합니다.
문제 3 :회사의 패키지 애플리케이션은 사용자 요청에 대한 응답으로 일회용 텍스트 파일을 동적으로 생성하고 반환합니다. 회사는 배포용으로 Amazon CloudFront를 사용하고 있지만 데이터 전송 비용을 추가로 줄이려고 합니다. 회사는 애플리케이션의 소스 코드를 수정할 수 없습니다.
솔루션 설계자는 비용을 줄이려면 어떻게 해야 합니까? A
A. Lambda@Edge를 사용하여 사용자에게 전송되는 파일을 압축
- Lambda@Edge는 CloudFront의 엣지 로케이션에서 실행되는 서버리스 컴퓨팅 서비스입니다. Lambda@Edge는 데이터를 사용자에게 전송하기 전에 엣지에서 처리할 수 있으며, 파일 압축을 통해 전송 크기를 줄일 수 있습니다. 이렇게 하면 데이터 전송량이 줄어들어 전송 비용을 절감할 수 있습니다. 압축을 통해 데이터 크기를 줄이는 것은 전송 비용 절감의 효과적인 방법입니다.
B. Amazon S3 Transfer Acceleration을 활성화하여 응답 시간 단축
- S3 Transfer Acceleration은 S3에 파일을 업로드하거나 다운로드할 때 더 빠르게 전송할 수 있는 기능입니다. 이 기능은 네트워크 지연을 줄이기 위한 목적이기 때문에 전송 시간을 단축할 수는 있지만, 비용을 줄이기 위한 방법은 아닙니다. 오히려 추가 비용이 발생할 수 있습니다.
C. CloudFront 배포에서 캐싱을 활성화하여 생성된 파일을 엣지에 저장
- CloudFront는 본래 캐싱 기능을 가지고 있어 자주 요청되는 콘텐츠를 엣지에서 제공함으로써 서버 부하를 줄이고 성능을 향상시킬 수 있습니다. 하지만 문제에서 언급된 “일회용 텍스트 파일”을 다루는 상황에서는 캐싱이 큰 도움이 되지 않을 수 있습니다. 캐싱은 정적 콘텐츠에 유리하지만, 동적으로 생성되는 일회용 파일에는 적합하지 않습니다.
D. Amazon S3 멀티파트 업로드를 사용하여 파일을 사용자에게 반환하기 전에 Amazon S3로 이동
- 멀티파트 업로드는 대용량 파일을 나누어 업로드하는 기능으로, 데이터 전송 속도 및 안정성을 높여주는 기술입니다. 하지만 여기서는 파일을 사용자에게 반환할 때 멀티파트 업로드를 사용하는 것이므로, 비용 절감보다는 업로드 최적화에 관련된 기능입니다. 문제의 조건과는 적합하지 않습니다.
문제 4 : 회사는 이전에 데이터 웨어하우스 솔루션을 AWS로 마이그레이션했습니다. 회사에 AWS Direct Connect 연결이 있습니다. 회사 사무실 사용자는 시각화 도구를 사용하여 데이터 웨어하우스를 쿼리합니다. 데이터 웨어하우스에서 반환되는 쿼리의 평균 크기는 50MB이고 시각화 도구는 약 500KB입니다. 데이터 웨어하우스에서 반환된 결과 집합이 캐시되지 않습니다. 회사에 가장 낮은 데이터 전송 송신 비용을 제공하는 솔루션은 무엇입니까? D
A. 온프레미스에서 시각화 도구를 호스팅하고 인터넷을 통해 직접 데이터 웨어하우스를 쿼리
- 이 경우 인터넷을 통해 데이터 웨어하우스에 접근하게 되므로, 트래픽이 인터넷을 통해 전송되어 보안성 및 비용 면에서 비효율적일 수 있습니다. 특히 데이터 전송량이 크다면 송신 비용도 많이 발생할 수 있습니다.
B. 데이터 웨어하우스와 동일한 AWS 리전에서 시각화 도구 호스팅 인터넷을 통해 액세스
- 시각화 도구를 데이터 웨어하우스와 동일한 리전에 호스팅하고 인터넷을 통해 액세스하는 방법입니다. 이 방법은 인터넷을 통해 접근하므로 전송 비용이 많이 발생할 수 있습니다. 또한, 데이터 웨어하우스와의 직접 연결을 활용하지 못해 네트워크 효율성이 떨어집니다.
C. 온프레미스에서 시각화 도구를 호스팅하고 동일한 AWS 리전의 위치에서 Direct Connect 연결을 통해 직접 데이터 웨어하우스를 쿼리
- 온프레미스에서 시각화 도구를 사용하면서 Direct Connect를 통해 AWS 데이터 웨어하우스와 연결하는 방법입니다. Direct Connect는 안정적이고 저렴한 네트워크 연결을 제공하므로 인터넷보다는 효율적이지만, 여전히 온프레미스에서 작업을 진행하므로 최적의 솔루션은 아닐 수 있습니다.
D. 데이터 웨어하우스와 동일한 AWS 리전에서 시각화 도구를 호스팅하고 동일한 리전의 위치에서 직접 연결을 통해 액세스
- 시각화 도구를 데이터 웨어하우스와 동일한 리전에 배치하고, Direct Connect를 사용하여 데이터를 주고받는 방법입니다. 동일한 리전에 배치하면 데이터 전송 비용을 줄일 수 있고, Direct Connect를 활용하면 네트워크 비용을 크게 절감할 수 있습니다. 또한 데이터 전송이 AWS 내부에서 이루어지므로 네트워크 효율성 및 비용 절감 측면에서 가장 이상적입니다.
'개발 > AWS' 카테고리의 다른 글
| [AWS - SAA] 개념정리 및 문제풀이 10일차 (1) | 2024.10.01 |
|---|---|
| [AWS-SAA] 개념정리 및 문제풀이 8일차 (1) | 2024.09.28 |
| [AWS - SAA] 개념정리 및 문제풀이 6일차 (2) | 2024.09.26 |
| [AWS-SAA] 개념정리 및 문제풀이 4일차 (2) | 2024.09.24 |
| [AWS - SAA] 개념정리 및 문제풀이 3일차 (8) | 2024.09.04 |