AWS 11 데이터 분석 — Athena·Glue·EMR·Redshift·Quick Sight·OpenSearch·Lake Formation·Flink
고친 사람 github-actions[bot]
쇼핑몰의 클릭 로그 1년 치가 S3 에 파일로 쌓여 있고, 주문·회원 표는 RDS 에 있다고 해 봅니다. 기획자가 「지난달 어느 화면에서 이탈이 가장 많았나」를 묻습니다. 운영 DB 에 몇 시간짜리 집계 쿼리를 던지면 그동안 주문 처리가 느려지고, S3 에 쌓인 로그 파일은 그 상태로는 SQL 로 읽을 수 없습니다. 질문은 하나인데, 그 질문을 어디서 계산할지부터 정해야 합니다.
이 편은 그 계산을 맡는 서비스들을 봅니다. 계산은 여섯이 나눠 맡습니다. 파일을 S3 에 둔 채 SQL 로 묻는 Athena, 표 정의를 모아 두고 파일 형식을 바꾸는 Glue, Spark 클러스터를 내 설정대로 돌리는 EMR, 데이터를 옮겨 담아 되풀이해 묻는 Redshift, 낱말과 로그 한 줄을 찾는 OpenSearch Service, 흘러드는 동안 계산하는 Managed Service for Apache Flink 입니다. 그 앞뒤에는 결과를 화면으로 보여 주는 Quick Sight 와 누가 어느 열·행을 볼지 정하는 Lake Formation 이 붙습니다. 끝에서는 이 서비스들을 쓸 때만 내는 쪽과 켜 둔 만큼 내는 쪽으로 나눠 한 달 값을 셈합니다. 요금과 한도는 전부 2026-11-13 서울(ap-northeast-2) 기준입니다.
지도
flowchart TD
START["쌓였거나 흘러드는 데이터"] --> Q1{"흘러드는 동안<br/>바로 계산해야 하나"}
Q1 -- "그렇다" --> FL["Managed Service<br/>for Apache Flink"]
Q1 -- "아니다" --> Q2{"낱말이나 로그 한 줄을<br/>찾는 일인가"}
Q2 -- "그렇다" --> OS["OpenSearch Service"]
Q2 -- "아니다" --> Q3{"같은 질문을<br/>하루 종일 되풀이하나"}
Q3 -- "그렇다" --> RS["Redshift"]
Q3 -- "아니다" --> Q4{"SQL 로 풀리나"}
Q4 -- "풀린다" --> AT["Athena"]
Q4 -- "코드가 필요하다" --> Q5{"클러스터 설정까지<br/>직접 골라야 하나"}
Q5 -- "아니다" --> GL["Glue ETL 작업"]
Q5 -- "그렇다" --> EMR["EMR"]
S3 처럼 값싼 저장소에 원본 파일을 쌓아 두고 필요할 때 읽는 방식을 데이터 레이크라고 하고, 정해진 표로 옮겨 담아 질문에 빨리 답하도록 꾸린 DB 를 데이터 웨어하우스라고 합니다. 그림의 아래쪽 세 갈래(Athena·Glue·EMR)는 데이터 레이크의 파일을 옮기지 않고 읽고, Redshift 는 웨어하우스로 옮겨 담습니다. 위쪽 두 갈래는 표 집계가 아니라 검색과 실시간 계산이라 처음부터 다른 길로 갑니다. Quick Sight 와 Lake Formation 은 갈래가 아니라 어느 길을 고르든 위에 얹히는 화면과 권한이라 그림에 넣지 않았습니다. S3 까지 데이터를 실어 오는 Kinesis·Firehose·MSK 는 07-3편에서 봤습니다.
1. Athena — S3 에 둔 채로 SQL 을 던진다
S3 에 쌓인 파일을 DB 로 옮기지 않고 SQL 로 물을 수는 없을까요? Athena 는 그 일을 하는 서버 없는 쿼리 서비스입니다. 먼저 「이 S3 경로의 파일들은 이런 열을 가진 표다」라는 표 정의를 만들어 두면, 쿼리를 던질 때 Athena 가 그 경로의 파일을 읽어 계산하고 결과를 돌려줍니다. 읽을 수 있는 형식은 CSV·JSON 같은 텍스트부터 Apache Parquet·Apache ORC 같은 열 지향 형식까지입니다. 표 정의는 다음 절의 Glue Data Catalog 에 두므로, 같은 표를 EMR 과 Redshift 의 S3 읽기 기능(2절)에서도 봅니다(When should I use Athena?).
띄워 둘 서버가 없으니 값은 쿼리가 읽은 데이터 양에만 붙습니다. 그래서 같은 질문이라도 파일 모양에 따라 값이 크게 달라집니다. 압축하면 읽을 바이트가 줄고, Parquet 처럼 열마다 따로 모아 저장하는 형식이면 쿼리에 쓰인 열만 읽습니다. 아래는 Athena 요금 페이지의 예시를 서울 단가로 옮긴 것입니다.
Athena · 서울 · 2026-11-13 · 읽은 데이터 TB 당 $5.00
원본 텍스트 3 TB 에 같은 질문 하나
압축 없는 텍스트 3 TB 읽음 → $15.00
GZIP 압축(약 3:1) 1 TB 읽음 → $5.00
압축한 Parquet, 열 하나 0.25 TB 읽음 → $1.25
+ 결과를 쓰는 S3 저장·요청 요금은 따로
압축과 열 지향 형식을 함께 쓰고 열 하나만 읽으면, 같은 질문이 열두 분의 일 값이 됩니다. 여기에 파일을 날짜별 경로로 나눠 두면(파티션) WHERE 절에 걸린 날짜 폴더만 읽으니 읽는 양이 더 줍니다.
잘못 짠 쿼리 하나가 테라바이트를 훑는 사고는 작업 그룹(workgroup)으로 막습니다. Athena 는 쿼리를 작업 그룹이라는 묶음 안에서 돌립니다. 팀이나 용도마다 묶음을 나눠 두고, 묶음마다 쿼리 하나가 읽을 양의 상한을 정하면 그 선을 넘는 쿼리는 취소됩니다(취소 전까지 읽은 양은 청구). 작업 그룹 전체의 시간당·하루 사용량에는 SNS 경보를 걸 수 있습니다(Configure per-query and per-workgroup data usage controls).
시간에도 한도가 있습니다. SELECT 같은 쿼리는 기본 30분에 끊기고(요청하면 240분까지), 서울에서 동시에 돌거나 기다리는 쿼리는 기본 100개입니다(Amazon Athena endpoints and quotas).
결국 Athena 는 질문이 가끔이고 읽는 양을 줄여 둘 수 있을 때 싸고, 같은 넓은 범위를 쉬지 않고 다시 읽을 때 비싸집니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| S3 의 로그를 가끔, 그때그때 다른 질문으로 본다 | 대시보드가 하루 종일 같은 넓은 범위를 다시 읽는다(→ Redshift) | 쿼리마다 읽은 만큼 다시 낸다 |
| 파일을 Parquet 로 바꾸고 날짜로 나눠 둘 수 있다 | 압축 없는 JSON 을 손대지 않고 쌓아 두고 자주 훑는다 | 형식을 바꾸는 작업(Firehose·Glue)을 따로 둬야 한다 |
| 30분 안에 끝나는 집계와 조회 | 몇 시간 걸려 결과를 파일로 다시 쓰는 큰 변환(→ Glue·EMR) | 긴 쿼리는 한도에 걸려 끊긴다 |
S3 Select 와 S3 Glacier Select 는 2024-07 부터 새 고객을 받지 않는 유지보수 단계라, S3 파일에 SQL 을 던지는 일은 Athena 로 모입니다(Services in Maintenance).
2. Glue — 표 정의를 모아 두고 형식을 바꾼다
Athena 가 읽을 표 정의는 누가 만들고, JSON 을 Parquet 로 바꾸는 일은 누가 할까요? AWS Glue 는 여러 원천의 데이터를 찾아 연결하고 옮기고 바꾸는 서버 없는 데이터 통합 서비스입니다. 핵심 부품은 둘입니다.
첫째는 Data Catalog 입니다. 「어느 S3 경로에 어떤 열을 가진 표가 있다」는 메타데이터를 계정 안 한 곳에 모아 두는 저장소입니다. Athena 와 EMR 이 이 카탈로그를 봅니다. Redshift 도 S3 파일을 옮기지 않고 읽는 기능인 Redshift Spectrum 으로 같은 카탈로그를 봅니다.
표 정의는 손으로 써도 됩니다. 크롤러(crawler)를 돌리면 S3 를 훑어 스키마를 짐작하고 카탈로그에 표를 만들어 줍니다.
둘째는 ETL 작업입니다. 원본을 읽어(Extract) 바꾸고(Transform) 다른 곳에 쓰는(Load) 일, 곧 ETL 을 Spark 기반 서버리스 엔진에서 돌립니다. 매일 밤 쌓인 JSON 을 Parquet 로 바꾸는 일이 흔한 예입니다(What is AWS Glue?).
Glue 는 작업이 도는 동안의 DPU(Data Processing Unit, vCPU 4개·메모리 16 GB 묶음) 시간만큼 청구합니다. 2026-08 에 나온 Glue 6.0 부터는 DPU 시간당 단가가 이전 판보다 30% 낮고, 판은 작업마다 고릅니다. 끝나는 시각이 조금 늦어져도 되는 작업은 Flex 실행으로 돌리면 단가가 더 내려갑니다.
AWS Glue · 서울 · 2026-11-13
ETL 작업(Spark), 초 단위
Glue 6.0 이상 DPU 시간당 $0.308
Glue 5.1 이하 DPU 시간당 $0.44
Flex 실행
Glue 6.0 이상 DPU 시간당 $0.203
Glue 5.1 이하 DPU 시간당 $0.29
크롤러 DPU 시간당 $0.44
Data Catalog 객체 100만 개 · 요청 월 100만 건까지 무료
넘으면 객체 10만 개당 월 $1
요청 100만 건당 $1
- 출처: AWS Glue pricing · AWS Glue 6.0 now available with 30% lower price and full Apache Iceberg v3 support. 요금 페이지 본문에는 아직 5.1 이하 단가만 있고, 6.0 단가는 발표 글과 AWS 가격 목록에 있습니다
Glue 가 맞는지는 변환이 Glue 가 띄우는 실행 환경 안에서 끝나느냐로 정해집니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 매일 밤 쌓인 JSON 을 Parquet 로 바꾸는 정해진 변환 | 클러스터 설정과 설치 소프트웨어까지 직접 골라야 하는 큰 작업(→ EMR) | Glue 가 띄우는 실행 환경 안에서만 조정한다 |
| 새 파일이 쌓이는 경로의 스키마를 자동으로 잡고 싶다(크롤러) | 스키마가 고정돼 있어 표 정의를 코드로 한 번 써 두면 끝난다 | 크롤러가 도는 시간도 DPU 시간으로 낸다 |
| 끝나는 시각이 조금 밀려도 되는 밤 배치(Flex) | 정해진 시각까지 꼭 끝나야 하는 작업 | 싼 단가 대신 완료 시각을 약속받지 못한다 |
클러스터를 내 손으로 고르고 Spark 말고도 Hadoop 생태계의 다른 도구를 함께 써야 한다면 EMR 로 갑니다.
3. EMR — Spark 클러스터를 내 설정대로 돌린다
이미 Spark·Hadoop 으로 짠 큰 작업이 있고 버전과 설정을 내가 정해야 한다면 무엇을 쓸까요? Amazon EMR(옛 이름 Elastic MapReduce)은 Hadoop·Spark 같은 빅데이터 프레임워크를 돌리는 관리형 클러스터 플랫폼입니다. SQL 엔진 Presto 나 키-값 저장소 HBase 도 올릴 수 있고, 클러스터 구성과 설치 소프트웨어를 전부 내가 정합니다. SQL 을 넘어 기계 학습·그래프 분석·변환처럼 코드로 짜는 대규모 처리가 주 용도입니다(What is Amazon EMR? · When should I use Athena?).
돌리는 곳은 셋입니다. EMR on EC2 는 EC2 인스턴스 여러 대로 클러스터를 띄우고, EMR on EKS 는 쓰던 쿠버네티스 클러스터에 작업을 올리며, EMR Serverless 는 클러스터 없이 작업 단위로 자원을 받습니다. EC2 에서 돌리면 EC2 요금 위에 EMR 요금이 얹힙니다.
Amazon EMR · 서울 · 2026-11-13
EMR on EC2 EC2 요금 + EMR 요금, 초 단위(최소 1분)
m7g.xlarge EC2 $0.2006 + EMR $0.0408
= 노드 하나 시간당 $0.2414
EMR Serverless 쓴 vCPU·메모리·저장, 초 단위(최소 1분)
x86 vCPU 시간당 $0.060528 · GB 시간당 $0.006643
Arm vCPU 시간당 $0.048425 · GB 시간당 $0.005317
Standard 임시 저장은 작업자마다 20 GB 까지 포함
- EMR on EKS 는 요청한 vCPU·메모리에 EMR 요금이 붙고, EKS 와 그 밑의 EC2·Fargate 요금은 따로 나갑니다(Amazon EMR pricing)
EMR 은 손댈 수 있는 범위가 넓은 만큼 고를 것도 많습니다. EC2 로 띄우면 작업이 없어도 켜 둔 시간만큼 값이 붙습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 큰 데이터를 Spark·Hadoop 코드로 처리하고 버전·설정까지 내가 고른다 | SQL 몇 줄로 풀리는 질문(→ Athena) | 노드 종류·개수·소프트웨어 버전을 내가 정하고 관리한다 |
| 사내에서 Hadoop·Spark 로 돌던 작업을 손대지 않고 옮긴다 | 처음 짜는 작은 변환(→ Glue) | 클러스터를 켜 둔 동안 EC2 요금에 EMR 요금이 얹힌다 |
| 작업이 띄엄띄엄 와서 클러스터를 늘 켜 두기 아깝다(Serverless) | 노드 종류까지 손으로 고르고 싶다(→ EMR on EC2) | 작업마다 쓴 vCPU·메모리 시간을 낸다 |
변환이 아니라 같은 질문에 빨리 답하는 것이 목적이라면, 파일을 매번 다시 읽는 대신 Redshift 에 옮겨 담습니다.
4. Redshift — 옮겨 담아 두고 되풀이해 묻는다
대시보드가 근무 시간 내내 같은 질문을 던진다면, 그때마다 S3 파일을 다시 읽어야 할까요? Amazon Redshift 는 데이터 웨어하우스입니다. 재고·재무·판매처럼 여러 원천의 데이터를 한 형식으로 모아 오래 두고, 아주 큰 표 여러 개를 조인하는 복잡한 쿼리에 맞춰 엔진을 다듬었습니다(When should I use Athena?).
빠른 까닭 하나는 저장 방식입니다. 보통의 관계형 DB 는 한 행의 값들을 이어 붙여 저장하지만, Redshift 는 한 열의 값들을 이어 붙여 저장합니다. 열이 100개인 표에서 5개만 쓰는 쿼리는 표의 약 5% 만 읽고, 한 블록에 같은 종류 값만 들어가니 압축도 잘 됩니다(Columnar storage).
대신 데이터를 들여와야 합니다. S3 파일을 여러 노드가 나눠 읽어 적재하는 COPY 명령이 가장 효율적인 길입니다. 새 파일이 생기면 자동으로 COPY 하게 걸어 둘 수도 있고, Kinesis Data Streams·MSK 에서 곧바로 받을 수도 있습니다(Loading data in Amazon Redshift).
Redshift 를 쓰는 형태는 둘입니다. Serverless 는 계산 용량을 RPU(Redshift Processing Unit, 메모리 16 GB 단위)로 세고, 쿼리가 도는 동안만 초 단위로 받으며 쿼리가 없으면 계산 요금이 0 입니다. 기본 용량은 128 RPU 이고 낮출 수 있는데, 가장 작은 4 RPU 를 쓸 수 있는 리전 목록에 서울이 없어 서울의 하한은 8 RPU 입니다(Compute capacity for Amazon Redshift Serverless).
프로비저닝 클러스터는 노드를 골라 늘 켜 둡니다. 2026-09 부터는 Graviton 기반 rg.large 노드 한 대짜리 클러스터도 서울에서 만들 수 있습니다. 고가용성이 필요 없는 작은 작업과 시험용입니다(Amazon Redshift rg.large single-node 발표).
어느 형태든 데이터를 담는 관리형 저장(RMS, Redshift Managed Storage)은 계산과 따로 GB 단위로 냅니다.
Amazon Redshift · 서울 · 2026-11-13
Serverless RPU 시간당 $0.438, 초 단위(최소 60초)
서울 하한 8 RPU 로 쿼리가 돌면 시간당 $3.504
프로비저닝 rg.large 노드 시간당 $0.4473
저장(RMS) GB-월 $0.0261
Serverless 에는 놓치기 쉬운 청구가 둘 있습니다. 커넥션 풀이 연결이 살아 있는지 보려고 보내는 SELECT 1 같은 상태 확인 쿼리도 계산 시간으로 청구되고, 끝내지 않은 트랜잭션은 그동안 RPU 를 계속 씁니다. 하루·주·월 단위 최대 RPU 시간을 정해 두면 넘었을 때 기록·알림·쿼리 차단 가운데 하나를 고를 수 있습니다(Billing for Amazon Redshift Serverless · Billing for on-demand compute capacity).
그래서 Redshift 는 같은 큰 표를 하루에도 여러 번 조인할 때 제값을 합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 주문·회원·결제를 한 형식으로 모아 오래 두고 큰 표끼리 조인한다 | S3 로그를 가끔 훑어볼 뿐이다(→ Athena) | COPY 로 옮겨 담는 적재 작업을 따로 운영한다 |
| 쿼리가 몰리는 시간이 정해져 있다(Serverless) | 쿼리가 하루 종일 끊이지 않는다(→ 프로비저닝) | 쿼리가 도는 초마다 RPU 요금이 붙고, 상태 확인 쿼리나 열린 트랜잭션도 청구된다 |
| 쿼리가 하루 종일 꾸준히 들어온다(프로비저닝) | 하루 몇 시간만 쓴다(→ Serverless) | 노드는 쿼리가 없어도 시간 요금이 나간다 |
로그 한 줄을 낱말로 찾는 일은 표 집계와 다른 엔진이 맡습니다. 다음 절의 OpenSearch 입니다.
5. OpenSearch Service — 낱말과 로그 한 줄을 찾는다
「timeout」이 든 로그를 지난 15분 치에서 찾거나, 상품명 일부로 상품을 찾는 일에 SQL 이 맞을까요? OpenSearch 는 로그 분석, 애플리케이션 실시간 모니터링, 클릭 흐름 분석 같은 일에 쓰는 오픈소스 검색·분석 엔진입니다. Amazon OpenSearch Service 는 그 클러스터를 대신 띄워 줍니다. 클러스터 하나를 도메인이라 부르며, 인스턴스 종류·개수·저장 용량을 내가 정하면 AWS 가 띄우고 고장 난 노드를 바꿉니다.
옛 Elasticsearch 도 오픈소스 마지막 판인 7.10 까지 고를 수 있습니다. 데이터를 보는 화면으로는 OpenSearch Dashboards 가 딸려 옵니다(What is Amazon OpenSearch Service?). 로그는 07-3편의 Firehose 나 CloudWatch Logs 에서 흘려 넣는 경우가 많습니다.
도메인은 데이터를 샤드로 나눠 노드에 흩어 두고, 원본 샤드와 복제본 샤드를 서로 다른 노드에 둡니다. AWS 는 복제본을 적어도 하나 두라고 권하므로 데이터 노드는 최소 둘이 됩니다. t3.small 같은 작은 인스턴스는 꾸준한 부하에 불안정해 운영에 권하지 않고, 작은 운영용으로는 r6g.large 를 듭니다(Operational best practices for Amazon OpenSearch Service).
노드를 고르기 싫다면 OpenSearch Serverless 가 있습니다. Serverless 에서는 도메인 대신 컬렉션을 만들고, 용량은 OCU(OpenSearch Compute Unit, 메모리 6 GiB 단위)로 인덱싱과 검색에 따로 붙습니다. 최솟값을 0 으로 두면 쉬는 동안 OCU 가 필요 없습니다. 다만 그러면 쉬다가 온 첫 요청이 늦을 수 있어 최솟값을 올려 두기도 합니다(Managing capacity limits for Amazon OpenSearch Serverless).
Amazon OpenSearch Service · 서울 · 2026-11-13
도메인(인스턴스 시간)
t3.small.search 시간당 $0.056 (운영에 권하지 않음)
r6g.large.search 시간당 $0.203 (작은 운영용)
저장(gp3) GB-월 $0.1391
Serverless 인덱싱·검색 OCU 시간당 각 $0.293
- 다중 가용 영역 도메인의 노드끼리 오가는 트래픽은 청구하지 않습니다(Amazon OpenSearch Service pricing)
버전도 값에 걸립니다. Elasticsearch 1.5·2.3·5.1~5.5·6.0~6.7·7.1~7.8 과 OpenSearch 1.0~1.2·2.3~2.9 는 표준 지원이 끝나 연장 지원 기간입니다. 2026-11-07 부터는 그 버전으로 도는 도메인이 인스턴스 요금과 같은 액수를 연장 지원료로 더 냅니다. 사실상 두 배이고, 이 연장 지원도 2027-11-07 에 끝납니다(What is Amazon OpenSearch Service? – Standard and extended support). 같은 검색 계열인 CloudSearch 는 2024-07 부터 새 고객을 받지 않는 유지보수 단계입니다. AWS 는 OpenSearch Service 로 옮기라고 안내합니다(Services in Maintenance).
OpenSearch 가 맞는지는 찾는 일이 서비스 기능인지, 가끔 하는 집계인지에 달려 있습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 로그·이벤트를 낱말과 필드로 찾고 대시보드로 지켜본다 | 몇 달 치 로그를 가끔 집계한다(→ Athena) | 도메인 노드가 늘 켜져 있어 쉬는 동안에도 시간 요금이 나간다 |
| 상품 검색처럼 전문 검색이 서비스 기능이다 | 매출 합계처럼 표 집계가 중심이다(→ Redshift) | 샤드 크기·개수와 노드 수를 데이터 크기에 맞춰 설계한다 |
| 쉬는 시간이 길고 노드를 고르기 싫다(Serverless, 최솟값 0) | 쉬다가 온 첫 검색도 바로 답해야 한다 | 최솟값을 올리면 그만큼 OCU 가 늘 켜져 있다 |
들어오는 대로 숫자를 갱신하는 일은 Flink 몫입니다.
6. Managed Service for Apache Flink — 흘러드는 동안 계산한다
5분마다 쌓인 파일을 다시 집계하는 대신, 이벤트가 들어오는 순간 「지난 1분 결제 실패 수」를 갱신하려면 무엇이 필요할까요? Apache Flink 는 스트림을 처리하는 오픈소스 프레임워크입니다. 지난 1분 동안의 실패 수처럼 이벤트 사이에 이어서 들고 있어야 하는 값을 상태(state)라고 합니다. Flink 는 이 값을 들고 있다가 체크포인트로 저장해 두어, 장애 뒤에도 이어서 셉니다.
Managed Service for Apache Flink 는 Flink 애플리케이션을 Java·Scala·Python·SQL 로 짜서 올리면 계산 자원, 가용 영역 장애 조치, 병렬 처리, 자동 확장, 상태 백업(체크포인트·스냅샷)을 맡아 줍니다. 스트림에서 기록을 읽어 시계열 분석을 하고 실시간 대시보드와 지표를 채우는 것이 주 용도입니다. 코드를 IDE 에서 짜 오래 돌리는 애플리케이션 말고도, Studio 노트북에서 SQL 로 스트림을 조회할 수 있습니다(What is Amazon Managed Service for Apache Flink?). 07-3편의 Firehose 가 기록 하나씩 형식만 바꾼다면, Flink 는 여러 기록을 엮는 조인과 시간 구간별 집계를 합니다.
옛 이름은 Kinesis Data Analytics 이고, SQL 로만 짜던 옛 판(Kinesis Data Analytics for SQL)은 2026-01-27 에 완전히 종료됐습니다(Services in Full Shutdown).
Flink 의 청구 단위는 KPU(Kinesis Processing Unit, vCPU 1개·메모리 4 GB)입니다. 기본 설정이면 애플리케이션은 KPU 하나로 돌고, 오케스트레이션용 KPU 하나가 더 붙습니다. 처리량이 몰리면 자동 확장이 KPU 를 더 붙이고 그만큼 더 냅니다. KPU 마다 실행 저장 50 GB 가 딸립니다(Implement application scaling).
Managed Service for Apache Flink · 서울 · 2026-11-13
KPU 시간당 $0.135, 초 단위
오케스트레이션 애플리케이션마다 KPU 1개 추가
실행 저장 KPU 당 50 GB, GB-월 $0.114
Studio 노트북 대화형이면 KPU 2개 추가
켜 둔 내내 KPU 요금이 나가니, 숫자가 1분 안에 바뀌어야 하는 일인지부터 따집니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 들어오는 이벤트로 1분 단위 집계·이상 감지를 바로 낸다 | 하루 한 번 보는 보고서(→ Athena·Glue 배치) | 애플리케이션을 켜 둔 시간만큼 KPU 요금이 나간다 |
| 두 스트림을 엮거나 상태를 들고 계산한다 | 기록 하나씩 형식만 바꿔 S3 에 쌓는다(→ Data Firehose, 07-3편) | Flink 의 API·상태·체크포인트를 익혀야 한다 |
기록 하나씩 형식만 바꾸면 되는 일은 Firehose 에, 하루 한 번 보는 숫자는 Athena 에 맡기는 편이 쌉니다.
7. Quick Sight — 결과를 화면으로 보여 준다
쿼리 결과를 매번 SQL 로 뽑아 스프레드시트로 넘길 수는 없습니다. 기획자가 직접 필터를 바꿔 보는 화면은 무엇으로 만들까요? Quick Sight 는 데이터 원천에 붙어 대시보드를 만들고, 그 대시보드를 내 애플리케이션 안에 넣어 보여 주는 비즈니스 인텔리전스(BI) 기능입니다. Athena·Redshift 같은 분석 서비스에 붙습니다. 원래 Amazon QuickSight 라는 독립 서비스였습니다. 지금은 AI 에이전트·자동화를 묶은 AWS Quick 안의 한 기능 AWS Quick Sight 로 들어갔고, 기존 API 와 연동은 바뀌지 않았습니다(What is AWS Quick?).
Quick Sight 는 보는 사람 수만큼 청구합니다. 대시보드를 만드는 Author 와 보기만 하는 Reader 가 따로입니다. 쿼리를 빠르게 하려고 데이터를 미리 메모리에 올려 두는 엔진 SPICE(Super-fast, Parallel, In-memory Calculation Engine)는 용량만큼 냅니다.
자연어로 묻고 답을 받는 생성형 AI 기능은 Pro 등급에 들어 있습니다. Pro 사용자가 있거나 Q&A 를 켜면 계정에 월 고정 요금이 하나 더 붙습니다.
Quick Sight · 2026-11-13 · BI 요금
Author 사용자당 월 $24 (SPICE 10 GB 포함)
Reader 사용자당 월 $3
Pro 등급 Author Pro $40 · Reader Pro $20
Pro 사용자가 있거나 Q&A(토픽·대시보드 Q&A)를 켜면
계정당 월 $250
SPICE 추가 GB-월 $0.38
- 요금 페이지에는 리전 구분이 없고, Reader 와 SPICE 단가는 서울 가격표와 같습니다. 보는 사람이 많으면 사용자 대신 30분 세션 단위로 사는 Reader 용량(월 500세션 $250)도 있습니다(Quick Sight pricing)
그래서 쓸지 말지는 개발자 몇 명이 쿼리 결과를 보느냐, 여러 부서가 화면을 여느냐로 정해집니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 기획·영업이 대시보드를 직접 보고 필터를 바꾼다 | 개발자 몇 명이 쿼리 결과만 보면 된다(→ Athena 콘솔) | 보는 사람 수만큼 월 요금이 붙는다 |
| 자연어 질문 같은 생성형 AI 기능까지 쓴다(Pro) | 정해진 차트 몇 개만 보면 된다 | Pro 사용자가 생기거나 Q&A 를 켜는 순간 계정당 월 $250 이 붙는다 |
개발자끼리 보는 결과라면 Athena 콘솔이나 OpenSearch Dashboards 로 충분합니다.
8. Lake Formation — 누가 어느 열·행을 보나
분석가는 주문 표를 보되 전화번호 열은 못 보게 하고, 지역 팀은 자기 지역 행만 보게 하려면 어떻게 할까요? IAM 정책은 「이 S3 경로를 읽어도 된다」처럼 경로와 API 단위로 허락하므로, 같은 파일 안의 열과 행을 가르지 못합니다. AWS Lake Formation 은 Glue Data Catalog 위에 표·열·행 단위 권한을 얹습니다. 관계형 DB 의 GRANT·REVOKE 처럼 권한을 주면, Athena·Quick Sight·Redshift Spectrum·EMR·Glue 가 그 권한을 지켜서 읽습니다.
표가 많아지면 하나씩 권한을 주기 어렵습니다. 표와 열에 LF-Tag 라는 꼬리표를 붙여 꼬리표 단위로 권한을 주면, 수천 개 표의 권한을 몇 개의 꼬리표로 관리합니다. 다른 AWS 계정과 표 단위로 데이터를 나눌 수도 있습니다(What is AWS Lake Formation?).
권한을 만들고 쓰는 것과 계정 사이 공유는 무료입니다. 나가는 것은 주로 밑의 S3·Glue Data Catalog 요금이고, 다른 분석 서비스를 거치지 않고 Storage API 로 직접 읽을 때는 읽은 바이트만큼 따로 냅니다(AWS Lake Formation pricing). 한때 있던 Governed Tables 기능은 2024-12-31 에 완전히 종료됐습니다(Services in Full Shutdown).
권한은 무료라, 따질 것은 값이 아니라 IAM 위에 권한이 한 겹 더 생긴다는 점입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 한 데이터 레이크를 여러 팀이 쓰는데 팀마다 볼 열·행이 다르다 | 분석가 한두 명이 버킷 전체를 봐도 된다(→ IAM 정책으로 충분) | IAM 권한과 Lake Formation 권한 두 겹을 함께 읽어야 한다 |
| 다른 AWS 계정과 표 단위로 데이터를 나눈다 | 파일을 통째로 넘기면 끝난다(→ S3 버킷 정책) | 받는 계정에서도 Lake Formation 권한과 카탈로그 연결을 따로 설정해야 한다 |
버킷 단위로 나누면 충분한 데이터라면 IAM 과 버킷 정책으로 끝냅니다.
9. 켜 두기만 해도 한 달에 얼마인가
여덟 서비스의 값은 두 묶음으로 나눠 볼 수 있습니다. 쓰지 않으면 0 에 가까운 쪽과, 켜 두는 동안 계속 나가는 쪽입니다. 앞 절의 단가로 흔한 첫 구성을 하나씩 셈합니다. 하루 단위로 쓰는 항목은 한 달을 30일로, 늘 켜 두는 항목은 AWS 계산기가 쓰는 평균 한 달 730시간으로 셉니다.
서울 · 2026-11-13
쓸 때만 낸다
Athena 읽은 TB 당 $5.00 (1절)
Glue ETL Glue 6.0, 10 DPU 로 10분, 매일 30일
10 × (10/60) × $0.308 × 30 = $15.40
Redshift Serverless 8 RPU, 하루 2시간 쿼리
8 × $0.438 × 2 × 30 = $210.24
EMR Serverless 작업마다 쓴 vCPU·메모리 시간 (3절)
켜 둔 만큼 낸다
EMR on EC2 m7g.xlarge 3대
3 × $0.2414 × 730 = $528.67
Redshift rg.large 노드 1대
$0.4473 × 730 = $326.53
OpenSearch r6g.large.search 2대 + gp3 100 GB씩
2 × $0.203 × 730 = $296.38
200 × $0.1391 = $27.82
합계 = $324.20
Flink KPU 1 + 오케스트레이션 1, 저장 50 GB
2 × $0.135 × 730 = $197.10
50 × $0.114 = $5.70
합계 = $202.80
Quick Sight Author 1명 + Reader 10명
$24 + 10 × $3 = $54.00
- EMR on EC2 클러스터를 하루 8시간만 켜고 끄면 3 × $0.2414 × 8 × 30 = $173.81 입니다. 켜고 끄는 일은 내 몫입니다
- Flink 는 자동 확장이 KPU 를 늘리면 그만큼 더 냅니다
- Redshift 두 줄의 관리형 저장(RMS)과 Athena·Glue 가 읽고 쓰는 S3 요금은 넣지 않았습니다
- Redshift Serverless 8 RPU 와
rg.large한 대는 같은 처리 능력이 아니므로 두 값을 손익분기로 견주지 않습니다
위 묶음은 쿼리를 멈추면 계산 요금도 멈춥니다. 아래 묶음은 아무도 쓰지 않는 새벽에도 OpenSearch 두 대가 월 $324.20, Flink 애플리케이션 하나가 월 $202.80 을 냅니다. 그래서 처음 분석을 붙일 때는 위 묶음(S3 + Glue Data Catalog + Athena, 필요하면 Redshift Serverless)으로 시작하고, 검색이나 실시간 집계가 서비스 기능이 될 때 아래 묶음을 켭니다.
이럴 땐 무엇
| 상황 | 서비스 | 이유 |
|---|---|---|
| S3 에 쌓인 로그를 가끔, 그때그때 다른 SQL 로 본다 | Athena | 서버 없이 읽은 TB 당 $5.00 이고, Parquet 로 바꾸면 읽는 양이 준다 |
| 매일 밤 JSON 을 Parquet 로 바꾸고 표 정의를 잡는다 | Glue | 크롤러가 스키마를 잡고 ETL 작업은 도는 동안만 낸다 |
| 사내 Spark·Hadoop 작업을 설정을 바꾸지 않고 옮긴다 | EMR | 클러스터와 소프트웨어 버전을 내가 고른다 |
| 여러 원천을 모아 대시보드가 근무 시간 내내 조인 쿼리를 던진다 | Redshift Serverless | 열 단위 저장으로 되풀이 쿼리가 빠르고, 쿼리가 없으면 계산 요금이 0 이다 |
| 로그를 낱말로 찾고 상품 검색을 붙인다 | OpenSearch Service | 검색 엔진이다. 대신 노드가 늘 켜져 있다 |
| 들어오는 결제 이벤트로 1분 단위 실패 수를 바로 갱신한다 | Managed Service for Apache Flink | 흘러드는 동안 상태를 들고 계산한다 |
| 기획자가 직접 보는 대시보드 | Quick Sight | 사용자당 월 요금으로 Athena·Redshift 결과를 화면에 올린다 |
| 팀마다 볼 열·행을 나눈다 | Lake Formation | 권한은 무료이고 열·행 단위로 나뉜다 |
자주 붙는 서비스는 S3(데이터 레이크 저장소), Data Firehose·Kinesis Data Streams·MSK(07-3편, 데이터가 들어오는 길), IAM(서비스 역할과 접근), CloudWatch(쿼리·노드 지표와 경보), SNS(Athena 사용량 경보), Step Functions·EventBridge(07-2편, 밤 배치의 순서와 시작)입니다.
한 장 요약
분석 서비스는 질문을 어디서 계산하느냐로 갈립니다. S3 에 둔 채 묻는 Athena·Glue·EMR Serverless 와, 옮겨 담되 쿼리가 돌 때만 계산 요금을 내는 Redshift Serverless 는 쓸 때만 냅니다. 노드로 띄우는 EMR on EC2·Redshift 프로비저닝 클러스터·OpenSearch 도메인과 쉬지 않고 도는 Flink 는 켜 둔 만큼 냅니다. 첫 구성은 쓸 때만 내는 쪽으로 시작하고, 파일을 압축한 Parquet 로 바꿔 필요한 열만 읽으면 1절 예시처럼 Athena 값이 열두 분의 일로 줄어듭니다.
관련 항목
이 편의 서비스
Amazon Athena · AWS Glue · Amazon EMR · Amazon Redshift · AWS Quick Sight · AWS Quick · Amazon OpenSearch Service · AWS Lake Formation · Managed Service for Apache Flink
앞뒤로 이어지는 편
AWS 07-3 쉬지 않고 흐르는 데이터 — Kinesis Data Streams·Data Firehose·MSK · AWS 02-1 S3 하나로 이렇게 많은 일을 한다 — 저장 등급·S3 Tables·S3 Vectors · AWS 03-1 관계형 DB를 맡긴다 — RDS·Aurora·Aurora DSQL · AWS 05-1 누가 무엇을 할 수 있나 — IAM·IAM Identity Center·Cognito·Verified Permissions · AWS 07-2 이벤트로 잇고 흐름을 짠다 — EventBridge·Scheduler·Pipes·Step Functions
데이터를 담는 방식
데이터 레이크 · 데이터 웨어하우스 · 데이터 마트 · 열 지향 저장소 · Apache Parquet · Apache ORC · Apache Iceberg · 파티션 · 데이터 카탈로그 · 메타데이터
데이터를 옮기고 바꾸는 일
ETL · ELT · 배치 처리 · AWS Glue Data Catalog · Glue 크롤러 · DPU · 스키마 · 스키마 진화 · Redshift COPY · Redshift Spectrum
계산 엔진
Apache Spark · Hadoop · MapReduce · Presto · Apache HBase · Apache Flink · EMR Serverless · Redshift Serverless · RPU · KPU
검색과 실시간 집계
OpenSearch · Elasticsearch · OpenSearch Serverless · OCU · 전문 검색 · 역색인 · 벡터 검색 · 스트림 · 집계 · 슬라이딩 윈도 · 체크포인트
보여 주고 지키는 쪽
비즈니스 인텔리전스 · 대시보드 · SPICE · 데이터 시각화 · AWS IAM · LF-Tag · 속성 기반 접근 제어 · 행 수준 보안 · AWS CloudTrail