시험 대비 · 도메인 4
비용 최적화 아키텍처 설계 (20%)
Design Cost-Optimized Architectures는 가중치가 가장 작지만 가장 적은 노력으로 가장 확실하게 점수가 오르는 도메인입니다. 판단 규칙이 단순하고 반복되기 때문입니다. 그리고 이 도메인은 금액을 외우는 시험이 아닙니다 — 무엇이 시간당 과금되고 무엇이 그렇지 않은지, 어느 방향의 전송이 과금되는지 같은 구조를 묻습니다.
학습 목표
- 과제 진술 4.1부터 4.4까지가 각각 무엇을 묻는지 구분하고 담당 챕터를 지목할 수 있습니다.
- 금액을 모르는 상태에서도 과금 구조를 근거로 더 저렴한 구성을 고를 수 있습니다.
- 접근 빈도와 검색 시간 요구로 S3 스토리지 클래스를 선택할 수 있습니다.
- 워크로드의 중단 허용 여부와 사용 기간으로 EC2 구매 옵션을 선택할 수 있습니다.
- 데이터 전송의 방향에 따라 과금 여부가 달라진다는 것을 설계 판단에 반영할 수 있습니다.
- 이 도메인의 판단 지점 15개를 점검표로 삼아 자기 취약 지점을 찾을 수 있습니다.
이 도메인의 성격
| 과제 진술 | 중심 질문 | 주 담당 챕터 |
|---|---|---|
| 4.1 비용 최적화 스토리지 | 얼마나 자주 읽는가. 접근 빈도와 검색 시간 요구가 티어를 결정합니다 | 8장 S3 · 9장 파일 스토리지 |
| 4.2 비용 최적화 컴퓨팅 | 얼마나 오래, 얼마나 확실하게 쓰는가. 중단 허용 여부와 약정 가능성 | 5장 EC2 · 18장 비용 |
| 4.3 비용 최적화 데이터베이스 | 부하가 항상 있는가. 유휴 시간이 길면 다른 답이 나옵니다 | 10장 RDS · 11장 NoSQL |
| 4.4 비용 최적화 네트워크 | 트래픽이 어느 경계를 넘는가. 방향과 경유 지점이 과금을 만듭니다 | 4장 VPC 연결 · 18장 비용 |
금액 없이 비용을 판단하는 법
시험은 요금표를 외웠는지 묻지 않습니다. 요금은 리전과 시점에 따라 달라지므로 문항의 근거가 될 수 없습니다. 대신 과금이 발생하는 구조를 묻습니다. 판단에 쓰는 축은 세 가지입니다.
| 축 | 묻는 것 | 적용 예 |
|---|---|---|
| 상시 가동 자원이 있는가 | 쓰지 않는 동안에도 시간이 흐르면 과금되는 자원이 존재하는가 | NAT 게이트웨이는 시간당 자원이 상시 가동되지만, 게이트웨이 VPC 엔드포인트는 라우팅 테이블의 경로라 그런 자원이 없습니다 |
| 경계를 몇 번 넘는가 | 데이터가 가용 영역·리전·인터넷 경계를 넘는 횟수 | 단일 NAT 게이트웨이에 여러 가용 영역이 붙으면 가용 영역 경계를 한 번 더 넘습니다 |
| 관리 주체가 누구인가 | 같은 결과를 얻는 데 사람의 운영 시간이 얼마나 드는가 | 직접 운영하는 인스턴스는 요금 외에 운영 비용이 계속 듭니다. 관리형이 총비용에서 유리한 근거입니다 |
과제 진술 4.1 · 비용 최적화 스토리지 솔루션 설계
스토리지 비용 문항의 판단 축은 접근 빈도와 허용 가능한 검색 시간입니다. 둘 다 문제문에 거의 언제나 명시되어 있습니다. "분기에 한 번 감사용으로 조회한다"거나 "몇 시간 안에만 꺼내면 된다" 같은 문장이 그것입니다.
S3 스토리지 클래스 선택 SAA 빈출
| 클래스 | 가용 영역 수 · 최소 저장 기간 · 최소 청구 크기 | 고르는 신호 |
|---|---|---|
| S3 Standard | 3개 이상 · 최소 기간 없음 · 최소 크기 없음 | 자주 읽습니다. 기본값입니다 |
| S3 Standard-IA | 3개 이상 · 30일 · 128 KB | 드물게 읽지만 읽을 때는 즉시 필요하고, 가용 영역 장애를 견뎌야 합니다 |
| S3 One Zone-IA | 1개 · 30일 · 128 KB | 드물게 읽고 잃어도 다시 만들 수 있는 사본입니다 |
| S3 Glacier Instant Retrieval | 3개 이상 · 90일 · 128 KB | 거의 읽지 않지만 읽을 때는 즉시 필요합니다 |
| S3 Glacier Flexible Retrieval | 3개 이상 · 90일 · 40 KB | 보관이 목적이고 분에서 시간 단위의 복원 대기를 허용합니다 |
| S3 Glacier Deep Archive | 3개 이상 · 180일 · 40 KB | 규정상 장기 보관이고 기본 검색 시간 12시간을 허용합니다 |
| S3 Intelligent-Tiering | 3개 이상 · 최소 기간 없음 · 최소 크기 없음 | 접근 패턴을 모르거나 변합니다. 모니터링과 자동 계층화 요금이 별도로 붙습니다 |
표에서 비용 판단에 직접 쓰이는 값은 최소 저장 기간입니다. 30일 미만으로 지웠다 다시 쓰는 데이터를 Standard-IA에 두면 저장 기간을 채우지 않아도 그 기간만큼 요금이 부과되므로 오히려 손해입니다. "매주 갱신되는 데이터"에 IA 계열을 고르는 선택지는 대개 함정입니다.
S3 Intelligent-Tiering은 접근 패턴을 모를 때의 답입니다. 수명 주기 규칙은 "며칠 뒤에 어디로"를 미리 정해야 하지만, Intelligent-Tiering은 실제 접근 여부에 따라 계층을 옮깁니다. 반대로 접근 패턴이 명확하다면 수명 주기 규칙이 더 단순하고 저렴합니다.
수명 주기 규칙과 정리
수명 주기 규칙은 전환(transition)과 만료(expiration) 두 가지 일을 합니다. 비용 문항에서 자주 함께 나오는 세 가지 정리 대상이 있습니다.
| 대상 | 방치했을 때 | 규칙 |
|---|---|---|
| 오래된 객체 | 자주 읽지 않는데 Standard 요금을 계속 냅니다 | 일정 기간 후 IA·Glacier 계열로 전환 |
| 이전 버전 | 버전 관리를 켜면 덮어쓴 이전 버전이 계속 쌓입니다 | 비현재 버전의 전환·만료 규칙 |
| 불완전한 멀티파트 업로드 | 실패한 업로드의 조각이 목록에 보이지 않은 채 저장 요금을 발생시킵니다 | 일정 기간 후 자동 중단 규칙 |
128 KB 미만 객체는 IA 계열이나 Glacier Instant Retrieval로 전환되지 않습니다. 작은 파일이 아주 많은 워크로드에서 "수명 주기로 옮기면 싸진다"는 판단이 성립하지 않는 이유입니다. 전환 요청 자체에도 요청 요금이 붙으므로, 객체 수가 많을수록 전환의 이득이 줄어듭니다.
과제 진술 4.2 · 비용 최적화 컴퓨팅 솔루션 설계
컴퓨팅 비용 문항은 두 질문으로 갈립니다. 중단되어도 되는가와 얼마나 오래 쓸 것을 약속할 수 있는가입니다. 이 두 질문의 답만 정하면 구매 옵션은 자동으로 결정됩니다.
EC2 구매 옵션 SAA 빈출
| 옵션 | 성격 | 고르는 신호 |
|---|---|---|
| 온디맨드 | 약정 없이 쓴 만큼 지불합니다 | 기간을 예측할 수 없는 단기·불규칙 워크로드, 신규 서비스의 초기 |
| 스팟 인스턴스 | 여유 용량을 쓰며 회수되면 중단됩니다 | 중단되어도 되는 배치·렌더링·CI 작업, 상태 비저장 워커 |
| Savings Plans | 일정 기간의 시간당 지출 금액을 약정하고, 조건에 맞는 사용량에 자동 적용됩니다 | 상시 가동되는 기저 부하가 있고, 인스턴스 패밀리나 리전이 바뀔 여지가 있습니다 |
| 예약 인스턴스 | 인스턴스 속성에 대한 약정입니다. 존 단위 예약은 용량까지 확보합니다 | 구성이 고정되어 있고 용량 예약이 필요합니다 |
| 전용 호스트 · 전용 인스턴스 | 물리 서버를 전용으로 사용합니다 | 서버 바인딩 라이선스나 규정상 물리적 격리가 요구될 때만 |
실제 설계에서는 이 옵션들을 섞습니다. 상시 기저 부하는 Savings Plans나 예약 인스턴스로, 변동분은 온디맨드로, 중단 가능한 작업은 스팟으로 나누는 구성이 비용 문항의 표준 정답 형태입니다. 선택지에 "전부 스팟으로 바꾼다"가 있으면 대개 요구를 위반합니다.
서버리스가 유리한 경우와 불리한 경우
AWS Lambda와 AWS Fargate는 유휴 시간에 과금되지 않는다는 점에서 비용을 줄입니다. 요청이 드문드문 들어오는 워크로드, 하루 몇 분만 도는 작업이 대표적입니다.
반대로 부하가 일정하게 높고 계속 도는 워크로드에서는 서버리스가 오히려 비쌀 수 있습니다. 상시 가동되는 자원을 약정 옵션으로 할인받을 수 있기 때문입니다. "비용 최적화"라는 한정어만 보고 무조건 서버리스를 고르면 이 지점에서 틀립니다.
라이트사이징과 자동 종료
가장 확실한 절감은 쓰지 않는 자원을 끄는 것입니다. 개발·테스트 환경을 업무 시간 외에 중지하는 구성, 연결되지 않은 Elastic IP와 사용하지 않는 EBS 볼륨·스냅샷 정리가 여기 속합니다.
도구는 역할이 나뉩니다. AWS Compute Optimizer는 지표를 근거로 인스턴스 크기를 제안하고, AWS Trusted Advisor는 비용·성능·보안·내결함성·서비스 한도를 점검합니다. "어떤 인스턴스를 줄여야 하는지 알고 싶다"면 Compute Optimizer입니다.
과제 진술 4.3 · 비용 최적화 데이터베이스 솔루션 설계
데이터베이스 비용 문항의 첫 질문은 유휴 시간이 있는가입니다. 24시간 일정한 부하와, 하루 두 시간만 쓰이고 나머지는 비어 있는 부하는 전혀 다른 답으로 이어집니다.
| 부하 패턴 | 선택 | 근거 |
|---|---|---|
| 예측 가능한 상시 부하 | Amazon RDS 또는 Amazon Aurora의 프로비저닝된 인스턴스 + 약정 옵션 | 상시 가동 자원을 약정으로 할인받는 구조가 가장 단순합니다 |
| 간헐적이거나 예측 불가한 부하 | Amazon Aurora Serverless v2 | 용량이 부하에 따라 조정되므로 유휴 구간에 과잉 프로비저닝을 유지하지 않습니다 |
| 키-값 접근이고 트래픽이 들쭉날쭉 | Amazon DynamoDB 온디맨드 모드 | 요청 단위 과금이라 유휴 구간의 부담이 없습니다 |
| 키-값 접근이고 트래픽이 안정적 | Amazon DynamoDB 프로비저닝된 모드 + 오토 스케일링 | 예측 가능한 용량을 미리 잡는 편이 유리합니다. 모드는 나중에 변경할 수 있습니다 |
| 읽기 부하가 반복 조회 위주 | 캐시 계층 추가 | 인스턴스 크기를 키우는 것보다 저렴하게 읽기를 흡수합니다 |
저장 비용도 함께 봅니다. 백업 보존 기간과 수동 스냅샷은 지우기 전까지 남습니다. 자동 백업은 보존 기간이 지나면 사라지지만 수동 스냅샷은 그렇지 않으므로, "스냅샷이 계속 쌓여 비용이 는다"는 시나리오의 답은 스냅샷 수명 정책입니다.
마이그레이션 문항이 비용과 함께 나오는 경우도 있습니다. 6R 전략 가운데 리호스트(Rehost)는 빠르지만 클라우드 이점을 덜 얻고, 리플랫폼(Replatform)은 관리형 서비스로 옮겨 운영 비용을 줄이며, 리팩터(Refactor)는 가장 큰 절감을 낼 수 있지만 노력이 가장 큽니다. "최소한의 변경으로 빠르게"면 리호스트, "운영 부담을 줄이려면"이면 리플랫폼입니다.
과제 진술 4.4 · 비용 최적화 네트워크 아키텍처 설계
네트워크 비용은 방향과 경계가 전부입니다. 같은 양의 데이터라도 어디에서 어디로 가는지에 따라 과금 여부가 달라집니다. 이 규칙 하나만 알아도 이 진술의 문항 대부분이 풀립니다.
데이터 전송의 방향성
| 방향 | 과금 성격 | 설계에 주는 함의 |
|---|---|---|
| 인터넷에서 AWS로 들어오는 트래픽(인바운드) | 대체로 과금되지 않습니다 | 업로드가 많은 워크로드는 전송 비용 관점에서 유리합니다 |
| AWS에서 인터넷으로 나가는 트래픽(아웃바운드) | 과금됩니다 | 비용 절감의 주 대상입니다. 캐싱과 압축이 직접 효과를 냅니다 |
| 같은 가용 영역 안의 프라이빗 통신 | 경계를 넘지 않습니다 | 서로 통신이 잦은 구성 요소를 같은 가용 영역에 두면 전송이 줄어듭니다 |
| 가용 영역 사이 | 과금됩니다 | 가용성을 위해 감수하는 비용입니다. 불필요한 왕복을 만들지 않는 것이 요령입니다 |
| 리전 사이 | 과금됩니다 | 교차 리전 복제와 다중 리전 DR의 비용 근거입니다 |
| NAT 게이트웨이를 경유 | 상시 가동 자원 요금과 처리 데이터 요금이 함께 붙습니다 | 프라이빗 서브넷에서 AWS 서비스로 나가는 트래픽을 VPC 엔드포인트로 돌리는 근거입니다 |
NAT 게이트웨이 비용을 줄이는 판단
프라이빗 서브넷의 인스턴스가 Amazon S3나 Amazon DynamoDB에 접근할 때 NAT 게이트웨이를 경유하면 상시 가동 자원과 처리 데이터 양쪽에서 비용이 발생합니다. 게이트웨이 VPC 엔드포인트는 라우팅 테이블에 경로를 추가하는 방식이라 그런 상시 가동 자원이 없습니다. 보안 요구와 비용 요구가 같은 답을 가리키는 대표 사례입니다.
그 밖의 AWS 서비스는 인터페이스 VPC 엔드포인트로 접근합니다. 인터페이스 엔드포인트는 서브넷에 네트워크 인터페이스를 만들므로 게이트웨이 엔드포인트와 달리 자체 비용이 발생합니다. 따라서 "NAT를 거치는 트래픽 양"과 "엔드포인트 개수"를 견주는 판단이 필요합니다.
가용 영역 배치도 비용에 직접 영향을 줍니다. NAT 게이트웨이를 한 가용 영역에만 두고 여러 가용 영역의 프라이빗 서브넷을 붙이면, 가용 영역 장애에 취약해지는 동시에 가용 영역 간 전송 요금이 추가로 발생합니다. 가용 영역마다 하나씩 두고 라우팅 테이블을 분리하는 구성이 가용성과 비용 양쪽에서 낫습니다.
CloudFront로 오리진 송신을 줄이는 판단
Amazon CloudFront는 엣지에 콘텐츠를 캐싱하므로 오리진에서 인터넷으로 나가는 반복 전송을 줄입니다. 같은 파일을 여러 사용자가 반복해서 받는 워크로드에서 효과가 큽니다. 성능 요구와 비용 요구가 함께 나오면 CloudFront가 두 요구를 동시에 만족시킵니다.
반대로 캐시 적중률이 낮은 완전 개인화 응답이라면 캐싱으로 줄일 수 있는 오리진 전송이 거의 없습니다. "동적 콘텐츠라 캐싱이 되지 않는다"는 조건이 명시되면 다른 축에서 답을 찾아야 합니다.
하이브리드 연결과 대량 전송
| 상황 | 선택 | 판단 기준 |
|---|---|---|
| 회선 대역폭으로는 기한 안에 못 옮긴다 | AWS Snow Family | 물리 장비를 배송해 오프라인으로 옮깁니다. 대역폭과 기한이 결정 근거입니다 |
| 회선이 충분하고 주기적으로 동기화해야 한다 | AWS DataSync | 에이전트가 네트워크로 전송하고 일정에 따라 반복합니다 |
| 온프레미스에서 상시로 클라우드 스토리지를 쓴다 | AWS Storage Gateway | 기존 애플리케이션이 로컬 프로토콜을 그대로 쓰면서 뒤쪽을 S3로 둡니다 |
| 지속적으로 많은 양이 오간다 | AWS Direct Connect | 전용 회선이며 인터넷 아웃바운드보다 전송 단가가 낮은 구조입니다 |
비용 가시성 도구
네 진술 어디에도 속하지 않지만 반복해서 출제되는 갈래입니다. 세 도구의 역할이 겹치지 않으므로 동사만 보면 갈립니다.
| 도구 | 답하는 질문 | 고르는 신호 |
|---|---|---|
| AWS Cost Explorer | 어디에 얼마를 썼는가, 추세는 어떤가 | "분석한다", "시각화한다", "어느 서비스가 늘었는지 확인한다" |
| AWS Budgets | 한도를 넘었는가 | "임계값을 넘으면 알림을 받는다" |
| AWS Cost and Usage Report | 청구 항목 단위의 원본 데이터는 무엇인가 | "가장 상세한 데이터", "자체 분석 도구로 가져간다" |
비용을 부서·프로젝트 단위로 나눠 보려면 비용 할당 태그가 전제됩니다. "팀별로 비용을 파악하고 싶다"는 요구에는 태그 지정과 활성화가 먼저 나오고, 그 위에서 Cost Explorer로 분석하는 순서가 정답 형태입니다.
판단 지점 점검표 15개
아래는 이 도메인에서 반드시 판단할 수 있어야 하는 지점입니다. 각 행을 읽고 기준을 한 문장으로 말할 수 없다면 담당 챕터로 돌아갑니다.
| 번호 | 판단 지점 | 기준 | 담당 챕터 |
|---|---|---|---|
| 1 | EC2 구매 옵션 선택 | 중단 허용 여부와 약정 가능성. 대개 여러 옵션을 섞는 것이 답입니다 | 5장 |
| 2 | 스팟과 Savings Plans의 역할 분담 | 중단 가능한 작업은 스팟, 상시 기저 부하는 Savings Plans | 5장 · 18장 |
| 3 | S3 스토리지 클래스 선택 | 접근 빈도와 허용 검색 시간. 최소 저장 기간 30·90·180일에 주의 | 8장 |
| 4 | S3 Intelligent-Tiering을 쓰는 때 | 접근 패턴을 모르거나 변할 때. 패턴이 명확하면 수명 주기 규칙이 낫습니다 | 8장 |
| 5 | 수명 주기 규칙으로 정리할 대상 | 오래된 객체, 이전 버전, 불완전한 멀티파트 업로드 | 8장 |
| 6 | One Zone-IA의 교환 조건 | 가용 영역이 하나라 그 가용 영역 장애에 취약합니다. 재생성 가능한 사본에만 | 8장 |
| 7 | 데이터 전송의 방향성 | 인바운드는 대체로 무과금, 아웃바운드·가용 영역 간·리전 간은 과금 | 18장 |
| 8 | NAT 게이트웨이 비용을 엔드포인트로 줄이기 | S3·DynamoDB는 게이트웨이 엔드포인트. 상시 가동 자원이 없다는 점이 근거 | 4장 · 18장 |
| 9 | CloudFront로 오리진 송신 줄이기 | 반복 전송이 많을수록 효과가 큽니다. 개인화 응답은 효과가 작습니다 | 14장 · 18장 |
| 10 | 비용 가시성 도구 구분 | 분석은 Cost Explorer, 알림은 Budgets, 원본 데이터는 Cost and Usage Report | 18장 |
| 11 | 라이트사이징 | 크기 제안은 Compute Optimizer, 폭넓은 점검은 Trusted Advisor | 18장 |
| 12 | 서버리스가 비용을 줄이는 경우와 늘리는 경우 | 유휴가 길면 유리, 일정한 고부하면 약정 옵션이 유리할 수 있습니다 | 12장 · 18장 |
| 13 | Aurora Serverless v2를 쓰는 때 | 간헐적·예측 불가한 부하. v1은 지원이 종료되었습니다 | 10장 · 18장 |
| 14 | 마이그레이션 6R 전략의 비용과 노력 | 빠른 이전은 리호스트, 운영 비용 절감은 리플랫폼, 최대 절감은 리팩터 | 18장 |
| 15 | 대용량 전송 수단 선택 | 대역폭과 기한이면 Snow Family, 주기적 동기화면 DataSync, 상시 접근이면 Storage Gateway | 9장 · 18장 |
이 도메인의 함정
도메인 미니 퀴즈
이 도메인의 판단 지점을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.
이어서 볼 곳
- 18장 · 비용 최적화·마이그레이션·재해 복구 이 도메인의 본체입니다. 데이터 전송 요금 구조, 구매 옵션 전략, 6R 마이그레이션을 다룹니다.
- 8장 · S3와 오브젝트 스토리지 과제 진술 4.1의 본체입니다. 스토리지 클래스 전체와 수명 주기 규칙을 정면으로 다룹니다.
- 함정 사전 이 도메인에서 자주 뒤집히는 쌍 — Standard-IA와 One Zone-IA, 예약 인스턴스와 Savings Plans를 모았습니다.
- 한정어 키워드 사전 MOST cost-effective가 무엇을 가리키고, 제약을 위반하는 저렴한 선택지를 왜 먼저 버려야 하는지 다룹니다.
- 케이스 3 · S3 비용이 매달 늘어난다 스토리지 클래스와 수명 주기, 불완전 멀티파트 업로드를 실제 사례로 따라갑니다.
- 비용 빠른참조 요금 모델 요약과 데이터 전송 방향 지도, 절감 레버를 표로 모았습니다.
공식 문서 출처
- SAA-C03 시험 가이드 — 도메인 4의 가중치 20%와 과제 진술 네 개
- Amazon S3 사용 설명서 — 스토리지 클래스 사용 — 클래스별 가용 영역 수, 최소 저장 기간, 최소 청구 크기
- Amazon S3 사용 설명서 — 수명 주기 전환 시 일반 고려 사항 — 30일 전환 제약과 128 KB 미만 객체가 전환되지 않는다는 서술
- Amazon S3 사용 설명서 — 멀티파트 업로드 — 완료되지 않은 업로드가 남아 저장 요금을 발생시킨다는 서술
- Amazon EC2 사용 설명서 — 인스턴스 구매 옵션 — 온디맨드·스팟·예약 인스턴스·전용 호스트의 성격
- AWS Savings Plans 사용 설명서 — 시간당 지출 약정 모델과 적용 방식
- Amazon DynamoDB API 레퍼런스 — CreateTable — 온디맨드와 프로비저닝된 용량 모드의 권고 기준, 모드 변경 가능성
- Amazon VPC 사용 설명서 — VPC 엔드포인트 — 게이트웨이 엔드포인트와 인터페이스 엔드포인트의 구조 차이
- AWS Billing and Cost Management 사용 설명서 — Cost Explorer, Budgets, Cost and Usage Report의 역할
- AWS 백서 — AWS 개요 — 데이터 전송 방향에 따른 과금 성격의 개괄