[SAA Ch-04] 비용 최적화 아키텍처 설계: 무엇에 요금이 붙는지부터 센다

결론부터

1. 비용 문제는 요금이 붙는 단위를 세면 풀립니다. S3는 저장량, 요청 수, 꺼내는 양, 최소 보관 기간에 요금이 붙고 NAT 게이트웨이는 시간과 처리한 GB에, Transit Gateway는 연결 시간과 처리량에 붙습니다. 보기 중 이 단위를 줄이는 쪽이 정답입니다.
2. 스토리지는 접근 패턴을 아는지가 갈림길입니다. 패턴을 알면 수명 주기 규칙으로 클래스를 내리고 모르면 Intelligent-Tiering입니다. 128KB보다 작은 객체는 기본적으로 수명 주기 전환 대상이 아니고 Intelligent-Tiering에서도 자동 계층 이동을 하지 않습니다.
3. 컴퓨팅은 꾸준한 기준 부하에 약정(Savings Plans 최대 72%), 중단해도 되는 작업에 Spot(최대 90%), 나머지에 On-Demand를 섞습니다. AWS는 Reserved Instances보다 Savings Plans를 권합니다. 크기는 Compute Optimizer의 권고(기본 14일 지표)로 맞춥니다.
4. 데이터베이스는 부하 모양으로 고릅니다. 한가한 시간이 긴 관계형은 Aurora Serverless v2(0 ACU까지 축소 가능), 예측 어려운 키-값은 DynamoDB 온디맨드, 꾸준하면 프로비저닝입니다. Aurora는 I/O 지출이 전체의 25% 이상이면 I/O-Optimized가 낫다고 문서가 적습니다.
5. 네트워크 비용은 트래픽 경로로 줄입니다. 사설 서브넷에서 S3, DynamoDB로 가는 트래픽은 추가 요금이 없는 게이트웨이 엔드포인트로 돌리고 NAT 게이트웨이는 같은 AZ에 둡니다. AWS 오리진에서 CloudFront로 가는 전송은 무료입니다.

---

1. 영역 4를 읽는 법

시험 안내서의 영역 4는 과제 네 개(4.1 스토리지, 4.2 컴퓨팅, 4.3 데이터베이스, 4.4 네트워크)로 나뉩니다(2026년 10월 19일 확인). 눈에 띄는 점은 네 과제 모두 지식 항목 앞부분에 같은 두 줄이 반복된다는 것입니다(4.1은 요청자 지불 항목 다음에 나옵니다).

• 비용 관리 서비스 기능(예: 비용 할당 태그, 다중 계정 결제)
• 비용 관리 도구와 용도(예: Cost Explorer, Budgets, Cost and Usage Report)

그래서 이 글은 도구를 2절에서 먼저 정리하고 3~6절에서 과제별로 들어갑니다. 영역 3(Ch-03)이 같은 네 축을 “빠르게”의 관점으로 봤다면 여기서는 “같은 요구를 더 싸게”의 관점으로 다시 봅니다.

2. 비용 관리 도구와 기능

2-1. Cost Explorer, Budgets, Cost and Usage Report

Budgets 문서는 예산 유형을 여섯 가지로 나눕니다. 비용 예산, 사용량 예산, RI 사용률과 RI 적용률(coverage) 예산, Savings Plans 사용률과 적용률 예산입니다. 실제 지출과 예측 지출 둘 다로 알림을 걸 수 있고 알림은 이메일이나 SNS로 갑니다. 문서는 사용과 청구 사이에 지연이 있어서 알림이 오기 전에 한도를 넘을 수 있다고도 적습니다. 예산 조치(budget action)로 사용자 지정 IAM 정책을 붙여 추가 리소스 생성을 막는 예가 문서에 있습니다.

CUR은 시간, 일, 월 단위로 서비스, 리소스, 태그별 비용을 S3 버킷에 보냅니다. 기존 CUR은 이제 문서에서 레거시로 분류되고 AWS는 Data Exports의 CUR 2.0을 권합니다. 내보내기는 하루 최소 한 번 CSV나 Parquet 파일로 쌓이고 Athena, Redshift, Amazon Quick과 연동할 수 있습니다.

2-2. 비용 할당 태그

“Organizing and tracking costs using AWS cost allocation tags” 문서 기준입니다.

• AWS 생성 태그(aws: 접두사, 예: aws:createdBy)와 사용자 정의 태그(user: 접두사) 두 종류가 있습니다.
• 두 종류 모두 결제 콘솔에서 따로 활성화해야 Cost Explorer와 비용 할당 보고서에 나타납니다. 활성화한 뒤 콘솔에 보이기까지 최대 24시간이 걸립니다.
• 조직에서는 관리 계정(과 조직에 속하지 않은 단일 계정)만 비용 할당 태그 관리자에 접근합니다.

“리소스에 Project 태그를 달았는데 Cost Explorer에서 태그별로 나눠 보이지 않는다”는 문제의 답은 태그 활성화입니다.

2-3. 다중 계정 결제(통합 결제)

“Consolidating billing for AWS Organizations” 문서는 통합 결제의 이점을 네 가지로 적습니다. 청구서 하나, 계정 간 비용 추적, 사용량 합산으로 볼륨 할인과 RI 할인과 Savings Plans를 공유, 추가 요금 없음입니다. 관리 계정이 모든 멤버 계정의 요금을 냅니다. 개발, 운영, 분석 계정을 나눠 쓰는 회사에서 S3 단계별 요금이나 RI를 합산해 쓰고 싶다는 조건이면 Organizations 통합 결제입니다.

2-4. Trusted Advisor와 Support 플랜

Trusted Advisor도 범위 안 서비스이고 비용 절감 권고를 냅니다. 지원 문서(2026년 10월 20일 확인)는 Basic Support 플랜에서는 Service Limits 범주 전체와 Security, Fault tolerance 범주 일부 검사만 쓸 수 있고 전체 검사(비용 최적화 포함)와 API는 Business Support+, Enterprise Support, Unified Operations 플랜에서 쓴다고 적습니다. 같은 문서는 Developer Support, Business Support, Enterprise On-Ramp가 2027년 1월 1일에 종료된다고 공지합니다. Developer와 Business 고객은 Business Support+로 옮기고 Enterprise On-Ramp 고객은 2026년 중에 Enterprise Support로 자동 전환됩니다. GovCloud(US) 리전에서는 기존 플랜이 유지됩니다.

기존 강의 자료의 “Business 이상이면 Trusted Advisor 전체 검사”라는 문장은 플랜 이름만 바뀌는 중이라 의미는 같습니다. 시험 문항이 새 플랜 이름을 쓰는지는 알 수 없습니다. “유휴 리소스와 적정 크기 권고”가 단독으로 나오면 Compute Optimizer(4-3절), “여러 범주의 모범 사례 점검과 서비스 한도 확인”이면 Trusted Advisor로 구분했습니다.

3. 과제 4.1 비용 최적화 스토리지

3-1. 저장 클래스를 고르는 순서

S3 클래스별 가용성, AZ 수, 최소 보관 기간은 Ch-00 4-2절 표에 있습니다. 여기서는 고르는 순서를 정리합니다.

“다시 만들 수 있다”는 조건은 One Zone-IA를 고르는 근거입니다. 원본은 다른 곳에 있고 썸네일처럼 재생성 가능한 사본이면 AZ 하나를 잃어도 다시 만들면 됩니다.

3-2. 수명 주기 규칙의 제약

“Transitioning objects using Amazon S3 Lifecycle” 문서의 제약은 보기를 지우는 데 바로 쓰입니다.

• 전환은 폭포(waterfall) 방향으로만 갑니다. Standard에서 아래 모든 클래스로, Standard-IA에서 Intelligent-Tiering, One Zone-IA, Glacier 계열로, Glacier Flexible Retrieval에서는 Deep Archive로만 갑니다. Deep Archive에서는 수명 주기로 다른 클래스로 갈 수 없고 복원 후 복사해야 합니다.
• 128KB보다 작은 객체는 기본적으로 어떤 클래스로도 전환하지 않습니다(2024년 9월 변경). 객체마다 전환 요청 요금이 붙어 작은 객체는 전환 비용이 절감액보다 클 수 있기 때문입니다. 객체 크기 필터로 바꿀 수 있습니다.
• 최소 보관 기간 전에 클래스를 옮기면 남은 기간 요금을 냅니다. 한 규칙 안에서 최소 기간이 지나기 전 다음 전환을 걸 수 없습니다. 문서 예시로 Glacier Instant Retrieval(최소 90일)로 4일째 옮겼다면 Deep Archive 전환은 최소 94일째 이후여야 합니다.
• Glacier Flexible Retrieval과 Deep Archive로 보낸 객체에는 객체마다 40KB가 더 붙습니다. 8KB는 Standard 요금, 32KB는 해당 Glacier 요금입니다. 작은 객체를 많이 보관하면 묶어서 큰 객체로 만드는 편이 싸다고 문서가 적습니다.

수명 주기의 만료(expiration) 동작으로 객체를 지울 수도 있습니다. 쇼핑몰 주문 영수증 PDF를 “30일 Standard, 이후 Glacier Instant Retrieval, 5년 뒤 삭제”로 관리하는 규칙이 데이터 수명 주기 항목의 전형입니다.

3-3. Intelligent-Tiering 계층

“How S3 Intelligent-Tiering works” 문서 기준입니다.

객체당 소액의 모니터링과 자동화 요금이 붙고 Ch-00에서 정리했듯 꺼낼 때 요금은 없습니다. 128KB보다 작은 객체는 모니터링하지 않고 항상 Frequent Access 계층 요금으로 저장합니다. 자동 계층에 있는 객체를 다시 읽으면 Frequent Access로 돌아갑니다. 선택 계층 두 개는 비동기로 읽어도 되는 애플리케이션일 때만 켜라고 문서가 적습니다.

3-4. 접근 옵션: 요청자 지불(Requester Pays)

안내서 4.1의 첫 지식 항목이 “요청자 지불 버킷”입니다. 문서(“Using Requester Pays general purpose buckets”) 기준입니다.

• 요청자가 요청 비용과 다운로드 전송 비용을 내고 버킷 소유자는 저장 비용만 냅니다.
• 익명 접근이 허용되지 않습니다. 모든 요청은 인증되어야 하고 요청자는 x-amz-request-payer 헤더(또는 CLI의 --request-payer)로 비용 부담에 동의해야 합니다.
• 큰 공개 데이터셋(우편번호, 지리 정보, 웹 크롤링 데이터)을 공유하면서 남이 내려받는 비용을 지고 싶지 않을 때 씁니다.

“연구 기관 여러 곳에 대용량 데이터셋을 제공하는데 전송 비용은 받는 쪽이 내야 한다”가 요청자 지불입니다.

3-5. EBS 비용: 볼륨 유형, 크기, 스냅샷

블록 스토리지 옵션(HDD와 SSD 볼륨 유형)은 Ch-03 2-3절의 표를 비용 관점으로 다시 읽으면 됩니다.

• gp3는 gp2보다 GiB당 가격이 20% 낮고 성능을 크기와 따로 정합니다. Elastic Volumes로 인스턴스를 멈추지 않고 유형을 바꿉니다. Elastic Volumes 문서(2026년 10월 20일 확인)는 크기는 늘릴 수만 있고 줄일 수 없으며 줄이려면 작은 볼륨을 새로 만들어 rsync 같은 도구로 옮기라고 적습니다. 한 볼륨은 24시간 동안 최대 4번 수정할 수 있습니다. gp2를 gp3로 바꾸며 IOPS를 지정하지 않으면 원래 gp2 성능과 gp3 기준 성능 중 높은 쪽으로 자동 설정됩니다.
• 큰 순차 I/O면 st1, 접근이 드물고 저장 비용이 가장 중요하면 sc1입니다. 둘 다 부트 볼륨은 안 됩니다.
• Compute Optimizer가 EBS 볼륨 권고도 냅니다(4-3절).

스냅샷은 기본 Standard 계층에서 증분(바뀐 블록만)으로 저장됩니다. “Archive Amazon EBS snapshots” 문서의 아카이브 계층은 다르게 동작합니다.

문서는 한 볼륨의 일일 증분 스냅샷을 아카이브하면 Standard에 두는 것보다 비쌀 수 있다고 경고합니다. 증분이 전체로 바뀌기 때문입니다. “규정상 7년 보관, 거의 복원하지 않음”은 아카이브 계층이고 “매일 백업, 빠른 복원”은 Standard입니다.

3-6. 파일 스토리지 비용

EFS 문서는 Elastic 처리량에서 읽거나 쓴 메타데이터와 데이터 양에만 요금을 낸다고 적습니다. 부하가 가끔 튀는 공유 디렉터리는 처리량을 미리 사 두는 Provisioned보다 Elastic이 맞는 경우가 많습니다. EFS 수명 주기 정책의 기본값은 30일 동안 접근하지 않으면 IA, 90일이면 Archive로 옮기는 것입니다. 일수는 1, 7, 14, 30, 60, 90, 180, 270, 365일 중에서 고르고 IA나 Archive의 파일을 첫 접근 때 Standard로 되돌리는 설정도 있습니다.

3-7. AWS로 데이터를 옮기는 가장 싼 방법

안내서 기술 항목에 “워크로드의 데이터를 AWS 스토리지로 옮기는 가장 저렴한 방법”과 “배치 업로드와 개별 업로드 비교”가 있습니다.

배치 업로드가 유리한 이유는 S3 요금이 요청 수에도 붙기 때문입니다. 3-2절의 128KB 기준과 40KB 오버헤드도 같은 방향을 가리킵니다.

3-8. 시험에서 갈리는 조건(스토리지)

4. 과제 4.2 비용 최적화 컴퓨팅

4-1. 구매 옵션

EC2 요금 페이지와 Savings Plans, Reserved Instances 문서 기준입니다(2026년 10월).

몇 가지 조건을 같이 기억합니다.

• Reserved Instances 문서 첫머리에 “Reserved Instances보다 Savings Plans를 권한다”는 문장이 있습니다. RI는 특정 인스턴스 구성에 약정하고 Savings Plans는 시간당 사용 금액에 약정합니다.
• RI는 실제 인스턴스가 아니고 조건이 맞는 On-Demand 사용에 붙는 청구 할인입니다. 자동으로 갱신되지 않아 만료되면 On-Demand 요금으로 돌아갑니다. 구매는 취소할 수 없고 수정, 교환, RI Marketplace 판매만 가능합니다.
• RI 범위(scope)는 가격에 영향을 주지 않습니다. 리전 RI는 용량을 예약하지 않는 대신 리전 안 모든 AZ에 할인이 붙고 같은 패밀리 안 크기 유연성(Linux/Unix 기본 테넌시)이 있습니다. 영역 RI는 지정한 AZ의 용량을 예약하고 AZ와 크기 유연성이 없습니다.
• 결제 방식은 전액 선결제, 부분 선결제, 선결제 없음 세 가지이고 선결제가 클수록 대체로 더 쌉니다.
• Spot은 회수 2분 전에 중단 알림이 EventBridge 이벤트와 인스턴스 메타데이터로 옵니다. 중단 동작을 최대 절전으로 정하면 알림은 오지만 2분 유예 없이 바로 시작합니다.
• Savings Plans에는 Database Savings Plans(최대 35%, 5-6절)와 SageMaker AI Savings Plans(최대 64%)도 있습니다. Savings Plans 유형 문서(2026년 10월 20일 확인)는 Compute Savings Plans가 테넌시(Dedicated, Dedicated Host)와 관계없이 적용되지만 Dedicated Instance가 하나라도 도는 리전마다 붙는 시간당 2달러 전용 요금은 Savings Plans로 할인되지 않는다고 적습니다.
• 용량 확보와 할인은 다른 문제입니다. EC2 구매 옵션 문서는 용량 예약이 필요하면 특정 AZ에 대한 RI나 Capacity Reservation을 사라고 적고 Savings Plans는 이 자리에 넣지 않습니다. “블랙프라이데이 당일 특정 AZ에 인스턴스 200대를 반드시 띄워야 함”은 On-Demand Capacity Reservation이고 할인까지 원하면 Savings Plans를 함께 겁니다.
• Dedicated Host와 Dedicated Instance는 둘 다 단일 테넌트지만 Dedicated Host는 물리 호스트 단위로 받아 소켓·코어 단위 기존 라이선스를 쓸 수 있습니다. “서버 단위 라이선스를 그대로 가져옴”은 Dedicated Host입니다.

4-2. 워크로드 등급별 가용성과 구매 옵션

안내서 기술 항목 “워크로드 등급별 필요한 가용성(운영과 비운영)“은 같은 서비스라도 등급마다 다른 옵션을 고르라는 뜻으로 읽힙니다.

Ch-00에서 본 공식 샘플 문항처럼 “중단할 수 없음”이 붙으면 Spot은 가장 싸도 오답입니다.

4-3. 인스턴스 패밀리와 크기 맞추기(rightsizing)

Compute Optimizer 문서는 리소스의 설정과 사용률 지표를 분석해 적정 크기 권고와 유휴 리소스를 알려 준다고 설명합니다.

• 지원 리소스: EC2 인스턴스, Auto Scaling 그룹, EBS 볼륨, Lambda 함수, Fargate 위 ECS 서비스, 상용 소프트웨어 라이선스, Aurora와 RDS, NAT 게이트웨이, DynamoDB, ElastiCache 등입니다.
• 옵트인이 필요하고 기본적으로 CloudWatch의 최근 14일 지표를 분석합니다. 유료 기능인 향상된 인프라 지표를 켜면 93일로 늘어납니다.
• 조직 관리 계정에서 옵트인하면 여러 계정의 권고를 한 곳에서 봅니다.

패밀리 선택 기준은 Ch-03 3-1절의 이름 읽기와 같습니다. 메모리 사용률은 높고 CPU는 한가하면 C에서 R로, 반대면 R에서 C로 옮기는 식입니다. Lambda 메모리 권고도 Compute Optimizer가 내는데 Lambda 문서는 x86_64 함수만 지원한다고 적습니다.

4-4. Graviton

AWS Graviton 제품 페이지(2026년 10월)는 Graviton 기반 인스턴스가 비교 가능한 x86 기반 EC2 인스턴스보다 최대 20% 저렴하고 같은 성능에 최대 60% 적은 에너지를 쓴다고 적습니다. 인스턴스 이름의 g 옵션(예: m7g, c7gn)이 Graviton입니다. 시험에서 “애플리케이션이 Arm에서 동작한다”, “가격 대비 성능 개선”이 조건이면 Graviton 패밀리로 옮기는 보기가 맞습니다. 강의 자료에 자주 나오는 “가격 대비 성능 최대 40% 향상”은 Graviton2 기반 M6g 인스턴스 페이지가 M5와 비교해 적은 수치이고 지금 Graviton 제품 페이지에는 없습니다.

4-5. 확장 방식: 수평, 수직, 최대 절전

EC2 최대 절전 문서는 부팅과 메모리 적재에 오래 걸리는 애플리케이션을 미리 데워 두는 용도를 듭니다. 원하는 상태까지 올린 뒤 최대 절전으로 두었다가 필요할 때 재개합니다. “개발 서버가 퇴근 후 꺼져야 하는데 켤 때마다 캐시를 다시 채우느라 20분 걸린다”면 최대 절전입니다.

4-6. Lambda, Fargate, EC2 중 무엇이 싼지

안내서는 이 셋을 예로 들어 “비용 효율적인 컴퓨팅 서비스와 용도”를 묻습니다. 요금 단위가 다르다는 점에서 출발합니다.

Compute Savings Plans가 EC2, Fargate, Lambda 모두에 적용된다는 점도 비교에 넣습니다. 세 서비스의 단가는 리전과 시점마다 달라 이 글에서는 적지 않았습니다.

4-7. 로드 밸런서와 하이브리드 컴퓨팅

안내서 4.2 기술 항목에 ALB(L7), NLB(L4), GWLB 비교가 있습니다. 비용 관점에서는 하나의 ALB가 호스트와 경로 규칙으로 여러 서비스를 나눌 수 있다는 점이 중요합니다. 서비스마다 로드 밸런서를 따로 만들 필요가 줄어듭니다. ELB 요금 페이지는 로드 밸런서가 떠 있는 시간과 분 단위로 쓴 용량 단위(ALB는 LCU, NLB는 NLCU, GWLB는 GLCU)에 요금을 매긴다고 적습니다. ALB의 LCU는 새 연결, 활성 연결, 처리 바이트, 규칙 평가 네 기준 중 가장 큰 값으로 셉니다.

지식 항목의 하이브리드 컴퓨팅 예시는 AWS Outposts, 분산 컴퓨팅 예시는 엣지 처리입니다. 지연이나 데이터 상주 요건 때문에 온프레미스에서 AWS 인프라를 써야 하는 경우가 Outposts의 문구입니다. Outposts 문서는 AWS 인프라와 서비스, API, 도구를 고객 시설로 확장해 낮은 지연과 로컬 데이터 처리 요건에 쓰는 완전관리형 서비스로 설명합니다. 1U와 2U Outposts 서버는 판매가 끝났습니다.

4-8. 시험에서 갈리는 조건(컴퓨팅)

5. 과제 4.3 비용 최적화 데이터베이스

5-1. 부하 모양으로 서비스 고르기

안내서 기술 항목은 “DynamoDB와 RDS 비교, 서버리스”를 예로 듭니다.

5-2. Aurora Serverless v2와 저장 구성

“How Aurora serverless works” 문서 기준입니다.

• 단위는 ACU이고 1 ACU는 약 2GiB 메모리와 그에 맞는 CPU, 네트워크입니다.
• 범위는 0~256 ACU입니다. 최소값 0은 자동 일시 정지(auto-pause)를 지원하는 엔진 버전(예: Aurora MySQL 3.08.0 이상, Aurora PostgreSQL 13.15, 14.12, 15.7, 16.3 이상)에서만 고를 수 있습니다. 부하가 없으면 0까지 내려갑니다.
• 0.5 ACU 단위까지 잘게 늘고 줄며 용량은 초 단위로 측정하고 ACU-시간으로 과금합니다.
• 소매, 게임, 스포츠 사이트의 주기적 프로모션, 필요할 때만 보고서를 만드는 DB, 개발과 테스트 환경이 문서가 드는 예시입니다. 꾸준한 부하에는 프로비저닝 클러스터가 맞다고 적습니다.

같은 Aurora라도 저장 구성으로 요금이 달라집니다. Aurora Standard는 I/O 요청 100만 건당 요금을 따로 내고 I/O-Optimized는 I/O 요금이 없는 대신 인스턴스와 저장 단가가 다릅니다. 문서 기준은 I/O 지출이 Aurora 전체 지출의 25% 이상이면 I/O-Optimized입니다. Standard에서 I/O-Optimized로는 30일에 한 번 바꿀 수 있습니다.

5-3. DynamoDB 용량 모드와 테이블 클래스

Ch-03 4-5절에서 본 대로 온디맨드는 요청당 요금, 프로비저닝은 프로비저닝한 시간당 용량에 요금을 냅니다. 비용 관점의 판단은 사용률입니다. 프로비저닝한 용량을 꾸준히 많이 쓰면 프로비저닝이 싸고 트래픽이 들쭉날쭉해 평소에 놀면 온디맨드가 쌉니다. 이 손익 분기점을 숫자로 계산하는 공식 예시는 이번에 찾지 않았습니다.

“DynamoDB table classes” 문서는 Standard-IA 테이블 클래스를 저장이 비용의 대부분인 테이블에 맞춘 클래스로 소개합니다. 예시는 애플리케이션 로그, 오래된 게시글, 전자상거래 주문 이력, 지난 게임 업적입니다. 테이블 클래스는 나중에 바꿀 수 있습니다.

5-4. 캐싱, 복제, 연결로 비용 줄이기

캐시 자체도 노드 요금이 드니 적중률이 낮으면 손해입니다. DAX 문서는 적중률 90% 이상에서 가장 잘 동작한다고 적습니다.

5-5. 백업과 보존 정책

안내서 기술 항목은 “스냅샷 빈도 같은 백업과 보존 정책 설계”를 듭니다. RDS 자동 백업 보존 기간은 0~35일이고 0이면 자동 백업이 꺼집니다(Multi-AZ DB 클러스터는 1~35일). RDS와 Aurora 모두 리전의 전체 DB 저장 용량의 100%까지는 백업 저장에 추가 요금이 없습니다. 복구 시점 목표(RPO)가 짧을수록 스냅샷 빈도와 저장량이 늘고 보존 기간이 길수록 저장 비용이 늡니다. EBS 스냅샷 문서는 AWS Backup으로 만든 스냅샷도 아카이브 계층으로 보낼 수 있다고 적으니 장기 보존분은 3-5절의 아카이브 계층으로 내리는 설계가 가능합니다.

5-6. Database Savings Plans

Savings Plans 문서(2026년 10월)는 Database Savings Plans를 Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Timestream, Neptune, Keyspaces, DMS, OpenSearch Service에 최대 35% 할인을 주는 약정으로 설명합니다. 엔진, 인스턴스 패밀리, 크기, AZ, 리전과 관계없이 최신 프로비저닝 인스턴스 세대에 적용되고 서버리스 사용에도 적용됩니다. RDS for Oracle에서 Aurora PostgreSQL로 옮기거나 RDS에서 DynamoDB로 옮겨도 할인이 유지된다는 예가 있습니다. 비교적 새로운 옵션이라 시험 문항에 반영됐는지는 모릅니다. 기존 강의에서는 RDS Reserved Instances가 DB 약정 할인의 답으로 나왔을 가능성이 큽니다.

5-7. 목적에 맞는 DB 유형과 이관

안내서 기술 항목은 “비용 효율적인 DB 유형(시계열 형식, 컬럼 형식)“과 “스키마와 데이터를 다른 위치나 다른 엔진으로 이관”을 듭니다.

범용 관계형 DB에 분석 쿼리까지 몰아넣으면 인스턴스를 키우게 됩니다. 분석은 컬럼 형식으로 빼는 편이 같은 요구를 더 싸게 처리합니다. Neptune 문서는 Gremlin, openCypher, SPARQL을 지원하는 완전관리형 그래프 DB로 설명하고 추천, 사기 탐지, 지식 그래프를 용도로 듭니다. Timestream for LiveAnalytics는 2025년 6월 20일부터 신규 고객을 받지 않고 AWS는 신규 고객에게 Timestream for InfluxDB를 권합니다.

이관 도구는 Ch-03 4-7절의 DMS와 DMS Schema Conversion(AWS SCT 변환 엔진을 쓰는 DMS의 관리형 기능) 또는 AWS SCT입니다. DMS 문서는 사용한 만큼만 내는 요금 모델이라고 적고 상용 엔진에서 RDS, Aurora, DynamoDB, S3 같은 관리형 서비스로 옮겨 비용을 줄이는 경우를 예로 듭니다.

5-8. 시험에서 갈리는 조건(데이터베이스)

6. 과제 4.4 비용 최적화 네트워크

6-1. 데이터 전송 요금의 방향

안내서 기술 항목은 “리전 간, AZ 간, 사설에서 공용으로” 가는 경로를 비용으로 비교하라고 합니다. 이번에 열어 본 문서에서 확인한 사실만 모으면 이렇습니다.

EC2 On-Demand 요금 페이지는 같은 AZ 안 전송은 무료이고 같은 리전의 AZ 사이 전송은 방향마다 GB당 0.01달러라고 적습니다. 리전 간 전송은 출발과 도착 리전에 따라 다르고 요금 데이터(2026년 10월 21일 요금 데이터)에서 버지니아에서 오하이오는 GB당 0.01달러, 서울에서 도쿄는 0.08달러였습니다. 원칙은 “같은 AZ, 같은 리전, 사설 경로일수록 싸다”로 정리하고 수치는 요금 페이지에서 다시 확인합니다.

6-2. NAT 게이트웨이 요금 구조

“Pricing for NAT gateways” 문서는 NAT 게이트웨이가 사용 가능한 시간마다, 그리고 처리한 GB마다 요금을 낸다고 적습니다. Amazon VPC 요금 페이지의 미국 동부(오하이오) 예시는 시간당 0.045달러, 처리한 GB당 0.045달러입니다(2026년 10월 19일 확인). 처리 요금은 출발지와 목적지와 관계없이 붙고 일반 데이터 전송 요금도 따로 붙습니다. 서울 리전은 시간당 0.059달러, 처리한 GB당 0.059달러입니다(2026년 10월 21일 요금 데이터).

같은 문서가 권하는 절감 방법은 두 가지입니다.

1. AZ를 건너는 트래픽이 많으면 리소스와 NAT 게이트웨이를 같은 AZ에 두거나 AZ마다 NAT 게이트웨이를 만듭니다.
2. NAT를 지나는 트래픽 대부분이 게이트웨이 엔드포인트나 인터페이스 엔드포인트를 지원하는 AWS 서비스로 간다면 엔드포인트를 만듭니다.

안내서 기술 항목 “공유 NAT 게이트웨이 하나와 AZ별 NAT 게이트웨이 비교”는 이 트레이드오프입니다.

2026년 10월 VPC 문서에는 리전 NAT 게이트웨이(regional NAT gateway)도 있습니다. 워크로드가 있는 AZ로 자동으로 확장하고 줄어들며 공용 서브넷이 필요 없습니다. 요금 페이지 예시는 시간 요금이 활성 AZ마다 붙어 AZ 3개면 시간당 0.135달러(오하이오)라고 적습니다. 사설 NAT는 지원하지 않습니다. 새 기능이라 시험에 반영됐는지는 모릅니다.

NAT 인스턴스와 비교한 “Compare NAT gateways and NAT instances” 문서의 핵심입니다.

AWS는 NAT 게이트웨이를 권합니다. 시험에서 NAT 인스턴스가 정답이 되는 경우는 “트래픽이 아주 적은 개발 환경에서 비용이 최우선이고 관리 부담을 감수”처럼 조건이 분명할 때로 보입니다. 이 판단은 문서에 직접 적힌 문장이 아니고 요금 구조에서 끌어낸 추론입니다.

6-3. VPC 엔드포인트: 게이트웨이와 인터페이스

사설 서브넷의 EC2가 NAT 게이트웨이를 통해 같은 리전 S3로 매일 수 TB를 올린다면 NAT 처리 요금이 GB마다 붙습니다. 게이트웨이 엔드포인트를 만들면 같은 트래픽이 추가 요금 없이 엔드포인트로 갑니다. 영역 4에서 가장 자주 나오는 조합으로 보입니다.

6-4. 연결 방식: 인터넷, VPN, Direct Connect

안내서는 “Direct Connect와 VPN과 인터넷 비교”와 “단일 VPN과 여러 VPN, Direct Connect 속도 같은 대역폭 할당”을 듭니다.

Direct Connect 문서는 포트가 활성화되거나 LOA 발급 후 90일 중 먼저 오는 시점부터 과금이 시작된다고 적습니다. 전용 연결의 포트 속도는 만든 뒤 바꿀 수 없어서 속도를 바꾸려면 새 연결을 만듭니다. 대역폭 할당 문제에서 “필요한 대역폭이 2Gbps”면 VPN 터널 하나로는 부족하고 ECMP로 여러 터널을 묶거나 Direct Connect 속도를 고르는 판단이 됩니다. 요금 페이지 기준 Site-to-Site VPN 연결은 오하이오와 서울 모두 시간당 0.05달러이고 Direct Connect 전용 포트는 시간당 1Gbps 0.30달러, 10Gbps 2.25달러(일본 제외)입니다. Direct Connect로 들어오는 전송은 무료입니다(2026년 10월 21일 요금 데이터).

6-5. 토폴로지: 피어링과 Transit Gateway

Transit Gateway 문서는 연결(attachment)마다 시간 요금, 처리한 트래픽 양에 요금을 낸다고 적습니다. VPC 피어링은 Ch-03 5-4절에서 본 대로 전이 라우팅을 지원하지 않습니다.

VPC 둘 사이에 트래픽이 아주 많고 전이 라우팅이 필요 없다면 연결 요금과 처리 요금이 없고 전송 요금만 붙는 피어링이 쌀 수 있습니다. 두 요금 구조는 VPC 피어링 문서와 Transit Gateway 요금 페이지에서 확인했고 “더 싸다”는 결론은 그 구조에서 끌어낸 판단입니다.

6-6. CDN과 엣지 캐싱

CloudFront 문서는 요금이 엣지에서 나가는 데이터 전송과 HTTP/HTTPS 요청에 붙는다고 적습니다. AWS 오리진에서 CloudFront로 가는 전송은 항상 무료입니다. 오리진(S3, ALB)에서 사용자에게 직접 나가던 전송을 CloudFront로 돌리면 오리진 쪽 전송 비용과 오리진 부하가 같이 줄어듭니다. 캐시 적중률이 높을수록 효과가 큽니다. 캐시 정책을 쓰지 않으면 기본 TTL은 24시간이고 캐시 정책이나 오리진 헤더로 조정합니다.

Global Accelerator도 안내서 4.4에 예시로 나오지만 캐시를 하지 않으니 비용 절감 수단이 되기는 어렵습니다. 성능과 고정 IP가 조건일 때의 서비스입니다(Ch-03 5-2절).

6-7. 조절(throttling) 전략과 기존 워크로드 검토

안내서 기술 항목 “적절한 조절 전략 선택”에 관해 이번 문서에서 확인한 것은 두 가지입니다. Lambda 할당량 문서는 API Gateway 기본 조절 한도가 초당 10,000건이고 Lambda 기본 동시 실행이 1,000이라 둘이 어긋날 수 있다고 적습니다. RDS Proxy는 한도를 넘는 연결을 대기시키거나 거부합니다. 뒤 단계가 감당할 만큼만 앞에서 받아 주면 뒤 단계를 최대 부하에 맞춰 키우지 않아도 됩니다. SQS로 요청을 쌓고 소비자가 정해진 속도로 처리하는 구성도 같은 효과를 냅니다.

“기존 워크로드의 네트워크 최적화 검토”는 VPC Flow Logs, Cost Explorer의 데이터 전송 항목, Compute Optimizer의 NAT 게이트웨이 권고(유휴 탐지)로 시작할 수 있습니다. Compute Optimizer가 NAT 게이트웨이를 지원 리소스로 적은 것은 확인했지만 어떤 권고를 내는지는 열어 보지 않았습니다.

6-8. 시험에서 갈리는 조건(네트워크)

7. 확인 문제

아래 문제는 공식 문서의 조건을 바탕으로 직접 만든 연습 문제입니다. 실제 시험 문항이나 문제 은행에서 가져오지 않았습니다.

문제 1. 쇼핑몰이 주문 영수증 PDF(평균 300KB)를 S3에 저장합니다. 첫 30일은 고객이 자주 내려받고 이후에는 거의 보지 않지만 요청이 오면 즉시 보여 줘야 합니다. 5년이 지나면 지워도 됩니다. 가장 비용 효율적인 구성은?

A. 처음부터 Glacier Deep Archive에 저장한다
B. Standard에 저장하고 수명 주기로 30일 후 Glacier Instant Retrieval, 5년 후 만료
C. Standard에 저장하고 수명 주기로 30일 후 Glacier Flexible Retrieval, 5년 후 만료
D. 모든 객체를 One Zone-IA에 저장한다

정답과 해설

B입니다. 30일 뒤에는 접근이 드물지만 즉시(밀리초) 보여 줘야 하니 Glacier Instant Retrieval이 맞고 만료 동작으로 5년 뒤 지웁니다. 객체가 128KB보다 커서 기본 전환 대상입니다. A와 C는 복원 대기 시간이 있어 “즉시” 조건을 만족하지 못합니다. D는 영수증이 다시 만들 수 없는 원본이라 AZ 하나를 잃으면 데이터를 잃습니다.

문제 2. 사진 공유 앱의 사용자 업로드는 어떤 사진이 언제 다시 읽힐지 예측할 수 없습니다. 객체 대부분은 2MB 이상입니다. 꺼낼 때 요금 없이 자동으로 비용을 줄이려면?

A. Standard-IA
B. S3 Intelligent-Tiering
C. 수명 주기로 90일 후 Glacier Flexible Retrieval
D. Requester Pays

정답과 해설

B입니다. Intelligent-Tiering은 30일 접근이 없으면 Infrequent Access, 90일이면 Archive Instant Access로 자동 이동하고 꺼낼 때 요금이 없습니다. 다시 읽으면 Frequent Access로 돌아옵니다. A는 꺼낼 때 요금이 있고 자주 읽히는 사진에는 오히려 비쌉니다. C는 예측할 수 없는 접근에 복원 대기가 생깁니다. D는 요금을 누가 내는지만 바꿉니다.

문제 3. 결제 서비스의 API 서버는 1년 내내 최소 8대가 돌고 연말에는 30대까지 늘어납니다. 내년에는 인스턴스 패밀리를 새 세대로, 일부는 Fargate로 옮길 계획입니다. 비용을 가장 줄이는 조합은?

A. 30대 모두 3년 Standard Reserved Instances
B. 8대분을 Compute Savings Plans로 약정하고 나머지는 Auto Scaling으로 On-Demand
C. 30대 모두 Spot
D. 8대분을 EC2 Instance Savings Plans로 약정

정답과 해설

B입니다. 꾸준한 기준 부하(8대)만 약정하고 피크는 On-Demand로 탄력 있게 씁니다. Compute Savings Plans는 패밀리가 바뀌어도, Fargate로 옮겨도 적용됩니다. A는 연중 대부분 놀 22대분까지 약정합니다. C는 결제 API처럼 중단하면 안 되는 운영 워크로드에 맞지 않습니다. D는 패밀리를 고정하는 약정이라 세대 변경과 Fargate 이전 계획과 맞지 않습니다.

문제 4. 사내 정산 보고서용 Aurora MySQL 클러스터는 매달 마지막 날 몇 시간만 무거운 쿼리를 돌리고 나머지는 거의 유휴입니다. 엔진 버전은 3.08입니다. 비용을 가장 줄이는 방법은?

A. 가장 큰 프로비저닝 인스턴스를 1년 예약한다
B. Aurora Serverless v2로 바꾸고 최소 용량을 0 ACU로 설정한다
C. 읽기 복제본 15개를 추가한다
D. 같은 데이터를 DynamoDB 온디맨드로 옮긴다

정답과 해설

B입니다. Aurora Serverless v2는 0.5 ACU 단위로 늘고 줄며 Aurora MySQL 3.08.0 이상은 최소 0 ACU로 자동 일시 정지를 쓸 수 있습니다. 문서가 드는 예시에도 필요할 때만 보고서를 만드는 DB가 있습니다. A는 대부분 유휴인 시간까지 큰 인스턴스 비용을 냅니다. C는 비용을 늘립니다. D는 관계형 보고서 쿼리를 키-값 모델로 다시 설계해야 해서 요구와 맞지 않습니다.

문제 5. 사설 서브넷의 EC2 수십 대가 같은 리전 S3 버킷으로 하루 3TB를 올립니다. 청구서에서 NAT 게이트웨이 처리 요금이 크게 나옵니다. 보안 요구는 그대로 지키면서 비용을 줄이려면?

A. EC2를 공용 서브넷으로 옮기고 공용 IP를 붙인다
B. S3 게이트웨이 VPC 엔드포인트를 만들고 사설 서브넷 라우팅 테이블에 연결한다
C. NAT 게이트웨이를 NAT 인스턴스로 바꾼다
D. S3 Transfer Acceleration을 켠다

정답과 해설

B입니다. 게이트웨이 엔드포인트는 추가 요금이 없고 같은 리전 S3 트래픽을 NAT 대신 엔드포인트로 보냅니다. NAT 문서도 NAT를 지나는 트래픽이 엔드포인트를 지원하는 서비스로 간다면 엔드포인트를 만들라고 권합니다. A는 보안 요구를 약하게 만듭니다. C는 처리 요금은 없어지지만 대역폭과 관리 부담이 생기고 B보다 낫지 않습니다. D는 먼 거리 전송 가속용이고 요금이 추가됩니다.

문제 6. 개발팀이 리소스에 Team 태그를 꼼꼼히 달았는데 Cost Explorer에서 팀별로 비용을 나눠 볼 수 없습니다. 무엇을 해야 하나요?

A. 리소스를 팀별 계정으로 옮긴다
B. 결제 콘솔에서 Team을 비용 할당 태그로 활성화한다
C. CUR을 만들어야만 태그가 보인다
D. AWS Budgets를 만든다

정답과 해설

B입니다. 사용자 정의 태그도 결제 콘솔에서 비용 할당 태그로 활성화해야 Cost Explorer와 비용 할당 보고서에 나타나고 반영까지 최대 24시간이 걸립니다. A는 가능하지만 이 문제의 원인을 고치지 않습니다. C는 사실이 아닙니다. 활성화하면 Cost Explorer에서도 태그로 거를 수 있습니다. D는 알림 도구라서 원인과 관계가 없습니다.

문제 7. 게시판 서비스의 EBS 볼륨이 gp2 4,000GiB입니다. 데이터는 600GiB뿐이고 12,000 IOPS를 얻으려고 크게 잡았습니다. 성능은 유지하고 비용을 줄이려면?

A. io2 Block Express로 바꾼다
B. 새 gp3 볼륨(약 700GiB, 12,000 IOPS 프로비저닝)으로 데이터를 옮긴다
C. st1으로 바꾼다
D. 볼륨을 그대로 두고 스냅샷을 아카이브 계층으로 보낸다

정답과 해설

B입니다. gp2는 GiB당 3 IOPS라 12,000 IOPS를 얻으려면 4,000GiB가 필요하지만 gp3는 기본 3,000 IOPS에 GiB당 500까지 IOPS를 따로 추가합니다. GiB당 가격도 20% 낮습니다. Elastic Volumes 문서는 볼륨 크기를 줄일 수 없고 작은 볼륨을 새로 만들어 데이터를 옮기라고 적으므로 새 gp3 볼륨으로 옮기는 B가 맞습니다. 유형만 gp3로 바꾸고 4,000GiB를 유지하면 성능은 맞지만 저장 요금이 남습니다. A는 성능은 넘치지만 더 비쌉니다. C는 HDD라 작은 랜덤 I/O의 IOPS를 내지 못합니다. D는 볼륨 비용과 관계가 없습니다.

문제 8. 동영상 강의 플랫폼이 강의 영상을 S3에서 전 세계 수강생에게 직접 내려보냅니다. 같은 영상이 여러 번 재생되고 데이터 전송 비용이 가장 큰 항목입니다. 가장 효과적인 조치는?

A. S3 Transfer Acceleration을 켠다
B. S3 버킷을 오리진으로 CloudFront 배포를 만든다
C. AWS Global Accelerator를 S3 앞에 둔다
D. 영상을 One Zone-IA로 옮긴다

정답과 해설

B입니다. AWS 오리진에서 CloudFront로 가는 전송은 무료이고 같은 영상을 엣지 캐시가 반복해서 전달하니 오리진 전송과 요청이 같이 줄어듭니다. A는 업로드나 먼 거리 전송을 빠르게 할 뿐 요금이 추가됩니다. C는 캐시가 없습니다. D는 저장 비용만 바꾸고 자주 읽히는 영상이면 꺼낼 때 요금이 붙습니다.

8. 범위와 한계

• 요금 수치는 2026년 10월 19일에 연 AWS 요금 페이지와 문서 기준입니다. NAT 게이트웨이와 전송 단가는 10월 21일에 요금 페이지가 쓰는 요금 데이터로 다시 확인했습니다. 요금은 바뀌니 이 글의 금액을 계산 근거로 쓰지 않습니다.
• 서비스를 직접 만들어 청구서를 확인하지 않았습니다. 비용 비교는 모두 문서가 밝힌 요금 구조에서 읽은 것이고 실제 청구 금액으로 검증한 것이 없습니다. 프리 티어 실습 뒤 Cost Explorer로 본 결과를 따로 쓰겠습니다.
• 2026년 10월 21일 보강: AZ 간·리전 간 전송 단가, VPN, Direct Connect, PrivateLink, VPC 피어링, Transit Gateway 단가, 로드 밸런서 요금 구조, CUR 요금과 CUR 2.0, RDS 자동 백업 보존 규칙, EFS 수명 주기 일수, Outposts, Timestream, Neptune, Graviton 40% 출처, RI 범위를 문서와 요금 페이지가 쓰는 공식 요금 데이터로 확인해 본문에 넣었습니다. 요금 페이지 HTML에 숫자가 없는 경우 페이지가 불러오는 b0.p.awsstatic.com 요금 데이터를 읽었습니다.
• 확인하지 못한 것: Compute Optimizer가 NAT 게이트웨이에 내는 권고의 구체 내용.
• 2026년 10월 20일 보강: Budgets 요금, EBS 볼륨 크기 축소 불가와 24시간 4회 수정 한도, Savings Plans 네 유형의 최대 할인, Dedicated Host·Dedicated Instance·Capacity Reservation, Trusted Advisor와 Support 플랜 개편(2027년 1월 1일)을 문서로 확인해 넣었습니다.
• 6-2절의 NAT 인스턴스 판단과 6-5절의 “피어링이 더 쌀 수 있다”는 결론은 문서 문장이 아니고 요금 구조에서 끌어낸 추론입니다.
• 리전 NAT 게이트웨이, Database Savings Plans, Support 플랜 이름 변경처럼 최근 문서에 있는 내용이 시험에 반영됐는지는 모릅니다.
• 확인 문제는 직접 만든 것이라 실제 시험의 난이도나 문구와 다를 수 있습니다.

참고 자료

시험 안내서

• AWS, Content Domain 4: Design Cost-Optimized Architectures
• AWS, AWS Certified Solutions Architect - Associate (SAA-C03)

비용 관리 도구

• Analyzing your costs and usage with AWS Cost Explorer
• Managing your costs with AWS Budgets
• What are AWS Cost and Usage Reports?
• Organizing and tracking costs using AWS cost allocation tags
• Consolidating billing for AWS Organizations

스토리지

• Transitioning objects using Amazon S3 Lifecycle
• How S3 Intelligent-Tiering works
• Using Requester Pays general purpose buckets for storage transfers and usage
• Amazon EBS General Purpose SSD volumes, Amazon EBS volume types
• Archive Amazon EBS snapshots, Considerations and limitations for archiving Amazon EBS snapshots
• Amazon EFS performance specifications, Help Me Choose An Amazon FSx File System
• What is AWS DataSync?, What is AWS Transfer Family?, AWS Snowball

컴퓨팅

• Amazon EC2 pricing, Amazon EC2 On-Demand Pricing
• What are Savings Plans?, Savings Plans types
• Reserved Instances for Amazon EC2 overview
• Spot Instance interruptions, Spot Instance interruption notices
• What is AWS Compute Optimizer?
• Amazon EC2 billing and purchasing options
• Modify an Amazon EBS volume using Elastic Volumes operations
• AWS Budgets pricing, AWS Trusted Advisor
• AWS Graviton
• Hibernate your Amazon EC2 instance
• Lambda quotas, Configure Lambda Event Function memory

데이터베이스

• How Aurora serverless works, Amazon Aurora storage
• DynamoDB throughput capacity, DynamoDB table classes
• In-memory acceleration with DynamoDB Accelerator (DAX)
• Working with DB instance read replicas, Amazon RDS Proxy
• What is AWS Database Migration Service?

네트워크

• Pricing for NAT gateways, Amazon VPC Pricing
• NAT gateways, Regional NAT gateways for automatic multi-AZ expansion, Compare NAT gateways and NAT instances
• Gateway endpoints, What is AWS PrivateLink?
• What is AWS Transit Gateway for Amazon VPC?, How VPC peering connections work
• AWS Site-to-Site VPN quotas, Dedicated Direct Connect connections
• What is Amazon CloudFront?

2026년 10월 21일 보강 때 연 문서

• Data Exports (CUR 2.0), CUR FAQs, CloudWatch billing and cost, Cost Explorer multi-year data
• Trusted Advisor (Support 플랜 공지), Amazon EC2 M6g, What is AWS Outposts?, Reserved Instance scope
• Aurora Serverless v2 how it works, Backup retention period, Amazon RDS for MySQL pricing, Amazon Aurora pricing
• Timestream for LiveAnalytics availability change, What is Amazon Neptune?, DMS Schema Conversion
• EFS lifecycle management, What is AWS Snowball Edge?
• EC2 On-Demand pricing, Amazon VPC pricing, What is VPC peering?, Site-to-Site VPN pricing, Direct Connect pricing, PrivateLink pricing, Transit Gateway pricing, Elastic Load Balancing pricing