Amazon S3 버킷에 업로드된 모든 객체는 보안 규정 준수를 위해 암호화되어야 합니다. 버킷은 Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용하여 256비트 고급 암호화 표준(AES-256) 블록 암호를 사용하여 데이터를 암호화합니다.
다음 요청 헤더 중 어떤 것을 사용해야 합니까?
x-amz-server-side-encryption
서버 측 암호화는 데이터를 받는 애플리케이션 또는 서비스에 의해 해당 대상에서 데이터를 암호화하는 것입니다. Amazon S3에서 데이터 센터의 디스크에 데이터를 쓰면서 객체 수준에서 데이터를 암호화하고 사용자가 해당 데이터에 액세스할 때 자동으로 암호를 해독합니다. 요청을 인증하기만 하면 액세스 권한을 갖게 되며, 객체의 암호화 여부와 관계없이 액세스 방식에는 차이가 없습니다. 예를 들어, 미리 서명된 URL을 사용하여 객체를 공유하는 경우, 해당 URL은 암호화된 객체와 암호화되지 않은 객체에 동일하게 작동합니다. 또한 버킷에 객체를 나열하는 경우 목록 API에서는 암호화 여부와 관계없이 전체 객체의 목록을 반환합니다.
암호화 키 관리 방법으로 무엇을 선택하느냐에 따라 다음과 같은 세 가지 옵션을 독립적으로 사용할 수 있습니다.
Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)
Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하면 각 객체는 고유한 키로 암호화됩니다. 또한 추가 보안 조치로 주기적으로 교체되는 루트 키를 사용하여 키 자체를 암호화합니다. Amazon S3 서버 측 암호화는 가장 강력한 블록 암호 중 하나인 256비트 Advanced Encryption Standard(AES-256) GCM을 사용하여 데이터를 암호화합니다. AES-GCM 이전에 암호화된 객체의 경우 AES-CBC는 여전히 해당 객체의 암호를 해독하도록 지원됩니다.
AWS Key Management Service에 저장된 KMS 키를 사용한 서버 측 암호화(SSE-KMS)
AWS KMS keys를 사용한 서버 측 암호화(SSE-KMS)는 SSE-S3와 유사하지만 이 서비스 사용 시 몇 가지 추가적인 이점이 있고 비용이 발생합니다. Amazon S3의 객체에 대한 무단 액세스에 대응하여 추가적인 보호를 제공하는 -KMS 키를 사용하려면 별도의 권한이 필요합니다. SSE-KMS도 KMS 키가 사용된 때와 사용 주체를 표시하는 감사 추적 기능을 제공합니다. 또한 고객 관리형 키를 생성하고 관리하거나 사용자, 서비스 및 리전에 고유한 AWS 관리형 CMK를 사용할 수 있습니다.
고객 제공 키를 사용한 서버 측 암호화(SSE-C)
고객 제공 키를 사용한 서버 측 암호화(SSE-C)를 사용하면 사용자는 암호화 키를 관리하고 Amazon S3는 암호화(디스크에 쓸 때) 및 해독(객체에 액세스할 때)을 관리합니다.
버킷에 저장된 모든 객체에 대해 서버 측 암호화가 필요할 경우 버킷 정책을 사용합니다. 예를 들어 다음 버킷 정책은 요청에 서버 측 암호화를 요청하는 x-amz-server-side-encryption 헤더가 포함되지 않을 경우 객체 업로드 권한을 거부합니다.
- {
- "Version": "2012-10-17",
- "Id": "PutObjectPolicy",
- "Statement": [
- {
- "Sid": "DenyIncorrectEncryptionHeader",
- "Effect": "Deny",
- "Principal": "*",
- "Action": "s3:PutObject",
- "Resource": "arn:aws:s3:::awsexamplebucket1/*",
- "Condition": {
- "StringNotEquals": {
- "s3:x-amz-server-side-encryption": "AES256"
- }
- }
- },
- {
- "Sid": "DenyUnencryptedObjectUploads",
- "Effect": "Deny",
- "Principal": "*",
- "Action": "s3:PutObject",
- "Resource": "arn:aws:s3:::awsexamplebucket1/*",
- "Condition": {
- "Null": {
- "s3:x-amz-server-side-encryption": "true"
- }
- }
- }
- ]
- }
은행은 관리 복잡성과 오버헤드를 단순화하면서 고가용성과 비용 효율성을 보장하기 위해 여러 핵심 뱅킹 애플리케이션을 클라우드로 마이그레이션하는 데 SQS를 사용하고 있습니다. 은행의 개발팀은 SQS를 통해 처리되는 초당 약 1000개 메시지의 최고 속도를 예상합니다. 메시지를 순서대로 처리하는 것이 중요합니다.
다음 중 이 시스템을 구현하는 데 사용할 수 있는 옵션은 무엇입니까?
작업당 4개 메시지의 배치 모드에서 Amazon SQS FIFO 대기열을 사용하여 최대 속도로 메시지를 처리합니다.
Amazon Simple Queue Service(SQS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리하고 확장할 수 있는 완전관리형 메시지 대기열 서비스입니다. SQS는 표준 대기열과 FIFO 대기열의 두 가지 유형의 메시지 대기열을 제공합니다.
FIFO 대기열의 경우 메시지를 보내고 받는 순서가 엄격하게 유지됩니다(즉, 선입선출). 반면에 표준 SQS 대기열은 최선형 주문을 제공합니다. 이는 때때로 메시지가 전송된 순서와 다른 순서로 배달될 수 있음을 의미합니다.
기본적으로 FIFO 대기열은 초당 최대 300개의 메시지를 지원합니다(초당 300개의 보내기, 받기 또는 삭제 작업). 작업당 10개의 메시지(최대)를 일괄 처리하는 경우 FIFO 대기열은 초당 최대 3,000개의 메시지를 지원할 수 있습니다. 따라서 FIFO 대기열이 초당 최대 1200개 메시지를 지원할 수 있도록 작업당 4개의 메시지를 처리해야 합니다.
회사는 Application Load Balancer 뒤에 있는 EC2 인스턴스의 Auto Scaling 그룹에서 전자 상거래 웹 사이트를 호스팅했습니다. Solutions Architect는 웹 사이트가 지속적으로 변경되는 IP 주소를 사용하는 여러 시스템에서 많은 수의 불법적인 외부 요청을 수신하고 있음을 확인했습니다. 성능 문제를 해결하기 위해 Solutions Architect는 합법적인 트래픽에 대한 영향을 최소화하면서 불법적인 요청을 차단하는 솔루션을 구현해야 합니다.
다음 중 이 요구 사항을 충족하는 옵션은 무엇입니까?
AWS WAF에서 속도 기반 규칙을 생성하고 웹 ACL을 Application Load Balancer에 연결합니다.
AWS WAF는 고객이 정의한 조건에 따라 웹 요청을 허용, 차단 또는 모니터링(계수)하는 규칙을 구성하여 공격으로부터 웹 애플리케이션을 보호하는 웹 애플리케이션 방화벽입니다. 이러한 조건에는 IP 주소, HTTP 헤더, HTTP 본문, URI 문자열, SQL 명령어 주입 및 교차 사이트 스크립팅이 포함됩니다.
AWS WAF는 어떻게 트래픽을 허용 또는 차단합니까?
기본 서비스에서 웹 사이트에 대한 요청을 수신하면, 규칙과 비교하여 검사하도록 해당 요청을 AWS WAF로 전달합니다. 요청이 규칙에 정의된 조건에 부합하는 경우, AWS WAF에서 기본 서비스에 정의한 작업에 따라 해당 요청을 허용 또는 차단하도록 지시합니다.
AWS WAF는 내 웹 사이트 또는 애플리케이션을 어떻게 보호합니까?
AWS WAF는 AWS 고객이 웹 사이트와 애플리케이션을 위한 콘텐츠를 전달하기 위해 흔히 사용하는 서비스인 Amazon CloudFront, Application Load Balancer(ALB), Amazon API Gateway 및 AWS AppSync와 긴밀히 통합됩니다. Amazon CloudFront에서 AWS WAF를 사용할 때는 전 세계 곳곳에서 최종 사용자에게 가까운 곳에 위치한 모든 AWS 엣지 로케이션에서 규칙이 실행됩니다. 즉, 보안으로 인해 성능이 저하되지는 않습니다. 차단된 요청은 고객 웹 서버에 도달하기 전에 중지됩니다. Application Load Balancer, Amazon API Gateway 및 AWS AppSync와 같은 리전 서비스에서 AWS WAF를 사용하는 경우에는 규칙이 리전에서 실행되며 이를 사용하여 내부 리소스는 물론 인터넷 연결 리소스를 보호할 수 있습니다.
AWS WAF의 비율 기반 규칙은 각 발신 IP 주소에 대한 요청 비율을 추적하고 제한을 초과하는 비율의 IP에 대해 규칙 작업을 트리거합니다. 제한을 5분 시간 범위당 요청 수로 설정합니다. 이 유형의 규칙을 사용하여 과도한 요청을 전송하는 IP 주소의 요청에 임시 차단을 적용할 수 있습니다. 기본적으로, AWS WAF웹 요청 오리진의 IP 주소를 기반으로 요청을 집계하지만 다음과 같이 HTTP 헤더의 IP 주소를 사용하도록 규칙을 구성할 수 있습니다
주어진 시나리오의 요구 사항은 정식 요청에 영향을 주지 않고 불법적인 요청의 요청 수를 제한하는 것입니다. 이 요구 사항을 달성하기 위해 AWS WAF 웹 ACL을 사용할 수 있습니다. 고유한 웹 ACL 규칙을 만드는 데는 일반 규칙과 비율 기반 규칙이라는 두 가지 유형의 규칙이 있습니다. 웹 ACL에 속도 제한을 추가하려면 후자를 선택해야 합니다. 웹 ACL을 생성한 후 ALB와 연결할 수 있습니다. 규칙 작업이 트리거되면 AWS WAF는 요청 속도가 제한 아래로 떨어질 때까지 IP 주소의 추가 요청에 작업을 적용합니다.
전 세계 수천 명의 고객이 있는 온라인 거래 플랫폼이 AWS에서 호스팅됩니다. 대기 시간을 줄이려면 사용자 트래픽을 클라이언트에 가장 가까운 애플리케이션 엔드포인트로 보내야 합니다. 트래픽은 고정 IP 주소를 통해 가장 가까운 엣지 로케이션으로 라우팅되어야 합니다. DDoS 보호를 위해 AWS Shield도 통합되어야 합니다.
다음 중 위의 요구 사항을 충족하기 위해 Solutions Architect가 사용해야 하는 가장 적합한 서비스는 무엇입니까?
AWS Global Accelerator
AWS Global Accelerator는 로컬 또는 글로벌 사용자와 함께 애플리케이션의 가용성과 성능을 향상시키는 서비스입니다. Application Load Balancer, Network Load Balancer 또는 Amazon EC2 인스턴스와 같은 단일 또는 여러 AWS 리전에서 애플리케이션 엔드포인트에 대한 고정 진입점 역할을 하는 고정 IP 주소를 제공합니다.
AWS Global Accelerator는 AWS 글로벌 네트워크를 사용하여 사용자에서 애플리케이션까지의 경로를 최적화하여 TCP 및 UDP 트래픽의 성능을 개선합니다. AWS Global Accelerator는 애플리케이션 엔드포인트의 상태를 지속적으로 모니터링하고 비정상 엔드포인트를 감지하고 1분 이내에 정상적인 엔드포인트로 트래픽을 리디렉션합니다.
게임, 미디어, 모바일 애플리케이션 및 금융 애플리케이션과 같은 많은 애플리케이션은 우수한 사용자 경험을 위해 매우 짧은 대기 시간을 필요로 합니다. 사용자 경험을 개선하기 위해 AWS Global Accelerator는 사용자 트래픽을 클라이언트에 가장 가까운 애플리케이션 엔드포인트로 전달하여 인터넷 지연 시간과 지터를 줄입니다. Anycast를 통해 가장 가까운 엣지 로케이션으로 트래픽을 라우팅한 다음 AWS 글로벌 네트워크를 통해 가장 가까운 리전 엔드포인트로 라우팅합니다. AWS Global Accelerator는 네트워크 성능의 변화에 빠르게 대응하여 사용자의 애플리케이션 성능을 개선합니다.
AWS Global Accelerator와 Amazon CloudFront는 AWS 글로벌 네트워크와 전 세계의 엣지 로케이션을 사용하는 별도의 서비스입니다. CloudFront는 캐시 가능한 콘텐츠(예: 이미지 및 비디오)와 동적 콘텐츠(예: API 가속 및 동적 사이트 제공)에 대한 성능을 향상시킵니다. Global Accelerator는 하나 이상의 AWS 리전에서 실행되는 애플리케이션으로 에지에서 패킷을 프록시하여 TCP 또는 UDP를 통해 광범위한 애플리케이션의 성능을 향상시킵니다. Global Accelerator는 게임(UDP), IoT(MQTT) 또는 VoIP(Voice over IP)와 같은 비 HTTP 사용 사례와 특히 고정 IP 주소 또는 결정적이고 빠른 지역 장애 조치가 필요한 HTTP 사용 사례에 적합합니다. 두 서비스 모두 DDoS 보호를 위해 AWS Shield와 통합됩니다.
회사는 대량의 재무 데이터를 일괄 처리할 수 있는 애플리케이션을 설계할 계획입니다. Solutions Architect는 입력 및 출력 데이터를 저장할 두 개의 Amazon S3 버킷을 생성하는 업무를 받았습니다. 애플리케이션은 네트워크를 통해 여러 EC2 인스턴스 간에 데이터를 전송하여 데이터 처리를 완료합니다.
다음 중 데이터 전송 비용을 줄이는 옵션은 무엇입니까?
동일한 가용 영역에 Amazon EC2 인스턴스를 배포합니다.
1. 기본 원칙
모든 AWS 리전의 모든 서비스 간 인바운드 데이터 전송에는 요금이 부과되지 않습니다. 단, AWS에서 인터넷으로의 아웃 바운드 데이터 전송 요금은 서비스당 부과되며, 각 비용은 리전에 따라 다릅니다.
AWS 내에서의 데이터 전송은 워크로드에서 다른 AWS 서비스로 전송되거나 워크로드의 다른 구성 요소 간에 전송될 수 있습니다. 각 워크로드가 AWS 서비스에 액세스할 때 경우에 따라, 데이터 전송 요금이 발생할 수 있습니다.
2. 동일 AWS 리전 내의 전송 요금
인터넷 게이트웨이로 AWS 서비스에 접근 하는 경우
인터넷 게이트웨이를 사용하여 같은 리전에 있는 AWS 서비스의 퍼블릭 엔드포인트에 액세스하는 경우 데이터 전송 요금이 부과되지 않습니다. NAT 게이트웨이를 사용하여 동일한 서비스에 액세스하는 경우 게이트웨이를 통과하는 데이터에 대해 데이터 처리 요금(기가바이트[GB] 당)이 부과됩니다.
다중 가용 영역의 서비스에 접근하는 경우
동일한 리전 내 동일 가용 영역(AZ) 내에서의 데이터 전송은 무료입니다. 다만, 워크로드의 고가용성을 달성하기 위해 다중 가용 영역을 쓰는 경우에 데이 전송 비용이 발생할 수 있습니다.
3. 다른 AWS 리전 사이 전송 요금
해당 워크로드가 다른 AWS 리전의 서비스에 액세스하는 경우, 리전 간 데이터 전송 요금이 부과됩니다.
리전 간 VPC 내부 통신을 하는 경우
워크로드 구성 요소가 VPC 피어링 연결 또는 Transit Gateway를 사용하여 여러 리전에서 통신하는 경우 추가 데이터 전송 요금이 부과됩니다. VPC가 리전 간에 피어링되는 경우, 표준 리전 간 데이터 전송 요금이 부과됩니다.
이 시나리오에서는 동일한 가용 영역에 모든 EC2 인스턴스를 배포해야 합니다. 동일한 가용 영역에서 Amazon EC2, Amazon RDS, Amazon Redshift, Amazon ElastiCache 인스턴스 및 Elastic Network Interface 간에 전송되는 데이터는 무료입니다. 퍼블릭 네트워크를 사용하여 데이터를 전송하는 대신 사설 네트워크를 사용하여 전체 데이터 전송 비용을 줄일 수 있습니다.
회사에서 최소 비용으로 재해 복구(DR) 메커니즘을 설정하려고 합니다. 장애가 발생한 경우 시스템은 십분의 데이터 손실만 견딜 수 있습니다.
어떤 DR 방법을 제안하시겠습니까?
Pilot Light
파일럿 라이트라는 용어는 환경의 최소 버전이 항상 클라우드에서 실행되는 DR 시나리오를 설명하는 데 자주 사용됩니다. 파일럿 라이트의 아이디어는 가스 히터에서 나온 비유입니다. 가스 히터에서는 항상 켜져 있는 작은 불꽃으로 전체 용광로를 빠르게 점화하여 집을 데울 수 있습니다. 이 시나리오는 백업 및 복원 시나리오와 유사합니다. 예를 들어 AWS를 사용하면 AWS에서 시스템의 가장 중요한 핵심 요소를 구성하고 실행하여 파일럿 라이트를 유지할 수 있습니다. 주어진 사례의 경우 백업 인프라의 작은 부분이 항상 변경 가능한 데이터(예: 데이터베이스 또는 문서)를 동기화하여 중요한 데이터가 손실되지 않도록 동시에 실행됩니다. 복구 시간이 되면 핵심 코어를 중심으로 본격적인 프로덕션 환경을 신속하게 프로비저닝할 수 있습니다. 파일럿 라이트의 경우 RPO는 십분 단위이므로 이것이 올바른 솔루션입니다.
백업 및 복구 (시간 단위 RPO, 24시간 이하의 RTO): 데이터와 애플리케이션을 복구 리전에 백업합니다. 자동화된 백업 또는 지속적인 백업을 사용하면 특정 시점 복구가 가능하여 경우에 따라서는 RPO를 5분까지 줄일 수 있습니다. 재해 이벤트 시 인프라를 배포(RTO를 단축하기 위해 인프라를 코드로 사용하여)하고, 코드를 배포하고, 백업 데이터를 복원하여 복구 리전에서 재해로부터 복구합니다.
파일럿 라이트 (분 단위 RPO, 10분 단위 RTO): 코어 워크로드의 인프라 복사본을 복구 리전에 프로비저닝합니다. 데이터를 복구 리전에 복제하고 복구 리전에서 백업을 생성합니다. 데이터베이스 및 객체 스토리지 등 데이터 복제 및 백업을 지원하는 데 필요한 리소스가 항상 실행됩니다. 애플리케이션 서버 또는 서버리스 컴퓨팅과 같은 기타 요소는 배포되지 않지만 필요에 따라 필수 구성 및 애플리케이션 코드로 생성될 수 있습니다.
웜 대기 (초 단위 RPO, 분 단위 RTO): 모든 기능을 갖추었지만 축소된 버전의 워크로드를 복구 리전에 항상 실행되는 상태로 유지합니다. 비즈니스 크리티컬 시스템은 완전히 복제되고 항상 실행되지만 플릿은 축소됩니다. 데이터가 복구 리전에 복제되며 실행됩니다. 복구 시기가 되면 시스템은 프로덕션 로드를 처리하기 위해 신속하게 확장됩니다. 웜 대기가 확장될수록 RTO 및 컨트롤 플레인 의존도는 낮아집니다. 완전히 확장되면 이것을 상시 대기 방식이라고 합니다.
복수 리전(다중 사이트) 액티브/액티브 (0에 가까운 RPO, 0일 수 있는 RTO): 워크로드가 여러 AWS 리전에 배포되고 능동적으로 트래픽을 처리합니다. 이 전략을 사용하려면 리전 전체에서 데이터를 동기화해야 합니다. 서로 다른 두 개 리전에 있는 복제본에 같은 레코드를 쓸 때 나타날 수 있는 충돌을 피하거나 처리해야 하는데, 그 방법이 복잡할 수 있습니다. 데이터 복제는 데이터 동기화에 유용하며 일부 유형의 재해로부터 보호해 주지만, 솔루션에 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다.
회사는 애플리케이션을 호스팅하기 위해 영구 블록 스토리지가 있는 Amazon EC2 인스턴스를 시작해야 합니다. 저장된 데이터는 미사용 시 암호화되어야 합니다.
다음 중 이 시나리오에서 가장 적합한 스토리지 솔루션은 무엇입니까?
AWS KMS를 사용하여 암호화된 Amazon EBS 볼륨
Amazon Elastic Block Store(Amazon EBS)는 EC2 인스턴스에 사용할 수 있는 블록 수준 스토리지 볼륨을 제공합니다. EBS 볼륨은 형식이 지정되지 않은 원시 블록 디바이스처럼 동작합니다. 이러한 볼륨을 인스턴스에 디바이스로 마운트할 수 있습니다. 인스턴스에 연결된 EBS 볼륨은 스토리지 볼륨으로 표시되며, 인스턴스 수명에 관계없이 지속됩니다. 이러한 볼륨 위에 파일 시스템을 생성하거나 하드 드라이브와 같은 블록 디바이스를 사용하는 것처럼 볼륨을 사용할 수 있습니다. 인스턴스에 연결된 볼륨의 구성을 동적으로 변경할 수 있습니다.
데이터에 빠르게 액세스하고 장기적으로 지속해야 하는 경우 Amazon EBS를 사용하는 것이 좋습니다. EBS 볼륨은 세분화된 업데이트가 필요하고 형식이 지정되지 않은 블록 수준의 원시 스토리지에 액세스해야 하는 파일 시스템, 데이터베이스 또는 애플리케이션의 기본 스토리지로 사용하기에 특히 적합합니다. Amazon EBS는 임의 읽기 및 쓰기에 의존하는 데이터베이스 스타일의 애플리케이션과 장시간의 지속적인 읽기 및 쓰기를 수행하는 처리량 집약적 애플리케이션에 모두 적합합니다.
Amazon EBS 암호화는 EBS 데이터 볼륨, 부팅 볼륨 및 스냅샷에 대한 원활한 암호화를 제공하므로, 보안 키 관리 인프라를 구축하고 유지 관리할 필요가 없습니다. EBS 암호화는 Amazon 관리 키 또는 AWS Key Management Service (KMS)를 사용하여 생성 및 관리하는 키로 데이터를 암호화하여 저장 데이터 보안을 활성화합니다. EC2 인스턴스를 호스팅하는 서버에서 암호화가 이루어지기 때문에, EC2 인스턴스와 EBS 스토리지 사이에서 이동하는 데이터의 암호화도 제공합니다.
Amazon EBS 암호화가 대신 키 관리를 처리합니다. 새로 생성된 볼륨마다 고유한 256비트 AES 키가 있으며, 암호화된 스냅샷에서 생성된 볼륨은 해당 키를 공유합니다. 이러한 키는 강력한 논리적, 물리적 보안 제어를 구현하여 무단 액세스를 방지하는 AWS 고유의 키 관리 인프라를 통해 보호됩니다. 데이터 및 이와 연결된 키는 산업 표준 AES-256 알고리즘을 사용하여 암호화됩니다.
회사는 AWS에 여러 인스턴스에서 대량의 데이터를 주기적으로 처리하는 분산 애플리케이션을 가지고 있습니다. Solutions Architect는 모든 인스턴스 장애로부터 정상적으로 복구하도록 애플리케이션을 설계했습니다. 그런 다음 그는 가장 비용 효율적인 방법으로 애플리케이션을 시작해야 합니다.
이 요구 사항을 충족하는 EC2 인스턴스 유형은 무엇입니까?
스팟 인스턴스
다른 유형 중에서 가장 비용 효율적인 EC2 인스턴스가 필요합니다. 또한 호스트할 애플리케이션은 인스턴스 오류 발생 시 정상적으로 복구되도록 설계되었습니다.
비용 효율성 측면에서 스팟 및 예약 인스턴스가 최고의 옵션입니다. 그리고 애플리케이션은 인스턴스 장애로부터 정상적으로 복구할 수 있으므로 스팟 인스턴스는 가장 저렴한 유형의 EC2 인스턴스이므로 이 경우에 가장 적합한 옵션입니다. 스팟 인스턴스를 사용할 때 중단이 있습니다. Amazon EC2는 스팟 가격이 최고 가격을 초과하거나 스팟 인스턴스에 대한 수요가 증가하거나 스팟 인스턴스의 공급이 감소할 때 스팟 인스턴스를 중단할 수 있습니다.
회사에서 프라이빗 서브넷 내부의 EC2 인스턴스에서 배치 작업을 실행하고 있습니다. 인스턴스는 NAT 게이트웨이를 통해 동일한 리전의 S3 버킷에서 입력 데이터를 수집합니다. 이 회사는 중복성 또는 가용성에 대한 위험을 부과하지 않으면서 비용을 절감할 수 있는 솔루션을 찾고 있습니다.
어떤 솔루션이 이를 달성할 것입니까?
NAT 게이트웨이를 제거하고 게이트웨이 VPC 엔드포인트를 사용하여 인스턴스에서 S3 버킷에 액세스합니다.
게이트웨이 엔드포인트는 AWS 네트워크를 통해 VPC에서 Amazon S3에 액세스하기 위해 라우팅 테이블에 지정하는 게이트웨이입니다. 인터페이스 엔드포인트는 프라이빗 IP 주소를 사용하여 VPC 내, 온프레미스 또는 다른 AWS 리전에서 Amazon S3로 요청을 라우팅함으로써 게이트웨이 엔드포인트의 기능을 확장합니다. 인터페이스 끝점은 게이트웨이 엔드포인트와 호환됩니다. VPC에 기존 게이트웨이 엔드포인트가 있는 경우 동일한 VPC에서 두 가지 유형의 엔드포인트를 모두 사용할 수 있습니다.
게이트웨이 엔드포인트 사용에 대한 추가 비용은 없습니다. 그러나 데이터 전송 및 리소스 사용에 대한 표준 요금은 계속 적용됩니다.
전 세계에 지사를 두고 있는 글로벌 회사는 여러 AWS 계정을 보유하고 있습니다. CIO(최고 정보 책임자)는 효율성을 높이고 비용을 절감하기 위해 AWS 리소스를 중앙에서 관리하는 솔루션을 설정하려고 합니다. 이를 통해 AWS 리소스를 중앙에서 조달하고 AWS Transit Gateway, AWS License Manager 구성 또는 Amazon Route 53 Resolver 규칙과 같은 리소스를 다양한 계정에서 공유하려고 합니다.
이 시나리오에서 어떤 옵션 조합을 구현해야 합니까? (2개 선택)
AWS Resource Access Manager(RAM) 서비스를 사용하여 AWS 계정과 리소스를 쉽고 안전하게 공유합니다.
AWS Organizations를 사용하여 회사의 모든 계정을 통합합니다.
AWS Resource Access Manager(RAM)를 사용하면 AWS 계정 전체, AWS Organizations의 조직 또는 조직 단위(OU) 내, 그리고 지원되는 리소스 유형에 대한 IAM 역할 및 IAM 사용자와 리소스를 안전하게 공유할 수 있습니다. AWS RAM을 사용하여 전송 게이트웨이, 서브넷, AWS License Manager 라이선스 구성, Amazon Route 53 Resolver 규칙 등의 리소스 유형을 공유할 수 있습니다.
많은 조직에서 여러 계정을 사용하여 관리 또는 청구 격리를 생성하고 오류의 영향을 제한합니다. AWS RAM을 사용하면 여러 AWS 계정에 중복 리소스를 생성할 필요가 없습니다. 이렇게 하면 소유한 모든 계정의 리소스를 관리하는 운영 오버헤드가 줄어듭니다. 대신 다중 계정 환경에서 리소스를 한 번 생성하고 AWS RAM을 사용하여 리소스 공유를 생성하여 계정 간에 해당 리소스를 공유할 수 있습니다. 리소스 공유를 생성할 때 공유할 리소스를 선택하고, 리소스 유형별로 AWS RAM 관리 권한을 선택하고, 리소스에 액세스할 수 있는 사용자를 지정합니다. AWS RAM은 추가 요금 없이 사용할 수 있습니다.
AWS Organizations는 AWS 리소스가 늘어나고 확장됨에 따라 환경을 중앙 집중식으로 관리하고 규제하는 데 도움이 됩니다. AWS Organizations를 통해 프로그래밍 방식으로 새 AWS 계정을 생성하고 리소스를 할당하며, 계정을 그룹화하여 워크플로를 구성하고, 거버넌스를 위해 계정이나 그룹에 정책을 적용하며, 모든 계정에 대해 단일 결제 방법을 사용하여 청구를 간소화할 수 있습니다.
또한, AWS Organizations는 다른 AWS 서비스에 통합되므로 중앙 구성, 보안 메커니즘, 감사 요구 사항 및 조직 내 계정에 걸쳐 공유되는 리소스를 정의할 수 있습니다. 모든 AWS 고객은 AWS Organizations를 추가 비용 없이 사용할 수 있습니다.
감사팀은 회계 연도에 두 번만 감사 보고서를 생성하고 액세스합니다. 이 부서는 AWS Step Functions를 사용하여 솔루션에 내장된 장애 조치 및 재시도 시나리오가 있는 보고서 생성 프로세스를 조정합니다. 이러한 감사 보고서를 생성하기 위한 기본 데이터는 S3에 저장되고 수백 테라바이트로 실행되며 밀리초 지연 시간으로 사용할 수 있어야 합니다.
이 사용 사례에 사용하도록 권장하는 가장 비용 효율적인 스토리지 클래스는 무엇입니까?
Amazon S3 Standard-Infrequent Access
데이터는 회계 연도에 두 번만 액세스되지만 필요할 때 신속하게 액세스해야 하므로 이 사용 사례에 가장 비용 효율적인 스토리지 클래스는 S3 Standard-IA입니다. S3 Standard-IA 스토리지 클래스는 액세스 빈도가 낮지만 필요할 때 빠른 액세스가 필요한 데이터를 위한 것입니다. S3 Standard-IA는 S3 Standard의 높은 내구성, 높은 처리량 및 짧은 대기 시간과 일치하며 GB당 스토리지 가격과 GB당 검색 요금이 낮습니다. Standard-IA는 S3 Standard의 99.99% 가용성과 비교하여 99.9% 가용성을 위해 설계되었습니다. 그러나 보고서 생성 프로세스에는 워크플로에 장애 조치 및 재시도 시나리오가 내장되어 있으므로 S3 Standard-IA의 99.9% 가용성으로 인해 데이터를 사용할 수 없는 경우 데이터가 성공적으로 검색될 때까지 작업이 자동으로 다시 호출됩니다.
회사에는 프로젝트의 모든 상태와 진행 상황을 추적하는 온라인 시스템이 있습니다. 시스템은 AWS에서 호스팅되며 MySQL RDS 인스턴스에 대한 읽기 및 쓰기 IOP 지표를 모니터링하고 DevOps 팀에 실시간 알림을 보내야 하는 요구 사항이 있습니다.
AWS에서 다음 중 요구 사항을 충족하기 위해 사용할 수 있는 서비스는 무엇입니까? (2개 선택)
CloudWatch
Amazon Simple Notification Service
Amazon Simple Notification Service(Amazon SNS)는 클라우드에서 손쉽게 알림을 설정, 운영 및 전송할 수 있도록 하는 웹 서비스입니다. 개발자에게 애플리케이션의 메시지를 게시하고 이를 구독자나 다른 애플리케이션에 즉시 전송할 수 있는 고도로 확장 가능하며 유연하고 비용 효율적인 기능을 제공합니다. 개발자가 보다 쉽게 웹 규모의 컴퓨팅 작업을 할 수 있도록 설계되었습니다. Amazon SNS는 “publish-subscribe”(pub-sub) 메시징 패러다임을 따릅니다. 즉, 클라이언트에게 전송되는 알림이 “푸시” 메커니즘을 사용하기 때문에 새로운 정보나 업데이트를 정기적으로 확인하거나 “폴링”할 필요가 없습니다. 또한 초기 개발 수고가 거의 없는 간편한 API를 갖추고 있어 유지관리 부담이 없고, 종량 과금제로 청구되기 때문에 개발자는 애플리케이션에 강력한 기능의 알림 시스템을 손쉽게 통합할 수 있습니다.
Amazon CloudWatch는 Amazon Web Services(AWS) 리소스 및 AWS에서 실행되는 애플리케이션을 실시간으로 모니터링합니다. CloudWatch를 사용하여 리소스 및 애플리케이션에 대해 측정할 수 있는 변수인 지표를 수집하고 추적할 수 있습니다.
CloudWatch 홈페이지에는 사용 중인 모든 AWS 서비스에 관한 지표가 자동으로 표시됩니다. 사용자 지정 대시보드를 추가로 생성해 사용자 지정 애플리케이션에 대한 지표를 표시하고, 선택한 지표의 사용자 지정 집합을 표시할 수 있습니다.
이 시나리오에서는 CloudWatch를 사용하여 AWS 리소스와 SNS를 모니터링하여 알림을 제공할 수 있습니다.
회사에서 Redis용 Amazon ElastiCache를 분산 세션 관리 구성 요소로 사용하는 업무 포털을 설계하고 있습니다. 부서의 다른 클라우드 엔지니어가 ElastiCache 클러스터에 액세스할 수 있으므로 Redis 명령을 실행할 수 있는 권한이 부여되기 전에 비밀번호를 입력하도록 요구하여 포털의 세션 데이터를 보호해야 합니다.
위의 요구 사항을 충족하려면 다음 중 무엇을 해야 합니까?
--transit-encryption-enabled 및 --auth-token 매개변수가 모두 활성화된 새 Redis 클러스터를 생성하여 Redis AUTH를 사용하여 사용자를 인증합니다.
Redis 인증 토큰 또는 암호는 Redis가 클라이언트의 명령 실행을 허용하기 전에 암호를 요구할 수 있게 함으로써 데이터 보안을 개선합니다. 이렇게 하려면 복제 그룹 또는 클러스터를 생성할 때 올바른 토큰을 가진 파라미터 --auth-token(API: AuthToken)을 포함시킵니다. 또한 복제 그룹 또는 클러스터에 대한 모든 후속 명령에 이를 포함시킵니다.
다음 AWS CLI 작업은 전송 중 데이터 암호화(TLS)가 활성화되고 AUTH 토큰 This-is-a-sample-token이 포함된 복제 그룹을 생성합니다. 서브넷 그룹 sng-test는 존재하는 서브넷 그룹으로 대체합니다.
키 파라미터
--engine - 반드시 redis여야 합니다.
--engine-version - 3.2.6, 4.0.10 또는 그 이상이어야 합니다.
--transit-encryption-enabled - 인증 및 HIPAA 자격 획득에 필요합니다.
--auth-token - HIPAA 자격 획득에 필요합니다. 이 값은 이러한 토큰 보호 Redis 서버를 위한 올바른 토큰이어야 합니다.
--cache-subnet-group - HIPAA 자격 획득에 필요합니다.
Solutions Architect는 Amazon FSx for Windows File Server가 연결된 Windows EC2 인스턴스에서 실행되는 애플리케이션을 관리하고 있습니다. 비용을 절감하기 위해 경영진은 업무 외 시간에 인스턴스를 중지하고 필요할 때만 다시 시작하기로 결정했습니다. 애플리케이션이 완전히 작동하는 데 몇 분이 소요되어 생산성에 영향을 미치는 것으로 관찰되었습니다.
비용을 높이지 않고 어떻게 인스턴스의 로딩 시간을 단축할 수 있습니까?
최대 절전 모드가 활성화된 EC2 인스턴스로 애플리케이션을 마이그레이션합니다.
최대 절전 모드를 사용하면 인스턴스를 편리하게 일시 중지하고 다시 시작할 수 있고, 애플리케이션 시작 시간을 줄여 시간을 절약할 수 있으며, 환경 또는 애플리케이션을 완전히 다시 설정하는 수고를 덜 수 있습니다. 하이버네이션을 사용하면 메모리 공간을 다시 구축하는 대신 애플리케이션을 중단한 위치에서 정확히 다시 시작할 수 있습니다.
최대 절전 모드 프로세스는 나중에 동일한 시점에서 인스턴스를 다시 시작할 수 있도록 인스턴스의 인메모리 상태와 프라이빗 및 탄력적 IP 주소를 저장합니다.
인스턴스를 최대 절전 모드 상태로 설정하면 인메모리 상태가 루트 EBS 볼륨에 있는 파일에 저장된 다음 실질적으로 인스턴스가 종료됩니다. 인스턴스를 시작하는 데 사용된 AMI와 인스턴스의 루트 EBS 볼륨은 암호화되어야 합니다. 암호화는 민감한 데이터가 메모리에서 EBS 볼륨으로 복사될 때 올바른 보호 기능을 제공합니다.
이미지 공유 회사는 Amazon S3를 사용하여 사용자가 업로드한 이미지를 저장합니다. 이러한 이미지는 AWS-KMS를 사용하여 S3에서 암호화된 상태로 유지되며 회사는 암호화를 위해 자체 CMK(고객 마스터 키)를 관리합니다. DevOps 팀의 구성원이 하루 전에 실수로 CMK를 삭제하여 사용자의 사진 데이터를 복구할 수 없게 되었습니다. 이 위기에 대한 가능한 솔루션에 대해 상담하기 위해 회사에서 연락을 받았습니다.
이 문제를 해결하기 위해 다음 중 어떤 단계를 권장하시겠습니까?
CMK는 하루 전에 삭제되었으므로 '삭제 보류 중' 상태여야 하므로 CMK 삭제를 취소하고 키를 복구하면 됩니다.
AWS Key Management Service(KMS)를 사용하면 암호화 키를 쉽게 생성 및 관리하고 광범위한 AWS 서비스와 애플리케이션에서 사용을 제어할 수 있습니다. AWS KMS는 FIPS 140-2에 따라 검증된 하드웨어 보안 모듈을 사용하는 안전하고 탄력적인 서비스입니다.
AWS Key Management Service(AWS KMS)에서 고객 마스터 키(CMK)를 삭제하면 파괴적이며 잠재적으로 위험합니다. 따라서 AWS KMS는 대기 기간을 적용합니다. AWS KMS에서 CMK를 삭제하려면 키 삭제를 예약합니다. 대기 기간은 최소 7일에서 최대 30일까지 설정할 수 있습니다. 기본 대기 기간은 30일입니다. 대기 기간 동안 CMK 상태 및 키 상태는 삭제 보류입니다. CMK를 복구하려면 대기 기간이 끝나기 전에 키 삭제를 취소하면 됩니다. 대기 기간이 끝나면 키 삭제를 취소할 수 없으며 AWS KMS가 CMK를 삭제합니다.
고객 관리형 키 삭제만 예약할 수 있습니다. AWS 관리형 키 또는 AWS 소유 키은 삭제할 수 없습니다.
명시적으로 삭제를 예약하고 필수 대기 기간이 만료되지 않으면 AWS KMS에서 KMS 키가 삭제되지 않습니다.
콘텐츠 관리 시스템(CMS)은 Amazon Aurora를 데이터베이스로 사용하는 자동 크기 조정, 온디맨드 EC2 인스턴스 집합에서 호스팅됩니다. 현재 시스템은 사용자가 업로드한 파일 문서를 첨부된 EBS 볼륨 중 하나에 저장합니다. 관리자는 시스템 성능이 상당히 느리다는 것을 알아차리고 시스템 아키텍처를 개선하도록 지시했습니다.
이 시나리오에서 확장 가능하고 고가용성 POSIX 호환 공유 파일 시스템을 구현하기 위해 무엇을 하시겠습니까?
EFS 사용
Amazon Elastic File System(Amazon EFS)은 AWS에서 파일 스토리지를 쉽게 설정, 확장 및 비용 최적화할 수 있게 해주는 간단한 방식의 탄력적 서버리스 파일 시스템으로, 한 번만 설정하면 됩니다. AWS 관리 콘솔을 사용하면 클릭 몇 번 만으로 Amazon Elastic Compute Cloud(EC2) 인스턴스, Amazon 컨테이너 서비스(Amazon Elastic Container Service(ECS), Amazon Elastic Kubernetes Service(EKS) 및 AWS Fargate)에 액세스할 수 있고 파일 시스템 인터페이스(표준 운영 체제 파일 I/O API를 사용)를 통해 AWS Lambda 함수에 액세스할 수 있는 파일 시스템을 생성할 수 있습니다. 또한 강력한 데이터 일관성, 파일 잠금 등의 파일 시스템 액세스 시멘틱을 완벽하게 지원합니다.
Amazon EFS 파일 시스템은 스토리지를 프로비저닝할 필요 없이 자동으로 기가바이트에서 페타바이트 규모의 데이터로 확장될 수 있습니다. 수십 개, 수백 개 또는 수천 개의 컴퓨팅 인스턴스에서 동시에 Amazon EFS 파일 시스템에 액세스할 수 있으며, Amazon EFS는 각 컴퓨팅 인스턴스에 일관된 성능을 제공합니다. Amazon EFS는 높은 가용성과 뛰어난 내구성을 갖추도록 설계되었습니다. Amazon EFS에는 최소 비용이나 설정 비용이 없으며, 사용한 만큼만 비용을 지불하면 됩니다.
이 시나리오는 EBS, EFS 및 S3에 대한 이해도를 테스트합니다. 이 시나리오에는 사용자의 파일 문서를 연결된 EBS 볼륨 중 하나로 저장하는 온디맨드 EC2 인스턴스 집합이 있습니다. 아키텍처가 파일 문서에 대한 EC2 인스턴스 병렬 공유 액세스를 제공하지 않기 때문에 시스템 성능이 상당히 느립니다.
EBS 볼륨은 여러 EC2 인스턴스에 연결할 수 있지만 가용 영역 내의 인스턴스에만 연결할 수 있습니다. 이 시나리오에서 필요한 것은 여러 가용 영역에 걸쳐 있는 고가용성 스토리지입니다. 여기에 필요한 저장소 유형은 EFS 입니다.
회사에서 고품질 사진을 받아 다운로드 가능한 비디오로 변환하는 웹사이트를 시작했습니다. 웹사이트는 더 빠른 처리를 보장하는 무료 및 프리미엄 계정을 제공합니다. 무료 및 프리미엄 회원의 모든 요청은 단일 SQS 대기열을 거친 다음 비디오를 생성하는 EC2 인스턴스 그룹에서 처리됩니다. 회사는 서비스를 유료로 제공하는 프리미엄 사용자가 무료 회원보다 우선순위가 높은지 확인해야 합니다.
회사는 이 요구 사항을 해결하기 위해 아키텍처를 어떻게 재설계해야 합니까?
무료 회원을 위한 SQS 대기열과 프리미엄 회원을 위한 또 다른 대기열을 만듭니다. 프리미엄 대기열에서 먼저 메시지를 사용하도록 EC2 인스턴스를 구성하고 비어 있는 경우 무료 회원의 SQS 대기열에서 폴링합니다.
Amazon Simple Queue Service(SQS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리하고 확장할 수 있는 완전관리형 메시지 대기열 서비스입니다. SQS는 메시지 지향 미들웨어 관리 및 운영과 관련된 복잡성과 오버헤드를 제거하고 개발자가 작업 차별화에 집중할 수 있도록 합니다. SQS를 사용하면 메시지 손실이나 다른 서비스를 사용할 필요 없이 모든 볼륨의 소프트웨어 구성 요소 간에 메시지를 보내고 저장하고 받을 수 있습니다.
이 시나리오에서는 각 유형의 구성원에 대해 2개의 별도 SQS 대기열을 만드는 것이 가장 좋습니다. 프리미엄 회원의 SQS 대기열은 EC2 인스턴스에서 먼저 폴링할 수 있으며 완료되면 무료 회원의 메시지를 다음에 처리할 수 있습니다.
회사에 일련의 EC2 인스턴스에서 호스팅되는 글로벌 뉴스 웹사이트가 있습니다. 최근 웹사이트의 로드가 증가하여 사이트 방문자의 응답 시간이 느려졌습니다. 이 문제는 일부 독자가 10초 후에 로드되지 않으면 사이트를 떠나는 경향이 있기 때문에 회사의 수익에 영향을 미칩니다.
다음 중 이 문제를 해결하는 데 사용할 수 있는 AWS 서비스는 무엇입니까? (2개 선택)
웹 사이트와 함께 Amazon CloudFront를 사용자 지정 오리진으로 사용합니다
웹 사이트의 인메모리 데이터 스토어 또는 캐시에 Amazon ElastiCache를 사용합니다.
글로벌 뉴스 사이트는 전 세계에서 사이트의 독자가 많다는 점을 감안할 때 지연 문제가 있습니다. 이 시나리오에서는 인터넷 콘텐츠의 빠른 배달을 제공하기 위해 함께 작동하는 지리적으로 분산된 서버 그룹인 CDN(콘텐츠 배달 네트워크)을 사용할 수 있습니다. 그리고 이것은 뉴스 웹사이트이기 때문에 대부분의 데이터가 읽기 전용이므로 읽기 처리량을 개선하고 서버의 반복적인 요청을 피하기 위해 캐시할 수 있습니다.
AWS에서 Amazon CloudFront는 사용할 수 있는 글로벌 CDN(콘텐츠 전송 네트워크) 서비스이며 웹 캐싱에는 Amazon ElastiCache가 적합한 서비스입니다.
Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다.
Amazon ElastiCache는 유연한 실시간 사용 사례를 지원하는 완전관리형 인 메모리 캐싱 서비스입니다. 캐싱에 ElastiCache를 사용하면 애플리케이션 및 데이터베이스 성능을 가속화할 수 있으며, 세션 스토어, 게임 리더보드, 스트리밍 및 분석과 같이 내구성이 필요하지 않는 사용 사례에서는 기본 데이터 스토어로 사용할 수 있습니다. ElastiCache는 Redis 및 Memcached와 호환 가능합니다.
AWS의 Auto Scaling EC2 인스턴스 그룹에서 호스팅되는 웹 애플리케이션이 있습니다. 애플리케이션은 매일 아침 엄청난 트래픽을 수신하며 많은 사용자가 요청 시간 초과에 대해 불평하고 있습니다. EC2 인스턴스는 사용자 요청에 응답하기 전에 부팅하는 데 1분이 걸립니다. 애플리케이션의 변화하는 트래픽에 더 잘 대응할 수 있도록 클라우드 아키텍처를 재설계해야 합니다.
아키텍처를 어떻게 재설계해야 합니까?
단계 조정 정책을 생성하고 인스턴스 워밍업 시간 조건을 구성합니다.
Amazon EC2 Auto Scaling은 Amazon EC2 인스턴스를 자동으로 시작하거나 종료하여 애플리케이션 로드를 처리하기에 적절한 수의 Amazon EC2 인스턴스를 유지할 수 있도록 설계된 완전관리형 서비스입니다. Amazon C2 Auto Scaling을 사용하면 비정상 인스턴스를 탐지하여 교체하는 EC2 인스턴스 플릿 관리를 통해 그리고 사용자가 정의하는 조건에 따라 Amazon EC2 용량을 자동으로 확장 또는 축소함으로써 애플리케이션 가용성을 유지할 수 있습니다. Amazon EC2 Auto Scaling을 사용하면 수요가 급증할 경우 Amazon EC2 인스턴스의 수를 자동으로 늘려 성능을 그대로 유지하고, 수요가 적을 경우 자동으로 용량을 줄여 비용을 절감할 수 있습니다.
단계 조정은 경보 위반의 크기에 따라 조정을 변경하기 위해 여러 조치를 설정할 수 있음을 의미하는 "단계 조정"을 적용합니다. 단계 조정 정책을 생성할 때 새로 시작한 인스턴스가 워밍업되는 데 걸리는 시간(초)도 지정할 수 있습니다.
스트리밍 솔루션 회사는 기본 EC2 인스턴스로 요청을 라우팅하는 ALB(Application Load Balancer)를 사용하여 비디오 스트리밍 제품을 구축하고 있습니다. 엔지니어링팀은 특이한 패턴을 발견했습니다. ALB는 비정상으로 감지될 때마다 정상 인스턴스 풀에서 인스턴스를 제거하지만 Auto Scaling 그룹이 교체 인스턴스를 시작하고 프로비저닝하지 못합니다.
이 이상 현상을 무엇으로 설명할 수 있습니까?
Auto Scaling 그룹은 EC2 기반 상태 확인을 사용하고 Application Load Balancer는 ALB 기반 상태 확인을 사용 중입니다.
Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 유지할 수 있습니다. 오토 스케일링이라는 EC2 인스턴스 모음을 생성합니다. 각 오토 스케일링의 최소 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling에서는 그룹의 크기가 이 값 아래로 내려가지 않습니다. 각 오토 스케일링의 최대 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling에서는 그룹의 크기가 이 값을 넘지 않습니다. 원하는 용량을 지정한 경우 그룹을 생성한 다음에는 언제든지 Amazon EC2 Auto Scaling에서 해당 그룹에서 이만큼의 인스턴스를 보유할 수 있습니다. 조정 정책을 지정했다면 Amazon EC2 Auto Scaling에서는 애플리케이션의 늘어나거나 줄어드는 수요에 따라 인스턴스를 시작하거나 종료할 수 있습니다.
Application Load Balancer는 수신되는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너 및 Lambda 함수와 같은 여러 대상에 자동으로 분산합니다. 단일 가용 영역 또는 여러 가용 영역에서 애플리케이션 트래픽의 다양한 로드를 처리할 수 있습니다.
ASG(자동 스케일링 그룹)가 EC2를 상태 검사 유형으로 사용하고 ALB(Application Load Balancer)가 내장 상태 검사를 사용하는 경우 상태 검사 ping이 인스턴스에서 응답을 수신하지 못해 ALB 상태 검사가 실패하는 상황이 발생할 수 있습니다. 동시에 ASG 상태 검사는 EC2 기반 상태 검사를 기반으로 하므로 성공적으로 돌아올 수 있습니다. 따라서 이 시나리오에서는 ALB가 인벤토리에서 인스턴스를 제거하지만 ASG는 대체 인스턴스를 제공하지 못합니다. 이로 인해 문제 문에 언급된 확장 문제가 발생할 수 있습니다.
Solutions Architect는 애플리케이션을 위한 고가용성 환경을 설계하고 있습니다. Architect는 Auto Scaling Group 내의 EC2 인스턴스에서 애플리케이션을 호스팅할 계획입니다. 그리고 조건 중 하나는 인스턴스가 종료되는 경우 루트 EBS 볼륨에 저장된 데이터를 보존해야 한다는 것입니다.
요구 사항을 충족하려면 어떻게 해야 합니까?
EBS 볼륨의 DeleteOnTermination 속성 값을 False로 설정합니다.
인스턴스는 종료한 후에도 잠시 동안 콘솔에 표시되며 그 이후 항목이 자동으로 삭제됩니다. 종료된 인스턴스 항목을 사용자가 직접 삭제할 수는 없습니다. 인스턴스가 종료되면 태그 및 볼륨과 같은 리소스가 해당 인스턴스에서 점차 연결 해제되며, 조금 지나면 종료된 인스턴스에서 더 이상 보이지 않을 수 있습니다.
인스턴스가 종료하면 해당 인스턴스와 관련된 모든 인스턴스 스토어 볼륨의 데이터는 삭제됩니다.
기본적으로 Amazon EBS 루트 디바이스 볼륨은 인스턴스 종료 시 자동으로 삭제됩니다. 하지만 시작 시 연결하는 추가 EBS 볼륨 또는 기존 인스턴스에 연결하는 EBS 볼륨은 인스턴스가 종료된 후에도 기본적으로 유지됩니다. 이런 동작은 해당 볼륨의 DeleteOnTermination 속성에 의해 제어되며, 이러한 속성은 사용자가 변경할 수 있습니다.
인스턴스가 종료되면 Amazon EC2가 연결된 각 Amazon EBS 볼륨의 DeleteOnTermination 속성 값을 사용하여 볼륨 유지 또는 삭제 여부를 결정합니다.
인스턴스가 종료될 때 루트 볼륨을 유지하려면 루트 볼륨의 DeleteOnTermination 속성을 False로 변경합니다.
회사에 Amazon S3에서 CSV 파일로 복제해야 하는 온프레미스 MySQL 데이터베이스가 있습니다. 데이터베이스는 Amazon Aurora Serverless 클러스터로 시작되고 RDS 프록시와 통합되어 웹 애플리케이션이 데이터베이스 연결을 풀링하고 공유할 수 있게 되었습니다. 데이터가 완전히 복사되면 온프레미스 데이터베이스에 대한 지속적인 변경 사항이 S3 버킷으로 계속 스트리밍되어야 합니다. 이 회사는 관리 오버헤드가 적으면서도 여전히 높은 보안을 구현할 수 있는 솔루션을 원합니다.
Solutions Architect는 어떤 수집 패턴을 취해야 합니까?
AWS Database Migration Service(AWS DMS)를 사용하여 전체 로드 및 변경 데이터 캡처(CDC) 복제 작업을 생성합니다. 새 Certificate Authority (CA) 인증서를 추가하고 SSL을 사용하여 AWS DMS 엔드포인트를 생성합니다.
AWS Database Migration Service(AWS DMS)는 관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 및 기타 유형의 데이터 저장소를 쉽게 마이그레이션할 수 있는 클라우드 서비스입니다. AWS DMS를 사용하여 데이터를 AWS 클라우드로 또는 클라우드와 온프레미스 설정의 조합 간에 마이그레이션할 수 있습니다.
AWS DMS를 사용하면 일회성 마이그레이션을 수행하고 지속적인 변경 사항을 복제하여 소스와 대상을 동기화 상태로 유지할 수 있습니다. 다른 데이터베이스 엔진으로 마이그레이션하려는 경우 AWS Schema Conversion Tool(AWS SCT)을 사용하여 데이터베이스 스키마를 새 플랫폼으로 변환할 수 있습니다. 그런 다음 AWS DMS를 사용하여 데이터를 마이그레이션합니다. AWS DMS는 AWS 클라우드의 일부이므로 AWS 서비스가 제공하는 비용 효율성, 출시 속도, 보안 및 유연성을 얻을 수 있습니다.
기본 수준에서 AWS DMS는 복제 소프트웨어를 실행하는 AWS 클라우드의 서버입니다. 소스 및 대상 연결을 생성하여 AWS DMS에 추출 및 로드할 위치를 알려줍니다. 그런 다음 이 서버에서 실행되는 작업을 예약하여 데이터를 이동합니다. AWS DMS는 대상에 테이블 및 연결된 기본 키가 없는 경우 생성합니다. 원하는 경우 대상 테이블을 직접 사전 생성할 수 있습니다. 또는 AWS Schema Conversion Tool(AWS SCT)을 사용하여 대상 테이블, 인덱스, 보기, 트리거 등의 일부 또는 전체를 생성할 수 있습니다.
지원되는 모든 데이터베이스 소스에서 AWS DMS를 사용하여 Amazon S3로 데이터를 마이그레이션할 수 있습니다. AWS DMS 작업에서 Amazon S3를 대상으로 사용할 때 전체 로드 및 변경 데이터 캡처(CDC) 데이터는 기본적으로 쉼표로 구분된 값(.csv) 형식으로 기록됩니다.
쉼표로 구분된 값(.csv) 형식은 Amazon S3 대상 객체의 기본 스토리지 형식입니다. 보다 컴팩트한 스토리지와 더 빠른 쿼리를 위해 Apache Parquet(.parquet)를 스토리지 형식으로 대신 사용할 수 있습니다.
SSL(Secure Sockets Layer)을 사용하여 소스 및 대상 엔드포인트에 대한 연결을 암호화할 수 있습니다. 이를 위해 AWS DMS Management Console 또는 AWS DMS API를 사용하여 엔드포인트에 인증서를 할당할 수 있습니다. AWS DMS 콘솔을 사용하여 인증서를 관리할 수도 있습니다.
모든 데이터베이스가 동일한 방식으로 SSL을 사용하는 것은 아닙니다. Amazon Aurora MySQL-Compatible Edition은 클러스터에 있는 기본 인스턴스의 엔드포인트인 서버 이름을 SSL의 엔드포인트로 사용합니다. Amazon Redshift 엔드포인트는 이미 SSL 연결을 사용하고 있으며 AWS DMS에서 설정한 SSL 연결이 필요하지 않습니다.
웹 애플리케이션 제품군은 3개의 가용 영역에 걸쳐 EC2 인스턴스의 Auto Scaling 그룹에서 호스팅되며 기본 설정으로 구성됩니다. 요청을 URL 경로의 해당 대상 그룹에 전달하는 Application Load Balancer가 있습니다. 이 때 애플리케이션으로 들어오는 트래픽이 적어 축소 정책이 트리거되었습니다.
Auto Scaling 그룹에서 가장 먼저 종료할 EC2 인스턴스는 무엇입니까?
가장 오래된 시작 구성에서 시작된 EC2 인스턴스
Amazon EC2 Auto Scaling은 종료 정책을 사용하여 축소 이벤트 중에 처음 종료할 인스턴스를 결정합니다. 종료 정책은 종료할 인스턴스를 선택할 때 Amazon EC2 Auto Scaling에서 사용하는 종료 기준을 정의합니다.
오토 스케일링은 기본 종료 정책을 사용하지만, 사용자는 원하는 경우 자신의 종료 기준에 따라 자체 종료 정책을 선택하거나 생성할 수 있습니다. 이렇게 하면 특정 애플리케이션 요구 사항에 따라 인스턴스가 종료될 수 있습니다.
기본 종료 정책은 종료할 인스턴스를 선택하기 전에 여러 종료 기준을 적용합니다. Amazon EC2 Auto Scaling이 인스턴스를 종료하면 먼저 인스턴스가 가장 많은 가용 영역을 확인하고 축소가 방지되지 않는 인스턴스를 최소 하나 이상 찾습니다. 선택한 가용 영역 내에서 다음과 같은 기본 종료 정책 동작이 적용됩니다.
1. 종료 대상 인스턴스 중 가장 오래된 시작 템플릿 또는 시작 구성을 사용하는 인스턴스가 있는지 확인합니다.
1.1. [시작 템플릿을 사용하는 오토 스케일링의 경우]
시작 구성을 사용하는 인스턴스가 없다면 인스턴스 중에서 가장 오래된 시작 템플릿을 사용하는 인스턴스가 있는지 확인합니다. Amazon EC2 Auto Scaling은 시작 템플릿을 사용하는 인스턴스를 종료하기 전에 시작 구성을 사용하는 인스턴스를 종료합니다.
1.2. [시작 구성을 사용하는 오토 스케일링의 경우]
이 중에서 가장 오래된 시작 구성을 사용하는 인스턴스가 있는지 확인합니다.
2. 앞선 기준을 적용한 후 종료할 비보호 인스턴스가 여러 개 있는 경우, 다음 결제 시간에 가장 근접한 인스턴스가 무엇인지 확인합니다. 다음번 결제 시간에 가장 근접한 비보호 인스턴스가 여러 개인 경우 이러한 인스턴스 중 하나를 임의로 종료합니다.
회사는 내구성 있는 스토리지 서비스를 사용하여 온프레미스 데이터베이스 백업을 AWS 클라우드에 저장할 계획입니다. 백업 데이터를 이동하려면 빠른 복구를 위해 표준 파일 저장 프로토콜을 통해 객체를 저장하고 검색할 수 있는 서비스를 사용해야 합니다.
다음 중 이 요구 사항을 충족하는 옵션은 무엇입니까?
AWS Storage Gateway 파일 게이트웨이를 사용하여 모든 백업 데이터를 Amazon S3에 저장합니다.
AWS Storage Gateway는 사실상 무제한의 클라우드 스토리지에 대한 온프레미스 액세스 권한을 제공하는 하이브리드 클라우드 스토리지 서비스입니다. Storage Gateway는 iSCSI, SMB 및 NFS와 같은 표준 스토리지 프로토콜 세트를 제공하므로 기존 애플리케이션을 다시 작성하지 않고 AWS 스토리지를 사용할 수 있습니다. Amazon 클라우드 스토리지 서비스에 데이터를 안전하고 안정적으로 저장하면서 자주 액세스하는 데이터는 온프레미스에 캐싱하여 지연 시간이 짧은 성능을 제공합니다. Storage Gateway는 변경된 데이터만 전송하고 데이터를 압축하여 AWS로의 데이터 전송을 최적화합니다. Storage Gateway는 Amazon S3 및 Amazon FSx for Windows File Server 클라우드 스토리지와 기본적으로 통합하여 데이터를 클라우드 내에서 처리할 수 있고, AWS Identity and Access Management(IAM)와 통합하여 서비스 및 리소스에 대한 액세스 관리를 안전하게 보호할 수 있으며, AWS Key Management Service(KMS)와 통합하여 클라우드에 저장된 데이터를 암호화하고, Amazon CloudWatch와 통합하여 모니터링 기능을 제공하고, AWS CloudTrail과 통합하여 계정 활동을 로깅할 수 있습니다.
온프레미스의 백업 데이터를 내구성 있는 클라우드 스토리지 서비스에 저장하려면 파일 게이트웨이를 사용하여 표준 파일 스토리지 프로토콜(SMB 또는 NFS)을 통해 객체를 저장하고 검색할 수 있습니다. 파일 게이트웨이를 사용하면 기존 파일 기반 애플리케이션, 디바이스 및 워크플로에서 수정 없이 Amazon S3를 사용할 수 있습니다. 파일 게이트웨이는 파일 콘텐츠와 메타데이터를 모두 객체로 안전하고 지속적으로 저장하는 동시에 온프레미스 애플리케이션에 캐시된 데이터에 대한 짧은 대기 시간 액세스를 제공합니다.
Amazon S3 File Gateway는 업계 표준 파일 프로토콜을 사용하여 파일을 원활하게 Amazon S3에 객체로 저장하고 이에 액세스할 수 있는 파일 인터페이스를 애플리케이션에 제공하는 AWS Storage Gateway 서비스 구성입니다.
Amazon S3 File Gateway의 사용 사례로는 (a) 최근에 액세스한 데이터에 대해 빠른 로컬 액세스를 유지하면서 온프레미스 파일 데이터를 Amazon S3로 마이그레이션, (b) 온프레미스 파일 데이터를 Amazon S3에 객체로 백업하고(Microsoft SQL Server와 Oracle 데이터베이스 및 로그 포함) 수명 주기 관리 및 교차 리전 복제와 같은 S3 기능을 사용, (c) 기계 학습, 빅 데이터 분석 또는 서버리스 함수와 같은 AWS 서비스로 처리하기 위해 온프레미스 애플리케이션에서 생성한 데이터를 사용하는 하이브리드 클라우드 워크플로가 있습니다.
Amazon S3 File Gateway를 사용하면 아무런 변경 없이 기존 파일 기반 애플리케이션, 디바이스 및 워크플로에서 Amazon S3를 사용할 수 있습니다. Amazon S3 File Gateway는 파일 콘텐츠와 메타데이터를 모두 객체로 안전하고 안정적으로 저장하면서 동시에 온프레미스 애플리케이션에 캐시된 데이터에 대한 대기 시간이 짧은 액세스를 제공합니다.
온라인 게임은 백엔드 서비스에 CloudFront, Lambda 및 DynamoDB를 사용합니다. 플레이어 데이터는 DynamoDB 테이블에 유지되고 정적 콘텐츠는 CloudFront에서 배포됩니다. 하지만 플레이어 정보를 저장하고 불러오는 데 시간이 많이 걸린다는 불만이 많습니다.
게임 성능을 개선하기 위해 DynamoDB 응답 시간을 밀리초에서 마이크로초로 줄이는 데 사용할 수 있는 AWS 서비스는 무엇입니까?
Amazon DynamoDB Accelerator(DAX)
DAX는 Amazon DynamoDB를 위한 가용성이 뛰어난 완전관리형 인 메모리 cache로서, 초당 요청 수가 몇 백만 개인 경우에도 몇 밀리초에서 몇 마이크로초까지 최대 10배의 성능을 제공합니다.
개발자가 캐시 무효화, 클러스터 관리 또는 데이터 집단을 관리할 필요 없이 DAX가 DynamoDB 테이블에 인 메모리 가속화를 추가하는 데 필요한 모든 작업을 수행합니다.
DynamoDB에서 일관되게 10밀리초 미만의 지연 시간을 제공하지만, DynamoDB와 DAX가 결합되면 성능을 한 단계 업그레이드하여 읽기 중심의 워크로드에서 초당 수백만 개의 요청에도 마이크로초의 응답 시간을 지원합니다. DAX를 사용하면 인기 있는 이벤트 또는 뉴스로 요청 볼륨이 전례 없이 증가하더라도 애플리케이션이 빠른 응답 속도를 유지할 수 있습니다.
회사에 Application Load Balancer 뒤의 Amazon ECS 클러스터에서 호스팅되는 애플리케이션이 있습니다. Solutions Architect는 요청이 시작된 국가를 기반으로 웹 요청을 허용하거나 차단하는 정교한 웹 필터링 솔루션을 구축하고 있습니다. 그러나 솔루션은 여전히 해당 국가의 특정 IP 주소를 허용해야 합니다.
이 요구 사항을 충족하기 위해 Architect는 어떤 단계 조합을 구현해야 합니까? (2개 선택)
특정 국가에서 시작된 요청을 차단하는 지역 일치 조건을 사용하여 AWS WAF 웹 ACL에 다른 규칙을 추가합니다.
AWS WAF를 사용하여 IP 세트에 선언된 승인된 IP 주소의 요청을 명시적으로 허용하는 규칙으로 웹 ACL을 생성합니다.
요청이 시작된 국가를 기반으로 웹 요청을 허용하거나 차단하려면 하나 이상의 지역 일치 조건을 만드십시오. 지역 일치 조건은 요청이 시작된 국가를 나열합니다. 나중에 프로세스에서 웹 ACL을 생성할 때 해당 국가의 요청을 허용할지 또는 차단할지 지정합니다.
지역 일치 조건을 다른 AWS WAF Classic 조건 또는 규칙과 함께 사용하여 정교한 필터링을 구축할 수 있습니다. 예를 들어 특정 국가를 차단하지만 해당 국가의 특정 IP 주소는 계속 허용하려는 경우 지역 일치 조건과 IP 일치 조건이 포함된 규칙을 만들 수 있습니다. 해당 국가에서 시작되고 승인된 IP 주소와 일치하지 않는 요청을 차단하도록 규칙을 구성합니다. 다른 예로 특정 국가의 사용자에 대한 리소스의 우선 순위를 지정하려는 경우 두 가지 다른 비율 기반 규칙에 지역 일치 조건을 포함할 수 있습니다. 선호하는 국가의 사용자에 대해 더 높은 비율 제한을 설정하고 다른 모든 사용자에 대해 더 낮은 비율 제한을 설정합니다.
CloudFront 지리적 제한 기능을 사용하여 국가가 콘텐츠에 액세스하지 못하도록 차단하는 경우 해당 국가의 모든 요청이 차단되고 AWS WAF Classic으로 전달되지 않습니다. 따라서 지역 및 기타 AWS WAF Classic 조건을 기반으로 요청을 허용하거나 차단하려는 경우 CloudFront 지역 제한 기능을 사용하면 안 됩니다. 대신 AWS WAF Classic 지역 일치 조건을 사용해야 합니다.
회사에 웹 애플리케이션을 호스팅하는 EC2 인스턴스가 있습니다. 앞으로 몇 개월 동안 사용자 수가 증가할 것으로 예상되므로 수요에 대처하기 위해 AWS 아키텍처에 더 많은 탄력성과 확장성을 추가해야 합니다.
다음 중 주어진 시나리오에 대해 위의 요구 사항을 충족할 수 있는 옵션은 무엇입니까? (2개 선택)
2개의 EC2 인스턴스를 설정하고 Route 53을 사용하여 가중치 기반 라우팅 정책을 기반으로 트래픽을 라우팅합니다.
두 개의 EC2 인스턴스를 설정한 다음 Elastic Load Balancer(ELB) 뒤에 배치합니다.
Elastic Load Balancing(ELB)은 하나 이상의 가용 영역(AZ)에 있는 여러 대상 및 가상 어플라이언스에서 들어오는 애플리케이션 트래픽을 자동으로 분산합니다.
Elastic Load Balancing(ELB)은 4가지 유형의 로드 밸런서를 지원합니다. 애플리케이션 요구 사항에 따라 적절한 로드 밸런서를 선택할 수 있습니다. HTTP 요청을 로드 밸런싱해야 하는 경우 Application Load Balancer(ALB)를 사용하는 것이 좋습니다. 네트워크/전송 프로토콜(4계층 - TCP, UDP) 로드 밸런싱의 경우와 고도의 성능이 요구되거나 대기 시간이 낮아야 하는 애플리케이션의 경우에는 네트워크 로드 밸런서를 사용하는 것이 좋습니다. 애플리케이션이 Amazon Elastic Compute Cloud(Amazon EC2) Classic 네트워크 안에 구축된 경우 Classic Load Balancer를 사용해야 합니다. 서드 파티 가상 어플라이언스를 배포하고 실행해야 하는 경우 Gateway Load Balancer를 사용할 수 있습니다.
Amazon Route 53는 가용성과 확장성이 뛰어난 DNS(도메인 이름 시스템) 웹 서비스입니다. Route 53을 사용하여 세 가지 주요 기능, 즉 도메인 등록, DNS 라우팅, 상태 확인을 조합하여 실행할 수 있습니다.
가중치 기반 라우팅을 사용하면 다수의 리소스를 단일 도메인 이름(example.com) 또는 하위 도메인 이름(acme.example.com)과 연결하고 각 리소스로 라우팅되는 트래픽 비율을 선택할 수 있습니다. 이러한 방식은 로드 밸런싱, 새 버전의 소프트웨어 테스트 등을 비롯한 다양한 목적에 활용될 수 있습니다.
Elastic Load Balancer를 사용하는 것은 애플리케이션에 탄력성을 추가하기 위한 이상적인 솔루션입니다. 또는 가중 라우팅 정책과 같은 Route 53에서 정책을 생성하여 트래픽을 2개 이상의 EC2 인스턴스에 고르게 분배할 수도 있습니다.
회사는 온프레미스 데이터 센터와 함께 S3와 같은 일부 AWS 서비스를 사용하는 하이브리드 클라우드 인프라를 채택하려고 합니다. 이 회사는 온프레미스 데이터 센터와 AWS 간의 전용 전용 연결을 원합니다. 하지만 실패할 경우 회사는 가동 시간을 보장해야 하며 암호화된 연결을 위해 퍼블릭 인터넷을 사용할 의향이 있습니다.
추천 기능은 무엇인가요? (2개 선택)
Site to Site VPN을 백업 연결로 사용
Direct Connect를 기본 연결로 사용
AWS Direct Connect를 사용하면 네트워크와 AWS Direct Connect 위치 중 하나 사이에 전용 네트워크 연결을 설정할 수 있습니다. 업계 표준 802.1q VLAN을 사용하여 이 전용 연결을 여러 가상 인터페이스로 분할할 수 있습니다. AWS Direct Connect에는 인터넷이 포함되지 않습니다. 대신 인트라넷과 Amazon VPC 간에 전용 프라이빗 네트워크 연결을 사용합니다.
AWS Site-to-Site VPN을 사용하면 온프레미스 네트워크 또는 지사 사이트를 Amazon Virtual Private Cloud(Amazon VPC)에 안전하게 연결할 수 있습니다. AWS Site-to-Site VPN 연결을 사용하여 데이터 센터 또는 지사 네트워크를 클라우드로 안전하게 확장할 수 있습니다. VPC VPN 연결은 IPSec을 사용하여 인터넷을 통해 인트라넷과 Amazon VPC 간에 암호화된 네트워크 연결을 설정합니다. VPN 연결은 몇 분 안에 구성할 수 있으며 즉각적인 필요가 있고 대역폭 요구 사항이 낮거나 보통이며 인터넷 기반 연결의 고유한 가변성을 견딜 수 있는 경우에 좋은 솔루션입니다.
기본 연결로서의 Direct Connect는 뛰어난 성능과 보안을 보장합니다(연결이 비공개이므로). 장애 조치 시나리오를 처리하기 위해 암호화된 연결을 제공하는 Site to Site VPN을 사용해야 합니다.
회사의 엔지니어링 팀은 Amazon CloudWatch 경보를 사용하여 손상된 EC2 인스턴스를 자동으로 복구하려고 합니다.
다음 중 이 자동 복구 프로세스와 관련하여 올바른 것은 무엇입니까? (2개 선택)
인스턴스에 퍼블릭 IPv4 주소가 있는 경우 복구 후 퍼블릭 IPv4 주소를 유지합니다.
복구된 인스턴스는 인스턴스 ID, 프라이빗 IP 주소, 탄력적 IP 주소 및 모든 인스턴스 메타데이터를 포함하여 원래 인스턴스와 동일합니다.
시스템 상태 확인 실패 시 인스턴스를 자동으로 복구하려면 인스턴스의 기본 구성을 사용하거나 Amazon CloudWatch 경보를 생성할 수 있습니다. 기본 하드웨어 장애나 복구에 AWS 개입이 필요한 문제로 인해 인스턴스에 연결할 수 없는 경우 해당 인스턴스를 자동으로 복구할 수 있습니다.
복구된 인스턴스는 인스턴스 ID, 프라이빗 IP 주소, 탄력적 IP 주소 및 모든 인스턴스 메타데이터를 포함하여 원본 인스턴스와 동일합니다. 손상된 인스턴스에 퍼블릭 IPv4 주소가 있는 경우 복구 후에도 인스턴스에서 해당 퍼블릭 IPv4 주소를 유지합니다. 손상된 인스턴스가 배치 그룹에 있다면, 복구된 인스턴스는 배치 그룹에서 실행됩니다. 인스턴스 복구 중에 인스턴스를 재부팅할 때 인스턴스가 마이그레이션되고 메모리의 모든 데이터가 손실됩니다.
온라인 뱅킹 플랫폼은 복잡한 애플리케이션이 더 작고 독립적인 서비스로 분해되는 마이크로서비스 아키텍처를 갖도록 재설계되었습니다. 새로운 플랫폼은 애플리케이션 컨테이너가 소규모의 분리된 서비스를 실행하는 데 최적이라는 점을 고려하여 Docker를 사용하고 있습니다. 새로운 솔루션은 서버를 프로비저닝 및 관리할 필요를 없애고, 애플리케이션별로 리소스를 지정하고 비용을 지불할 수 있도록 하며, 설계에 따른 애플리케이션 격리를 통해 보안을 개선해야 합니다.
다음 중 이 새로운 플랫폼을 AWS로 마이그레이션하는 데 가장 적합한 서비스는 무엇입니까?
AWS Fargate
AWS Fargate는 컨테이너에 적합한 서버리스 컴퓨팅 엔진으로, Amazon Elastic Container Service(ECS) 및 Amazon Elastic Kubernetes Service(EKS)와 연동됩니다. AWS Fargate를 사용하면 애플리케이션을 구축하는 데 집중할 수 있습니다. Fargate를 사용하면 서버를 프로비저닝하고 관리할 필요가 없기 때문에 애플리케이션별로 리소스를 지정하고 관련 비용을 지불할 수 있으며, 계획적으로 애플리케이션을 격리하여 보안을 개선할 수 있습니다.
AWS Fargate는 마이크로 아키텍처 애플리케이션, 배치 처리, 기계 학습 애플리케이션, 온프레미스 애플리케이션을 클라우드로 마이그레이션 등을 비롯한 일밙거인 컨테이너 사용 사례를 모두 지원합니다.
회사에서 AWS에서 AI 기반 얼굴 인식 애플리케이션을 구축하고 있으며 S3 버킷에 수백만 개의 이미지를 저장합니다. Solutions Architect는 시스템에 업로드된 모든 이미지가 문제 없이 저장되었는지 확인해야 합니다.
Amazon S3에 객체를 넣을 때 객체가 성공적으로 저장되었다는 올바른 표시는 무엇입니까?
HTTP 200 결과 코드 및 MD5 체크섬.
S3 API 호출을 트리거하고 HTTP 200 결과 코드와 MD5 체크섬을 얻은 경우 성공적인 업로드로 간주됩니다. 업로드에 실패한 경우 S3 API는 오류 코드를 반환합니다.
회사에는 EC2 인스턴스에 설치 되어 있는 데이터베이스의 몇 가지 메트릭을 모니터링한 다음 문제가 있는 경우 운영 팀에 이메일 알림을 보내야 하는 최우선 요구 사항이 있습니다.
이 요구 사항을 충족할 수 있는 AWS 서비스는 무엇입니까? (2개 선택)
Amazon CloudWatch
Amazon Simple Notification Service (SNS)
Amazon CloudWatch는 DevOps 엔지니어, 개발자, 사이트 안정성 엔지니어(SRE), IT 관리자 및 제품 소유자를 위해 구축된 모니터링 및 관찰 서비스입니다. CloudWatch는 애플리케이션을 모니터링하고 시스템 전체 성능 변경에 대응하며 리소스 사용률을 최적화하는 데 필요한 데이터와 실행 가능한 인사이트를 제공합니다. CloudWatch는 모니터링 및 운영 데이터를 로그, 지표 및 이벤트 형태로 수집합니다. 이를 통해 운영 상태를 통합적으로 보고 AWS 및 온프레미스에서 실행되는 AWS 리소스, 애플리케이션 및 서비스를 완벽하게 파악할 수 있습니다. CloudWatch를 사용하여 환경에서 이상 동작을 감지하며, 경보를 설정하고, 로그와 지표를 나란히 시각화하며, 자동화된 작업을 수행하고, 문제를 해결하며, 인사이트를 확보하여 애플리케이션을 원활하게 실행할 수 있습니다.
Amazon Simple Notification Service(Amazon SNS)는 애플리케이션 간(A2A) 및 애플리케이션과 사용자 간(A2P) 통신 모두를 위한 완전관리형 메시징 서비스입니다.
A2A 게시/구독 기능에서는 분산 시스템, 마이크로서비스 및 이벤트 중심의 서버리스 애플리케이션 사이에서 처리량이 높은 푸시 기반의 다대다 메시징을 위한 주제를 제공합니다. Amazon SNS 주제를 사용하여 게시자 시스템은 병렬 처리를 위해 Amazon SQS 대기열, AWS Lambda 함수, HTTPS 엔드포인트 및 Amazon Kinesis Data Firehose를 비롯한 많은 구독자 시스템으로 메시지를 팬아웃할 수 있습니다. A2P 기능을 사용하면 SMS, 모바일 푸시 및 이메일을 통해 대규모로 사용자에게 메시지를 전송할 수 있습니다.
Amazon CloudWatch를 사용하여 데이터베이스를 모니터링한 다음 Amazon SNS를 사용하여 운영 팀에 이메일을 보낼 수 있습니다. EC2 인스턴스를 모니터링하려면 SES(Simple Email Service) 대신 SNS를 사용해야 합니다.
온프레미스 데이터 센터에서 호스팅되는 다중 계층 애플리케이션은 AWS로 마이그레이션될 예정입니다. 애플리케이션에는 애플리케이션에서 메시징 코드를 다시 작성하지 않고 마이그레이션해야 하는 업계 표준 메시징 API 및 프로토콜을 사용하는 메시지 브로커 서비스가 있습니다.
다음 중 메시징 서비스를 AWS로 이전하는 데 사용해야 하는 가장 적합한 서비스는 무엇입니까?
Amazon MQ
Amazon MQ는 클라우드에서 메시지 브로커를 쉽게 설정하고 운영할 수 있도록 지원하는 Apache ActiveMQ 및 RabbitMQ용 관리형 메시지 브로커 서비스입니다. ActiveMQ 및 RabbitMQ 콘솔과 메시징용 업계 표준 API 및 프로토콜(JMS, NMS, AMQP 1.0 및 0.9.1, STOMP, MQTT, WebSocket 등)에 직접 액세스할 수 있습니다. 애플리케이션의 메시징 코드를 다시 작성할 필요가 없으므로 이러한 표준을 사용하는 메시지 브로커에서 Amazon MQ로 손쉽게 이전할 수 있습니다.
Amazon MQ는 누가 사용하면 좋습니까?
Amazon MQ는 온프레미스든 클라우드든 관계없이 메시지 브로커 관리를 담당하며, 애플리케이션의 메시징 코드를 다시 작성하지 않고 완전 관리형 클라우드 서비스로 이전하길 원하는 엔터프라이즈 IT 전문가, 개발자 및 아키텍트가 사용하면 좋습니다.
Amazon MQ, Amazon SQS, Amazon SNS는 스타트업부터 기업까지 누구에게나 적합한 메시징 서비스입니다. 기존 애플리케이션에서 메시징을 사용 중이고 메시징 서비스를 클라우드로 빠르고 쉽게 이동하려는 경우 Amazon MQ를 고려하는 것이 좋습니다. 업계 표준 API 및 프로토콜을 지원하므로 애플리케이션에서 메시징 코드를 다시 작성하지 않고도 표준 기반 메시지 브로커에서 Amazon MQ로 전환할 수 있습니다.
클라우드에서 완전히 새로운 애플리케이션을 구축하는 경우 Amazon SQS 및 Amazon SNS를 고려하는 것이 좋습니다. Amazon SQS 및 SNS는 거의 무한대로 확장되고 간단하고 사용하기 쉬운 API를 제공하는 경량의 완전 관리형 메시지 대기열 및 주제 서비스입니다. Amazon SQS 및 SNS를 사용하여 마이크로서비스, 분산 시스템, 서버리스 애플리케이션을 분리 및 확장하고 안정성을 개선할 수 있습니다.
Solutions Architect는 50TB의 온프레미스 데이터를 Amazon S3로 전송해야 하는 회사를 위한 전략을 수립하고 있습니다. 이 회사는 데이터 센터와 AWS 간의 네트워크 전송 속도가 느려 데이터 마이그레이션에 병목 현상이 발생합니다.
다음 중 Solutions Architect가 구현해야 하는 것은 무엇입니까?
AWS Snowball Edge 디바이스를 사용하여 Amazon S3로 가져오기 작업을 요청합니다.
AWS Snowball은 AWS 컴퓨팅 및 스토리지 기능을 엣지 환경으로 가져오고 AWS와 데이터를 주고 받을 수 있도록, 안전하고 견고한 디바이스를 제공하는 서비스입니다. 이 견고한 디바이스를 보통 AWS Snowball 또는 AWS Snowball Edge 디바이스라고 합니다. 이전에는 이러한 디바이스의 초기 하드웨어 버전을 AWS Snowball이라고 했으며 해당 모델은 이제 업데이트된 하드웨어로 대체되었습니다. 이제 AWS Snowball 서비스는 온보드 컴퓨팅 기능과 스토리지를 모두 갖춘 Snowball Edge 디바이스를 사용합니다.
Snowball Edge를 연결하고 활성화한 후에는 디바이스에서 사용할 수 있는 S3 호환 엔드포인트 또는 NFS 파일 인터페이스를 통해 로컬 소스의 데이터를 디바이스로 전송할 수 있습니다. 또한 Snowball 클라이언트를 사용하여 데이터를 복사할 수도 있습니다
다음 AWS 서비스 중 소스에서 클릭스트림 이벤트를 캡처한 다음 다운스트림 애플리케이션에 데이터 스트림의 동시 피드를 제공하는 고가용성 내결함성 솔루션은 무엇입니까?
AWS Kinesis Data Streams
Amazon Kinesis Data Streams를 사용하면 특수 요구에 맞춰 스트리밍 데이터를 처리 또는 분석하는 사용자 지정 애플리케이션을 구축할 수 있습니다. 수십 만개의 소스에서 클릭 스트림, 애플리케이션 로그, 소셜 미디어와 같은 다양한 유형의 데이터를 Kinesis 데이터 스트림에 추가할 수 있습니다. 그러면 몇 초 안에 애플리케이션에서 스트림의 해당 데이터를 읽고 처리할 수 있습니다.
Amazon Kinesis Data Streams는 데이터 처리량 수준에서 데이터를 스트리밍하는 데 필요한 인프라, 스토리지, 네트워킹, 구성을 관리합니다. 하드웨어, 소프트웨어는 물론 데이터 스트림을 위한 기타 서비스의 프로비저닝, 배포 혹은 지속적인 유지 관리 등을 걱정할 필요가 없습니다. 또한, Kinesis Data Streams는 3곳의 가용 영역에 데이터를 동기적으로 복제하여 높은 가용성과 데이터 내구성을 제공합니다. 기본적으로 Kinesis Data Streams는 용량을 자동으로 조정하므로 용량을 프로비저닝하고 관리할 필요가 없습니다. 자체적으로 처리량을 프로비저닝하고 관리하려는 경우 프로비저닝된 모드를 선택할 수 있습니다.
Kinesis Data Streams는 데이터를 데이터 생산자로부터 빠르게 이동한 다음 지속적으로 데이터를 처리하는 데 유용합니다. 즉, 데이터 저장소로 전송하기 전에 데이터를 변환하거나, 실시간 지표 및 분석을 실행하거나, 추가 처리를 위해 더 복잡한 데이터 스트림을 파생하는 것을 의미합니다.
다음은 Kinesis Data Streams 사용에 대한 일반적인 시나리오입니다.
가속화된 로그 및 데이터 피드 입력: 데이터 일괄 처리를 기다리는 대신 데이터 생산자가 데이터가 생성되는 즉시 Kinesis 데이터 스트림으로 데이터를 푸시하도록 하여 생산자 실패 시 데이터 손실을 방지할 수 있습니다. 예를 들어, 시스템 및 애플리케이션 로그는 지속적으로 데이터 스트림에 추가되며 몇 초 내에 처리에 사용할 수 있습니다.
실시간 지표 및 보고: 실시간으로 Kinesis 데이터 스트림 데이터에서 지표를 추출하고 보고서를 생성할 수 있습니다. 예를 들어 Amazon Kinesis 애플리케이션은 데이터 배치를 수신할 때까지 기다리는 대신 데이터가 스트리밍되는 대로 시스템 및 애플리케이션 로그에 대한 지표 및 보고 작업을 수행할 수 있습니다.
실시간 데이터 분석: Kinesis Data Streams를 사용하여 실시간 데이터 분석을 실행할 수 있습니다. 예를 들어 Kinesis 데이터 스트림에 클릭스트림을 추가하고 Kinesis 애플리케이션이 실시간으로 분석을 실행하도록 할 수 있으므로 몇 시간 또는 며칠이 아닌 몇 분 만에 데이터에서 인사이트를 얻을 수 있습니다.
로그 및 이벤트 데이터 수집: 서버, 데스크톱, 휴대기기와 같은 소스에서 로그 및 이벤트 데이터를 수집합니다. 그런 다음 Amazon Lambda 또는 Kinesis Data Analytics를 사용하여 애플리케이션을 구축하여 지속적으로 데이터를 처리하고, 지표를 생성하고, 라이브 대시보드를 구동하고, 집계된 데이터를 Amazon Simple Storage Service(S3)와 같은 저장소로 내보낼 수 있습니다.
이벤트 기반 애플리케이션 구동: AWS Lambda와 빠르게 페어링하여 규모에 상관없이 환경의 이벤트 기반 애플리케이션 내에서 즉각적인 발생에 대응하거나 조정합니다.
1분마다 금융 데이터를 자주 처리하고 저장하는 거래 플랫폼은 온프레미스 데이터 센터에서 호스팅되며 Oracle 데이터베이스를 사용합니다. 최근 데이터 센터의 냉각 문제로 인해 이 회사는 애플리케이션 성능을 개선하기 위해 인프라를 AWS로 긴급 마이그레이션해야 합니다. Solutions Architect는 데이터베이스가 적절하게 마이그레이션되고 향후 데이터베이스 서버 오류가 발생할 경우에도 계속 사용할 수 있도록 해야 할 책임이 있습니다.
다음 중 요구 사항을 충족하는 데 가장 적합한 솔루션은 무엇입니까?
다중 AZ 배포가 포함된 RDS에서 Oracle 데이터베이스를 생성합니다.
Amazon RDS 다중 AZ 배포는 데이터베이스(DB) 인스턴스에 대한 향상된 가용성과 내구성을 제공하므로 프로덕션 데이터베이스 워크로드에 적합합니다. 다중 AZ DB 인스턴스를 프로비저닝하면 Amazon RDS가 자동으로 기본 DB 인스턴스를 생성하고 데이터를 다른 가용 영역(AZ)의 대기 인스턴스에 동기식으로 복제합니다. 각 AZ는 물리적으로 별개의 독립적인 인프라에서 실행되며 매우 안정적으로 설계되었습니다.
다중 AZ 배포에는 대기 DB 인스턴스가 하나 또는 두 개 있을 수 있습니다. 배포에 하나의 대기 DB 인스턴스가 있는 경우를 다중 AZ DB 인스턴스 배포라고 합니다. 다중 AZ DB 인스턴스 배포에는 장애 조치 지원을 제공하지만, 읽기 트래픽은 처리하지 않는 대기 DB 인스턴스가 하나 있습니다. 배포에 두 개의 대기 DB 인스턴스가 있는 경우를 다중 AZ DB 클러스터 배포라고 합니다. 다중 AZ DB 클러스터 배포에는 장애 조치 지원을 제공하고 읽기 트래픽도 처리할 수 있는 대기 DB 인스턴스가 있습니다.
1. 대기가 1개인 Amazon RDS 다중 AZ
Amazon RDS 다중 AZ 배포에서 Amazon RDS는 자동으로 프라이머리 데이터베이스 DB 인스턴스를 생성하고 동시에 다른 AZ의 인스턴스에 데이터를 복제합니다. 장애를 감지하면 Amazon RDS는 수동 개입 없이 자동으로 대기 인스턴스로 장애 조치합니다.
2. 읽기 가능한 대기가 2개인 Amazon RDS 다중 AZ
읽기 가능한 대기가 2개인 Amazon RDS 다중 AZ를 사용하여 3개의 AZ에서 고가용성, 내구성 MySQL 또는 PostgreSQL 데이터베이스를 배포합니다. 일반적으로 35초 이내에 자동으로 장애 조치되고, 대기가 1개인 Amazon RDS 다중 AZ 대비 트랜잭션 커밋 지연 시간이 최대 2배 더 빠르며, 추가 읽기 용량이 있고, AWS Graviton2 또는 인텔 기반 인스턴스를 컴퓨팅에 선택할 수 있습니다.
회사가 AWS에 클라우드 인프라를 구축할 계획입니다. 계획에서는 3년 동안 지속적으로 실행해야 하는 두 개의 EC2 인스턴스를 배포해야 한다고 논의했습니다. EC2 인스턴스의 CPU 사용률도 안정적이고 예측 가능합니다.
이 시나리오에 가장 적합한 가장 비용 효율적인 Amazon EC2 요금 유형은 무엇입니까?
예약 인스턴스
예약 인스턴스는 온디맨드 인스턴스 요금에 비해 상당한 할인(최대 75%)을 제공합니다. 또한 예약 인스턴스가 특정 가용 영역에 할당되면 용량 예약을 제공하므로 필요할 때 인스턴스를 시작할 수 있다는 확신을 가질 수 있습니다.
안정적인 상태 또는 예측 가능한 사용량이 있는 애플리케이션의 경우 예약 인스턴스는 온디맨드 인스턴스를 사용하는 것에 비해 상당한 비용 절감 효과를 제공할 수 있습니다.
예약 인스턴스는 다음에 권장됩니다.
- 안정적인 사용이 가능한 애플리케이션
- 예약된 용량이 필요할 수 있는 애플리케이션
- 총 컴퓨팅 비용을 줄이기 위해 1년 또는 3년 동안 EC2를 사용하기로 약정할 수 있는 고객
새로 고용된 Solutions Architect는 AWS에서 회사의 클라우드 아키텍처에 사용되는 CloudFormation 템플릿 집합을 관리하도록 할당됩니다. Solutions Architect는 템플릿에 액세스하고 S3 버킷에 대해 구성된 IAM 정책을 분석하려고 했습니다.
- "Version": "2012-10-17",
- "Statement": [
- {
- "Effect": "Allow",
- "Action": [
- "s3:Get*",
- "s3:List*"
- ],
- "Resource": "*"
- },
- {
- "Effect": "Allow",
- "Action": "s3:PutObject",
- "Resource": "arn:aws:s3:::buw/*"
- }
- ]
- }
위의 IAM 정책은 무엇을 허용합니까? (2개 선택)
이 IAM 정책이 있는 IAM 사용자는 buw S3 버킷에 객체를 읽고 쓸 수 있습니다.
이 IAM 정책이 있는 IAM 사용자는 계정이 소유한 모든 S3 버킷에서 객체를 읽을 수 있습니다.
AWS Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다. IAM을 사용하여 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어합니다.
AWS 계정을 생성할 때는 해당 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 로그인 ID로 시작합니다. 이 자격 증명은 AWS 계정 루트 사용자라고 하며, 계정을 생성할 때 사용한 이메일 주소와 암호로 로그인하여 액세스합니다. 일상적인 작업에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 보안 인증 정보를 보호하고 루트 사용자만 수행할 수 있는 작업을 수행하는 데 사용합니다.
대부분의 정책은 AWS에 JSON 문서로서 저장됩니다. 자격 증명 기반 정책, 경계를 설정할 수 있는 정책은 사용자 또는 역할에 연결할 수 있는 JSON 정책 문서입니다. 리소스 기반 정책은 리소스에 연결하는 JSON 정책 문서입니다. SCP는 AWS Organizations 조직 단위(OU)에 연결하는 제한된 구문이 있는 JSON 정책 문서입니다. ACL은 리소스에도 연결되지만 다른 구문을 사용해야 합니다. 세션 정책은 역할 또는 페더레이션 사용자 세션을 수임할 때 제공하는 JSON 정책입니다.
JSON 정책 문서 구조
JSON 정책 문서의 정보는 일련의 요소를 포함하고 있습니다.
- Version - 사용하고자 하는 정책 언어의 버전을 지정합니다. 가장 좋은 방법은 최신 2012-10-17 버전을 사용하는 것입니다.
- Statement - 이 주요 정책 요소를 다음 요소의 컨테이너로 사용합니다. 정책에 설명문 둘 이상을 포함할 수 있습니다.
- Sid(선택 사항) - 선택 설명문 ID를 포함하여 설명문들을 구분합니다.
- Effect - Allow 또는 Deny를 사용하여 정책에서 액세스를 허용하는지 또는 거부하는지 여부를 설명합니다.
- Principal(일부 상황에서만 필요) - 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시해야 합니다. 사용자 또는 역할에 연결할 IAM 권한 정책을 생성하면 이 요소를 포함할 수 없습니다. 보안 주체는 사용자 또는 역할을 의미합니다.
- Action - 정책이 허용하거나 거부하는 작업 목록을 포함합니다.
- Resource(일부 상황에서만 필요) - IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정해야 합니다. 리소스 기반 정책을 생성하는 경우 이 요소는 선택 사항입니다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스입니다.
- Condition(선택 사항) - 정책에서 권한을 부여하는 상황을 지정합니다.
제공된 IAM 정책에 따라 사용자는 buw s3 버킷의 모든 객체를 가져오고, 쓰고, 읽을 수 있습니다. s3:PutObject는 기본적으로 데이터를 저장하기 위해 S3 버킷에 PUT 객체 요청을 제출할 수 있음을 의미합니다.
