Week 5의 뼈대는 네 박자다 — 견적 → 구매 방식 → 가시성·통제 → 문제 해결. 이 전부를 다계정으로 묶는 것이 Organizations·통합 결제다.
요금 모델은 "얼마나 오래, 얼마나 확실히 쓰는가" 한 축으로 갈린다. 모르면 온디맨드, 확실하면 RI/SP, 끊겨도 되면 스팟.
비용 도구는 시점으로 갈린다. 쓰기 전 Pricing Calculator, 쓴 뒤 Cost Explorer, 넘기 전 Budgets, 가장 상세한 건 CUR.
지원 플랜은 응답 속도와 도움의 깊이가 곧 등급이다. '사람'(TAM)과 '도구'(Trusted Advisor)를 절대 섞지 말 것.
다계정은 Organizations = 거버넌스, 통합 결제 = 절감으로 역할이 나뉜다.
오늘은 새 지식을 얹는 날이 아니라, 문항의 언어를 정답으로 번역하는 연습을 하는 날이다.
이번 주는 "돈과 도움"의 주간이었다. 같은 자원도 어떻게 사느냐(요금 모델), 얼마 썼는지 어떻게 보느냐(비용 도구), 문제가 생기면 누가 돕느냐(지원 플랜), 여러 계정을 어떻게 결제·관리하느냐(청구 구조)를 배웠다. 오늘은 네 갈래를 하나의 그림으로 묶어 복습하고, 시험에서 자주 헷갈리는 짝들을 정리한다.
핵심 한 문장: 사기 전에 견적하고(Pricing Calculator/TCO) → 올바른 방식으로 사고(요금 모델) → 쓴 비용을 보고 통제하고(비용 도구) → 문제는 적절한 지원으로 해결한다(지원 플랜) → 이 모든 걸 다계정 차원에서 묶는다(Organizations/통합 결제).
클라우드 이전에는 "비용 관리"가 사실상 구매 결재를 뜻했다. 견적서를 받고, 예산을 잡고, 결재를 올리고, 장비가 도착하면 그 뒤로는 몇 년간 감가상각표에 숫자가 박혀 있을 뿐이었다. 한번 사고 나면 더 볼 것이 없었고, 잘못 샀어도 되돌릴 방법이 없었다.
클라우드는 이 구조를 뒤집었다. 살 때 한 번 결정하는 게 아니라 쓰는 내내 결정한다. 서버를 하나 더 켜는 순간 청구서가 늘고, 끄는 순간 줄어든다. 좋게 말하면 자유이고, 나쁘게 말하면 아무도 안 보면 계속 새는 구조다. 그래서 예전에는 없던 질문 네 가지가 새로 생겼다 — "만들기 전에 얼마 나올지 알 수 있나(Pricing Calculator·TCO)", "더 싸게 사는 방법이 있나(요금 모델)", "지금 얼마 쓰는지 어떻게 보나(Cost Explorer·Budgets·CUR·태그)", "문제가 생기면 누가 도와주나(지원 플랜)". 이번 주에 배운 것들이 각각 그 답이고, 이 전부를 계정 단위로 묶는 것이 Organizations와 통합 결제다.
비용 관리의 순서는 항상 "보이게 만들기 → 나누기 → 줄이기" 다. 안 보이는 비용은 줄일 수 없고(Cost Explorer·CUR), 누구 것인지 모르는 비용은 책임질 사람이 없으며(태그), 그 뒤에야 요금 모델을 바꿔 진짜로 줄일 수 있다(RI·SP·스팟). "먼저 무엇을 해야 하는가"를 물으면 이 순서를 떠올린다.
RI와 Savings Plans가 끝까지 헷갈린다면 "무엇을 약속했는가"만 기억한다. RI는 자리를, Savings Plans는 금액을 약속한다. 이 차이가 유연성의 차이를 그대로 만든다.
선택은 이 순서로 내려오면 거의 틀리지 않는다. 중간에 끊겨도 되나? → 예면 스팟. 아니면, 장기간 계속 돌 것이 확실한가? → 예면 RI/Savings Plans(사양 고정이면 RI, 유연성이 필요하면 SP), 아니면 온디맨드.
⚠️ 함정: "가장 저렴한 방법은?"만 보고 반사적으로 스팟을 고르면 틀린다. 스팟은 AWS가 언제든 회수할 수 있어 중단을 견딜 수 있는 작업에만 해당한다. 상시 웹 서버, 결제 처리, 데이터베이스에는 쓰지 않는다. "중단 허용", "내결함성", "배치", "재시작 가능" 같은 표현이 함께 있어야 정답 후보다.
밤마다 하루치 로그를 모아 통계를 내는 배치 작업이 있다고 가정한다. 중간에 서버가 사라져도 다시 돌리면 그만이니 스팟이 제격이다. 반면 같은 회사의 로그인 서버는 1년 내내 꺼질 수 없으니 RI 또는 Savings Plans, 다음 달에 띄울 실험용 서버는 며칠 만에 끌지도 모르니 온디맨드가 맞다. 한 회사 안에서도 워크로드 성격에 따라 답이 갈린다는 점이 핵심이다.
여기서 잘 구분해야 할 축이 시점이다. 같은 '비용'이라는 단어가 붙어 있어도 셋은 서 있는 시점이 다르다 — Cost Explorer·CUR는 과거(이미 쓴 돈), Budgets는 현재(넘기 전에 알림), Pricing Calculator는 미래(아직 안 만든 것).
⚠️ 함정: Cost Explorer에도 예측 기능이 있어 그 단어만 보고 고르는 실수가 잦다. 하지만 그 예측은 이미 쓰는 것의 추세를 늘려 그린 선이다. 아직 만들지 않은 아키텍처의 비용은 Pricing Calculator다. "배포 전", "아직 생성하지 않은", "신규 설계"가 보이면 Cost Explorer가 아니다.
한 가지 더. 개발팀·마케팅팀이 한 계정을 같이 쓰는데 "이 금액 중 우리 몫이 얼마냐"에 아무도 답을 못 한다면, 첫 조치는 도구를 새로 여는 게 아니라 리소스에 팀 이름 태그를 붙이는 것이다. 태그가 붙어야 Cost Explorer에서 쪼개 볼 수 있고 팀별 Budgets도 걸 수 있다.
지원 플랜은 상품이라기보다 보험 등급으로 보면 이해가 빠르다. 평소엔 차이를 못 느끼지만 사고가 났을 때 누가 얼마나 빨리 오는지가 달라진다. 한 계단씩 올라갈 때 새로 생기는 것만 기억하면 표를 통째로 외울 필요가 없다.
Basic 문서 · 포럼 · 청구 문의 (기술 케이스 ✕)
└ + 기술 지원(이메일, 업무 시간) → Developer
└ + 24/7 지원, 전체 Trusted Advisor 점검 → Business
└ + TAM(전담 사람), 최단 응답 → Enterprise
함정: "24시간 지원이 필요하다"만 보고 곧장 Enterprise를 고르는 실수가 잦다. 24/7 지원 자체는 Business에서 이미 제공된다. Enterprise를 골라야 하는 신호는 TAM(전담 기술 자문 인력)이나 가장 빠른 응답처럼 Business에는 없는 조건이 함께 나올 때다. 요건을 초과하는 비싼 답을 고르는 것도 오답이라는 점을 기억한다.
TAM은 사람, Trusted Advisor는 도구다. Trusted Advisor는 계정 환경을 자동으로 훑어 비용·성능·보안·내결함성·서비스 한도 같은 관점에서 모범 사례에 어긋난 지점을 알려준다. 사람이 붙어 우리 회사 사정을 알고 조언해 주는 것과, 프로그램이 규칙에 맞춰 점검표를 뽑아 주는 것은 전혀 다른 일이다. 보기에 두 이름이 같이 나오면 "사람이냐 도구냐"부터 갈라라.
처음 배우는 사람이 가장 이상하게 느끼는 대목이다. "계정 하나로 쓰면 되지, 왜 나눈 다음에 다시 묶느냐." 이유는 나누는 목적과 묶는 목적이 다르기 때문이다.
나누는 이유 — 개발 계정에서 실수로 지운 것이 운영 계정에 번지면 안 된다. 계정은 가장 확실한 담벼락이라 사고 범위가 그 안에서 멈춘다.
묶는 이유(Organizations) — 나눠 놓으면 관리가 흩어진다. "모든 계정에서 이 리전은 못 쓰게 하라"를 계정마다 손으로 걸 수는 없으니 OU로 묶고 SCP로 위에서 한 번에 제한한다.
또 묶는 이유(통합 결제) — 청구서를 한 장으로 합치고, 사용량도 합산되므로 볼륨 할인과 약정 혜택을 계정끼리 나눠 쓸 수 있다.
가족 결합 요금제가 그대로 이 그림이다. 번호(계정)는 각자 따로지만 요금은 한 장으로 나오고(통합 결제), 데이터는 가족끼리 나눠 쓴다(할인 공유). 부모가 자녀 회선에 차단을 거는 것이 SCP다.
함정: SCP는 권한을 '주는' 도구가 아니라 '한도를 정하는' 도구다. SCP로 허용해 두었더라도 그 계정 안의 IAM 정책이 허용하지 않으면 여전히 못 한다. 반대로 IAM에서 관리자 권한을 줬어도 SCP가 막아 두었다면 할 수 없다. "울타리(SCP) 안에서 열쇠(IAM)를 쥐어 준다"고 기억한다.
클라우드 비용은 "잘 사고, 잘 보고, 잘 막고, 잘 묶는" 네 박자로 다스린다. 워크로드의 지속성과 예측 가능성에 맞춰 요금 모델을 고르고, Cost Explorer·Budgets·CUR·태그로 가시성과 통제를 확보하고, 조직 규모에 맞는 지원 플랜으로 안정성을 사고, Organizations·통합 결제로 다계정을 효율화한다. 그 출발점에는 늘 Pricing Calculator와 TCO로 따져 본 의사결정이 있다.
CLF 비용·지원 문항은 대부분 위 짝 중 하나의 구분을 묻는다. "사전/사후", "사람/도구", "분석/알림", "거버넌스/결제" 같은 축으로 갈래를 먼저 잡으면 오답을 빠르게 걸러낼 수 있다.
여기에 세 짝만 더 얹어 두면 이 도메인의 구분은 거의 다 채워진다. Budgets vs Trusted Advisor(내가 정한 금액 감시 vs 모범 사례 기준 점검), 프리 티어 vs 온디맨드(신규 무료 한도 vs 정상 종량 요금), Pricing Calculator vs TCO(개별 견적 vs 온프레미스와 총비용 비교).