Day 5 - Week 11 복습, 비용·성능 운영을 하나의 의사결정 흐름으로

Week 11에서 다룬 도구들 — Compute Optimizer, Trusted Advisor, Cost Explorer, Budgets, Savings Plans, Spot — 은 따로 보면 제각각이지만, 실전에서는 하나의 흐름으로 연결된다. 비용 최적화는 무작위로 도구를 꺼내 쓰는 게 아니라 순서가 있는 파이프라인이다. 먼저 그릇 크기를 맞추고(Right Sizing), 다음에 안정 사용량을 약정으로 깎고, 변동분을 Spot으로 처리하고, 그 전체를 분석·통제·점검한다. 이 순서를 거꾸로 하면 — 예컨대 Right Sizing 전에 약정부터 걸면 — 잘못된 크기를 3년간 약정하는 비싼 실수를 한다.

이 글은 Week 11을 두 축으로 정리한다. 첫째는 각 도구의 역할을 한 문장으로 압축하고 "출제 키워드 → 정답 서비스" 매핑을 굳히는 것, 둘째는 도구들이 어떻게 한 의사결정 흐름으로 엮이는지 보는 것이다. 그 다음 실전 시나리오 12문항으로 감각을 점검한다. 시험에서 비용·성능 문제는 대개 "이 상황에 가장 적합한 도구 하나"를 고르는 형태이고, 그 선택은 도구의 고유 영역을 정확히 알 때 갈린다.

Week 11 한 문장 요약과 키워드 매핑

시험은 상황 키워드로 도구를 가린다. 이 매핑이 핵심이다.

💡 관련 이론: 이 도구 분류의 밑바탕은 운영의 OODA 루프(Observe-Orient-Decide-Act)다. 관측(Observe)은 CloudWatch·Cost Explorer·CUR이, 판단(Orient)은 Compute Optimizer·Trusted Advisor·Anomaly Detection이, 결정(Decide)은 약정 구매·패밀리 변경이, 행동(Act)은 Budgets Action·Spot 회수 처리·자동 복구가 맡는다. 도구를 기능별로 외우는 대신 "이건 관측이냐, 판단이냐, 행동이냐"로 분류하면 어느 상황에 무엇이 답인지 자연스럽게 좁혀진다. 예컨대 "탐지만 하고 막지는 못함"(Anomaly Detection)과 "실제로 막음"(Budgets Action)의 구분이 바로 Orient와 Act의 차이다.

비용 최적화의 올바른 순서 — 왜 Right Sizing이 먼저인가

비용 최적화 도구를 아는 것과 올바른 순서로 적용하는 것은 다르다. 순서가 틀리면 절감 효과가 반감되거나 오히려 손해를 본다.

1단계 ─ Right Sizing (그릇 크기 맞추기)
        Compute Optimizer 권장 → 다운사이즈, 패밀리 변경
        gp2 → gp3, io1 → gp3 마이그레이션
        ※ 반드시 먼저! 잘못된 크기에 약정 걸면 잘못된 비용을 3년 묶음

2단계 ─ 약정 할인 (안정 baseline 깎기)
        24/7 상시 워크로드 60~70% → Compute SP 3년
        절대 줄지 않는 최소 사용량에만

3단계 ─ 변동 워크로드 (On-Demand + Spot)
        예측 어려운 변동분 → On-Demand 20~30%
        무상태·회수 견딤 → Spot 10~20% (capacityOptimized)

4단계 ─ 지속 모니터링 (관측·통제)
        Cost Explorer 분석 / Budgets 통제 / Anomaly 탐지
        SP·RI Utilization·Coverage 점검

1단계가 반드시 먼저인 이유는 약정이 비가역적이기 때문이다. m5.4xlarge가 사실 m5.large면 충분한데, Right Sizing 없이 이 큰 인스턴스에 3년 Standard RI를 걸면, 1년 뒤 다운사이즈하고 싶어도 약정에 묶여 못 줄인다. 먼저 적정 크기를 찾고 나서, 그 적정 크기의 baseline에 약정을 거는 것이 순서다. 약정은 "이미 최적화된 크기"를 깎는 마지막 단계지 첫 단계가 아니다.

⚠️ 함정: Right Sizing과 약정의 순서를 뒤집는 실수 외에, "약정을 baseline 이상으로 거는" 실수도 흔하다. 트래픽이 출렁이는 워크로드의 피크에 맞춰 약정하면, 골짜기 시간엔 약정의 상당 부분을 안 쓰고도 돈을 낸다(낮은 Utilization). 약정은 항상 "그래프의 바닥선(절대 안 줄어드는 부분)"에만 걸고, 그 위는 On-Demand·Spot으로 받친다. 시험에서 "변동성 큰 워크로드 + 비용 절감"이면 Standard RI 풀 약정은 오답일 가능성이 높고, Compute SP(baseline) + Spot(변동) 조합이 정답 방향이다.

자주 혼동되는 경계들 — 시험이 노리는 구분점

비용·성능 영역의 시험 문제는 대부분 "비슷해 보이는 두 도구 중 하나"를 고르게 한다. 핵심 경계를 정리한다.

탐지 vs 차단: Cost Anomaly Detection은 ML로 이상 비용을 탐지·알림하지만 비용을 막지는 못한다. 실제로 차단하는 건 Budgets Action(EC2 stop, IAM/SCP)뿐이다. "자동으로 막아라"가 키워드면 Budgets Action, "비정상을 알아차려라"면 Anomaly Detection이다.

고정 임계 vs 패턴 이상: Budgets는 "월 $5,000" 같은 고정 임계를 넘으면 알린다. Cost Anomaly Detection은 평소 패턴 대비 이상치를 잡는다. 임계 안에서의 갑작스러운 spike는 Budgets가 못 잡고 Anomaly가 잡는다 — 보완 관계다.

Right Sizing 권장 vs 모범 사례 점검: Compute Optimizer는 인스턴스 단위로 정밀한 크기 권장을 낸다. Trusted Advisor는 계정 전반의 거친 모범 사례 점검이다. "어떤 인스턴스를 어떤 타입으로 줄여라"는 Compute Optimizer, "전반적 비용·보안·내결함성 점검"은 Trusted Advisor.

할인 vs 용량 보장: SP/RI는 할인이지 용량을 보장하지 않는다. Capacity Reservation은 용량 보장이지 할인이 아니다. "반드시 띄울 수 있어야"면 Capacity Reservation, "싸게"면 SP/RI.

내 설정 vs AWS 측 사건: Trusted Advisor는 내 계정 설정의 문제를, Personal Health Dashboard는 AWS 쪽 사건(retirement, 유지보수)을 본다.

빠른 요약 vs 원시 데이터: Cost Explorer는 사전 집계된 빠른 요약(콘솔), CUR은 시간·리소스 단위 원시 데이터(S3 + Athena 임의 SQL).

이 경계들이 존재하는 근본 이유는 각 도구가 다른 데이터 해상도와 다른 작동 시점에 최적화됐기 때문이다. Cost Explorer는 일/시간 단위 사전 집계라 빠르지만 거칠고, CUR은 리소스·시간 단위 원시라 정밀하지만 무겁다. Anomaly Detection은 비동기 ML 추론이라 탐지엔 강하지만 실시간 차단은 못 하고, Budgets Action은 임계 트리거 기반이라 즉시 차단하지만 패턴은 못 본다. 도구를 외울 때 "이건 어느 해상도의 데이터를, 어느 시점에 처리하나"를 물으면 왜 그 도구가 그 일만 잘하는지가 보인다 — 모든 걸 다 하는 단일 도구가 없는 건 데이터 해상도와 지연(latency) 사이의 트레이드오프 때문이다.

약정 점검 지표 — Utilization과 Coverage의 의미

약정(SP/RI)을 한 번 사고 끝이 아니다. 워크로드는 변하므로 약정이 여전히 적정한지 지속 점검해야 하고, 그 핵심 지표가 Cost Explorer의 Utilization과 Coverage다. 이 둘을 혼동하면 잘못된 결정을 한다.

• Utilization(활용률): 산 약정 중 실제로 써서 할인을 본 비율. 90%면 약정의 90%를 활용 중이고, 60%면 40%를 버리는 중(과다 약정). 낮으면 약정을 줄여야 한다.
• Coverage(적용률): 전체 On-Demand 가능 사용량 중 약정이 덮은 비율. 50%면 사용량의 절반은 아직 정가(On-Demand)로 내는 중. 낮으면 약정을 더 걸 여지(추가 절감 기회)다.

둘을 함께 봐야 한다 — Coverage가 낮고 Utilization이 높으면 "약정을 더 사도 다 쓸 것"이니 추가 약정이 안전하다. Coverage가 높은데 Utilization이 낮으면 이미 과다 약정이니 더 사면 안 된다.

FinOps Foundation의 업계 조사에 따르면, 클라우드 비용 낭비의 큰 축은 ① 끄지 않은 유휴 리소스와 ② 잘못 산 약정이다. 많은 조직이 "약정하면 무조건 싸다"는 생각에 피크 사용량에 맞춰 RI를 대량 구매했다가, 워크로드가 줄거나 패밀리를 바꿔 Utilization이 50% 아래로 떨어지는 실패를 겪었다 — 안 쓰는 약정이 오히려 On-Demand보다 비싸진 것이다. 이 교훈으로 업계는 "보수적 약정 + 정기적 Utilization/Coverage 점검"을 표준으로 삼았고, AWS도 Convertible RI와 유연한 Compute SP를 내놓아 약정의 경직성을 완화했다. 약정은 사는 순간이 아니라 운영하며 관리하는 대상이다.

정리

Week 11의 도구들은 "관측 → 판단 → 결정 → 행동"의 운영 루프를 비용·성능 영역에서 구현한다. 시험에서든 실무에서든 핵심은 각 도구의 고유 영역과 그들을 엮는 순서다.

다섯 가지로 압축하면 이렇다. ① Compute Optimizer = Right Sizing 권장(14일 메트릭, 메모리는 Agent 필요), 비용 최적화의 1단계. ② Trusted Advisor = 다섯 카테고리 모범 사례 점검(전체는 Business+ Support, 한도는 80% 사전 경보). ③ Cost Explorer(다차원 분석) + Budgets(Action으로 차단) + Tag(분배, 활성화 소급 안 됨) + Anomaly Detection(ML 탐지, 차단 아님). ④ 약정은 baseline에만(Compute SP 유연 / EC2 Instance SP·Standard RI 묶임 / RDS·Redshift는 RI), Utilization·Coverage로 점검. ⑤ Spot은 무상태·회수 견딤 전용(capacityOptimized, 2분 통보 처리), Capacity Reservation은 할인 아닌 용량 보장. 이 순서대로 — Right Sizing → 약정 → Spot → 모니터링 — 적용하는 것이 비용 최적화의 정석이다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

EC2 200대를 운영 중이며 어떤 인스턴스가 over-provisioned인지 인스턴스 단위로 정밀하게 알고 싶다. 가장 적합한 도구는?

• ACloudWatch Dashboard에 인스턴스별 CPU·메모리 그래프를 띄워 운영자가 수동으로 over-provisioned를 판별
• BCompute Optimizer — 14일 메트릭의 퍼센타일 분포를 ML로 분석해 인스턴스별 Over/Under/Optimized와 권장 타입을 제시
• CTrusted Advisor Performance 카테고리로 계정 전반의 활용도 낮은 인스턴스를 모범 사례 기준으로 점검
• DCost Explorer에서 인스턴스 타입별 비용을 분해해 지출이 큰 인스턴스를 over-provisioned로 추정

문제 2

운영팀이 매월 $5,000 예산을 두고, 80% 도달 시 알림, 100% 도달 시 일부 EC2를 자동 중지하길 원한다. 사람 개입 없이.

• ACost Explorer에서 월별 지출을 모니터링하다 80%를 넘으면 운영자가 수동으로 EC2를 중지
• BAWS Budgets + Budgets Action(80% 알림, 100% 도달 시 EC2 stop 또는 IAM Deny 부착)
• CCost Anomaly Detection으로 비용 급증을 탐지하고 SNS 알림 후 자동으로 EC2를 중지
• D청구 지표(EstimatedCharges)에 CloudWatch Alarm을 걸어 임계 도달 시 Lambda로 EC2를 중지

문제 3

CloudOps 팀과 DevOps 팀의 비용을 별도로 추적하려 한다. 가장 가벼운 방법은?

• A팀마다 별도 AWS 계정을 만들고 Organizations 통합 결제로 계정 단위 비용을 분리 집계
• B리소스에 Team 태그 부여 + Cost Allocation Tag 활성화 + Cost Explorer Group by Tag
• C팀마다 Budgets를 생성해 예산 단위로 각 팀의 비용을 따로 추적
• DCUR을 S3로 내려받아 매일 Athena·스프레드시트로 팀별 비용을 수동 분석

문제 4

회사가 향후 3년간 EC2를 안정적으로 운영하지만 패밀리·리전을 자주 바꾼다. 코드 변경 없이 최대한 할인받으려면?

• AStandard RI 3년 — 특정 인스턴스 패밀리에 약정해 최대 할인을 받고 패밀리 변경 시 RI를 재구매
• BCompute Savings Plans 3년 — 모든 리전·패밀리·EC2/Fargate/Lambda에 약정 금액 내 자동 적용
• COn-Demand로 운영하며 패밀리·리전 변경의 자유를 유지하되 할인은 포기
• DSpot으로 운영해 최대 90% 할인을 받되 회수 시 다른 패밀리로 자동 대체

문제 5

야간에만 100대 노드로 EMR 배치를 돌린다. 무상태이고 회수돼도 재실행하면 된다. 비용 최소화는?

• AOn-Demand 100대로 매 야간 배치마다 정가로 띄우고 종료해 약정 없이 유연하게 운영
• BStandard RI 100대를 3년 약정해 배치 노드에 최대 할인을 적용
• CSpot Fleet + capacityOptimized — 무상태·회수 내성 배치의 최적, 최대 90% 할인 + 안정성 확보
• DCompute Savings Plans로 야간 배치의 시간당 지출에 약정해 할인을 받음

문제 6

모든 AWS 서비스의 한도(쿼터)가 80%에 근접하면 자동 경고를 받고 싶다.

• A서비스별 사용량을 CloudWatch Custom Metric으로 직접 publish하고 80% 임계 알람을 수동 구성
• BTrusted Advisor Service Limits + EventBridge 알림 (Business+ Support)
• CConfig Rule로 각 서비스 리소스 수를 추적해 한도 대비 80% 초과 여부를 평가
• DService Quotas 콘솔에서 각 쿼터의 사용률을 정기적으로 수동 확인

문제 7

회사 비용이 어느 날 평소 패턴 대비 3배로 튀었다. 고정 예산 임계는 안 넘었다. 이런 이상을 자동 탐지하려면?

• AAWS Budgets로 월 고정 임계를 잘게 쪼개 걸어 패턴 이탈을 임계 초과로 잡음
• BCost Anomaly Detection — ML로 평소 패턴을 학습해 통계적 이상치를 탐지
• CTrusted Advisor Cost 카테고리로 낭비 리소스를 점검해 비용 급증 원인을 찾음
• D청구 지표(EstimatedCharges)에 CloudWatch Alarm을 걸어 평소 대비 급증을 감지

문제 8

신규 m7i 인스턴스를 BCP용으로 특정 AZ에 항상 즉시 띄울 수 있게 확보하고 싶다. 목표는 비용 절감이 아니라 가용성이다.

• AStandard RI(할인은 되나 용량 보장은 아님)
• BEC2 Capacity Reservation — 특정 AZ에 용량 확보, 할인은 별도(SP/RI와 조합)
• CSpot으로 해당 AZ에 미리 확보해 두고 회수되면 즉시 재요청
• DOn-Demand 인스턴스를 BCP용으로 미리 띄워 stop 상태로 두고 필요 시 start

문제 9

RDS PostgreSQL을 24/7 운영하며 약정 할인을 받고 싶다.

• ACompute Savings Plans로 시간당 지출에 약정해 RDS 인스턴스에도 할인을 적용
• BEC2 Instance Savings Plans로 특정 인스턴스 패밀리에 약정해 RDS를 포함한 컴퓨트를 할인
• CReserved Instances (RDS RI)
• DSpot으로 RDS 인스턴스를 띄워 최대 할인을 받되 회수에 대비

문제 10

EBS 비용 절감을 위해 gp2 → gp3 마이그레이션 후보를 자동 식별하려 한다.

• ACLI로 전 볼륨의 타입·IOPS를 조회해 스프레드시트로 gp2 볼륨을 수동 선별
• BCompute Optimizer EBS Volume 권장 + Trusted Advisor Cost 카테고리
• CCost Explorer에서 EBS 비용을 볼륨 타입별로 분해해 gp2 지출이 큰 볼륨을 후보로 추정
• DConfig Rule로 gp2 볼륨을 비준수로 표시해 마이그레이션 후보 목록을 생성

문제 11

회사가 1년 전 산 Compute SP의 Cost Explorer Utilization이 55%로 낮다. 의미와 조치는?

• A약정이 부족하다는 신호이므로 baseline을 더 키워 SP를 추가 구매해 할인 범위를 넓힌다
• B과다 약정 — 약정의 45%를 안 쓰고 버리는 중이므로, 다음 약정은 절대 줄지 않는 baseline에 맞춰 규모를 줄인다
• CUtilization이 아니라 Coverage가 낮은 상황이므로, 아직 On-Demand로 내는 사용량을 덮도록 약정을 더 산다
• DUtilization은 시점별 변동이 커 신뢰할 수 없는 지표이므로 Coverage만 보고 판단한다

문제 12

운영팀이 t3.large로 돌리던 API 서버가 트래픽이 꾸준히 늘며 매일 오후 응답이 급락하고 CPU가 일정 값에 천장을 친다. 비용·성능을 함께 고려한 올바른 조치는?

• A인스턴스를 t3.2xlarge로 키운다
• BCPU 크레딧 고갈이 원인이므로, 꾸준한 부하에 맞는 m/c 패밀리(예: m6i)로 변경하고 Compute Optimizer로 적정 크기를 확인한다
• Cgp3로 볼륨을 변경한다
• DSpot으로 전환한다

📌 오늘의 요약

1. 비용 최적화는 순서가 있는 파이프라인 — Right Sizing(1단계) → 약정(baseline) → Spot(변동) → 모니터링. 약정 전에 크기부터 맞춰야 잘못된 비용을 약정하지 않음
2. 키워드 매핑: 크기 권장→Compute Optimizer, 5개 카테고리 점검→Trusted Advisor, 자동 차단→Budgets Action, ML 탐지→Anomaly Detection, 용량 보장→Capacity Reservation
3. 경계: 탐지(Anomaly) vs 차단(Budgets Action), 빠른 요약(Cost Explorer) vs 원시 데이터(CUR), 할인(SP/RI) vs 용량 보장(Capacity Reservation), 내 설정(TA) vs AWS 측(PHD)
4. 약정은 baseline에만, Compute SP(유연)/EC2 Instance SP·Standard RI(묶임)/RDS·Redshift는 RI, Utilization·Coverage로 적정성 점검
5. Spot은 무상태·회수 견딤 전용(capacityOptimized, 2분 통보 처리), T 패밀리 크레딧 고갈은 m/c 패밀리로 교정