학습 목표

이 도메인의 성격

SAA-C03 도메인별 출제 비중에서 비용 최적화 아키텍처 설계는 20%로 가장 작습니다. 그러나 과제 진술이 4개이고 판단 규칙이 단순해 학습 효율은 가장 높습니다. 가중치가 작다고 후순위로 미룰 도메인이 아닙니다
도메인 4의 과제 진술 네 개와 중심 질문
과제 진술 중심 질문 주 담당 챕터
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 스토리지 클래스의 확인된 제약과 선택 신호
클래스 가용 영역 수 · 최소 저장 기간 · 최소 청구 크기 고르는 신호
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 빈출

EC2 구매 옵션과 고르는 신호
옵션 성격 고르는 신호
온디맨드 약정 없이 쓴 만큼 지불합니다 기간을 예측할 수 없는 단기·불규칙 워크로드, 신규 서비스의 초기
스팟 인스턴스 여유 용량을 쓰며 회수되면 중단됩니다 중단되어도 되는 배치·렌더링·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개

아래는 이 도메인에서 반드시 판단할 수 있어야 하는 지점입니다. 각 행을 읽고 기준을 한 문장으로 말할 수 없다면 담당 챕터로 돌아갑니다.

도메인 4 비용 최적화 아키텍처 설계의 판단 지점과 담당 챕터
번호 판단 지점 기준 담당 챕터
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로 제출합니다.

이어서 볼 곳

공식 문서 출처