[AWS] 8회차: 비용과 아키텍처 원칙 - 비용 최적화와 설계 원칙

이번 회차에서 다룬 내용

2026년 1월 29일 목요일, AWS Certified Cloud Practitioner(CLF-C02) 스터디 8회차를 진행했다. 이번 회차의 주제는 비용과 아키텍처 원칙이었다.

발표자 배정표 기준으로 8회차 범위는 다음과 같았다.

• A(현석): EC2 구매 옵션 (On-Demand / RI / Spot)
• B(현석): Savings Plans
• C(지호): Cost Explorer & Budgets
• D(지호): Well-Architected Framework & CAF

이번 회차는 지금까지 배운 내용을 “어떻게 싸고, 안정적이고, 장기적으로 잘 운영할 것인가”라는 관점으로 다시 정리하는 시간이었다.

앞선 회차에서는:

• 어떤 컴퓨팅 서비스를 쓸지
• 어떤 스토리지를 고를지
• 어떤 데이터베이스를 써야 할지
• 어떤 네트워크 구조를 가져갈지
• 어떻게 보안을 설계할지

를 배웠다.

그런데 실제 운영에서는 “된다”가 끝이 아니다.

• 비용이 너무 많이 들지는 않는가
• 리소스를 과하게 쓰고 있지는 않은가
• 장기적으로 확장 가능한 구조인가
• 운영 원칙이 있는가

이런 질문이 반드시 따라온다.

Cloud Practitioner에서 비용 파트가 중요한 이유도 여기 있다. AWS는 단순히 기능이 많은 플랫폼이 아니라, 잘 쓰면 효율적이고 잘못 쓰면 낭비가 커질 수 있는 플랫폼이기 때문이다.

왜 8회차가 중요한가

클라우드를 처음 배울 때는 보통 기능 쪽에 더 관심이 간다.

• 서버가 잘 뜨는가
• DB가 연결되는가
• 파일이 저장되는가

그런데 실무에서는 그 다음 질문이 더 중요해진다.

• 이 구조를 계속 유지할 수 있는가
• 트래픽이 늘어나도 비용이 감당 가능한가
• 더 나은 구매 방식이 있는가
• 현재 사용 패턴을 분석하고 있는가
• 서비스 설계가 AWS 모범 사례에 맞는가

이번 회차는 이런 운영 감각을 AWS 기본 자격증 수준에서 처음 정리하는 시간이었다.

즉, 8회차는 단순한 “비용 절감 팁” 회차가 아니라, 클라우드를 지속 가능하게 운영하는 기본 프레임을 배우는 회차였다.

EC2 구매 옵션이 왜 중요한가

컴퓨팅 회차에서 EC2를 배웠을 때는 기능과 역할이 중심이었다. 그런데 EC2는 같은 인스턴스를 쓰더라도 어떤 구매 방식으로 쓰느냐에 따라 비용 구조가 달라진다.

즉:

• 같은 서버라도
• 언제, 얼마나, 어떤 방식으로 쓸 것인지에 따라
• 더 비싸게 쓸 수도 있고 더 효율적으로 쓸 수도 있다

Cloud Practitioner 시험에서는 바로 이 선택을 묻는 문제가 많다.

On-Demand 인스턴스

On-Demand는 가장 기본적인 구매 방식이다.

쉽게 말하면:

• 약정 없이
• 필요할 때 바로 쓰고
• 쓴 만큼 비용을 내는 방식

이다.

장점

• 유연하다
• 바로 시작할 수 있다
• 장기 약정이 필요 없다

적합한 경우

• 사용량 예측이 어려울 때
• 처음 시작하는 서비스
• 짧은 테스트
• 임시 워크로드

단점

• 장기적으로 보면 다른 옵션보다 비용이 높을 수 있다

즉, On-Demand는 가장 간단하고 안전한 시작점이지만, 장기적으로 항상 최적은 아니다.

Reserved Instances(RI)

Reserved Instances는 일정 기간 사용을 약정해 비용 할인을 받는 방식이다.

쉽게 이해하면:

• 이 서버는 오래 쓸 것 같으니
• 미리 일정 조건으로 예약하고
• 할인받는 구조

라고 보면 된다.

장점

• 장기적이고 안정적인 사용량이 있다면 비용 절감 효과가 크다

적합한 경우

• 항상 켜져 있는 운영 서버
• 예측 가능한 워크로드
• 장기간 동일하거나 유사한 리소스를 쓸 계획이 있을 때

단점

• 유연성이 On-Demand보다 낮다
• 수요 예측이 틀리면 비효율이 생길 수 있다

Cloud Practitioner 수준에서는 RI의 세부 옵션보다, 장기적이고 예측 가능한 사용량에 적합한 할인 모델이라는 감각을 잡는 것이 더 중요하다.

Spot 인스턴스

Spot 인스턴스는 AWS의 남는 용량을 매우 저렴하게 사용하는 방식이다.

여기서 핵심은 싸다는 점보다도, 언제든 중단될 수 있다는 점이다.

장점

• 매우 저렴할 수 있다

단점

• AWS가 필요하면 회수할 수 있다
• 안정적으로 계속 돌아가야 하는 워크로드에는 부적합할 수 있다

적합한 경우

• 중단되어도 다시 시작할 수 있는 작업
• 배치 처리
• 테스트
• 장애를 감내할 수 있는 워크로드

즉, Spot은 “싸지만 끊길 수 있다”는 한 줄로 기억하면 된다.

시험에서도:

• 가장 저렴한 옵션
• 중단 가능
• 유연한 작업

과 연결해 자주 나온다.

EC2 구매 옵션을 한 번에 비교해보기

On-Demand

• 가장 유연함
• 약정 없음
• 예측 어려운 워크로드

Reserved Instances

• 할인
• 예측 가능한 장기 사용
• 운영 서버에 적합

Spot

• 가장 저렴할 수 있음
• 언제든 중단될 수 있음
• 배치/비핵심 워크로드에 적합

시험에서는 결국 “이 상황이면 어떤 구매 옵션이 맞는가”를 묻는다. 그래서 기능보다 사용 패턴을 먼저 떠올리는 게 중요하다.

Savings Plans란 무엇인가

Savings Plans는 RI와 함께 AWS 비용 최적화에서 자주 나오는 개념이다.

큰 틀에서 보면:

• 일정 수준의 사용을 약정하고
• 할인 혜택을 받는 방식

이다.

왜 Savings Plans가 중요한가

Cloud Practitioner에서는 RI와 Savings Plans를 아주 세밀하게 비교하기보다, 둘 다 장기 사용 약정을 통해 비용을 절감하는 방식이라는 공통점을 이해하는 것이 우선이다.

다만 Savings Plans는 조금 더 유연한 할인 구조로 소개되는 경우가 많다.

즉:

• RI는 특정 리소스와 좀 더 직접 연결된 느낌
• Savings Plans는 사용량 약정 기반의 더 유연한 할인 프레임

으로 정리하면 이해가 쉽다.

Savings Plans가 적합한 경우

다음과 같은 상황에서 떠올릴 수 있다.

• AWS를 계속 사용할 것이 확실하다
• 장기적으로 일정 수준 이상의 사용량이 있다
• 비용을 더 최적화하고 싶다

즉, 단순 실험 단계가 아니라 운영 환경으로 넘어가면 자연스럽게 검토하게 되는 옵션이다.

Cloud Practitioner 문제에서는 보통:

• “장기 사용 예정”
• “비용 절감 필요”
• “유연성도 어느 정도 필요”

같은 키워드가 나오면 Savings Plans를 연결해볼 수 있다.

Cost Explorer란 무엇인가

AWS에서는 비용이 사용량에 따라 계속 변하기 때문에, 단순히 “얼마 나왔지?”만 보는 것으로는 부족하다. 이때 쓰는 대표 도구가 Cost Explorer 다.

Cost Explorer는 말 그대로:

• 비용이 어디서 발생했는지
• 어떤 서비스가 많이 쓰였는지
• 시간이 지나며 사용량이 어떻게 바뀌는지

를 시각적으로 분석하는 도구다.

왜 중요한가

클라우드는 잘못하면 “모르고 계속 쓰다가 비용이 쌓이는” 구조가 될 수 있다.

Cost Explorer를 쓰면:

• 비용 추세를 보고
• 낭비가 있는 서비스가 무엇인지 보고
• 최적화 포인트를 찾는 데 도움을 받을 수 있다

즉, 단순 청구서 확인이 아니라 비용 분석 도구로 이해하는 편이 맞다.

Budgets란 무엇인가

Budgets는 AWS 비용이나 사용량에 대해 미리 기준을 정하고 경고를 받는 도구다.

즉:

• 이번 달 비용이 일정 금액을 넘기면 알림
• 특정 사용량을 초과하면 알림

같은 식으로 설정할 수 있다.

Cost Explorer와 Budgets의 차이

이 둘은 자주 같이 나오기 때문에 구분해야 한다.

Cost Explorer

• 분석 중심
• 과거와 현재 비용을 들여다봄

Budgets

• 임계치 설정
• 초과 시 경고

쉽게 말하면:

• Cost Explorer = “무슨 일이 일어났는지 본다”
• Budgets = “일정 기준을 넘으면 알려준다”

이다.

시험에서는 이 구분을 정확히 잡으면 문제를 쉽게 풀 수 있다.

비용 최적화를 공부하면서 중요한 태도

8회차를 하면서 느낀 건, 비용 최적화는 단순히 “싼 옵션을 고르는 것”이 아니라는 점이었다.

예를 들면:

• 중요 서비스에 무조건 Spot을 쓰는 건 위험할 수 있다
• 예측 불가능한 사용량에 RI를 과하게 잡으면 비효율이 생길 수 있다
• Cost Explorer를 안 보면 어디서 돈이 새는지 알 수 없다
• Budget 알림이 없으면 문제가 커진 뒤에야 알아차릴 수 있다

즉, 비용 최적화는 가격표를 보는 일이 아니라 사용 패턴을 이해하고 운영 기준을 세우는 일에 더 가깝다.

Well-Architected Framework란 무엇인가

AWS Well-Architected Framework는 AWS가 제시하는 좋은 클라우드 아키텍처 원칙 모음이다.

쉽게 말하면:

• 서비스를 AWS 위에 올렸을 때
• 어떤 관점으로 설계를 점검해야 하는지

를 체계적으로 정리한 프레임워크다.

Cloud Practitioner 수준에서는 세부 체크리스트보다, “AWS가 좋은 아키텍처를 평가하는 기준” 정도로 이해하면 된다.

왜 중요한가

서비스는 단순히 동작만 하면 끝나지 않는다.

• 안정적인가
• 안전한가
• 성능이 적절한가
• 비용이 낭비되지 않는가
• 운영이 가능한가

이런 질문을 계속 받아야 한다. Well-Architected Framework는 바로 이런 점검 기준을 제공한다.

Well-Architected Framework의 대표 관점

Cloud Practitioner에서는 보통 각 축의 세부 내용을 깊게 파기보다, AWS가 아키텍처를 다각도로 본다는 감각을 잡는 것이 중요하다.

대표적으로 잘 알려진 기둥은 다음과 같은 방향을 가진다.

• 운영 우수성
• 보안
• 신뢰성
• 성능 효율성
• 비용 최적화

즉, AWS는 “잘 돌아가는지”만 보는 게 아니라, 운영, 보안, 복원력, 성능, 비용을 함께 본다.

시험에서는 “비용 최적화” 자체도 여기와 연결해서 나올 수 있다.

CAF(Cloud Adoption Framework)란 무엇인가

발표자 일정에는 Well-Architected Framework와 함께 CAF(Cloud Adoption Framework) 가 들어 있었다.

이 둘은 비슷해 보이지만 초점이 조금 다르다.

Well-Architected Framework

이미 설계된 워크로드나 아키텍처를 AWS 모범 사례 관점에서 점검하는 느낌에 가깝다.

CAF

조직이 클라우드를 도입할 때:

• 사람
• 프로세스
• 기술

을 어떻게 준비할 것인가에 더 가까운 프레임워크다.

즉, Well-Architected가 워크로드 설계 품질 점검에 가깝다면, CAF는 조직 차원의 클라우드 도입 준비 프레임이라고 볼 수 있다.

시험에서는 둘의 차이를 아주 깊게 묻지 않더라도, “아키텍처 점검”과 “조직 도입 프레임”의 차이를 알고 있으면 도움이 된다.

8회차 전체를 한 흐름으로 보면

이번 회차는 사실 두 덩어리로 나뉜다.

1. 비용 최적화

• EC2 구매 옵션
• Savings Plans
• Cost Explorer
• Budgets

2. 장기 운영 원칙

• Well-Architected Framework
• CAF

즉, 앞부분은 지금 당장 어떻게 더 효율적으로 쓸 것인가에 가깝고, 뒷부분은 클라우드를 장기적으로 어떻게 잘 운영할 것인가에 가깝다.

이 흐름으로 이해하면 8회차가 훨씬 선명해진다.

이번 회차에서 남겨둘 포인트

이번 회차를 하면서 가장 크게 느낀 건, 클라우드는 기능보다 운영 감각이 중요해지는 시점이 반드시 온다는 점이었다.

처음에는:

• 서버 띄우기
• 저장소 연결하기
• DB 고르기

같은 것이 중심이다.

그런데 실제 운영 단계에서는:

• 이 서버를 어떤 구매 옵션으로 돌릴까
• 사용량이 장기적으로 예측 가능한가
• 지금 돈이 어디서 많이 나가고 있지
• 알림은 걸어뒀나
• 이 구조가 AWS 권장 원칙에 맞는가

같은 질문이 더 중요해진다.

즉, 8회차는 기술 자체보다도 “AWS를 계속 잘 쓰는 법”을 배우는 회차였다.

시험 전에 다시 볼 포인트

짧게 압축하면:

• On-Demand는 유연하지만 장기적으로 더 비쌀 수 있다.
• Reserved Instances와 Savings Plans는 장기 사용량에 대한 할인 모델이다.
• Spot은 매우 저렴하지만 중단될 수 있다.
• Cost Explorer는 비용 분석 도구다.
• Budgets는 예산 초과 경고 도구다.
• Well-Architected Framework는 좋은 AWS 아키텍처 점검 기준이다.
• CAF는 조직의 클라우드 도입 프레임워크다.

8회차까지 오니 Cloud Practitioner가 왜 입문 자격증이면서도 꽤 넓은 범위를 다루는지 더 잘 이해됐다. 단순히 서비스를 쓰는 법이 아니라, 그 서비스를 어떻게 판단하고 운영할 것인가까지 보는 시험이기 때문이다.

다음 글에서는 2월 3일 문제풀이 회차를 정리하거나, 실제 시험 직전 복기와 합격 후기를 이어서 정리할 예정이다.