Practice Test #8

SQS + Auto Scaling 워커는 견고한 분리 패턴이지만, scheduled scaling은 변동성이 큰 워크로드에 대한 "최대 복원력 및 자동 조정"이 아닙니다. 이는 예측 및 과거 패턴에 의존하므로 예상치 못한 급증이나 월말 타이밍/볼륨의 변화를 놓칠 수 있습니다. 또한 활동이 적은 기간 동안 초과 용량을 계속 실행하여 대기열 깊이 기반 조정에 비해 비용과 운영 튜닝 노력을 증가시킬 수 있습니다.

코디네이터 서버를 유지하면 단일 장애점과 조정 병목 현상이 유지되어 복원력이 저하됩니다. CloudTrail은 작업 분배 이벤트를 캡처하거나 라우팅하기 위한 것이 아니라 API 호출을 감사하기 위한 것입니다. 코디네이터 CPU를 기반으로 한 조정은 백로그나 처리량과 상관관계가 없을 수 있는 간접적인 지표이며, 급증 시 지연되거나 불안정한 조정 동작으로 이어질 수 있습니다.

EventBridge는 이벤트를 라우팅할 수 있지만, 배치 워크로드에 대해 SQS가 수행하는 방식의 내구성 있는 작업 버퍼링 및 백프레셔의 필요성을 대체하지는 않습니다. 코디네이터 서버를 유지하면 여전히 단일 장애점과 운영 오버헤드가 발생합니다. 워커의 CPU 기반 조정은 CPU가 대기 중인 작업(예: I/O 대기)을 반영하지 않을 수 있으므로 대기열 깊이 조정보다 덜 정확하여 과소/과대 조정을 유발할 수 있습니다.

DynamoDB Streams는 항목 수준의 변경 사항을 내보낼 수 있지만 DynamoDB는 거의 실시간으로 광범위하게 공유되어야 하는 수백만 개의 동시 이벤트를 위한 최상의 기본 수집 버스가 아닙니다. 또한 DynamoDB는 쓰기 시 PII를 제거/마스킹하는 네이티브 "규칙" 메커니즘을 제공하지 않습니다. 애플리케이션 로직이나 Lambda 기반 파이프라인이 필요합니다. 이 옵션은 또한 수집을 데이터베이스에 직접 결합하여 여러 분석 소비자를 위한 유연성을 줄입니다.

Kinesis Data Firehose는 선택적 Lambda 변환을 사용하여 스트리밍 데이터를 스토리지/분석 대상(일반적으로 S3, Redshift, OpenSearch)으로 로드하는 데 최적화되어 있습니다. 그러나 Firehose는 여러 독립적인 거의 실시간 소비자를 위해 설계되지 않았습니다. 공유 이벤트 스트림으로 작동하기보다는 대상으로 전송합니다. 또한 DynamoDB는 일반적/네이티브 Firehose 대상이 아니므로 이 아키텍처는 명시된 DynamoDB 요구 사항과 일치하지 않습니다.

일괄 처리된 이벤트를 S3 파일로 저장하고 Lambda로 처리하는 것은 엔드투엔드 지연 시간을 증가시키고 "거의 실시간" 요구 사항에 덜 적합한 배치 지향 패턴입니다. 또한 파일 크기 조정, 파티셔닝 및 재처리와 관련된 운영 복잡성을 추가합니다. S3는 내구성 있는 데이터 레이크에 탁월하지만 여러 분석 애플리케이션으로의 실시간 이벤트 팬아웃을 위한 올바른 기본 메커니즘은 아닙니다.

Amazon S3는 뛰어난 내구성과 가용성을 제공하지만 NFS/POSIX 파일 시스템이 아닌 API를 통해 액세스되는 객체 스토리지입니다. S3 access points를 사용하더라도 워크스테이션에는 다른 도구(SDK/CLI) 또는 파일 게이트웨이/마운트 솔루션이 필요하며 파일 잠금/이름 바꾸기 의미 체계가 다릅니다. 이는 워크플로 변경 없이 현재 공유 파일 액세스 패턴을 유지해야 한다는 요구 사항을 위반합니다.

AWS Storage Gateway File Gateway는 주로 온프레미스 클라이언트가 캐시된 로컬 성능과 백업 스토어로서의 S3를 사용하여 NFS/SMB 액세스가 필요한 하이브리드 사용 사례를 위한 것입니다. "EC2 NFS 서버"에 File Gateway를 마운트하면 복잡성이 추가되고 여러 편집 워크스테이션을 위한 깔끔하고 고가용성인 공유 파일 시스템을 본질적으로 제공하지 않습니다. 또한 EFS처럼 AWS 내에서 HA 공유 스토리지의 필요성을 직접적으로 대체하지 않습니다.

Amazon FSx for Lustre는 고성능 병렬 워크로드(HPC, 대규모 렌더링/컴퓨팅)에 최적화되어 있으며 S3와 통합할 수 있지만 "NFS 워크플로 유지" 및 일반 공유 스토리지에 가장 간단하게 일치하는 것은 아닙니다. 옵션에서 언급한 "cross-AZ replication"은 오해의 소지가 있습니다. FSx for Lustre HA는 일반적으로 이러한 방식으로 cross-AZ replication으로 구성되지 않습니다. EFS에 비해 과도할 수 있으며 운영/설계 복잡성을 추가합니다.

미사용/전송 중 EFS 암호화 및 보안 그룹은 네트워크 가로채기 및 스토리지 미디어 노출에 대한 강력한 보호를 제공하지만, 파일 시스템을 마운트하거나 액세스 권한이 있는 인스턴스를 관리할 수 있는 권한 있는 사용자로부터 기밀성을 보장하지는 않습니다. OS 수준 액세스 권한이 있는 관리자는 마운트된 후 일반 텍스트로 파일을 읽을 수 있습니다. 또한 EFS는 파일 시스템이므로 쿼리/트랜잭션 의미론이 필요한 구조화된 의료/처방전 데이터의 기본 기록 시스템으로는 이상적이지 않습니다.

DynamoDB SSE-KMS는 미사용 데이터를 암호화하지만 DynamoDB는 승인된 읽기를 위해 데이터를 해독합니다. 테이블(또는 읽기 권한이 있는 역할)에 대한 액세스가 여전히 일반 텍스트를 검색할 수 있으므로 이는 일반적으로 합법적인 액세스 권한이 있는 관리자/운영자로부터 데이터를 기밀로 유지하라는 요구 사항을 충족하지 못합니다. IAM 제한이 도움이 되지만 질문은 명시적으로 관리자로부터의 보호를 요구하며, 이는 일반적으로 서버 측 암호화만이 아닌 클라이언트 측/필드 수준 암호화를 의미합니다.

FSx for Lustre는 고성능 컴퓨팅 워크로드(예: HPC, ML, 미디어 처리)에 최적화되어 있으며 환자 기록/처방전을 저장하고 쿼리하는 일반적인 선택이 아닙니다. 암호화 및 AD 통합은 미사용 보호 및 인증을 해결하지만, 권한 있는 관리자가 파일 시스템 액세스 권한을 얻은 후 일반 텍스트에 액세스하는 것을 본질적으로 방지하지는 않습니다. 또한 데이터베이스와 같은 액세스 패턴 및 세분화된 필드 기밀성에 대한 필요성을 직접 해결하지 않습니다.

Network Access Analyzer는 Amazon VPC 환경 내부의 network reachability를 평가합니다. route tables, security groups, network ACLs, gateways와 같은 구성 요소를 기반으로 paths를 분석합니다. 이는 IAM identity-based permissions를 검사하지 않으며 IAM user가 과도한 privileges를 가지고 있는지 판단하지도 않습니다. 따라서 IAM user permissions를 감사해야 한다는 요구 사항과는 관련이 없습니다.

CloudWatch alarm은 일반적으로 CloudTrail logs와 metric filters를 사용하여 특정 events가 발생할 때 administrators에게 알릴 수 있습니다. 그러나 이 접근 방식은 users가 실제로 수행한 actions만 보여줄 뿐, 그들에게 부여된 전체 permissions 집합은 보여주지 않습니다. 사용자가 해당 permissions를 한 번도 사용하지 않았더라도 여전히 과도한 권한을 가질 수 있습니다. 또한 이 옵션은 alarms, filters, event patterns를 설계하고 유지해야 하므로 더 많은 운영 오버헤드를 발생시킵니다.

Amazon Inspector는 Amazon EC2, Amazon ECR의 container images, AWS Lambda functions와 같은 workloads를 위한 vulnerability management 서비스입니다. 이는 IAM user permissions를 검토하여 identities가 과도한 privileges를 가지고 있는지 판단하지 않습니다. Inspector findings는 IAM authorization 설계보다는 software vulnerabilities와 exposure issues에 초점을 맞춥니다. 따라서 여러 accounts 전반에서 IAM permissions를 감사해야 한다는 요구 사항을 충족하지 않습니다.