Amazon DEA-C01: 데이터 워크로드 비용 최적화 — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

다음의 일부입니다: Amazon Data Engineer Associate DEA-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

데이터 워크로드의 비용 최적화는 스토리지, 컴퓨팅, 데이터 처리 파이프라인이 비용 급증 없이 가치를 제공하도록 보장합니다. 데이터 엔지니어는 쿼리 성능, 데이터 내구성, 가용성과 서비스 및 사용 패턴에 따라 달라지는 요금 모델 사이에서 균형을 맞춰야 합니다. 이 영역에서는 스토리지 클래스와 수명 주기 정책, 쿼리 및 클러스터 수준 제어, 스팟 및 예약 용량, 서버리스와 프로비저닝 방식의 장단점에 대한 이해가 필요합니다.

S3 스토리지 비용 최적화

S3 Intelligent-Tiering은 액세스 패턴을 예측할 수 없는 데이터 세트에 권장되는 기본 옵션입니다. 객체 액세스 빈도를 안정적으로 예측할 수 없는 경우, 콘솔이나 AWS CLI를 통해 Intelligent-Tiering을 활성화하십시오. Intelligent-Tiering을 구성할 때는 관련 모니터링/자동화 수수료(객체당 소액의 월별 모니터링 요금이 있음)를 인지하고, 자동 티어 전환을 위한 최소 기간(Frequent Access에서 Infrequent Access 티어로 전환 시 30일)을 올바르게 설정해야 합니다. 객체 태그와 수명 주기 규칙을 사용하여 모니터링 요금이 절감액보다 클 수 있는 작고 요청이 많은 객체는 제외하십시오.

S3 비용을 줄이기 위해 다음 운영 패턴을 사용하십시오:

수명 주기 규칙을 생성하기 전에 S3 Storage Class Analysis(콘솔 > Management > Analytics 또는 aws s3control)를 실행하여 접두사/태그 수준의 액세스 패턴을 파악합니다.
대규모 기록 데이터 세트를 수명 주기 전환을 사용하여 아카이브 클래스(Glacier Flexible Retrieval 또는 Glacier Deep Archive)로 변환합니다. 비즈니스 SLA에 맞춰 수명 주기 전환 시점을 설정하고, 빈번한 Expedited 검색을 피합니다.
분석 워크로드의 경우, 여러 개의 작은 객체(small-file 문제)를 더 큰 객체(Parquet 컨테이너 파일)로 통합하여 요청당 및 GET당 비용을 줄입니다.

결정 기준:

Intelligent-Tiering: 액세스 패턴을 예측할 수 없고 검색 시간이 유연한 중간 정도의 액세스 빈도를 가진 데이터 세트에 사용합니다.
Standard-IA 또는 One Zone-IA: 액세스 빈도는 낮지만 예측 가능한 검색 패턴으로 빠르게 검색해야 하는 데이터에 사용합니다.
Glacier Standard/Bulk/Deep Archive: 검색이 드물고 수 분에서 수 시간의 지연 시간을 허용할 수 있는 장기 보관용 데이터에 사용합니다. 높은 요금을 피하기 위해 Expedited 검색보다 Bulk/Standard 검색을 선호합니다.

Athena 및 Redshift 비용 관리

Athena 비용은 스캔된 바이트에 비례하여 증가합니다. 작업 그룹 제어(콘솔 또는

undefined

)를 적용하여 쿼리당 데이터 스캔 제한과 작업 그룹당 월별 예산을 구현합니다. ‘작업 그룹 설정 강제 적용’을 활성화하여 쿼리당 데이터 제한을 초과하는 쿼리는 실행되지 않고 실패하도록 합니다. 소스 파일을 컬럼 기반 압축 형식(Parquet/ORC)으로 변환하고, 날짜나 자주 사용되는 필터 컬럼으로 파티셔닝하고, 조건자 푸시다운(predicate pushdown)을 적용하고, CTAS 또는 CREATE TABLE AS를 사용하여 최적화된 데이터 세트를 구체화함으로써 스캔되는 바이트를 줄이십시오. 쿼리 결과 재사용 및 워크로드를 별도의 작업 그룹으로 격리하여 팀 간 비용 누수를 방지합니다.

Redshift 비용 결정은 워크로드 예측 가능성과 스토리지 선택에 따라 결정됩니다. 안정적이고 예측 가능한 데이터 웨어하우스 컴퓨팅 사용량의 경우, Reserved Nodes(1년 또는 3년 약정, 일부/전체 선결제 옵션)를 구매하여 온디맨드 대비 할인된 요금을 적용받습니다. 가변적인 워크로드의 경우:

Redshift Serverless 또는 관리형 스토리지를 사용하는 RA3 노드를 사용하여 컴퓨팅과 스토리지를 분리합니다.
동시성 확장(concurrency scaling)은 신중하게 사용하고(추가 요금이 발생하지만 자동 확장을 제공함) 크레딧을 모니터링합니다.

비교 하이라이트:

Reserved Nodes: 안정적인 상태의 장기 클러스터에 최적입니다. 약정이 필요하지만 상당한 할인을 제공합니다.
On-demand: 예측 불가능하거나 단기적인 프로젝트에 유연합니다. 시간당 비용이 더 높습니다.
Serverless/RA3 with Spectrum: 스토리지를 S3로 이전하고 활성 상태일 때만 컴퓨팅 비용을 지불하여 대규모 예약 약정을 피할 수 있습니다.

Glue 및 EMR 비용 전략

AWS Glue는 다양한 비용 관리 수단을 제공하는 서버리스 ETL입니다. 지연 시간에 민감하지 않은 배치 작업의 경우, 표준 Glue 실행 대비 비용을 최대 약 34%까지 절감할 수 있는 Glue 유연한 실행(Glue Flex 작업)을 사용하십시오. Glue Studio 또는 CLI(

undefined

)에서 Glue 작업 파라미터를 구성하여 작업자 유형과 최대 DPU를 선택하고, 무제한 자동 확장을 방지하기 위해 합리적인 최대 DPU 한도를 설정하며, 작업 북마크를 사용하여 전체 재처리를 방지합니다. 대화형 또는 지연 시간에 민감한 워크로드의 경우, 작업자 유형(Standard/G.1X/G.2X)을 선택하고 병렬 처리를 책임감 있게 조정합니다.

EMR 비용 절감은 마스터 및 코어 노드는 On-Demand로 유지하면서 태스크 노드에 Spot Instances를 사용하는 데 중점을 둡니다(콘솔 또는

undefined

를 통해 인스턴스 플릿 또는 인스턴스 그룹 구성). 태스크 노드에만 Spot을 사용하고, 용량 최적화 할당 전략을 선택하며, 입찰 방식의 Spot을 사용하는 경우 적절한 입찰가/최대 가격을 설정합니다. 클러스터 상태와 작업 복원력을 보호하려면 다음을 따르십시오:

Spot 태스크 노드를 사용할 때는 영구 데이터를 HDFS 대신 S3에 저장합니다(EMRFS 사용).
자동 재시도 및 단계 기반 워크플로를 사용하여 Spot 중단을 처리합니다.
EMR Managed Scaling을 사용하여 클러스터 크기를 적절하게 조정하고, 크기 조정의 급격한 변동(oscillation)을 피하기 위해 스케일링 정책을 모니터링합니다.

결정 기준:

Glue Flex: 우선순위가 낮고 비용에 민감하며 시작 시간이 더 길어도 괜찮은 ETL에 사용하고, 최대 DPU를 제한합니다.
EMR with Spot task nodes: 대규모 임시 처리(예: 야간 배치)에 사용하되, 마스터/코어 노드는 On-Demand로 유지하거나 혼합 할당 방식의 Instance Fleets를 사용합니다.

데이터 서비스를 위한 예약 용량 및 Savings Plans

예약 용량과 Savings Plans는 데이터 서비스마다 다르게 적용됩니다. EC2 기반 서비스(EMR, 자체 관리형 HBase, 맞춤형 Hadoop)의 경우, EC2 Savings Plans 또는 예약 인스턴스를 사용하여 컴퓨팅 비용을 절감하세요. 이동성 요구에 따라 리전 또는 영역 옵션을 선택합니다. Redshift는 프로비저닝된 클러스터에 대한 예약 노드 구매를 지원하여 예측 가능한 웨어하우스 워크로드의 시간당 비용을 줄일 수 있습니다. 서버리스 서비스(Glue, Athena)는 리소스 예약 기능이 없으므로, 대신 워크로드 스케줄링 및 데이터 형식 변경을 통해 최적화해야 합니다.

실용적인 구매 가이드:

사용량이 알려진 안정적인 상태의 데이터 웨어하우스 워크로드에는 Redshift 예약 노드를 구매하세요(1년/3년 약정 및 전체/부분/선결제 없음 옵션 평가).
여러 인스턴스 패밀리에 걸쳐 예측 가능한 EMR/EC2 비용을 절감하려면 EC2 Savings Plans를 사용하세요. Savings Plans는 인스턴스 패밀리나 리전이 변경될 경우 유연성을 제공합니다.
서버리스 서비스에 대한 예약은 구매하지 마세요. 대신 사용 패턴, 스케줄링, 데이터 레이아웃을 최적화하세요.

일반적인 함정과 의사결정 기준

Athena는 파티셔닝 없이 전체 테이블을 스캔합니다 — 항상 크고 시계열적인 테이블은 날짜나 카디널리티가 높고 자주 필터링되는 다른 열을 기준으로 파티셔닝하고, 스캔되는 바이트를 최소화하기 위해 Parquet/ORC로 변환하세요.
Glue DPU 자동 확장은 과도하게 프로비저닝될 수 있습니다 — 작업 구성(콘솔 또는

undefined

)에서 최대 DPU 한도를 설정하고 적절한 워커 유형을 선택하여 비용을 예측 가능하게 유지하세요.

S3 Glacier 검색 요금 — 비즈니스에 매우 중요하지 않은 한 신속(Expedited) 검색은 피하세요. 표준(Standard) 또는 대량(Bulk) 검색을 계획하고 현실적인 SLA를 설정하여 수명 주기 전환을 구성하세요.
EMR 마스터 및 코어 노드는 스팟을 사용해서는 안 됩니다 — 마스터/코어 노드는 온디맨드로 구성하고, 태스크 노드에만 스팟을 할당하되 HDFS 상태를 피하거나 복제하도록 구성하세요.
많은 작은 S3 객체는 요청 비용을 증가시키고 분석 속도를 저하시킵니다 — 수집 중에 작은 파일들을 더 큰 열 형식 파일로 압축하세요.
동시성 확장 또는 관리되지 않는 자동 확장에 대한 과도한 의존은 시간당 요금을 증가시킬 수 있습니다 — 확장 지표를 모니터링하고, 한도를 설정하며, 워크로드가 예측 가능할 때는 예약 용량을 사용하세요.

실전 문제: Acme Analytics의 야간 ETL 비용 절감

Acme Analytics는 야간 ETL과 일일 임시 분석을 실행합니다. 증가하는 원시 S3 스토리지와 온디맨드 Redshift 사용 시간으로 인해 월간 클라우드 지출이 급증했습니다. 회사는 야간 SLA에 영향을 주지 않으면서 비용을 35% 절감해야 합니다.

S3 스토리지 클래스 분석을 실행하고 수명 주기 규칙을 적용하여 90일 이상 된 콜드(cold) 원시 파일을 Glacier Flexible Retrieval로 이동합니다(대량/표준 검색 계획).
원시 CSV를 파티셔닝되고 압축된 Parquet으로 변환하고 작은 파일들을 압축합니다. 최적화된 데이터 세트는 Athena/Redshift Spectrum을 위해 별도의 접두사(prefix) 아래에 저장합니다.
쿼리당 데이터 스캔 한도가 있는 Athena 작업 그룹을 생성하고 작업 그룹 설정을 강제 적용합니다. 쿼리 결과 재사용을 활성화하고 작업 그룹별 월간 예산을 설정합니다.
긴급하지 않은 변환 작업은 Glue Flex 작업으로 마이그레이션하고, 최대 DPU 한도를 설정하며, 오프피크(off-peak) 시간에 스케줄링합니다. 긴급한 작업을 위해 더 작은 규모의 표준 Glue 플릿(fleet)은 유지합니다.
Redshift 용량 최적화(Right-sizing): 안정적인 기준 컴퓨팅을 위해 1년 약정 예약 노드를 구매하고, 과거 데이터는 S3로 이동하여 드문 쿼리에 Spectrum을 사용하며, 모니터링과 함께 동시성 확장을 활성화합니다.

근거: 이 전략은 데이터 형식 및 수명 주기 최적화(스토리지 및 스캔 비용 절감), 유연한 작업을 위한 서버리스 저비용 실행(Glue Flex), 쿼리 거버넌스(Athena 작업 그룹), 그리고 지속적인 컴퓨팅을 위한 예약 용량 확보를 결합하여 가용성과 성능을 유지하면서 할인을 극대화합니다.

← 데이터 파이프라인 모니터링 및 문제 해결 · 모든 도메인 · 데이터 품질 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →