연습 문제

문제 1

멀티미디어 분석 스타트업이 단일 Amazon S3 bucket에 JSON 요약과 썸네일을 저장합니다(평균 object 크기 200 KB; 시간당 약 80,000개의 신규 object; 애플리케이션에서 읽기와 쓰기 모두 수행). 회사는 지연 시간을 줄이고, 두 Region 모두에서의 쓰기를 지원하며, 애플리케이션을 위한 단일 데이터 액세스 endpoint를 제공하고, 15분 미만의 replication 지연을 갖는 eventual consistency를 허용하며, 애플리케이션 코드 변경을 최소화하고, 운영 오버헤드를 최소로 하기 위해 두 AWS Region(us-east-1 및 ap-southeast-2)에 동일한 애플리케이션 스택을 배포해야 합니다. 회사는 어떤 솔루션을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 두 Region에서의 쓰기를 포함하는 active-active, multi-Region Amazon S3 액세스와 최소한의 애플리케이션 변경, 그리고 낮은 운영 오버헤드를 테스트합니다. 핵심 서비스는 S3 Cross-Region Replication(CRR)과 S3 Multi-Region Access Points(MRAP)이며, MRAP는 가장 가까운 정상 S3 bucket으로 요청을 라우팅하는 단일 글로벌 endpoint를 제공합니다. 정답이 맞는 이유: Option B만이 모든 요구 사항을 동시에 충족합니다: us-east-1과 ap-southeast-2에 두 개의 동일한 스택, 두 Region 모두에서 발생하는 쓰기, 단일 데이터 액세스 endpoint, 그리고 최소한의 코드 변경. Region별로 bucket 2개(Region당 1개)와 MRAP를 사용하면 애플리케이션은 전 세계적으로 하나의 S3 endpoint 이름을 사용할 수 있고, MRAP는 지연 시간과 가용성에 따라 가장 가까운 bucket으로 읽기/쓰기를 라우팅합니다. 양방향 replication은 Region 간 데이터가 수렴하도록 유지하며, 15분 미만의 replication 지연을 갖는 eventual consistency는 일반적인 CRR 동작과 부합합니다(더 엄격한 SLA가 필요하면 Replication Time Control을 사용할 수 있음). 주요 AWS 기능: - S3 Multi-Region Access Points: 단일 글로벌 endpoint, 지능형 라우팅, 자동 failover, 단순화된 multi-Region 아키텍처. - 양방향 replication: 두 개의 단방향 CRR rule(각 bucket이 서로에게 replication)로 구현. 두 bucket 모두에서 versioning 활성화 및 적절한 IAM role/policy 필요. - Replication 고려 사항: 신규 object replication 처리; 요구 사항에 따라 delete marker replication 및 replica modification sync를 선택적으로 구성. 흔한 오해: CloudFront와 Global Accelerator(Option A)는 읽기 지연 시간을 개선할 수 있지만, 단일하고 일관된 데이터 계층을 갖춘 multi-Region, active-active S3 쓰기를 제공하지는 않습니다. 단방향 CRR(Option C)은 “두 Region에서의 쓰기” 요구 사항을 충족하지 못합니다. VPC gateway endpoint와 Intelligent-Tiering(Option D)은 네트워킹/비용 기능이며 multi-Region replication이나 단일 글로벌 endpoint를 해결하지 못합니다. 시험 팁: “single endpoint” + “multi-Region S3” + “writes from both Regions” + “minimal app changes”를 보면, 두 개의 bucket과 replication, 그리고 S3 MRAP를 떠올리십시오. 또한 S3 replication은 bucket 쌍별로 구성되며 본질적으로 비동기입니다. 문제가 replication SLA를 언급한다면 Replication Time Control을 고려하되, MRAP는 글로벌 액세스의 핵심 구성 요소로 유지됩니다.

문제 2

한 핀테크 스타트업이 향후 3년 동안 지속될 컴플라이언스 프로그램을 위해 AWS에서 통화 견적 API를 운영하고 있습니다. 이 API는 두 개의 Availability Zone에 걸쳐 Network Load Balancer (NLB) 뒤의 target group에 등록된 20개의 Amazon EC2 On-Demand Instances에서 실행됩니다. 이 서비스는 stateless이며 24x7로 실행됩니다. 사용자들이 응답이 느리다고 보고합니다. metrics를 보면 정상 트래픽 동안 평균 CPU는 10%이지만, 매일 몇 시간 동안 시장 개장 시간에는 CPU가 100%까지 급증합니다. 회사는 급증 시 지연 시간을 해결하면서 3년 기간 동안 비용을 최소화하는 새로운 아키텍처가 필요합니다. 가장 비용 효율적인 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 24x7로 유지되는 안정적인 baseline과 예측 가능한 일일 급증이 있는 상황에서 비용 최적화된 탄력성을 테스트합니다. 핵심 서비스/개념은 EC2 Auto Scaling (load balancer 뒤의 stateless workload에 대한 동적 scaling)과 EC2 pricing models (baseline에는 Reserved Instances/Savings Plans, burst에는 On-Demand)입니다. 정답이 맞는 이유: 워크로드는 stateless이고 NLB 뒤에 있으며, 평균 CPU가 낮고(10%) 짧은 일일 기간 동안 포화(100%)가 발생합니다. 3년 관점에서 가장 비용 효율적인 설계는 항상 켜져 있는 baseline을 적정 규모로 맞추고 spike 구간에만 scale out하는 것입니다. 옵션 D는 작은 minimum capacity(4)로 baseline을 커버하고, 시장 개장 시간에 Auto Scaling으로 최대 28까지 확장하여 CPU spike 시 용량을 추가함으로써 지연 시간을 제거합니다. baseline(4개)에 대해서만 Reserved Instances를 구매하면 장기 비용을 최소화할 수 있고, 추가 인스턴스는 spike 동안에만 실행되므로(On-Demand) 24x7로 필요하지 않은 용량을 예약하는 것보다 더 저렴합니다. 주요 AWS 기능: - target tracking(예: 평균 CPU 또는 NLB metrics)을 사용하는 EC2 Auto Scaling으로 인스턴스를 자동으로 추가/제거 - health checks 및 registration/deregistration를 위한 Auto Scaling과 NLB target group 통합 - 항상 켜져 있는 baseline에는 Reserved Instances(또는 Compute Savings Plans), burst capacity에는 On-Demand - Well-Architected Cost Optimization: 수요에 맞춰 공급을 조정하고 steady-state usage에만 커밋 흔한 오해: 흔한 함정은 현재 fleet이 20이므로 너무 많은 인스턴스를 예약하는 것(옵션 A)입니다. 하지만 metrics는 지속적인 과다 프로비저닝(10% CPU)을 보여주므로 20개를 예약하면 3년 동안 비용이 낭비됩니다. 또 다른 오해는 Spot이 항상 가장 저렴하다는 것(옵션 B/C)입니다. 컴플라이언스 프로그램과 지연 시간에 민감한 시장 개장 시간 spike의 경우, Spot interruption risk와 capacity availability는 다양화와 fallback 없이 설계하면 성능과 신뢰성에 악영향을 줄 수 있습니다. 시험 팁: “24x7로 3년”과 “spiky”를 보면 “baseline은 reserve하고 burst는 autoscale”을 떠올리십시오. metrics를 사용해 baseline 과다 프로비저닝을 추론하십시오. stateless 서비스라면 기존 load balancer 뒤에서 Auto Scaling을 선호하십시오. Spot은 비용 효율적일 수 있지만, 시험에서는 보통 interruption tolerance가 명시되고 graceful handling 및 fallback 아키텍처가 포함될 때 선택됩니다.

문제 3

한 fintech 기업이 co-location facility의 Windows VM에서 리스크 분석 도구를 실행하고 있으며, 이 도구는 SMB를 통해 65 TB 공유 파일 리포지토리를 읽고 쓰고, 평균 일일 변경량은 약 100 GB입니다. 기업은 내구성과 비용을 위해 공유 스토리지를 Amazon S3로 이전하려고 하지만, 애플리케이션이 native S3 API를 사용하도록 리팩터링되는 것은 4개월 후에나 가능합니다. 이 기간 동안 on-premises 애플리케이션은 최소한의 클라이언트 변경으로 SMB를 통해 동일한 데이터셋에 계속 액세스해야 하며, cutover는 AWS에서 file server를 실행할 필요가 없어야 합니다. solutions architect는 마이그레이션 중과 이후에도 on premises에서 중단 없는 SMB 액세스를 보장하면서 데이터를 새로운 S3 위치로 마이그레이션해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 애플리케이션을 리팩터링하지 않고, 그리고 AWS에서 file server를 실행하지 않으면서, 궁극적으로는 내구성이 높고 비용 효율적인 Amazon S3에 저장되는 데이터에 대해 SMB/NFS 파일 액세스를 제공하는 방법을 테스트합니다. 핵심 서비스는 AWS Storage Gateway (File Gateway)로, on-premises 클라이언트에 SMB file share를 제공하면서 객체를 S3에 저장합니다. 정답인 이유: 기업은 데이터셋이 지금은 S3에 존재하길 원하지만, Windows VM은 약 4개월 동안 최소한의 클라이언트 변경으로 SMB를 계속 사용해야 합니다. AWS Storage Gateway file gateway는 on premises에 VM으로 배포할 수 있으며 S3 bucket을 백엔드로 하는 SMB share를 노출할 수 있습니다. 애플리케이션은 SMB를 통해 동일한 데이터에 계속 액세스하며(일반적으로 UNC path를 gateway share로 재지정), gateway는 파일을 투명하게 S3 object로 저장합니다. 이는 SMB server endpoint가 EC2 기반 file server가 아니라 on-premises gateway VM이므로 “AWS에서 file server를 실행하지 않음” 제약을 충족합니다. 주요 AWS 기능: File Gateway는 SMB share를 지원하고, 인증/인가를 위해 Active Directory와 통합되며, hot data에 대한 저지연 액세스를 위해 local cache를 사용하면서 비동기적으로 S3에 업로드합니다. 대규모 데이터셋과 incremental change(100 GB/일)를 효율적으로 지원합니다. 초기 데이터 복사는 기존 SMB 리포지토리에서 gateway SMB share로 복사(또는 Robocopy 같은 도구 사용)하여 수행할 수 있으며, 이후에는 gateway를 통해 지속적인 액세스가 이루어지고 S3가 system of record가 됩니다. 흔한 오해: FSx for Windows File Server(옵션 A)는 SMB를 제공하지만 데이터는 S3가 아니라 FSx(EBS-backed)에 저장되며, AWS에서 관리형 file server를 실행하는 것이므로 명시적으로 허용되지 않습니다. S3로 직접 복사(옵션 B)는 앱이 리팩터링되지 않는 한 SMB 액세스를 깨뜨립니다. file server를 EC2로 lift-and-shift(옵션 C)하는 것은 “AWS에서 file server를 실행할 필요가 없어야 함” 요구 사항을 위반하며 운영 오버헤드를 추가합니다. 시험 팁: “SMB/NFS 클라이언트를 변경하지 않음” + “S3에 저장” + “리팩터링 없음”을 보면 Storage Gateway File Gateway를 떠올리세요. “AWS에서 SMB”와 Windows semantics가 필요하면 FSx for Windows를 떠올리되, S3 backing 여부와 AWS에서 file system을 실행하는 것이 허용되는지 제약을 확인하세요.

문제 4

(3개 선택)

한 의료 분석 기업이 세 개의 Region(us-east-1, us-west-2, eu-west-1)에 걸쳐 320개의 멤버 계정을 보유한 AWS Organizations 조직을 운영하고 있으며, 해당 Region 내 모든 계정의 기존 및 신규 Application Load Balancers(ALB)에 AWS WAF를 사용하여 OWASP Top 10에 대한 기본 보호를 강제해야 합니다. 조직 전반에 걸쳐 이 보호를 중앙에서 적용하고 지속적으로 강제하기 위해 솔루션스 아키텍트가 수행해야 하는 단계 조합은 무엇입니까? (세 가지를 선택하세요.)

문제 분석

핵심 개념: 이 문제는 여러 AWS 계정과 Region 전반에서 AWS WAF 보호(예: OWASP Top 10을 위한 AWS Managed Rules)를 중앙에서 배포하고 조직 차원에서 강제하는 능력을 평가합니다. 핵심 서비스는 AWS Organizations(멀티 계정 거버넌스), AWS Firewall Manager(WAF 정책의 중앙 배포 및 지속적 강제), 그리고 AWS Config(Firewall Manager가 범위 내 리소스를 발견하고 지속적으로 평가하기 위한 필수 조건)입니다. 정답이 맞는 이유: 세 개 Region에 걸친 320개 멤버 계정의 모든 기존 및 신규 Application Load Balancers에 AWS WAF를 적용하려면, ALB와 지정된 Region으로 범위를 지정한 AWS WAF 정책을 AWS Firewall Manager로 사용하는 패턴이 정답입니다. Firewall Manager는 범위 내 ALB에 Web ACL을 자동으로 연결하고, 신규 ALB가 생성되거나 연결이 제거되는 등 드리프트가 발생하면 이를 자동으로 교정할 수 있습니다. Firewall Manager가 동작하려면, AWS Organizations에서 “all features”가 활성화되어 있어야 하며, 이를 통해 Firewall Manager가 service-linked role과 조직 전체 정책 타기팅을 사용하여 계정 전반에서 작동할 수 있습니다. 또한 각 계정/Region에서 AWS Config를 활성화해야 Firewall Manager가 리소스를 인벤토리하고 규정 준수 여부를 평가하여 정책을 지속적으로 강제할 수 있습니다. 주요 AWS 기능 및 모범 사례: - AWS Firewall Manager: AWS WAF 정책을 생성하고, AWS Managed Rules(예: Core rule set / OWASP Top 10 커버리지)를 선택하며, 범위(ALB 리소스)를 정의하고, OU/계정을 타기팅하고, 자동 교정을 활성화합니다. - Multi-Region: WAF/ALB 연결은 regional이므로, 필요한 각 Region(us-east-1, us-west-2, eu-west-1)에서 AWS Config를 활성화하고 Firewall Manager 정책을 배포합니다. - AWS Organizations all features: 중앙 보안 서비스 및 delegated administrator 패턴에 필요합니다. 흔한 오해: - GuardDuty와 Security Hub는 탐지/집계 서비스이며, ALB에 WAF 규칙을 배포하지 않습니다. - Shield Advanced는 DDoS 보호를 제공하고 WAF와 통합될 수 있지만, 여러 계정에 걸쳐 WAF 정책을 조직 차원에서 강제하는 주된 메커니즘은 아닙니다. 시험 팁: “중앙에서 적용하고 지속적으로 강제”하며 “여러 계정에 걸쳐” “기존 및 신규 리소스”라는 표현이 보이면 AWS Firewall Manager + AWS Organizations(all features) + AWS Config를 떠올리세요. 또한 WAF/ALB는 regional이므로, 범위에 포함된 각 Region에서 필수 조건과 정책을 활성화해야 한다는 점을 기억하세요.

문제 5

한 ad-tech 회사가 dev, staging, prod 전반에 걸쳐 12개의 microservices를 운영하고 있으며 AWS CDK로 IaC를 관리하는 동시에 versioning이 활성화된 Amazon S3와 Amazon ECR에 synthesized templates 및 container artifacts를 저장하고 있습니다. 개발자들은 IDE가 호스팅된 단일 Amazon EC2 Linux workstation에 접속하여 S3/ECR에서 artifacts를 pull하고, 로컬에서 unit tests를 실행한 뒤, 업데이트를 다시 push합니다. 하지만 이제 팀은 AWS CodePipeline으로 CI/CD를 구현하여 현대화하려고 하며 다음 요구 사항이 있습니다: 소스 관리는 AWS CodeCommit을 사용, main 및 release/* 브랜치에 대한 모든 commit마다 unit tests와 security scanning을 자동 실행, unit tests 실패 시 2분 이내에 팀에 알림, pipeline 동안 특정 API를 on/off하고 환경 구성을 커스터마이즈할 수 있는 dynamic feature toggles 허용, production으로 승격하기 전에 lead developer의 승인 요구. 어떤 솔루션이 이러한 요구 사항을 가장 잘 충족합니까?

문제 분석

핵심 개념: 이 문제는 CodeCommit을 소스로, CodeBuild로 build/test/security scanning을 수행하고, event-driven 알림과 통제된 승격(manual approvals)을 포함하는 현대적인 AWS-native CI/CD pipeline을 CodePipeline으로 설계하는 것을 평가합니다. 또한 AWS CDK/CloudFormation과 깔끔하게 통합되는 구성/feature management 패턴도 다룹니다. 정답이 맞는 이유: Option A는 표준 AWS CI/CD 아키텍처와 일치합니다: CodeCommit이 특정 브랜치(main 및 release/*)에 대한 commit 시 CodePipeline을 트리거합니다. CodeBuild는 unit tests와 security scans(예: SAST, dependency scanning, container image scanning 단계)를 실행하기 위한 올바른 managed service입니다. “2분 이내 알림” 요구 사항의 경우 EventBridge가 CodeBuild build state change events를 구독하고 SNS로 fan out하여 이메일/SMS/ChatOps로 빠르고 안정적으로 알릴 수 있습니다. 마지막으로 CodePipeline은 Manual approval action을 기본 제공하므로 production 전에 lead developer의 승인을 요구하는 정석적인 방법입니다. 주요 AWS 기능: - CodeCommit 및 branch filters(또는 브랜치 패턴별 별도 pipeline)를 사용하는 CodePipeline source action으로 main 및 release/*만 트리거되도록 보장. - unit tests 및 security scanning tools를 실행하기 위한 buildspec.yml의 CodeBuild; IAM least privilege 및 artifact encryption과 통합. - near-real-time 알림을 위해 CodeBuild “FAILED”(또는 phase failure) events를 대상으로 SNS로 전달하는 EventBridge rule. - feature toggles/구성: CDK constructs와 manifest/config file(또는 context/parameters)을 사용하는 것은 전체 아키텍처를 매번 다시 빌드하지 않고도 pipeline 시점에 API를 enable/disable하고 환경별 구성을 커스터마이즈할 수 있는 유효한 메커니즘. - production으로의 승격을 게이트하기 위한 CodePipeline의 Manual approval stage. 흔한 오해: 일부는 CodeDeploy가 테스트를 실행한다고 생각할 수 있지만(주로 deployments를 처리), 또는 Lambda가 범용 CI runner라고 생각할 수 있지만(timeout/runtime 제약으로 일반적인 builds/scans에는 부적합) 그렇지 않습니다. 또한 approvals를 Lambda/SES로 커스텀 구현해야 한다고 가정할 수 있으나, CodePipeline은 이미 1st-class manual approval action을 제공합니다. 시험 팁: AWS-native CI/CD에서는 CodeCommit/CodePipeline/CodeBuild/CodeDeploy를 기본으로 고려하십시오. event-driven notifications에는 EventBridge를, alerting에는 SNS를 사용하십시오. gated releases에는 CodePipeline Manual approval을 찾으십시오. dynamic configuration에는 ad-hoc scripts나 기능별 별도 images보다 CDK/CloudFormation과 통합된 parameterization/manifest/context를 선호하십시오.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

실시간 멀티플레이어 게임 플랫폼이 Amazon EC2 인스턴스 플릿에서 세션 상태 및 매치메이킹 서비스를 배포하고 있습니다. 여기서 1개의 coordinator node와 10개의 worker node는 핫 game-state shard를 전부 메모리 내에서 공유하고 복제해야 합니다. coordinator는 node health를 모니터링하고, 초당 최대 250,000개의 player event를 수집하며, 작업을 worker에게 디스패치하고 응답을 집계합니다. worker node는 sub-millisecond 일관성을 유지하기 위해 빈번한 east-west 복제를 수행합니다. 또한 회사는 처리량을 극대화하고 tail latency를 최소화하기 위해 단일 Availability Zone 내에서 가능한 한 가장 낮은 인스턴스 간 네트워크 지연 시간을 요구합니다. 어떤 솔루션이 이러한 요구 사항을 충족하나요?

문제 분석

핵심 개념: 이 문제는 EC2 placement group과 그것이 단일 Availability Zone(AZ) 내에서 인스턴스 간 네트워크 지연 시간과 처리량에 어떤 영향을 미치는지 평가합니다. 초저지연, 높은 packet-per-second의 east-west 트래픽을 위해서는 인스턴스를 물리적으로 가깝고 고대역폭/저지연 네트워킹으로 연결된 하드웨어에 배치하는 것이 핵심입니다. 정답이 맞는 이유: cluster placement group은 동일한 AZ 내 인스턴스 간 가능한 한 가장 낮은 네트워크 지연 시간과 가장 높은 네트워크 처리량을 제공하도록 설계되었습니다. 설명된 워크로드(메모리 내 hot shard 복제, sub-millisecond 일관성, coordinator/worker fan-out 및 집계, 매우 높은 이벤트 수집률)는 tail latency에 극도로 민감하며, 긴밀하게 결합된 네트워킹의 이점을 크게 받습니다. cluster placement group은 인스턴스를 동일한 랙/네트워크 세그먼트에 배치하려고 시도하여 hop 수와 경합을 최소화하는데, 이는 빈번한 east-west 복제와 빠른 coordinator-to-worker 디스패치에 정확히 부합합니다. 주요 AWS 기능: - Cluster placement group: 하나의 AZ 내에서 저지연, 고처리량 네트워킹에 최적화. - Instance type 선택: “memory-optimized”는 game-state shard를 전부 메모리에 유지해야 한다는 요구 사항(큰 RAM 용량, 높은 메모리 대역폭)과 일치합니다. compute도 중요할 수 있지만, 문제는 명시적으로 메모리 내 상태를 강조합니다. - 운영 참고: cluster placement group은 용량 제약이 있을 수 있습니다. 동일한 instance type을 사용하고, 함께 시작하며, instance size에 유연성을 두면 배치 성공률을 높일 수 있습니다. 흔한 오해: partition placement group은 종종 “최고 성능”으로 오해되지만, 주 목적은 fault isolation(서로 다른 partition의 별도 랙/전원/네트워크로 인스턴스를 분산)입니다. 이는 HDFS/Cassandra 같은 대규모 분산 시스템에서 절대 최저 지연 시간보다 복원력을 우선할 때 흔히 사용됩니다. spread placement group은 격리를 극대화(서로 다른 하드웨어)하므로, 마이크로 지연 시간 수준의 east-west 트래픽에는 오히려 반대입니다. 시험 팁: “absolute lowest latency”, “tightly coupled”, “HPC-style”, “sub-millisecond”, 또는 하나의 AZ 내에서 heavy east-west 트래픽 같은 표현이 보이면 cluster placement group을 떠올리세요. 대규모 플릿에서 “fault isolation”이 보이면 partition을, 소수의 핵심 인스턴스에서 “correlated failures 회피”가 보이면 spread를 떠올리면 됩니다. 그 다음 지배적인 리소스 요구 사항(여기서는 in-memory shard)에 따라 instance family(memory/compute)를 선택하세요.

문제 7

(2개 선택)

모빌리티 분석 스타트업은 사용량 기반 보험 요율을 계산하기 위해 연결된 e-bike의 텔레메트리를 60초마다 수집해야 합니다. 각 디바이스는 JSON 페이로드를 Amazon API Gateway로 전송하고, Amazon API Gateway는 정규화된 레코드를 Amazon DynamoDB 테이블에 쓰는 AWS Lambda 함수를 호출합니다. 제한된 베타(2,000대 자전거) 동안 Lambda 호출은 2~~4초 내에 완료되었습니다. 35,000대로 확장하고 새로운 가속도계 및 배터리 상태 메트릭을 추가한 후, 평균 Lambda 실행 시간이 70~~120초로 증가했으며 추가 메트릭이 더해질수록 실행 시간은 계속 증가하고 있습니다. 팀은 DynamoDB PutItem 호출에서 많은 ProvisionedThroughputExceededException 오류와, API Gateway를 통해 Lambda에서 반환되는 TooManyRequestsException 오류가 자주 발생하는 것을 관찰합니다. 거의 실시간 처리를 유지하면서 이러한 문제를 가장 효과적으로 해결할 변경 사항 조합은 무엇입니까? (두 개 선택)

문제 8

국제 e-learning 플랫폼이 단일 AWS Organizations management account 하에서 8개의 AWS account에 걸친 12개의 cost center에 대한 workload를 운영하고 있습니다. 모든 account의 모든 resource에는 이미 올바른 값으로 CostCenter라는 tag가 적용되어 있으며, Finance는 모든 account 전반에서 각 cost center에 월별 및 일별 AWS 지출의 100%를 배분하고, 월말 이후 48시간 이내에 cost center별 interactive dashboard를 게시해야 하며, 최소 12개월의 이력을 보관해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Organizations 전반에서 cost allocation tag, AWS Cost and Usage Report (CUR), 그리고 분석/시각화 도구(Athena + QuickSight)를 사용하여 daily 및 monthly 정확도와 multi-account 범위를 갖춘 chargeback/showback dashboard를 생성하는 AWS 비용 배분을 평가합니다. 정답이 맞는 이유: Finance는 8개 account에 걸친 12개 cost center에 대해 지출의 100% 배분이 필요하며, daily 및 monthly 관점, 월말 이후 48시간 이내 dashboard 제공, 그리고 최소 12개월 이력 보관이 요구됩니다. 올바른 패턴은 다음과 같습니다: management account에서 CostCenter tag를 AWS cost allocation tag로 활성화(그래야 billing 데이터에 포함됨)하고, 중앙 S3 bucket으로 organization-wide CUR를 생성(모든 linked account가 하나의 dataset에 포함됨)한 뒤, Athena로 query하고 QuickSight로 시각화합니다. CUR는 가장 상세한 line-item billing 데이터(활성화된 이후 tag column 포함)를 제공하며 daily granularity 및 resource IDs를 지원하므로 정확한 배분과 drill-down이 가능합니다. S3는 12개월 이상 보관을 위한 내구성 있고 저비용의 저장소를 제공합니다. 주요 AWS 기능: - AWS Organizations consolidated billing + management account가 billing 데이터의 소유자. - Cost allocation tag는 CUR/비용 도구에 나타나기 전에(일반적으로 management account에서) 활성화되어야 하며, 활성화는 소급 적용되지 않음. - Organization-wide CUR는 모든 member account를 포괄하는 단일 report를 하나의 S3 bucket으로 전달하여 governance 및 분석을 단순화. - Daily granularity 및 resource IDs를 포함한 CUR는 daily 및 monthly rollup과 상세 조사 모두를 지원. - Athena는 S3의 CUR 데이터를 query(종종 Glue Data Catalog를 통해)하고, QuickSight는 Finance 이해관계자에게 적합한 interactive dashboard를 구축. 흔한 오해: - CloudWatch dashboard는 운영 metric/log를 위한 것이며, 권위 있는 billing 배분 및 chargeback 보고용이 아님. - account별로 별도의 CUR를 생성하면 복잡성이 증가하고 cross-account 집계 및 governance가 어려워져 SLA 미준수 위험이 커짐. - 각 account에서 tag를 “생성”하는 것은 여기서는 불필요하며(이미 resource에 tag가 존재), 중요한 단계는 billing을 위한 tag 활성화임. 시험 팁: “지출 100% 배분”, “multi-account”, “daily + monthly”, “이력 보관”, “dashboard”가 보이면 다음을 떠올리세요: cost allocation tag 활성화 + S3로 CUR + Athena/QuickSight. consolidated billing 분석과 운영 단순화를 위해 management account에서 organization-wide CUR를 선호하세요.

문제 9

글로벌 물류 기업이 두 개의 온프레미스 데이터 센터에서 AWS로 420개의 VMware VM(Windows 및 Linux)을 마이그레이션할 계획이며, Migration Evaluator 평가 요청을 제출한 후 (1) 포트/프로세스 수준에서 애플리케이션 간 종속성을 시각화하고 (2) 온프레미스 자산에 대한 Quick Insights 평가 보고서를 생성하는 21일간의 초기 디스커버리가 필요합니다. 또한 회사는 제약 없이 OVA 어플라이언스를 배포하고 에이전트를 설치할 수 있습니다. 그렇다면 필요한 결과를 가장 적은 운영 오버헤드로 제공하는 접근 방식은 무엇입니까?

문제 10

지역 에너지 유틸리티는 매월 계량기 보고서(PDF/CSV) 180TB를 7년 동안 아카이브해야 하며, 기업 인트라넷을 통해 내부 직원만 사용할 수 있도록 해야 합니다. 직원들은 AWS Client VPN을 통해 VPC에 연결하며, 모든 액세스는 private로 유지되어야 합니다(public endpoint 없음). 파일은 offline tape에도 저장된 기록의 중복 사본입니다. 예상 요청률은 주당 10회 미만의 retrieval batch이며, 최대 12시간의 retrieval latency가 허용되고 availability 또는 retrieval 속도에 대한 요구사항은 없습니다. 가장 낮은 비용으로 이러한 요구사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 VPC에서 private-only 액세스를 지원하면서도 가장 낮은 비용의 아카이브 스토리지를 선택하는 것을 테스트합니다. 핵심 서비스는 Amazon S3 storage class(특히 S3 Glacier Deep Archive)와 VPC endpoint를 사용한 S3에 대한 private connectivity, 그리고 bucket policy를 통한 액세스 제어입니다. 정답이 맞는 이유: S3 Glacier Deep Archive는 수년 단위의 장기 보관과 매우 드문 액세스를 위해 설계되었으며 S3에서 가장 낮은 storage cost를 제공합니다. 해당 유틸리티는 매월 180TB를 7년간 보관하고, tape에 중복본이 존재하며(따라서 S3의 기본 수준을 넘어서는 초고 durability/availability가 핵심 동인이 아님), retrieval은 드물고(주당 <10 batch) 최대 12시간의 latency가 허용됩니다. 이는 Deep Archive의 retrieval 모델(밀리초가 아닌 수 시간)과 정확히 부합합니다. 모든 액세스를 private로 유지하기 위해 사용자는 AWS Client VPN으로 VPC에 접속한 뒤 S3 Interface VPC Endpoint(AWS PrivateLink)를 통해 S3에 접근합니다. bucket policy에서 endpoint를 통한 액세스만 허용하도록(aws:SourceVpce 사용) 강제하여 public 경로 액세스를 차단할 수 있습니다. 주요 AWS 기능: - 최저 비용 아카이브 스토리지를 위한 S3 Glacier Deep Archive storage class. - public endpoint 없이 AWS 네트워크 내에서 트래픽을 유지하는 S3 Interface Endpoint(PrivateLink). - private-only 액세스를 강제하기 위한 bucket policy condition key(예: aws:SourceVpce). - 선택 사항: 보관 거버넌스를 위한 S3 Object Lock / lifecycle policy(문항에서 요구하진 않지만 7년 아카이브에서 흔함). 흔한 오해: - “Static website hosting”은 public website endpoint를 의미하며 private-only 액세스 요구사항과 호환되지 않습니다. 인트라넷 액세스에 불필요합니다. - One Zone-IA는 Standard-IA보다 저렴하지만 여전히 online class로서 더 빠른 retrieval과 Deep Archive보다 높은 액세스 빈도를 전제로 합니다. 이 규모와 보관 기간에서는 storage cost가 지배적입니다. - EFS/EBS는 수 PB 규모의 장기 아카이브를 최소 비용으로 저장하기에 비용 효율적이지 않으며, 지속적으로 실행되는 EC2/web tier가 필요합니다. 시험 팁: “수년간 아카이브”, “드문 액세스”, “수 시간의 retrieval latency 허용”을 보면 기본적으로 S3 Glacier Deep Archive(또는 더 짧은 latency가 필요하면 Glacier Flexible Retrieval)를 선택하십시오. “public endpoint 없음”이면 VPC endpoint + 제한적인 bucket policy를 찾고, static website hosting 및 public S3 액세스 패턴은 피하십시오.

Practice Test #4

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(9)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #5

지금 학습 시작하기