Practice Test #6

오답입니다. AWS X-Ray는 분산 추적(지연 시간 분해, service map, traces/segments)에 초점을 둡니다. 메모리 사용률, swap 사용량, filesystem 사용률, 또는 1분 단위 disk I/O 같은 OS 수준 메트릭을 수집하지 않습니다. 또한 X-Ray는 cacheHitRate 및 queueDepth 같은 임의의 커스텀 메트릭을 CloudWatch로 수집하는 표준 메커니즘도 아닙니다.

오답입니다. 애플리케이션을 수정하여 AWS SDK로 메트릭을 게시하는 방식은 커스텀 애플리케이션 메트릭에는 가능할 수 있지만, 코드 변경이 필요하며 메모리, swap, filesystem 사용률 같은 OS 수준 메트릭을 본질적으로 제공하지 않습니다. 이러한 OS 메트릭을 수집하려면 여전히 agent 또는 추가 호스트 계측이 필요합니다. 이 접근은 CloudWatch agent의 내장 기능을 사용하는 것에 비해 개발 노력과 리스크를 증가시킵니다.

오답입니다. AWS CloudTrail은 거버넌스, 컴플라이언스, 감사(auditing)를 위해 AWS API 호출(누가, 무엇을, 언제, 어디서 했는지)을 기록합니다. 인스턴스별 OS 성능 메트릭이나 커스텀 애플리케이션 메트릭을 캡처하지 않습니다. CloudTrail 로그는 보안 조사 및 변경 추적에는 유용하지만, CPU/메모리/disk 사용률 기반의 적정 규모 조정이나 cacheHitRate 및 queueDepth 같은 애플리케이션 수준 KPI 모니터링에는 적합하지 않습니다.

Rolling 배포는 인스턴스를 배치 단위로 업데이트하여, 일부 용량은 트래픽을 처리하는 동안 나머지를 업데이트합니다. 이는 다운타임을 줄일 수 있지만, 고정된 평가 구간 동안 두 버전 간 정확하고 제어된 비율 분할(25%/75%)을 제공하지는 않습니다. Rolling 중에는 배치 진행 상황에 따라 업데이트된/미업데이트 인스턴스가 섞여 트래픽을 받게 되며, 안정적인 카나리 비율이 아닙니다.

In-place 배포는 기존 인스턴스를 직접 업데이트합니다(한 번에 모두 또는 일시적으로 용량을 줄일 수 있는 방식). 이 접근은 특히 지연 시간에 민감한 API에서 짧은 중단이나 성능 저하를 유발할 수 있으며, 버전 간 25%/75% 트래픽 분할을 제어하는 기능을 제공하지 않습니다. 일반적으로 프로덕션 릴리스에서는 immutable 또는 traffic-splitting보다 안전성이 떨어집니다.

Immutable 배포는 새 버전으로 새로운 인스턴스 세트를 생성하고, health를 검증한 다음 전환하여 배포 리스크를 크게 줄이고 거의 제로 다운타임을 달성할 수 있습니다. 그러나 immutable은 주로 올-오어-낫싱 컷오버 모델이며, 시간 제한이 있는 평가 구간 동안 정확한 25%/75% 요청 라우팅 분할을 기본적으로 제공하지는 않습니다. 해당 요구 사항은 traffic-splitting에 직접적으로 매핑됩니다.

세션 데이터와 애플리케이션 데이터를 모두 EC2의 MySQL에 저장하는 것은 적합하지 않습니다. 세션은 변경이 잦아 대량의 읽기/쓰기 트래픽, 잠금, 연결 오버헤드를 유발할 수 있으며, 스파이크 동안 지연 시간을 악화시킬 수 있습니다. 또한 EC2에서 MySQL을 운영하면 운영 부담(패치, 백업, HA 설계)이 증가하고 Multi-AZ failover가 본질적으로 제공되지 않습니다. 이 옵션은 stateless 확장을 효과적으로 해결하지 못합니다.

세션 데이터와 애플리케이션 데이터를 모두 Memcached에 저장하는 것은 위험합니다. Memcached는 영속성이 없는 인메모리 캐시이며 시스템 오브 레코드가 아닙니다. 캐시 노드 장애나 eviction이 발생하면 데이터 손실이 발생할 수 있습니다. 일부 애플리케이션 읽기를 캐싱하면 성능에 도움이 될 수 있지만, 기본 데이터베이스는 내구성 있는 저장소(예: RDS/Aurora)로 유지되어야 합니다. 이 옵션은 캐싱과 내구성 저장을 혼동하고 있으며, 중요한 시험 플랫폼 데이터에는 적절하지 않습니다.

EC2 instance store는 인스턴스 로컬의 ephemeral 스토리지로, 인스턴스 간에 공유되지 않으며 인스턴스가 stop 또는 terminate되면 데이터가 손실됩니다. Auto Scaling 환경에서는 인스턴스가 자주 교체되므로, 세션 데이터가 손실되어 사용자가 로그아웃되거나 일관되지 않은 동작을 볼 수 있습니다(또는 sticky sessions를 강제해야 하는데, 이는 확장성을 저하시킵니다). 이 옵션은 인스턴스 간 세션 공유 문제를 해결하지 못하며 운영적으로 취약합니다.

이 접근 방식은 추가 API를 도입하고 원래 Lambda가 다른 endpoint를 호출하도록 수정해야 합니다. 결합도가 증가하고 지연 및 장애 지점이 늘어나며, 모든 DynamoDB 업데이트를 자동으로 캡처하지 못합니다(특히 향후 파트너 전용 Lambda가 DynamoDB에 직접 write하는 경우). 또한 DynamoDB Streams를 사용하는 것보다 개발 노력이 더 큽니다. 추가 API Gateway/Lambda 통합 로직을 유지해야 하기 때문입니다.

Kinesis Data Streams만으로는 데이터를 S3로 직접 전달하지 못하며, 일반적으로 Kinesis Data Firehose(또는 consumer 애플리케이션)를 사용해 S3에 영구 저장합니다. 더 중요한 점은 ingest Lambda(들)를 수정하여 Kinesis로 publish해야 한다는 것이고, 전용 Lambda로 온보딩되는 새 파트너가 늘어날수록 각 producer를 업데이트하고 관리해야 합니다. 이는 DynamoDB 계층에서 변경을 캡처하는 것보다 더 많은 작업입니다.

ingest Lambda에서 SNS로 publish하려면 producer(들)의 코드 변경이 필요하며, 향후 파트너 전용 Lambda도 완전한 커버리지를 위해 SNS publish 로직을 구현해야 합니다. SNS는 fanout notification 서비스이지 database change capture 메커니즘이 아니므로, 다른 경로를 통해 발생하는 업데이트를 자동으로 캡처하지 못합니다. 또한 메시지 크기/포맷 고려사항과 추가 운영 복잡성을 유발합니다.

Lambda-backed custom resource로 비밀번호를 생성할 수는 있지만, custom resource 응답 데이터로 반환하면 노출 위험이 증가합니다(구현에 따라 CloudFormation 이벤트에 나타나거나 스택/리소스 검사로 조회 가능할 수 있음). 또한 Lambda 코드 작성 및 유지보수, IAM 권한, 업데이트/삭제를 안전하게 처리하는 작업이 필요합니다. 네이티브 Secrets Manager 생성에 비해 최소 개발 노력에 해당하지 않습니다.

CodeBuild에서 aws secretsmanager get-random-password로 비밀번호를 생성하는 것은 CloudFormation 스택 생성 외부에서 발생하므로, 스택 생성의 일부로 생성되어야 한다는 요구 사항을 위반합니다. (NoEcho를 사용하더라도) 파라미터로 전달하는 과정에서 CI/CD 로그, 환경 변수, 또는 디버깅 출력으로 유출될 위험이 있습니다. NoEcho는 CloudFormation에서의 표시를 줄이지만, 파이프라인 전반에서 평문으로 절대 나타나지 않는다는 보장을 제공하지 않습니다.

이 접근 방식은 custom resource와 Secrets Manager를 함께 추가하므로 불필요하게 더 복잡합니다. 비밀번호를 Secrets Manager에 저장하고 dynamic reference를 사용하는 패턴은 좋지만, Secrets Manager가 규격에 맞는 비밀번호를 네이티브로 생성할 수 있으므로 custom Lambda 생성은 중복입니다. 개발 노력과 운영 표면적(Lambda 코드, 권한, 재시도, 멱등성)을 증가시킵니다.

Step Functions는 Wait state와 retry 로직을 추가할 수 있지만, 429를 모니터링하는 것은 reactive 방식입니다. 즉, 파트너의 제한을 이미 초과한 상태입니다. 또한 추가적인 state 관리 없이 8,000/일 quota를 자연스럽게 처리하거나 여러 날에 걸친 내구성 있는 backlog를 제공하지도 못합니다. Step Functions는 오케스트레이션에는 유용하지만, 분/일 경계에서 지속적인 rate shaping을 위한 MOST 운영 효율적인 메커니즘은 아닙니다.

CloudWatch Logs metric filter와 alarm은 관측 및 알림을 위한 것이지, 정밀한 실시간 제어를 위한 것이 아닙니다. alarm은 기간 단위로 평가되어 지연이 발생할 수 있으며, 실행 중인 Lambda invocation을 직접 “중지”할 수도 없습니다(Lambda에는 CloudWatch를 통한 native kill switch가 없음). 초과를 감지하더라도 추가 호출을 방지하기 위한 throttling 메커니즘이 여전히 필요하므로 운영적으로 비효율적이고 신뢰하기 어렵습니다.

Kinesis Data Firehose는 S3, Redshift, OpenSearch 같은 대상으로 streaming 데이터를 버퍼링하고 전달하도록 설계되었습니다. outbound REST API 호출을 오케스트레이션하거나 외부 rate limit을 강제하지 않습니다. 요청을 S3에 기록하고 S3 event로 Lambda를 트리거하는 방식은 불필요한 지연과 복잡성을 추가하며, 분당 75 및 하루 8,000 미만으로 요청을 유지하는 깔끔하고 결정적인 방법도 제공하지 못합니다.

Lambda 함수가 NAT/egress 없이 VPC 내부에서 실행되고 SNS에 대한 private 연결이 필요하다면 SNS용 interface VPC endpoint가 필요할 수 있습니다. 그러나 여기의 증상은 AccessDeniedException(HTTP 403)로, 요청이 SNS에 도달했고 인증되었지만 권한이 없음을 나타냅니다. VPC endpoint는 누락된 sns:Publish 권한을 해결하지 못하며, IAM 권한 부여가 아니라 네트워크 경로를 다룹니다.

Lambda 함수는 개발자의 장기 credentials를 사용하면 안 됩니다. 코드에 credentials가 지정되지 않으면 AWS SDK는 Lambda execution role의 임시 credentials를 자동으로 사용합니다. 개발자의 IAM user 권한을 변경해도 AWS에서 실행되는 Lambda 함수의 런타임 ID에는 영향을 주지 않습니다. 또한 이 옵션은 credential 관리 및 최소 권한에 관한 best practice를 위반합니다.

Lambda 함수에 대한 resource-based policy는 누가 함수를 invoke할 수 있는지(예: SNS, EventBridge 또는 다른 계정이 invoke하도록 허용)를 제어합니다. 이는 함수가 SNS를 호출할 수 있는 권한을 부여하지 않습니다. Lambda에서의 아웃바운드 호출 권한은 Lambda execution role의 identity-based policies에 의해 관리되므로, Lambda resource policy를 추가해도 sns:Publish AccessDenied는 해결되지 않습니다.

오답입니다. Gateway Load Balancer는 GENEVE를 사용해 서드파티 가상 네트워크 어플라이언스(방화벽, IDS/IPS)를 투명하게 배포하고 확장하도록 설계되었습니다. Lambda 함수를 HTTP 엔드포인트로 노출하기 위한 용도가 아닙니다. GWLB를 사용하면 불필요한 네트워크 복잡성이 추가되며, Lambda 기반 엔드포인트로 HTTPS POST 요청을 수락해야 한다는 요구 사항을 직접 충족하지 못합니다.

“추가 구성이 최소”라는 관점에서 오답입니다. NLB는 Lambda를 대상으로 지정할 수 있지만 Layer 4에서 동작하며 주로 TCP/UDP/TLS 패스스루 및 고성능 네트워킹 패턴에 사용됩니다. API 스타일 기능(경로 기반 라우팅, 요청 검증, JWT authorizers 같은 인증 옵션)을 제공하지 않으며, 단순한 POST /signup 엔드포인트에는 Function URLs나 API Gateway보다 일반적으로 더 많은 설정이 필요합니다.

오답입니다. AWS Global Accelerator는 정적 anycast IP를 제공하고 트래픽을 리전 엔드포인트(예: ALB, NLB, API Gateway)로 라우팅하여 가용성과 성능을 개선합니다. 자체적으로 Lambda 함수를 HTTP 엔드포인트로 직접 노출하지는 않습니다. 여전히 기본 엔드포인트(API Gateway, Function URL, 또는 load balancer)가 필요하므로 구성을 최소화하기보다는 추가 구성이 됩니다.

오답입니다. AWS Lambda는 function에 Amazon EBS volume을 연결하는 것을 지원하지 않습니다. EBS volume은 EC2 instance용 block storage입니다. Lambda에서 mounted filesystem이 필요하다면 지원되는 옵션은 Amazon EFS이지만, EFS는 network 기반이므로 단일 invocation 내 반복 읽기에서는 로컬 /tmp만큼 빠르지 않으며, 특히 데이터가 파싱 후 폐기되는 경우에는 적절하지 않습니다.

오답입니다. Elastic Network Adapter (ENA)를 Lambda function에 연결할 수 없습니다. Lambda의 networking은 AWS가 추상화하여 관리합니다. Lambda는 VPC에서 실행될 수 있고 시간이 지나며 networking이 개선될 수는 있지만, ENA는 EC2의 구성 요소입니다. 또한 이 선택지는 핵심 최적화(3~5회의 반복적인 S3 전체 network 읽기 회피)를 해결하지 못합니다.

오답입니다. 파서가 파일이 필요할 때마다 S3에서 직접 읽으면 invocation당 3~5회 전체 다운로드가 발생합니다. S3가 빠르더라도 대용량 전송을 반복하면 latency가 크게 증가하고 비용/시간의 지배 요인이 될 수 있습니다. 이 방식은 더 단순하지만 반복 읽기 workload에 대해 성능 최적화된 접근이 아니며, /tmp로 스테이징하는 것이 표준 최적화입니다.