엔지니어링 팀에서 차기 프로젝트를 위해 Amazon EC2의 사용자 데이터 기능에 대한 활용 가능성을 조사하려고 합니다.
다음 중 EC2 사용자 데이터 설정에 대한 설명으로 옳은 것은 무엇입니까? (2개를 고르시오.)
일반적으로 사용자 데이터는 공통 자동 구성 작업을 수행하는 데 사용되며 인스턴스가 시작된 후에라도 스크립트를 실행하는 데 사용됩니다. Amazon EC2에서 인스턴스를 실행할 때 여러분은 쉘 스크립트와 cloud-init 명령 등 두 가지 유형의 사용자 데이터를 제공할 수 있습니다. 여러분은 플레인 텍스트 또는 파일 형태로 실행 마법사에 그러한 데이터를 제공할 수도 있습니다.
사용자 데이터로 입력된 스크립트는 기본적으로 루트 사용자 권한으로 실행된다. - 사용자 데이터로서 입력된 스크립트는 루트 사용자 권한으로 실행되며, 따라서 스크립트에 sudo 명령을 쓸 필요가 없습니다. 여러분이 생성한 모든 파일은 루트가 소유하며, 루트 사용자 이외의 사용자가 파일에 액세스해야 한다면 스크립트에서 적절히 권한을 수정해야 합니다.
사용자 데이터는 기본적으로 인스턴스를 처음 시작할 때의 부팅 주기 동안만 실행된다. - 기본값으로서, 사용자 데이터 스크립트와 cloud-init 명령은 여러분이 인스턴스를 최초로 실행할 때 부팅 사이클 중에만 실행됩니다. 여러분이 인스턴스를 재시작할 때마다 사용자 데이터 스크립트와 cloud-init 명령이 실행되도록 구성을 업데이트할 수 있습니다.
한 빅 데이터 처리 업체에서 처리 장치 간의 네트워크 성능이 좋을 때 최상의 성능을 발휘하는 분산 데이터 처리 프레임워크를 구축했습니다. 애플리케이션은 AWS에 배포되어야 하며 회사는 성능만을 주요 지표로 보고 있습니다.
솔루션 아키텍트로서 어떤 배포 방법을 제안하시겠습니까?
새로운 EC2 인스턴스를 실행하면 EC2 서비스는 연관된 고장을 최소화하기 위해 여러분의 모든 인스턴스를 기본 하드웨어에 걸쳐 분산시키는 방식으로 인스턴스를 배치하려 합니다. 여러분은 배치 그룹을 이용하여, 워크로드 수요를 충족하기 위해 상호의존적인 인스턴스 그룹의 배치에 영향을 미칠 수 있습니다. 워크로드의 유형에 따라, 다음 배치 전략 중 하나를 이용하여 배치 그룹을 만들 수 있습니다.
클러스터 – 가용 영역(AZ) 안에서 인스턴스들을 가까이 배치합니다. 이러한 전략을 사용하면 HPC 애플리케이션에 흔히 사용되는 밀접하게 커플링된 노드 간 통신에 필요한 저레이턴시 네트워크 성능을 워크로드가 달성할 수 있습니다.
파티션 – 여러분의 인스턴스를 논리 파티션에 걸쳐 분산시켜 하나의 파티션 안의 인스턴스 그룹들이 다른 파티션에 있는 인스턴스 그룹들과 기본 하드웨어를 공유하지 않게 됩니다. 이러한 전략은 흔히 Hadoop, Cassandra, Kafka 같은 대규모 분산 및 복제 워크로드에 의해 사용됩니다.
분산 - 상호 연관에 따른 실패를 줄이기 위해 구분되는 기본 하드웨어에 작은 인스턴스 그룹들을 엄격하게 배치합니다.
배치 그룹 생성에 대한 요금은 없습니다.
클러스터 배치 그룹을 사용한다. - 클러스터 배치 그룹은 하나의 가용 영역 안에서 인스턴스들을 논리적으로 그룹화하는 것입니다. 클러스터 배치 그룹은 동일한 리전(Region)에서 유사한(peered) VPC들 간에 걸쳐 있을 수 있습니다. 동일한 클러스터 배치 그룹에 있는 인스턴스들은 TCP/IP 트래픽에 대해 최대 10Gbps의 높은 플로우당 처리 속도 한도를 누리고 네트워크의 동일한 높은 이분(high bi-section) 대역폭에 배치됩니다.
클러스터 배치 그룹은 낮은 네트워크 레이턴시, 높은 네트워크 처리 속도 또는 둘 다에서 이득을 얻을 수 있는 애플리케이션에 권장합니다. 네트워크 트래픽의 대부분이 그룹 내 인스턴스 간 트래픽인 경우에도 권장됩니다. 배치 그룹에 가장 낮은 레이턴시와 가장 높은 초당 패킷 네트워크 성능을 제공하기 위해서는 고급 네트워킹을 지원하는 인스턴스 타입을 선택하십시오.
한 온라인 게임 선도 기업에서 자사의 온라인 게임을 전 세계 사용자들에게 제공하기 위하여 주력 애플리케이션을 AWS 클라우드로 이전하고 있습니다. 회사는 네트워크 로드 밸런서(NLB)를 사용해 초당 수백만의 요청을 처리하고자 합니다. 엔지니어링 팀은 퍼블릭 서브넷에 여러 인스턴스를 프로비저닝하고 해당 인스턴스 ID를 NLB의 대상(Target)으로 지정했습니다.
솔루션 아키텍트의 관점에서 엔지니어링 팀이 위의 대상 인스턴스에 대한 올바른 라우팅 메커니즘을 이해하는 데 도움을 줄 수 있는 내용은 무엇입니까?
트래픽은 인스턴스의 기본(Primary) 네트워크 인터페이스에 지정된 기본 프라이빗 IP를 통해 인스턴스로 라우팅된다.
네트워크 로드 밸런서는 개방형 시스템 간 상호 접속(OSI) 모델의 네 번째 레이어에서 작동합니다. 네트워크 로드 밸런서는 초당 수백만 건의 요청을 처리할 수 있습니다. 밸런서는 연결 요청을 받은 후에 기본값 규칙에 부합되는 타깃 그룹에서 타깃을 선택합니다. 밸런서는 리스너 구성에 지정된 포트에서 선택된 타깃에 대한 TCP 연결을 열려고 시도합니다.
라우팅 및 IP 주소 요청 -
여러분이 인스턴스 ID를 이용하여 타깃을 명시하면, 인스턴스에 대한 기본 네트워크 인터페이스에 명시된 기본 사설 IP 주소를 이용하여 트래픽을 인스턴스로 라우팅합니다. 로드 밸런서는 데이터 패킷으로부터 목적지 IP 주소를 다시 기록하고 그것을 타깃 인스턴스에 전달합니다.
여러분이 IP 주소를 이용하여 타깃을 명시하면 여러분은 하나 이상의 네트워크 인터페이스에서 온 어떠한 사설 IP 주소를 이용해서도 인스턴스로 트래픽을 라우팅할 수 있습니다. 그렇게 하면 어떤 인스턴스의 다수의 애플리케이션이 동일한 포트를 사용할 수 있게 됩니다. 각각의 네트워크 인터페이스가 각자의 보안 그룹을 가질 수 있다는 점에 주의하십시오. 로드 밸런서는 데이터 패킷으로부터 목적지 IP 주소를 다시 기록하고 그것을 타깃 인스턴스에 전달합니다.
한 전자 상거래 기업의 엔지니어링 팀이 배치(batch)를 사용해 SQS 표준 대기열을 FIFO 대기열로 마이그레이션하려고 합니다.
솔루션 아키텍트로서 다음 중 마이그레이션 체크리스트에 포함해야 할 단계는 무엇입니까? (3개를 고르시오.)
기존에 있던 표준 대기열을 삭제하고 FIFO 대기열로 다시 생성한다.
FIFO 대기열의 이름 끝에 접미사로 끝나는지 확인한다.
대상 FIFO 대기열의 메시지 처리량이 초당 3,000개를 초과하지 않는지 확인한다.
Amazon Simple Queue Service(SQS)는 여러분이 마이크로서비스, 분산 시스템, 서버리스 애플리케이션을 디커플링하고 스케일링할 수 있게 해주는 완벽히 관리되는 메시지 대기열화 서비스입니다. SQS는 복잡성을 줄여주고 메시지에서 유래되는 미들웨어의 관리와 운영에 관련된 경상운영비를 줄여주며 개발자들이 차별화 업무에 집중할 수 있도록 역량을 강화해줍니다. 여러분은 SQS를 사용하여 메시지를 잃거나 다른 서비스를 사용할 필요 없이 모든 볼륨의 소프트웨어 컴포넌트 간에 메시지를 전송, 저장, 수신할 수 있습니다.
SQS는 두 가지 유형의 메시지 대기열을 제공합니다. 표준 대기열은 처리 속도가 극대화되고 순서가 최적화되며 최소한 한 번 전달이 이루어집니다. SQS FIFO 대기열은 메시지가 전송된 순서대로 정확히 한 번 처리되도록 보장하기 위해 고안되었습니다.
기본값으로서, FIFO 대기열은 배칭(batching)을 이용하여 초당 최대 3,000개의 메시지를 지원하거나 배칭 없이 초당 최대 300개의 메시지를 지원합니다(초당 300회의 전송, 수신 또는 삭제 작업). 그러므로 배칭을 사용하면 여러분은 초당 최대 3,000개의 메시지 처리 속도 요구사항을 충족할 수 있습니다.
FIFO 대기열의 이름은 .fifo라는 접미어로 끝나야 합니다.. 접미어도 80자라는 대기열 이름 한도에 포함됩니다. 어떤 대기열이 FIFO인지 결정하기 위해, 여러분은 대기열 이름이 그 접미어로 끝나는지 확인할 수 있습니다.
만일 표준 대기열을 사용하는 기존 애플리케이션이 있고, FIFO 대기열의 정렬(ordering) 또는 정확히 한 번(exactly-once) 처리 기능을 이용하고 싶다면 대기열과 애플리케이션을 정확히 구성해야 합니다. 기존의 표준 대기열을 FIFO 대기열로 변환할 수는 없습니다. 구성을 위해 여러분은 애플리케이션을 위해 새로운 FIFO 대기열을 만들거나 기존의 표준 대기열을 삭제하고 FIFO 대기열로서 새로 만들어야 합니다.
한 전자 상거래 기업의 엔지니어링 팀에 인프라를 서버리스 아키텍처로 마이그레이션하는 업무가 주어졌습니다. 엔지니어링 팀은 Lambda를 아키텍처 백본(backbone)으로 사용할 때 고려해야 할 주요 사항에 초점을 맞추고 있습니다.
솔루션 아키텍트의 관점에서 다음 중 주어진 요구 사항에 대해 맞게 설명한 것은 무엇입니까? (3개를 고르시오.)
기본적으로 Lambda 함수는 항상 AWS 소유의 VPC에서 동작하기 때문에 공용 인터넷 주소나 공용 AWS API에 접근할 수 있다. Lambda 함수가 VPC를 사용하도록 설정되어 있다면 퍼블릭 서브넷에서 NAT 게이트웨이를 통해 라우팅하여 퍼블릭 리소스에 접근해야 한다. - 람다 함수는 항상 AWS가 소유한 VPC로부터 작동합니다. 기본적으로 여러분의 함수는 모든 공용 인터넷 주소에 네트워크 요청을 할 완벽한 능력을 갖습니다. 여기에는 공용 AWS API에 대한 액세스도 포함됩니다. 예를 들어 여러분의 함수는 AWS DynamoDB API와 상호작용하여 기록물을 PutItem하거나 Query할 수 있습니다. 여러분은 프라이빗 서브넷에 있는 사적 리소스와의 상호작용이 필요할 때에만 VPC 액세스를 위한 함수를 활성화해야 합니다. RDS 인스턴스가 좋은 예입니다.
여러분의 함수에 VPC가 활성화되면 여러분의 함수에서 나오는 모든 네트워크 트래픽은 VPC/서브넷의 라우팅 규칙을 따르게 됩니다. 여러분의 함수가 공용 리소스와 상호작용을 해야 한다면 퍼블릭 서브넷의 NAT 게이트웨이를 통한 라우트가 필요할 것입니다.
Lambda 함수는 아주 빠르게 늘어날 수 있기 때문에 동시 실행(Concurrent Executions) 또는 동시 호출과 같은 함수 지표가 예상 임계값을 초과했을 때 팀에게 알려줄 수 있도록 CloudWatch 경보를 배포하는 것이 좋다. - 람다 함수는 매우 빠르게 스케일링할 수 있기 때문에 여러분은 동시성이 급증하면 알림을 받을 수 있는 통제장치를 해두어야 합니다. ConcurrentExecutions 또는 Invocations 같은 함수 지표가 여러분의 한계치를 초과하면 여러분의 팀에게 알리는 CloudWatch 알람을 배포하는 것이 좋습니다. 여러분은 매일 비용을 모니터링할 수 있도록 AWS Budget을 생성해야 합니다.
둘 이상의 Lambda 함수에서 코드를 재사용할 거라면 코드 재사용이 가능한 Lambda 계층 생성을 고려해야 한다. - 여러분은 람다 함수를 구성하여 레이어 형태로 된 추가적인 코드와 콘텐츠를 가져올 수 있습니다. 레이어는 라이브러리, 커스텀 런타임 또는 기타 의존성이 포함되어 있는 ZIP 아카이브입니다. 레이어를 사용하면 여러분은 배포 패키지에 넣지 않고도 함수에서 라이브러리를 사용할 수 있습니다. 레이어를 사용하면 배포 패키지의 크기를 작게 유지하여 개발이 더 쉬워집니다. 함수는 한 번에 레이어를 5개까지 사용할 수 있습니다.
여러분은 레이어를 만들거나 AWS 또는 다른 AWS 고객이 게시한 레이어를 사용할 수 있습니다. 레이어는 특정한 AWS 계정, AWS 단체 또는 모든 계정에게 레이어 사용 권한을 부여하기 위한 리소스 기반 정책을 지원합니다. 함수와 모든 레이어를 압축 해제한 용량이 250MB라는 배포 패키지(압축 해제 후) 용량 한계를 넘지 말아야 합니다.
한 개발자가 AWS 계정 A에서 AWS 계정 B의 Amazon S3 버킷에 액세스하는 Lambda 함수를 구현하려고 합니다.
솔루션 아키텍트로서 이 요구 사항을 충족시킬 방법으로 제안할 만한 것은 다음 중 무엇입니까?
Lambda 함수에 S3 버킷에 대한 액세스 권한을 부여하는 IAM 역할을 생성하고, 해당 IAM 역할을 Lambda 함수의 실행 역할로 설정한다. 버킷 정책에서 Lambda 함수의 실행 역할에도 액세스 권한을 부여하는지 확인한다.
동일한 AWS 계정에서 여러분이 람다 함수에 대해 IAM 역할을 생성한 경우, IAM 역할과 버킷 정책 모두에 Amazon S3 권한을 부여할 필요가 없습니다. 대신에 여러분은 IAM 역할에 권한을 부여하고, 이어서 버킷 정책이 람다 함수 역할에 대한 액세스를 명시적으로 거부하지 않는지 확인할 수 있습니다. IAM 역할과 버킷이 다른 계정에 있는 경우, 여러분은 IAM 역할과 버킷 정책 모두에 Amazon S3 권한을 부여해야 합니다. 그러므로 이것이 제시된 활용 사례에서 AWS Lambda에 대한 액세스 권한을 부여하는 올바른 방법입니다.
한 건강 관리 스타트업에서 Amazon S3에 저장된 객체에 대해 규정 준수 및 규제 지침을 시행하려고 합니다. 주요 요구 사항 중 한 가지는 객체가 실수로 삭제되지 않도록 적절한 보호 장치를 제공하는 것입니다.
솔루션 아키텍트로서 이러한 지침을 처리하기 위해 권장하는 방식은 무엇입니까? (2개를 고르시오.)
버킷에서 버전 관리를 활성화한다. - 버저닝(versioning)은 어떤 객체의 다양한 버전을 같은 버킷에 유지하는 방법입니다. 여러분은 버저닝을 이용하여 Amazon S3 버킷에 저장된 모든 객체의 모든 버전을 보존, 검색, 복원할 수 있습니다. 버저닝이 활성화된 버킷을 이용하면 우발적으로 삭제하거나 덮어쓴 객체를 복구할 수 있습니다.
다음과 같은 예가 있습니다.
객체를 덮어쓰면 버킷 안에 새로운 객체 버전이 생성됩니다. 여러분은 언제나 이전 버전을 복구할 수 있습니다. 어떤 객체를 영구적으로 제거하지 않고 삭제하면 Amazon S3는 삭제 마커를 삽입하고, 그게 현재의 객체 버전이 됩니다. 여러분은 언제나 이전 버전을 복구할 수 있습니다. 그러므로 이것이 정답입니다.
버킷에서 MFA delete를 활성화한다. - 추가적인 보호를 제공하기 위해 멀티팩터 인증(MFA) 삭제를 활성화할 수 있습니다. MFA 삭제는 객체를 Amazon S3 버킷에서 영구적으로 삭제하기 위해 먼저 2차 인증을 요구합니다. 그러므로 이것이 정답입니다.
한 기상 예보 기관은 미국 여러 도시에서 주요 기상 지표를 수집하여 키-값 쌍 형태의 데이터로 만들어 1분에 한 번씩 AWS 클라우드로 전송하고 있습니다.
솔루션 아키텍트로서 이 데이터를 안정적으로 처리 및 저장할 수 있는 고가용성 솔루션을 구축하는 데 어떤 AWS 서비스를 사용하시겠습니까? (2개를 고르시오.)
Lambda - AWS Lambda를 사용하면 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있습니다. 여러분이 소비한 연산 시간에 대해서만 지불하고, 코드가 실행되지 않을 때는 요금이 부과되지 않습니다. 실제로 모든 유형의 애플리케이션이나 백엔드 서비스에 코드를 실행할 수 있고 관리가 전혀 필요하지 않습니다.
DynamoDB - Amazon DynamoDB는 모든 스케일에서 수 밀리 초 단위의 성능을 제공하는 키-값 및 문서 데이터베이스입니다. 내장된 보안, 백업, 복원, 인터넷 스케일 응용을 위한 인메모리 캐싱이 제공되는 완벽히 관리되는 견고한 멀티 리전, 멀티 마스터 데이터베이스입니다. DynamoDB는 NoSQL 데이터베이스이며 키-값 쌍에 데이터를 저장하도록 최적화되어 있습니다.
AWS Lambda와 DynamoDB를 조합하여, 활용 사례에 설명된 IoT 소스에서 나오는 키-값 데이터를 처리하고 포착할 수 있습니다. 그러므로 두 선택지는 모두 정답입니다.
한 유통 업체가 Amazon EC2 인스턴스, API Gateway, Amazon RDS, 일래스틱 로드 밸런서, CloudFront 서비스를 사용하고 있습니다. 위험 관리 그룹에서는 이들 서비스의 보안을 강화하기 위해 Amazon GuardDuty 서비스 사용에 대한 타당성 검사를 제안했습니다.
다음 중 GuardDuty에서 지원하는 소스 데이터로 맞게 짝지어진 것은 무엇입니까?
VPC Flow Logs, DNS 로그, CloudTrail 이벤트 - Amazon GuardDuty는 여러분의 AWS 계정, 워크로드, Amazon S3에 저장된 데이터를 보호하기 위해 악의적인 활동과 무단 행동을 연속적으로 모니터링하는 위협 탐지 서비스입니다. 클라우드를 사용하면 계정과 네트워크 활동의 수집과 집계가 간단하지만 보안팀이 연속적으로 이벤트 로그 데이터를 분석하여 잠재적인 위협을 찾기 위해서는 많은 시간이 소요될 수 있습니다. GuardDuty를 사용하면 이제 AWS에서 경제적으로, 그리고 연속적으로 스마트하게 위협을 탐지할 수 있습니다. 이 서비스는 머신러닝, 이상 탐지, 통합 위협 인텔리전스를 사용하여 잠재적인 위협을 식별하고 우선순위화합니다.
GuardDuty는 AWS CloudTrail 이벤트, Amazon VPC Flow Logs, DNS 로그 같은 다수의 AWS 데이터 소스에 걸쳐 수백억 개의 이벤트를 분석합니다.
AWS 관리 콘솔에서 클릭 몇 번만 하면 배포하거나 유지할 하드웨어나 소프트웨어 없이 GuardDuty를 활성화할 수 있습니다. Amazon EventBridge 이벤트와 통합된 GuardDuty 경보는 액셔너블하며 손쉽게 다수의 계정들을 집계할 수 있고 기존의 이벤트 관리 및 워크플로 시스템에 곧바로 통합할 수 있습니다.
빅데이터 분석 업체가 Amazon S3 버킷에 데이터와 로그 파일을 기록하고 있습니다. 업체는 이제 기존 데이터 파일뿐만 아니라 진행 중인 파일 업데이트도 Amazon S3에서 Amazon Kinesis Data Streams으로 스트리밍하기를 원합니다.
다음 중 솔루션 아키텍트의 관점에서 이 요구 사항에 대한 솔루션을 가장 빠르게 구축할 수 있는 방법은 무엇입니까?
AWS 데이터베이스 마이그레이션 서비스(AWS DMS)를 Amazon S3와 Amazon Kinesis Data Streams 간의 브리지로 활용한다. - 여러분은 AWS 데이터베이스 마이그레이션 서비스(AWS DMS)를 사용하여 그렇게 할 수 있습니다. AWS DMS를 사용하면 지원되는 소스의 데이터를 관계형 데이터베이스, 데이터 웨어하우스, 스트리밍 플랫폼, 기타 AWS 클라우드의 데이터 스토어로 매끄럽게 마이그레이션할 수 있습니다.
제시된 요구사항은 가능한 한 빨리 구현될 수 있는 기능을 요구합니다. 여러분은 그러한 데이터 처리 요구에 대해 AWS DMS를 사용할 수 있습니다. AWS DMS를 사용하면 새로운 코드를 작성하고 유지할 필요 없이, 기존의 애플리케이션을 확장하여 Amazon S3로부터 Amazon Kinesis Data Streams로 데이터를 스트리밍하여 실시간 분석기에 활용할 수 있습니다. AWS DMS에서는 Amazon S3를 소스로 지정하고 Kinesis나 Amazon Managed Streaming of Kafka(Amazon MSK) 같은 스트리밍 서비스를 타깃으로 지정할 수 있습니다. AWS DMS를 사용하면 모든 변경 데이터 캡처(CDC) 파일을 그러한 서비스로 마이그레이션할 수 있습니다. AWS DMS는 복잡한 구성이나 코드 작성 없이 곧바로 그러한 작업을 수행합니다. 여러분은 또한 워크로드에 맞춰 스케일을 키우거나 줄이기 위해 AWS DMS 복제 인스턴스를 구성할 수도 있습니다.
AWS DMS는 Amazon S3를 소스로, Kinesis를 타깃으로 지원하며, 따라서 S3 버킷에 저장된 데이터가 Kinesis로 스트리밍됩니다. AWS Lambda, Amazon Kinesis Data Firehose, Amazon Kinesis Data Analytics, Kinesis Consumer Library(KCL) 같은 컨슈머가 동시에 데이터를 소비하여 데이터셋에 대한 실시간 분석을 수행할 수 있습니다. 이 아키텍처에 있는 모든 AWS 서비스는 필요에 따라 독립적으로 스케일링이 가능합니다.
전자 설계 자동화(EDA) 애플리케이션은 두 가지 범주에 속하는 방대한 양의 데이터를 생산합니다. ‘핫 데이터’는 병렬 및 분산 방식으로 빠르게 처리되어 저장되어야 하고, ‘콜드 데이터’는 낮은 비용으로 읽기 및 업데이트를 수행하기 위해 신속히 액세스할 수 있도록 참조용으로 보관해야 합니다.
다음 중 위에서 언급한 칩 설계 프로세스를 가속화하는 데 가장 적합한 AWS 서비스는 무엇입니까?
Amazon FSx for Lustre
Amazon FSx for Lustre를 사용하면 세계에서 가장 유명한 고성능 파일 시스템을 쉽고 경제적으로 시작하고 실행할 수 있습니다. Amazon FSx for Lustre는 머신러닝, 고성능 컴퓨팅(HPC), 비디오 프로세싱, 재무 모델링 등의 워크로드에 사용됩니다. 오픈소스 Lustre 파일 시스템은 스토리지가 연산 속도와 보조를 맞추는 빠른 스토리지를 요구하는 애플리케이션을 위해 설계되어 있습니다. FSx for Lustre는 Amazon S3와 통합되어 Lustre 파일 시스템으로 간편하게 데이터셋을 처리할 수 있습니다. FSx for Lustre 파일 시스템은 S3 버킷에 연결된 경우, S3 객체를 파일로서 투명하게 제시하고 여러분이 변경된 데이터를 다시 S3에 기록할 수 있게 해줍니다.
FSx for Lustre는 ‘핫 데이터(hot data)’를 병렬로, 그리고 분산식으로 모두 처리할 능력을 제공할 뿐만 아니라 ‘콜드 데이터’를 간단히 Amazon S3에 저장할 능력도 제공합니다. 그러므로 이 선택지는 제시된 문제 설명에 가장 적합합니다.
일래스틱(Elastic) 로드 밸런서가 대상 그룹에 있는 모든 EC2 인스턴스를 비정상(Unhealthy) 상태로 표시했습니다. 하지만 개발자가 웹브라우저에서 EC2 인스턴스의 IP 주소를 입력했을 때는 웹 사이트에 접속할 수 있었습니다.
인스턴스 상태가 비정상으로 표시되는 이유는 타당한 것은 무엇입니까? (2개를 고르시오.)
EC2 인스턴스의 보안 그룹에서 애플리케이션 로드 밸런서의 보안 그룹으로부터의 트래픽을 허용하지 않았다.
상태 확인(Health Check) 경로가 잘못 설정되었다.
애플리케이션 로드 밸런서는 상태를 테스트하기 위해 등록된 타깃에게 주기적으로 요청을 전송합니다. 그러한 테스트를 건전성 체크라고 부릅니다.
각각의 로드 밸런서 노드는 로드 밸런서의 활성화된 가용 영역에 있는 건전한 타깃으로만 요청을 라우팅합니다. 각각의 로드 밸런서 노드는 타깃이 등록된 타깃 그룹에 대한 건전성 체크 설정을 이용하여 각 타깃의 건전성을 체크합니다. 타깃 그룹에 건전하지 않은 등록된 타깃만 있는 경우, 로드 밸런서 노드는 그룹의 건전하지 않은 타깃들에 걸쳐 요청을 라우팅합니다.
여러분은 리스너 포트와 건전성 체크 포트 모두에서 로드 밸런서가 등록된 타깃과 교신할 수 있는지 확인해야 합니다. 여러분이 리스너를 로드 밸런서에 추가하거나, 로드 밸런서가 요청을 라우팅하는 데 사용하는 타깃 그룹의 건전성 체크 포트를 업데이트할 경우에는 언제나 로드 밸런서에 관련된 보안 그룹이 새로운 포트에서 양방향 트래픽을 허용하는지 반드시 확인해야 합니다.
한 미디어 회사는 로스앤젤레스에 본사와 데이터 센터를 두고 AWS Direct Connect를 사용해 AWS VPC와 연결합니다. 샌프란시스코 지사와 마이애미 지사는 Site-to-Site VPN 연결을 사용해 AWS VPC에 연결합니다. 회사는 지사들 간에는 물론 본사와도 데이터를 주고받을 수 있는 솔루션을 모색하고 있습니다.
솔루션 아키텍트로서 이 사례를 해결하기 위해 제안할 수 있는 AWS 서비스는 다음 중 무엇입니까?
VPN CloudHub
여러분에게 다수의 AWS 사이트 간 VPN 연결이 있다면, AWS VPN CloudHub를 이용하여 사이트 간에 보안 통신을 제공할 수 있습니다. 여러분의 원격 사이트들이 VPC뿐만 아니라 서로 간에 통신할 수 있게 됩니다. 가상 사설 게이트웨이에 대한 AWS Direct Connect 연결을 사용하는 사이트들도 AWS VPN CloudHub의 일부가 될 수 있습니다. VPN CloudHub는 VPC와 함께, 또는 VPC 없이 사용할 수 있는 단순한 허브 앤 스포크(hub-and-spoke) 모델로 작동합니다. 여러분에게 다수의 지점 사무실과 기존 인터넷 연결이 있고 그러한 원격 사무실들 간에 기본 또는 보조 연결성을 위해 편리하고 비용도 절약할 수 있는 허브 앤 스포크 모델을 구현하려고 한다면 이러한 설계가 적절합니다.
제시된 활용 사례에서 기업 본사에는 VPC에 대한 AWS Direct Connect 연결이 있고 지점 사무실에는 VPC에 대한 사이트 간 VPN 연결이 있습니다. 그러므로 AWS VPN CloudHub를 사용하여 지점 사무실들은 서로 간에, 그리고 기업 본사와 데이터를 전송하고 수신할 수 있습니다.
고빈도 거래 시스템을 사용하는 금융 서비스 회사에서 시스템의 로그 파일을 Amazon S3에 작성하려고 합니다. 시스템은 작성과 동시에 해당 로그 파일을 거의 실시간으로 읽습니다. 엔지니어링 팀은 거래 시스템이 기존 로그 파일을 덮어쓴 다음 해당 로그 파일을 바로 읽으려고 할 때 발생할 수 있는 데이터 불일치 문제를 해결하려고 합니다.
다음 중 이 시나리오와 관련된 Amazon S3의 기능을 가장 잘 설명한 것은 무엇입니까?
프로세스가 기존 객체를 변경한 뒤 즉시 읽으려고 하면 Amazon S3는 항상 최신 버전의 객체를 반환한다.
Amazon S3는 성능이나 가용성을 변경하지 않고, 또한 애플리케이션의 지역적 분리도를 희생시키지 않고 어떠한 추가 비용도 없이 자동으로 강력한 쓰기 후 읽기(read-after-write) 일관성을 제공합니다.
새로운 객체를 성공적으로 쓰거나 기존 객체에 덮어 쓴 후에 이루어지는 읽기 요청은 즉시 객체의 최신 버전을 받게 됩니다. S3는 또한 리스트 작업에도 강력한 일관성을 제공하기 때문에 쓴 다음에 즉시 모든 변경사항을 반영하여 버킷에 있는 객체의 목록화를 수행할 수 있습니다.
강력한 쓰기 후 읽기 일관성은 여러분이 쓴 다음에 즉시 객체를 읽어야 할 때 유용합니다. 예를 들어 여러분이 자주 읽고 객체를 쓴 다음에 즉시 목록화를 할 경우에 강력한 쓰기 후 읽기 일관성이 도움을 줍니다.
요약하자면, 모든 S3의 GET, PUT, LIST 작업, 그리고 객체의 태그, ACL 또는 메타데이터를 변경하는 작업에 강력한 일관성이 있습니다. 여러분이 기록한 바로 그것을 읽게 되고, LIST의 결과는 버킷 안에 있는 것들을 정확히 반영하게 됩니다.
한 미디어 기업에서 자체적으로 IT 인프라를 보유하고 직접 유지 관리하는 방식에서 벗어나려고 합니다. 회사에서는 디지털 전환 작업의 일환으로 온프레미스 데이터 센터에 있는 약 5PB의 데이터를 내구성 있는 장기 스토리지에 보관하고자 합니다.
솔루션 아키텍트로서 제안할 수 있는 가장 경제적인 데이터 마이그레이션 방식은 무엇입니까?
온프레미스 데이터를 여러 Snowball Edge Storage Optimized 장치로 전송한다. Snowball Edge에서 Amazon S3로 데이터를 복사하고, 수명 주기 정책을 생성하여 해당 데이터를 AWS Glacier에 백업한다.
수 테라바이트 내지 페타바이트급의 데이터를 AWS로 안전하고 빠르게 전송해야 한다면 Snowball Edge Storage Optimized가 최적의 선택입니다. 최대 사용 가능한 HDD 저장소 80TB, vCPU 40개, SATA SSD 저장소 1TB를 제공하며, 대규모 데이터 전송 및 전처리 활용 사례를 위해 최대 40Gb의 네트워크 연결성을 제공합니다. Snowball Edge 장치에 저장된 데이터는 S3 버킷에 복사할 수 있고, 나중에 라이프사이클 정책을 통해 AWS Glacier로 이전할 수 있습니다. 여러분은 데이터를 직접 Snowball Edge 장치에서 AWS Glacier로 복사할 수 없습니다.
회사에서 코딩 실력을 평가하기 위한 웹 사이트를 운영하고 있습니다. 여러분은 솔루션 아키텍트로서 API Gateway와 AWS Lambda를 사용해 AWS 클라우드에서 서버리스 패턴을 따르는 웹 사이트 아키텍처를 설계했습니다. 백엔드에서는 RDS PostgreSQL 데이터베이스를 사용하고 있으며, 캐시 기능은 Redis ElastiCache 클러스터로 구현되었습니다. 사용자 이름과 암호를 조합을 활용하여 Lambda 함수에서 Redis에 대한 사용자 인증 보안을 강화하려고 합니다.
다음 중 솔루션 아키텍트로서 제안할 수 있는 선택지는 무엇입니까?
Redis AUTH를 사용한다. - Amazon ElastiCache for Redis는 인터넷 스케일의 실시간 애플리케이션에 밀리 초 미만의 레이턴시를 제공하는 번개처럼 빠른 인메모리 데이터 스토어입니다.
Amazon ElastiCache for Redis는 캐싱, 챗/메시징, 게이밍 리더보드, 지리공간, 머신러닝, 미디어 스트리밍, 대기열, 실시간 분석기, 세션 스토어 등 실시간 트랜잭션 및 분석 프로세싱 활용 사례에 아주 적합합니다.
ElastiCache for Redis는 구성 없이 곧바로 복제, 높은 가용성, 클러스터 샤딩을 제공합니다. ElastiCache는 IAM Auth를 지원하지 않습니다.
Redis 인증 토큰을 사용하면, 클라이언트가 명령을 실행하기 전에 Redis가 토큰(패스워드)을 요구할 수 있도록 해주어 데이터 보안이 개선됩니다.
한 IT 기업은 팀에 합류한 신입 개발자에게 DynamoDB에 대한 모든 액세스 권한이 부여되는 사건이 보고된 이후 보안 모범 사례(Best Practice)를 검토하려고 합니다. 해당 개발자는 새로운 기능을 구현하던 중 실수로 프로덕션 환경에 있는 테이블 몇 개를 삭제했습니다.
이런 사고의 재발을 방지할 수 있는 가장 효율적인 해결 방법은 무엇입니까?
권한 경계(Permissions boundary)를 사용해 직원이 IAM 주체에게 부여할 수 있는 최대 권한을 제어한다.
권한 경계를 사용하여 직원들이 그들이 생성하고 관리하는 IAM 주체에 부여할 수 있는 최대 권한 수(즉 사용자와 역할)를 통제할 수 있습니다. IAM 관리자로서 여러분은 관리된 정책을 이용하여 하나 이상의 권한 경계를 정의하고 직원들이 이 경계 안에서 주체를 생성하도록 할 수 있습니다. 이어서 직원들은 그러한 주체에게 권한 정책을 부착할 수 있습니다. 그러나 권한 경계와 권한 정책의 교차점이 주체의 효과적인 권한이라고 할 수 있습니다. 결과적으로 새로운 주체는 여러분이 정의한 경계를 초과할 수 없습니다. 그러므로 권한 경계를 사용하는 것이 이 활용 사례의 적절한 솔루션입니다.
한 빅 데이터 분석 회사는 갑작스러운 트래픽 급증에 대비하여 요청을 조절할 수 있는 AWS 클라우드 아키텍처를 구축하려고 합니다. 회사는 이러한 트래픽 변동을 처리하기 위해 버퍼링 및 스로틀링에 사용할 수 있는 AWS 서비스를 찾고 있습니다.
다음 중 이 요구 사항을 충족하기 위해 사용할 수 있는 서비스는 무엇입니까?
스로틀링은 승인된 프로그램이 주어진 시간 안에 어떤 작업에 제출할 수 있는 요청의 개수를 제한하는 프로세스입니다.
Amazon API Gateway, Amazon SQS, Amazon Kinesis - 여러분의 API가 너무 많은 요청에 압도당하지 않도록 하기 위해 Amazon API 게이트웨이는 토큰 하나가 요청 하나에 해당하는 토큰 버킷 알고리즘을 사용하여 여러분의 API에 대한 요청을 스로틀링합니다. 구체적으로는, API 게이트웨이가 여러분의 계정에 있는 모든 API에 대해 정상 상태(steady-state) 속도 및 요청 제출 버스트에 제한을 설정합니다. 토큰 버킷 알고리즘에서 버스트(burst)는 최대 버킷 크기를 가리킵니다.
Amazon SQS - Amazon Simple Queue Service(SQS)는 여러분이 마이크로서비스, 분산 시스템, 서버리스 애플리케이션을 디커플링하고 스케일링할 수 있게 해주는 완벽히 관리되는 메시지 대기열화 서비스입니다. Amazon SQS는 메시지를 잃거나 레이턴시를 증가시키지 않고 일시적인 볼륨 폭증을 매끄럽게 해주는 버퍼링 능력을 제공합니다.
Amazon Kinesis - Amazon Kinesis는 실시간으로 스트리밍 데이터를 소화, 버퍼링, 처리할 수 있는 완벽히 관리되는 스케일링 가능한 서비스입니다.
한 전자 상거래 기업에서 사내(on-premises) 데이터 센터에 있던 1PB 크기의 데이터를 AWS Direct Connect 링크를 사용해 us-west-1 리전의 Amazon S3 버킷으로 복사했습니다. 기업에서는 이 데이터를 us-east-1 리전의 또 다른 S3 버킷으로 복사하려고 합니다. 사내 데이터 센터에서는 AWS Snowball을 사용할 수 없습니다.
다음 중 이 목표를 달성하기 위해 솔루션 아키텍트로서 사용할 수 있는 방법은 무엇입니까? (2개를 고르시오.)
aws S3 sync 명령어를 사용해 소스 버킷에서 대상 버킷으로 데이터를 복사한다.
aws S3 sync 명령은 S3 버킷들 간에 객체를 복사하기 위해 CopyObject API를 사용합니다. sync 명령은 소스와 타깃 버킷을 나열하여 소스 버킷에는 있지만 타깃 버킷에는 없는 객체를 식별합니다. 해당 명령은 또한 타깃 버킷에 있는 객체와 LastModified 날짜가 다른 소스 버킷의 객체들도 식별합니다. 버저닝된 버킷에 대한 sync 명령은 현재의 객체 버전만 복사하며 이전 버전은 복사되지 않습니다. 기본적으로 객체 메타데이터가 보존되지만 여러분의 AWS 계정에서 접근통제목록(ACL)이 FULL_CONTROL로 설정되며, 그러면 추가적인 ACL이 모두 삭제됩니다. 작업이 실패하면 이전에 복사한 객체를 복제할 필요 없이 sync 명령을 다시 실행할 수 있습니다.
다음과 같이 명령을 사용할 수 있습니다.
aws s3 sync s3://DOC-EXAMPLE-BUCKET-SOURCE s3://DOC-EXAMPLE-BUCKET-TARGET
S3 콘솔을 사용해 S3 배치 복제(Batch Replication)를 구성하여 다른 리전의 S3 버킷으로 객체를 복사한다.
S3 배치 복제를 사용하면 복제 구성이 이루어지기 전에 있었던 객체, 이전에 복제되었던 객체, 복제에 실패했던 객체를 복제할 수 있습니다. Batch Operations 작업을 이용하여 복제할 수 있습니다.
배치 복제는 Amazon S3 버킷들에 걸쳐 새로운 객체를 연속적이고도 자동적으로 복제하는 라이브 복제와 다르다는 점에 주의해야 합니다. 기존 객체에 대해 크로스 리전(cross-Region) 복제를 구성하기 위해 AWS S3 콘솔을 직접 사용할 수는 없습니다. 기본적으로 복제는 활성화된 후의 새로운 Amazon S3 객체의 AWS S3 콘솔을 이용한 복제만 지원합니다. 복제를 이용하면 Amazon S3 버킷들 간에 객체들을 자동으로, 비동기적으로 복사할 수 있습니다. 객체 복제를 위해 구성된 버킷들은 동일한 AWS 계정 또는 다른 계정이 소유할 수 있습니다. 객체는 단일한 대상 버킷 또는 다수의 대상 버킷에 복제될 수 있습니다. 대상 버킷은 소스 버킷과 다른 AWS 리전 또는 같은 리전에 있을 수 있습니다.
여러분의 버킷의 기존 객체에 대해 라이브 복제를 활성화하려면 AWS 지원 센터에 연락하거나 지원 티켓을 요청해야 합니다. 복제를 올바르게 구성하기 위해서는 그렇게 해야 합니다.
한 유통 기업에서 앞으로 48시간 안에 자사의 글로벌 애플리케이션을 위한 Blue-Green 배포를 롤아웃 및 테스트하려고 합니다. 고객 대부분은 DNS 캐싱이 용이한 휴대전화를 사용합니다. 회사에서 추수감사절 연례 판매 행사를 시작하기까지는 이틀밖에 남지 않았습니다.
솔루션 아키텍트의 관점에서 가능한 한 많은 사용자가 주어진 시간 내에 배포를 테스트할 수 있게 하는 방법은 다음 중 무엇입니까?
청색/녹색 배포는 다른 버전의 애플리케이션을 실행하는 두 개의 동일한 환경 간에 트래픽을 이전해서 애플리케이션을 릴리스하기 위한 기법입니다. ‘청색’은 현재 실행 중인 버전이고 ‘녹색’은 새로운 버전입니다. 이러한 배포 유형을 이용하면 여러분은 현재 실행 중인 애플리케이션 버전에 영향을 미치지 않고 녹색 환경에서 피처를 테스트할 수 있습니다. 녹색 버전이 적절히 작동하여 만족한 경우, 여러분은 점진적으로 기존의 청색 환경에서 새로운 녹색 환경으로 트래픽을 재인도할 수 있습니다. 청색/녹색 배포를 이용하면 불가동 시간 및 롤백 능력 등 소프트웨어 배포에 수반되는 공통된 위험을 줄일 수 있습니다.
AWS Global Accelerator를 사용해 트래픽의 일부를 특정 배포로 분산한다. - AWS 글로벌 액셀러레이터는 AWS 글로벌 네트워크에 걸쳐 트래픽을 최적의 엔드포인트로 인도하는 네트워크 레이어 서비스입니다. 이로써 인터넷 애플리케이션의 가용성과 성능이 개선됩니다. AWS 글로벌 액셀러레이터는 하나 또는 다수의 AWS 리전에서 애플리케이션 로드 밸런서, 네트워크 로드 밸런서, 탄력적 IP 주소 또는 Amazon EC2 인스턴스 등 여러분의 애플리케이션 엔드포인트에 대한 고정된 진입점 역할을 하는 정적 애니캐스트(anycast) IP 주소를 2개 제공합니다.
AWS 글로벌 액셀러레이터는 엔드포인트 가중치를 사용하여 어떤 엔드포인트 그룹 안의 엔드포인트들로 향하는 트래픽의 비중을 결정하고 트래픽 다이얼을 이용하여 어떤 엔드포인트 그룹(애플리케이션이 배포된 AWS 리전)으로 향하는 트래픽의 비중을 제어합니다.
청색/녹색 배포를 위해 DNS 서비스에 의지하는 것이 좋지만, 빠르고 제어된 트래픽 전환을 요구하는 활용 사례에는 적합하지 않을 수 있습니다. 일부 클라이언트 장치와 인터넷 리졸버는 DNS 응답을 오랫동안 캐시하며, 그러한 DNS 피처는 인터넷을 통하는 DNS 트래픽을 줄여서 DNS 서비스의 효율을 개선하고, 강제적인 네임서버 오버로드를 방지하여 회복 기법 역할을 합니다. 청색/녹색 배포에서 이러한 방식의 단점은 여러분이 기록을 업데이트하고 라우팅 기본설정을 변경하거나 애플리케이션에 고장이 있으면 여러분의 모든 사용자가 업데이트된 IP 주소를 받을 때까지 얼마나 걸릴지 알지 못한다는 점입니다.
AWS 글로벌 액셀러레이터를 사용하면 클라이언트 장치의 DNS 캐싱, 인터넷 리졸버, 트래픽 다이얼과 상관없이 청색 및 녹색 환경 간에 점진적으로 또는 한꺼번에 트래픽을 이전할 수 있으며 엔드포인트 가중치 변경은 몇 초 안에 유효해집니다.
한 IT 회사의 DevOps 팀이 퍼블릭 서브넷과 프라이빗 서브넷이 있는 VPC에 2계층(2-Tier) 애플리케이션을 프로비저닝하고 있습니다. 팀에서는 퍼블릭 서브넷에서 NAT 인스턴스 또는 NAT 게이트웨이를 사용하여 프라이빗 서브넷에 있는 인스턴스가 인터넷으로 아웃바운드 IPv4 트래픽을 내보내도록 하고 싶지만, NAT 인스턴스와 NAT 게이트웨이에서 사용할 수 있는 설정 옵션에 대한 기술적 지원이 필요합니다.
솔루션 아키텍트의 관점에서 봤을 때 다음 설명 중 옳은 것은 무엇입니까? (3개를 고르시오.)
NAT 인스턴스를 배스천(bastion) 서버로 사용할 수 있다.
보안 그룹은 NAT 인스턴스와 연결할 수 있다.
NAT 인스턴스는 포트 포워딩을 지원한다.
NAT 인스턴스 또는 NAT 게이트웨이는 퍼블릭 서브넷과 여러분의 VPC에서 사용하여 프라이빗 서브넷에 있는 인스턴스들이 인터넷을 향해 아웃바운드 IPv4 트래픽을 개시할 수 있게 해줍니다.
개발 팀은 보안을 위해 EC2 인스턴스를 프라이빗 서브넷에 배포하기로 결정했습니다. 개발 팀은 인스턴스가 일부 AWS 서비스에 안전하게 액세스할 수 있도록 VPC 엔드포인트를 사용할 계획입니다. 이를 위해 팀원들은 게이트웨이 엔드포인트를 지원하는 AWS 서비스 두 가지를 확보하려고 합니다.
솔루션 아키텍트로서 다음 중 이 요구 사항에 맞는 서비스로 무엇을 제안하시겠습니다? (2개를 고르시오.)
Amazon S3
DynamoDB
VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 장치, VPN 연결 또는 AWS Direct Connect 연결 없이 여러분의 VPC를 지원되는 AWS 서비스 및 AWS PrivateLink가 제공하는 VPC 엔드포인트에 사설로 연결할 수 있습니다. 여러분의 VPC 안의 인스턴스들은 서비스의 리소스와 통신하기 위해 공용 IP 주소를 필요로 하지 않습니다. VPC와 다른 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.
엔드포인트는 가상 장치입니다. 그것들은 수평적으로 스케일링되고 여분이며 가용성이 높은 VPC 컴포넌트들입니다. 네트워크 트래픽에 가용성 위험이나 대역폭 제약을 주지 않고 VPC와 서비스에서 인스턴스들 간에 통신이 가능합니다.
VPC 엔드포인트에는 두 가지 유형이 있습니다. 즉 인터페이스 엔드포인트와 게이트웨이 엔드포인트입니다. 인터페이스 엔드포인트는 지원되는 서비스를 향하는 트래픽을 위한 진입점 역할을 하는 여러분 서브넷의 IP 주소 범위에 있는 사설 IP 주소가 있는 탄력적 네트워크 인터페이스입니다.
게이트웨이 엔드포인트는 지원되는 AWS 서비스를 향하는 트래픽을 위해 여러분의 라우트 테이블에 타깃으로 지정한 게이트웨이입니다. 다음과 같은 AWS 서비스가 지원됩니다. Amazon S3 및 DynamoDB.
여러분은 게이트웨이 엔드포인트 및 인터페이스 엔드포인트 등 두 가지 유형의 VPC 엔드포인트를 사용하여 Amazon S3에 액세스할 수 있습니다. 게이트웨이 엔드포인트는 AWS 네트워크를 통해 여러분의 VPC로부터 Amazon에 액세스하기 위해 여러분의 라우트 테이블에 지정한 게이트웨이입니다. 인터페이스 엔드포인트는 사설 IP 주소를 사용하여 여러분의 VPC에서 나오는 요청을 Amazon S3로 라우팅하거나 VPC 피어링 또는 AWS 트랜짓 게이트웨이를 사용하여 다른 AWS 리전의 VPC에서 나오는 요청을 라우팅함으로써 게이트웨이 엔드포인트의 기능을 확장합니다.
여러분은 이 두 서비스가 VPC 게이트웨이 엔드포인트를 사용한다는 점을 반드시 기억하셔야 합니다.
한 스타트업의 클라우드 인프라는 여러 개의 Amazon EC2 인스턴스와 Amazon RDS 인스턴스, Amazon S3 스토리지로 구성되어 있습니다. 사업 운영을 시작한지 1년이 지났는데 이 업체의 비즈니스 요구 사항에 비해 너무 많은 서버 비용이 발생하고 있는 것 같습니다.
다음 중 유효한 비용 최적화 솔루션에 해당하는 것은 무엇입니까?
AWS Cost Explorer의 리소스 최적화를 사용해 유휴 상태이거나 활용율이 낮은 EC2 인스턴스에 대한 보고서를 확인하고, AWS Compute Optimizer를 사용해 인스턴스 유형 권장 사항을 확인한다. - AWS Cost Explorer를 사용하면 사이즈를 줄일 수 있는 활용도가 낮은 EC2 인스턴스를 동일한 인스턴스 패밀리 안에서 인스턴스별로 식별하고 여러분의 예약 인스턴스와 절약 플랜을 고려하여 AWS 요금에 미칠 수 있는 영향을 이해할 수도 있습니다.
AWS Compute Optimizer는 머신러닝을 이용하여 과거의 활용 메트릭을 분석함으로써 비용을 절감하고 성능을 개선하기 위해 여러분의 워크로드를 위한 최적의 AWS Compute 리소스를 권고합니다. Compute Optimizer는 여러분의 활용 데이터를 기초로, Amazon EC2 오토 스케일링 그룹의 일부를 포함하여, 여러분이 최적의 Amazon EC2 인스턴스 타입을 선택하도록 도움을 줍니다.
한 미디어 기관에서 재사용이 가능한 자료를 Amazon S3 버킷에 저장하고 있습니다. 처음 며칠 동안은 아주 많은 사용자가 자료에 액세스하지만 일주일 후에는 액세스 빈도가 급격히 떨어집니다. 일주일 뒤에 사용 빈도가 떨어짐에도 불구하고 필요할 때는 바로 액세스할 수 있어야 합니다. 최근 모든 자료를 S3 스토리지에서 유지 관리하는 데 아주 큰 비용이 드는 것으로 밝혀져 기관에서는 최대한 비용을 줄일 수 있는 방안을 모색하고 있습니다.
솔루션 아키텍트의 관점에서 비즈니스 요구 사항을 충족하면서 스토리지 비용을 절감할 수 있는 방안은 무엇입니까?
30일 뒤에 객체를 Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환하도록 수명 주기 정책을 설정한다. - S3 One Zone-IA는 액세스 빈도가 낮지만 필요할 때는 빠른 액세스가 필요한 데이터에 사용합니다. 최소한 3개의 가용 영역(AZ)에 데이터를 저장하는 다른 S3 스토리지 클래스와 달리, S3 One Zone-IA는 하나의 AZ에 데이터를 저장하고 S3 Standard-IA에 비해 비용이 20% 적게 듭니다. S3 One Zone-IA는 액세스 빈도가 낮고 재생성이 가능한 데이터에 대해 낮은 비용 옵션을 원하지만 S3 Standard 또는 S3 Standard-IA의 가용성과 회복성이 필요하지 않은 고객들에게 적합합니다. 최소 보관 기간은 30일이며 그 전에 여러분은 객체를 S3 Standard에서 S3 One Zone-IA로 이전할 수 있습니다.
S3 One Zone-IA는 S3 Standard와 같은 높은 내구성, 빠른 처리 속도, 낮은 레이턴시를 제공하며 GB당 저장 가격 및 GB당 검색 요금이 낮습니다. S3 스토리지 클래스는 객체 수준에서 구성할 수 있고 S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA에 걸쳐 저장된 객체들을 하나의 버킷에 담을 수 있습니다. S3 라이프사이클 정책을 이용하여 애플리케이션 변경 없이 스토리지 클래스들 간에 객체를 자동으로 이전할 수 있습니다.
한 미디어 회사에서 자사의 주력 애플리케이션을 AWS 클라우드로 마이그레이션하기 위해 AWS Direct Connect 연결을 구성했습니다. 온프레미스 애플리케이션은 마운트된 NFS 파일 시스템에 매일 수백개의 동영상 파일을 기록합니다. 마이그레이션이 끝나면 회사는 EFS 파일 시스템이 마운트된 Amazon EC2 인스턴스에 애플리케이션을 호스트할 예정입니다. 마이그레이션이 시작되기 전에 회사는 새로 생성된 온프레미스 동영상 파일을 EFS 파일 시스템으로 복제하는 프로세스를 구축해야 합니다.
다음 중 요구 사항을 충족하는 가장 효율적인 운영 방법은 무엇입니까?
NFS 파일 시스템에 액세스할 수 있는 온프레미스 서버에서 AWS DataSync 에이전트를 구성한다. 프라이빗 VIF를 사용하여 Direct Connect 연결을 통해 Amazon EFS용 AWS PrivateLink 인터페이스 VPC 엔드포인트로 데이터를 전송한다. 24시간마다 EFS 파일 시스템으로 동영상 파일을 보내도록 DataSync 예약 작업을 설정한다.
AWS DataSync는 온프레미스 스토리지 시스템과 AWS 스토리지 서비스 간, 또한 AWS 스토리지 서비스 간 대량의 데이터 복사를 단순화하고 자동화하며 가속화하는 온라인 데이터 전송 서비스입니다.
여러분은 AWS DataSync를 사용하여 온프레미스, 엣지, 또는 다른 클라우드에 있는 데이터를 Amazon S3, Amazon EFS, Amazon FSx for Windows File Server, Amazon FSx for Lustre, Amazon FSx for OpenZFS, Amazon FSx for NetApp ONTAP으로 마이그레이션할 수 있습니다.
여러분의 가상 사설 클라우드(VPC)와 Amazon EFS API 간에 사설 연결을 수립하기 위해 인터페이스 VPC 엔드포인트를 생성할 수 있습니다. 또한 AWS VPN, AWS Direct Connect 또는 VPC 피어링(peering)을 이용하여 온프레미스 환경 또는 기타 VPC로부터 인터페이스 VPC 엔드포인트에 액세스할 수도 있습니다.
AWS Direct Connect는 공용(public), 사설(private), 트랜짓(transit) 등 세 가지 타입의 가상 인터페이스를 제공합니다.
제시된 활용 사례에서 여러분은 사설 VIF를 사용하여 Direct Connect 연결을 통해 데이터를 Amazon EFS용 AWS PrivateLink 인터페이스 VPC 엔드포인트로 전송할 수 있습니다.
AWS DataSync의 작업 스케줄링을 이용하여, 여러분은 소스 스토리지 시스템에서 목적지로의 전송 작업을 주기적으로 실행할 수 있습니다. 여러분은 24시간마다 비디오 파일을 EFS 파일 시스템으로 전송하기 위해 DataSync 예약 작업을 사용할 수 있습니다.
한 빅데이터 분석 업체가 Kinesis Data Streams(KDS)을 사용하여 농업 과학 기업의 필드 장치에서 IoT 데이터를 받아 처리하고 있습니다. 들어온 데이터 스트림은 다양한 컨슈머 애플리케이션에서 사용되고 있는데, 엔지니어들이 프로듀서와 데이터 스트림 컨슈머 사이에서 데이터 전달 속도의 성능 저하를 발견했습니다.
솔루션 아키텍트의 관점에서 주어진 사례의 성능 문제를 개선하기에 적합한 방식은 무엇입니까?
Kinesis Data Streams의 향상된 팬아웃(Enhanced Fanout) 기능을 활성화한다.
Amazon Kinesis Data Streams(KDS)는 엄청난 규모로 확장할 수 있는 견고한 실시간 데이터 스트리밍 서비스입니다. KDS는 웹사이트 클릭스트림, 데이터베이스 이벤트 스트림, 재무 거래, 소셜미디어 피드, IT 로그, 위치추적 이벤트 등 수십만 가지 소스에서 초당 수 기가바이트에 이르는 데이터를 연속적으로 수집할 수 있습니다.
기본값으로 스트림 데이터를 소비하는 모든 애플리케이션 간에 2MB/초/샤드의 출력이 공유됩니다. 스트림으로부터 병렬로 데이터를 검색하는 다수의 컨슈머가 있다면 향상된 팬아웃 기능을 사용하셔야 합니다. 향상된 팬아웃 기능을 사용하여 개발자는 스트림 컨슈머를 등록하여 향상된 팬아웃 기능을 사용하고 샤드당 2MB/초라는 읽기 처리 속도로 수신할 수 있으며 이러한 처리 속도는 스트림 안의 샤드 개수에 맞춰 자동으로 스케일링됩니다.
한 유통 회사는 AWS 클라우드를 사용해 자사의 IT 인프라를 관리합니다. 회사는 AWS 계정을 운영하고 EC2 인스턴스와 RDS 데이터베이스 같은 리소스를 사용하는 부서들을 관리하기 위해 AWS 조직(AWS Organizations)를 구성했습니다. 회사는 고도의 상호 연결이 필요한 애플리케이션을 사용하는 모든 부서에 중앙 집중식 공유 VPC를 제공하려고 합니다.
솔루션 아키텍트로서 이 사례에 맞는 환경을 구축하기 위해 다음 중 어떤 방법을 택하시겠습니까?
VPC 공유를 사용해 AWS Organizations에서 동일한 상위 조직에 속한 다른 AWS 계정과 하나 이상의 서브넷을 공유한다.
VPC 공유(리소스 액세스 매니저의 일부)를 이용하면 다수의 AWS 계정이 EC2 인스턴스, RDS 데이터베이스, Redshift 클러스터, 람다 함수 같은 애플리케이션 리소스를 공유되고 일원적으로 관리되는 Amazon 가상 사설 클라우드(VPC)로 만들 수 있습니다. 이렇게 설정하기 위해 VPC를 소유한 계정(오너)은 AWS 조직의 동일한 조직에 속한 다른 계정(참여자)과 하나 이상의 서브넷을 공유합니다. 서브넷이 공유된 후에 참여자는 공유된 서브넷에서 자신들의 애플리케이션 리소스를 열람, 생성, 변경, 삭제할 수 있습니다. 참여자들은 다른 참여자 또는 VPC 오너에게 속한 리소스를 열람, 변경 또는 삭제할 수 없습니다.
여러분은 Amazon VPC를 공유하여, 높은 수준의 상호연결성을 요구하고 동일한 신뢰성 경계 안에 있는 애플리케이션들을 위해 VPC 안의 암묵적 라우팅(implicit routing)을 활용할 수 있습니다. 그렇게 하면 청구와 액세스 통제를 위해 별도의 계정을 사용하는 한편, 여러분이 생성하고 관리하는 VPC의 개수가 감소합니다.
한 중견기업에서 EC2 인스턴스에 택시 배차 애플리케이션을 배포했습니다. 애플리케이션의 알 수 없는 버그로 인해 인스턴스가 불규칙적으로 멈추는 현상이 발생하고 있습니다. 문제가 발생하면 AWS 관리 콘솔을 통해 인스턴스를 수동으로 재시작해야 합니다.
다음 중 개발 팀이 문제를 영구적으로 수정하기 전까지 사용할 자동화 솔루션을 구현하는 방법 중에 비용과 자원이 가장 덜 드는 방법은 무엇입니까?
CloudWatch 경보(Alarm)를 구성해 인스턴스의 상태를 모니터링한다. 인스턴스 상태 확인이 실패하면 CloudWatch 경보 액션을 사용해 인스턴스를 재부팅할 수 있다.
Amazon CloudWatch 알람 액션을 사용하여 여러분은 EC2 인스턴스를 자동으로 정지, 종료, 재부팅, 또는 복구하는 알람을 생성할 수 있습니다. 여러분은 인스턴스를 더 이상 실행할 필요가 없을 때 정지 또는 종료 액션을 사용하여 비용을 절감할 수 있습니다. 여러분은 시스템 손상이 발생하면 재부팅 또는 복구 액션을 사용하여 자동으로 그러한 인스턴스들을 재부팅하거나 새로운 하드웨어에서 복구할 수 있습니다.
여러분은 Amazon EC2 인스턴스를 모니터링하고 자동으로 인스턴스를 재부팅하는 Amazon CloudWatch 알람을 생성할 수 있습니다. 인스턴스 건전성 체크 실패 시 재부팅 알람 액션을 사용하는 것이 좋습니다(반면에 복구 알람 액션은 시스템 건전성 체크 실패 시 사용하면 좋습니다.)
한 회사의 비즈니스 분석 팀은 고위 경영진을 위한 일일 보고서 준비를 위해 Amazon RDS에서 Oracle과 PostgreSQL 서비스에 임의(Ad-Hoc) 쿼리를 실행하고 있습니다. 비즈니스 분석 보고를 용이하게 하기 위해, 엔지니어링 팀은 데이터를 Amazon Redshift로 스트리밍하여 데이터를 지속적으로 복제하고 데이터베이스를 페타바이트 규모의 데이터 웨어하우스로 통합하려고 합니다.
다음 중 솔루션 아키텍트로서 기존 인프라 관리도 필요 없고 최소의 개발 시간만을 필요로 하는 가장 자원 효율적인 솔루션으로 제안할 수 있는 것은 무엇입니까?
AWS Database Migration Service를 사용해 데이터베이스에서 Amazon Redshift로 데이터를 복제한다.
AWS 데이터베이스 마이그레이션 서비스를 이용하면 빠르고 안전하게 데이터베이스를 AWS로 마이그레이션할 수 있습니다. 마이그레이션 중에 소스 데이터베이스가 완벽하게 운영되므로 데이터베이스에 의존하는 애플리케이션의 불가동 시간이 최소화됩니다. AWS 데이터베이스 마이그레이션 서비스를 이용하면 높은 가용성을 유지하면서 여러분의 데이터를 계속적으로 복제하고, 데이터를 Amazon Redshift 및 Amazon S3로 스트리밍하여 데이터베이스를 페타바이트 규모 데이터 웨어하우스에 통합할 수 있습니다.
여러분은 AWS 데이터베이스 마이그레이션 서비스를 이용하여 데이터를 Amazon Redshift 데이터베이스로 마이그레이션할 수 있습니다. Amazon Redshift는 완벽히 관리되는 페타바이트 규모의 클라우드 데이터 웨어하우스 서비스입니다. Amazon Redshift 데이터베이스를 타깃으로 하여 여러분은 다른 모든 지원되는 소스 데이터베이스로부터 데이터를 마이그레이션할 수 있습니다.
Amazon Redshift 클러스터는 복제 인스턴스와 동일한 AWS 계정 및 동일한 AWS 리전에 있어야 합니다. 데이터베이스를 Amazon Redshift로 마이그레이션하는 중에 AWS DMS는 먼저 데이터를 Amazon S3 버킷으로 옮깁니다. 파일들이 Amazon S3 버킷에 상주하면 이어서 AWS DMS는 그것들을 Amazon Redshift 데이터 웨어하우스 안의 적절한 테이블로 전송합니다. AWS DMS는 Amazon Redshift 데이터베이스와 동일한 AWS 리전에 S3 버킷을 생성합니다. AWS DMS 복제 인스턴스는 그 동일한 리전에 있어야 합니다.
소셜 사진 공유 웹 애플리케이션이 일래스틱 로드 밸러서 뒤에 있는 EC2 인스턴스에서 호스팅되고 있습니다. 앱은 사용자에게 사진을 업로드할 수 있는 기능을 제공하고, 앱의 홈 화면에는 순위표를 표시합니다. 업로드된 사진은 S3에 저장되고 순위표 데이터는 DynamoDB에서 유지 관리됩니다. EC2 인스턴스는 기능을 제공하기 위해 S3와 DynamoDB에 모두 접근해야 합니다.
솔루션 아키텍트로서 제안할 수 있는 가장 안전한 솔루션은 다음 중 무엇입니까?
EC2 인스턴스 프로필에 적절한 IAM 역할을 연결하여 인스턴스가 S3 및 DynamoDB에 액세스할 수 있게 한다.
EC2 인스턴스에서 실행되는 애플리케이션은 AWS API 요청에 AWS 자격 증명이 포함되어 있어야 합니다. 여러분은 개발자들이 AWS 자격 증명을 직접 EC2 인스턴스 안에 저장할 수 있고, 그 인스턴스에서 애플리케이션이 그러한 자격 증명을 사용하도록 할 수 있습니다. 그러나 그 경우에 개발자들은 자격 증명들을 관리해야 할 것이며, 자격 증명들을 안전하게 각각의 인스턴스에 전달하고 자격 증명을 전환해야 할 때에는 각각의 EC2 인스턴스를 업데이트해야 합니다.
대신에 여러분은 IAM 역할을 사용하여 EC2 인스턴스에서 실행되는 애플리케이션의 임시 자격 증명을 관리해야 합니다. 여러분이 역할을 사용할 때는 장기적 자격 증명(예를 들면 사용자 이름과 패스워드 또는 액세스 키)을 EC2 인스턴스에 분배할 필요가 없습니다. 역할은 애플리케이션이 다른 AWS 리소스를 호출할 때 사용할 수 있는 임시 권한을 공급합니다. 여러분이 EC2 인스턴스를 실행할 때는 인스턴스에 연계된 IAM 역할을 명시합니다. 그러면 인스턴스에서 실행되는 애플리케이션은 역할이 공급한 임시 자격 증명을 이용하여 API 요청에 서명할 수 있습니다. 그러므로 이 선택지가 정답입니다.
한 회사가 작은 스타트업에서 시작해 1,000명이 넘는 직원이 근무하는 기업으로 성장했습니다. 팀의 규모가 커지면서, 최근 회사에서는 S3 버킷 설정이 주기적으로 변경되는 이상 현상이 관측되었습니다.
사용자의 권리를 제한하지 않고 문제의 원인을 파악하려면 어떻게 해야 합니까?
CloudTrail을 사용해 API 호출을 분석한다. - AWS CloudTrail은 여러분의 AWS 계정에 대한 관리, 규정 준수, 운영 감사, 위험 감사를 실현해주는 서비스입니다. CloudTrail을 사용하면 여러분의 AWS 인프라 전체에 걸친 액션에 관련된 계정 행위를 로깅하고 연속적으로 모니터링하며 보관할 수 있습니다. CloudTrail은 AWS 관리 콘솔, AWS SDK, 명령줄 도구, 기타 AWS 서비스를 통해 이루어진 액션을 포함하여 여러분의 AWS 계정 활동의 이벤트 이력을 제공합니다.
일반적으로 어떤 AWS 계정 안에서 이루어진 API 호출을 분석하기 위해 CloudTrail을 사용합니다. 여러분은 사용자, 역할 또는 AWS 서비스가 Amazon S3 리소스에 한 액션을 기록하고 감사 및 규정 준수를 목적으로 로그 기록을 유지할 수 있습니다. 그렇게 하기 위해서는 서버 액세스 로깅, AWS Cloud Trail 로깅을 사용하거나 둘을 조합하여 사용할 수 있습니다. AWS에서는 여러분의 Amazon S3 리소스에 관한 버킷 및 객체 수준 액션을 로깅하기 위해 AWS CloudTrail을 사용하도록 권장하고 있습니다.
여러분은 AWS가 API Gateway 내에서 API 호출을 승인하기 위해 제공하는 다양한 인증/인가 메커니즘에 대해 조언하기 위해 한 회사에 솔루션 아키텍트로 고용되었습니다. 회사는 사용자 관리 기능을 기본으로 제공하는 솔루션을 선호합니다.
다음 중 주어진 사례에 가장 알맞은 솔루션은 무엇입니까?
Amazon Cognito 사용자 풀을 사용한다. - 사용자 풀은 Amazon Cognito의 사용자 디렉터리입니다. 여러분은 Amazon Cognito 사용자 풀을 사용하여 내장된 사용자 관리를 제공하거나 Facebook, Twitter, Google+, Amazon 같은 외부 자격 증명 제공자와 통합할 수 있습니다. 여러분의 사용자가 직접 로그인하든 제3자를 통해 로그인하든 사용자 풀의 모든 구성원은 여러분이 소프트웨어 개발 키트(SDK)를 통해 액세스할 수 있는 디렉터리 프로필을 갖게 됩니다.
사용자 풀은 다음을 제공합니다. 1. 등록 및 로그인 서비스. 2. 사용자 로그인을 위한 내장되고 맞춤화 가능한 웹 UI. 3. Facebook, Google을 이용한 소셜 로그인, Amazon을 이용한 로그인, Apple을 이용한 로그인, SAML 자격 증명 제공자를 이용한 여러분의 사용자 풀로부터의 로그인. 4. 사용자 디렉터리 관리 및 사용자 프로필. 5. 멀티팩터 인증(MFA), 손상된 자격 증명 확인, 계정 탈취 보호, 휴대폰 및 이메일 인증 등 보안 기능. 6. AWS Lambda 트리거를 통한 사용자 마이그레이션 및 맞춤화 워크플로.
API 게이트웨이에서 Amazon Cognito 사용자 풀을 만든 다음에 여러분은 해당 사용자 풀을 사용하는 COGNITO_USER_POOLS 권한 부여자를 생성해야 합니다.
한 유통 업체는 AWS 클라우드를 사용해 자사 기술 인프라를 관리합니다. 업체는 소비자 중심의 웹 애플리케이션을 EC2 기반 웹 서버에 배포했으며, 데이터 저장소로 RDS PostgreSQL DB를 사용합니다. PostgreSQL DB는 특정 EC2 인스턴스의 인바운드 트래픽을 허용하는 프라이빗 서브넷에 구성되어 있습니다. 또한 DB에서 유휴 데이터 암호화를 위해 AWS KMS를 사용합니다.
데이터베이스에 대한 보안 액세스를 구축하려면 다음 중 어느 단계를 따라야 합니까?
전송 중인 데이터에 SSL을 사용하도록 RDS를 구성한다.
전송 중인 데이터를 암호화하기 위해 여러분은 보안소켓계층/전송계층보안(SSL/TLS) 연결을 사용할 수 있습니다. Amazon RDS는 SSL 인증서를 생성하고 인스턴스가 프로비저닝될 때 해당 인증서를 DB 인스턴스에 설치합니다. MySQL의 경우, --ssl_ca 파라미터를 사용하여 MySQL 클라이언트를 실행하여 공용 키를 참조해서 연결을 암호화합니다. SSL을 사용하면 여러분의 애플리케이션과 PostgreSQL DB 인스턴스 간에 PostgreSQL 연결을 암호화할 수 있습니다. 여러분의 PostgreSQL DB 인스턴스에 대한 모든 연결이 SSL을 사용하도록 강제할 수도 있습니다.
한 IT 회사는 프로젝트별로 작업을 진행하기 위해 동일한 계정에 있는 특정 사용자들에게 S3 버킷 액세스 권한을 제공합니다. 비즈니스 요구 사항이 변경됨에 따라 교차 계정 S3 액세스 요청도 매달 증가하고 있습니다. 회사에서는 S3 버킷에 저장된 데이터에 대한 액세스 권한을 계정 수준에서뿐만 아니라 사용자 수준에서도 제공할 수 있는 솔루션을 찾고 있습니다.
다음 중 솔루션 아키텍트로서 제안할 수 있는 이 사례에 가장 적합한 액세스 권한 제어 방식을 무엇입니까?
Amazon S3 버킷 정책을 사용한다.
Amazon S3의 버킷 정책을 사용하여 하나의 버킷에 있는 객체 일부 또는 전부에 걸쳐 권한을 추가하거나 거부할 수 있습니다. 정책을 사용자, 그룹 또는 Amazon S3 버킷에 부착하여 권한을 일원화해서 관리할 수 있습니다. 버킷 정책을 사용하면 여러분의 AWS 계정 또는 다른 AWS 계정에 있는 사용자들에게 여러분의 Amazon S3 리소스에 대한 액세스 권한을 부여할 수 있습니다.
여러분은 특정한 조건을 기준으로 구체적인 리소스에 대한 액세스를 더욱 제한할 수도 있습니다. 예를 들면, 여러분은 요청 시간(날짜 조건), 요청이 SSL을 이용하여 전송되었는지의 여부(불리언 조건), 요청자의 IP 주소(IP 주소 조건) 또는 요청자의 클라이언트 애플리케이션(문자열 조건)을 기준으로 액세스를 제한할 수 있습니다. 그러한 조건들을 식별하기 위해 정책 키를 사용할 수 있습니다.
한 금융 서비스 회사에서 사내(on-premises) IT 인프라를 AWS 클라우드로 이전하려고 합니다. 회사에는 애플리케이션 스택 전반에 걸쳐 여러 장기 서버와 바인딩된 라이선스가 있는데 CTO는 AWS로 이전하는 동안에도 계속해서 라이선스를 활용하기를 원합니다.
다음 중 솔루션 아키텍트로서 제안할 수 있는 가장 경제적인 솔루션은 무엇입니까?
EC2 전용 호스트를 사용한다.
여러분은 전용 호스트를 사용하여 Amazon EC2 인스턴스를 여러분의 전용 물리 서버에서 실행할 수 있습니다. 전용 호스트를 사용하면 인스턴스가 물리 서버에 어떻게 배치되어 있는지 눈으로 확인하고 통제할 수 있으며 오랫동안 동일한 물리 서버를 안정적으로 사용할 수 있습니다. 결과적으로 전용 호스트를 사용하면 여러분은 Windows Server 같은 서버에 연계된 기존 소프트웨어 라이선스를 사용하고 기업의 규정 준수 및 규제 요건을 충족할 수 있게 됩니다.
한 뉴스 네트워크는 Amazon S3를 사용해 미국 전역에 있는 취재 팀으로부터 원본 영상 자료를 수집합니다. 최근 이 뉴스 네트워크는 유럽과 아시아로 서비스 지역을 확장했습니다. 해외 지사의 기술 팀에서 대용량의 동영상 파일을 목적지 S3 버킷으로 업로드하는 데 엄청난 시간 지연이 발생했다는 보고가 들어왔습니다.
다음 중 S3에 대한 파일 업로드 속도를 향상시킬 수 있는 가장 경제적인 방법은 무엇입니까? (2개를 고르시오.)
S3 전송 가속화(Transfer Acceleration)를 사용하여 목적지 S3 버킷으로 더 빠르게 파일을 업로드한다. - Amazon S3 Transfer Acceleration을 사용하면 여러분의 클라이언트와 S3 버킷 사이의 먼 거리에 걸쳐 파일들을 빠르고 쉬우며 안전하게 전송할 수 있습니다. Transfer Acceleration은 Amazon CloudFront의 전 세계적으로 분포된 엣지 위치를 활용합니다. 데이터가 엣지 위치에 도달하면 최적화된 네트워크 경로를 거쳐 데이터가 Amazon S3로 라우팅됩니다.
멀티파트(multipart) 업로드를 사용해 목적지 S3 버킷으로 더 빠르게 파일을 업로드한다. - 멀티파트 업로드를 사용하면 하나의 객체를 부분들로서 업로드할 수 있습니다. 각각의 부분들은 객체 데이터의 인접한 부분들입니다. 여러분은 그러한 객체 부분들을 독립적으로, 그리고 어떤 순서로도 업로드할 수 있습니다. 어떤 부분의 전송이 실패하면 여러분은 다른 부분에 영향을 미치지 않고 그 부분을 재전송할 수 있습니다. 객체의 모든 부분이 업로드되면 Amazon S3는 그 부분들을 조립하여 객체를 만듭니다. 일반적으로 여러분의 객체 크기가 100MB에 도달하면 객체를 한 번의 작업으로 업로드하는 대신에 멀티파트 업로드 이용을 고려해야 합니다. 멀티파트 업로드는 처리속도가 개선되므로 더 빠르게 파일을 업로드하는 데 도움이 됩니다.
한 유통 조직에서 사내 서버 데이터를 AWS 클라우드로 이전하고 있습니다. 조직의 DevOps 팀은 인터넷을 통해 원격 온프레미스 네트워크와 Amazon VPC AWS 사이에 관리형 IP Sec VPN 연결을 구성했습니다.
다음 중 IP Sec VPN 연결 구성에 대해 올바르게 설명한 것은 무엇입니까?
VPN의 AWS 측에는 가상 프라이빗 게이트웨이를 생성하고, 온프레미스 측에는 고객(Customer) 게이트웨이를 생성한다.
Amazon VPC는 원격 고객 네트워크와 그들의 Amazon VPC 간에 인터넷을 통해 IPsec VPN 연결(사이트 간(site-to-site) VPN이라고도 부름)을 생성하기 위한 도구를 제공합니다. 다음은 사이트 간 VPN의 핵심 개념들입니다.
가상 사설 게이트웨이: 가상 사설 게이트웨이(또는 VPN 게이트웨이라고도 부름)는 여러분의 VPN 연결의 AWS VPC 쪽 엔드포인트입니다.
VPN 연결: 여러분의 온프레미스 장비와 VPC 간의 보안 연결입니다.
VPN 터널: 데이터가 고객 네트워크와 AWS 사이를 오갈 수 있는 암호화된 링크입니다.
고객 게이트웨이: 여러분의 고객 게이트웨이 장치에 관한 정보를 AWS에 제공하는 AWS 리소스입니다.
고객 게이트웨이 장치: 사이트 간 VPN 연결의 고객 측에 있는 물리적 장치 또는 소프트웨어 애플리케이션입니다.
회사에서 Elastic Beanstalk를 사용해 웹 사이트를 배포하고 있습니다. 이 웹 사이트는 설치하는 데 45분 이상이 소요되며 설치 과정 중에 생성해야 하는 정적 파일과 동적 파일을 모두 포함하고 있습니다.
솔루션 아키텍트는 Elastic Beanstalk 배포 환경에서 새 인스턴스를 생성하는 데 걸리는 시간을 2분 미만으로 단축하고자 합니다. 이 요구 사항에 대한 솔루션을 구축하려면 다음의 선택지를 어떻게 조합해야 합니까? (2개를 고르시오.)
AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker로 개발한 웹 애플리케이션과 서비스를 Apache, Nginx, Passenger, IIS 등의 유명한 서비스에 배포하고 스케일링하는 데 사용되는 간편한 서비스입니다.
여러분이 간단히 코드를 업로드하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, 자동 스케일링부터 애플리케이션 건전성 모니터링까지 배포를 자동으로 처리합니다. 또한 여러분은 애플리케이션을 지원하는 AWS 리소스에 대해 완전한 통제력을 유지하고 언제라도 그러한 리소스에 액세스할 수 있습니다.
여러분이 AWS Elastic Beanstalk 환경을 생성할 때 플랫폼 버전에 포함된 표준 Elastic Beanstalk AMI 대신에 Amazon Machine Image(AMI)를 지정할 수 있습니다. 커스텀 AMI를 사용하면 표준 AMI에 포함되어 있지 않은 많은 소프트웨어를 설치해야 할 경우, 여러분의 환경에서 인스턴스가 실행될 때 프로비저닝 시간을 개선할 수 있습니다.
정적 설치 컴포넌트가 구성되어 있는 골든 이미지(Golden AMI)를 생성한다. - Golden AMI는 구성, 일관된 보안 패칭, 보강을 통해 표준화하는 AMI입니다. Golden AMI에는 여러분이 로깅, 보안, 성능 모니터링 등을 위해 승인한 에이전트도 포함되어 있습니다. 제시된 활용 사례의 경우, 여러분은 Golden AMI를 통해 이미 설정한 정적 설치 컴포넌트를 가질 수 있습니다.
EC2 사용자 데이터를 사용해 부팅 시점에 동적 설치 부분의 설정을 변경한다. - EC2 인스턴스 사용자 데이터는 여러분이 인스턴스를 실행하는 중에 구성 스크립트 형태로 지정하는 데이터입니다. 여러분은 EC2 사용자 데이터를 이용하여 부팅 시 애플리케이션 자체를 설치하는 대신에, 부팅 시 동적 설치 부분을 사용자 지정할 수 있습니다.
한 건강 관리 회사는 사내 인프라를 사용해 호스트 운영 체제(OS) 및 기존 Oracle 데이터베이스에 대한 특수 사용자 지정이 필요한 레거시 애플리케이션을 실행하고 있습니다. 또한 이 회사에서는 Oracle 데이터베이스 계층의 가용성을 개선하기를 원합니다. 회사는 기존 인프라 유지 관리에 드는 노력을 최소화하면서 AWS에 위와 같은 요구 사항을 충족하는 솔루션을 구축하기 위해 AWS 공인 솔루션 아키텍트 어소시에이트인 여러분을 고용했습니다.
다음 중 이런 경우에 가장 적합한 솔루션을 설명하고 있는 것은 무엇입니까?
Oracle용 RDS Custom에서 다중 AZ 설정을 사용하여 데이터베이스 관리자가 데이터베이스 환경 및 운영 체제에 접근해 사용자 지정할 수 있도록 한다.
Amazon RDS는 클라우드에서 관계형 데이터베이스의 설정, 운영, 스케일링을 쉽게 만들어주는 매니지드 서비스입니다. Amazon RDS는 많은 시간이 드는 데이터베이스 관리 작업을 관리하는 한편 경제적이고 사이즈 재설정이 가능한 용량을 제공합니다. Amazon RDS는 여러분의 데이터베이스를 자동으로 백업하고 여러분의 데이터베이스 소프트웨어를 최신 버전으로 유지할 수 있습니다. 그러나 RDS를 이용하여 데이터베이스의 호스트 OS에 액세스할 수는 없습니다.
RDS Custom for Oracle은 예를 들어 특수 패치를 적용하고 데이터베이스 소프트웨어 설정을 변경하여, 특권 액세스를 요구하는 서드파티 애플리케이션을 지원함으로써 여러분이 데이터베이스 서버 호스트와 운영체계에 액세스하고 맞춤화할 수 있게 해주므로 제시된 활용 사례에서 여러분은 RDS Custom for Oracle을 사용해야 합니다. RDS Custom for Oracle은 최소한의 인프라 유지보수 노력으로 그러한 기능을 보조해 줍니다. 여러분은 높은 가용성을 위해 multi-AZ 구성에서 RDS Custom for Oracle을 설정해야 합니다.
Amazon EC2에서는 인스턴스를 시작하는 순간부터 종료될 때까지 인스턴스를 관리할 수 있습니다. EC2 인스턴스 상태를 변경하여 컴퓨팅 비용을 유연하게 제어할 수 있습니다.
다음 중 EC2 청구에 관한 설명으로 옳지 않은 것은? (2개 선택)
온디맨드 인스턴스가 중지 상태로 최대 절전 모드로 전환될 준비가 되면 요금이 청구됩니다.
예약 인스턴스가 종료된 상태일 때 요금이 청구됩니다.
pending
인스턴스는 running 상태로 될 준비를 하고 있습니다. 인스턴스를 처음 시작하거나 pending 상태의 인스턴스를 다시 시작하면 stopped 상태가 됩니다.
인스턴스 사용 요금 : 미청구
running
인스턴스를 실행하고 사용할 준비가 되었습니다.
인스턴스 사용 요금 : 청구
stopping
인스턴스가 중지 또는 중지-최대 절전 모드로 전환할 준비를 하고 있습니다.
인스턴스 사용 요금 : 중지 준비 중인 경우 미청구
인스턴스 사용 요금 : 최대 절전 모드로 전환 준비 중인 경우 청구
stopped
인스턴스가 종료되고 사용이 불가합니다. 언제든지 인스턴스를 다시 시작할 수 있습니다.
인스턴스 사용 요금 : 미청구
shutting-down
인스턴스가 종료할 준비를 하고 있습니다.
인스턴스 사용 요금 : 미청구
terminated
인스턴스가 영구적으로 삭제되었으며 시작할 수 없습니다.
인스턴스 사용 요금 : 미청구
예약 인스턴스는 예약 인스턴스 계약이 종료될 때까지 지정된 달의 각 시간에 대한 요금이 매달 청구됩니다.
인스턴스 유형을 더 이상 사용하지 않는 경우 적용 가능한 예약 인스턴스를 현재 사용 사례에 적합한 크기로 수정합니다. Amazon EC2 예약 인스턴스 Marketplace에서 인스턴스를 판매할 수도 있습니다.
회사에 개발팀이 있으며 개발팀이 AWS 관리 정책을 계정에 연결하여 신속하게 실험할 수 있도록 하고 싶지만 개발팀 자신에게 AdministratorAccess 관리 정책을 부여하여 권한 상승 것을 방지하고자 합니다.
어떻게 진행해야 할까요?
각 개발자에 대해 자신에게 연결할 수 있는 관리형 정책을 제한하는 IAM 권한 경계를 정의합니다.
AWS는 IAM 엔터티(사용자 또는 역할)에 대한 권한 경계를 지원합니다. 권한 경계는 관리형 정책을 사용하여 자격 증명 기반 정책이 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하기 위한 고급 기능입니다. 엔터티의 권한 경계를 통해 엔터티는 자격 증명 기반 정책과 권한 경계 모두에서 허용하는 작업만 수행할 수 있습니다. 여기서 IAM 권한 경계를 사용해야 합니다. IAM 그룹이 아닌 역할 또는 사용자에게만 적용할 수 있습니다.
회사는 온프레미스 데이터 센터에 연결된 10.1.0.0/27의 CIDR 블록이 있는 Amazon VPC를 사용하고 있습니다. 매분 엄청난 양의 데이터 교환을 처리하고 그 결과를 EFS에 저장하는 Lambda 함수를 생성해야 한다는 요구 사항이 있었습니다. 서버리스 아키텍처를 설정하고 Lambda 함수를 VPC에 연결한 후 Solutions Architect는 하루 중 특정 시간에 EC2ThrottledException과 같은 EC2 오류 유형에서 호출 오류가 증가하는 것을 발견했습니다.
다음 중 이 문제의 가능한 원인은 무엇입니까? (2개 선택)
Lambda 함수 구성에서 서브넷을 하나만 지정했습니다. 해당 단일 서브넷에 사용 가능한 IP 주소가 부족하고 피크 로드를 처리할 수 있는 다른 서브넷이나 가용 영역이 없습니다.
VPC에 서브넷 ENI 또는 서브넷 IP가 충분하지 않습니다.
Amazon Virtual Private Cloud(Amazon VPC)를 사용하여 데이터베이스, 캐시 인스턴스 또는 내부 서비스와 같은 리소스에 대한 사설 네트워크를 생성합니다. 함수를 VPC에 연결하여 실행 중에 프라이빗 리소스에 액세스합니다.
AWS Lambda는 기본적으로 VPC 내에서 안전하게 함수 코드를 실행합니다. 그러나 Lambda 함수가 프라이빗 VPC 내부의 리소스에 액세스할 수 있도록 하려면 VPC 서브넷 ID 및 보안 그룹 ID를 포함하는 추가 VPC별 구성 정보를 제공해야 합니다. AWS Lambda는 이 정보를 사용하여 함수가 프라이빗 VPC 내의 다른 리소스에 안전하게 연결할 수 있도록 하는 탄력적 네트워크 인터페이스(ENI)를 설정합니다.
Lambda 함수는 전용 인스턴스 테넌시가 있는 VPC에 직접 연결할 수 없습니다. 전용 VPC의 리소스에 연결하려면 기본 테넌시가 있는 두 번째 VPC에 피어링합니다.
Lambda 함수는 처리하는 이벤트 수에 따라 자동으로 확장됩니다. Lambda 함수가 VPC에 액세스하는 경우 VPC에 Lambda 함수의 확장 요구 사항을 지원하기에 충분한 ENI 용량이 있는지 확인해야 합니다. 또한 Lambda 함수 구성의 각 가용 영역에 하나 이상의 서브넷을 지정하는 것이 좋습니다.
각 가용 영역에 서브넷을 지정하면 하나가 다운되거나 IP 주소가 부족한 경우 다른 가용 영역에서 Lambda 함수를 실행할 수 있습니다. VPC에 ENI 또는 서브넷 IP가 충분하지 않은 경우 Lambda 함수는 요청 증가에 따라 확장되지 않으며 EC2ThrottledException과 같은 EC2 오류 유형으로 호출 오류가 증가하는 것을 보게 됩니다. 비동기식 호출의 경우 해당 CloudWatch Logs 없이 오류가 증가하는 경우 콘솔에서 동기식으로 Lambda 함수를 호출하여 오류 응답을 받습니다.
Solutions Architect는 AWS CLI를 사용하여 기본 설정으로 완전히 새로운 IAM 사용자를 생성했습니다. 이는 Amazon S3, DynamoDB, Lambda 및 회사 클라우드 인프라의 기타 AWS 리소스에 API 요청을 보내는 데 사용하기 위한 것입니다.
사용자가 AWS 리소스에 대한 API 호출을 수행할 수 있도록 하려면 다음 중 무엇을 수행해야 합니까?
사용자에 대한 액세스 키 세트를 생성하고 필요한 권한을 첨부합니다.
IAM 사용자에게 적합한 자격 증명을 선택할 수 있습니다. AWS Management 콘솔을 사용하여 사용자를 생성할 때 최소한 콘솔 암호 또는 액세스 키를 포함하도록 선택해야 합니다. 기본적으로 AWS CLI 또는 AWS API를 사용하여 생성된 새로운 IAM 사용자에게는 어떤 종류의 자격 증명도 없습니다. 사용자의 요구 사항에 따라 IAM 사용자에 대한 자격 증명 유형을 생성해야 합니다.
액세스 키는 IAM 사용자 또는 AWS 계정 루트 사용자의 장기 자격 증명입니다. 액세스 키를 사용하여 AWS CLI 또는 AWS API에 대한 프로그래밍 방식 요청에 서명할 수 있습니다(직접 또는 AWS SDK 사용). 사용자는 AWS 명령줄 인터페이스(AWS CLI), Windows PowerShell용 도구, AWS SDK에서 프로그래밍 방식으로 AWS를 호출하거나 개별 AWS 서비스용 API를 사용하여 직접 HTTP를 호출하려면 고유한 액세스 키가 필요합니다.
이러한 요구 사항을 충족하기 위해 IAM 사용자에 대한 액세스 키(액세스 키 ID 및 보안 액세스 키)를 생성, 수정, 확인 또는 교체할 수 있습니다. 액세스 키를 생성하면 IAM이 액세스 키 ID와 보안 액세스 키를 반환합니다. 안전한 위치에 저장하고 사용자에게 제공해야 합니다.
회사는 EC2 인스턴스의 Auto Scaling 그룹에서 웹 애플리케이션을 호스팅했습니다. IT 관리자는 더 높은 운영 비용을 유발할 수 있는 리소스의 과잉 공급에 대해 우려하고 있습니다. Solutions Architect는 애플리케이션의 성능에 영향을 주지 않으면서 비용 효율적인 솔루션을 만들라는 지시를 받았습니다.
이 요구 사항을 충족하려면 어떤 동적 조정 정책을 사용해야 합니까?
Auto Scaling의 대상 추적 조정 정책을 사용합니다.
오토 스케일링 그룹에는 자동 크기 조정 및 관리를 위해 논리적 그룹으로 취급되는 EC2 인스턴스 모음이 포함되어 있습니다. 오토 스케일링을 통해 상태 검사 교체 및 크기 조정 정책과 같은 Amazon EC2 Auto Scaling 기능도 사용할 수 있습니다. 오토 스케일링 내 인스턴스 수 유지와 및 자동 크기 조정, 이 두 가지가 Amazon EC2 Auto Scaling 서비스의 핵심 기능입니다.
오토 스케일링의 크기는 사용자가 원하는 용량으로 설정한 인스턴스 수에 따라 달라집니다. 수동으로 또는 자동 크기 조정을 사용하여 수요에 맞게 크기를 조정할 수 있습니다.
오토 스케일링은 원하는 용량을 충족하도록 충분한 인스턴스를 실행하여 시작합니다. 그룹 내 인스턴스에 대한 주기적인 상태 확인을 수행하여 이 인스턴스 수를 유지합니다. 오토 스케일링은 인스턴스 상태가 이상이 있는 경우에도 고정된 수의 인스턴스를 계속 유지합니다. 인스턴스가 비정상 상태가 되면 그룹에서는 비정상 인스턴스를 종료하고 이를 대체할 다른 인스턴스를 시작합니다.
조정 정책을 사용하여 바뀌는 조건을 충족하도록 그룹의 인스턴스 수를 동적으로 늘리거나 줄일 수 있습니다. 조정 정책의 효력이 발생되면, 오토 스케일링이 해당 그룹의 희망 용량을 사용자가 지정하는 최소 및 최대 용량 값 사이에서 조절하고 필요에 따라 인스턴스를 시작 또는 종료합니다. 일정에서도 확장이 가능합니다.
동적 조정은 트래픽의 변화에 따라 오토 스케일링 그룹의 용량을 조정합니다.
Amazon EC2 Auto Scaling은 다음과 같은 유형의 동적 조정 정책을 지원합니다.
1. 대상 추적 조정(Target tracking scaling) -Amazon CloudWatch 지표와 목표 값을 기준으로 그룹의 현재 용량을 늘리거나 줄입니다. 이는 온도 조절기가 집안 온도를 유지하는 방식과 비슷하게 작동합니다. 사용자가 온도만 선택하면 나머지는 온도 조절기가 알아서 합니다.
2. 단계 조정(Step scaling) - 그룹의 현재 용량을 일련의 조정 조절에 따라 늘리고 줄이며 경보 위반의 크기에 따라 달라지는 단계 조절이라고 합니다.
3. 단순 조정(Simple scaling) - 단일 조정 설정에 따라 그룹의 현재 용량을 늘리고 줄입니다. 각 조정 작업 간에는 휴지 기간이 발생합니다.
오토 스케일링 그룹의 인스턴스 수에 비례하여 증가하거나 감소하는 지표를 기준으로 조정하는 경우 대상 추적 조정 정책을 사용하는 것이 좋습니다. 그렇지 않은 경우 단계 조정 정책을 사용하는 것이 좋습니다.
대상 추적을 사용하면 오토 스케일링 그룹이 애플리케이션의 실제 부하에 정비례하여 조정됩니다. 즉, 대상 추적 정책은 로드 변화에 대응하여 즉각적인 용량 요구 사항을 충족하는 것 외에도, 계절적 변동 등으로 인해 시간 경과에 따라 발생하는 로드 변화에도 맞추어 조정할 수 있습니다.
기본적으로 새 오토 스케일링 그룹은 조정 정책 없이 시작됩니다. 어떠한 형태의 동적 조정도 없이 오토 스케일링 그룹을 사용하는 경우, 예약된 조정 또는 예측 조정을 설정하지 않는 한 자체적으로 조정되지 않습니다.
회사에서 일하는 개발팀은 EC2에 애플리케이션을 배포했으며 변경 사항에 신속하게 대응할 수 있는 경보를 설정하기 위해 1분 해상도로 관련 지표에 대한 CloudWatch 모니터링이 필요합니다.
다음 중 가장 최적의 솔루션은 무엇입니까?
EC2 세부 모니터링을 활성화합니다.
지표는 CloudWatch의 기본 개념입니다. 지표는 CloudWatch에 게시되는 시간 순서의 데이터 포인트 세트를 나타냅니다. 메트릭을 모니터링할 변수로 생각하고 데이터 포인트를 시간 경과에 따른 해당 변수의 값을 나타내는 것으로 생각합니다.
기본적으로 인스턴스는 기본 모니터링을 위해 활성화되어 있습니다. 선택적으로 세부 모니터링을 활성화할 수 있습니다. 세부 모니터링을 활성화하면 Amazon EC2 콘솔에 인스턴스에 대한 모니터링 그래프가 1분 간격으로 표시됩니다. 따라서 주어진 사례에 대해 EC2 세부 모니터링을 사용할 수 있습니다. CloudWatch로 전송된 지표별로 요금이 부과됩니다. 데이터 저장에 대해서는 요금이 부과되지 않습니다.
회사는 다양한 웹 도메인의 트래픽을 처리하는 Application Load Balancer 뒤의 Auto Scaling 온디맨드 EC2 인스턴스 그룹에서 호스팅되는 웹 애플리케이션 제품군을 보유하고 있습니다. 보안을 개선하고 전체 비용을 줄이기 위해 새 도메인을 추가할 때마다 인증서를 재인증하고 다시 프로비저닝할 필요 없이 여러 도메인이 SSL 트래픽을 제공하도록 허용하여 시스템을 보호하라는 지시를 받습니다. HTTP에서 HTTPS로의 마이그레이션은 SEO 및 Google 검색 순위를 높이는 데 도움이 됩니다.
다음 중 위의 요구 사항을 충족하는 가장 비용 효율적인 솔루션은 무엇입니까?
콘솔을 사용하여 ALB에 있는 도메인의 모든 SSL 인증서를 업로드하고 로드 밸런서의 동일한 리스너에 여러 인증서를 바인딩합니다. ALB는 SNI(Server Name Indication)를 사용하여 각 클라이언트에 대해 최적의 TLS 인증서를 자동으로 선택합니다.
SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다. 하지만 쉽게 이해할 수 있도록 이 글에서는 TLS라는 용어를 사용하겠습니다.
TLS는 암호, 쿠키, 신용 카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 즉 인증 기관(CA)을 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.
SNI 지원이 시작되면서 이제는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 되었습니다. 다수의 인증서가 필요한 가장 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 단순 패턴이 일치하는 하위 도메인에서만 사용 가능합니다. 또한 SAN 인증서가 다수의 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.
애플리케이션 로드 밸런서(ALB)에서 서버 이름 표시(SNI)를 사용해 다중 TLS/SSL 인증서 지원됩니다. 단일 로드 밸런서 뒤에서 각각 자체 TLS 인증서를 갖는 다수의 TLS 보안 애플리케이션을 호스팅할 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의TLS 인증서를 자동으로 선택합니다. 이러한 새로운 기능은 추가 요금 없이 제공됩니다.
엔지니어링팀은 퍼블릭 및 프라이빗 서브넷이 있는 VPC를 설계하고 있습니다. VPC와 서브넷은 IPv4 CIDR 블록을 사용합니다. 고가용성을 위해 세 개의 가용 영역(AZ) 각각에 하나의 퍼블릭 서브넷과 하나의 프라이빗 서브넷이 있습니다. 인터넷 게이트웨이는 퍼블릭 서브넷에 대한 인터넷 액세스를 제공하는 데 사용됩니다. 프라이빗 서브넷은 EC2 인스턴스가 소프트웨어 업데이트를 다운로드할 수 있도록 인터넷에 액세스할 수 있어야 합니다.
다음 옵션 중 프라이빗 서브넷에 대한 인터넷 액세스를 설정하는 올바른 솔루션을 나타내는 것은 무엇입니까?
각 AZ의 각 퍼블릭 서브넷에 하나씩 3개의 NAT 게이트웨이를 설정합니다. 로컬이 아닌 트래픽을 해당 AZ의 NAT 게이트웨이로 전달하는 각 AZ에 대한 사용자 지정 라우팅 테이블을 생성합니다.
NAT(네트워크 주소 변환) 게이트웨이를 사용하여 프라이빗 서브넷의 인스턴스가 인터넷이나 다른 AWS 서비스에 연결할 수 있도록 할 수 있지만 인터넷이 해당 인스턴스와의 연결을 시작하지 못하도록 할 수 있습니다.
NAT 게이트웨이를 생성하려면 NAT 게이트웨이가 있어야 하는 퍼블릭 서브넷을 지정해야 합니다. NAT 게이트웨이를 생성할 때 연결할 탄력적 IP 주소도 지정해야 합니다. 탄력적 IP 주소를 NAT 게이트웨이와 연결한 후에는 변경할 수 없습니다. NAT 게이트웨이를 생성한 후에는 하나 이상의 프라이빗 서브넷과 연결된 라우팅 테이블을 업데이트하여 인터넷 바인딩 트래픽이 NAT 게이트웨이를 가리키도록 해야 합니다. 이렇게 하면 프라이빗 서브넷의 인스턴스가 인터넷과 통신할 수 있습니다.
각 NAT 게이트웨이는 특정 가용 영역에서 생성되고 해당 영역에서 중복으로 구현됩니다.
여러 가용 영역에 리소스가 있고 하나의 NAT 게이트웨이를 공유하는 경우 NAT 게이트웨이의 가용 영역이 다운되면 다른 가용 영역의 리소스는 인터넷에 액세스할 수 없습니다. 가용 영역 독립 아키텍처를 생성하려면 각 가용 영역에서 NAT 게이트웨이를 생성하고 리소스가 동일한 가용 영역에서 NAT 게이트웨이를 사용하도록 라우팅을 구성합니다.
회사는 사내 데이터 센터에 저장되는 기밀 데이터를 생성하고 있습니다. 회사는 백업 솔루션으로 데이터를 Amazon S3 버킷에 업로드하려고 합니다. 내부 보안 의무에 따라 데이터를 Amazon S3로 보내기 전에 암호화를 수행해야 합니다.
다음 중 이 요구 사항을 충족할 수 있는 방법은 무엇입니까? (2개 선택)
AWS Key Management Service(AWS KMS)에 저장된 고객 마스터 키로 클라이언트 측 암호화를 설정합니다.
클라이언트 측 마스터 키를 사용하여 클라이언트 측 암호화를 설정합니다.
데이터 보호란 전송 중(Amazon S3 안팎으로 데이터가 이동 중)과 유휴 시(Amazon S3 데이터 센터의 디스크에 데이터가 저장된 동안) 데이터를 보호하는 것을 말합니다. SSL/TLS(Secure Socket Layer/Transport Layer Security)를 사용하거나 클라이언트 측 암호화를 사용하여 전송 중인 데이터를 보호할 수 있습니다. Amazon S3에서 유휴 데이터를 보호하는 다음과 같은 옵션이 있습니다.
1. 서버 측 암호화 – 데이터 센터의 디스크에 저장하기 전에 객체를 암호화하고 객체를 다운로드할 때 이를 해독하도록 Amazon S3에 요청합니다.
서버 측 암호화는 데이터를 받는 애플리케이션 또는 서비스에 의해 해당 대상에서 데이터를 암호화하는 것입니다. Amazon S3에서 데이터 센터의 디스크에 데이터를 쓰면서 객체 수준에서 데이터를 암호화하고 사용자가 해당 데이터에 액세스할 때 자동으로 암호를 해독합니다. 요청을 인증하기만 하면 액세스 권한을 갖게 되며, 객체의 암호화 여부와 관계없이 액세스 방식에는 차이가 없습니다. 예를 들어, 미리 서명된 URL을 사용하여 객체를 공유하는 경우, 해당 URL은 암호화된 객체와 암호화되지 않은 객체에 동일하게 작동합니다. 또한 버킷에 객체를 나열하는 경우 목록 API에서는 암호화 여부와 관계없이 전체 객체의 목록을 반환합니다.
암호화 키 관리 방법으로 무엇을 선택하느냐에 따라 다음과 같은 세 가지 옵션을 독립적으로 사용할 수 있습니다.
1. Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)
2. AWS Key Management Service에 저장된 KMS 키를 사용한 서버 측 암호화(SSE-KMS)
3. 고객 제공 키를 사용한 서버 측 암호화(SSE-C)
2. 클라이언트 측 암호화 – 클라이언트 측 데이터를 암호화하여 암호화된 데이터를 Amazon S3에 업로드합니다. 이 경우 사용자가 암호화 프로세스, 암호화 키 및 관련 도구를 관리합니다.
클라이언트 측 암호화는 데이터가 Amazon S3 서비스로 전달될 때 보안을 보장하기 위해 로컬에서 데이터를 암호화하는 작업입니다. Amazon S3 서비스는 암호화된 데이터를 수신하며 데이터를 암호화 또는 복호화하는 과정에 기여하지 않습니다.
클라이언트 측 암호화를 사용 설정하기 위한 다음 옵션이 있습니다.
1. AWS Key Management Service(AWS KMS)에 저장된 키를 사용합니다.
2. 애플리케이션 내에 저장한 키를 사용합니다.
회사에 느린 디스크 기반 데이터베이스에 전적으로 의존하여 성능이 저하되는 웹 애플리케이션이 있습니다. 성능을 개선하기 위해 Solutions Architect는 ElastiCache를 사용하여 인메모리 데이터 저장소를 웹 애플리케이션에 통합했습니다.
Amazon ElastiCache는 데이터베이스 성능을 어떻게 개선합니까?
데이터베이스 쿼리 결과를 캐싱합니다.
Amazon ElastiCache는 유연한 실시간 사용 사례를 지원하는 완전관리형 인 메모리 캐싱 서비스입니다. 캐싱에 ElastiCache를 사용하면 애플리케이션 및 데이터베이스 성능을 가속화할 수 있으며, 세션 스토어, 게임 리더보드, 스트리밍 및 분석과 같이 내구성이 필요하지 않는 사용 사례에서는 기본 데이터 스토어로 사용할 수 있습니다. ElastiCache는 Redis 및 Memcached와 호환 가능합니다.
인 메모리 키-값 스토어의 주된 목적은 지연 시간이 1밀리초 미만인 매우 빠른 속도와 저렴한 비용으로 데이터 복사본에 액세스할 수 있게 하는 것입니다. 대부분의 데이터 스토어에는 자주 액세스하지만 거의 업데이트하지 않는 데이터 영역이 있습니다. 또한 데이터베이스를 쿼리하면 키-값 페어 캐시에서 키를 찾는 것에 비해 확실히 속도가 느리고 비용이 많이 듭니다. 일부 데이터베이스 쿼리는 특히 수행하는 데 있어 많은 비용이 듭니다. 예로는 여러 표에 걸친 조인이나 복잡한 계산이 포함된 쿼리를 들 수 있습니다. 이러한 쿼리 결과를 캐시하여 쿼리 가격을 한 번만 지불합니다. 그런 다음 쿼리를 다시 실행할 필요 없이 여러 번 데이터를 빠르게 검색할 수 있습니다.
회사는 자체 IT 인프라를 소유하고 유지 관리하는 비즈니스에서 벗어나고 싶어합니다. 이 디지털 혁신의 일환으로 미디어 회사는 사내 데이터 센터에 있는 약 5PB의 데이터를 내구성 있는 장기 스토리지에 보관하기를 원합니다.
데이터를 가장 비용 최적화된 방식으로 마이그레이션하기 위한 권장 사항은 무엇입니까?
온프레미스 데이터를 여러 Snowball Edge Storage Optimized 디바이스로 전송합니다. Snowball Edge 데이터를 Amazon S3에 복사하고 수명 주기 정책을 생성하여 데이터를 AWS Glacier로 전환합니다.
Snowball Edge Storage Optimized는 수십 테라바이트에서 페타바이트 규모의 데이터를 AWS로 안전하고 빠르게 전송해야 하는 경우 최적의 선택입니다. 최대 80TB의 사용 가능한 HDD 스토리지, 40개의 vCPU, 1TB의 SATA SSD 스토리지 및 최대 40Gb 네트워크 연결을 제공하여 대규모 데이터 전송 및 사전 처리 사례를 처리합니다. Snowball Edge 디바이스에 저장된 데이터는 S3 버킷에 복사하고 나중에 수명 주기 정책을 통해 AWS Glacier로 전환할 수 있습니다. Snowball Edge 디바이스에서 AWS Glacier로 데이터를 직접 복사할 수 없습니다.
회사는 동일한 가용 영역의 Virtual Private Cloud 내부에 두 개의 온디맨드 EC2 인스턴스가 있지만 서로 다른 서브넷에 배포됩니다. 한 EC2 인스턴스는 데이터베이스를 실행하고 다른 EC2 인스턴스는 데이터베이스와 연결하는 웹 애플리케이션을 실행합니다. 시스템이 제대로 작동하려면 이 두 인스턴스가 서로 통신할 수 있는지 확인해야 합니다.
이러한 EC2 인스턴스가 VPC 내부에서 통신할 수 있도록 확인해야 할 사항은 무엇입니까? (2개 선택)
애플리케이션 호스트가 올바른 포트 및 프로토콜에서 데이터베이스와 통신할 수 있도록 보안 그룹이 설정되어 있는지 확인합니다.
두 서브넷 간의 통신을 허용하는 경우 네트워크 ACL을 확인합니다.
Amazon Virtual Private Cloud(Amazon VPC)를 이용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.
Virtual Private Cloud(VPC)는 사용자의 AWS 계정 전용 가상 네트워크입니다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있습니다. VPC의 IP 주소 범위를 지정하고 서브넷과 게이트웨이를 추가하고 보안 그룹을 연결합니다.
서브넷은 VPC의 IP 주소 범위입니다. Amazon EC2 인스턴스와 같은 AWS 리소스를 서브넷으로 실행할 수 있습니다. 서브넷을 인터넷, 다른 VPC 및 자체 데이터 센터에 연결하고 라우팅 테이블을 사용하여 서브넷으로/서브넷에서 트래픽을 라우팅할 수 있습니다.
보안 그룹은 연결된 리소스에 도달하고 나갈 수 있는 트래픽을 제어합니다. 예를 들어 보안 그룹을 EC2 인스턴스와 연결하면 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어합니다.
VPC를 생성할 경우 VPC는 기본 보안 그룹과 함께 제공됩니다. 각 VPC 대해 추가 보안 그룹을 생성할 수 있습니다. 보안 그룹은 해당 보안 그룹이 생성된 VPC의 리소스에만 연결할 수 있습니다.
각 보안 그룹에 대해 프로토콜 및 포트 번호를 기반으로 트래픽을 제어하는 규칙을 추가합니다. 인바운드 트래픽과 아웃바운드 트래픽에 대한 규칙 집합은 별개입니다.
네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. VPC에 대한 기본 네트워크 ACL을 사용하거나 보안 그룹에 대한 규칙과 유사한 규칙을 사용하여 VPC에 대한 사용자 지정 네트워크 ACL을 생성하여 VPC에 보안 계층을 추가할 수 있습니다.
두 서브넷 간의 통신을 허용하도록 네트워크 ACL을 적절하게 설정해야 합니다. 웹 서버가 데이터베이스 서버와 통신할 수 있도록 보안 그룹도 적절하게 구성해야 합니다.
회사는 내부 서버에 약 250TB 크기의 대용량 아카이브 데이터를 호스팅합니다. 회사는 내구성과 중복성 때문에 이러한 데이터를 S3로 이동하기로 결정했습니다. 이 회사는 현재 본사를 인터넷에 연결하는 100Mbps 전용 회선을 보유하고 있습니다.
다음 중 이러한 모든 데이터를 Amazon S3로 가져오는 가장 빠르고 비용 효율적인 방법은 무엇입니까?
여러 AWS Snowball Edge 디바이스를 주문하여 Amazon S3에 파일을 업로드합니다.
AWS Snowball은 AWS 컴퓨팅 및 스토리지 기능을 엣지 환경으로 가져오고 AWS와 데이터를 주고 받을 수 있도록, 안전하고 견고한 디바이스를 제공하는 서비스입니다. 이 견고한 디바이스를 보통 AWS Snowball 또는 AWS Snowball Edge 디바이스라고 합니다. 이전에는 이러한 디바이스의 초기 하드웨어 버전을 AWS Snowball이라고 했으며 해당 모델은 이제 업데이트된 하드웨어로 대체되었습니다. 이제 AWS Snowball 서비스는 온보드 컴퓨팅 기능과 스토리지를 모두 갖춘 Snowball Edge 디바이스를 사용합니다.
AWS Snowball Edge는 AWS Snowball 서비스에서 제공하는 엣지 컴퓨팅 및 데이터 전송 디바이스입니다. 이 디바이스는 특정 AWS 서비스가 엣지 로케이션에서 사용할 수 있는 온보드 스토리지와 컴퓨팅 성능을 탑재하고 있습니다. Snowball Edge는 선박, 풍력 발전기 및 원격 공장과 같이 외진 환경에서의 로컬 데이터 프로세싱 및 수집을 지원하기 위해 Storage Optimized 및 Compute Optimized의 두 가지 옵션으로 제공됩니다.
초기 Snowball 디바이스는 서비스가 중지되었으며 이제 Snowball Edge Storage Optimized가 데이터 전송을 위한 기본 디바이스로 사용됩니다.
거친 환경, 열악한 환경, 모바일 환경 또는 연결이 차단되었거나 간헐적인 환경에서 컴퓨팅을 실행해야 하는 경우 Snowball Edge를 고려하십시오. 또한, AWS DataSync와 같은 고속 온라인 전송 서비스에 이용할 수 있는 대역폭이 없는 상황에서 대규모 데이터 전송 및 마이그레이션을 수행할 때에도 고려할 수 있습니다.
Snowball Edge Storage Optimized는 테라바이트(TB)~페타바이트(PB)의 고용량 데이터를 안전하고 신속하게 AWS로 전송해야 할 때 선택할 수 있는 가장 적합한 데이터 전송 옵션입니다. 대량의 데이터 백로그를 전송할 경우 혹은 AWS로 전송해야 할 데이터를 자주 수집하며 고대역폭 인터넷 연결을 할 수 없거나 비용이 많이 드는 영역에 스토리지가 있는 경우 Snowball Edge Storage Optimized를 사용할 수 있습니다.
API Gateway, AWS Lambda 및 Aurora 데이터베이스 서비스를 활용하는 새로운 REST API를 개발했습니다. 웹 사이트의 대부분의 워크로드는 읽기가 많습니다. 데이터는 거의 변경되지 않으며 사용자에게 약 1시간 동안 오래된 데이터를 제공하는 것이 허용됩니다. 최근 웹사이트에 과부하가 걸리고 Aurora 데이터베이스에 발생하는 비용이 매우 높아졌습니다.
최소한의 변경으로 성능을 향상시키면서 비용을 쉽게 절감할 수 있는 방법은 무엇입니까?
API 게이트웨이 캐싱 활성화
Amazon API Gateway는 개발자가 규모에 관계없이 API를 쉽게 생성, 게시, 유지 관리, 모니터링 및 보호할 수 있는 완전 관리형 서비스입니다. API는 애플리케이션이 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능에 액세스할 수 있도록 하는 "정문" 역할을 합니다. API Gateway를 사용하여 실시간 양방향 통신 애플리케이션을 가능하게 하는 RESTful API 및 WebSocket API를 생성할 수 있습니다. API Gateway는 컨테이너화된 서버리스 워크로드와 웹 애플리케이션을 지원합니다.
Amazon API Gateway에서 API 캐싱을 활성화하여 엔드포인트의 응답을 캐싱할 수 있습니다. 캐싱을 사용하면 엔드포인트에 대한 호출 수를 줄이고 API에 대한 요청 지연 시간을 개선할 수 있습니다.
단계에 대한 캐싱을 활성화할 경우 API Gateway에서는 지정된 TTL(Time-to-Live) 기간(초) 동안 엔드포인트에 대한 응답을 캐싱합니다. 그런 다음 API Gateway는 엔드포인트에 요청하는 대신 캐시에서 엔드포인트 응답을 조회하여 요청에 응답합니다. API 캐싱에 대한 기본 TTL 값은 300초입니다. 최대 TTL 값은 3600초입니다. TTL=0이면 캐싱이 비활성화됩니다.
애플리케이션은 EC2 인스턴스의 Auto Scaling 그룹과 Amazon RDS의 Microsoft SQL Server에서 호스팅됩니다. 웹 서버와 RDS 사이의 모든 전송 데이터를 보호해야 한다는 요구 사항이 있습니다.
다음 옵션 중 구현해야 하는 가장 적합한 솔루션은 무엇입니까? (2개 선택)
rds.force_ssl 파라미터를 true로 설정하여 DB 인스턴스에 대한 모든 연결이 SSL을 사용하도록 합니다. 완료되면 DB 인스턴스를 재부팅합니다.
Amazon RDS 루트 CA 인증서를 다운로드합니다. 인증서를 서버로 가져오고 SSL을 사용하여 RDS에 대한 연결을 암호화하도록 애플리케이션을 구성합니다.
SSL(Secure Sockets Layer)을 사용하여 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스와 클라이언트 애플리케이션 간의 연결을 암호화할 수 있습니다. SSL 지원은 지원되는 모든 SQL Server 에디션에 대해 모든 AWS 리전에서 사용할 수 있습니다.
SQL Server DB 인스턴스를 생성하면 Amazon RDS가 이에 대한 SSL 인증서를 생성합니다. SSL 인증서에는 스푸핑 공격으로부터 보호하기 위해 SSL 인증서의 CN(일반 이름)으로 DB 인스턴스 엔드포인트가 포함됩니다.
SSL을 사용하여 SQL Server DB 인스턴스에 연결하는 방법에는 두 가지가 있습니다.
- 모든 연결에 SSL 강제 적용 : 이는 클라이언트에 투명하게 발생하며 클라이언트는 SSL을 사용하기 위해 작업을 수행할 필요가 없습니다.
- 특정 연결 암호화 : 특정 클라이언트 컴퓨터에서 SSL 연결을 설정하고 연결을 암호화하려면 클라이언트에서 작업해야 합니다.
DB 인스턴스에 대한 모든 연결이 SSL을 사용하도록 강제하거나 특정 클라이언트 컴퓨터의 연결만 암호화할 수 있습니다. 특정 클라이언트에서 SSL을 사용하려면 클라이언트 컴퓨터에 대한 인증서를 얻고 클라이언트 컴퓨터에서 인증서를 가져온 다음 클라이언트 컴퓨터에서 연결을 암호화해야 합니다.
SSL을 강제 실행하려면 rds.force_ssl 매개변수를 사용합니다. 기본적으로 rds.force_ssl 매개변수는 false로 설정됩니다. 연결에서 SSL을 사용하도록 하려면 rds.force_ssl 매개변수를 true로 설정합니다. rds.force_ssl 파라미터는 정적이므로 값을 변경한 후 변경 사항을 적용하려면 DB 인스턴스를 재부팅해야 합니다.
Solutions Architect는 자주 액세스하지는 않지만 감사자가 요청할 때 즉시 사용할 수 있어야 하는 재무 보고서를 저장하기 위해 새로운 표준 등급 S3 버킷을 생성했습니다. 비용을 절감하기 위해 Architect는 S3 버킷의 스토리지 클래스를 Standard에서 Infrequent Access 스토리지 클래스로 변경했습니다.
Amazon S3 Standard - Infrequent Access 스토리지 클래스에서 다음 설명 중 사실인 것은 무엇입니까? (2개 선택)
필요할 때 빠른 액세스가 필요한 데이터를 위해 설계되었습니다
액세스 빈도가 낮은 데이터용으로 설계되었습니다.
Amazon S3는 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있도록 구축된 객체 스토리지입니다. 업계 최고 수준의 내구성, 가용성, 성능, 보안 및 거의 무제한의 확장성을 아주 저렴한 요금으로 제공하는 단순한 스토리지 서비스입니다.
Amazon S3는 워크로드의 데이터 액세스, 복원력 및 비용 요구 사항에 따라 선택할 수 있는 다양한 스토리지 클래스를 제공합니다. S3 스토리지 클래스는 다양한 액세스 패턴에 대해 가장 저렴한 스토리지를 제공하기 위해 특별히 구축되었습니다. S3 스토리지 클래스는 까다로운 성능 요구 사항, 데이터 레지던시 요구 사항, 알 수 없거나 변경되는 액세스 패턴 또는 아카이브 스토리지를 포함하여 거의 모든 사용 사례에 적합합니다. 각 S3 스토리지 클래스는 데이터에 액세스하는 요금과 데이터를 저장하는 요금을 청구합니다. 어떤 S3 스토리지 클래스가 워크로드에 가장 적합한지 결정할 때 데이터의 수명에 대한 가장 저렴한 총 비용을 최적화할 수 있도록 데이터의 보존 시간과 액세스 패턴을 고려합니다.
Amazon S3 Standard(S3 Standard)
S3 Standard는 자주 액세스하는 데이터를 위해 높은 내구성, 가용성 및 성능을 갖춘 객체 스토리지를 제공합니다. S3 Standard는 짧은 지연 시간과 많은 처리량을 제공하므로 클라우드 애플리케이션, 동적 웹 사이트, 콘텐츠 배포, 모바일 및 게임 애플리케이션, 빅 데이터 분석 등의 다양한 사용 사례에 적합합니다. S3 스토리지 클래스를 객체 수준에서 구성할 수 있으며 S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA 전반에 걸쳐 저장된 여러 객체가 단일 버킷에 포함될 수 있습니다. 또한 S3 수명 주기 정책을 사용하여 애플리케이션 변경 없이 자동으로 스토리지 클래스 간에 객체를 전환할 수 있습니다.
Amazon S3 Intelligent-Tiering(S3 Intelligent-Tiering)
Amazon S3 Intelligent-Tiering(S3 Intelligent-Tiering)은 성능에 대한 영향, 검색 요금 또는 운영 부담 없이 액세스 빈도에 따라 가장 비용 효율적인 액세스 티어로 데이터를 자동으로 이동하여 세분화된 객체 수준에서 스토리지 비용을 자동으로 절감해주는 최초의 클라우드 스토리지입니다. S3 Intelligent-Tiering은 Frequent, Infrequent Access 및 Archive Instant Access 티어에서 자주 액세스하는 데이터, 자주 액세스하지 않는 데이터, 그리고 거의 액세스하지 않는 데이터에 대해 밀리초 단위의 대기 시간과 높은 처리량을 제공합니다. 거의 모든 워크로드, 특히 데이터 레이크, 데이터 분석, 새로운 애플리케이션 및 사용자 생성 콘텐츠에 대한 기본 스토리지 클래스로 S3 Intelligent-Tiering을 사용할 수 있습니다.
Amazon S3 Standard-Infrequent Access(S3 Standard-IA)
S3 Standard-IA는 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합합니다. S3 Standard-IA는 S3 Standard의 뛰어난 내구성, 높은 처리량 및 짧은 대기 시간을 저렴한 GB당 스토리지 요금과 GB당 검색 요금으로 제공합니다. 저렴한 비용과 높은 성능의 조합을 제공하는 S3 Standard-IA는 장기 스토리지, 백업 및 재해 복구 파일용 데이터 스토어에 이상적입니다. S3 스토리지 클래스를 객체 수준에서 구성할 수 있으며 S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA 전반에 걸쳐 저장된 여러 객체가 단일 버킷에 포함될 수 있습니다. 또한 S3 수명 주기 정책을 사용하여 애플리케이션 변경 없이 자동으로 스토리지 클래스 간에 객체를 전환할 수 있습니다.
Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)
S3 One Zone-IA는 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합합니다. 최소 3개의 가용 영역(AZ)에 데이터를 저장하는 다른 S3 스토리지 클래스와는 달리, S3 One Zone-IA는 단일 AZ에 데이터를 저장하며 비용이 S3 Standard-IA보다 20% 적게 듭니다. S3 One Zone-IA는 자주 액세스하지 않는 데이터에 대한 저렴한 옵션을 원하지만 S3 Standard 또는 S3 Standard-IA 스토리지와 같은 가용성 및 복원력이 필요 없는 고객에게 적합합니다. 이 서비스는 온프레미스 데이터 또는 쉽게 다시 생성할 수 있는 데이터의 보조 백업 복사본을 저장하는 경우 좋은 선택입니다. 또한, S3 교차 리전 복제를 사용하여 다른 AWS 리전에서 복제한 데이터를 위한 비용 효과적인 스토리지로 사용할 수 있습니다.
Amazon S3 Glacier Instant Retrieval
Amazon S3 Glacier Instant Retrieval은 거의 액세스하지 않으면서 밀리초 단위의 검색이 필요한 장기 데이터에 대해 가장 저렴한 비용의 스토리지를 제공하는 아카이브 스토리지 클래스입니다. S3 Glacier Instant Retrieval에서는 분기당 한 번 데이터에 액세스하는 경우 S3 Standard-Infrequent Access(S3 Standard-IA) 스토리지 클래스를 사용할 때와 비교하면 최대 68%의 스토리지 비용을 절감할 수 있습니다. S3 Glacier Instant Retrieval은 S3 Standard 및 S3 Standard-IA 스토리지 클래스와 동일한 처리량 및 밀리초 단위의 액세스를 지원하며 아카이브 스토리지에 대한 가장 빠른 액세스를 제공합니다. S3 Glacier Instant Retrieval은 의료 이미지, 뉴스 미디어 자산 또는 사용자 생성 콘텐츠 아카이브와 같이 즉각적인 액세스가 필요한 아카이브 데이터에 이상적입니다. 객체를 S3 Glacier Instant Retrieval에 직접 업로드하거나 S3 수명 주기 정책을 사용하여 S3 스토리지 클래스에서 데이터를 전송할 수 있습니다.
Amazon S3 Glacier Flexible Retrieval(이전 S3 Glacier)
S3 Glacier Flexible Retrieval은 연간 1~2회 액세스하고 비동기식으로 검색되는 아카이브 데이터에 대해 S3 Glacier Instant Retrieval보다 최대 10% 더 저렴한 비용으로 스토리지를 제공합니다. S3 Glacier Flexible Retrieval(이전 S3 Glacier)은 즉각적인 액세스가 필요하지 않지만 백업 또는 재해 복구 사용 사례와 같이 대규모 데이터 집합을 무료로 검색할 수 있는 유연성이 필요한 아카이브 데이터에 이상적인 스토리지 클래스입니다. S3 Glacier Flexible Retrieval은 몇 분 정도에서 몇 시간까지 다양한 액세스 시간에서 비용의 균형을 조정하는 가장 유연한 검색 옵션과 무료 대량 검색 기능을 제공합니다. 이는 가끔 몇 분 안에 일부 데이터를 검색해야 하고 비용에 대해 걱정하고 싶지 않은 경우, 그리고 백업, 재해 복구, 오프사이트 데이터 스토리지 요구 사항에 대해 적합한 솔루션입니다. S3 Glacier Flexible Retrieval은 특정 연도에 물리적으로 분리된 여러 AWS 가용 영역에서 데이터를 중복 저장하여 99.999999999%의 데이터 내구성과 99.99%의 가용성을 지원하도록 설계되었습니다.
Amazon S3 Glacier Deep Archive
S3 Glacier Deep Archive는 Amazon S3에서 가장 저렴한 비용의 스토리지 클래스이며 1년에 한두 번 정도 액세스할 수 있는 데이터의 장기 보관 및 디지털 보존을 지원합니다. 이 서비스는 규제 규정 준수 요건을 충족하기 위해 7~10년 이상 데이터 집합을 보관하는 고객(특히 금융 서비스, 의료, 공공 부문과 같이 엄격하게 규제되는 산업의 고객)을 위해 설계되었습니다. 또한 S3 Glacier Deep Archive는 백업 및 재해 복구 사용 사례에도 사용할 수 있으며 온프레미스 라이브러리든 오프프레미스 서비스든 상관없이 자기 테이프 시스템에 대한 비용 효과적이고 관리하기 쉬운 대안입니다. S3 Glacier Deep Archive는 Amazon S3 Glacier를 보완하며, 데이터를 정기적으로 검색하고 일부 데이터의 경우 몇 분 이내에 사용해야 할 수 있는 아카이브에 이상적입니다. S3 Glacier Deep Archive에 저장된 모든 객체는 최소 3개의 지리적으로 분산된 가용 영역에 걸쳐 복제되고 저장되며, 99.999999999%의 내구성으로 보호되고 12시간 이내에 복원할 수 있습니다.
S3 Outposts
Amazon S3 on Outposts는 온프레미스 AWS Outposts 환경에 객체 스토리지를 제공합니다. 오늘부터 AWS 리전에 제공되는 S3 API와 기능을 사용하면 S3 on Outposts는 Outpost에서 데이터를 손쉽게 저장 및 검색할 수 있을 뿐만 아니라, 데이터 보안, 액세스 제어, 태그 지정, 보고 기능도 사용할 수 있습니다. S3 on Outposts는 'OUTPOSTS'라는 단일 Amazon S3 스토리지 클래스를 제공합니다. 이 클래스는 S3 API를 사용하며 Outposts의 여러 디바이스 및 서버에서 내구성이 뛰어난 중복 데이터 저장 기능을 제공하도록 설계되었습니다. S3 Outposts 스토리지 클래스는 로컬 데이터 레지던시 요구 사항이 있는 워크로드에 적합하고, 데이터를 온프레미스 애플리케이션에 가까이 저장해서 까다로운 성능 요구 사항을 충족할 수 있습니다.
회사의 DevOps 팀은 단계 조정 정책을 사용하여 Auto Scaling 그룹의 일부인 특정 EC2 인스턴스에서 일부 유지 관리 작업을 수행하려고 합니다. 팀은 유지 관리 문제에 직면해 있습니다. 팀이 유지 관리 패치를 배포할 때마다 인스턴스 상태 확인 상태가 몇 분 동안 서비스 불가로 표시됩니다. 이로 인해 Auto Scaling 그룹은 다른 대체 인스턴스를 즉시 프로비저닝합니다.
Solutions Architect로서 유지 관리 작업을 가장 빨리 완료할 수 있도록 권장하는 가장 시간/자원 효율적인 단계는 무엇입니까? (2개 선택)
인스턴스를 대기 상태로 전환한 다음 유지 관리 패치를 적용하여 인스턴스를 업데이트합니다. 인스턴스가 준비되면 대기 상태를 종료한 다음 인스턴스를 서비스로 되돌릴 수 있습니다.
Auto Scaling 그룹에 대한 ReplaceUnhealthy 프로세스 유형을 일시 중단하고 인스턴스에 유지 관리 패치를 적용합니다. 인스턴스가 준비되면 수동으로 인스턴스의 상태를 정상으로 다시 설정하고 ReplaceUnhealthy 프로세스 유형을 다시 활성화할 수 있습니다.
InService 상태의 인스턴스를 Standby 상태로 설정하고, 인스턴스를 업데이트하거나 문제 해결한 다음, 해당 인스턴스를 서비스 상태로 되돌릴 수 있습니다. 대기 상태의 인스턴스는 오토 스케일링에 여전히 속하나, 로드 밸런서 트래픽을 처리하지는 못합니다.
이 기능을 사용하면 상태 확인의 일부로 또는 축소 이벤트 중에 인스턴스를 종료하는 Amazon EC2 Auto Scaling에 대한 걱정 없이 인스턴스를 중지 및 시작하거나 재부팅할 수 있습니다.
예를 들어 시작 템플릿 또는 시작 구성을 변경하여 오토 스케일링의 Amazon Machine Image(AMI)를 언제든 변경할 수 있습니다. 오토 스케일링이 시작하는 모든 후속 인스턴스가 이 AMI를 사용합니다. 그러나 오토 스케일링은 현재 서비스 중인 인스턴스를 업데이트하지 않습니다. 이러한 인스턴스를 종료하고 Amazon EC2 Auto Scaling이 인스턴스를 대체하도록 하거나 인스턴스 새로 고침 기능을 사용하여 인스턴스를 종료하고 대체할 수 있습니다. 또는 인스턴스 상태를 대기로 설정하고 소프트웨어를 업데이트한 후 인스턴스를 다시 서비스 상태로 설정할 수 있습니다.
ReplaceUnhealthy 프로세스는 비정상으로 표시된 인스턴스를 종료한 다음 이를 대체할 새 인스턴스를 생성합니다. Amazon EC2 Auto Scaling은 비정상으로 표시된 인스턴스 교체를 중지합니다. EC2 또는 Elastic Load Balancing 상태 확인에 실패한 인스턴스는 여전히 비정상으로 표시됩니다. ReplaceUnhealthly 프로세스를 재개하는 즉시 Amazon EC2 Auto Scaling은 이 프로세스가 일시 중단된 동안 비정상으로 표시된 인스턴스를 교체합니다.
커뮤니티 웹 사이트는 CloudFront 웹 배포를 사용하여 전 세계 수백만 사용자에게 정적 콘텐츠를 제공합니다. 사이트 관리자는 최근 사용자가 웹 사이트에 로그인하는 데 많은 시간이 걸린다는 불만을 접수하고 있습니다. 또한 사용자에게 HTTP 504 오류가 발생하는 경우도 있습니다. 관리자는 시스템을 더욱 최적화하기 위해 사용자의 로그인 시간을 크게 줄이도록 지시합니다.
다음 중 애플리케이션 성능을 향상시킬 수 있는 비용 효율적인 솔루션을 설정하기 위해 함께 사용해야 하는 옵션은 무엇입니까? (2개 선택)
Lambda@Edge를 사용하여 CloudFront 웹 배포가 사용자에게 제공하는 콘텐츠를 사용자 지정하면 Lambda 함수가 사용자에게 더 가까운 AWS 위치에서 인증 프로세스를 실행할 수 있습니다.
두 개의 오리진이 있는 오리진 그룹을 생성하여 오리진 장애 조치를 설정합니다. 하나는 기본 오리진으로 지정하고 다른 하나는 기본 오리진이 특정 HTTP 상태 코드 실패 응답을 반환할 때 CloudFront가 자동으로 전환하는 두 번째 오리진으로 지정합니다.
고가용성을 필요로 하는 시나리오에 대한 오리진 장애 조치를 사용하여 이제 CloudFront를 설정할 수 있습니다. 시작하려면 2개의 오리진(기본 오리진 및 보조 오리진)이 포함된 오리진 그룹을 만듭니다. 기본 오리진을 사용할 수 없거나 실패를 나타내는 특정 HTTP 응답 상태 코드를 반환하는 경우 CloudFront는 자동으로 보조 오리진으로 전환합니다.
오리진 장애 조치를 설정하려면 최소 2개의 오리진이 있는 배포가 전제되어야 합니다. 다음으로, 2개의 오리진이 포함된 배포에 대한 오리진 그룹을 만들고 그 중 1개의 오리진을 기본 오리진으로 설정합니다. 마지막으로, 오리진 그룹을 사용하도록 캐시 동작을 생성하거나 업데이트합니다.
Lambda@Edge를 사용하면 Node.js 및 Python Lambda 함수를 실행하여 CloudFront가 제공하는 콘텐츠를 사용자 지정하여 AWS 위치의 함수를 최종 사용자와 더 가깝게 실행할 수 있습니다. 이 함수는 서버 프로비저닝 또는 관리 없이 CloudFront 이벤트에 응답하여 실행됩니다. Lambda 함수를 사용하여 CloudFront 요청 및 응답을 다음과 같이 변경할 수 있습니다.
- CloudFront가 최종 사용자의 요청을 수신한 후(최종 사용자 요청)
- CloudFront가 오리진에 요청을 전달하기 전(오리진 요청)
- CloudFront가 오리진으로부터 응답을 수신한 후(오리진 응답)
- CloudFront가 최종 사용자에게 응답을 전달하기 전(최종 사용자 응답)
Lambda@Edge 함수를 오리진 그룹에 설정한 CloudFront 배포와 함께 사용할 수 있습니다. Lambda 함수를 사용하려면, 캐시 동작을 생성할 때 오리진 그룹에 대한 오리진 요청 또는 오리진 응답 트리거에 이 함수를 지정합니다. 오리진 그룹과 함께 Lambda@Edge 함수를 사용하는 경우, 단일 최종 사용자 요청에 대해 함수를 두 번 트리거할 수 있습니다. 예를 들어 다음 시나리오를 고려해 보십시오.
- 오리진 요청 트리거를 사용하여 Lambda@Edge 함수를 생성합니다.
- Lambda 함수는 CloudFront가 (캐시 누락 시) 기본 오리진에 요청을 보낼 때 한 번 트리거됩니다.
- 기본 오리진은 장애 조치를 위해 구성된 HTTP 상태 코드로 응답합니다.
- Lambda 함수는 CloudFront가 보조 오리진에 동일한 요청을 보낼 때 다시 트리거됩니다.
이 시나리오에서 Lambda@Edge를 사용하여 Lambda 함수가 CloudFront에서 제공하는 콘텐츠를 사용자 지정하고 사용자에게 더 가까운 AWS 위치에서 인증 프로세스를 실행하도록 할 수 있습니다. 또한 하나는 기본 오리진으로, 다른 하나는 두 번째 오리진으로 기본 오리진이 실패할 때 CloudFront가 자동으로 전환하는 두 개의 오리진으로 오리진 그룹을 생성하여 오리진 장애 조치를 설정할 수 있습니다. 이렇게 하면 사용자에게 발생하는 간헐적인 HTTP 504 오류가 완화됩니다.
회사는 내부 기업 웹 포털의 프라이빗 서브넷에서 Amazon EC2 인스턴스를 시작할 계획입니다. 보안을 위해 EC2 인스턴스는 퍼블릭 인터넷을 통과하지 않는 프라이빗 엔드포인트를 통해 Amazon DynamoDB 및 Amazon S3에 데이터를 보내야 합니다.
다음 중 위의 요구 사항을 충족할 수 있는 것은 무엇입니까?
VPC 엔드포인트를 사용하여 프라이빗 엔드포인트를 통해 S3 및 DynamoDB에 대한 모든 액세스를 라우팅합니다.
VPC 엔드포인트를 통해 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결이 필요 없이 Virtual Private Cloud(VPC)와 지원 서비스 간에 연결을 설정할 수 있습니다. 따라서 VPC에서 연결할 수 있는 특정 API 엔드포인트, 사이트 및 서비스를 제어합니다. VPC의 인스턴스는 서비스의 리소스와 통신하기 위해 퍼블릭 IP 주소가 필요하지 않습니다. VPC와 다른 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.
이 시나리오에서는 퍼블릭 인터넷에 액세스하지 않고 Amazon DynamoDB 및 Amazon S3에 데이터를 보내도록 프라이빗 엔드포인트를 구성을 요구하고 있습니다.
DynamoDB에 대한 VPC 엔드포인트를 사용하면 VPC의 Amazon EC2 인스턴스가 퍼블릭 인터넷에 노출되지 않고도 프라이빗 IP 주소를 사용해 DynamoDB에 액세스할 수 있습니다. EC2 인스턴스에 퍼블릭 IP 주소를 지정할 필요가 없으며 VPC에서 인터넷 게이트웨이, NAT 디바이스 또는 가상 프라이빗 게이트웨이가 필요 없습니다. 엔드포인트 정책을 사용하여 DynamoDB에 대한 액세스를 제어합니다. VPC와 AWS 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.
Amazon S3에 대한 VPC 엔드포인트를 사용하여 AWS EC2 인스턴스가 퍼블릭 인터넷에 노출되지 않고도 프라이빗 IP 주소를 사용하여 Amazon S3에 액세스할 수 있습니다. AWS EC2 인스턴스에 퍼블릭 IP 주소를 지정할 필요가 없으며 VPC에서 인터넷 게이트웨이, NAT 디바이스 또는 가상 프라이빗 게이트웨이가 필요 없습니다. 엔드포인트 정책을 사용하여 Amazon S3에 대한 액세스를 제어합니다. VPC와 AWS 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.
회사는 프로덕션 환경에서 사용되는 모든 AWS 리소스에 대해 IT 감사를 실시했습니다. 감사 활동 중에 애플리케이션에서 표준 및 컨버터블 예약 EC2 인스턴스의 조합을 사용하고 있음이 확인되었습니다.
다음 중 이 두 가지 유형의 예약 EC2 인스턴스를 사용할 때의 특징과 이점은 무엇입니까? (2개 선택)
사용하지 않은 표준 예약 인스턴스는 나중에 예약 인스턴스 마켓플레이스에서 판매할 수 있습니다.
컨버터블 예약 인스턴스를 사용하면 다른 인스턴스 패밀리의 다른 컨버터블 예약 인스턴스로 교환할 수 있습니다.
Amazon EC2 RI(예약 인스턴스)는 온디맨드 요금과 비교하여 상당한 할인 혜택(최대 72%)을 제공하며 특정 가용 영역에서 사용하는 경우에는 용량 예약을 제공합니다.
컨버터블 RI를 사용할 때 RI 가격의 이점을 누리면서 제품군, OS 유형 및 테넌시를 유연하게 변경할 수 있습니다. 여기서 기억해야 할 한 가지 중요한 점은 예약 인스턴스는 물리적 인스턴스가 아니라 계정에서 온디맨드 인스턴스 사용에 적용되는 청구 할인이라는 것입니다.
예약 인스턴스의 제공 클래스는 스탠다드 또는 컨버터블입니다. 스탠다드 예약 인스턴스는 컨버터블 예약 인스턴스보다 훨씬 많은 할인을 제공하지만 스탠다드 예약 인스턴스는 교환할 수 없습니다. 컨버터블 예약 인스턴스는 교환할 수 있습니다. 스탠다드 및 컨버터블 예약 인스턴스을 수정할 수 있습니다.
예약 인스턴스의 구성은 한 기간 동안 단일 인스턴스 유형, 플랫폼, 범위 및 테넌시로 구성됩니다. 컴퓨팅 요구 사항이 변경되면 예약 인스턴스를 수정하거나 교환할 수 있습니다.
예약 인스턴스 Marketplace는 서드 파티 및 AWS 고객이 기간 및 요금 옵션이 각기 다른 미사용 표준 예약 인스턴스를 판매할 수 있는 플랫폼입니다. 예를 들어 인스턴스를 새로운 AWS 리전으로 이동할 경우, 새 인스턴스 유형으로 변경한 후, 약정이 만료되기 전에 프로젝트가 종료될 경우, 비즈니스에서 변경이 필요한 경우 또는 불필요한 용량이 있는 경우 예약 인스턴스를 판매할 수 있습니다.
예약 인스턴스 Marketplace에 예약 인스턴스를 등록하는 즉시 잠재적 구매자들이 예약 인스턴스를 찾을 수 있습니다. 모든 예약 인스턴스는 남은 약정 기간 및 시간당 요금에 따라 분류됩니다.
관공서에서는 AWS에 기밀 세금 문서를 저장할 계획입니다. 파일의 민감한 정보로 인해 Solutions Architect는 스토리지 솔루션에 대한 데이터 액세스 요청을 특정 Amazon VPC로만 제한해야 합니다. 또한 솔루션은 WORM(Write-Once-Read-Many) 스토리지 모델의 규정 요구 사항을 충족하기 위해 파일이 삭제되거나 덮어쓰여지는 것을 방지해야 합니다.
Solutions Architect가 구현해야 하는 다음 옵션의 조합은 무엇입니까? (2개 선택)
특정 Amazon VPC에 대한 데이터 액세스만 제한하도록 S3 버킷에 대한 Amazon S3 액세스 포인트를 구성합니다.
S3 객체 잠금 기능이 활성화된 새 Amazon S3 버킷을 생성합니다. 버킷에 문서를 저장하고 객체 보존을 위한 법적 보존 옵션을 설정합니다.
Amazon S3 액세스 포인트는 모든 AWS서비스 또는 S3에 데이터를 저장하는 고객 애플리케이션에 대한 데이터 액세스를 간소화합니다. 액세스 포인트는 GetObject 및 PutObject 같은 S3 객체 작업을 수행하는 데 사용할 수 있는 버킷에 연결된 네트워크 엔드포인트입니다. 각 액세스 포인트에는 해당 액세스 포인트를 통해 이루어진 모든 요청에 대해 S3가 적용하는 고유한 권한 및 네트워크 제어가 있습니다. 각 액세스 포인트는 기본 버킷에 연결된 버킷 정책과 함께 작동하는 사용자 지정 액세스 포인트 정책을 적용합니다. Virtual Private Cloud(VPC)의 요청만 수락하도록 액세스 포인트를 구성하여 프라이빗 네트워크에 대한 Amazon S3 데이터 액세스를 제한할 수 있습니다. 또한 각 액세스 포인트에 대해 사용자 지정 퍼블릭 액세스 차단 설정을 구성할 수 있습니다.
S3 객체 잠금을 사용하면 write-once-read-many(WORM) 모델을 사용하여 객체를 저장할 수 있습니다. 객체 잠금은 고정된 시간 동안 또는 무기한으로 객체의 삭제 또는 덮어쓰기를 방지하는 데 도움이 될 수 있습니다. 객체 잠금을 사용하면 WORM 스토리지가 필요한 규제 요구 사항을 충족하거나 객체 변경 및 삭제에 대한 보호 계층을 추가하는 데 도움이 됩니다.
객체 잠금은 버전이 지정된 버킷에서만 작동하며, 보관 기간과 법적 보유는 개별 객체 버전에 적용됩니다. 객체 버전을 잠그면 Amazon S3는 해당 객체 버전의 메타데이터에 잠금 정보를 저장합니다. 객체에 보관 기간 또는 법적 보존을 설정하면 요청에 지정된 버전만 보호됩니다. 객체의 새로운 버전이 생성되는 것을 차단하지 않습니다.
객체를 기존의 보호된 객체와 동일한 키 이름을 가진 버킷에 넣으면 Amazon S3는 해당 객체의 새 버전을 생성하고 요청된 대로 버킷에 저장한 다음 요청이 성공적으로 완료된 것으로 보고합니다. 기존의 보호된 버전의 객체는 보관 구성에 따라 잠긴 상태로 유지됩니다.
S3 객체 잠금을 사용하려면 다음 기본 단계를 수행합니다.
1. 객체 잠금이 활성화된 새 버킷을 생성합니다.
2. (선택 사항) 버킷에 있는 객체의 기본 보관 기간을 구성합니다.
3. 버킷에 잠그고자 하는 객체를 넣습니다.
4. 보호하려는 객체에 보관 기간, 법적 보존 또는 둘 다 적용합니다.
회사가 AWS Direct Connect를 통해 온프레미스 데이터 센터를 AWS 클라우드에 연결했습니다. 이 회사는 AWS VPC에서 온프레미스 네트워크의 리소스에 대한 DNS 쿼리를 해결하고 온프레미스 네트워크에서 AWS VPC 리소스에 대한 DNS 쿼리도 해결할 수 있기를 원합니다.
다음 솔루션 중 주어진 사례를 해결하기 위해 결합할 수 있는 솔루션은 무엇입니까? (2개 선택)
Route 53 Resolver에 인바운드 엔드포인트를 생성하면 온프레미스 네트워크의 DNS 확인자가 이 엔드포인트를 통해 DNS 쿼리를 Route 53 Resolver에 전달할 수 있습니다.
Route 53 Resolver에서 아웃바운드 엔드포인트를 생성하면 Route 53 Resolver가 조건부로 이 엔드포인트를 통해 온프레미스 네트워크의 확인자에게 쿼리를 전달할 수 있습니다.
Amazon Route 53은 가용성과 확장성이 뛰어난 클라우드 DNS(Domain Name System) 웹 서비스입니다. Amazon Route 53은 사용자 요청을 Amazon EC2 인스턴스와 같이 AWS에서 실행되는 인프라에 효과적으로 연결하고 사용자를 AWS 외부의 인프라로 라우팅하는 데 사용할 수도 있습니다. 기본적으로 Route 53 Resolver는 EC2 인스턴스의 로컬 VPC 도메인 이름에 대한 DNS 쿼리에 자동으로 응답합니다. 전달 규칙을 구성하여 온프레미스 네트워크의 확인자와 DNS 확인자 간에 DNS 확인을 통합할 수 있습니다.
온프레미스 네트워크에서 AWS VPC의 리소스에 대한 DNS 쿼리를 해결하려면 Route 53 Resolver에서 인바운드 엔드포인트를 생성하면 온프레미스 네트워크의 DNS 해석기가 이 엔드포인트를 통해 DNS 쿼리를 Route 53 Resolver로 전달할 수 있습니다.
AWS VPC에서 온프레미스 네트워크의 리소스에 대한 DNS 쿼리를 확인하려면 Route 53 Resolver에서 아웃바운드 엔드포인트를 생성하면 Route 53 Resolver가 이 엔드포인트를 통해 온프레미스 네트워크의 확인자에게 쿼리를 조건부로 전달할 수 있습니다. 선택한 쿼리를 전달하려면 전달하려는 DNS 쿼리의 도메인 이름(예: example.com) 및 쿼리를 전달하려는 네트워크에 있는 DNS 해석기의 IP 주소를 지정하는 Resolver 규칙을 생성합니다. 쿼리가 여러 규칙(example.com, acme.example.com)과 일치하는 경우 Resolver는 가장 확실히 일치하는 규칙(acme.example.com)을 선택하고 해당 규칙에 지정한 IP 주소에 쿼리를 전달합니다.
회사는 Amazon S3에서 데이터를 정기적으로 푸시하고 가져오는 EC2 인스턴스에서 애플리케이션을 호스팅하고 있습니다. 규정 준수 변경으로 인해 인스턴스를 프라이빗 서브넷에서 이동해야 합니다. 이러한 변화와 함께 회사는 AWS 리소스를 구성하여 데이터 전송 비용을 낮추고자 합니다.
가장 비용 효율적인 방식으로 이를 수행할 수 있는 방법은 무엇입니까?
Amazon S3 게이트웨이 엔드포인트를 생성하여 인스턴스와 Amazon S3 간의 연결을 활성화합니다.
VPC 엔드포인트를 통해 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결이 필요 없이 Virtual Private Cloud(VPC)와 지원 서비스 간에 연결을 설정할 수 있습니다. 따라서 VPC에서 연결할 수 있는 특정 API 엔드포인트, 사이트 및 서비스를 제어합니다.
VPC 엔드포인트는 가상 디바이스입니다. 수평으로 확장된 고가용성 중복 VPC 구성 요소입니다. 다음은 다양한 유형의 VPC 엔드포인트입니다. 지원되는 서비스에서 요구하는 유형의 VPC 엔드포인트를 생성합니다.
인터페이스 엔드포인트
인터페이스 엔드포인트는 서브넷의 IP 주소 범위에서 프라이빗 IP 주소를 사용하는 탄력적 네트워크 인터페이스이며, AWS가 소유하거나 AWS 고객 또는 파트너가 소유한 서비스로 전달되는 트래픽에 대한 진입점 역할을 합니다.
Gateway Load Balancer 엔드포인트
Gateway Load Balancer 엔드포인트는 서브넷의 IP 주소 범위에서 프라이빗 IP 주소를 사용하는 탄력적 네트워크 인터페이스입니다. 트래픽을 가로채고 Gateway Load Balancer를 사용하여 구성한 네트워크 또는 보안 서비스로 라우팅하는 진입점 역할을 합니다. Gateway Load Balancer 엔드포인트를 라우팅 테이블의 경로에 대한 대상으로 지정합니다. Gateway Load Balancer 엔드포인트는 Gateway Load Balancer를 사용해 구성된 엔드포인트 서비스에서만 지원됩니다.
게이트웨이 엔드포인트
게이트웨이 엔드포인트는 라우팅 테이블의 경로에 대한 대상인 게이트웨이로, Amazon S3 또는 DynamoDB로 전달되는 트래픽에 사용됩니다.
두 가지 유형의 VPC 엔드포인트, 즉 게이트웨이 엔드포인트와 인터페이스 엔드포인트(AWS PrivateLink 사용)를 사용하여 Amazon S3에 액세스할 수 있습니다. 게이트웨이 엔드포인트는 AWS 네트워크를 통해 VPC에서 Amazon S3에 액세스하기 위해 라우팅 테이블에 지정하는 게이트웨이입니다. 인터페이스 엔드포인트는 프라이빗 IP 주소를 통해 온프레미스의 VPC 내에서 또는 VPC 피어링이나 AWS Transit Gateway를 사용하여 다른 AWS 리전의 VPC에서 Amazon S3로 요청을 라우팅함으로써 게이트웨이 엔드포인트의 기능을 확장합니다.
회사는 여러 애플리케이션에서 사용되는 MySQL용 Amazon RDS 데이터베이스에 대한 보안 액세스가 필요합니다. 각 IAM 사용자는 데이터베이스에 연결하기 위해 단기 인증 토큰을 사용해야 합니다.
다음 중 이 시나리오에서 가장 적합한 솔루션은 무엇입니까?
IAM DB 인증을 사용하고 MySQL에서 AWS 제공 AWSAuthenticationPlugin 플러그인을 사용하여 데이터베이스 계정을 생성합니다.
AWS Identity and Access Management(IAM) 데이터베이스 인증을 사용하여 DB 인스턴스에 인증할 수 있습니다. IAM 데이터베이스 인증은 MariaDB, MySQL, PostgreSQL과 함께 작동합니다. 이러한 인증 방식은 DB 인스턴스에 연결할 때 암호를 사용할 필요 없습니다. 대신에 인증 토큰을 사용합니다.
인증 토큰이란 요청이 있을 때 Amazon RDS가 생성하는 고유 문자열입니다. 인증 토큰은 AWS 서명 버전 4를 통해 생성됩니다. 각 토큰의 수명은 15분입니다. 인증을 외부에서 IAM을 사용해 관리하기 때문에 사용자 자격 증명을 데이터베이스에 저장할 필요도 없습니다. 또한 표준 데이터베이스 인증 방식도 사용 가능합니다. 토큰은 인증에만 사용되며 설정된 후에는 세션에 영향을 주지 않습니다.
IAM 데이터베이스 인증은 다음과 같은 이점이 있습니다.
- 데이터베이스를 오가는 네트워크 트래픽은 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)를 통해 암호화됩니다. Amazon RDS에서 SSL/TLS를 사용하는 방법에 대한 자세한 내용은 SSL/TLS를 사용하여 DB 인스턴스에 대한 연결 암호화 단원을 참조하십시오.
- 데이터베이스 리소스에 대한 액세스는 DB 인스턴스에서 개별적으로 관리할 필요 없이 IAM을 통해 중앙에서 관리할 수 있습니다.
- Amazon EC2에서 실행되는 애플리케이션의 경우, 암호가 아닌 EC2 인스턴스용 프로파일 자격 증명을 사용해 데이터베이스에 액세스하기 때문에 보안을 더욱 강화하는 효과가 있습니다.
일반적으로 애플리케이션에서 초당 200개 미만의 연결을 생성하고 애플리케이션 코드에서 사용자 이름과 암호를 직접 관리하지 않으려는 경우 IAM 데이터베이스 인증을 사용하는 것이 좋습니다.
시나리오에서는 Amazon RDS 데이터베이스에 액세스하기 위해 단기 인증 토큰을 생성하도록 요청하므로 데이터베이스 인스턴스에 연결할 때 IAM 데이터베이스 인증을 사용할 수 있습니다. 인증은 IAM과 원활하게 작동하여 IAM 사용자를 인증하는 AWS 제공 플러그인인 AWSAuthenticationPlugin에 의해 처리됩니다.
회사는 5분마다 공개 Application Load Balancer를 통과한 모든 HTTP 요청의 세부 정보를 캡처해야 합니다. 클라이언트의 IP 주소와 네트워크 대기 시간도 추적해야 합니다. 트래픽 패턴을 분석하고 Amazon ECS Anywhere 서비스에서 조정하는 Docker 애플리케이션 문제를 해결하는 데 이 데이터를 사용하려고 합니다.
다음 옵션 중 최소한의 오버헤드로 요구 사항을 충족하는 옵션은 무엇입니까?
Application Load Balancer에서 액세스 로그를 활성화합니다. Amazon ECS 클러스터를 Amazon CloudWatch Application Insights와 통합하여 트래픽 패턴을 분석하고 문제 해결을 간소화합니다.
Amazon CloudWatch Application Insights는 애플리케이션 및 기본 AWS 리소스에 대한 관찰 가능성을 용이하게 합니다. 애플리케이션 리소스에 대한 최상의 모니터를 설정하여 애플리케이션 문제의 징후에 대한 데이터를 지속적으로 분석하는 데 도움이 됩니다. SageMaker 및 기타 AWS 기술로 구동되는 Application Insights는 모니터링되는 애플리케이션의 잠재적인 문제를 보여주는 자동화된 대시보드를 제공하여 애플리케이션 및 인프라에서 진행 중인 문제를 신속하게 격리하는 데 도움이 됩니다. Application Insights가 제공하는 애플리케이션 상태에 대한 향상된 가시성은 애플리케이션 문제를 해결하기 위해 "MTTR(평균 수리 시간)"을 줄이는 데 도움이 됩니다.
Amazon CloudWatch Application Insights에 애플리케이션을 추가하면 애플리케이션의 리소스를 스캔하고 CloudWatch에서 애플리케이션 구성 요소에 대한 지표와 로그를 추천 및 구성합니다. 애플리케이션 구성 요소의 예로는 SQL Server 백엔드 데이터베이스와 Microsoft IIS/웹 계층이 있습니다. Application Insights는 기록 데이터를 사용하여 메트릭 패턴을 분석하여 이상을 감지하고 애플리케이션, 운영 체제 및 인프라 로그에서 오류 및 예외를 지속적으로 감지합니다. 분류 알고리즘과 기본 제공 규칙의 조합을 사용하여 이러한 관찰을 연관시킵니다. 그런 다음 관련 관찰 및 문제 심각도 정보를 표시하는 대시보드를 자동으로 생성하여 조치의 우선 순위를 지정하는 데 도움이 됩니다.
Elastic Load Balancing은 로드 밸런서로 전송된 요청에 대한 자세한 정보를 캡처하는 액세스 로그를 제공합니다. 각 로그에는 요청이 수신된 시간, 클라이언트의 IP 주소, 대기 시간, 요청 경로 및 서버 응답과 같은 정보가 포함됩니다. 이러한 액세스 로그를 사용하여 트래픽 패턴을 분석하고 문제를 해결할 수 있습니다.
액세스 로깅은 기본적으로 비활성화되어 있는 Elastic Load Balancing의 선택적 기능입니다. 로드 밸런서에 대한 액세스 로깅을 활성화하면 Elastic Load Balancing이 로그를 캡처하여 압축 파일로 지정한 Amazon S3 버킷에 저장합니다. 언제든지 액세스 로깅을 비활성화할 수 있습니다.
회사에 AWS 클라우드로 마이그레이션하려는 온프레미스 인프라에서 호스팅되는 웹 애플리케이션이 있습니다. 관리자는 마이그레이션 프로세스가 진행되는 동안 다운타임이 없는지 확인하도록 지시했습니다. 이를 달성하기 위해 팀은 트래픽의 50%를 AWS의 새 애플리케이션으로, 나머지 50%를 온프레미스 인프라에서 호스팅되는 애플리케이션으로 전환하기로 결정했습니다. 마이그레이션이 끝나고 애플리케이션이 문제 없이 작동하면 AWS로의 전체 전환이 구현됩니다. 회사의 VPC는 AWS Direct Connect 연결을 통해 온프레미스 네트워크에 연결됩니다.
다음 중 위의 요구 사항을 충족하기 위해 구현할 수 있는 가능한 솔루션은 무엇입니까? (2개 선택)
가중치 기반 라우팅 정책이 포함된 Route 53을 사용하여 온프레미스 애플리케이션과 AWS 호스팅 애플리케이션 간에 트래픽을 전환합니다. 트래픽의 50%를 AWS의 새 애플리케이션으로 전환하고 나머지 50%를 온프레미스 인프라에서 호스팅되는 애플리케이션으로 전환합니다.
가중치 대상 그룹이 있는 Application Elastic Load Balancer를 사용하여 온프레미스 애플리케이션과 AWS 호스팅 애플리케이션 간에 트래픽을 전환하고 비율을 조정합니다. 트래픽의 50%를 AWS의 새 애플리케이션으로 전환하고 나머지 50%를 온프레미스 인프라에서 호스팅되는 애플리케이션으로 전환합니다.
Application Load Balancer는 가중치 대상 그룹 라우팅을 지원합니다. 이 기능을 사용하면 규칙에 의해 여러 대상 그룹에 전달되는 트래픽의 가중치 기반 라우팅을 수행할 수 있습니다. 이를 통해 여러 로드 밸런서 없이도 청록색, 카나리아 및 하이브리드 배포와 같은 다양한 사용 사례를 사용할 수 있습니다. 온프레미스와 클라우드 간 또는 EC2 및 Lambda와 같은 다양한 컴퓨팅 유형 간에 다운타임 없이 마이그레이션할 수도 있습니다.
트래픽의 50%를 AWS의 새 애플리케이션으로, 나머지 50%를 애플리케이션으로 전환하기 위해 Route 53을 가중치 기반 라우팅 정책과 함께 사용할 수도 있습니다. 그러면 그에 따라 온프레미스와 AWS 호스팅 애플리케이션 간에 트래픽이 전환됩니다.
가중치 라우팅을 사용하면 여러 리소스를 단일 도메인 이름(buildupworks.com) 또는 하위 도메인 이름(portal.buildupworks.com)과 연결하고 각 리소스로 라우팅되는 트래픽 양을 선택할 수 있습니다. 이는 로드 밸런싱 및 소프트웨어의 새 버전 테스트를 포함하여 다양한 목적에 유용할 수 있습니다. 가중치를 지정하여 리소스에 할당할 트래픽의 특정 비율을 설정할 수 있습니다.
Application Load Balancer에서 대상 그룹을 생성할 때 대상 유형을 지정합니다. 이는 이 대상 그룹에 등록할 때 지정하는 대상 유형을 결정합니다.
대상 유형이 ip인 경우 다음 CIDR 블록 중 하나에서 IP 주소를 지정할 수 있습니다.
- 대상 그룹에 대한 VPC의 서브넷
- 10.0.0.0/8(RFC 1918)
- 100.64.0.0/10(RFC 6598)
- 172.16.0.0/12(RFC 1918)
- 192.168.0.0/16(RFC 1918)
지원되는 이러한 CIDR 블록을 통해 대상 그룹에 ClassicLink 인스턴스, 로드 밸런서 VPC와 연결된 VPC의 인스턴스, IP 주소와 포트를 통해 주소 지정 가능한 AWS 리소스(예: 데이터베이스), AWS Direct Connect 또는 VPN Connection을 통해 AWS에 연결된 온프레미스 리소스 등을 등록할 수 있습니다.
공개적으로 라우팅 가능한 IP 주소는 지정할 수 없습니다. 인스턴스 ID를 사용하여 대상을 지정하는 경우 트래픽은 해당 인스턴스의 기본 네트워크 인터페이스에 지정된 기본 프라이빗 IP 주소를 사용하여 인스턴스로 라우팅됩니다. IP 주소를 사용하여 대상을 지정하는 경우 하나 이상의 네트워크 인터페이스에서 프라이빗 IP 주소를 사용하여 트래픽을 인스턴스로 라우팅할 수 있습니다. 이렇게 하면 인스턴스의 여러 애플리케이션이 동일한 포트를 사용할 수 있습니다. 각 네트워크 인터페이스에는 자체 보안 그룹이 있을 수 있습니다.
회사는 더 많은 스토리지 하드웨어를 구입하는 것과 Amazon S3의 사용을 비교하여 총 소유 비용(TCO) 분석을 수행했습니다. 그 결과 모든 직원에게 개인 문서 저장을 위해 Amazon S3를 사용할 수 있는 액세스 권한이 부여되었습니다.
다음 중 기업 AD 또는 LDAP 디렉터리의 싱글 사인온 기능을 통합하고 각 개별 사용자의 액세스를 S3 버킷의 지정된 사용자 폴더로 제한하는 솔루션을 설정하려면 다음 중 무엇을 고려해야 합니까? (2개 선택)
자격증명 페더레이션 설정하고 AWS Security Token Service를 사용하여 임시 토큰을 생성합니다.
버킷에 액세스하도록 IAM 자격 증명 공급자를 사용합니다.
질문은 AWS의 임시 자격 증명에 대한 일반적인 시나리오 중 하나를 나타냅니다. 임시 자격 증명은 자격 증명 연동, 위임, 교차 계정 액세스 및 IAM 역할과 관련된 시나리오에서 유용합니다. 이 예에서는 SSO(Single Sign-On) 기능도 설정해야 한다는 점을 고려하여 SAML 2.0 기반 페더레이션을 사용해야 합니다.
AWS 외부에서 사용자 자격 증명을 이미 관리하고 있다면, AWS 계정에서 IAM 사용자를 생성하는 대신 IAM 자격 증명 공급자를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 기업 사용자 디렉터리처럼 조직 내에 이미 고유의 자격 증명 시스템이 있다면 이 방법이 유용합니다. 그 밖에 AWS 리소스에 액세스해야 하는 모바일 앱이나 웹 애플리케이션을 개발할 때도 효과적입니다.
IAM 자격 증명 공급자를 사용하면 사용자 지정 로그인 코드를 생성할 필요도, 고유한 사용자 자격 증명을 관리할 필요도 없습니다. IdP에서 이러한 작업을 대신 수행합니다. 외부 사용자는 Login with Amazon, Facebook 또는 Google과 같은 널리 알려진 IdP를 통해 로그인합니다. 이러한 외부 자격 증명에 계정의 AWS 리소스를 사용할 권한을 제공할 수 있습니다. IAM 자격 증명 공급자를 사용하면 애플리케이션에서 사용자 액세스 키 같은 장기 보안 자격 증명을 배포하거나 포함할 필요가 없으므로 AWS 계정을 안전하게 보호할 수 있습니다.
AWS는 많은 자격 증명 공급자(IdP)가 사용하는 개방형 표준인 SAML 2.0(Security Assertion Markup Language 2.0)이라는 ID 페더레이션을 지원합니다. 이 기능은 페더레이션 통합 인증(SSO)을 활성화하므로 조직의 모든 구성원에 대해 IAM 사용자를 생성하지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있습니다. SAML을 사용함으로써 AWS로 연동을 구성하는 과정을 단순화할 수 있는데, 이는 사용자 지정 자격 증명 프록시 코드를 작성하는 대신 IdP의 서비스를 사용할 수 있기 때문입니다.
IAM 페더레이션은 다음과 같은 사용 사례를 지원합니다.
1. 조직의 사용자 또는 애플리케이션이 AWS API 작업을 호출할 수 있도록 허용하는 페더레이션 액세스. 조직에서 생성되는 SAML 어설션(인증 응답의 일부)을 사용해 임시 보안 자격 증명을 얻습니다. 이 시나리오는 임시 보안 자격 증명 요청 및 웹 ID 페더레이션 정보에 기술된 것과 같이 IAM이 지원하는 다른 페더레이션 시나리오와 유사합니다. 그러나 조직의 SAML 2.0 기반 IdP가 인증 수행 및 권한 부여 확인을 위한 세부 사항을 런타임에 대부분 처리합니다.
2. 조직에서 AWS Management Console로 이루어지는 웹 기반 SSO(Single Sign-On). 사용자가 SAML 2.0 호환 IdP에서 호스트하는 조직의 포털에 로그인하고 AWS로 이동하는 옵션을 선택하면 추가 로그인 정보를 제공하지 않고도 콘솔에 리디렉션될 수 있습니다. 타사 SAML IdP를 사용하여 콘솔에 SSO 액세스하거나 사용자 지정 IdP를 만들어 외부 사용자의 콘솔 액세스를 허용할 수 있습니다.
엔터프라이즈 자격 증명 연동에서는 조직 네트워크의 사용자를 인증한 다음 새 AWS 자격 증명을 생성하고 별도의 사용자 이름과 암호로 로그인하도록 요구하지 않고 해당 사용자에게 AWS에 대한 액세스를 제공할 수 있습니다. 이를 임시 액세스에 대한 SSO(Single Sign-On) 접근 방식이라고 합니다. AWS STS는 Microsoft AD FS를 사용하여 Microsoft Active Directory를 활용할 수 있는 SAML(Security Assertion Markup Language) 2.0과 같은 개방형 표준을 지원합니다. SAML 2.0을 사용하여 사용자 ID 연합을 위한 자체 솔루션을 관리할 수도 있습니다.
AWS Security Token Service(AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. 임시 보안 자격 증명은 다음과 같은 차이점을 제외하고는 IAM 사용자가 사용할 수 있는 장기 액세스 키 자격 증명과 거의 동일한 효력을 지닙니다.
고객의 수요를 충족하기 위해 일부 Auto Scaling 기능이 있고 스팟 인스턴스와 온디맨드 인스턴스를 혼합하여 효율적으로 활용하는 Application Load Balancer 뒤에 애플리케이션을 배포하려고 합니다.
인스턴스 관리를 위해 무엇을 권장합니까?
시작 템플릿으로 ASG 생성
시작 구성은 Auto Scaling 그룹이 EC2 인스턴스를 시작하는 데 사용하는 인스턴스 구성 템플릿입니다. 시작 구성을 생성할 때 Amazon 머신 이미지(AMI)의 ID, 인스턴스 유형, 키 페어, 하나 이상의 보안 그룹 및 블록 디바이스 매핑과 같은 인스턴스에 대한 정보를 지정합니다.
시작 템플릿은 인스턴스 구성 정보를 지정한다는 점에서 시작 구성과 유사합니다. Amazon 머신 이미지(AMI)의 ID, 인스턴스 유형, 키 페어, 보안 그룹 및 EC2 인스턴스를 시작하는 데 사용하는 기타 파라미터가 포함됩니다. 그러나 시작 구성 대신 시작 템플릿을 정의하면 여러 버전의 템플릿을 가질 수 있습니다.
시작 템플릿은 온디맨드 및 스팟 인스턴스의 혼합을 지원하며 ASG 덕분에 자동 크기 조정 기능이 제공됩니다.
온라인 이벤트 등록 시스템은 AWS에서 호스팅되며 ECS를 사용하여 프런트 엔드 계층과 데이터베이스 계층에 대해 다중 AZ로 구성된 RDS를 호스팅합니다.
Amazon RDS가 자동으로 대기 복제본에 대한 장애 조치를 수행하도록 하는 이벤트는 무엇입니까? (2개 선택)
기본 스토리지 오류
기본 가용 영역의 가용성 손실
Amazon RDS는 다중 AZ 배포를 사용하여 DB 인스턴스에 대한 고가용성 및 장애 조치 지원을 제공합니다. Amazon RDS는 여러 가지 기술을 사용하여 장애 조치 지원을 제공합니다. Oracle, PostgreSQL, MySQL 및 MariaDB DB 인스턴스용 다중 AZ 배포는 Amazon의 장애 조치 기술을 사용합니다. SQL Server DB 인스턴스는 SQL Server 데이터베이스 미러링(DBM)을 사용합니다.
다중 AZ 배포에서 Amazon RDS는 다른 가용 영역에 동기식 대기 복제본을 자동으로 프로비저닝하고 유지 관리합니다. 기본 DB 인스턴스는 가용 영역에서 대기 복제본으로 동기식으로 복제되어 데이터 중복성을 제공하고 I/O 정지를 제거하며 시스템 백업 중 지연 시간 급증을 최소화합니다. 고가용성으로 DB 인스턴스를 실행하면 계획된 시스템 유지 관리 중에 가용성이 향상되고 DB 인스턴스 장애 및 가용 영역 중단으로부터 데이터베이스를 보호할 수 있습니다.
Amazon RDS는 다중 AZ 배포에 대한 가장 일반적인 실패 시나리오를 감지하고 자동으로 복구하므로 관리자 개입 없이 가능한 한 빨리 데이터베이스 작업을 재개할 수 있습니다.
고가용성 기능은 읽기 전용 시나리오를 위한 확장 솔루션이 아닙니다. 읽기 트래픽을 처리하기 위해 대기 복제본을 사용할 수 없습니다. 읽기 전용 트래픽을 처리하려면 읽기 전용 복제본을 사용해야 합니다.
계획되거나 계획되지 않은 DB 인스턴스의 운영 중단으로 인해 인프라 장애가 발생한 경우, 다중 AZ를 설정하면 Amazon RDS는 자동으로 다른 가용 영역의 대기 복제본으로 전환됩니다. 장애 조치가 완료되는 데 소요되는 시간은 프라이머리 DB 인스턴스를 사용할 수 없게 된 시점의 데이터베이스 활동 및 기타 조건에 따라 달라집니다. 장애 조치에 소요되는 시간은 일반적으로 60–120초입니다. 그러나 트랜잭션의 규모가 크거나 복구 프로세스가 복잡한 경우 장애 조치에 소요되는 시간이 증가할 수 있습니다. 장애 조치가 완료되면 RDS 콘솔에 새 가용 영역이 반영되는 데 시간이 더 걸릴 수 있습니다.
Amazon RDS는 자동으로 장애 조치를 취하여 관리자의 개입 없이 데이터베이스 작업을 신속하게 재개할 수 있도록 합니다. 다음 표에 설명된 조건 중 하나가 발생하면 기본 DB 인스턴스는 자동으로 예비 복제본으로 전환됩니다. 이 장애 조치 이유는 이벤트 로그에서 확인할 수 있습니다.
이유 : RDS 데이터베이스 인스턴스 기반의 운영 체제가 오프라인 작업에서 패치되고 있습니다.
설명 : OS 패치 또는 보안 업데이트를 위한 유지 관리 기간 동안 장애 조치가 트리거되었습니다.
이유 : RDS 다중 AZ 인스턴스의 기본 호스트가 비정상입니다.
설명 : 다중 AZ DB 인스턴스 배포에서 손상된 프라이머리 DB 인스턴스를 감지하여 장애 조치를 수행했습니다.
이유 : 네트워크 연결 손실로 인해 RDS 다중 AZ 인스턴스의 기본 호스트에 연결할 수 없습니다.
설명 : RDS 모니터링이 기본 DB 인스턴스에 대한 네트워크 연결 실패를 감지하여 장애 조치를 트리거했습니다.
이유 : RDS 인스턴스를 고객이 수정했습니다.
설명 : RDS DB 인스턴스 수정 때문에 장애 조치가 트리거되었습니다.
이유 : RDS 다중 AZ 기본 인스턴스가 사용 중이며 응답하지 않습니다.
설명 : 기본 DB 인스턴스가 응답하지 않습니다.
이유 : RDS 다중 AZ 인스턴스의 기본 호스트 기반의 스토리지 볼륨에 오류가 발생했습니다.
설명 : 다중 AZ DB 인스턴스 배포가 프라이머리 DB 인스턴스에서 스토리지 문제를 감지하여 장애 조치를 수행했습니다.
이유 : 사용자가 DB 인스턴스의 장애 조치를 요청했습니다.
설명 : 사용자가 DB 인스턴스를 재부팅하고 장애 조치를 사용하여 재부팅을 선택했습니다.
회사가 IT 인프라를 AWS 클라우드로 이전할 가능성을 평가하고 있습니다. 회사는 대부분 대용량 비디오인 특정 파일을 처리하기 위해 가능한 최대 I/O 성능을 갖춘 최소 10TB의 스토리지가 필요합니다. 이 회사는 또한 미디어 콘텐츠를 저장하기 위해 거의 450TB에 달하는 내구성이 뛰어난 스토리지가 필요하고 거의 두 배인 레거시 데이터 보관을 위해 900TB가 필요합니다.
이러한 요구 사항을 충족하기 위해 어떤 서비스 세트를 추천하시겠습니까?
최대 성능을 위한 Amazon EC2 인스턴스 스토어, 내구성 있는 데이터 스토리지를 위한 Amazon S3, 아카이브 스토리지를 위한 Amazon S3 Glacier
인스턴스 스토어는 인스턴스에 대한 임시 블록 수준 스토리지를 제공합니다. 이 저장소는 호스트 컴퓨터에 물리적으로 연결된 디스크에 있습니다. 인스턴스 스토어는 버퍼, 캐시, 스크래치 데이터 및 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 스토리지 또는 로드 밸런싱된 웹 서버 풀과 같이 인스턴스 집합 전체에 복제되는 데이터에 이상적입니다.
인스턴스를 시작할 때만 인스턴스에 대한 인스턴스 스토어 볼륨을 지정할 수 있습니다. 한 인스턴스에서 인스턴스 스토어 볼륨을 분리하여 다른 인스턴스에 연결할 수 없습니다.
일부 인스턴스 유형은 NVMe 또는 SATA 기반 SSD(반도체 드라이브)를 사용하여 높은 임의 I/O 성능을 제공합니다. 이는 대기 시간이 매우 짧은 스토리지가 필요할 때 좋은 옵션이지만 인스턴스가 종료될 때 데이터를 유지할 필요가 없거나 내결함성 아키텍처를 활용할 수 있습니다.
S3 Standard는 자주 액세스하는 데이터에 대해 높은 내구성, 가용성 및 성능 객체 스토리지를 제공합니다. 짧은 대기 시간과 높은 처리량을 제공하기 때문에 S3 Standard는 클라우드 애플리케이션, 동적 웹 사이트, 콘텐츠 배포, 모바일 및 게임 애플리케이션, 빅 데이터 분석을 비롯한 다양한 사례에 적합합니다.
S3 Glacier는 데이터 보관을 위한 안전하고 내구성이 있으며 저렴한 스토리지 클래스입니다. 온프레미스 솔루션과 경쟁하거나 더 저렴한 비용으로 모든 양의 데이터를 안정적으로 저장할 수 있습니다. 비용을 낮게 유지하면서도 다양한 요구 사항에 적합하도록 S3 Glacier는 몇 분에서 몇 시간에 이르는 세 가지 검색 옵션을 제공합니다. 객체를 S3 Glacier에 직접 업로드하거나 S3 수명 주기 정책을 사용하여 활성 데이터(S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA 및 S3 One Zone-IA)와 S3에 대한 S3 스토리지 클래스 간에 데이터를 전송할 수 있습니다.
IT 회사는 직원의 AWS 계정 및 비즈니스 애플리케이션에 통합하려고 합니다.
다음 AWS 서비스 중 이 요구 사항에 대한 솔루션을 구축하는 데 도움이 되는 것은 무엇입니까? (2개 선택)
AWS Identity and Access Management (IAM)
AWS Single Sign-On (SSO)
Identity federation은 사용자를 인증하고 리소스에 대한 액세스 권한을 부여하는 데 필요한 정보를 전달하기 위한 목적으로 두 당사자 간의 신뢰 시스템입니다. 이 시스템에서 IdP(Identity Provider)는 사용자 인증을 담당하고 서비스 또는 애플리케이션과 같은 SP(Service Provider)는 리소스에 대한 액세스를 제어합니다. 관리 계약 및 구성에 따라 SP는 IdP를 신뢰하여 사용자를 인증하고 IdP가 제공한 사용자 정보에 의존합니다. 사용자를 인증한 후 IdP는 사용자의 로그인 이름과 SP가 사용자와의 세션을 설정하고 SP가 수행해야 하는 리소스 액세스 범위를 결정하는 데 필요한 기타 속성이 포함된 어설션이라고 하는 메시지를 SP에 보냅니다. 승인하다. 페더레이션은 중앙 IdP 내에서 중앙에서 사용자를 관리하고 SP 역할을 하는 여러 애플리케이션 및 서비스에 대한 액세스를 제어하는 액세스 제어 시스템을 구축하기 위한 일반적인 접근 방식입니다.
AWS Single Sign-On(SSO) 또는 AWS Identity and Access Management(IAM)의 두 가지 AWS 서비스를 사용하여 인력을 AWS 계정 및 비즈니스 애플리케이션에 통합할 수 있습니다. AWS SSO는 중앙 집중식 단일 디렉터리의 그룹 멤버십을 기반으로 사용자에 대한 연동 액세스 권한을 정의하는 데 도움이 되는 탁월한 선택입니다. 여러 디렉터리를 사용하거나 사용자 속성을 기반으로 권한을 관리하려는 경우 설계 대안으로 AWS IAM을 고려합니다.
AWS Organization은 조직의 모든 계정에 대해 사용 가능한 최대 권한을 중앙에서 제어하기 위해 서비스 제어 정책(SCP)을 사용하고 있습니다. 이를 통해 조직은 모든 계정이 조직의 액세스 제어 지침을 준수하도록 할 수 있습니다.
설명된 권한과 관련하여 옳은 것은 무엇입니까? (2개 선택)
SCP는 서비스 연결 역할에 영향을 미치지 않습니다.
SCP는 루트 사용자를 포함하여 연결된 계정의 모든 사용자 및 역할에 영향을 줍니다.
SCP(서비스 제어 정책)는 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형입니다. SCP는 조직의 모든 계정에 사용 가능한 최대 권한을 중앙에서 제어합니다. SCP를 사용하면 조직의 액세스 제어 지침에 따라 계정을 유지할 수 있습니다. SCP는 활성화된 모든 기능을 가진 조직에서만 사용할 수 있습니다. 조직이 통합 결제 기능만 지원한다면 SCP를 이용할 수 없습니다.
SCP만으로는 조직 내 계정에 권한을 부여하기에 충분하지 않습니다. SCP는 어떠한 권한도 부여하지 않습니다. SCP는 계정 관리자가 영향을 받는 계정의 IAM 사용자 및 역할에 위임할 수 있는 작업에 대해 권한 범위를 정의하거나 제한을 설정합니다. 관리자는 실제로 권한을 부여하기 위해 여전히 자격 증명 기반 또는 리소스 기반 정책을 IAM 사용자 또는 역할에 연결하거나 계정의 리소스에 연결해야 합니다. 유효 권한은 SCP가 허용하는 권한과 IAM 및 리소스 기반 정책이 허용하는 권한 간의 논리적 교집합입니다.
SCP는 조직에 속한 계정이 관리하는 IAM 사용자 및 역할에만 영향을 줍니다. SCP는 리소스 기반 정책에 직접 영향을 주지 않습니다. 조직 외부 계정의 사용자 또는 역할에도 영향을 주지 않습니다. 예를 들어 조직의 A 계정이 소유하는 Amazon S3 버킷을 가정해 보겠습니다. 버킷 정책(리소스 기반 정책)은 조직 외부의 B 계정에 속한 사용자에게 액세스 권한을 부여합니다. A 계정에는 SCP가 연결되어 있습니다. 해당 SCP는 B 계정의 외부 사용자에게 적용되지 않습니다. 이 SCP는 조직의 A 계정이 관리하는 사용자에게만 적용됩니다.
SCP는 조직의 멤버 계정에만 영향을 미칩니다. 관리 계정의 사용자 또는 역할에는 영향을 미치지 않습니다.
사용자와 역할이 적절한 IAM 권한 정책으로 권한을 부여받아야 한다는 사실은 변하지 않습니다. IAM 권한 정책이 없는 사용자는 관련 SCP가 모든 서비스와 작업을 허용해도 액세스 권한이 없습니다.
사용자나 역할에 관련 SCP가 허용하지 않거나 명시적으로 거부한 작업의 액세스 권한을 부여하는 IAM 권한 정책이 있으면 사용자나 역할이 해당 작업을 수행할 수 없습니다.
SCP는 어떠한 서비스 연결 역할에도 영향을 미치지 않습니다. 서비스 연결 역할은 다른 AWS 서비스에서 AWS Organizations와 통합하도록 활성화하며 SCP로 제한할 수 없습니다.
대량의 쿼리 요청으로 인해 온라인 보고 애플리케이션의 데이터베이스 성능이 크게 저하되었습니다. Solutions Architect는 개발자에게 클라이언트가 다중 AZ 배포 구성을 설정하는 대신 애플리케이션에 Amazon RDS 읽기 전용 복제본을 사용하도록 설득하려고 합니다.
다중 AZ에 대한 읽기 전용 복제본 사용의 두 가지 이점은 무엇입니까? (2개 선택)
비동기 복제를 제공하고 읽기가 많은 데이터베이스 워크로드를 기본 데이터베이스에서 가져와서 기본 데이터베이스의 성능을 향상시킵니다.
읽기가 많은 데이터베이스 워크로드를 위해 단일 DB 인스턴스의 용량 제약을 넘어서 탄력적으로 확장됩니다.
Amazon RDS 읽기 전용 복제본은 Amazon RDS 데이터베이스(DB) 인스턴스의 성능과 내구성을 높여줍니다. 읽기 전용 복제본을 사용하면 손쉽게 단일 DB 인스턴스의 용량 한도 이상으로 탄력적으로 스케일 아웃하여 읽기 중심의 데이터베이스 워크로드를 처리할 수 있습니다. 특정 소스 DB 인스턴스의 복제본을 여러 개 만들어 여러 데이터 사본이 요청하는 높은 애플리케이션 읽기 트래픽도 처리할 수 있습니다. 덕분에 전체 읽기 처리량이 향상됩니다. 필요한 경우 읽기 전용 복제본은 독립 실행형 DB 인스턴스로 승격될 수 있습니다. 읽기 전용 복제본은 Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server뿐만 아니라 Amazon Aurora에서도 사용할 수 있습니다.
MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server 데이터베이스 엔진의 경우, Amazon RDS에서 소스 DB 인스턴스의 스냅샷을 사용해 두 번째 DB 인스턴스를 생성합니다. 그런 다음 엔진의 기본 비동기식 복제 기능을 사용해 소스 DB 인스턴스가 변경될 때마다 읽기 전용 복제본을 업데이트합니다. 읽기 전용 복제본은 읽기 전용 연결만 가능한 DB 인스턴스 역할을 수행합니다. 애플리케이션을 읽기 전용 복제본에 연결하는 방법은 DB 인스턴스에 연결하는 방법과 동일합니다. Amazon RDS는 원본 DB 인스턴스의 모든 데이터베이스를 복제합니다.
애플리케이션에서 읽기 전용 복제본으로 읽기 쿼리를 라우팅하여 원본 DB 인스턴스의 로드를 줄일 수 있습니다. 읽기 전용 복제본을 사용하면 단일 DB 인스턴스 용량의 한도 이상으로 탄력적으로 스케일 아웃할 수 있어 읽기 중심의 데이터베이스 워크로드를 쉽게 처리할 수 있습니다. 읽기 전용 복제본이 기본 상태로 승격될 수 있으므로 샤딩 구현의 일부로 사용하기에 유용합니다.
읽기 성능을 더욱 극대화하려면 Amazon RDS for MySQL을 사용하여 기본 복제본에 표시하지 않고 테이블 인덱스를 읽기 전용 복제본에 직접 추가할 수 있습니다.
Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server의 읽기 전용 복제본은 이러한 엔진의 기본 비동기식 복제를 사용하여 구현됩니다. Amazon Aurora는 다른 복제 메커니즘을 사용하지만, 여전히 비동기식입니다.
데이터 분석 회사는 소비자가 무엇을 보고 어떤 광고에 노출되는지 측정합니다. 이 실시간 데이터는 온프레미스 데이터 센터로 수집된 후 일일 데이터 피드가 단일 파일로 압축되고 백업을 위해 Amazon S3에 업로드됩니다. 일반적인 압축 파일 크기는 약 2GB입니다.
다음 중 일일 압축 파일을 S3에 업로드하는 가장 빠른 방법은 무엇입니까?
S3 transfer acceleration과 함께 멀티파트 업로드를 사용하여 압축 파일 업로드
Amazon S3 Transfer Acceleration은 클라이언트와 S3 버킷 간의 장거리 파일 전송을 파일을 빠르고 쉽고 안전하게 전송할 수 있는 버킷 수준 기능입니다. Transfer Acceleration은 전 세계에서 S3 버킷으로 전송 속도를 최적화하도록 설계되었습니다. Transfer Acceleration은 Amazon CloudFront에서 전 세계에 분산된 엣지 로케이션을 활용합니다. 엣지 로케이션에 도착한 데이터는 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅됩니다.
멀티파트 업로드를 사용하면 단일 객체를 여러 부분의 집합으로 업로드할 수 있습니다. 각 부분은 객체 데이터의 연속적인 부분입니다. 이러한 객체 부분은 독립적으로 그리고 임의의 순서로 업로드할 수 있습니다. 부분의 전송이 실패할 경우 다른 부분에 영향을 주지 않고도 해당 부분을 재전송할 수 있습니다. 객체의 모든 부분이 업로드되면 Amazon S3가 이들 부분을 수집하여 객체를 생성합니다. 일반적으로 객체 크기가 100MB에 근접할 경우, 단일 작업에서 객체를 업로드하는 대신 멀티파트 업로드 사용을 고려해 봐야 합니다.
멀티파트 업로드 사용은 다음 이점을 제공합니다.
- 개선된 처리량 개선 - 부분을 병렬적으로 업로드하여 처리량을 개선할 수 있습니다.
- 네트워크 문제로부터 빠른 복구 - 더 작아진 부분 크기는 네트워크 오류로 인해 실패한 업로드 재시작의 영향을 최소화합니다.
- 객체 업로드 일시 중지 및 재개 – 객체 부분을 장시간에 걸쳐 업로드할 수 있습니다. 일단 멀티파트 업로드가 시작되면 제한 시간이 없습니다. 멀티파트 업로드를 명시적으로 완료하거나 중단해야 합니다.
- 최종 객체 크기를 알기 전에 업로드를 시작 – 객체를 생성하는 동안 업로드할 수 있습니다.
다음 방법으로 멀티파트 업로드를 사용하는 것이 좋습니다.
- 안정적인 높은 대역폭 네트워크를 통해 큰 객체를 업로드하는 경우, 멀티파트 업로드를 사용하여 멀티 스레드 성능을 위해 여러 객체 부분을 동시에 업로드함으로써 대역폭 사용을 극대화합니다.
- 불규칙한 네트워크를 통해 업로드하는 경우, 멀티파트 업로드를 사용하여 업로드가 다시 시작되는 것을 방지하여 네트워크 오류에 대한 복원력을 높입니다. 멀티파트 업로드를 사용하는 경우, 업로드 중에 중단된 부분만 다시 업로드해야 합니다. 객체 업로드를 처음부터 다시 시작하지 않아도 됩니다.
회사에 실시간 데이터 대시보드를 업데이트하는 데이터 분석 애플리케이션과 Amazon Redshift에 데이터를 보관하는 별도의 애플리케이션이 있습니다. 두 애플리케이션 모두 Amazon Kinesis Data Streams를 사용하여 동일한 스트림의 데이터를 동시에 독립적으로 사용하도록 구성됩니다. 그러나 샤드 반복자가 예기치 않게 만료되는 경우가 많다는 것을 알아차렸습니다. 확인 결과 Kinesis가 사용하는 DynamoDB 테이블에 임대 데이터를 저장할 용량이 충분하지 않다는 것을 알게 되었습니다.
다음 중 이 문제를 해결하는 데 가장 적합한 솔루션은 무엇입니까?
샤드 테이블에 할당된 쓰기 용량을 늘립니다.
Amazon Kinesis Data Streams를 사용하면 특수 요구에 맞춰 스트리밍 데이터를 처리 또는 분석하는 사용자 지정 애플리케이션을 구축할 수 있습니다. 수십 만개의 소스에서 클릭 스트림, 애플리케이션 로그, 소셜 미디어와 같은 다양한 유형의 데이터를 Kinesis 데이터 스트림에 추가할 수 있습니다. 그러면 몇 초 안에 애플리케이션에서 스트림의 해당 데이터를 읽고 처리할 수 있습니다.
Kinesis Data Streams 스트림으로 할 수 있는 작업은 무엇입니까?
신속하고 지속적인 데이터 인테이크 및 집계를 위해 Kinesis Data Streams를 사용할 수 있습니다. 사용되는 데이터 유형으로는 IT 인프라 로그 데이터, 애플리케이션 로그, 소셜 미디어, 시장 데이터 피드, 웹 클릭스트림 데이터 등이 있습니다. 데이터 인테이크 및 처리에 대한 응답이 실시간으로 이루어지기 때문에 간단하게 처리되는 것이 일반적입니다.
다음은 Kinesis Data Streams Streams를 사용하는 일반적인 시나리오입니다.
가속화된 로그 및 데이터 피드 인테이크 및 처리 : 생산자를 통해 스트림으로 직접 데이터를 푸시할 수 있습니다. 예를 들어, 시스템 및 애플리케이션 로그를 푸시하고 몇 초 만에 처리할 수 있습니다. 그러면 프런트 엔드 또는 애플리케이션 서버가 실패해도 로그 데이터가 손실되지 않습니다. 인테이크를 위해 데이터를 제출하기 전에 서버에서 데이터를 배치 처리하지 않기 때문에 Kinesis Data Streams 속도가 빨라집니다.
실시간 측정치 및 보고 : 간단한 데이터 분석 및 실시간 보고를 위해 Kinesis Data Streams Streams에 수집된 데이터를 사용할 수 있습니다. 예를 들어, 데이터가 스트레밍되는 동안 데이터 처리 애플리케이션이 데이터 배치를 수신할 때까지 기다리는 대신 측정치를 내고 시스템 및 애플리케이션 로그를 보고할 수 있습니다.
실시간 데이터 분석 : 실시간 데이터의 가치와 병렬 처리 능력이 함께 발휘됩니다. 예를 들어 웹 사이트 클릭 스트림을 실시간으로 처리한 다음 병렬로 실행되는 여러 Kinesis Data Streams 애플리케이션을 사용하여 사이트 가용성 참여를 분석합니다.
복잡한 스트림 처리 : Kinesis Data Streams 애플리케이션 및 데이터 스트림의 DAG (방향성 비순환 그래프) 를 생성할 수 있습니다. 이렇게 하려면 일반적으로 여러 Kinesis Data Streams 애플리케이션의 데이터를 또 다른 스트림에 넣어 다른 Kinesis Data Streams 애플리케이션에서 다운스트림을 처리합니다.
샤드 반복자가 예기치 않게 만료되는 경우
모든 GetRecords 요청에서 새로운 반복자가 NextShardIterator로 반환되며, 다음 GetRecords 요청에서 이 샤드 반복자를 ShardIterator로 사용합니다. 대개 이 샤드 반복자는 사용하기 전에 만료되지 않지만 하지만 5분 이상 GetRecords를 호출하지 않거나 소비자 애플리케이션의 다시 시작을 수행하면 샤드 반복자가 만료될 수 있습니다.
샤드 이터레이터가 사용 전에 즉시 만료되는 경우, 이는 Kinesis에서 사용하는 DynamoDB 테이블에 임대 데이터를 저장할 용량이 충분하지 않다는 것을 의미할 수 있습니다. 샤드 수가 많으면 이런 문제가 생기기 쉽습니다. 이 문제를 해결하려면 샤드 테이블에 할당된 쓰기 용량을 늘리십시오.
회사는 개발자에게 AWS 콘솔 액세스 권한을 부여할 계획입니다. 회사 정책은 ID 연합 및 역할 기반 액세스 제어의 사용을 의무화입니다. 현재 역할은 이미 회사 Active Directory의 그룹을 사용하여 할당되어 있습니다.
이 시나리오에서 다음 서비스의 어떤 조합이 개발자에게 AWS 콘솔에 대한 액세스를 제공할 수 있습니까? (2개 선택)
IAM Roles
AWS Directory Service AD Connector
회사에서 회사 Active Directory를 사용하고 있다는 점을 고려할 때, 보다 쉬운 통합을 위해서는 AWS Directory Service AD Connector를 사용하는 것이 가장 좋습니다. 또한 회사 Active Directory의 그룹을 사용하여 역할이 이미 할당되어 있으므로 IAM 역할도 함께 사용하는 것이 좋습니다. AWS Directory Service AD Connector를 통해 VPC와 통합되면 Active Directory에서 사용자 또는 그룹에 IAM 역할을 할당할 수 있습니다.
AWS Directory Service는 다른 AWS 서비스에서 Microsoft Active Directory(AD)를 사용할 수 있는 몇 가지 방법을 제공합니다. 디렉터리는 사용자, 그룹 및 디바이스에 대한 정보를 저장하고, 관리자는 이를 사용하여 정보 및 리소스에 대한 액세스를 관리합니다.AWS Directory Service는 클라우드에서 기존 Microsoft AD 또는 LDAP (Lightweight Directory Access Protocol) 인식 애플리케이션을 사용하려는 고객에게 다양한 디렉터리 선택 옵션을 제공합니다. 또한 사용자, 그룹, 디바이스 및 액세스 권한을 관리하기 위해 디렉터리가 필요한 개발자에게도 동일한 선택 옵션을 제공합니다.
