김신건의 로그 - 위키 / cloud

[AWS] Amazon Pinpoint: EoS & End User Messaging 마이그레이션

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Pinpoint 는 AWS 의 고객 참여 (customer engagement) 플랫폼 이었음. 이메일, SMS, 푸시 알림, 음성 통화를 통합 채널로 발송하고 세그먼트/캠페인/저니로 조직화. 2024-11 End of Support 발표, 2026-10-30 종료 예정.

End of Support 타임라인 (핵심)

[!CAUTION] 2026-10-30 이후 Pinpoint 콘솔 접근/주요 기능 사용 불가. 지금 마이그레이션 계획 필수.

시기	이벤트
2024-11	End of Support 공식 발표
2025	신규 계정 접수 중단, 마이그레이션 가이드 배포
2026-10-30	콘솔 접근 종료, Endpoints/Segments/Campaigns/Journeys/Analytics 종료

무엇이 종료되고 무엇이 남는가

종료되는 것 (2026-10-30)

Pinpoint 콘솔 UI
Endpoints - 사용자별 채널 프로필 관리
Segments - 오디언스 타겟팅
Campaigns - 예약 발송
Journeys - 다단계 워크플로 (트리거 -> 이메일 -> 대기 -> SMS 등)
Analytics - 발송/오픈/클릭 대시보드
Machine Learning 모델 - 추천, 이탈 예측

남는 것 (계속 유지)

SMS v2 API - AWS End User Messaging SMS 로 이관
Voice v2 API - AWS End User Messaging Voice
Push API - AWS End User Messaging Push
OTP API - OTP 검증
Phone Number 관리 - 발신 번호 (long code, short code, TFN)

즉, 로우 레벨 채널 API 는 이름만 바뀌어 유지. 상위 오케스트레이션 (segment/campaign/journey) 은 사라짐.

마이그레이션 매핑

Pinpoint 에서 하던 것	마이그레이션 대상
Pinpoint SMS 발송	AWS End User Messaging SMS
Pinpoint Voice 발송	AWS End User Messaging Voice
Pinpoint Push 알림	AWS End User Messaging Push
Pinpoint OTP	AWS End User Messaging OTP
Pinpoint 이메일	Amazon SES (Simple Email Service)
Endpoints/Segments 관리	자체 DB ([[dynamodb\|DynamoDB]] / [[aws-rds\|RDS]]) + 앱 로직
Campaigns (예약 발송)	[[aws-eventbridge\|EventBridge Scheduler]] + [[aws-lambda\|Lambda]]
Journeys (워크플로)	[[aws-step-functions\|Step Functions]] + End User Messaging
Analytics (open/click)	Amazon SES event destinations + [[aws-kinesis-data-streams\|Kinesis]] + BI
Predictive ML	SageMaker (자체 학습)

AWS End User Messaging

포지션: Pinpoint 의 channel API 를 계승한 새 서비스군.

End User Messaging SMS

import boto3
sms = boto3.client('pinpoint-sms-voice-v2')  # API 는 여전히 v2

response = sms.send_text_message(
    DestinationPhoneNumber='+821012345678',
    OriginationIdentity='+18005551234',   # 미리 발급받은 발신 번호
    MessageBody='주문이 배송 시작되었습니다',
    MessageType='TRANSACTIONAL',   # or PROMOTIONAL
    ConfigurationSetName='my-config-set'
)

기능:

200+ 국가 SMS 발송
Long/Short code, 10DLC, TFN, Sender ID
Two-way SMS (수신)
MMS (일부 국가)
Delivery reports -> [[aws-kinesis-data-streams|Kinesis]] / [[aws-sns|SNS]] / CloudWatch
Opt-out 자동 처리
국가별 요금

End User Messaging Push

APNs (iOS), FCM (Android), ADM (Kindle), Baidu
발송 API 직접 호출 (오케스트레이션은 직접)

End User Messaging Voice

TTS (Polly 통합) 또는 사전 녹음
OTP 음성 전달
국제 발신

이메일: Amazon SES

Pinpoint 이메일은 SES 로 마이그레이션.

import boto3
ses = boto3.client('sesv2')

ses.send_email(
    FromEmailAddress='no-reply@example.com',
    Destination={'ToAddresses': ['user@example.com']},
    Content={
        'Simple': {
            'Subject': {'Data': '주문 확인'},
            'Body': {'Html': {'Data': '<h1>주문이 접수되었습니다</h1>'}}
        }
    },
    ConfigurationSetName='transactional'
)

SES 주요 기능:

Transactional / marketing 이메일
SPF / DKIM / DMARC
Reputation dashboard
Event destinations -> [[aws-kinesis-data-streams|KDS]] / [[aws-eventbridge|EventBridge]]
Suppression list
Sending quota (샌드박스 -> 프로덕션 승인)
Configuration sets
템플릿 (SES Templates)

캠페인 / 저니 대체 아키텍처

flowchart TB
    subgraph Trigger[트리거]
        Time["EventBridge Scheduler<br/>(cron)"]
        Event["앱 이벤트<br/>(주문 완료 등)"]
    end

    Trigger --> SF["Step Functions<br/>(저니 워크플로)"]

    subgraph Journey["예: Cart Abandonment 저니"]
        S1["1. 즉시 SMS 전송"]
        S2["2. 1시간 대기"]
        S3["3. 이메일 전송"]
        S4["4. 24시간 대기"]
        S5["5. 최종 할인 이메일"]
    end

    SF -.-> S1 -.-> S2 -.-> S3 -.-> S4 -.-> S5

    S1 --> EUM["End User Messaging SMS"]
    S3 --> SES["Amazon SES"]
    S5 --> SES

    Analytics["Analytics<br/>(open/click)"] -.-> Kinesis
    SES --> Kinesis[Kinesis]
    Kinesis --> S3D[("S3 이벤트 저장")]
    S3D --> Athena[Athena SQL 대시보드]

Endpoints/Segments 대체:

사용자 프로필 저장: [[dynamodb|DynamoDB]] 또는 [[aws-rds|RDS]]
Segment 조회: 프로필 DB 에 SQL / query
Personalization: 자체 로직 or SageMaker

OTP (One-Time Password)

Pinpoint OTP API 는 그대로 유지 (End User Messaging).

sms.send_destination_number_verification_code(
    DestinationPhoneNumber='+821012345678',
    DestinationCountryParameters={},
    OriginationIdentity='+18005551234',
    ConfigurationSetName='otp-config'
)

# 검증
sms.verify_destination_number(
    DestinationPhoneNumber='+821012345678',
    VerificationCode='123456'
)

Pinpoint 를 계속 쓰던 사용자를 위한 체크리스트

신규 프로젝트라면

Pinpoint 자체는 선택하지 말 것. 처음부터:

SMS/Push/Voice -> AWS End User Messaging
Email -> Amazon SES
오케스트레이션 -> [[aws-step-functions|Step Functions]] + [[aws-eventbridge|EventBridge]]
사용자 프로필 -> [[dynamodb|DynamoDB]]
분석 -> [[aws-kinesis-data-streams|Kinesis]] + [[aws-s3|S3]] + [[aws-athena|Athena]] + QuickSight

함정

[!CAUTION] 2026-10-30 이후 Pinpoint 콘솔/기능 종료. 지금 마이그레이션 시작. 미룰수록 위험.

[!WARNING] Endpoints/Segments/Campaigns/Journeys 는 자동 마이그레이션 안 됨. 자체 앱으로 재구현.

[!IMPORTANT] mobiletargeting:* 권한 은 없어짐. 신규 IAM 은 sms-voice:*, ses:*, push:* (End User Messaging).

[!CAUTION] SES 는 처음 sandbox 모드 (본인 확인된 주소만 발송). 프로덕션 발송은 승인 요청 필요.

[!WARNING] SMS 국가별 규제 상이 (10DLC, TFN 등록 등). 발신 번호 종류 신중 선택.

[!IMPORTANT] A/B 테스트, Personalization 등 고급 기능은 자체 구현하거나 서드파티 (Braze, OneSignal, Iterable) 로.

[AWS] Amazon Redshift

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Redshift 는 AWS 가 관리하는 페타바이트 규모 컬럼형 데이터 웨어하우스 입니다. 2012년 PostgreSQL 8.0.2 를 기반으로 시작해 MPP (Massively Parallel Processing) 아키텍처로 대규모 분석 쿼리를 병렬 실행합니다. 2020년대에는 Redshift Serverless, Zero-ETL, Data Sharing (writes), Streaming Ingestion, Redshift ML 등으로 확장되었습니다.

왜 데이터 웨어하우스 인가

OLTP (RDS, Aurora) 는 트랜잭션 지향 (row-based). 분석 쿼리 (수십억 행 aggregation) 는 다른 스토리지/실행 모델이 필요:

컬럼형 저장: 필요 컬럼만 읽음 -> I/O 절감
압축: 컬럼 값이 유사 -> 압축률 높음 (5-10x)
MPP: 슬라이스로 나뉜 데이터를 병렬 스캔
집계 최적화: SUM, COUNT, GROUP BY 등 대량 aggregation 특화

아키텍처

flowchart LR
  U[클라이언트<br/>BI/JDBC/ODBC] --> LN[Leader Node]
  LN --> CN1[Compute Node 1]
  LN --> CN2[Compute Node 2]
  LN --> CN3[Compute Node N]
  CN1 --> RMS[(Redshift Managed<br/>Storage on S3)]
  CN2 --> RMS
  CN3 --> RMS

Leader Node: 쿼리 파싱, 최적화, compute node 로 분배, 결과 통합
Compute Nodes: 실제 데이터 저장 + 실행. 각 노드는 여러 slice 로 분할.
RMS (Redshift Managed Storage): S3 위 계층. Compute 와 스토리지 독립 스케일링 (RA3+).

노드 유형 (2025-2026)

RA3 (권장)

Compute + Storage 분리. Compute 만 늘리거나 storage 만 확장 가능.

ra3.large, ra3.xlplus, ra3.4xlarge, ra3.16xlarge
Managed Storage: 실제 데이터는 S3 layer. Local SSD 는 캐시.
Data Sharing, Zero-ETL, Streaming Ingestion 모두 RA3+ 만.

DS2 (Deprecated)

이전 노드. RA3 로 마이그레이션 권장.

DC2 (Deprecated)

Dense Compute. Compute+Storage 결합. 2025년 이후 신규 사용 안 함.

결론: RA3 또는 Redshift Serverless 만 선택.

Redshift Serverless

Compute 를 완전 자동 스케일. 유휴 시 요금 없음.

RPU (Redshift Processing Unit) 단위
Base capacity: 8 ~ 512 RPU
사용량 기반 청구

Provisioned RA3 vs Serverless

축	RA3 provisioned	Serverless
워크로드	예측 가능한 지속 부하	스파이키, 간헐적
비용	Reserved instance 로 저렴	사용량 만큼
관리	Cluster 관리 필요	AWS 자동
워크로드 관리 (WLM)	Manual + Auto	Auto only
유휴 요금	Instance-hour 지속	0
동시 사용자 수	Concurrency Scaling 필요	자동 스케일

결정: 새 프로젝트는 Serverless 부터. 예측 가능한 heavy 부하면 RA3.

Managed Storage (RMS)

RA3 / Serverless 의 스토리지 계층. S3 위에 구축되어 compute 와 독립 스케일. 사용자는 스토리지 크기 걱정 없음, 사용한 만큼 GB-월 청구.

Backup: 자동 (증분)
Hot data: local SSD 캐시
Cold data: S3
압축: 컬럼별 자동 encoding

분산 스타일 (Distribution Style)

테이블 데이터를 노드에 어떻게 나눌지.

EVEN

라운드 로빈. 균등 분포. JOIN 없는 fact table 에 적합.

KEY

특정 컬럼 hash 로 분산. 같은 key 조인 시 co-located (성능 최적).

CREATE TABLE orders (
  order_id BIGINT,
  user_id BIGINT NOT NULL,
  ...
) DISTKEY(user_id);

CREATE TABLE users (
  user_id BIGINT NOT NULL,
  ...
) DISTKEY(user_id);

-- users.user_id JOIN orders.user_id 는 network shuffle 없이 로컬

ALL

모든 노드에 복제. 작은 dimension table (수백만 행) 에.

CREATE TABLE date_dim (...) DISTSTYLE ALL;

AUTO

Redshift 가 데이터 크기 기반 자동 선택. 기본값.

정렬 키 (Sort Key)

블록 skip 을 위한 물리적 정렬:

CREATE TABLE orders (
  order_id BIGINT,
  order_date DATE,
  amount NUMERIC
) SORTKEY(order_date);

SELECT SUM(amount) FROM orders WHERE order_date >= '2026-01-01';
-- Redshift 는 order_date < 2026-01-01 인 블록 skip

Compound sort key (기본): 여러 컬럼 우선순위
Interleaved sort key: 여러 컬럼 균등 (거의 사용 안 함, 성능 저하 사례 다수)

압축 (Encoding)

컬럼 별 압축. 자동 감지 (ANALYZE COMPRESSION) 또는 명시:

CREATE TABLE users (
  user_id BIGINT ENCODE az64,
  email VARCHAR(256) ENCODE zstd,
  created_at TIMESTAMP ENCODE az64,
  status CHAR(10) ENCODE bytedict
);

압축 알고리즘:

AZ64 (Amazon 개발, 정수/시간에 최적)
ZSTD (범용, 문자열)
LZO, RUNLENGTH, DELTA, BYTEDICT, MOSTLY8/16/32

COPY (대량 로드)

COPY orders
FROM 's3://my-bucket/data/orders/'
IAM_ROLE 'arn:aws:iam::123:role/RedshiftLoadRole'
FORMAT AS PARQUET;

지원 format: CSV, TSV, JSON, [[apache-parquet|Parquet]], ORC, Avro. Parquet 가 컬럼형이라 로드 빠름. 대부분의 [[etl|ETL]] 파이프라인은 [[aws-glue|Glue]] 로 변환 후 Parquet 로 저장 -> COPY.

옵션:

MAXERROR: 오류 허용 개수
MANIFEST: 여러 파일을 매니페스트로
COMPUPDATE: 압축 encoding 자동 갱신

Redshift Spectrum (S3 쿼리)

S3 데이터를 Redshift 로 로드하지 않고 직접 쿼리. External table.

CREATE EXTERNAL SCHEMA spectrum_schema
FROM DATA CATALOG
DATABASE 'my_glue_db'
IAM_ROLE 'arn:aws:iam::123:role/SpectrumRole';

SELECT * FROM spectrum_schema.access_logs
WHERE date >= '2026-01-01' LIMIT 100;

-- Redshift 내부 테이블과 JOIN 도 가능
SELECT o.order_id, l.click_count
FROM orders o
JOIN spectrum_schema.access_logs l ON o.user_id = l.user_id;

[[aws-glue|Glue Data Catalog]] 로 스키마 관리. [[apache-parquet|Parquet]] / ORC 가 성능 최적. 별도 요금 $5/TB scanned.

자세히: [[aws-redshift-spectrum|Redshift Spectrum]].

Cross-cluster / cross-account read (write 도 지원) 데이터 공유. 데이터 복제 없음.

-- Producer cluster
CREATE DATASHARE sales_share;
ALTER DATASHARE sales_share ADD SCHEMA public;
ALTER DATASHARE sales_share ADD TABLE public.orders;
GRANT USAGE ON DATASHARE sales_share TO ACCOUNT '123456789012';

-- Consumer cluster
CREATE DATABASE sales_shared FROM DATASHARE sales_share OF ACCOUNT '123456789012' NAMESPACE 'producer-namespace';
SELECT * FROM sales_shared.public.orders;

RA3 / Serverless 만. 조직 내 팀별 사일로 관리에 유리.

Zero-ETL Integrations

Aurora MySQL / PostgreSQL, RDS MySQL, DynamoDB 등에서 Redshift 로 거의 실시간 replication. DMS 없이.

Source (Aurora / RDS / DynamoDB)
   ↓ (초 단위 CDC)
Redshift (Zero-ETL target)

소스에 트랜잭션 -> Redshift 반영 (수 초)
최대 50 통합/target
Primary key 필요 (source 테이블)

Streaming Ingestion

Kinesis Data Streams, MSK (Kafka) 에서 실시간 로드.

CREATE EXTERNAL SCHEMA kds FROM KINESIS;

CREATE MATERIALIZED VIEW events AUTO REFRESH YES AS
SELECT approximate_arrival_timestamp,
       JSON_EXTRACT_PATH_TEXT(kinesis_data, 'user_id')::BIGINT AS user_id,
       JSON_EXTRACT_PATH_TEXT(kinesis_data, 'event') AS event
FROM kds."my-stream" WHERE is_utf8(kinesis_data);

Materialized view auto-refresh 로 지속 갱신.

Redshift ML

SQL 로 ML 모델 학습/예측. SageMaker 자동 통합.

CREATE MODEL churn_prediction
FROM (SELECT customer_id, age, tenure, ..., churned FROM customers WHERE churn_flag_known = TRUE)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'my-redshift-ml-bucket');

-- 예측
SELECT customer_id, predict_churn(age, tenure, ...) AS churn_probability
FROM customers;

내부적으로 SageMaker Autopilot / XGBoost / LinearLearner 등 활용.

Concurrency Scaling

트래픽 급증 시 추가 클러스터 자동 프로비저닝. Read-heavy 쿼리 오프로드.

ALTER USER analyst SET enable_result_cache_for_session TO ON;
ALTER SYSTEM SET concurrency_scaling TO auto;

RA3 는 매일 1시간 무료, 이후 초 단위 청구. Serverless 는 자동.

WLM (Workload Management)

RA3 provisioned 만. Query queue 를 정의해 사용자별 우선순위.

Auto WLM (권장): AWS 자동 조정
Manual WLM: 큐/메모리/동시성 명시

Redshift Serverless 는 auto only.

VACUUM & ANALYZE

VACUUM: DELETE 후 공간 회수, 정렬 재수행 (RA3+ 는 대부분 자동)
ANALYZE: 통계 갱신 (query optimizer)

VACUUM FULL orders;
ANALYZE orders;

백업 & 복구

Automated snapshot: 8시간 or 5 GB 데이터 변경마다 (자동)
Manual snapshot: 사용자 지정
Cross-region copy: DR
Restore from snapshot: 새 클러스터로

성능 튜닝

1. DISTKEY / SORTKEY 설계

Join 자주 하는 컬럼 = DISTKEY, filter/range 쿼리 컬럼 = SORTKEY.

2. COPY 성능

Multi-part 파일 (여러 개로 나눠 병렬 로드)
Parquet (컬럼형, 압축)
압축 파일: gzip/bzip2/lzop

3. 쿼리 프로파일

EXPLAIN SELECT ...;
SELECT * FROM SVL_QLOG WHERE ...;

STL_, SVL_ 시스템 뷰로 실행 이력, redistribution 감지.

4. Materialized View

CREATE MATERIALIZED VIEW daily_sales AS
SELECT DATE(order_date), SUM(amount) FROM orders GROUP BY 1;

주기적 refresh 또는 auto refresh.

5. Result Cache

같은 쿼리 반복 -> 캐시 결과 (기본 활성).

보안

VPC only (RA3 provisioned) 또는 VPC + public (조합 가능)
Encryption: KMS (기본 활성 권장)
IAM 통합: SSO, IAM database authentication
Column-level access control: GRANT SELECT (col1, col2) ON table TO user;
Row-level security (RLS): 정책 기반 row 필터

데이터 API (`redshift-data`)

JDBC 없이 REST API 로 실행:

aws redshift-data execute-statement \
  --workgroup-name my-serverless-workgroup \
  --database dev \
  --sql "SELECT COUNT(*) FROM orders;"

aws redshift-data get-statement-result --id <id>

Lambda 등에서 편리.

함정

[!WARNING] DC2 / DS2 은 legacy. RA3 / Serverless 로 마이그레이션 권장 (2025년 이후 신규 지원 축소).

[!CAUTION] INSERT 한 행씩은 매우 느림. 대량 로드는 반드시 COPY. Streaming Ingestion 도 batch.

[!WARNING] JOIN 이 nested loop / hash redistribute 로 실행되면 성능 급락. DISTKEY 설계로 co-located join.

[!IMPORTANT] Serverless base RPU 하한. 너무 낮으면 병렬성 부족. 프로덕션은 최소 16 RPU 부터 검토.

[!CAUTION] Zero-ETL 지연. “거의 실시간” 이지만 몇 초 ~ 몇 분. Sub-second 요구는 다른 아키텍처.

[!WARNING] VARCHAR 크기 잘못 잡으면 낭비. 컬럼형 압축이 크기 영향 받음. 필요 이상 크게 잡지 말 것.

Redshift vs 다른 데이터 웨어하우스

DW	강점	약점
Redshift	AWS 통합, 성숙, Spectrum	Vertical scaling 어려움 (Serverless 로 완화)
Snowflake	Multi-cloud, 사용자 경험 우수	벤더 락인, 비용
BigQuery	Serverless, low overhead	GCP 종속
Databricks SQL	Delta Lake + Photon	개별 세팅 필요
ClickHouse	초고속, 오픈소스	자체 관리
Firebolt	신생, 성능 강조	성숙도

[AWS] Athena: 서버리스 SQL on S3

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Athena 는 S3 에 있는 데이터를 서버 없이 SQL 로 쿼리 하는 서비스. 클러스터 프로비저닝, 스키마 로딩, 인덱스 생성 없이 데이터 파일 (Parquet/ORC/CSV/JSON/Iceberg/Hudi/Delta) 을 바로 쿼리.

내부 엔진은 Trino 기반 (Engine v3). 이전 v2 는 Presto 기반이었음. [[aws-glue|Glue Data Catalog]] 를 메타 저장소로 씀.

사용 상황

상황	적합성
Ad-hoc 로그 분석	적합
BI 대시보드 백엔드 (QuickSight 등)	적합
Data lake 위 SQL	적합
ETL의 lightweight transform (CTAS)	적합
Federated query (RDS/DynamoDB 통합 쿼리)	적합, 소규모만
초저지연 (< 1초) API 백엔드	부적합, DW 나 캐시
트랜잭션 처리	부적합, [[postgresql\|Postgres]]
초대용량 반복 배치	부적합, [[aws-redshift\|Redshift]] / EMR

아키텍처

flowchart LR
    User["사용자 / BI / Lambda"] -->|"SQL"| Athena
    Athena -->|"meta 조회"| Glue[("Glue Data Catalog")]
    Athena -->|"data 스캔"| S3[("S3 데이터<br/>Parquet/ORC/CSV/Iceberg")]
    Athena -->|"결과 저장"| Res[("S3 결과 버킷")]
    Athena -->|"제어"| WG["Workgroup<br/>(비용/암호화/버전)"]

엔진: Trino (Engine v3)
메타 저장소: [[aws-glue|Glue Data Catalog]] (Hive Metastore 호환)
데이터: [[aws-s3|S3]] 그대로 (Athena 는 저장 X)
결과: S3 결과 버킷 (workgroup 별)

Engine v2 vs v3

항목	v2 (구)	v3 (현재)
기반	Presto	Trino
성능	기준	~10-15% 개선
SQL 표준	Presto 계열	ANSI SQL 확장
[[apache-parquet\|Parquet]] v2 encoding	부분	완전
Iceberg / Hudi / Delta	제한	완전 지원
Query Result Reuse	X	O (24h)
auto-upgrade	-	기본 활성 (workgroup 별)

정책: v3 이 기본. AWS Health Dashboard 로 deprecation 통보. Workgroup pin 도 가능.

요금 모델

1. On-demand (기본)

$5 / TB scanned (region 별 상이, us-east-1 기준)
최소 10 MB per query (실제 스캔이 작아도 10 MB 로 청구)
성공/실패 쿼리 모두 청구
DDL 은 무료

Scan 1 TB Parquet =  $5
Scan 4 GB Parquet =  $5 × 4/1024 = $0.02  (10MB 는 넘으니 실 크기)
Scan 5 MB CSV     =  $5 × 10/1024/1024 = $0.00005  (10MB 로 청구)

2. Capacity Reservation (예약)

$0.30 / DPU-hour
예측 가능한 큰 워크로드에 유리 (스캔 요금 아님)
사용 안 하는 시간에는 요금 청구 안 됨 (예약 안 하면)
DPU 을 워크그룹 단위로 예약

언제 유리:

하루 수 TB 이상 반복 스캔
동시 사용자 많음
스캔량이 큰 쿼리를 자주

3. Athena for Apache Spark

$0.35 / DPU-hour
Driver 1 DPU + workers (계산 시간만)
Notebook 세션 (Jupyter 스타일)

요금 계산 예:

계산 6회, 각 20 DPU 1분, 세션 1시간 (driver 1 DPU):
  worker DPU-hour = 6 × 20 × (1/60) = 2 DPU-hr
  driver DPU-hour = 1 × 1 = 1 DPU-hr
  총 = 3 DPU-hr × $0.35 = $1.05

4. Federated Query

데이터 스캔은 동일 $5/TB
Lambda 커넥터 호출 = Lambda 요금 별도

Workgroups

팀/워크로드 격리 단위. 각 workgroup 은:

결과 저장 위치 (S3)
암호화 정책
엔진 버전 pin
데이터 스캔 한도 (per-query, per-workgroup)
CloudWatch 지표 발행 여부
태그 (비용 배분)

Cost Control:

per-query limit:  1 GB
  → 쿼리가 1 GB 초과 스캔 시 자동 cancel
per-workgroup limit: 10 GB / 15분
  → SNS 알림 (자동 cancel 아님)

가장 흔한 사고 방지: SELECT * 인 실수 쿼리로 수 TB 스캔되는 것을 workgroup 한도로 차단.

파일 포맷별 비용 영향

포맷	압축	1 TB raw 스캔 시 실 스캔량	청구
CSV (uncompressed)	1x	1 TB	$5
CSV + GZIP	3-4x	~300 GB	$1.50
JSON	1-2x	~800 GB	$4
[[apache-parquet\|Parquet]] + SNAPPY	3-4x + column projection	~10 GB (컬럼 1개)	$0.05
[[apache-parquet\|Parquet]] + ZSTD	4-6x + column projection	~7 GB	$0.035

[!IMPORTANT] CSV -> Parquet 로 옮기는 것만으로 10-100배 요금 절감. Athena 비용 최적화의 첫 단계.

파티션 (Partitions)

Hive 스타일 디렉토리 파티션:

s3://bucket/events/
├── year=2026/
│   ├── month=07/
│   │   ├── day=15/
│   │   │   └── part-00000.parquet

CREATE EXTERNAL TABLE events (
  user_id BIGINT,
  event_type STRING,
  amount DECIMAL(10,2)
)
PARTITIONED BY (year INT, month INT, day INT)
STORED AS PARQUET
LOCATION 's3://bucket/events/';

-- 파티션 등록 (자동)
MSCK REPAIR TABLE events;

-- 쿼리 (year=2026, month=7 파티션만 스캔)
SELECT COUNT(*) FROM events
WHERE year = 2026 AND month = 7 AND event_type = 'purchase';

Partition Projection

카탈로그 등록 없이 규칙으로 파티션을 유추. 파티션이 수백만 개인 대규모 데이터에 유리.

CREATE EXTERNAL TABLE events (...)
PARTITIONED BY (year INT, month INT, day INT)
STORED AS PARQUET
LOCATION 's3://bucket/events/'
TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.year.type' = 'integer',
  'projection.year.range' = '2020,2027',
  'projection.month.type' = 'integer',
  'projection.month.range' = '1,12',
  'projection.day.type' = 'integer',
  'projection.day.range' = '1,31',
  'storage.location.template' = 's3://bucket/events/year=${year}/month=${month}/day=${day}/'
);

장점:

Glue Catalog partition API 호출 없음 (요금/지연 감소)
새 파티션 자동 인식 (ALTER TABLE ADD PARTITION 불필요)
대규모 시계열에 최적

CTAS (CREATE TABLE AS SELECT)

쿼리 결과를 새 테이블로 저장. Parquet + 파티셔닝으로 lightweight ETL.

CREATE TABLE curated.orders_2026
WITH (
  format = 'PARQUET',
  parquet_compression = 'ZSTD',
  external_location = 's3://curated/orders_2026/',
  partitioned_by = ARRAY['year', 'month']
)
AS
SELECT
  order_id, user_id, amount,
  YEAR(order_date) AS year,
  MONTH(order_date) AS month
FROM raw.orders
WHERE order_date >= DATE '2026-01-01';

INSERT INTO 도 지원 (append). CTAS + INSERT INTO 는 사실상 Athena 내에서 [[etl|ELT]] 를 가능하게 함.

Apache Iceberg (Athena 에서)

Iceberg v2 테이블 완전 지원 (2024+).

CREATE TABLE lakehouse.orders (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10,2),
  order_date DATE
)
PARTITIONED BY (order_date)
LOCATION 's3://lakehouse/orders/'
TBLPROPERTIES (
  'table_type' = 'ICEBERG',
  'format' = 'parquet',
  'write_compression' = 'zstd'
);

-- ACID 트랜잭션 (UPDATE / DELETE / MERGE)
UPDATE lakehouse.orders SET amount = amount * 1.1 WHERE order_id = 123;
DELETE FROM lakehouse.orders WHERE user_id = 999;

MERGE INTO lakehouse.orders AS t USING staging AS s
  ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET amount = s.amount
  WHEN NOT MATCHED THEN INSERT VALUES (s.order_id, s.user_id, s.amount, s.order_date);

-- Time travel
SELECT * FROM lakehouse.orders FOR TIMESTAMP AS OF TIMESTAMP '2026-07-01 00:00:00';
SELECT * FROM lakehouse.orders FOR VERSION AS OF 12345;

제약:

Lake Formation 으로 등록된 Iceberg 테이블 DDL 제한
중첩 필드 파티셔닝 X
ALTER TABLE SET LOCATION 미지원
시간 정밀도 밀리초 (마이크로초 X)

Federated Query

Lambda 커넥터로 S3 밖 데이터 를 SQL 로 조인.

지원 커넥터:
- RDS (MySQL, PostgreSQL)
- Redshift
- DynamoDB
- DocumentDB
- Elasticsearch
- CloudWatch Logs / Metrics
- HBase
- Custom (Lambda 로 직접 개발)

-- 사전에 데이터 소스 등록 (커넥터 Lambda + IAM)
SELECT r.customer_name, SUM(a.amount) AS total
FROM rds_mysql.public.customers r
JOIN s3_lake.public.orders a ON r.customer_id = a.customer_id
GROUP BY r.customer_name;

주의: 대량 데이터를 원격 소스에서 pull 하면 Lambda 요금 + 지연. 소규모 lookup 이나 dimension join 에 적합.

Query Result Reuse (2023+)

같은 쿼리를 24시간 이내 재실행 시 캐시된 결과 반환. 스캔 요금 없음.

정확히 같은 쿼리 텍스트여야 함 (whitespace, comment 제외)
Workgroup 이 같아야 함
24시간 이내 (default, MaxAgeInMinutes 설정 가능)

Prepared Statements & Views

-- Prepared
PREPARE q1 FROM
  SELECT * FROM orders WHERE user_id = ? AND status = ?;

EXECUTE q1 USING 123, 'paid';

-- View (Athena native)
CREATE OR REPLACE VIEW top_customers AS
SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 10000;

Athena for Apache Spark

Spark notebook 을 서버리스로. Trino SQL 로 안 되는 분석/ML feature engineering 에.

Spark 3.5, Python
세션 idle 20분 기본
Iceberg / Hudi / Delta 지원
DPU 기반 ($0.35 / DPU-hour)

노트북 첫 셀에서 세션 자동 생성. 커스텀 Spark 설정 가능.

[[aws-athena|Athena]] vs [[aws-redshift-spectrum|Redshift Spectrum]] vs [[aws-redshift|Redshift]]

축	Athena	Redshift Spectrum	Redshift (RA3/Serverless)
엔진	Trino	Redshift 자체	Redshift 자체
데이터 위치	S3 만	S3 + RMS 조인	RMS 내부
사전 클러스터	불필요	필요 (Redshift 클러스터)	필요
요금	$5/TB 스캔	$5/TB Spectrum + Redshift 컴퓨트	Redshift 컴퓨트
동시 사용자	사실상 무제한	클러스터 한도 (concurrency scaling)	클러스터 한도
JOIN 성능	중간	우수 (RA3 노드에서)	최고
ETL	CTAS 지원	제한 (external table read 위주)	COPY, MERGE 등
적합	Ad-hoc, BI, ETL lite	Redshift 를 이미 씀 + S3 조인	무거운 배치, warehouse

사용 예제

데이터 로딩 없이 로그 분석

-- ALB 로그 (S3 에 이미 있음)
CREATE EXTERNAL TABLE alb_logs (
  type STRING, time STRING, elb STRING,
  client_ip STRING, target_ip STRING, request_processing_time DOUBLE,
  ...
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES ('serialization.format' = '1', 'input.regex' = '...')
LOCATION 's3://my-alb-logs/AWSLogs/123/elasticloadbalancing/us-east-1/2026/07/';

-- 지난 시간 5xx 오류 top 10 client
SELECT client_ip, COUNT(*) AS n
FROM alb_logs
WHERE elb_status_code LIKE '5%'
  AND time >= '2026-07-30T14:00:00Z'
GROUP BY client_ip
ORDER BY n DESC LIMIT 10;

S3 Access Log 를 QuickSight 대시보드로

S3 Access Log → S3 → Glue Crawler → Glue Catalog
                                  ↓
                              Athena Table
                                  ↓
                            QuickSight 대시보드

함정

[!WARNING] SELECT * on CSV = 스캔량 폭탄. 컬럼 프로젝션 (필요한 컬럼만) + Parquet 로 변환.

[!CAUTION] 파티션 없는 테이블 = 매 쿼리 전체 데이터 스캔. 데이터 레이크에 처음 붓기 전에 파티션 설계 필수.

[!WARNING] 파티션 프루닝 안 됨 = WHERE UPPER(year) = '2026' 같은 함수 적용은 파티션 프루닝 실패. WHERE year = 2026 그대로.

[!IMPORTANT] 작은 파일 수천 개 = Athena 성능 붕괴 + 요청 오버헤드. CTAS 로 큰 파일로 합침, Iceberg auto-compact.

[!CAUTION] Workgroup 한도 미설정 = 실수 SELECT * 로 수십 TB 스캔 후 요금 청구. 반드시 per-query / per-workgroup 한도.

[!WARNING] 10 MB 최소 청구 = 매우 작은 쿼리가 많은 워크로드는 오히려 비쌈. Batch aggregation 고려.

[!IMPORTANT] Federated Query 를 반복 대량 처리에 사용 = Lambda 요금 폭탄 + 지연. Materialize 후 로컬 조인.

[!CAUTION] Iceberg 를 Lake Formation 으로 등록 = DDL 제한. Athena 에서 UPDATE/DELETE 안 되는 경우 있음. 등록 방식 사전 검토.

[!WARNING] Query Result Reuse 를 데이터 신선도 필요한 쿼리에 = 최대 24시간 stale. NoReuse 설정.

[AWS] CloudFront: CDN, origin, behavior, signed URL

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

CloudFront 는 AWS 의 글로벌 CDN (Content Delivery Network). 전 세계 600+ PoP (Points of Presence) + 13 Regional Edge Cache 를 통해 사용자에게 가장 가까운 edge 에서 콘텐츠 제공. 지연 감소, origin 부하 감소, DDoS 완화가 목적.

CloudFront 는 어떻게 동작하는가 (원리)

1. 글로벌 네트워크 계층

CloudFront 는 3계층 캐시 구조 + AWS 백본 네트워크 로 동작:

flowchart LR
    Client["사용자<br/>(서울)"]

    subgraph Tier1["1차 캐시 (PoP)"]
        Edge1["Edge Location<br/>ICN61 (서울)"]
    end

    subgraph Tier2["2차 캐시 (Regional)"]
        REC["Regional Edge Cache<br/>(도쿄)"]
    end

    subgraph Tier3["3차 캐시 (선택)"]
        Shield["Origin Shield<br/>(us-east-1)"]
    end

    Origin["Origin<br/>(S3 / ALB / Custom)"]

    Client -->|"1. DNS: cf-xxx.cloudfront.net<br/>(anycast IP)"| Edge1
    Edge1 -->|"MISS"| REC
    REC -->|"MISS"| Shield
    Shield -->|"MISS"| Origin

    Origin -.->|"응답"| Shield
    Shield -.-> REC
    REC -.-> Edge1
    Edge1 -.-> Client

계층	위치	역할	개수
Edge Location (PoP)	600+ 도시	사용자와 가장 가까움, 첫 캐시	매우 많음 (콘텐츠 소량)
Regional Edge Cache	13 리전	PoP 미스 시 상위 캐시, 콘텐츠 대량	큰 캐시
Origin Shield	특정 리전 (선택)	최상위 통합 캐시, origin 요청 정리	사용자 지정
Origin	S3/ALB/EC2/Custom	실제 데이터	1개 (또는 origin group)

2. DNS 기반 라우팅 (Anycast)

사용자가 d111.cloudfront.net 을 조회하면:

[[aws-route53|Route 53]] (또는 사용자 DNS) 이 CloudFront 의 anycast IP 반환
BGP anycast: 같은 IP 를 전 세계 모든 PoP 이 광고 -> ISP 는 가장 가까운 PoP 으로 라우팅
Latency-based / Geo-based 조합: 정확한 지연 측정 결과와 지리적 위치를 함께 사용

Global Accelerator 와 차이: [[aws-global-accelerator|Global Accelerator]] 는 anycast IP 2개를 사용자에게 제공 (정적 IP 필요 시), CloudFront 는 도메인 기반 라우팅 + HTTP/HTTPS 콘텐츠 캐싱에 특화.

3. TCP + TLS 종단 (Termination at Edge)

핵심 성능 이점: TCP handshake + TLS handshake 가 사용자와 가장 가까운 edge 에서 완료.

사용자 (서울) -> ICN61 PoP (서울): TCP + TLS handshake (~5-10 ms RTT)
ICN61 PoP -> Origin (us-east-1): AWS 백본 (지속 연결, keep-alive)

일반 인터넷 대비 handshake 지연 100 ms+ 절감 가능
Origin 연결은 persistent connection 재사용
HTTP/2, HTTP/3 (QUIC) 지원 -> multiplexing, 0-RTT resumption

4. AWS Global Backbone 활용

Edge -> Origin 구간은 인터넷이 아닌 AWS 사설 백본 을 타고 감. BGP flap / peering 문제 없음.

Global backbone: 100+ Tbps 용량
여러 대륙 간 전용 광케이블
원본이 [[aws-s3|S3]] / ALB 인 경우 데이터 전송 완전 내부 (인터넷 hop 0)

5. Cache 계층 (Cache Tier Hierarchy)

세 레벨 조회 순서 (miss 시 상위로):

1) Edge (PoP) 캐시 확인       → HIT: 즉시 응답 (~10 ms)
2) MISS → Regional Edge Cache 조회
3) MISS → Origin Shield 조회 (활성화 시)
4) MISS → Origin fetch → 각 계층에 캐싱

왜 계층 캐시가 유리한가:

PoP 이 600+ 개 -> 각 PoP 은 콘텐츠의 일부만 캐시 (용량 제한)
인기 콘텐츠는 PoP 에서 처리
롱테일 콘텐츠는 Regional Edge Cache 에서 흡수 (Origin 요청 감소)

6. Origin Shield (선택 최상위 캐시)

Origin Shield 는 사용자가 지정하는 하나의 리전 을 최상위 통합 캐시로 사용.

flowchart TB
    subgraph NoShield["Origin Shield 없음"]
        REC1["Regional 도쿄"] --> Origin1["Origin"]
        REC2["Regional 프랑크푸르트"] --> Origin1
        REC3["Regional 상파울루"] --> Origin1
        Note1["여러 REC 이 origin 을 동시에 fetch<br/>= origin 부하 증가"]
    end

    subgraph WithShield["Origin Shield 있음"]
        REC4["Regional 도쿄"] --> Shield["Origin Shield<br/>(us-east-1)"]
        REC5["Regional 프랑크푸르트"] --> Shield
        REC6["Regional 상파울루"] --> Shield
        Shield --> Origin2["Origin"]
        Note2["단 하나의 Origin Shield 가 origin fetch<br/>= 통합, 중복 제거"]
    end

이점:

Origin 부하 감소 (같은 콘텐츠를 여러 REC 이 각자 fetch 하는 문제 해결)
Cache hit rate 상승 (전역 통합)
Custom origin (온프레미스) 의 대역폭 절감

과금: Origin Shield 요청 수 × 요금 (data-out 은 origin 요금과 통합).

언제 켜나:

Origin 이 다중 리전에서 동시에 요청받아 부담될 때
Origin 이 온프레미스 / 자체 서버
Cache hit rate 를 최대화 (인기 콘텐츠가 여러 지역에 균등 분포)

7. 요청 흐름 (완전판)

sequenceDiagram
    participant U as 사용자 (서울)
    participant DNS as Route 53
    participant Edge as ICN61 PoP
    participant REC as 도쿄 Regional Edge
    participant Shield as Origin Shield (us-east-1)
    participant Origin as Origin (S3 us-east-1)

    U->>DNS: d111.cloudfront.net?
    DNS-->>U: anycast IP (서울 근처)
    U->>Edge: TCP + TLS handshake
    U->>Edge: GET /image.jpg

    alt Edge HIT
        Edge-->>U: 응답 (~10 ms)
    else Edge MISS
        Edge->>REC: 상위 fetch
        alt REC HIT
            REC-->>Edge: 응답
            Edge-->>U: 응답
        else REC MISS
            REC->>Shield: 상위 fetch
            alt Shield HIT
                Shield-->>REC: 응답
                REC-->>Edge: 응답
                Edge-->>U: 응답
            else Shield MISS
                Shield->>Origin: fetch (AWS 백본)
                Origin-->>Shield: 응답 + Cache-Control
                Shield-->>REC: 응답 + 캐싱
                REC-->>Edge: 응답 + 캐싱
                Edge-->>U: 응답 + 캐싱
            end
        end
    end

왜 이 아키텍처인가 (설계 결정)

PoP 다수 + 각 PoP 소형 캐시 = 사용자 근접 + 낮은 저장 비용
REC 소수 + 큰 캐시 = 롱테일 흡수 + PoP 부하 완화
Origin Shield 선택형 = 필요할 때만 (비용/hit rate 트레이드오프)
AWS 백본 활용 = 인터넷 라우팅 변동성 회피
Anycast IP = 사용자에게 단일 도메인, 내부적으로 최적 PoP 자동 선택

동작 흐름

sequenceDiagram
    participant Client as 사용자 (서울)
    participant Edge as "CloudFront Edge\n(서울 PoP)"
    participant Regional as "Regional Edge Cache\n(도쿄)"
    participant Origin as "Origin (S3 / ALB)"

    Client->>Edge: GET /image.jpg
    alt cache HIT
        Edge-->>Client: 즉시 응답 (< 10ms)
    else cache MISS
        Edge->>Regional: 상위 캐시 조회
        alt regional HIT
            Regional-->>Edge: 캐시 응답
            Edge-->>Client: 응답 + 캐싱
        else regional MISS
            Regional->>Origin: origin fetch
            Origin-->>Regional: 응답
            Regional-->>Edge: 전달 + 캐싱
            Edge-->>Client: 응답
        end
    end

Origin 종류

Origin	사용 사례
S3	정적 파일, 이미지, SPA
ALB / NLB	동적 API, 웹 앱
Custom HTTP (any)	외부 자체 서버
Lambda Function URL	서버리스 API
MediaPackage	라이브/VOD 스트리밍
API Gateway	REST / WebSocket API

Cache Behavior

요청 경로 패턴별로 다른 origin + 캐시 정책 적용.

flowchart LR
    Req["요청 URL"] --> Behavior["Cache Behavior\n(패턴 매칭)"]
    Behavior -->|"/static/*"| BehA["S3 origin\nCache-Control: 1일"]
    Behavior -->|"/api/*"| BehB["ALB origin\nno-cache, no-store"]
    Behavior -->|"* (default)"| BehC["S3 origin\nCache-Control: 1시간"]

매칭 우선순위: 더 구체적인 패턴이 먼저. /api/v2/* 가 /api/* 보다 먼저 평가.

Cache Key 설계

CachePolicy:
  HeadersConfig:
    HeaderBehavior: whitelist
    Headers: [Accept-Encoding, Accept-Language]
  CookiesConfig:
    CookieBehavior: whitelist
    Cookies: [session-id]
  QueryStringsConfig:
    QueryStringBehavior: whitelist
    QueryStrings: [version, locale]

cache key 에 포함되는 항목이 많을수록 cache hit rate 떨어짐. 최소한의 key 로 유지.

Origin Request Policy 와 분리: cache key 에는 없지만 origin 에 전달할 header/cookie/query 를 별도 정의 가능.

OAC (Origin Access Control)

S3 origin 의 직접 접근 차단 + CloudFront 만 허용.

# S3 Bucket Policy
Statement:
  - Effect: Allow
    Principal:
      Service: cloudfront.amazonaws.com
    Action: s3:GetObject
    Resource: arn:aws:s3:::my-bucket/*
    Condition:
      StringEquals:
        AWS:SourceArn: arn:aws:cloudfront::123456789:distribution/EXXX

옛 OAI (Origin Access Identity) 의 후계 (2022+)
OAC 는 SSE-KMS 암호화 S3 도 지원
S3 퍼블릭 차단 설정 유지 상태에서 CloudFront 만 접근

보호된 콘텐츠에 임시 접근 URL 생성.

# CLI 로 signed URL 생성
aws cloudfront sign \
  --url https://d111.cloudfront.net/private/video.mp4 \
  --key-pair-id K1234567890 \
  --private-key file://cloudfront-private-key.pem \
  --date-less-than 2026-12-31T23:59:59Z

# Boto3 Python
from botocore.signers import CloudFrontSigner
import rsa

def rsa_signer(message):
    with open('private_key.pem', 'rb') as f:
        private_key = rsa.PrivateKey.load_pkcs1(f.read())
    return rsa.sign(message, private_key, 'SHA-1')

signer = CloudFrontSigner(key_id, rsa_signer)
url = signer.generate_presigned_url(
    'https://d111.cloudfront.net/private/doc.pdf',
    date_less_than=datetime(2026, 12, 31)
)

Signed URL vs Signed Cookie:

Signed URL: 파일 단건. 다운로드 링크, 동영상 단건
Signed Cookie: 여러 파일. 구독 콘텐츠, 멤버십 전체 섹션

Edge Compute

CloudFront 에서 코드 실행. 두 가지 옵션.

항목	CloudFront Functions	Lambda@Edge
Runtime	JS (ES 2019)	Node.js, Python
실행 위치	edge PoP (가장 빠름)	Regional edge cache
Cold start	없음	있음 (드물게)
실행 시간 한도	1ms	viewer: 5s / origin: 30s
메모리	2MB	128MB-10GB
가격	$0.1/100만	Lambda 가격
네트워크 접근	불가	가능
사용 사례	header 조작, redirect, A/B	인증, 이미지 변환, 복잡 로직

// CloudFront Functions: URL 정규화 예시
async function handler(event) {
    const request = event.request;
    // /blog/post/ -> /blog/post/index.html
    if (request.uri.endsWith('/')) {
        request.uri += 'index.html';
    }
    return request;
}

# Lambda@Edge: JWT 인증 (origin request)
import jwt

def handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request.get('headers', {})
    auth = headers.get('authorization', [{}])[0].get('value', '')
    try:
        token = auth.replace('Bearer ', '')
        jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        return request  # 통과
    except Exception:
        return {'status': '401', 'body': 'Unauthorized'}

TLS / 인증서

AWS Certificate Manager (ACM) 무료 인증서 사용
반드시 us-east-1 (N. Virginia) 에서 발급 (CloudFront 가 글로벌 서비스이므로)
SNI (Server Name Indication) 기본 활성. 전용 IP 옵션 ($600/월) 은 레거시 클라이언트 지원 시만

# 서울에서 발급한 인증서는 CloudFront 에 사용 불가
# us-east-1 에서 발급 필수
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names *.example.com \
  --validation-method DNS \
  --region us-east-1

캐시 무효화 (Invalidation)

배포 후 캐시 즉시 갱신.

# 특정 경로 무효화
aws cloudfront create-invalidation \
  --distribution-id EXXX \
  --paths /index.html /app.js

# 전체 무효화
aws cloudfront create-invalidation \
  --distribution-id EXXX \
  --paths "/*"

비용: 첫 1000 path/월 무료, 이후 $0.005/path. 와일드카드 /* 는 1 path 로 계산.

CI/CD 배포마다 /* 무효화는 비효율적. 파일명에 hash 포함 (app.abc123.js) 후 영구 캐시 권장.

비용 구조

항목	요금 (서울 리전)
데이터 전송 (아웃바운드)	$0.114/GB (첫 10TB)
HTTP 요청	$0.0075/10만
HTTPS 요청	$0.01/10만
무효화	1000 path/월 무료 후 $0.005/path
Lambda@Edge	Lambda 요금 + 리전 추가 비용

비용 최적화:

S3 origin 은 CloudFront 통해 내보낼 때 무료 (S3 → CloudFront 데이터 전송 무료)
cache hit rate 높이면 origin 트래픽 + 비용 감소
Price Class 로 서비스 지역 제한 (US/EU 만 = 저렴)

CloudFront + WAF 조합

flowchart LR
    Internet["인터넷 트래픽"] --> WAF["AWS WAF\n(규칙 필터)"]
    WAF -->|"허용"| CF["CloudFront"]
    WAF -->|"차단"| Block["403 / 200 with error"]
    CF --> Origin["Origin"]

WAF 규칙: IP 차단, geo 제한, rate limiting, OWASP 관리형 규칙, bot 탐지.

CloudFront distribution 단위로 WAF WebACL 연결 (us-east-1 에서 생성한 WebACL).

흔한 함정

[!WARNING]

Origin 의 Cache-Control 헤더 누락: CloudFront 가 캐싱 안 함. Origin 에서 Cache-Control: max-age=... 명시 필수.

S3 origin 퍼블릭 오픈: CloudFront 우회 가능. OAC 필수, S3 버킷 퍼블릭 차단 유지.

TLS cert wrong region: us-east-1 이 아닌 리전의 ACM cert 는 CloudFront 에서 사용 불가.

무효화 남용: /* 매 배포마다 실행 = 비용 + hit rate 0. hash 파일명으로 대체.

Lambda@Edge 디버깅 어려움: 전 세계 리전에서 실행. CloudWatch Logs 가 실행 리전에 분산.

[!CAUTION] Lambda@Edge 는 CDK/CloudFormation 배포 후 edge 전파까지 수 분 소요. 배포 직후 즉시 반영 아님.

[!IMPORTANT] CloudFront distribution 삭제 전 비활성화 필수. 비활성화 후 삭제까지 15분 이상 소요.

[AWS] CloudHSM: 단일 테넌트 하드웨어 보안 모듈

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS CloudHSM 은 AWS VPC 안에서 실행되는 단일 테넌트 (single-tenant) 하드웨어 보안 모듈 (HSM). 물리 하드웨어에 격리된 HSM 을 고객 전용으로 프로비저닝하고, 고객이 사용자 / 키 / 백업을 완전히 통제. AWS 는 하드웨어 유지와 네트워크 가용성만 담당하며 키에는 접근할 수 없다.

한 줄 요약: AWS 관리 편의 (프로비저닝, HA) + “AWS 도 못 보는 키” 를 원하는 규제/보안 요구 의 결합.

HSM 이란

HSM (Hardware Security Module) = 암호화 키를 안전하게 생성 / 저장 / 사용하기 위한 전용 하드웨어.

특징:

키는 HSM 밖으로 나오지 않음 (사용은 HSM 안에서, 결과만 반환)
물리적 tamper 대응: 봉인 파괴 감지 시 키 자동 삭제
표준 인터페이스 (PKCS#11, JCE, CNG/KSP) 로 애플리케이션 통합
FIPS / Common Criteria 등 인증 획득

일반 서버의 소프트웨어 키 저장은 root 나 exploit 으로 유출 가능. HSM 은 물리 격리로 이를 원천 차단.

왜 CloudHSM 인가

KMS 와의 대비

[[aws-kms|AWS KMS]] 도 HSM 백엔드를 쓴다. 그러면 왜 CloudHSM 이 별도 필요한가?

축	[[aws-kms\|KMS]]	CloudHSM
테넌시	Multi-tenant (여러 고객이 같은 HSM 풀)	Single-tenant (고객 전용 HSM)
관리 주체	AWS 가 사실상 전부	고객이 사용자 / 키 / 백업
AWS 접근	AWS 가 관리 API 갖고 있음	AWS 는 접근 불가
표준 API	KMS API (AWS 전용)	PKCS#11, JCE, OpenSSL Dynamic Engine, CNG/KSP
알고리즘	AWS 가 지원하는 것만	HSM 이 지원하는 것 전부 (커스텀 포함)
FIPS 인증	FIPS 140-2 Level 2 (HSM 백엔드는 L3)	FIPS 140-2 Level 3
비용 모델	키당 + 요청당	HSM 시간당
AWS 서비스 통합	대부분 자동 (S3, EBS, RDS, …)	통합 제한 (KMS Custom Key Store 통해 우회)
적합	대부분의 앱 암호화	규제 / 커스텀 crypto / PKI CA

결정 규칙:

대부분: [[aws-kms|KMS]] 로 충분
금융 결제 / 정부 기밀 / PKI CA / “AWS 도 못 봐야” 요구: CloudHSM

대표 사용처

금융 서비스: PIN 처리, EMV 결제, HSM 기반 거래 서명
정부 / 방위: 분류된 데이터, 규제 준수 (FedRAMP High)
PKI Certificate Authority: 루트 / 중간 CA 개인 키 보관, 인증서 서명
디지털 서명: 계약서 서명, 문서 인증
DRM / 저작권: 콘텐츠 암호화 키
커스텀 암호 알고리즘: KMS 미지원 알고리즘 (예: 일부 국내 표준)

아키텍처

flowchart LR
    subgraph AWS["고객 AWS 계정"]
        subgraph VPC["고객 VPC"]
            App["애플리케이션<br/>(CloudHSM 클라이언트)"]

            subgraph AZ1["AZ 1"]
                ENI1["ENI"]
            end
            subgraph AZ2["AZ 2"]
                ENI2["ENI"]
            end
            subgraph AZ3["AZ 3"]
                ENI3["ENI"]
            end
        end
    end

    subgraph AWSVPC["AWS 관리 VPC (숨김)"]
        subgraph Cluster["CloudHSM Cluster"]
            HSM1["HSM 1 (AZ 1)"]
            HSM2["HSM 2 (AZ 2)"]
            HSM3["HSM 3 (AZ 3)"]
        end
    end

    App -->|"PKCS#11 / JCE / OpenSSL"| ENI1
    ENI1 <-.->|"AWS 사설 링크"| HSM1
    ENI2 <-.-> HSM2
    ENI3 <-.-> HSM3

    HSM1 <-.->|"자동 동기화<br/>키 복제"| HSM2
    HSM2 <-.-> HSM3

구성 요소

Cluster: 여러 HSM 의 논리 그룹. 각 HSM 이 다른 AZ 에 위치 → HA
HSM: 개별 물리 HSM (전용 하드웨어). 요청 부하 분산 대상
ENI (Elastic Network Interface): 고객 VPC 서브넷에 생성. 클라이언트가 이 ENI 로 HSM 과 통신 (자세히: [[aws-eni|ENI]])
클라이언트 SDK: EC2 나 On-prem 서버에 설치. HSM API 호출 처리

HA (고가용성)

Cluster 안 여러 HSM 이 자동으로 키를 동기화
클라이언트가 자동 로드 밸런싱
한 HSM 이 죽어도 다른 HSM 이 서비스 지속
실무 권장: 최소 2 AZ, 2 HSM 이상 (단일 HSM 은 프로덕션 금지)

표준 인터페이스

CloudHSM 이 지원하는 crypto API:

인터페이스	언어/환경	대표 사용
PKCS#11	C / Python / Go / etc	범용 표준, OpenSSL, PKI 도구
JCE (Java Cryptography Extension)	Java	Java 앱, Bouncy Castle
OpenSSL Dynamic Engine	OpenSSL 기반 어떤 도구든	Nginx / Apache TLS 종단, PKI
CNG / KSP	Windows	ADCS, Windows PKI

의미: 애플리케이션은 기존 표준 API 를 그대로 쓰고, 백엔드만 CloudHSM 을 가리키게 설정하면 됨. 코드 재작성 대부분 불필요.

KMS Custom Key Store 통합

CloudHSM 을 직접 안 쓰고 KMS 를 통해 CloudHSM 을 백엔드로 사용 하는 옵션.

flowchart LR
    App[애플리케이션] --> KMS[AWS KMS API]
    KMS --> CKS["Custom Key Store<br/>(고객 CloudHSM Cluster)"]
    CKS --> HSM[CloudHSM]

    S3["S3 SSE-KMS"] --> KMS
    EBS["EBS 암호화"] --> KMS
    RDS["RDS 암호화"] --> KMS

이점:

KMS 의 편의성 (S3/EBS/RDS 자동 통합) + CloudHSM 의 통제
애플리케이션은 KMS API 로 개발 → 이식성
KMS 감사 (CloudTrail) 유지

단점:

KMS 요금 + CloudHSM 요금 둘 다
지연 (KMS → CloudHSM 왕복)

언제 유리: KMS 편의성은 원하되 규제로 인해 키가 고객 통제 하에 있어야 할 때.

AWS 서비스 통합

CloudHSM 을 직접 지원 (별도 통합) 하는 서비스:

[[aws-redshift|Redshift]]: 클러스터 암호화 키를 CloudHSM 에 저장
RDS Oracle TDE: Transparent Data Encryption
ACM Private CA: PKI 인증서 발급 (루트 CA 키를 CloudHSM 에)
NGINX / Apache: OpenSSL 통해 TLS 개인 키 관리

그 외 대부분은 KMS Custom Key Store 를 경유.

FIPS 140-2 Level 3

CloudHSM 이 인증 받은 표준. 물리 보안의 국제 표준.

Level	특징
Level 1	SW 기반 crypto
Level 2	SW + 물리 tamper 증거 (봉인 seal)
Level 3	물리 tamper 대응 (봉인 파괴 시 키 자동 삭제) + role-based auth
Level 4	최상위 (환경 공격 대응)

Level 3 는 대부분의 금융 / 정부 규제가 요구하는 수준. CloudHSM 의 이 인증이 KMS 대신 CloudHSM 을 선택하는 주된 이유.

사용자 관리

CloudHSM 의 특별한 점: AWS 계정의 IAM 이 아니라, HSM 자체의 사용자 시스템.

HSM 사용자 역할:

Precrypto Officer (PRECO): 초기화 시 임시 관리자
Crypto Officer (CO): 사용자 관리, 클러스터 설정
Crypto User (CU): 실제 crypto 연산 (key 생성/사용/삭제)
Appliance User (AU): 관리 목적

CloudHSM 클러스터 활성화 시 CO 를 지정하고, 이후 애플리케이션 별로 CU 를 생성. AWS 는 이 사용자 데이터베이스에 접근 불가.

백업

자동 백업: 클러스터 상태 변경 시 (사용자/키 추가 등)
암호화된 백업: AWS 관리 KMS 키로 봉인
저장 위치: 클러스터와 같은 리전 S3 (고객 소유 아님)
복원: 새 클러스터 생성 시 백업에서 복원 가능

중요: 백업조차도 AWS 가 열 수 없음. 클러스터의 CO 자격 증명이 없으면 아무도 복원 불가.

요금

HSM 시간당 (~$1.60 - $2 USD / HSM-hour, 리전별 상이)
Cluster 는 HSM 개수 x 시간
스토리지 / 백업 무료 (기본)
데이터 전송 표준

계산 예시:

HA 최소 (2 HSM × 24 × 30) × $1.60 = ~$2,304 /월

3 HSM (3 AZ HA) × 24 × 30 × $1.60 = ~$3,456 /월

KMS 는 키당 $1/월 + 요청당 소액이라 대부분 훨씬 저렴. CloudHSM 은 규제 / 통제가 필수인 워크로드에만.

운영 책임

항목	AWS	고객
하드웨어 유지	O	X
네트워크 가용성	O	X
Cluster 프로비저닝	O	X
사용자 관리 (CO / CU)	X	O
키 생성 / 로테이션	X	O
백업 관리	X	O (자동 백업이지만 복원은 고객)
클라이언트 통합	X	O
모니터링 (실패, 성능)	부분	O

핵심: AWS 가 하드웨어를 대신 운영해주지만, 키와 사용자의 책임은 완전히 고객. 이걸 KMS 와 혼동하면 안 됨 (KMS 는 대부분 AWS 가 함).

관측 & 감사

CloudTrail: CloudHSM API 호출 (클러스터 관리) 기록
CloudWatch: HSM 상태 지표 (healthy 개수, 사용률)
HSM 자체 audit log: crypto 연산 이력 (선택적 syslog 전송)

함정

[!WARNING] 단일 HSM = 프로덕션 금지. HSM 이나 AZ 장애 시 서비스 중단. 최소 2 AZ, 2 HSM.

[!CAUTION] CO / CU 자격증명 분실 = 클러스터 복구 불가. AWS 도 도와줄 수 없음. 자격증명은 여러 명 / 여러 저장소에 안전 백업 (예: 안전 금고).

[!WARNING] KMS 대신 CloudHSM 을 대부분 워크로드에 = 요금 폭탄 + 운영 부담. 규제/통제 요구가 없으면 KMS 부터.

[!IMPORTANT] AWS 는 키에 접근 불가. 좋은 점이자 나쁜 점. 관리자 실수로 잘못된 키를 지우면 복구 불가. 백업 정책 필수.

[!CAUTION] AWS 서비스 통합 제한. S3 SSE-KMS 같은 자동 통합을 원하면 KMS Custom Key Store 로 우회 (양쪽 요금 다 발생).

[!WARNING] CloudHSM 클라이언트 SDK 관리. EC2 / On-prem 에 설치되는 클라이언트가 있음. 버전 업그레이드, TLS 갱신 등 관리 필요.

[!IMPORTANT] hsm1.medium 은 end-of-support 로 마이그레이션 대상. 신규는 hsm2m.medium (또는 최신).

[AWS] Data Firehose: 서버리스 스트림 적재

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Data Firehose (구 Kinesis Data Firehose, 2024-02 이름 변경) 는 스트리밍 데이터를 받아 S3/Redshift/OpenSearch/Splunk 등으로 자동 적재 하는 완전 서버리스 서비스. 저장하지 않고 전달 (delivery) 만.

한 줄 감각: 스트림을 목적지까지 배달하는 트럭. 코드 작성 없이 인프라 관리 없이 적재.

왜 Firehose 인가

로그를 [[aws-s3|S3]] 에 넣는 흔한 요구를 예로 들면:

Firehose 없이:

Kinesis / Kafka 컨슈머 코드 작성
버퍼링, 배치, 재시도, 오류 처리 직접 구현
인스턴스/컨테이너 운영
파티션 폴더 구조 관리

Firehose 로:

콘솔에서 delivery stream 생성 (5분)
목적지: S3 버킷 지정
그 뒤로 유지 관리 0

KDS vs Firehose

축	[[aws-kinesis-data-streams\|Kinesis Data Streams]]	Amazon Data Firehose
역할	수집/저장 스트림	전달 (적재) 서비스
관리	샤드 (Provisioned) or On-demand	완전 서버리스
지연	실시간 (~200 ms, EFO ~70 ms)	준실시간 (버퍼 최소 60초, Zero Buffering ~5초)
저장 / 보존	O (24h ~ 365일)	X (저장 X)
재처리 (Replay)	가능	불가
다중 소비자	여러 독립 소비자	목적지로만 전달
소비자 구현	직접 코딩	코딩 불필요
순서 보장	샤드 내 O	보장 X
데이터 변환	직접 구현	Lambda 인라인 내장
목적지	사용자 정의	정해진 세트
레코드 크기	최대 1 MiB	최대 1 MiB
과금	샤드 시간 + 데이터량	수집/전달 데이터량

데이터 흐름

sequenceDiagram
    participant P as Producer
    participant F as Firehose Delivery Stream
    participant L as Lambda (선택, 변환)
    participant D as Destination (S3/Redshift/...)

    P->>F: PutRecord / PutRecordBatch
    Note over F: 버퍼링 (시간 60s or 크기 5MB)

    alt Lambda 변환
        F->>L: 버퍼 배치 전달
        L-->>F: 변환된 배치 (CSV→JSON, 필터, 마스킹)
    end

    F->>D: 배치 flush (Parquet 변환, 압축, 파티션)
    D-->>F: OK

    Note over F: 실패 시 지수 백오프 재시도<br/>결국 실패하면 S3 backup 버킷으로

목적지 (Destinations)

목적지	특징
[[aws-s3\|Amazon S3]]	가장 흔함. Parquet/ORC 변환 + 파티션 자동
[[aws-redshift\|Amazon Redshift]]	S3 경유 후 COPY 자동
Amazon OpenSearch Service	로그 분석 인덱스
Splunk	엔터프라이즈 로그
Apache Iceberg on S3 (2024+)	Lakehouse 직접 적재
HTTP 엔드포인트	Datadog, New Relic, MongoDB Atlas 등 파트너
Snowflake	직접 통합 (2024+)

소스 (Sources)

소스	특징
Direct PUT	애플리케이션이 SDK 로 직접
[[aws-kinesis-data-streams\|Kinesis Data Streams]]	KDS 를 소스로 (구독)
Amazon MSK	Kafka 를 소스로 (2023+)
CloudWatch Logs subscription filter	로그 -> Firehose
IoT Rules	IoT 데이터

버퍼링 (Buffering)

Firehose 는 배치로 flush -> 준실시간.

두 조건 중 먼저 도달:

시간: 60초 ~ 900초 (기본 300)
크기: 1 MB ~ 128 MB (기본 5)

Zero Buffering (2023+):

시간 0초 설정 시 사실상 실시간 (~5초)
OpenSearch/Splunk 목적지에서 유용

데이터 변환 (Transformation)

Lambda 인라인 변환

def lambda_handler(event, context):
    output = []
    for record in event['records']:
        raw = base64.b64decode(record['data']).decode('utf-8')
        # CSV -> JSON, 필드 추가, PII 마스킹 등
        transformed = transform(raw)
        output.append({
            'recordId': record['recordId'],
            'result': 'Ok',
            'data': base64.b64encode(transformed.encode()).decode()
        })
    return {'records': output}

결과 상태:

Ok - 변환 성공, 목적지로
Dropped - 필터링됨 (조용히 버림)
ProcessingFailed - 오류, S3 backup 으로

포맷 변환 (Format Conversion)

S3 목적지 한정. JSON -> [[apache-parquet|Parquet]] 또는 ORC 자동 변환.

입력: {"user_id": 1, "event": "click", "ts": "2026-07-30"}
      ↓ Parquet 변환 + SNAPPY 압축
S3: my-lake/events/year=2026/month=07/day=30/hour=15/xxx.parquet

필수 조건:

[[aws-glue|Glue Catalog]] 에 스키마 등록
소스 데이터가 JSON

압축: GZIP / SNAPPY / ZSTD 등.

Iceberg 목적지 (2024+)

Apache Iceberg 테이블에 직접 적재 (INSERT / UPDATE / DELETE 지원).

DestinationConfiguration:
  IcebergDestinationConfiguration:
    CatalogConfiguration:
      CatalogARN: arn:aws:glue:...:catalog
    S3Configuration:
      RoleARN: ...
      BucketARN: arn:aws:s3:::my-lake
    UniqueKeys: [order_id]      # Upsert 키
    OperationTypes: [INSERT, UPDATE, DELETE]

CDC 스트림을 Iceberg 로 그대로 반영. [[aws-athena|Athena]] / [[aws-emr|EMR]] 에서 즉시 쿼리.

파티션 (Dynamic Partitioning)

레코드 내용 기반으로 S3 파티션 자동 생성.

입력 record: {"customer_id": 42, "event_ts": "2026-07-30T15:00:00Z"}
파티션 표현식: !{partitionKeyFromQuery:customer_id}/!{partitionKeyFromLambda:date}
S3 결과: my-lake/customer_id=42/date=2026-07-30/xxx.parquet

partitionKeyFromQuery: JQ 로 필드 추출
partitionKeyFromLambda: Lambda 반환값
주의: 파티션 수 폭증 = small files

오류 처리 (Backup)

변환/전달 실패 -> S3 backup 버킷 (구성 필수)
소스 데이터도 백업 가능 (FailedDataOnly 또는 AllData)
재처리 시 backup 을 원본 소스처럼 사용

요금

수집 데이터: $0.029 / GB (초기), 이후 볼륨 할인
변환 (Format Conversion): 추가 $0.018 / GB
Lambda 변환: Lambda 요금 별도
Dynamic Partitioning: 추가 요금
VPC Delivery: 시간 + GB 추가

과금 단위: 5 KB 단위 반올림 (5 KB 미만 레코드도 5 KB 로 청구).

실전 예제

CloudWatch Logs -> S3 로그 레이크

[모든 Lambda 로그] -> CloudWatch Logs
   ↓ subscription filter
Firehose (delivery stream)
   ↓ Lambda 변환 (JSON 정제)
   ↓ Parquet 변환 + SNAPPY
S3 (year=/month=/day= 파티션)
   ↓
Athena SQL 로 분석

KDS + Firehose 결합

[생산자] -> Kinesis Data Streams -> ┬-> Lambda (실시간 alert)
                                    └-> Data Firehose -> S3 (자동 적재)

핵심: KDS 가 고속 수집 + 다중 소비자 + 재처리를 담당, Firehose 가 그 중 하나의 소비자로서 적재.

함정

[!WARNING] Firehose 는 저장하지 않는다. 재처리/다중 소비자 필요하면 [[aws-kinesis-data-streams|KDS]] 를 앞단에.

[!CAUTION] 밀리초 실시간 필요 = Firehose 부적합 (버퍼 지연). [[aws-kinesis-data-streams|KDS]] 소비자 직접 구현.

[!WARNING] 버퍼 크기 5 MB 유지 = S3 파일 수백만 개 (small files). 파일 크기 128 MB 근처로 조정, 또는 Athena CTAS / Iceberg auto-compact.

[!IMPORTANT] 5 KB 최소 청구 = 매우 작은 레코드 많으면 오히려 비쌈. 프로듀서에서 배치.

[!CAUTION] Dynamic Partitioning 남용 = 파티션 폭증 + 스몰 파일. 카디널리티 검증 필수.

[!WARNING] Lambda 변환 응답 시간 5분 초과 = 실패. 무거운 변환은 별도 파이프라인.

[!IMPORTANT] 이름 변경 (Kinesis Data Firehose → Amazon Data Firehose, 2024-02). API/SDK 는 하위 호환. 문서/블로그는 옛 이름 혼재.

[AWS] EC2: 인스턴스 타입, AMI, EBS

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

EC2 (Elastic Compute Cloud) = AWS 의 VM 서비스. instance type (CPU / RAM / NW) 결정 + AMI (OS 이미지) + EBS (스토리지).

사용 상황

상황	선택
웹 서버, 앱 서버	m/c family On-Demand
비용 절감 (예측 가능 트래픽)	Reserved / Savings Plans
배치, 비동기 처리, CI	Spot Instance
GPU 딥러닝 학습	p/g family
고메모리 DB 인스턴스	r/x family
로컬 NVMe 캐시 필요	i family
컨테이너 worker node	m/c Graviton + Spot

인스턴스 타입 명명

m6i.large
│ │ │
│ │ └── size (nano, micro, small, medium, large, xlarge, 2xlarge, ...)
│ └──── generation modifier (i=Intel, a=AMD, g=Graviton ARM, n=network, ...)
└────── family (m=general, c=compute, r=memory, x=extreme memory, p=GPU, ...)
        세대 (6 = 6세대)

Family	용도
`t`	burstable (가벼운 워크로드)
`m`	general purpose
`c`	compute optimized
`r`	memory optimized
`x`/`u`	high memory
`i`	storage optimized (NVMe)
`d`	dense HDD
`p`/`g`/`inf`/`trn`	GPU / AI accelerator

Graviton (ARM) vs Intel/AMD

	Intel (`m7i`)	AMD (`m7a`)	Graviton (`m7g`)
아키텍처	x86-64	x86-64	ARM64
가격 (vs Intel)	1.0x	~0.9x	~0.8x
성능 (workload)	기준	비슷	비슷 또는 우수
호환성	모든 OS	모든 OS	ARM 빌드 필요

[!IMPORTANT] 2026 시점 Graviton (ARM) 이 비용 효율 최강. 모든 새 워크로드는 ARM 호환 빌드부터.

Purchase Options

flowchart TB
    Q{사용 패턴}
    Q --> OD["On-Demand (기본 가격)"]
    Q --> Spot["Spot (최대 90% 할인, 중단 위험)"]
    Q --> Reserved["Reserved (1/3년 약정, 최대 72% 할인)"]
    Q --> SP["Savings Plans (약정 시간당 $, 유연)"]

옵션	할인	적합
On-Demand	0%	임시 / 테스트
Spot	60-90%	batch, stateless, K8s worker
Reserved Instances	40-72%	안정 워크로드
Savings Plans	25-72%	가장 유연
Dedicated Host	비쌈	컴플라이언스

Spot Instance

sequenceDiagram
    participant User
    participant AWS

    User->>AWS: Spot request
    AWS-->>User: "Spot instance (90% 할인)"
    Note over AWS: capacity 부족
    AWS->>User: 2분 중단 알림
    Note over User: graceful shutdown
    AWS->>User: instance reclaim

[!TIP] Karpenter / EKS managed node group 의 spot + on-demand 혼합이 2026 표준. 비용 60%+ 절감.

AMI (Amazon Machine Image)

aws ec2 describe-images --owners amazon --filters \
  "Name=name,Values=al2023-ami-*-x86_64" \
  "Name=state,Values=available"

옵션	의미
Amazon Linux 2023	AWS 최신
Ubuntu LTS	가장 흔함
Bottlerocket	container 전용 (EKS)
Custom AMI	Packer 로 빌드
Marketplace	RHEL, Windows, 3rd-party

User Data (부팅 스크립트)

#!/bin/bash
yum update -y
yum install -y nginx
systemctl enable --now nginx

EC2 부팅 시 1회 실행. cloud-init 기반.

Instance Metadata Service (IMDS)

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

[!CAUTION] IMDSv2 (token 필수) 가 SSRF 공격 방어. IMDSv1 비활성 강력 권장.

EBS Volume 타입

타입	용도	최대 IOPS	최대 처리량
`gp3`	범용 SSD (기본 권장)	16,000	1,000 MB/s
`gp2`	범용 SSD (구형)	16,000	250 MB/s
`io2 Block Express`	고성능 DB	256,000	4,000 MB/s
`io1`	고성능 (구형)	64,000	1,000 MB/s
`st1`	순차 처리량 HDD	500	500 MB/s
`sc1`	저비용 콜드 HDD	250	250 MB/s

# gp2 -> gp3 마이그레이션 (비용 20% 절감)
aws ec2 modify-volume \
  --volume-id vol-xxxx \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

gp3 는 IOPS/처리량을 독립적으로 설정. gp2 의 IOPS 연동 방식보다 유연하고 저렴.

Security Group

EC2 인바운드/아웃바운드 트래픽 제어. Stateful (응답 자동 허용).

# Security Group 생성
aws ec2 create-security-group \
  --group-name web-sg \
  --description "Web Server SG" \
  --vpc-id vpc-xxxx

# 규칙 추가
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxx \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# SG 간 참조 (내부 통신)
aws ec2 authorize-security-group-ingress \
  --group-id sg-db \
  --protocol tcp --port 5432 \
  --source-group sg-app   # IP 아닌 SG 참조

SG 간 참조는 IP 변경에 강건. 앱 SG → DB SG 패턴 필수.

Systems Manager Session Manager

SSH 포트 없이 인스턴스 접속. IAM 기반 접근 제어.

# SSM으로 접속 (22 포트 불필요)
aws ssm start-session --target i-xxxx

# 포트 포워딩 (로컬 DB 접근)
aws ssm start-session \
  --target i-xxxx \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["5432"],"localPortNumber":["15432"]}'

필요 IAM 권한:

{
  "Action": [
    "ssm:StartSession",
    "ssm:TerminateSession",
    "ec2:DescribeInstances"
  ],
  "Resource": "arn:aws:ec2:*:*:instance/*"
}

[!TIP] 배스천 호스트 제거 가능. CloudTrail + Session Manager 로그로 모든 접속 감사.

Placement Groups

타입	특성	사용
Cluster	같은 AZ, 낮은 latency	HPC, 분산 캐시
Spread	다른 하드웨어, HA	소수의 중요 인스턴스
Partition	파티션별 격리	Hadoop, Kafka, Cassandra

aws ec2 create-placement-group \
  --group-name hpc-cluster \
  --strategy cluster

aws ec2 run-instances \
  --placement '{"GroupName":"hpc-cluster"}' \
  ...

CloudWatch 모니터링

기본 메트릭 (5분 간격, 무료):

메트릭	의미
`CPUUtilization`	CPU 사용률
`NetworkIn`/`Out`	네트워크 트래픽
`DiskReadOps`/`WriteOps`	디스크 I/O
`StatusCheckFailed`	인스턴스/시스템 장애

상세 메트릭 (1분 간격, 유료):

aws ec2 monitor-instances --instance-ids i-xxxx

메모리/디스크 사용률은 CloudWatch Agent 설치 필요:

# Agent 설치 (Amazon Linux)
sudo yum install -y amazon-cloudwatch-agent
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

Auto Recovery

하드웨어 장애 시 자동 재시작 (같은 EIP, 동일 인스턴스 ID).

aws cloudwatch put-metric-alarm \
  --alarm-name ec2-auto-recover \
  --namespace AWS/EC2 \
  --metric-name StatusCheckFailed_System \
  --statistic Maximum --period 60 --evaluation-periods 2 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --threshold 1 \
  --alarm-actions arn:aws:automate:us-east-1:ec2:recover

흔한 함정

[!WARNING]

t family 의 CPU credit = burst 후 credit 소진 시 baseline 으로 떨어짐 → 느려짐. unlimited 모드 또는 다른 family.

Spot 의 갑작스런 중단 = stateful 워크로드 금지. checkpoint + retry.

AMI 가 오래됨 = 보안 패치 없음. 정기 AMI rebake + AMI ID 자동화.

EBS 만 보고 instance store 무시 = NVMe 의 극도로 빠른 임시 스토리지. 캐시 / shuffle 용.

gp2 를 아직 사용 = gp3 가 20% 저렴하고 더 유연. 모든 gp2 를 gp3 로 마이그레이션 권장.

SSH 22 포트 열어둠 = SSM Session Manager 로 대체. SG 에서 22 포트 닫기.

IMDSv1 비활성 안 함 = SSRF 취약점 시 IAM credentials 탈취. 모든 인스턴스 IMDSv2 강제.

Spot 인스턴스 2분 알림 미처리 = IMDS에서 중단 알림 폴링하거나 EventBridge로 graceful shutdown 구현.

[AWS] EMR: 관리형 빅데이터 클러스터

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon EMR (Elastic MapReduce) 은 [[hadoop-spark|Hadoop / Spark]] 등 오픈소스 빅데이터 프레임워크를 관리형 클러스터로 제공 하는 AWS 서비스. AWS 가 프로비저닝, 설치, 설정, 튜닝, 모니터링을 담당하고, 사용자는 잡 (job) 제출과 클러스터 크기 결정에만 집중한다.

핵심 정체성은 AWS 가 관리하는 대규모 분산 컴퓨트 플랫폼 이며, “어떤 프레임워크를 얹느냐” 는 선택. 대표적으로 Spark, Hive, Trino, HBase, Flink, Hudi/Iceberg/Delta 를 그대로 사용 가능.

왜 EMR 이 필요한가

빅데이터 프레임워크를 직접 운영하는 것의 어려움:

분산 시스템 튜닝: HDFS 복제, YARN 스케줄링, Spark memory 설정 등 수십 개 파라미터
버전 호환성: Hadoop 3.x + Spark 3.5 + Hive 3.1 + Trino 등의 조합 검증
확장성: 워크로드에 맞춰 노드 늘리기/줄이기 (수동은 지연 큼)
장애 복구: 노드 죽으면 리밸런싱, HDFS 재복제
패치: OS + JVM + 각 프레임워크의 CVE 대응
모니터링: 클러스터 상태, YARN queue, Spark UI, driver log

EMR 의 답:

검증된 조합의 프레임워크를 패키지로 제공 (release label 로 버전 고정)
자동 프로비저닝 + 부트스트랩
Managed Scaling 으로 워크로드에 맞춰 자동 확장/축소
Spot 통합 + 실패한 노드 자동 교체
EMRFS 로 [[aws-s3|S3]] 를 HDFS 처럼 접근 (영구 저장)
[[aws-iam|IAM]] / [[aws-vpc|VPC]] / [[aws-cloudwatch|CloudWatch]] 네이티브 통합

언제 EMR 을 쓰나

상황	EMR 적합성
수 GB - PB 규모 배치 처리	적합
Spark ETL / ML 학습	적합
인터랙티브 Presto/Trino SQL	적합 (EMR on EC2)
HBase (long-lived NoSQL)	적합 (EMR on EC2)
Flink 스트리밍	적합
Hudi / Iceberg / Delta 트랜잭션 lakehouse	적합
단순 ETL + Glue Catalog 활용	부적합 → [[aws-glue\|Glue]] 가 저렴
서버리스 SQL 애드혹	부적합 → [[aws-athena\|Athena]]
트랜잭션 처리	부적합 → [[postgresql\|Postgres]] / [[aws-redshift\|Redshift]]

세 가지 배포 방식

EMR 은 “클러스터를 어떻게 실행하느냐” 에 따라 세 모델을 제공. 관리 부담과 유연성의 트레이드오프.

flowchart TB
    Choice{배포 방식 선택}

    Choice --> EC2["EMR on EC2<br/>(전통 클러스터)"]
    Choice --> SL["EMR Serverless<br/>(클러스터 자동)"]
    Choice --> EKS["EMR on EKS<br/>(K8s 위)"]

    EC2 --> C1["장수명 클러스터<br/>HBase, Hive Metastore<br/>인터랙티브 노트북"]
    SL --> C2["간헐적 Spark 배치<br/>새 프로젝트 기본"]
    EKS --> C3["이미 EKS 표준화한 조직<br/>공용 K8s 자원 활용"]

1. EMR on EC2 (전통)

직접 관리하는 클러스터. Master + Core + Task 3 종의 노드로 구성.

flowchart TB
    subgraph Cluster["EMR on EC2 클러스터"]
        M["Master<br/>(YARN ResourceManager,<br/>HDFS NameNode)"]

        subgraph Core["Core Nodes"]
            C1["HDFS DataNode<br/>+ YARN NodeManager"]
            C2["HDFS DataNode<br/>+ YARN NodeManager"]
        end

        subgraph Task["Task Nodes (선택)"]
            T1["YARN NodeManager<br/>(HDFS X)"]
            T2["Spot 활용 가능"]
        end

        M --> C1
        M --> C2
        M --> T1
        M --> T2
    end

    Cluster --> EMRFS["EMRFS<br/>(S3 어댑터)"]
    EMRFS --> S3[("S3")]

노드 역할:

Master: 클러스터 조정. 죽으면 클러스터 전체 실패 (HA 옵션 있음)
Core: HDFS + 컴퓨트. 데이터를 저장하므로 spot 부적합
Task: 컴퓨트만 (HDFS X). Spot 인스턴스로 70% 비용 절감

적합:

HBase 같은 stateful 서비스
Hive Metastore 를 클러스터 안에서 유지
인터랙티브 사용 (Zeppelin, Jupyter, Trino)
여러 프레임워크 동시 실행

비적합:

짧은 단일 배치 (프로비저닝 5-10 분이 아까움)
사용 안 하는 시간에도 인스턴스 요금

2. EMR Serverless

Application 을 만들고, Job Run 을 제출 하는 모델. 클러스터 개념 없음.

flowchart LR
    App["EMR Serverless Application<br/>(Spark or Hive)"]

    Job1["Job Run 1"] --> App
    Job2["Job Run 2"] --> App
    Job3["Job Run N"] --> App

    App -.->|"실행 시만 컴퓨트 프로비저닝"| Workers["Driver + Executor 자동 관리"]

    Workers --> Result[("S3 결과")]

Application 유형: Spark / Hive 중 하나 (동시 지원 X)
컴퓨트 관리 없음: 필요할 때 자동 프로비저닝, 유휴 시 자동 해제
과금: 실제 사용한 vCPU-hour + memory-hour + 임시 storage-hour
Cold start: < 1 분
최대 용량 상한: application 설정으로

적합:

간헐적 배치 (하루 몇 번)
예측 불가한 워크로드
클러스터 관리 부담 없음이 우선
새 프로젝트 사실상 기본 선택

비적합:

HBase / HDFS 요구 (지원 X)
다양한 프레임워크 동시 사용

3. EMR on EKS

Kubernetes 위에서 Spark job 실행. EKS 클러스터가 이미 있는 조직에.

flowchart TB
    subgraph EKS["기존 EKS 클러스터"]
        Nodes["여러 워크로드 pod"]
        VC["Virtual Cluster<br/>(EMR 네임스페이스)"]
    end

    Job["EMR on EKS<br/>Spark Job"] --> VC
    VC -->|"Spark driver/executor pod 생성"| Nodes
    Nodes --> S3[("S3")]

Virtual Cluster: EKS 네임스페이스에 대응하는 EMR 논리 클러스터
Spark pod: driver / executor 가 K8s pod 로 실행
자원 공유: K8s 표준 스케줄링으로 다른 워크로드와 자원 공유

적합:

이미 EKS 로 표준화한 조직
Spark 와 다른 K8s 워크로드 자원 공유
K8s 관측 도구 (Prometheus, Grafana) 활용

비적합:

EKS 관리 부담이 별개
Spark 만 지원 (Hive, HBase, Trino 등 X)

세 방식 비교

축	EMR on EC2	EMR Serverless	EMR on EKS
관리 대상	클러스터 (Master/Core/Task)	없음 (Job 제출만)	EKS 별도
컴퓨트 프로비저닝	5-10 분 (수동)	< 1 분 (자동)	즉시 (K8s)
애플리케이션 종류	20+ (Spark, Hive, HBase, Trino, Flink, …)	Spark, Hive	Spark 만
HDFS / HBase	O	X	X
유휴 비용	인스턴스 요금 지속	0	0 (EMR 관점)
Spot 통합	Task fleet 로	자동	K8s spot
적합	지속 클러스터, 다중 앱	간헐 배치 (기본 선택)	K8s 표준 조직

저장 계층: EMRFS 와 S3

EMR 의 데이터 저장은 두 축.

HDFS

Core 노드의 로컬 디스크에 저장 + 복제
클러스터 종료 시 데이터 손실 (일시적 저장만)
Shuffle intermediate, cache 용도

EMRFS ([[aws-s3|S3]] as HDFS)

[[aws-s3|S3]] 를 HDFS 처럼 사용하는 어댑터
영구 저장 (클러스터와 독립)
여러 클러스터가 같은 데이터 공유
사실상 EMR 의 표준 저장

패턴: raw / staged / curated 데이터는 [[aws-s3|S3]] 에 [[apache-parquet|Parquet]] 로. HDFS 는 오직 job 실행 중 shuffle / cache.

자동 확장: Managed Scaling

EMR on EC2 의 핵심 편의 기능. 워크로드에 따라 코어/태스크 노드 자동 증감.

flowchart LR
    Metric["YARN 대기 컨테이너<br/>+ Spark 미배정 task"] --> Judge{"부하 급증?"}

    Judge -->|Yes| ScaleUp["코어/태스크 노드 추가"]
    Judge -->|No, 유휴| ScaleDown["Shuffle 안 하는 노드 종료"]

    ScaleUp --> Cluster[클러스터]
    ScaleDown --> Cluster

핵심 특성:

Shuffle data-aware: Spark shuffle 이 진행 중인 executor 는 종료하지 않음 (데이터 손실 방지)
On-demand vs Spot 분리 관리: 각각 min/max 지정 가능
최소 - 최대 노드 수 지정, 초 단위 조정

Serverless / EKS 는 자동 스케일링이 기본 내장.

대표 프레임워크

EMR release 하나에 검증된 조합으로 여러 프레임워크가 함께 포함.

프레임워크	용도
[[hadoop-spark\|Apache Spark]]	배치 + 스트리밍 + ML. 사실상 EMR 의 킬러 앱
Apache Hive	Hadoop SQL. Metastore 로 다른 엔진과 공유
Apache Flink	저지연 스트리밍 처리
Trino (구 Presto)	인터랙티브 SQL (여러 데이터 소스 페더레이션)
Apache HBase	Wide-column NoSQL (long-lived 클러스터에서)
Apache Hudi / Iceberg / Delta Lake	Lakehouse table format
Apache Zeppelin / JupyterHub	노트북 인터페이스
Apache Hadoop (HDFS + YARN)	저장 + 자원 관리 기반

구성: EMR release label (예: emr-7.x.y) 로 세트를 고정 지정. AWS 가 조합을 검증.

EMR Studio

웹 IDE + Jupyter 노트북 + Git 통합 + Cluster/Application 관리 UI.

IAM Identity Center 로 SSO
노트북 하나에서 EMR on EC2 / Serverless / EKS 모두 실행
팀 협업, 코드 재사용

EMR vs Glue vs Athena

세 서비스가 Spark / SQL 을 서비스로 제공한다는 점에서 겹침. 결정 축.

축	[[aws-glue\|AWS Glue]]	Amazon EMR	[[aws-athena\|Amazon Athena]]
주 인터페이스	Spark ETL 코드	Spark / Hive / Trino 등	SQL only
관리 오버헤드	최저 (완전 서버리스)	EC2: 중 / Serverless: 낮음	최저
커스터마이징	제한적 (Glue 릴리스)	자유 (버전, 라이브러리, 설정)	없음
다양한 앱	Spark ETL + Python Shell 만	Spark + Hive + HBase + Trino + Flink	SQL (Trino)
Job 시작	1-2 분	Serverless < 1 분 / EC2 5-10 분	즉시
적합	단순 ETL, Catalog 통합 강함	대규모, 복잡, 커스텀, 다양한 앱	애드혹 SQL, 서버리스

대략 결정:

단순 Spark ETL + Glue Catalog → [[aws-glue|Glue]]
복잡한 Spark / 커스텀 설정 / Iceberg 트랜잭션 → EMR (Serverless)
HBase, Trino 인터랙티브 → EMR on EC2
애드혹 SQL → [[aws-athena|Athena]]

성능 튜닝의 핵심 축

프레임워크 (Spark 등) 자체의 튜닝은 [[hadoop-spark|Hadoop / Spark]] 참조. EMR 특유의 축:

파일 포맷: [[apache-parquet|Parquet]] + ZSTD (CSV/JSON 대비 10-100 배)
파티셔닝: [[aws-s3|S3]] prefix 로 파티션 프루닝
AQE: Spark Adaptive Query Execution 활성화 (최신 Spark 는 기본 on)
Spot Task Fleet: 70% 비용 절감, Core 는 On-Demand
Managed Scaling: 워크로드에 맞춰 자동
S3 Committer: 대용량 write 시 partitioned/directory committer 로 rename 최소화
Instance Fleets: 여러 타입 혼합 → 가용성 + 비용 최적

함정

[!WARNING] HDFS 를 영구 저장으로 오해. 클러스터 종료 시 데이터 손실. 결과와 원본은 반드시 [[aws-s3|S3]] 에.

[!CAUTION] EMR on EC2 를 계속 켜둠 = 유휴 시에도 인스턴스 요금. 배치는 Serverless / EC2 는 auto-terminate 정책 (--auto-terminate).

[!WARNING] Core 노드를 Spot 으로. HDFS DataNode 이므로 spot interruption 시 블록 손실 가능. Spot 은 Task 만.

[!IMPORTANT] Managed Scaling 은 Shuffle-aware. 하지만 큰 job 시작 전 미리 스케일 아웃 트리거 필요할 수 있음.

[!CAUTION] EMR Serverless 는 HBase / HDFS X. Stateful 서비스는 EMR on EC2.

[!WARNING] [[aws-lake-formation|Lake Formation]] 세밀 권한 사용 시 EMR 버전 요건. 최소 EMR 6.7+ 로 사용 전 확인.

[!IMPORTANT] Trino 와 PrestoDB 는 다른 프로젝트. EMR 은 둘 다 지원하지만 신규는 Trino 권장 (활발한 개발).

[AWS] ENI: Elastic Network Interface

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

ENI (Elastic Network Interface, 탄력적 네트워크 인터페이스) 는 AWS [[aws-vpc|VPC]] 안의 가상 네트워크 카드. 물리 서버의 NIC (Network Interface Card) 를 소프트웨어로 구현한 것으로, [[aws-ec2|EC2]] / [[aws-lambda|Lambda]] / [[aws-rds|RDS]] / ECS 등이 VPC 에 붙기 위해 사용한다.

핵심 개념: 컴퓨트 리소스 (인스턴스, 함수) 는 하나 이상의 ENI 를 통해서만 VPC 네트워크에 접근 한다. ENI 없이는 IP 주소도, 보안 그룹도 없다.

ENI 가 가지는 속성

속성	의미
Primary Private IP	VPC 서브넷의 사설 IP (필수)
Secondary Private IP	추가 사설 IP (여러 개)
Public IP / EIP	인터넷 접근용 (선택)
MAC Address	ENI 고정 (인스턴스 재부팅해도 유지)
Security Group	ENI 별로 부착 (여러 개 가능)
Source/Dest Check	NAT 인스턴스는 disable
Subnet	소속 서브넷 (AZ 결정)
Description	사용자 지정

중요:

ENI 는 AZ 종속 (서브넷이 AZ 단위). 다른 AZ 로 이동 불가
ENI 는 인스턴스와 독립 수명. 인스턴스 종료 후 재부착 가능 (network migration)
MAC 주소가 고정이라 라이선스 바인딩 용도로 활용

ENI 유형

1. Primary ENI (`eth0`)

인스턴스 시작 시 자동 생성
인스턴스와 수명 동일 (인스턴스 종료 시 삭제)
분리 불가

2. Secondary ENI

추가로 부착 (인스턴스 실행 중에도 hot-plug)
다른 인스턴스로 이동 가능 (failover 용도)
인스턴스 종료해도 유지

3. Requester-managed ENI

AWS 서비스 가 자기 대신 생성한 ENI. 사용자가 직접 삭제 불가 (서비스가 관리).

예:

Lambda VPC 함수의 ENI
RDS 인스턴스의 ENI
ECS Fargate task 의 ENI
VPC Endpoint 의 ENI
ELB 노드의 ENI

왜 ENI 라는 개념이 필요한가

물리 세계에서는 서버 = NIC. AWS 는 가상화 환경이라 컴퓨트와 네트워크를 분리 해야 유연.

분리의 이점:

Failover: EC2 A 가 죽으면 ENI 를 EC2 B 로 이동 -> IP + MAC + SG 그대로 유지 -> 클라이언트는 몰라도 됨
Multi-homing: 하나의 인스턴스가 여러 서브넷 (다중 네트워크) 에 참여
관리 분리: 관리 트래픽용 ENI 와 데이터 트래픽용 ENI 분리
라이선스 고정: MAC 기반 라이선스 (Windows Server 등) 를 인스턴스와 무관하게 유지

인스턴스별 ENI 한도

인스턴스 타입에 따라 부착 가능한 ENI 수 + ENI 당 IP 수가 다름.

인스턴스 크기	대략 ENI 수	ENI 당 IP 수
t3.micro	2	2
t3.medium	3	6
m5.large	3	10
m5.4xlarge	8	30
m5.24xlarge	15	50

정확한 값은 Nitro 인스턴스 ENI 한도 문서 참조.

의미: EKS Pod (VPC CNI 기본), Fargate task 등이 노드당 사용 가능한 IP 수를 결정.

실전 사용 예

1. EC2 Failover (Active-Passive)

flowchart LR
    Client["클라이언트"] --> ENI["ENI<br/>(고정 IP 10.0.1.42)"]
    ENI -->|"현재 부착"| A["EC2 A (active)"]

    A -.->|"장애 감지 후<br/>스크립트/Lambda 가 ENI 재부착"| B["EC2 B (passive)"]

    Note["IP 그대로 유지"]

DNS TTL 대기 없이 초 단위 페일오버 가능.

2. Multi-homed 서버

EC2 (Firewall/NAT)
├─ ENI eth0: public subnet (인터넷)
└─ ENI eth1: private subnet (내부)

한 인스턴스가 두 네트워크를 걸침 (레거시 NAT 인스턴스 패턴).

3. 관리/데이터 분리

EC2 (DB 서버)
├─ ENI eth0: management subnet (SSH, 모니터링)
└─ ENI eth1: data subnet (앱 트래픽)

Security group 이 ENI 별로 다르므로 관리 트래픽만 SSH 허용.

Lambda ENI 의 역사 (Cold Start 개선)

Lambda 는 VPC 안에서 실행 시 ENI 가 필요. 이 부분이 오랜 시간 Lambda [[aws-lambda-cold-start|cold start]] 의 주범이었다.

옛날 모델 (~2019, 각 함수마다 ENI)

sequenceDiagram
    participant U as 사용자
    participant L as Lambda 서비스
    participant EC2API as EC2 API
    participant ENI as ENI

    U->>L: 함수 호출 (첫 호출)
    L->>EC2API: CreateNetworkInterface (VPC 안에서 ENI 생성 요청)
    Note over EC2API,ENI: ENI 생성 5-10 초
    EC2API-->>L: ENI ARN 반환
    L->>L: 함수 컨테이너 부팅
    L->>ENI: ENI attach
    Note over ENI: 총 지연 5-15 초
    L-->>U: 응답

문제:

각 함수 실행마다 ENI 생성 -> 5-15 초 cold start
함수 실행 종료 시 ENI 회수 -> 서브넷 IP 낭비
동시 실행이 많으면 서브넷 IP 고갈 -> ENI 생성 실패
개발자가 함수 코드를 얼마나 최적화해도 이 부분은 못 개선

이 때문에 “Lambda 는 VPC 안에 넣지 마라” 는 조언이 있었다.

새로운 모델 (2019-, Hyperplane ENI)

AWS 는 2019 년 Hyperplane 이라는 내부 인프라를 활용해 ENI 모델을 재설계.

sequenceDiagram
    participant U as 사용자
    participant L as Lambda 서비스
    participant H as Hyperplane ENI (미리 생성됨, 공유)

    Note over H: 여러 함수 실행이<br/>같은 ENI 공유

    U->>L: 함수 호출 (첫 호출)
    L->>L: 함수 컨테이너 부팅
    L->>H: attach (기존 공유 ENI 에)
    Note over L: 총 지연 < 1 초
    L-->>U: 응답

Hyperplane ENI 의 핵심:

함수/버전/서브넷/보안 그룹 조합당 하나 의 ENI (기존: 함수 실행마다 하나)
여러 실행이 같은 ENI 공유 (network multiplexing)
ENI 를 사전 생성 후 재사용
ENI 생성 시간이 cold start 에서 사라짐

결과:

VPC Lambda cold start: 5-15 초 -> < 1 초
IP 소비 대폭 감소
서브넷 크기 걱정 완화 (전에는 /24 이상 강력 권장, 이제는 여유 있음)

2024+ 추가 개선

Warm ENI pool: ENI 가 항상 warm 상태
일반 (non-VPC) 함수와 cold start 차이 거의 없음
Provisioned Concurrency 와 조합 시 사실상 0

VPC Endpoint 도 ENI

Interface Endpoint ([[aws-privatelink|PrivateLink]] 기반) 은 VPC 서브넷에 ENI 를 생성해서 서비스 제공.

[VPC] -> ENI (Interface Endpoint) -> AWS 서비스 (S3, DynamoDB, KMS 등)

이 ENI 의 IP 로 서비스 호출 -> 인터넷/NAT 우회.

Gateway Endpoint (S3, DynamoDB 만) 는 다른 메커니즘 (라우트 테이블) 이라 ENI 없음.

성능 & 대역폭

ENI 자체는 대역폭 상한이 없지만, 인스턴스 타입의 네트워크 성능 에 종속.

Nitro 인스턴스 (m5, m6, c5, c6 등): ENA (Elastic Network Adapter) 지원 -> 최대 100 Gbps
이전 세대 (m4 등): 낮은 상한
EFA (Elastic Fabric Adapter): HPC / ML 학습용 초저지연 인터페이스. RDMA 스타일. ENI 의 특수 형태.

Multi-Attach vs Multi-ENI

혼동 주의:

Multi-Attach EBS: 하나의 EBS 볼륨을 여러 EC2 에 부착 (io1/io2 only)
Multi-ENI: 하나의 EC2 에 여러 ENI 부착

전혀 다른 개념.

비용

ENI 자체 요금 없음
IP 자체 요금 없음 (2024-02 이후 IPv4 public IP 는 시간당 과금)
인스턴스 대역폭 / EIP 미사용 시 요금 등이 관련

함정

[!WARNING] ENI 는 AZ 종속. 서브넷 = AZ. 다른 AZ 로 이동 불가. Multi-AZ HA 는 다른 ENI 로.

[!CAUTION] Requester-managed ENI (Lambda, RDS, VPC Endpoint 가 만든 것) 는 사용자가 직접 삭제 X. 서비스 리소스를 먼저 삭제해야 함. VPC 삭제 실패의 흔한 원인.

[!WARNING] 서브넷 IP 고갈. Lambda / EKS Pod 등이 서브넷의 IP 를 소비. /24 (~250개) 는 소규모, 대규모는 /22 (~1000) 이상 권장.

[!IMPORTANT] Lambda cold start 옛 기억. “VPC Lambda 는 느리다” 는 2019 이전 이야기. 지금은 Hyperplane 으로 큰 문제 없음. 아직 이 이유로 Lambda 를 VPC 밖에 두는 관행이 있음.

[!CAUTION] Security Group 이 ENI 별. 한 EC2 에 여러 ENI 붙이면 각자 다른 SG. 트래픽이 어느 ENI 로 오는지 파악 필요.

[!WARNING] Public IP 자동 할당 은 서브넷 설정. Private subnet 에 만든 ENI 는 EIP 별도 부여해야 인터넷 접근.

[!IMPORTANT] 인스턴스별 ENI 한도 를 넘으면 attach 실패. EKS 노드 크기 결정 시 반드시 확인 (Pod 수 = ENI 수 × IP-per-ENI).

[AWS] Gateway Load Balancer + GENEVE

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Gateway Load Balancer (GWLB) 는 네트워크 계층 (L3) 에서 동작하는 투명 (transparent) 로드 밸런서. 방화벽 / IPS / IDS / DPI 같은 네트워크 보안 어플라이언스 (network security appliance) 를 배치, 확장, 관리하는 것이 유일한 목적이다. 데이터는 GWLB 를 통과하면서 어플라이언스로 우회 (inline inspection) 되고, 응답 후 원래 목적지로 이어진다.

트래픽 캡슐화에는 GENEVE (Generic Network Virtualization Encapsulation, RFC 8926) 프로토콜을 사용한다. UDP 포트 6081.

한 줄 요약: “모든 VPC 트래픽을 서드파티 방화벽 어플라이언스에 통과시켜라” 를 관리형으로 구현한 서비스.

왜 ALB / NLB 로는 부족한가

세 종류 로드 밸런서의 근본 차이.

로드 밸런서	계층	목적
[[aws-alb-nlb\|ALB]]	L7 (HTTP)	HTTP path / host 라우팅, TLS 종단
[[aws-alb-nlb\|NLB]]	L4 (TCP/UDP)	초저지연 TCP/UDP 부하 분산
GWLB	L3 (IP)	모든 IP 패킷을 어플라이언스로 우회

ALB / NLB 는 애플리케이션 트래픽을 여러 서버로 분산 이 목적. GWLB 는 트래픽을 서버로 보내기 전 반드시 검사/변형하는 미들박스로 보내기 위한 것.

대표 시나리오:

조직 정책: 모든 VPC 트래픽을 서드파티 방화벽 (Palo Alto, Fortinet, Check Point 등) 이 검사해야 함
IDS/IPS: 침입 감지/방지 어플라이언스 클러스터 배치
DLP: 데이터 유출 방지 스캐너
커스텀 패킷 검사 (SSL decrypt, protocol validation)

아키텍처

전형적 “centralized inspection VPC” 패턴.

flowchart LR
    subgraph AppVPC["소비자 VPC A (workload)"]
        Sub1["Subnet<br/>(app EC2)"]
        RT1["Route Table<br/>0.0.0.0/0 → GWLBe"]
        GWLBe1["GWLB Endpoint<br/>(GWLBe)"]
    end

    subgraph InspVPC["Inspection VPC (중앙)"]
        GWLB["GWLB<br/>(L3 transparent)"]
        subgraph Fleet["보안 어플라이언스 fleet"]
            A1["Appliance 1"]
            A2["Appliance 2"]
            A3["Appliance N"]
        end
    end

    subgraph AppVPC2["소비자 VPC B"]
        Sub2["app EC2"]
        GWLBe2["GWLBe"]
    end

    Sub1 --> RT1 --> GWLBe1
    Sub2 --> GWLBe2

    GWLBe1 -.->|"GENEVE tunnel<br/>UDP 6081"| GWLB
    GWLBe2 -.->|"GENEVE"| GWLB

    GWLB --> A1
    GWLB --> A2
    GWLB --> A3

    A1 -.->|"검사 후 다시 GENEVE"| GWLB
    GWLB -.->|"복귀"| GWLBe1
    GWLBe1 -->|"원래 목적지로"| Inet["Internet / peered VPC"]

구성 요소

GWLB: 어플라이언스 fleet 앞단의 L3 로드 밸런서. 반드시 inspection VPC 에.
GWLBe (GWLB Endpoint): 소비자 VPC 안에 배포하는 [[aws-privatelink|PrivateLink]] 스타일 endpoint. 라우트 테이블이 이 endpoint 를 목적지로 지정.
Appliance fleet: EC2 인스턴스에 서드파티 SW 설치. GENEVE 지원 필수.
Route Table: 소비자 VPC 의 서브넷 라우트가 트래픽을 GWLBe 로 우회.

트래픽 흐름 (Ingress 예)

1. Internet → IGW → 소비자 VPC 서브넷 라우트
2. 라우트가 "→ GWLBe" 지시
3. GWLBe 가 트래픽을 GENEVE 로 캡슐화 → GWLB 로 (사설 링크)
4. GWLB 가 flow hash 로 특정 appliance 선택 → GENEVE 로 전달
5. Appliance 가 GENEVE decapsulate → 원본 패킷 검사
6. 통과 결정 시 → GENEVE 로 재캡슐화 → GWLB
7. GWLB → GWLBe → 원래 목적지 (app EC2)

핵심: appliance 는 원본 패킷의 모든 헤더와 페이로드를 그대로 봄 (GENEVE 는 캡슐화만 함, 원본 훼손 X). 그래서 IPS / IDS 등이 “실제” 트래픽으로 판단 가능.

GENEVE 프로토콜

Generic Network Virtualization Encapsulation (RFC 8926, 2020 표준화). 네트워크 가상화용 범용 캡슐화.

왜 GENEVE 인가

기존 캡슐화 프로토콜들의 한계:

프로토콜	특징	한계
VXLAN (RFC 7348)	UDP 캡슐화, L2 over L3	헤더 고정, 확장 어려움
NVGRE (RFC 7637)	GRE 캡슐화	UDP 기반 아니라 hash 어려움
STT	TCP 캡슐화	TCP 헤더 활용, 미들박스 오해
GENEVE	UDP + 확장 가능한 TLV	컨트롤 플레인 독립, 메타데이터 무제한

GENEVE 의 결정적 이점:

TLV (Type-Length-Value) 옵션 필드 → 메타데이터를 유연하게 추가 (누가 보냈는지, 어느 tenant 인지, 어떤 정책 태그인지 등)
컨트롤 플레인 독립성 → 어떤 컨트롤러 (SDN) 와도 조합 가능
미들박스 / service chaining 에 최적 → 여러 어플라이언스를 순차 통과 시 메타데이터 전달

AWS 는 이러한 GENEVE 특성을 활용해 GWLB 를 구현. Appliance 벤더가 표준 GENEVE 만 지원하면 자동으로 GWLB 호환.

GENEVE 패킷 구조

+--------------------+
| Outer Ethernet     |
+--------------------+
| Outer IP           |  ← GWLB ↔ Appliance IP
+--------------------+
| Outer UDP (6081)   |  ← Geneve 포트
+--------------------+
| Geneve Header      |  ← VNI + TLV 옵션
+--------------------+
| ORIGINAL PACKET    |  ← 원본 (Ethernet / IP / TCP / Payload)
+--------------------+

포트 6081: IANA 등록. Appliance 는 UDP 6081 을 listen 해서 GENEVE 트래픽 수신.

Flow Stickiness (5-tuple)

같은 흐름 (flow) 이 항상 같은 appliance 로 가야 함. 그래야 stateful inspection (예: TCP session 추적) 이 가능.

기본 동작:

5-tuple hash: (src IP, dst IP, src port, dst port, protocol) 로 해시
Symmetric hashing: A→B 와 B→A 가 같은 hash → 양방향 모두 같은 appliance
Health check 실패 시 해당 appliance 제외 (해당 flow 재분배 - stateful 세션은 끊길 수 있음)

대체 옵션:

3-tuple: (src IP, dst IP, protocol) - port 무시. 여러 흐름을 같은 appliance 로 묶고 싶을 때
2-tuple: (src IP, dst IP) - 가장 broad 그룹핑

Health Check

Appliance 상태 확인 (TCP, HTTP, HTTPS)
실패 target 은 rotation 에서 제외
프로덕션: 어플라이언스 자체가 healthy 를 정확히 반영해야 함 (죽었는데 healthy 라 답하면 트래픽 blackhole)

배포 패턴

1. Centralized Inspection VPC (일반적)

[여러 workload VPC] → [Transit Gateway] → [Inspection VPC (GWLB + fleet)] → [Egress]

하나의 inspection VPC 가 조직 전체 방화벽 담당
관리 단순 (규칙 / 어플라이언스 fleet 한 곳)
TGW route table 로 트래픽 우회

2. 분산 Inspection

[각 workload VPC 안에] → [GWLBe → 로컬 fleet] → [원래 목적지]

각 VPC 가 자기 fleet
지연 최소 (같은 리전 안 데이터센터에서만)
관리 부담 증가

3. Ingress-only / Egress-only

Ingress 만 (인터넷 → 서비스) 검사하거나 Egress 만 (서비스 → 외부) 검사하는 부분 배치도 가능. 라우트 테이블 설계로 결정.

GWLB vs [[aws-network-firewall|AWS Network Firewall]]

같은 목적 (VPC 방화벽) 이지만 방식이 다름.

축	GWLB (+ 3rd party appliance)	[[aws-network-firewall\|AWS Network Firewall]]
관리 대상	Appliance fleet (사용자 관리)	완전 관리형
엔진	Palo Alto / Fortinet / Check Point / 커스텀	Suricata 기반
기능 확장	벤더 어플라이언스 기능 전부	AWS 지원 rule 만
라이선스	어플라이언스 라이선스 (BYOL 또는 marketplace)	AWS 요금에 포함
관측	어플라이언스 벤더 도구	CloudWatch / CloudTrail
적합	기존 벤더 이미 사용, 고급 기능 (SSL decrypt 등)	AWS 네이티브만 원함, 관리 부담 최소

결정:

기존 조직 표준 방화벽 (Palo Alto 등) 을 그대로 클라우드에 → GWLB
AWS 관리형 방화벽만 원함 → Network Firewall
둘 다 필요: L4 는 Network Firewall, L7 DPI 는 GWLB + 어플라이언스

실전 시나리오

1. 서드파티 방화벽 표준화

조직이 이미 Palo Alto VM-Series 를 온프렘에서 사용 중. AWS 로 확장 시:

Palo Alto VM-Series 를 GWLB target group 으로 배포
모든 workload VPC 의 outbound 를 inspection VPC 로 우회
온프렘과 동일 정책 유지

2. IDS/IPS 클러스터

Snort / Suricata 어플라이언스 fleet
GWLB 로 부하 분산
Symmetric hashing 으로 stateful IDS 세션 유지

3. DPI (Deep Packet Inspection)

네트워크 트래픽을 DPI 엔진에 통과
특정 프로토콜 / 페이로드 감지
Compliance 요구 (금융/의료)

Cross-AZ 고려사항

GWLB 는 리전 단위지만 target 은 AZ-aware
Cross-AZ 라우팅 = 데이터 전송 비용 + 지연
권장: workload / GWLBe / appliance 를 같은 AZ 에 위치 시켜 flow 가 AZ 안에서 완결되도록
Route table 을 서브넷별로 (같은 AZ) 로컬 GWLBe 를 참조하게

요금

GWLB 시간당 + 처리 데이터량 (GB)
GWLBe 시간당 + 처리 데이터량 (GB)
Appliance EC2 인스턴스 요금 별도
어플라이언스 라이선스 (marketplace / BYOL) 별도
Cross-AZ 데이터 전송 요금 (일반 VPC 규칙 적용)

총 비용은 상당함 (여러 요소 합산). 도입 전 시뮬레이션 필수.

어플라이언스 요구사항

Appliance 는 GENEVE 를 이해해야 함:

UDP 6081 listen
GENEVE decapsulate → 원본 패킷 처리 → 재캡슐화
Health check 응답
Symmetric flow 지원 (양방향 같은 appliance 로 오는 것 처리)

대부분의 상용 방화벽 벤더 (Palo Alto, Fortinet, Check Point, Cisco, F5 등) 가 GWLB 대상 이미지 (AMI) 를 marketplace 에 제공.

함정

[!WARNING] 모든 어플라이언스가 GENEVE 지원하지 않음. GWLB 도입 전 어플라이언스가 “GWLB target” 을 공식 지원하는지 벤더 문서 확인 필수.

[!CAUTION] 어플라이언스 fleet 이 SPOF = 죽으면 workload 트래픽 blackhole. 최소 3 AZ, Health check 실전 검증, 어플라이언스 auto-recovery 설정.

[!WARNING] Symmetric flow 실패 = stateful 세션 (TCP, TLS) 이 다른 appliance 로 가서 검사 실패. 어플라이언스가 symmetric hashing 을 정확히 지원해야 함.

[!IMPORTANT] Cross-AZ 요금. 서브넷별 로컬 GWLBe / appliance 배치로 최소화.

[!CAUTION] 관리 부담 크다. GWLB + GWLBe + appliance fleet + 라우트 테이블 + 어플라이언스 자체 관리. 소규모 조직은 [[aws-network-firewall|AWS Network Firewall]] 가 훨씬 저렴/편함.

[!WARNING] [[aws-alb-nlb|ALB / NLB]] 와 목적 완전 다름. 애플리케이션 부하 분산에 GWLB 를 쓰지 말 것.

[!IMPORTANT] 디버깅 어려움. VPC Flow Logs 로 트래픽 경로 관찰, appliance 자체 로그, GENEVE 캡슐화 특수성 이해 필요.

[AWS] Glue DataBrew: 시각적 데이터 준비

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Glue DataBrew 는 데이터 분석가와 데이터 사이언티스트를 위한 시각적 (no-code) 데이터 준비 도구. [[aws-glue|AWS Glue]] 제품군의 일부지만 별도 UI 를 갖고 SQL/Spark 코드 없이 250+ 개 사전 정의 변환으로 데이터를 클리닝, 정규화, 변환.

대상 사용자: 데이터 사이언티스트, 애널리스트, 비즈니스 사용자 (엔지니어 아님).

Glue Studio vs Glue DataBrew

같은 Glue 제품군이지만 목적이 다름.

축	[[aws-glue\|Glue Studio]]	Glue DataBrew
대상 사용자	데이터 엔지니어	데이터 분석가, 사이언티스트
UI 방식	노드 그래프 (source → transform → sink)	스프레드시트 (컬럼별 조작)
변환 표현	Spark 코드 생성 (Python/Scala)	Recipe (선언형 스텝)
탐색성	낮음 (파이프라인 실행 후 확인)	높음 (실시간 프리뷰)
변환 수	임의 (Spark)	250+ 사전 정의
머신러닝	별도	이상값/PII 자동 감지, 통계 프로파일
적합	대규모 배치 ETL	데이터 탐색 + 소규모 정제

핵심 개념

Dataset

DataBrew 가 참조하는 데이터 소스.

파일: [[aws-s3|S3]] (CSV, JSON, [[apache-parquet|Parquet]], ORC, Avro, XLSX)
테이블: [[aws-glue|Glue Data Catalog]] 등록 테이블
DB: [[aws-rds|RDS]], [[aws-redshift|Redshift]], [[dynamodb|DynamoDB]] (커넥션)
SaaS: Salesforce, Marketo, ServiceNow (일부)

Project

Dataset + Recipe 조합의 작업 공간. 인터랙티브 편집.

Recipe

순서대로 실행되는 변환 스텝의 집합. JSON 으로 저장, 버전 관리, 재사용 가능.

[
  {
    "Action": {
      "Operation": "REMOVE_MISSING",
      "Parameters": {"sourceColumn": "email"}
    }
  },
  {
    "Action": {
      "Operation": "CHANGE_DATA_TYPE",
      "Parameters": {"sourceColumn": "amount", "targetDataType": "double"}
    }
  },
  {
    "Action": {
      "Operation": "STANDARDIZE_TEXT",
      "Parameters": {"sourceColumn": "country", "standardizeMode": "UPPERCASE"}
    }
  }
]

Job

Recipe 를 dataset 에 적용해 실제 결과를 저장.

Job 유형:

Recipe Job: Recipe 를 데이터에 적용, 결과를 S3 등에 저장
Profile Job: 데이터 통계 (min, max, null, distinct, 히스토그램, 이상값) 생성

변환 종류 (250+ 개)

카테고리	예시
Cleaning	공백 제거, null 처리, 중복 제거, 특수문자 제거
Format	대소문자 변환, 날짜 포맷, 통화, 전화번호
Structural	컬럼 분할/합치기, pivot/unpivot, transpose
Combine	Join, Union
Statistical	Standardize, normalize (z-score, min-max), outliers
Text	정규식 추출, translate, tokenize
Date/Time	Parse, format, extract components, timezone
Math	사칙연산, 통계 함수, 조건부
PII	자동 감지, mask, hash, delete
NLP	감정 분석 (일부), 언어 감지

데이터 프로파일링

Profile Job 을 실행하면 데이터 품질 리포트 자동 생성.

포함:

컬럼별 통계 (min, max, mean, median, stddev)
Null / distinct / duplicate 카운트
값 분포 히스토그램
상관관계 (correlation matrix)
이상치 (outlier) 감지
PII 감지 (이름, 이메일, 주소, 신용카드 등)
데이터 품질 규칙 (Data Quality Rules) 결과

아키텍처

flowchart LR
    subgraph Sources["소스"]
        S3In[("S3 파일")]
        Cat[("Glue Data Catalog")]
        RDS[("RDS/Redshift")]
        SaaS[SaaS 커넥터]
    end

    Sources --> DS[Dataset]
    DS --> Proj[Project]
    Proj -->|"인터랙티브<br/>편집"| Rec[Recipe]

    Rec --> RJ[Recipe Job]
    DS --> PJ[Profile Job]

    RJ --> Out[("S3 출력<br/>CSV/Parquet/JSON")]
    PJ --> Report[("S3 프로파일 리포트")]

요금

Interactive Session: $1.00 / 30분 세션 (Project 편집)
Recipe Job: $0.48 / node-hour
Profile Job: $0.48 / node-hour

계산 예:

매일 recipe job 10분 실행 (2 nodes):
  2 × (10/60) × $0.48 = $0.16 /일
  = ~$5 /월

Glue Spark ETL 대비 저렴 (단순 정제 용도).

실전 예제

1. CSV 를 정제해 Parquet 로

Dataset: s3://raw/customer.csv (100 GB)
Recipe:
  1. REMOVE_DUPLICATES on customer_id
  2. STANDARDIZE_TEXT on country (UPPERCASE)
  3. CHANGE_DATA_TYPE on signup_date (STRING -> DATE)
  4. REPLACE_MISSING on email with 'unknown@domain'
  5. DELETE_COLUMN ssn                      // PII 제거
  6. HASH_STRING on phone_number             // PII masking
Job:
  Output: s3://curated/customer/ (Parquet, SNAPPY)

2. 데이터 품질 리포트 (Profile Job)

Dataset: s3://raw/orders.parquet
Profile Job:
  Output: s3://profiles/orders/report.json
  Includes:
    - order_amount: min=0, max=1M, mean=50, stddev=100
    - Outliers: 12 rows (amount > $10K)
    - customer_email: PII detected
    - country: 32 distinct values

3. 여러 소스 조인

Dataset A: s3://sales/orders.csv
Dataset B: Glue Catalog 의 customers 테이블
Recipe:
  1. JOIN on customer_id
  2. AGGREGATE by country: SUM(amount)
  3. TOP_N n=10 by revenue
Job: Redshift 로 적재

Glue DataBrew 언제 쓰나

적합:

데이터 사이언티스트가 Jupyter 로 데이터 탐색 (대안: pandas)
애널리스트가 원본 CSV 를 BI 용으로 정제
데이터 품질 감사 (Profile Job)
PII 감지 자동화 (한 번)
프로토타이핑, 파일럿

부적합:

대규모 배치 ETL (수 TB / 시간) - [[aws-glue|Glue Spark]] 나 [[aws-emr|EMR]]
실시간 스트리밍 - [[aws-kinesis-data-analytics|Managed Flink]] / [[aws-data-firehose|Firehose]]
복잡한 커스텀 로직 - Glue Spark
프로덕션 grade CI/CD - 코드 기반 (dbt / Glue)

다른 도구 비교

도구	사용자	강점	약점
DataBrew	애널리스트	No-code, 시각적, PII 감지	규모/커스터마이징 제한
[[aws-glue\|Glue Studio]]	데이터 엔지니어	Spark 파워	학습 곡선
dbt	애널리틱스 엔지니어	SQL + 테스트 + lineage	ELT 만
Trifacta	애널리스트	DataBrew 원류, 성숙	유료
pandas / polars	개발자	유연, 코드	규모

함정

[!WARNING] DataBrew 는 대규모 ETL 아님. 100 GB 이상 반복 정제는 [[aws-glue|Glue Spark]] 나 [[aws-emr|EMR]] 이 저렴/빠름.

[!CAUTION] Interactive Session 을 켜두고 idle = 세션당 $1/30분 계속 청구. 사용 후 반드시 종료.

[!WARNING] Recipe 는 순서 의존. 스텝 순서 바꾸면 결과 달라짐. Version 관리 필수.

[!IMPORTANT] Recipe 는 Spark 로 변환 실행. 매우 큰 데이터에는 partition/parallel 튜닝 불가.

[!CAUTION] Profile Job 도 유료 (node-hour). 매일 실행하면 비용 누적. 필요할 때만.

[!WARNING] CI/CD 자동화 어려움. Recipe JSON 을 Git 관리 하되, 배포는 AWS SDK 로 직접 스크립팅 필요.

[AWS] Glue: 서버리스 ETL + Data Catalog

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Glue 는 서버리스 [[etl|ETL]] + 통합 메타데이터 카탈로그 플랫폼. Apache Spark 로 데이터 변환을 실행하고, Hive 호환 Data Catalog 로 스키마를 관리. [[aws-athena|Athena]], [[aws-redshift-spectrum|Redshift Spectrum]], EMR 이 모두 같은 카탈로그를 공유.

세 가지 축:

Data Catalog - Hive 호환 메타 저장소 (databases, tables, partitions)
Crawlers - 데이터 스캔 -> 스키마 자동 등록
Jobs - Spark / Python Shell 기반 변환 실행

Glue Version 이라는 개념

Glue Job 을 만들 때 Glue version (릴리스 라벨) 을 선택한다. Glue version 은 그 안에서 사용할 Spark, Python, Java, 오픈 테이블 포맷 (Iceberg / Hudi / Delta) 조합을 고정한다. AWS 가 조합을 사전 검증해 제공하므로 사용자는 개별 버전 호환성을 신경 쓸 필요 없다.

의미:

Job 스크립트는 특정 Glue version 위에서 실행됨
상위 version 은 최신 Spark / Python / 최적화 포함
하위 version 은 레거시 코드 호환

선택 기준:

신규 프로젝트 -> 최신 안정 version (Iceberg 완전 지원 등 최신 features)
기존 프로덕션 -> 검증된 version 유지 (마이그레이션 계획 후 상승)
매우 오래된 version (2.x 이하) -> EOL 대비 마이그레이션

각 version 의 정확한 Spark/Python/Java 조합은 AWS Glue Release Notes 참조.

Data Catalog

Hive Metastore 호환의 서버리스 메타 저장소. Region 스코프.

Catalog (Region)
├── Database "sales_db"
│   ├── Table "orders"          → S3 위치, 스키마, 파티션, SerDe
│   │   ├── Partition (year=2026, month=07)
│   │   ├── Partition (year=2026, month=08)
│   ├── Table "customers"
├── Database "logs_db"
│   └── Table "access_logs"

소비자: [[aws-athena|Athena]], [[aws-redshift-spectrum|Spectrum]], EMR, Lake Formation, SageMaker
저장 요금: 첫 100만 오브젝트 무료, 초과 시 100k 당 $1
요청 요금: 첫 100만 requests/월 무료, 초과 시 100만 당 $1

Partition 관리 전략:

Crawler 등록: 배치로 파티션 발견 및 등록
Athena MSCK REPAIR TABLE: Hive 스타일 파티션 자동 발견
ALTER TABLE ADD PARTITION: 파이프라인이 직접 등록 (권장)
Partition Projection ([[aws-athena|Athena]] 전용): 카탈로그 등록 없이 규칙으로 유추

Crawlers

S3 / JDBC / [[dynamodb|DynamoDB]] / MongoDB 를 스캔해서 스키마와 파티션을 자동 발견.

Crawler 대상:
- S3 (Parquet, ORC, JSON, CSV, Avro, XML, Delta, Iceberg, Hudi)
- JDBC (RDS, Aurora, Redshift, on-prem)
- DynamoDB
- MongoDB / DocumentDB
- Glue Catalog (cross-region 카탈로그 복제)

모드:

CRAWL_EVERYTHING - 매번 전체
CRAWL_NEW_FOLDERS_ONLY - 새 파티션만
CRAWL_EVENT_MODE - S3 event 기반 증분

Schema Change Policy:

Update: LOG / UPDATE_IN_DATABASE
Delete: LOG / DELETE_FROM_DATABASE / DEPRECATE_IN_DATABASE

과금: $0.44 / DPU-hour (ETL job 과 동일). 2 DPU 반시간 = $0.44.

[!WARNING] Crawler 를 스케줄로 매시간 돌리는 관행 은 비용 유출. 새 파티션만 필요하면 CRAWL_NEW_FOLDERS_ONLY 또는 파이프라인이 파티션을 직접 등록.

Job 유형

유형	엔진	용도
Spark ETL	Apache Spark	대규모 변환, join, aggregate
Spark Streaming	Spark Structured Streaming	Kinesis/Kafka 실시간 인제스션
Python Shell	Python (Spark 없음)	경량 스크립트, API 호출
Ray	Ray.io	분산 Python (2026-04-30 신규 고객 접수 중단)

Worker Types & DPU

DPU (Data Processing Unit) = Glue 컴퓨트의 표준 단위. 대략 4 vCPU + 16 GB 메모리 조합에 해당하며, Glue 요금은 사실상 “DPU × 실행 시간” 으로 결정된다.

Worker 계열 두 축

Glue 는 워커 타입을 두 축으로 제공한다.

flowchart TB
    Job["Spark ETL Job"]

    Job --> G["G-series<br/>(균형형: CPU + Memory)"]
    Job --> R["R-series<br/>(메모리 최적화)"]

    G --> G1["작은 워커<br/>(0.25 - 2 DPU)<br/>스트리밍, 일반 ETL"]
    G --> G2["큰 워커<br/>(4 - 16 DPU)<br/>무거운 aggregation, join"]

    R --> R1["메모리 대비 CPU 낮음<br/>OOM 자주 발생하는<br/>워크로드"]

G-series: 대부분의 워크로드

CPU 와 메모리가 균형 잡힌 표준 워커. 대부분 여기.

작은 워커 (< 1 DPU) = 스트리밍이나 소규모 ETL. cost-efficient.
표준 워커 (1-2 DPU) = 일반 ETL / join / 집계 대부분
큰 워커 (4-16 DPU) = 매우 무거운 aggregation, GC 오버헤드 우려 있는 워크로드
한 워커의 DPU 가 커질수록 disk (임시 shuffle 저장) 도 함께 커짐

R-series: OOM 방지용

같은 DPU 대비 메모리 비중이 큰 워커. Spark job 이 자주 OutOfMemory 로 실패하거나, 매우 큰 shuffle / broadcast join / cache 를 다룰 때.

선택 기준: 로그에 java.lang.OutOfMemoryError / spark.executor.memoryOverhead 관련 실패가 반복 -> R-series 검토.

Worker 선택의 원칙

처음엔 G.1X 로 시작 - 대부분 워크로드 커버
profile 후 조정 - Spark UI 로 GC / shuffle spill 관찰
큰 워커 소수 vs 작은 워커 다수 - 각각 트레이드오프. 큰 워커 = shuffle 오버헤드 감소, 작은 워커 = 병렬성 향상
OOM 잦음 -> R-series 또는 워커 크기 증가
큰 워커 타입은 일부 리전 제약 있음 (신규 계열은 특정 리전만)

정확한 DPU × vCPU × 메모리 × 디스크 값은 AWS Glue 워커 문서 참조.

가격

Standard: $0.44 / DPU-hour, 초 단위 과금, 최소 1초 (Glue 3.0+) / 1분 (Glue 0.9/1.0).

Flex (비시간-민감 워크로드): $0.29 / DPU-hour (약 34% 절감).

Glue 3.0+ 만
G.1X / G.2X 만 (G.4X 이상 미지원)
예: 야간 배치, 재처리, 실험

Data Catalog:

스토리지: 첫 100만 오브젝트 무료, 초과 100k 당 $1/월
요청: 첫 100만 requests/월 무료, 초과 100만 당 $1

Interactive Sessions (Jupyter): $0.44 / DPU-hour, idle 자동 종료.

Data Quality: $0.44 / DPU-hour, 최소 2 DPU × 1분.

계산 예시:

Spark ETL job:
  G.2X × 10 workers = 20 DPU
  30분 실행
  = 20 × 0.5 × $0.44 = $4.40

Flex 로 실행 시:
  = 20 × 0.5 × $0.29 = $2.90

Job 스크립트 예제

PySpark (Glue 5.x)

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# Catalog 에서 읽기 (테이블 = 카탈로그 등록되어 있어야 함)
orders = glueContext.create_dynamic_frame.from_catalog(
    database="sales_db",
    table_name="orders_raw",
    push_down_predicate="year='2026' AND month='07'",  # 파티션 프루닝
)

# 변환
transformed = orders.apply_mapping([
    ("order_id", "long", "order_id", "long"),
    ("customer_id", "long", "customer_id", "long"),
    ("amount", "string", "amount", "decimal(10,2)"),  # 타입 캐스팅
    ("created_at", "string", "created_at", "timestamp"),
])

# Parquet + ZSTD 로 S3 에 저장, 카탈로그도 갱신
glueContext.write_dynamic_frame.from_options(
    frame=transformed,
    connection_type="s3",
    connection_options={
        "path": "s3://my-lake/orders_curated/",
        "partitionKeys": ["year", "month"],
    },
    format="parquet",
    format_options={"compression": "zstd"},
)

job.commit()

Job Bookmarks (증분 처리)

# 활성화 시 이미 처리한 파일/파티션은 건너뜀
orders = glueContext.create_dynamic_frame.from_catalog(
    database="sales_db",
    table_name="orders_raw",
    transformation_ctx="orders_source",  # bookmark key
)

Job 설정에서 Bookmark: Enable -> 재실행 시 새 데이터만.

Triggers & Workflows

개념	역할
Trigger	수동 / 스케줄 (cron) / 이벤트 기반 실행
Workflow	여러 job/crawler 의존성 그래프
Blueprint	재사용 가능한 workflow 템플릿

Workflow 예:
  Trigger (schedule daily 02:00)
    ↓
  Crawler (S3 raw)
    ↓
  Job (raw → staged Parquet)
    ↓
  Job (staged → curated with joins)
    ↓
  Crawler (curated 카탈로그 갱신)

큰 오케스트레이션은 [[aws-step-functions|Step Functions]] 또는 MWAA (Managed Airflow) 로.

Glue Studio

Visual drag-and-drop ETL 편집기. Source -> Transform -> Target 노드를 잇고 Scala/Python 코드가 자동 생성.

Notebook 지원 (Jupyter)
Git 통합 (GitHub, CodeCommit)
시각 lineage
초보자용 + PoC

한계: 실전 프로덕션은 결국 코드로 관리. Studio 는 프로토타입 → 코드 export 흐름.

Glue DataBrew

코드 없는 데이터 준비 UI. 250+ 사전 정의 변환 (정규화, cleansing, ML feature engineering).

Interactive: $1.00 / 30분 세션
Job: $0.48 / node-hour

Glue Data Quality

DQDL (Data Quality Definition Language) 로 규칙 정의. 자동 anomaly detection 도 지원 (Glue 3.0+).

Rules = [
  ColumnCount = 10,
  RowCount between 1000 and 10000000,
  IsComplete "user_id",
  Uniqueness "order_id" > 0.99,
  ColumnValues "status" in ["pending", "paid", "shipped"],
  ColumnValues "amount" >= 0
]

과금: $0.44 / DPU-hour, 최소 2 DPU × 1분.

Zero-ETL Integrations

관리형 CDC 로 [[aws-rds|RDS]]/Aurora/[[dynamodb|DynamoDB]] -> [[aws-redshift|Redshift]] / SageMaker Lakehouse.

설정 자체는 무과금
인제스션: 데이터 볼륨 (1 MB 최소 per request)
Target 컴퓨트: 별도 청구

자세히: [[aws-redshift#zero-etl-integrations|Redshift Zero-ETL]].

Glue Elastic Views (deprecated)

사실상 폐지. Iceberg materialized view (Glue Catalog) 또는 Lake Formation view / [[aws-athena|Athena]] view 로 대체.

Ray 지원 종료 (2026-04-30)

Glue for Ray 는 신규 고객 접수 중단. 기존 고객은 계속 사용 가능. 대체:

표준 Spark job
EMR Serverless
Databricks

성능 & 비용 최적화

Flex execution: 야간/재처리 배치는 Flex 로 34% 절감
Auto Scaling: 워크로드에 따라 워커 자동 조정 (Glue 3.0+)
Job Bookmark: 증분 처리로 재스캔 방지
파티션 프루닝: push_down_predicate 로 필요한 파티션만 read
파일 포맷: [[apache-parquet|Parquet]] / ORC + ZSTD (CSV 대비 10배 이상 절감)
Small files compaction: [[aws-athena|Athena]] CTAS / Iceberg auto-compact
적절한 worker type: 대부분 G.1X/G.2X 로 충분. G.8X+ 는 실제 profile 후
Temp directory 정리: S3 lifecycle 로 자동 삭제

Glue 관용 워크플로우

flowchart LR
    subgraph Source
        RDS[("RDS/Aurora")]
        S3Raw[("S3 raw/")]
    end

    subgraph Glue["AWS Glue"]
        Crawl["Crawler<br/>(schema 자동)"]
        Job["Spark Job<br/>(raw → Parquet)"]
        Cat[("Data Catalog")]
    end

    subgraph Consume["소비"]
        Athena["Athena SQL"]
        RS["Redshift Spectrum"]
        SM["SageMaker"]
        BI["QuickSight"]
    end

    RDS --> Crawl
    S3Raw --> Crawl
    Crawl --> Cat
    S3Raw --> Job
    Job -->|"S3 curated Parquet"| S3C[("S3 curated/")]
    Job -->|"파티션 등록"| Cat
    Cat --> Athena
    Cat --> RS
    Cat --> SM
    S3C --> Athena
    S3C --> RS
    Athena --> BI

함정

[!WARNING] DPU 과잉 프로비저닝. 큰 워커 (G.8X+) 를 기본으로 잡으면 비용 급증. Auto Scaling 또는 profile 후 조정.

[!CAUTION] Crawler 를 매시간 전체 스캔 = 파티션이 수천/수만 개인 데이터 레이크에서 요금 폭탄. CRAWL_NEW_FOLDERS_ONLY 또는 파이프라인이 파티션 직접 등록.

[!WARNING] CSV/JSON 을 Parquet 으로 변환 안 함 = 다운스트림 ([[aws-athena|Athena]], [[aws-redshift-spectrum|Spectrum]]) 이 매 쿼리마다 10-100배 스캔량. Bronze → Silver → Gold 계층에서 Parquet 로 변환은 사실상 필수.

[!IMPORTANT] Job Bookmark 잊음 = 매 실행마다 전체 데이터 재처리. 증분 처리는 명시적으로 활성화.

[!CAUTION] Small Files 를 그대로 카탈로그에 등록 = [[aws-athena|Athena]]/[[aws-redshift-spectrum|Spectrum]] 성능 붕괴. Job 마지막 단계에서 coalesce() 또는 Iceberg auto-compact.

[!WARNING] Ray job 신규 개발 = 2026-04-30 이후 접수 안 됨. 신규는 표준 Spark ETL 로.

[!IMPORTANT] Glue 2.0 이하 사용 = 2026-04-01 EOL. Glue 4.0/5.x 로 마이그레이션 (Python 버전, Spark 버전 호환성 사전 검증).

[!CAUTION] Interactive Session idle = DPU 계속 청구. 자동 타임아웃 짧게 (기본 30분 -> 필요 시 조정).

[!WARNING] Data Catalog 파티션 수백만 개 = 요청 요금 + 쿼리 planning 지연. [[aws-athena|Athena]] Partition Projection 로 대체 가능한 경우 고려.

[AWS] IAM: User, Role, Policy, STS

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

IAM (Identity and Access Management) = AWS 의 권한 관리 전부. User, Group, Role, Policy 로 구성. “누가 어떤 리소스에 어떤 행동을 할 수 있는가” 를 정의.

사용 상황

상황	IAM 사용 패턴
팀원 AWS 접근 권한	Identity Center + Permission Set (SSO 권장)
EC2/Lambda 가 AWS 서비스 호출	Instance Role / Execution Role
다른 계정 리소스 접근	Cross-account Role + AssumeRole
외부 ID Provider	Federated Identity (OIDC, SAML)
최소 권한 강제	Permission Boundary
조직 전체 정책	Service Control Policy (SCP)
EKS Pod 의 AWS 접근	IRSA (IAM Roles for Service Accounts)

객체

flowchart LR
    User["User<br/>(사람)"] -->|attach| Policy
    Group[Group] -->|attach| Policy
    Role["Role<br/>(임시 권한, EC2/Lambda/외부 등)"] -->|attach| Policy
    Policy --> Statement[Effect: Allow/Deny<br/>Action: s3:GetObject<br/>Resource: arn:...]

객체	의미
User	사람 (long-term credentials, 가급적 최소화)
Group	User 묶음 (Policy 를 그룹에 부착)
Role	임시 권한 받는 entity (EC2, Lambda, 외부 계정, EKS Pod 등)
Policy	권한 표현 (JSON Statement 배열)

Policy 구조

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-bucket"
    },
    {
      "Sid": "AllowReadObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": { "aws:SourceIp": "10.0.0.0/8" }
      }
    }
  ]
}

Effect: Allow 또는 Deny. Explicit Deny 가 Allow 를 이김.
Action: s3:GetObject, ec2:* 형식. * 와일드카드 가능.
Resource: ARN. * 로 전체 허용 (최소 권한 원칙 위반).
Condition: 추가 조건 (IP, MFA 여부, 태그 등).

Policy 종류

종류	부착 대상	권한 부여?	의미
AWS Managed	User/Group/Role	O	AWS 가 관리 (`AmazonS3ReadOnlyAccess`)
Customer Managed	User/Group/Role	O	사용자 정의, 재사용 가능
Inline	User/Group/Role	O	직접 임베드 (재사용 X)
Resource-based Policy	S3/SQS/KMS/Lambda 등	O	리소스에 붙음, 교차 계정 허용
Permission Boundary	User/Role	X (상한만)	Role 이 가질 수 있는 최대
Service Control Policy (SCP)	Org / OU / Account	X (상한만)	계정 내 principal 최대 권한
Resource Control Policy (RCP, 2024+)	Org / OU / Account	X (상한만)	계정 내 resource 최대 권한
Session Policy	AssumeRole 세션	X (상한만)	임시 세션에 상한

[!IMPORTANT] 권한을 부여 하는 것은 자격 증명 기반 + 리소스 기반 정책뿐. 나머지 (경계 / SCP / RCP / 세션) 는 상한만 정하고 권한을 주지 않음.

권한 평가 알고리즘

정책 여러 개가 얽힐 때 순서:

① 명시적 Deny 확인 → 있으면 즉시 거부 (short-circuit)
② RCP (조직 리소스 상한) → 통과해야 함
③ SCP (조직 계정 상한) → 통과해야 함
④ 리소스 기반 정책 → 허용 확인
⑤ 자격 증명 기반 정책 → 허용 확인
⑥ 권한 경계 (Boundary) → 통과해야 함
⑦ 세션 정책 → 통과해야 함
→ 최종: Deny 없고 + 최소 하나의 Allow + 모든 상한 통과 → 허용

flowchart TD
    Start[요청] --> Q1{"명시적 Deny?"}
    Q1 -->|있음| Deny[DENY]
    Q1 -->|없음| Q2{"RCP 허용?"}
    Q2 -->|아니오| Deny
    Q2 -->|예| Q3{"SCP 허용?"}
    Q3 -->|아니오| Deny
    Q3 -->|예| Q4{"리소스/자격 Allow?"}
    Q4 -->|아니오| Deny
    Q4 -->|예| Q5{"Boundary 안?"}
    Q5 -->|아니오| Deny
    Q5 -->|예| Q6{"Session 정책 통과?"}
    Q6 -->|아니오| Deny
    Q6 -->|예| Allow[ALLOW]

대원칙:

명시적 Deny > 명시적 Allow > 암묵적 Deny
부여 정책끼리는 합집합 (∪): 자격 증명 + 리소스 기반은 둘 중 하나라도 Allow 면 허용
상한 정책은 교집합 (∩): SCP · 권한 경계 · 자격 증명 정책 모두 통과해야 실제 허용
명시적 Deny 는 무엇으로도 못 뒤집는다

Union vs Intersection (직관)

권한을 주는 정책은 더할수록 넓어진다 (합집합)
권한을 제한하는 정책은 겹칠수록 좁아진다 (교집합)
어디든 명시적 Deny 하나면 결과 = Deny

자세히: [[aws-organizations|AWS Organizations]] SCP/RCP.

Role 과 AssumeRole

sequenceDiagram
    User->>STS: AssumeRole(arn:role/admin)
    STS-->>User: temporary credentials (1h-12h)
    User->>S3: API 호출 (임시 credentials)

aws sts assume-role \
  --role-arn arn:aws:iam::123:role/admin \
  --role-session-name my-session

사용	의미
EC2 Role	EC2 가 metadata 로 자동 취득
Lambda Role	함수 실행 권한
Cross-account	다른 계정의 Role assume
외부 ID + 신뢰 관계	3rd party (SaaS) 가 우리 계정 접근
Federated (OIDC, SAML)	외부 ID Provider 연동

임시 credentials = AccessKeyId + SecretAccessKey + SessionToken. 기본 1시간, 최대 12시간.

ABAC: Attribute-Based Access Control

태그 기반 동적 권한 부여. Role 을 늘리지 않고 태그로 접근 제어.

{
  "Effect": "Allow",
  "Action": "ec2:*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
    }
  }
}

aws:PrincipalTag/Environment: 현재 호출자(Principal)의 태그.
aws:ResourceTag/Environment: 대상 리소스의 태그.
태그가 일치하는 리소스만 접근 허용.

장점: 새 EC2 인스턴스를 만들 때마다 Policy 수정 불필요. 태그만 맞으면 자동 허용.

Condition Keys 상세

Key	의미
`aws:SourceIp`	요청 IP 대역
`aws:RequestedRegion`	요청 리전
`aws:MultiFactorAuthPresent`	MFA 인증 여부
`aws:SecureTransport`	HTTPS 여부
`aws:CurrentTime`	요청 시각 (업무 시간 외 차단)
`aws:PrincipalTag/Key`	호출자 태그
`aws:ResourceTag/Key`	리소스 태그
`iam:PermissionsBoundary`	Permission Boundary ARN
`s3:prefix`	S3 경로 prefix

{
  "Condition": {
    "Bool": { "aws:MultiFactorAuthPresent": "true" },
    "StringEquals": { "aws:RequestedRegion": ["ap-northeast-2"] }
  }
}

IRSA / Pod Identity (EKS)

자세한 건 [[aws-eks]].

IRSA (IAM Roles for Service Accounts): EKS Pod 가 AWS IAM Role 을 얻는 방법.

# ServiceAccount 에 annotation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123:role/s3-reader-role

EKS 가 OIDC Provider 로 등록.
Pod 의 ServiceAccount 에 IAM Role ARN annotation.
Pod 기동 시 OIDC 토큰 주입.
AWS SDK 가 토큰으로 AssumeRoleWithWebIdentity.

EKS Pod Identity (2023+): IRSA 보다 단순. OIDC Issuer 설정 없이 Pod 에 Role 직접 연결.

Identity Center (옛 SSO)

flowchart LR
    User --> IC[AWS Identity Center]
    IC --> Acct1[Account A]
    IC --> Acct2[Account B]
    IC --> Acct3[Account C]
    IC -.SAML.-> Okta[Okta / Azure AD]

Organization 의 통합 SSO.
User 가 로그인 1회로 N 계정 접근.
short-lived credentials (1시간).
Permission Set = 각 계정에서의 권한 묶음.
AD / Okta / Azure AD 연동 지원.

Access Analyzer

의도치 않은 외부 접근 자동 탐지.

분석 대상	탐지 예시
S3 Bucket Policy	퍼블릭 접근 허용 버킷
IAM Role	다른 계정 / 서비스가 assume 가능한 Role
KMS Key	외부 공유 Key
SQS Queue	외부 계정에서 메시지 전송 가능
Lambda Permission	외부 호출 허용 함수

aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:...:analyzer/my-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

[!IMPORTANT] Access Analyzer 는 신규 계정 생성 시 자동 활성화 권장. 설정 후 주기적 findings 리뷰.

Credential Report + Access Advisor

Credential Report (계정 전체)

aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 --decode

CSV 형식. 각 User 의 password 최근 사용, access key 최근 사용, MFA 활성화 여부 확인.

IAM Access Advisor (사용자별)

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123:user/alice
aws iam get-service-last-accessed-details --job-id <id>

최근 사용 서비스 확인 → 미사용 권한 식별 → 최소 권한으로 축소.

Best Practice

✓ Root user 의 MFA + 일상 사용 금지 (Access Key 삭제)
✓ User 대신 SSO (Identity Center)
✓ Role 우선 (long-term credentials 회피)
✓ Least privilege (필요한 권한만, Access Advisor 로 미사용 제거)
✓ Permission Boundary 로 최대 권한 제한
✓ SCP 로 조직 전체 guardrail
✓ Access Analyzer 로 외부 접근 탐지
✓ MFA 강제 (Condition 으로 정책 적용)
✓ Credentials rotation 정기 (90일 이내)
✓ CloudTrail 로 모든 IAM 이벤트 감사

흔한 함정

[!WARNING]

Root user 의 access key = 누출 = 모든 권한 탈취. 즉시 삭제 + SSO 전환.

"Action": "*" 남발 = 권한 과잉. 실제 필요한 Action 목록으로.

Long-term access key 를 git 에 = 자동 스캔으로 즉시 탐지됨. Role + STS 사용.

Resource-based policy 의 Principal 오타 = 의도치 않은 외부 공개.

Policy 변경 후 즉시 반영 안 됨 = IAM 은 eventually consistent. 수초 대기.

AssumeRole 시 duration 기본값 = 1시간. 장시간 작업은 --duration-seconds 조정.

SCP 와 Permission Boundary 혼동 = SCP 는 계정 전체 상한, PB 는 특정 Role 상한.

[AWS] Kinesis Data Streams: 실시간 스트리밍 수집

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Kinesis Data Streams (KDS) 는 실시간 스트리밍 데이터를 대규모로 수집/저장하고, 여러 소비자가 각자 실시간 처리/재처리 할 수 있는 관리형 스트리밍 플랫폼. Apache Kafka 대응 서비스.

핵심 특성:

실시간 (레코드 수집 후 ms ~ 수백 ms 소비 가능)
재처리 (replay) 가능 (24시간 ~ 365일 보존)
다중 소비자 각자 독립 처리
샤드 내 순서 보장

KDS vs Data Firehose 큰 그림

한 줄 감각:

KDS = “데이터를 강물처럼 흘려두고 여러 앱이 떠서 쓴다” (저장/재처리 O)
[[aws-data-firehose|Firehose]] = “데이터를 목적지까지 배달하는 트럭” (저장 X, 배달만)

자세히: [[aws-data-firehose|Amazon Data Firehose]].

핵심 개념

Stream

이름이 붙은 논리적 채널. 여러 프로듀서가 write, 여러 컨슈머가 read.

Shard (프로비저닝 모드)

스트림의 처리량 단위. 샤드 수 = 용량.

방향	샤드당
입력 (Ingress)	1 MB/s 또는 1,000 records/s
출력 (Egress, 클래식)	2 MB/s (모든 소비자 공유)
출력 (Enhanced Fan-Out)	소비자마다 전용 2 MB/s

Record

시퀀스 번호 (자동 할당, 샤드 내 단조증가)
파티션 키 (프로듀서 지정, 어느 샤드로 갈지 결정)
데이터 블롭 (최대 1 MiB)

Producer -> put_records(partition_key="user_42", data=b"...")
    ↓ hash(partition_key)
샤드 결정 -> 시퀀스 번호 부여 -> 저장

Partition Key

같은 파티션 키 = 같은 샤드 = 순서 보장. 잘못 설계하면 hot shard (특정 샤드에 트래픽 몰림).

좋은 파티션 키:

카디널리티 충분 (수천 이상)
균등 분포 (일부 값만 뜨면 hot)
도메인상 순서가 의미 있는 단위 (user_id, device_id)

나쁜 예:

"US" 같은 저카디널리티 (한 샤드에 몰림)
짝수/홀수 등 극히 낮은 카디널리티

용량 모드

Provisioned (전통)

샤드 수를 직접 지정/조정.

aws kinesis create-stream \
  --stream-name my-events \
  --shard-count 4

세밀한 제어
저비용 (트래픽 예측 가능 시)
샤드 관리 부담 (급증 시 수동 resharding)

On-Demand (2021+, 권장 기본)

샤드 관리 불필요, 자동 확장.

aws kinesis create-stream \
  --stream-name my-events \
  --stream-mode-details StreamMode=ON_DEMAND

최대 200 MB/s 자동 확장 (기본), 상한 상향 가능
트래픽 예측 불가 / 급변 시 유리
비용: 시간 + 데이터당 (예측 가능한 최대치는 provisioned 가 저렴)

소비자 (Consumer) 방식

Classic (Shared Throughput)

샤드당 2 MB/s 를 모든 소비자가 공유. GetRecords 폴링 (기본 1초 간격).

지연: ~200 ms
비용: 무료 (샤드 요금에 포함)
소비자 5개까지 권장 (그 이상은 처리량 부족)

Enhanced Fan-Out (EFO)

소비자마다 전용 2 MB/s + HTTP/2 push.

aws kinesis register-stream-consumer \
  --stream-arn arn:aws:kinesis:...:stream/my-events \
  --consumer-name my-consumer

지연: ~70 ms
비용: 소비자당 시간 + 데이터당
소비자 20개까지 (기본)
적합: 소비자 다수 (5개 이상), 저지연 필요

보존 & 재처리

aws kinesis increase-stream-retention-period \
  --stream-name my-events \
  --retention-period-hours 168   # 7일

기본: 24 시간
최대: 365 일 (추가 비용)
재처리 (Replay): 시퀀스 번호 / 타임스탬프로 임의 시점 재실행 가능
적합: 버그 수정 후 재처리, 새 소비자 온보딩, 감사

프로듀서 (Producer) 옵션

도구	특징
AWS SDK (`PutRecord`, `PutRecords`)	표준
KPL (Kinesis Producer Library, Java)	자동 배치, 재시도, 집계 (aggregation)
Kinesis Agent (로그 파일 스트리밍)	파일 tail
CloudWatch Logs subscription	로그 -> KDS
DynamoDB Streams / DMS	CDC 소스
IoT Rules	IoT 데이터

소비자 (Consumer) 옵션

도구	특징
KCL (Kinesis Client Library)	다중 소비자 정족수, 체크포인트, resharding 자동
AWS SDK (`GetRecords`)	저수준 폴링
[[aws-lambda\|Lambda]] (이벤트 소스 매핑)	자동 폴링 + 병렬 실행
[[aws-kinesis-data-analytics\|Managed Flink]]	실시간 SQL/Flink 처리
[[aws-data-firehose\|Data Firehose]]	자동 적재
[[aws-emr\|EMR]] / Spark Streaming	대규모 분석

아키텍처 예시

flowchart LR
    subgraph Producers
        Web[웹앱 이벤트]
        Mob[모바일 이벤트]
        IoT[IoT 디바이스]
        DB["DynamoDB Streams / DMS"]
    end

    Producers -->|"PutRecords"| KDS["Kinesis Data Streams<br/>(4 샤드 or On-demand)"]

    subgraph Consumers["동시 소비자"]
        C1["Lambda<br/>(실시간 alert)"]
        C2["Managed Flink<br/>(집계)"]
        C3["Data Firehose<br/>(S3 적재)"]
        C4["KCL 애플리케이션<br/>(ML feature)"]
    end

    KDS --> C1
    KDS --> C2
    KDS --> C3
    KDS --> C4

    C3 --> S3[("S3")]
    C2 --> S3

요금

Provisioned:

샤드-시간: ~$0.015 / shard-hour
PUT payload: $0.014 / 1M units (25 KB 단위)
확장 보존: $0.020 / shard-hour × extra hours

On-Demand:

스트림-시간: ~$0.04 / stream-hour
Write: $0.08 / GB
Read: $0.04 / GB
보존 확장: 별도

Enhanced Fan-Out:

소비자-시간: ~$0.015 / consumer-shard-hour
Data: $0.013 / GB

Resharding (샤드 분할/병합)

Split (트래픽 증가): 1 샤드 -> 2 샤드 Merge (트래픽 감소): 2 샤드 -> 1 샤드

aws kinesis split-shard \
  --stream-name my-events \
  --shard-to-split shardId-0001 \
  --new-starting-hash-key "170141183460469231731687303715884105728"

프로비저닝 모드만 필요 (on-demand 는 자동)
24시간 안에 여러 번 하면 API 제한
KCL 은 자동 감지

다른 스트리밍 서비스 비교

요구	선택
여러 앱이 실시간 스트림을 각자 처리 + 재처리	KDS
스트림을 S3/Redshift/OpenSearch 에 코드 없이 적재	[[aws-data-firehose\|Data Firehose]]
Apache Kafka 그대로 관리형	Amazon MSK
생산자-소비자 디커플링, 작업 큐 (재처리 불필요)	[[aws-sqs\|SQS]]
하나의 이벤트를 다수에게 팬아웃 (알림)	[[aws-sns\|SNS]]
AWS 이벤트 규칙 라우팅 + cron	[[aws-eventbridge\|EventBridge]]
실시간 SQL / Flink 처리	[[aws-kinesis-data-analytics\|Managed Flink]]

성능 튜닝

파티션 키 카디널리티 - hot shard 방지
PutRecords 배치 - PutRecord 대신 batch (최대 500)
KPL aggregation - 여러 사용자 레코드를 하나의 Kinesis 레코드로 (14x 처리량)
Enhanced Fan-Out - 소비자 5+ 개면
KCL 사용 - resharding 자동, 체크포인트 관리

함정

[!WARNING] 파티션 키 설계 실수 = hot shard = throttling. 카디널리티 충분 + 균등 분포 확인.

[!CAUTION] Enhanced Fan-Out 없이 소비자 5개 이상 = 처리량 나눠 갖기 -> 각자 400 KB/s. EFO 로 소비자당 2 MB/s 보장.

[!WARNING] GetRecords 를 초당 5회 초과 = throttling. 이터레이터 나이 (IteratorAgeMilliseconds) 지표로 감지.

[!IMPORTANT] On-Demand 는 편하지만 비쌈. 트래픽이 예측 가능하고 지속적이면 Provisioned 가 저렴.

[!CAUTION] Kinesis 를 SQS 처럼 쓰지 말 것. 순서/재처리 필요 없고 큐 semantics 만 원하면 [[aws-sqs|SQS]] 가 저렴.

[!WARNING] 레코드 최대 1 MiB. 초과 시 여러 레코드로 분할 필요.

[!IMPORTANT] Kinesis Data Analytics for SQL Applications 는 2026-01-27 종료. 신규는 [[aws-kinesis-data-analytics|Managed Service for Apache Flink]].

[AWS] Lake Formation Data Filter: 행/셀 수준 보안

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Lake Formation Data Filter 는 [[aws-lake-formation|Lake Formation]] 이 관리하는 테이블에 대해 행 (row) / 셀 (cell) 수준의 접근 제어를 정의하는 리소스. IAM 정책이나 버킷 정책만으로는 표현 불가능한 “같은 테이블에 대해 사용자별로 다른 row / 다른 column 만 보이게” 하는 세밀한 제어를 SQL 없이 선언적으로 표현한다.

핵심 대비:

[[aws-iam|IAM]]: 리소스 (버킷/테이블) 단위 접근
Lake Formation 기본 권한: 데이터베이스 / 테이블 / 컬럼 단위
Data Filter: row + column 조합 (cell) 단위

3 단계 보안 계층

Lake Formation 의 데이터 필터링은 3 단계로 구성된다.

flowchart TB
    Query["SELECT * FROM sales.orders<br/>WHERE order_date > '2026-01-01'"]

    Query --> C["Column-level<br/>(허용된 컬럼만 반환)"]
    C --> R["Row-level<br/>(RowFilter 표현식으로 조건 필터)"]
    R --> Cell["Cell-level<br/>(Row + Column 조합)"]
    Cell --> Result["최종 결과<br/>(사용자에게 반환)"]

1. Column-level Security

특정 컬럼만 SELECT 가능하도록. 나머지는 반환에서 제외.

Table orders (order_id, user_id, amount, ssn, credit_card, region)

Analyst-Marketing 그룹 :
  SELECT 가능 컬럼: [order_id, user_id, amount, region]
  숨김: [ssn, credit_card]

SELECT * -> SELECT order_id, user_id, amount, region 로 자동 변환
SELECT ssn FROM orders -> permission denied

2. Row-level Security

WHERE 조건과 유사한 필터 표현식으로 특정 row 만 반환.

Data Filter "region-korea-only":
  Table: orders
  RowFilter: "region = 'KR'"

Analyst-Korea 그룹 :
  SELECT * FROM orders 실행 시
  실제 실행 = SELECT * FROM orders WHERE region = 'KR'

3. Cell-level Security

Row filter + Column filter 결합. 다른 row 에 대해 다른 컬럼도 숨김 가능.

Data Filter "hr-own-region":
  RowFilter: "region = 'KR'"
  ColumnWildcard: ExcludedColumnNames = ['salary']

Analyst-Korea 그룹 :
  KR row 는 salary 제외한 모든 컬럼
  다른 region row 는 아예 안 보임

Data Filter 정의 구조

CreateDataCellsFilter API 또는 콘솔로 정의.

JSON 스펙

{
  "TableData": {
    "TableCatalogId": "111122223333",
    "DatabaseName": "sales",
    "TableName": "orders",
    "Name": "restrict-korea-non-pii",

    "RowFilter": {
      "FilterExpression": "region = 'KR' AND status = 'completed'"
    },

    "ColumnWildcard": {
      "ExcludedColumnNames": ["ssn", "credit_card", "phone"]
    }
  }
}

Name: 필터 식별자 (테이블당 고유)
RowFilter.FilterExpression: PartiQL 스타일 WHERE 표현식
ColumnWildcard: 컬럼 포함/제외 방식
ColumnNames: 명시적 포함 목록 (없으면 wildcard 사용)

컬럼 지정 방식 (셋 중 하나 선택)

방식 1: 명시적 포함 (allowlist)

"ColumnNames": ["order_id", "amount", "order_date"]

지정한 컬럼만 보임.

방식 2: Wildcard + 제외 (denylist)

"ColumnWildcard": {
  "ExcludedColumnNames": ["ssn", "credit_card"]
}

지정 컬럼 제외 모두 보임.

방식 3: Wildcard 만 (모든 컬럼)

"ColumnWildcard": {}

모든 컬럼 보임 (row filter 만 적용).

[!IMPORTANT] [[aws-athena|Athena]] / [[aws-redshift-spectrum|Spectrum]] 는 명시적 포함 (ColumnNames) 만 지원. 제외 방식은 [[aws-emr|EMR]] Spark / Trino 에서만.

RowFilter 표현식

PartiQL 기반 WHERE 스타일 표현식.

지원 연산

카테고리	예
비교	`=`, `<>`, `<`, `>`, `<=`, `>=`
논리	`AND`, `OR`, `NOT`
집합	`IN (...)`, `NOT IN (...)`
NULL	`IS NULL`, `IS NOT NULL`
패턴	`LIKE`, `NOT LIKE` (일부 엔진)
BETWEEN	`BETWEEN x AND y`

예제

-- 단순
region = 'KR'

-- AND / OR
region = 'KR' AND order_amount > 100

-- IN
country IN ('KR', 'JP', 'US')

-- 복합
(department = 'HR' AND access_level >= 3)
OR (department = 'Finance' AND CURRENT_USER = 'auditor')

지원하지 않는 것

서브쿼리 (다른 테이블 조회)
집계 함수 (SUM, COUNT)
JOIN
User-defined function

즉 행 자체의 값 만 참조 가능. 다른 테이블/사용자 정보와 조합은 안 됨.

Named Data Filter vs Inline

Named (재사용 가능, 표준)

콘솔 / API 로 생성 후, permission grant 시 참조.

1. CreateDataCellsFilter("restrict-korea", ...)
2. Grant SELECT ON DATA FILTER "restrict-korea" TO ROLE "Korea-Analyst"

장점:

여러 사용자에게 재사용
이름으로 감사 추적 쉬움
변경 시 한 곳만 수정

Inline (Permission 안에 직접)

Permission 생성 시 필터를 직접 정의.

Grant SELECT ON TABLE orders
  WITH ROW FILTER "region = 'KR'"
  WITH COLUMN EXCLUDES ["ssn"]
  TO ROLE "Korea-Analyst"

단점: 재사용 불가, 변경 시 각각 수정.

권장: Named data filter 사용.

Grant / Revoke 구문

-- Athena / Lake Formation SQL 스타일 (콘솔에서 관리)
GRANT SELECT ON DATA FILTER "restrict-korea"
  TO PRINCIPAL "arn:aws:iam::111122223333:role/KoreaAnalyst";

REVOKE SELECT ON DATA FILTER "restrict-korea"
  FROM PRINCIPAL "arn:aws:iam::111122223333:role/KoreaAnalyst";

CLI:

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::...:role/KoreaAnalyst \
  --resource '{
    "DataCellsFilter": {
      "TableCatalogId": "111122223333",
      "DatabaseName": "sales",
      "TableName": "orders",
      "Name": "restrict-korea"
    }
  }' \
  --permissions SELECT

Cross-Account Data Filter

Producer 계정의 테이블을 Consumer 계정에 필터 적용해 공유.

flowchart LR
    subgraph Producer["Producer 111122223333"]
        T[("orders 테이블")]
        F["Data Filter<br/>'restrict-korea'"]
    end

    subgraph Consumer["Consumer 555566667777"]
        RL["Resource Link<br/>-> orders"]
        Q["Athena 쿼리"]
    end

    F -.-> T
    T -->|"Grant + LF-Tag"| RL
    RL --> Q

    Note1["Producer 필터가<br/>Consumer 쿼리에도 적용"]

Producer 가 Grant → Consumer 가 AWS RAM 초대 수락 → Resource Link 생성
Consumer 가 쿼리하면 Producer 의 data filter 자동 적용

엔진별 지원

엔진	Row Filter	Column 포함	Column 제외	Nested 컬럼
[[aws-athena\|Athena]]	O	O	X	O
[[aws-redshift-spectrum\|Redshift Spectrum]]	O	O	X	O
[[aws-emr\|EMR]] Spark	O	O	O	O
[[aws-emr\|EMR]] Trino	O	O	O	O
[[aws-glue\|Glue]] ETL	부분 (엔진에 따름)	O	O	부분
QuickSight	O (엔진 통해서)	O	X	제한

[!IMPORTANT] Athena / Spectrum 은 컬럼 제외 방식 X. ExcludedColumnNames 를 쓰려면 EMR (Spark / Trino) 필요.

성능 영향

Predicate pushdown: 파티션 컬럼이 row filter 에 있으면 파티션 프루닝 유지 -> 성능 영향 미미
Non-partition 컬럼 필터: 전체 스캔 후 필터 적용 -> 원본 쿼리와 비슷한 비용
Column filter: 실제 read 컬럼 감소 -> 오히려 빠를 수 있음
Nested 컬럼: 필터 평가 오버헤드 발생 가능

최적화:

파티션 컬럼을 row filter 에 자주 활용
컬럼 수 감소로 read 최소화 유도

실전 예제

예 1: 지역별 데이터 격리

Filter "KR-Analysts":
  Table: sales.orders
  RowFilter: "country = 'KR'"
  ColumnWildcard: {}   // 모든 컬럼

Filter "JP-Analysts":
  Table: sales.orders
  RowFilter: "country = 'JP'"
  ColumnWildcard: {}

Grant SELECT ON "KR-Analysts" TO Group("korea-team")
Grant SELECT ON "JP-Analysts" TO Group("japan-team")

각 팀은 자기 지역 order 만 조회.

예 2: PII 컬럼 마스킹

Filter "customers-non-pii":
  Table: sales.customers
  RowFilter: ""   // 모든 row
  ColumnNames: [customer_id, country, signup_date, plan]
  // ssn, credit_card, phone, email 제외

일반 애널리스트는 PII 없는 뷰만 볼 수 있음.

예 3: 조건부 컬럼 접근 (권한 상승 감지)

Filter "hr-conditional-salary":
  Table: hr.employees
  RowFilter: "department IN ('engineering', 'sales')"
  ColumnWildcard:
    ExcludedColumnNames: ["salary", "bonus"]   // 일반 접근 시 급여 X

Filter "hr-full":
  RowFilter: ""
  ColumnWildcard: {}   // 모든 컬럼

Grant "hr-conditional-salary" TO Group("hr-analyst")
Grant "hr-full" TO Group("hr-manager")

감사 & 로깅

Data filter 적용 여부는 [[aws-cloudtrail|CloudTrail]] 이벤트로 기록:

GetTemporaryTableCredentials (엔진이 자격증명 요청)
GetDataAccess (실제 데이터 접근)

Athena / Spectrum 쿼리 로그와 결합해 누가 언제 어떤 필터로 접근했는지 감사 가능.

함정

[!WARNING] ExcludedColumnNames 는 Athena/Spectrum 미지원. 이 두 엔진 사용 시 필터를 ColumnNames (allowlist) 로 다시 작성해야 함.

[!CAUTION] RowFilter 는 서브쿼리 / JOIN 불가. 다른 테이블의 사용자 매핑 (WHERE user = current_user) 은 안 됨. 매핑 테이블을 dimension 으로 join 해서 필터링해야 하면 view 로 우회.

[!WARNING] 파티션 컬럼 필터로 pushdown. 파티션 아닌 컬럼 필터는 전체 스캔 후 필터라 스캔 비용 그대로. 파티션 설계와 함께 고려.

[!IMPORTANT] 테이블당 filter 이름 unique. 대량 관리 시 이름 규약 (e.g., {table}-{persona}) 필요.

[!CAUTION] [[aws-iam|IAM]] 정책이 SELECT 를 이미 거부 하면 Lake Formation 이 GRANT 해도 접근 불가. IAM 은 통과 + LF grant 둘 다 필요.

[!WARNING] Data filter 로 컬럼 숨겨도 [[aws-s3|S3]] 직접 접근은 우회 가능. S3 위치를 Lake Formation 에 등록해 임시 자격증명 vending 강제.

[!IMPORTANT] NULL vs empty. region = 'KR' 은 region 이 NULL 인 row 도 제외. region IS NULL OR region = 'KR' 로 명시.

[!CAUTION] Nested (STRUCT) 컬럼 접근 은 엔진별 지원 다름. Spark / Trino 는 nested 필드 필터 O, 일부는 X.

[AWS] Lake Formation: Data Lake 거버넌스

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Lake Formation (LF) 은 [[data-lake|데이터 레이크]] 의 세분화된 접근 제어 + 거버넌스를 중앙에서 관리 하는 서비스. [[aws-glue|Glue Data Catalog]] 위에 얹혀 데이터베이스/테이블/컬럼/row/cell 단위 권한을 [[aws-iam|IAM]] 정책 대신 LF 만의 표준으로 표현.

핵심: [[aws-iam|IAM]] 만으로는 컬럼/row 단위 제어가 어려움 -> LF 로 대체.

왜 Lake Formation

[[aws-s3|S3]] + [[aws-glue|Glue]] + [[aws-athena|Athena]] 만으로 데이터 레이크를 구성하면:

[[aws-iam|IAM]] 정책 이 유일한 접근 제어 -> 버킷/prefix 단위밖에 안 됨
컬럼 단위 접근 제어 어려움 (PII 컬럼만 숨기기)
row 단위 필터 없음 (지역별 데이터 격리)
여러 계정에 걸친 공유가 복잡
감사가 서비스별로 분산

Lake Formation 이 답:

테이블/컬럼/row/cell 단위 권한
LF-Tags 로 태그 기반 액세스 제어 (RBAC 대신 ABAC)
Cross-account 공유 표준화
[[aws-athena|Athena]], [[aws-redshift-spectrum|Spectrum]], [[aws-emr|EMR]], Spark 모두 동일 권한

아키텍처

flowchart TB
    S3[("S3 Data Lake")]

    subgraph LF["Lake Formation"]
        Catalog[("Glue Data Catalog<br/>databases/tables")]
        Perms["Permissions<br/>(DB/Table/Column/Row/Cell)"]
        Tags["LF-Tags<br/>(Tag-Based Access)"]
        LFAdmin["Lake Formation Administrator"]
    end

    S3 -.->|"위치 등록"| Catalog
    LFAdmin -->|"설정"| Perms
    LFAdmin --> Tags
    Tags -.-> Perms

    Perms --> Enforce["권한 검사 (모든 엔진)"]

    Enforce --> Athena[Athena]
    Enforce --> Spectrum[Redshift Spectrum]
    Enforce --> EMR[EMR Spark/Presto]
    Enforce --> Glue[Glue ETL]
    Enforce --> QS[QuickSight]

    IAM[IAM Policy] -.->|"기본 통과 후<br/>LF 검사"| Enforce

권한 계층

대상	권한 예시
Database	CREATE_TABLE, ALTER, DROP, DESCRIBE
Table	SELECT, INSERT, DELETE, ALTER, DROP, DESCRIBE
Column	SELECT (특정 컬럼만)
Row	SELECT (filter expression)
Cell	SELECT (row × column 조합)
Data Location (S3 prefix)	DATA_LOCATION_ACCESS

LF-Tags (Tag-Based Access Control, TBAC)

RBAC (역할 기반) 대신 ABAC (속성 기반). 태그로 리소스와 사용자를 매칭.

예: PII / 부서별 접근

1. LF-Tag 정의
   Key: classification
   Values: [public, internal, pii]

   Key: department
   Values: [finance, hr, marketing]

2. 리소스에 태그
   Database "sales"      -> department=finance
   Table   "customers"   -> classification=pii
   Column  "email"       -> classification=pii

3. 사용자에 정책
   Analyst-Finance 그룹:
     GRANT SELECT ON LF-Tags: department=finance AND classification!=pii

이제 Analyst-Finance 는 finance DB 의 non-PII 컬럼만 SELECT 가능.

왜 LF-Tags 인가

수백 개 테이블 × 수십 개 그룹 = 조합 폭발. 태그 기반이면 정책 수 = 태그 수 로 유지.

컬럼 / Row / Cell 필터

Column-Level Filter

특정 컬럼만 보이거나 숨김.

Table: customers
Grant SELECT on columns: [customer_id, name, country]
     Excluding: [ssn, birthdate, phone]  # PII 은닉

Row-Level Filter (Data Cells Filter)

WHERE 조건으로 row 필터.

Filter: "region-korea-only"
  DatabaseName: sales
  TableName: orders
  RowFilter: "country = 'KR'"
  ColumnWildcard: ["*"]  # 모든 컬럼

Grant SELECT ON DataFilter "region-korea-only" TO group "Korea-Analysts"

Korea-Analysts 는 orders 를 SELECT 해도 country='KR' row 만 보임.

Cell-Level Filter

Row + Column 결합. 다른 컬럼도 함께 제한.

Filter: "hr-own-region"
  RowFilter: "region = current_user_region()"
  ColumnWildcard:
    ExcludedColumnNames: ["salary"]  # region 이 자기 것이 아니면 salary 안 보임

Lake Formation vs IAM

축	[[aws-iam\|IAM]]	Lake Formation
단위	버킷/prefix	DB/Table/Column/Row/Cell
표현	JSON 정책	LF-Tags + 관계 모델
엔진	AWS 서비스 개별	Athena/Spectrum/EMR/Glue 통일
PII 관리	어려움	표준
감사	CloudTrail 서비스별	중앙화
관계	기본	IAM 통과 후 LF 재검사

우선순위: LF 가 켜진 리소스는 LF 권한이 IAM 을 오버라이드. IAM 이 SELECT 를 허용해도 LF 에서 안 하면 접근 불가.

Blueprints (워크플로)

deprecated 방향. 데이터 소스 (JDBC, S3) 를 catalog 로 로드하는 사전 정의 워크플로. 신규는 [[aws-glue|Glue]] 직접 사용 권장.

데이터 위치 등록

Lake Formation 이 관리할 S3 위치를 등록.

aws lakeformation register-resource \
  --resource-arn arn:aws:s3:::my-lake/analytics/ \
  --use-service-linked-role

등록된 위치의 S3 GET 은 LF 가 vending 하는 임시 자격 증명으로 수행
사용자가 직접 S3 API 를 호출해도 LF 권한 우회 불가 (프리셋)

Cross-Account 공유

Producer Account (data owner)
   |  GRANT SELECT ON table1 TO Consumer Account
   ↓
Consumer Account (data consumer)
   |  RAM 초대 수락 -> Local resource link 생성
   ↓
   Athena / Spectrum 에서 LOCAL 로 쿼리

AWS RAM 통합
LF-Tags 도 cross-account 로 전파
데이터 복사 없이 논리적 공유

관리 역할 (Administrator)

Lake Formation Admin: LF 자체 설정, 다른 사용자에게 권한 부여 가능
Data Lake Admin: Data catalog / underlying storage 관리
Read-Only Admin: 감사 목적

LF 활성화 절차

Lake Formation Administrator 지정
기존 [[aws-glue|Glue Data Catalog]] 를 LF 로 마이그레이션 (OnlyIAMSettings -> Mixed 또는 LF 만)
Data Location 등록
LF-Tags 정의 및 리소스에 부여
그룹/사용자에 GRANT
IAMAllowedPrincipals (default 우회) 제거

중요: LF 를 활성화하지 않은 계정에서 기존 IAM 만 사용해도 되지만, 새 프로젝트는 처음부터 LF 로.

엔진별 동작

엔진	LF 지원	특이사항
[[aws-athena\|Athena]]	완전 지원	Column/Row/Cell 필터 자동 적용
[[aws-redshift-spectrum\|Redshift Spectrum]]	완전 지원	LF-Tags 인식
[[aws-emr\|EMR]] Spark/Presto	지원	EMR 6.7+ (Trino), Spark 3.3+
[[aws-glue\|Glue Spark]] ETL	지원	Job role 이 LF 권한 필요
QuickSight	지원	Author 가 LF 권한

최근 업데이트 (2024-2026)

Nested column filtering: struct 안의 필드 단위 컬럼 제어
Iceberg 완전 지원 (v1.10+)
Data cell 확장: 복잡한 row filter 표현식
RCP 통합 ([[aws-organizations|Organizations]] RCP 와 결합)

요금

Lake Formation 자체는 무료. 다음이 요금:

[[aws-glue|Glue Data Catalog]] (요청, 저장)
[[aws-s3|S3]] (저장, 요청)
엔진 ([[aws-athena|Athena]] 스캔, [[aws-emr|EMR]] 인스턴스 등)

함정

[!WARNING] LF 활성화 후 IAMAllowedPrincipals 를 계속 두면 = IAM 이 계속 오버라이드 = LF 권한 무의미. 반드시 제거.

[!CAUTION] 테이블 위치 (S3) 를 LF 에 등록 안 하면 = 사용자가 [[aws-s3|S3]] API 로 직접 접근해 LF 우회. 반드시 등록.

[!WARNING] 엔진 버전 확인. [[aws-emr|EMR]] / [[aws-athena|Athena]] 가 오래된 버전이면 컬럼/row 필터 미지원.

[!IMPORTANT] [[aws-iam|IAM]] 정책과 LF 는 AND. 둘 다 통과해야 접근. IAM 이 이미 DENY 하면 LF 가 GRANT 해도 소용없음.

[!CAUTION] Cross-account share 는 AWS RAM 초대 수락 필요. Consumer 가 수락 안 하면 안 보임.

[!WARNING] LF-Tags 조합 폭발. 태그 key 개수 × values 개수 x 리소스 = 관리 부담. 4-6개 key 로 절제.

[!IMPORTANT] Data Cells Filter 는 성능 영향 있음. 매 쿼리마다 필터 평가. 큰 팩트 테이블에는 partitioning + filter 결합.

[AWS] Managed Service for Apache Flink (구 Kinesis Data Analytics)

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Managed Service for Apache Flink (구 Amazon Kinesis Data Analytics) 는 스트리밍 데이터를 실시간으로 처리 (aggregate, join, window, ML 추론) 하는 완전 관리형 Apache Flink 서비스. Java / Python / Scala / SQL 로 스트림 애플리케이션 작성.

이름 변경 & SQL 종료 (2025-2026)

[!IMPORTANT] Kinesis Data Analytics for SQL Applications 는 2026-01-27 종료. 신규 생성 불가, 기존 앱 모두 삭제. SQL 애플리케이션 사용자는 Managed Flink Studio (Zeppelin + Flink SQL) 로 마이그레이션.

시기별 정리:

시기	이름 / 상태
~2018	Kinesis Data Analytics for SQL Applications (SQL)
2018-2023	Kinesis Data Analytics for Apache Flink (Java/Python/Scala) 추가
2023-08	Amazon Managed Service for Apache Flink 로 이름 변경
2025-09-01	KDA for SQL - 제한적 지원 시작
2025-10-15	KDA for SQL - 신규 생성 차단
2026-01-27	KDA for SQL 모든 앱 삭제, 서비스 종료

지금은 Managed Service for Apache Flink (MSF) 하나만.

왜 Apache Flink

스트리밍 처리는 배치 처리보다 어려운 문제들이 있음:

Event time vs Processing time - 이벤트가 언제 발생했는지 vs 언제 처리됐는지
Late-arriving events - 늦게 도착한 데이터 처리
Watermark - “이 시점 이전 이벤트는 다 왔다” 신호
Exactly-once semantics - 정확히 한 번 처리
Stateful processing - 세션, 집계 상태 관리
Windowing - Tumbling / Sliding / Session window

Flink 는 이 모든 것을 first-class 지원. Kafka Streams, Spark Streaming 대비 저지연 + stateful 강함.

지원 언어

언어	특징
Java	원류, 가장 완전. Flink DataStream API
Python	PyFlink. Java API wrapper
Scala	사용 감소 (Flink 2.x 부터 core 제거)
SQL	Flink SQL. Studio (Zeppelin notebook) 에서

지원 버전 (2026 시점)

Flink 1.20.0 (최신, 2026 기준)
Flink 1.19.1
Flink 1.18.1

LTS 정책: 각 버전 GA 시점부터 24개월 지원.

아키텍처

flowchart LR
    subgraph Sources
        KDS["Kinesis Data Streams"]
        MSK[Amazon MSK]
        Kafka[Self-managed Kafka]
        S3In[("S3 파일")]
    end

    Sources --> MSF["Managed Flink Application<br/>(Flink Job)"]

    MSF --> Sinks

    subgraph Sinks
        KDSOut["KDS"]
        FH["Data Firehose"]
        S3Out[("S3")]
        DDB[("DynamoDB")]
        OS[OpenSearch]
        RDS[("RDS/Aurora")]
        Custom[Custom HTTP]
    end

    State["Application State<br/>(RocksDB, 자동 체크포인트)"] <-.-> MSF
    CW["CloudWatch<br/>Logs/Metrics"] <-.-> MSF

Application: Flink job (JAR 또는 Python)
KPU (Kinesis Processing Unit): 1 vCPU + 4 GB. 병렬성 단위
State: RocksDB 기반, S3 로 자동 체크포인트 / 스냅샷
Auto-scaling: 스트림 트래픽에 따라 KPU 자동 조정

실행 유형

1. Application (프로덕션)

배포된 JAR / Python 을 24/7 실행.

Application configuration:
  runtime: FLINK-1_20
  code_location: s3://my-bucket/flink-app.jar
  parallelism: 4
  parallelismPerKPU: 1
  autoScalingEnabled: true

2. Studio (Zeppelin Notebook)

인터랙티브 개발/탐색. Flink SQL, PyFlink, Scala 지원.

-- Flink SQL 예: 5분 tumbling window
CREATE TABLE clicks (
  user_id BIGINT,
  page STRING,
  event_time TIMESTAMP(3),
  WATERMARK FOR event_time AS event_time - INTERVAL '10' SECOND
) WITH (
  'connector' = 'kinesis',
  'stream' = 'clicks',
  'format' = 'json'
);

SELECT
  page,
  TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start,
  COUNT(*) AS click_count
FROM clicks
GROUP BY page, TUMBLE(event_time, INTERVAL '5' MINUTE);

Studio 는 SQL 사용자의 마이그레이션 답. KDA for SQL 을 대체.

커넥터 (Connectors)

40+ 개 소스/싱크:

카테고리	목록
AWS	[[aws-kinesis-data-streams\|Kinesis Data Streams]], MSK, [[aws-data-firehose\|Firehose]], [[aws-s3\|S3]], [[dynamodb\|DynamoDB]], [[aws-rds\|RDS]] (JDBC), OpenSearch, CloudWatch
Kafka	Self-managed Kafka, Confluent
Message Queue	RabbitMQ, ActiveMQ
DB	JDBC (PostgreSQL, MySQL), Iceberg, Hudi, Delta
HTTP	Async HTTP sink

윈도우 (Windowing) 예제

Tumbling Window

겹치지 않는 고정 크기.

[--5분--][--5분--][--5분--]

Sliding Window

겹치는 크기.

[--5분--]
   [--5분--]
      [--5분--]

Session Window

이벤트 간 gap 기반.

[event][event] .......gap....... [event][event][event]
        ↑↑ 하나의 세션              ↑↑↑ 다른 세션

Global Window

전체 스트림 하나 (트리거 커스텀).

DataStream<Event> input = ...;
input
  .keyBy(Event::getUserId)
  .window(TumblingEventTimeWindows.of(Time.minutes(5)))
  .aggregate(new SumAggregate())
  .print();

Exactly-Once

Flink 체크포인트 + 커넥터 트랜잭션 지원.

소스 (KDS, Kafka) offset 저장
싱크 (S3, Kafka) transactional write
실패 시 마지막 체크포인트에서 재실행

요금

KPU-hour: ~$0.11 / KPU-hour (Application)
Studio: ~$0.14 / KPU-hour
Running Application Storage: ~$0.10 / GB-월 (state)
Durable Application Backups: ~$0.023 / GB-월 (스냅샷)

계산 예:

Application 4 KPU × 730 시간 = 2920 KPU-hour
2920 × $0.11 = $321.20 /월

실무 시나리오

시나리오	답
실시간 이상 감지 (fraud detection)	Managed Flink DataStream (Java)
5분 tumbling aggregation	Managed Flink SQL (Studio)
CDC 로 KDS -> Iceberg 실시간	Managed Flink + Iceberg connector
세션 window 분석	Managed Flink Session Windows
배치 aggregation	[[aws-athena\|Athena]] / [[aws-emr\|EMR]] (Flink 아님)
단순 적재 (변환 없음)	[[aws-data-firehose\|Data Firehose]] (Flink 필요 X)

Flink vs 다른 스트리밍 엔진

엔진	특징	언제
Flink	저지연, exactly-once, stateful 강함	복잡한 스트리밍 처리
Spark Structured Streaming	배치와 통합, 익숙	이미 Spark 스택
Kafka Streams	Kafka 안에서만, 경량	Kafka 전용
KSQL / ksqlDB	SQL only, 단순	Confluent 환경
[[aws-data-firehose\|Firehose]]	변환 없이 적재	코딩 회피

함정

[!WARNING] KDA for SQL 은 2026-01-27 종료. 신규 개발 금지. 기존 SQL 앱은 Managed Flink Studio (Zeppelin) 로 마이그레이션 계획 수립.

[!CAUTION] Flink 학습 곡선 급함. Event time / watermark / windowing 개념 이해 없이 도입하면 실패. 배치 사고 방식 X.

[!WARNING] KPU 과잉 프로비저닝 = 비용 폭탄. Auto-scaling + 실측 후 조정.

[!IMPORTANT] State 크기 증가 = 체크포인트 지연 + 비용. Session window state TTL 설정, keyed state 크기 모니터링.

[!CAUTION] Late event handling 미설정 = 데이터 조용히 drop. Watermark 전략 + allowedLateness 정의.

[!WARNING] Studio 는 개발/탐색용. 24/7 프로덕션은 Application 배포로. Studio 는 노트북 종료 시 앱도 중단.

[!IMPORTANT] Flink 2.x 는 Scala 제거. 새 프로젝트는 Java / Python.

[AWS] Network Firewall

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Network Firewall (ANF) 은 VPC 를 위한 관리형 네트워크 방화벽 + 침입 방지 (IDS/IPS) 서비스입니다. Stateful + Stateless 규칙 엔진, Suricata 호환 규칙, TLS SNI 검사, 관리형 위협 인텔리전스 피드를 제공.

한 줄 요약: SG/NACL 로 부족한 딥 인스펙션 (Layer 7 검사, 도메인 필터, 시그니처 기반 IPS) 담당.

왜 필요한가

SG/NACL 의 한계

[[aws-sg-vs-nacl|Security Group / NACL]] 은 5-tuple (src IP, port, protocol, dst IP, port) 만 봄:

도메인 기반 차단 불가 (example.com/malicious 만 막고 example.com/api 허용?)
패킷 내용 검사 X (SQL injection payload 감지?)
알려진 공격 시그니처 X
위협 인텔리전스 자동 연동 X

Network Firewall 의 접근

Suricata 규칙: DPI (Deep Packet Inspection)
TLS SNI: HTTPS 도메인 필터
관리형 규칙 그룹: AWS 유지 (AttackVector, ThreatSignatures, BotNetCommandAndControlDomains)
로그: alert/flow/TLS

아키텍처

flowchart LR
  IGW[Internet Gateway] --> FW[Network Firewall<br/>Endpoint]
  FW -->|allowed| Private[Private Subnet]
  Private -->|outbound| FW
  FW --> IGW

중요: 서브넷 사이에 방화벽 endpoint 를 두고 route table 을 조정해 트래픽이 방화벽을 통과하도록.

구성 요소

Firewall

전체 배포 단위. 하나의 VPC 에 연결.

Firewall Policy

Firewall 이 사용할 규칙 그룹 모음. Stateless + Stateful 규칙 그룹, default action.

Rule Group

실제 규칙 컨테이너. 두 유형:

Stateless: 5-tuple 매칭 (Suricata 없음)
Stateful: Suricata 규칙 (DPI, 도메인 필터, 시그니처)

Firewall Endpoint

각 AZ 에 하나. Route table 이 이 endpoint 로 트래픽 라우팅.

Stateful Rules (Suricata)

Suricata 규칙 문법:

drop tcp any any -> any 443 (msg:"Block bad.example.com"; \
  tls.sni; content:"bad.example.com"; nocase; sid:1000001;)

alert http any any -> any any (msg:"SQL Injection"; \
  content:"UNION SELECT"; http_uri; sid:1000002;)

drop ip any any -> [$MALICIOUS_IPS] any (msg:"Known bad IP"; sid:1000003;)

action: alert, drop, pass, reject. direction: -> (단방향), <> (양방향).

FQDN 기반 필터링 (Deep Dive)

FQDN (Fully Qualified Domain Name) 필터링은 IP 대신 도메인 이름으로 트래픽을 허용/차단하는 능력. example.com, *.malicious.net, internal.corp.local 같은 규칙을 쓸 수 있다.

왜 중요한가: IP 만으로는 부족한 이유들.

CDN / 클라우드 서비스: github.com, s3.amazonaws.com 등은 수천 IP → CIDR 로는 불가능
동적 IP: 서비스가 IP 를 자주 바꿈
정책의 표현력: “우리 회사는 github 만 허용” 이 IP 대역 스캔보다 명확
감사: “어느 도메인으로 나갔는지” 가 IP 보다 이해하기 쉬움

도메인 리스트 (Domain List) 규칙

Suricata 문법 없이 관리자 친화적 방식.

RulesSourceList:
  Targets:
    - 'example.com'          # 정확한 도메인
    - '.github.com'          # 서브도메인 포함 (github.com + *.github.com)
    - 'api.stripe.com'
  TargetTypes:
    - 'HTTPS'                # TLS SNI 기반
    - 'HTTP'                 # HTTP Host header 기반
  GeneratedRulesType: ALLOWLIST   # 또는 DENYLIST

동작 방식:

ALLOWLIST: 리스트의 도메인만 허용, 나머지 차단
DENYLIST: 리스트의 도메인만 차단, 나머지 허용

Wildcard:

.github.com = github.com + *.github.com (모든 서브도메인)
github.com = 정확히 이 도메인만

어떻게 도메인을 감지하는가 (프로토콜별)

Network Firewall 은 트래픽의 평문 부분 에서 도메인 정보를 추출.

HTTP (평문 80)

HTTP Host 헤더 를 파싱.

GET /api/data HTTP/1.1
Host: api.example.com          ← 여기 매칭
User-Agent: ...

각 HTTP 요청마다 Host 확인
명확하고 확실 (평문이므로)

HTTPS (TLS 443)

TLS ClientHello 안의 SNI (Server Name Indication) 확장 을 파싱.

Client → Server: TCP SYN
Server → Client: TCP SYN-ACK
Client → Server: TCP ACK
Client → Server: TLS ClientHello
  ├─ Cipher suites
  ├─ Extensions:
  │   └─ server_name: "api.example.com"  ← SNI (평문 노출!)
  └─ ...
Server → Client: TLS ServerHello + Certificate
... (이후 완전 암호화)

핵심: SNI 는 TLS handshake 초반 (평문) 에 노출됨. 브라우저가 어느 사이트에 접속하려는지 서버가 알아야 (multi-tenant hosting) 하기 때문. Network Firewall 은 이 SNI 만 보고 결정.

중요한 함의:

실제 응답 데이터는 여전히 암호화. Network Firewall 은 못 봄 (TLS Inspection 옵션 없이는)
SNI 필터링은 connection 초기 에 결정 → 이후 데이터는 통과
하나의 도메인 (예: github.com) 이 여러 IP 로 서빙되어도 SNI 하나로 감지

상세 흐름 예시

sequenceDiagram
    participant C as Client (VPC)
    participant NF as Network Firewall
    participant S as bad.example.com

    Note over NF: Domain List DENYLIST:<br/>[".bad.example.com"]

    C->>NF: DNS 조회 (bad.example.com → 1.2.3.4)
    Note over NF: DNS 는 통과 (별도 필터)

    C->>NF: TCP SYN → 1.2.3.4:443
    NF->>NF: 5-tuple 매칭, connection 시작

    C->>NF: TLS ClientHello (SNI = bad.example.com)
    NF->>NF: SNI 파싱 → DENYLIST 매칭
    NF-->>C: RST (drop, msg logged)

    Note over C,S: 연결 성립 실패

Wildcard 패턴 예제

규칙	매칭
`example.com`	`example.com` 정확히 (서브도메인 X)
`.example.com`	`example.com` + `www.example.com` + `api.example.com` + …
`api.example.com`	정확히 그 서브도메인만
`.` (dot only)	모든 도메인 (사실상 all)

주의: *.example.com 형식은 지원 X. 리딩 dot (.) 이 표준.

FQDN 필터링의 근본적 한계

우회 가능한 경우들:

1. Encrypted DNS (DoH / DoT)

DoH (DNS over HTTPS, 443 위), DoT (DNS over TLS, 853)
클라이언트가 DNS 조회를 암호화된 채로 external resolver (Cloudflare 1.1.1.1, Google 8.8.8.8) 에 보냄
Network Firewall 은 도메인 결정 자체를 못 봄
완화: 조직 정책으로 DoH/DoT 를 차단 (특정 IP/포트) + 사내 DNS 강제

2. Encrypted Client Hello (ECH)

TLS 1.3 확장. SNI 를 암호화해서 전송
Network Firewall 이 도메인을 못 알아냄
완화: ECH 사용 트래픽 차단 (미묘, 미래에 확산될 것)

3. IP 직접 접근

클라이언트가 도메인 없이 IP 로 접근 (https://1.2.3.4/)
SNI 없음 (SNI 는 선택적 확장이지만, 대부분 있음)
완화: SNI 없는 TLS 를 차단하는 stateful 규칙

4. Fronting (도메인 위장)

공격자가 SNI 에 legit.example.com 을 쓰고 실제로는 bad.example.com 로 요청 (CDN 뒤에서)
Legit CDN 은 실제 Host 헤더 기반 라우팅
완화: TLS Inspection 으로 실제 Host 확인 (성능/프라이버시 트레이드오프)

TLS Inspection (도메인 이상의 검사)

TLS 를 복호화해 내부 콘텐츠까지 검사. Network Firewall 이 관리형으로 지원 (2023+).

동작:

Network Firewall 이 자체 CA 인증서로 TLS 종단 (MITM)
클라이언트 → Firewall (Firewall CA 신뢰 필요)
Firewall → Server (기존 TLS)
사이에서 평문 검사

요구:

클라이언트가 Firewall CA 신뢰
인증서 관리 부담
SSL Pinning 하는 앱은 실패

의미: FQDN 필터링을 넘어 실제 페이로드까지 검사. 하지만 프라이버시/성능/관리 비용 증가.

FQDN 필터링 vs Route 53 Resolver DNS Firewall

AWS 는 두 가지 도메인 기반 방화벽을 제공. 원리가 다름.

축	Network Firewall FQDN	Route 53 Resolver DNS Firewall
작동 지점	TCP/TLS 트래픽 (연결 시도 시점)	DNS 조회 시점
감지 방법	HTTP Host / TLS SNI	DNS query 도메인
차단 방식	RST / drop packet	DNS 응답 조작 (NXDOMAIN)
암호화 DNS 우회	우회 가능	사내 DNS 강제 시 효과
적용 대상	VPC 를 지나는 모든 트래픽	VPC 안 DNS 요청
성능 부담	각 세션 SNI 파싱	DNS 조회당

조합 권장:

Route 53 DNS Firewall → 조회 자체 차단 (빠름, 근본적)
Network Firewall FQDN → DNS 로 해결된 후 실제 연결 시도 차단 (이중 방어)

Managed Domain List (AWS 제공)

AWS 가 유지하는 도메인 리스트 subscribe 가능:

MalwareDomainsActionOrder: 알려진 malware 배포 도메인
BotNetCommandAndControlDomainsActionOrder: C2 서버
AbusedLegitDomainsActionOrder: 남용되는 정상 도메인

자동 업데이트. 자체 관리 부담 감소.

Suricata 로 FQDN 규칙 직접 작성

Domain List 대신 Suricata 규칙으로 더 세밀한 제어.

# TLS SNI 정확 매칭
drop tls any any -> any 443 (msg:"Block bad site"; \
  tls.sni; content:"bad.example.com"; nocase; \
  sid:2001; rev:1;)

# HTTP Host 헤더 매칭 (서브도메인 포함)
drop http any any -> any 80 (msg:"Block subdomain"; \
  http.host; content:".malware.net"; endswith; nocase; \
  sid:2002; rev:1;)

# 조건부 (특정 소스만)
drop tls $INTERNAL_NET any -> any 443 (msg:"Internal client blocked"; \
  tls.sni; content:"gambling.site"; nocase; \
  sid:2003;)

관리형 Rule Groups (AWS)

AWS 제공, 자동 업데이트:

ThreatSignatures: 알려진 공격 시그니처
AttackVectors: OWASP Top 10 등
BotNetCommandAndControlDomains: C2 서버 도메인
MalwareDomains: 알려진 malware 배포 도메인
AbusedLegitDomains: 남용되는 정상 도메인

subscription 형식으로 정책에 포함.

관용 배포 패턴

Centralized Egress

Transit Gateway 뒤에 Inspection VPC 하나 두고 모든 VPC 의 인터넷 outbound 를 그 곳 통과:

VPC-A ─┐
VPC-B ─┼─→ Transit Gateway ─→ Inspection VPC (Network Firewall) ─→ Internet
VPC-C ─┘

여러 VPC 의 정책 중앙 관리 + 요금 절감.

Per-VPC Firewall

각 VPC 안 subnet 사이에 firewall endpoint. 소규모 조직.

East-West (VPC 내부)

같은 VPC 안 subnet 간 트래픽을 firewall 통과. Zero-trust 네트워크.

로깅

Firewall 이 생성하는 로그:

Alert logs: 규칙 alert 발생
Flow logs: 모든 flow 요약 (source, dest, action)
TLS logs: TLS handshake 정보 (SNI 등)

CloudWatch Logs / Kinesis / S3 로.

요금

Endpoint 시간당: AZ 마다 (~0.395 USD/hour)
트래픽 처리: GB 당 (~0.065 USD/GB)
관리형 규칙 그룹: 일부 무료, 일부 subscription

주의: 여러 AZ 배포 시 endpoint 요금 곱하기.

Network Firewall vs 대안

옵션	강점	언제
[[aws-sg-vs-nacl\|SG/NACL]]	무료, 간단, 대부분 케이스	기본
Network Firewall	Layer 7, IPS, 도메인 필터	컴플라이언스, 엔터프라이즈
[[aws-waf\|WAF]]	HTTP 특화 (URL, header)	웹 앱 앞단
[[aws-shield\|Shield]]	DDoS	볼륨 공격
3rd-party (Palo Alto, Fortinet)	종합 NGFW	기존 firewall 팀

결정: SG/NACL 로 부족 + DPI 필요 → Network Firewall.

Stateless Rules 상세

Stateful 보다 먼저 평가. 5-tuple 만 사용, 빠르고 저렴함.

# Stateless rule group 예시
StatelessRules:
  - Priority: 10
    RuleDefinition:
      MatchAttributes:
        Protocols: [6]       # TCP
        DestinationPorts:
          - FromPort: 443
            ToPort: 443
      Actions:
        - aws:forward_to_sfe   # Stateful engine 으로 전달
  - Priority: 20
    RuleDefinition:
      MatchAttributes:
        Sources:
          - AddressDefinition: 10.0.1.0/24   # 관리 서브넷
        DestinationPorts:
          - FromPort: 22
            ToPort: 22
        Protocols: [6]
      Actions:
        - aws:pass

전략: 간단 허용/차단 = Stateless 로 먼저 처리, DPI 필요 = aws:forward_to_sfe 로 Stateful 에 전달.

Centralized Egress 상세 아키텍처

flowchart LR
    A["VPC-A 워크로드"] --> TGW["Transit Gateway"]
    B["VPC-B 워크로드"] --> TGW
    C["VPC-C 워크로드"] --> TGW
    TGW --> INS["Inspection VPC<br/>Network Firewall"]
    INS -->|"허용 트래픽"| IGW["Internet Gateway"]
    INS -->|"차단 트래픽"| DROP["Drop"]

Route Table 핵심:

Inspection VPC firewall-subnet: IGW 로 가는 경로 → firewall endpoint
Inspection VPC public-subnet: 외부 → firewall endpoint
TGW attachment route: 스포크 VPC 트래픽 → Inspection VPC

CloudWatch Logs 쿼리

-- 상위 차단 시그니처 (Alert 로그)
fields @timestamp, alert.signature, src_ip, dest_ip
| filter event_type = "alert"
| stats count(*) as cnt by alert.signature
| sort cnt desc
| limit 20

-- 내부에서 외부로 나가는 차단 트래픽 (Flow 로그)
fields @timestamp, src_ip, dest_ip, dest_port, action
| filter action = "blocked"
| limit 100

Terraform 예시

resource "aws_networkfirewall_rule_group" "domain_denylist" {
  name     = "domain-denylist"
  type     = "STATEFUL"
  capacity = 100

  rule_group {
    rules_source {
      rules_source_list {
        generated_rules_type = "DENYLIST"
        target_types         = ["HTTP_HOST", "TLS_SNI"]
        targets              = ["bad.example.com", ".malware.net"]
      }
    }
  }
}

resource "aws_networkfirewall_firewall_policy" "main" {
  name = "main-policy"
  firewall_policy {
    stateless_default_actions          = ["aws:forward_to_sfe"]
    stateless_fragment_default_actions = ["aws:forward_to_sfe"]
    stateful_rule_group_reference {
      resource_arn = aws_networkfirewall_rule_group.domain_denylist.arn
    }
  }
}

함정

[!WARNING] Route table 설정 실수. Firewall endpoint 로 라우팅 안 되면 방화벽 우회.

[!CAUTION] 양방향 (return traffic). Stateful 이면 자동, stateless 는 규칙 명시.

[!WARNING] 비용 폭발 가능. GB 당 요금 + 다중 AZ endpoint. 필요한 트래픽만 필터.

[!IMPORTANT] TLS SNI 만 검사, decrypt 안 함. TLS 안 payload 는 안 보임. TLS inspection 은 별도 (3rd-party appliance).

[!CAUTION] Suricata 규칙 성능. 수천 규칙은 지연 증가. 관리형 규칙 그룹 우선.

[AWS] Organizations: 다중 계정 거버넌스

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Organizations 는 여러 AWS 계정을 하나의 조직으로 통합 관리 하는 서비스. 계정을 계층 (OU) 으로 묶고, 정책 (SCP, RCP, Tag, Backup, AI opt-out) 으로 가드레일을 부여하며, 통합 결제로 비용을 합산.

핵심 3가지:

통합 결제 (Consolidated Billing) - 볼륨 할인 합산, RI/Savings Plans 공유
OU (Organizational Unit) - 계층적 계정 그룹
정책 가드레일 - SCP (권한 상한), RCP (리소스 상한) 등

구성

Organization Root
├── Management Account (관리 계정, root user 소유)
│   └── (모든 정책 관리, SCP 적용 안 됨)
│
├── OU: Security
│   ├── LogArchive Account
│   └── Audit Account
│
├── OU: Prod
│   ├── prod-app-a Account
│   ├── prod-app-b Account
│   └── OU: Prod-Sandbox
│       └── prod-sandbox Account
│
└── OU: Dev
    ├── dev-team-a Account
    └── dev-team-b Account

Management Account: 조직 생성/정책 관리. SCP 미적용.
Member Account: SCP/RCP 등 정책 적용 대상.
OU: 최대 5단계 중첩 가능. 계정은 정확히 하나의 OU 에 속함.

SCP (Service Control Policy)

주체 (principal) 의 최대 권한을 정의하는 조직 정책.

// 특정 리전만 허용 (Deny list 전략)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "sts:*", "organizations:*",
        "cloudfront:*", "route53:*", "waf:*",   // 전역 서비스 제외
        "support:*", "trustedadvisor:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"]
        }
      }
    }
  ]
}

중요 특성:

권한을 부여하지 않는다 - 허용해도 [[aws-iam|IAM]] 허용이 별도로 필요
관리 계정에는 적용 안 됨
부착 대상: Root / OU / 계정
두 전략:
- Deny list (기본): FullAWSAccess + 특정 Deny
- Allow list: 명시 허용만

대표 시나리오:

특정 리전 사용 원천 차단 (aws:RequestedRegion)
루트 사용자 특정 작업 금지
특정 서비스 전면 차단
태그 없는 리소스 생성 금지

RCP (Resource Control Policy)

리소스 (resource) 의 최대 권한을 정의하는 조직 정책 (2024 도입).

// 특정 계정 이외의 principal 이 버킷 정책으로 접근 못 하도록
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceOrgIdentities",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "o-xxx"
        }
      }
    }
  ]
}

SCP vs RCP:

SCP = 계정 안의 IAM principal (누가) 의 상한
RCP = 계정 안의 resource (무엇에) 의 상한

대표 시나리오:

OU 전체 S3 버킷이 실수로 퍼블릭 되지 않도록
조직 밖 principal 의 KMS 키 사용 차단
특정 리소스 태그 없이 접근 금지

정책 평가 로직 (핵심)

여러 정책이 얽힐 때 허용/거부 결정 순서:

① 명시적 Deny 확인 → 있으면 즉시 거부 (short-circuit)
② RCP (조직 리소스 상한) → 통과해야 함
③ SCP (조직 계정 상한) → 통과해야 함
④ 리소스 기반 정책 → 허용 확인
⑤ 자격 증명 기반 정책 → 허용 확인
⑥ 권한 경계 → 통과해야 함
⑦ 세션 정책 → 통과해야 함
→ 최종: Deny 없고 + 최소 하나의 Allow + 모든 상한 통과 → 허용

대원칙:

명시적 Deny > 명시적 Allow > 암묵적 Deny
부여 정책 (identity + resource-based) = 합집합
상한 정책 (SCP, RCP, boundary, session) = 교집합

자세히: [[aws-iam|IAM]] 정책 평가.

정책 종류 비교

정책	부착 대상	권한 부여?	범위
자격 증명 기반	사용자/그룹/역할	O	개별 주체
리소스 기반	S3, SQS, KMS 등	O + 교차 계정	리소스
권한 경계	사용자/역할	X (상한만)	개별 주체
SCP	Root/OU/계정	X (상한만)	계정 내 모든 주체
RCP	Root/OU/계정	X (상한만)	계정 내 모든 리소스
세션 정책	역할 수임 세션	X (상한만)	임시 세션

[!IMPORTANT] 권한을 부여 하는 것은 자격 증명/리소스 기반 정책뿐. 나머지는 상한만 정하고 권한을 주지 않음.

조직 정책 종류

정책 유형	목적
SCP	주체 권한 상한
RCP	리소스 정책 상한 (2024+)
Tag Policy	태그 표준화 (강제 태그, 값 형식)
Backup Policy	AWS Backup 정책 중앙 관리
AI Services Opt-out	AI 서비스가 데이터를 학습에 사용 못하게
Chatbot Policy	AWS Chatbot 사용 제어 (2024+)
Declarative	EC2 IMDSv2 강제 등 서비스별 선언 (2024+)

통합 결제 (Consolidated Billing)

모든 멤버 계정 청구서 통합
볼륨 할인 자동 합산 ([[aws-s3|S3]] 등 계층 할인)
RI (Reserved Instance) 와 Savings Plans 자동 공유
세금 목적 개별 계정 청구서도 확인 가능

AWS Control Tower

Organizations 기반으로 랜딩 존 (landing zone) 을 모범 사례대로 자동 구성.

포함:

Organizations + OU 계층 (Security, Prod, Sandbox 등)
[[aws-cloudtrail|CloudTrail]] 조직 전체 활성화
[[aws-config|AWS Config]] 규칙 배포
LogArchive 계정 + Audit 계정 자동 프로비저닝
가드레일 (Preventive = SCP / Detective = Config Rule) 세트

결과: 신규 계정 (Account Factory) 을 요청하면 자동으로 표준 규칙 적용된 상태로 생성.

서비스 활성화 (Trusted Access)

조직 안에서 여러 서비스가 계정 간 통합되도록 위임:

서비스	조직 통합 시
[[aws-cloudtrail\|CloudTrail]]	조직 전체 trail 생성 (모든 계정 이벤트 수집)
[[aws-config\|Config]]	조직 전체 규칙/aggregator
AWS Backup	정책 중앙 관리
GuardDuty	Delegated Admin 이 조직 전체 관리
Security Hub	조직 전체 통합 대시보드
[[aws-iam\|IAM]] Identity Center	중앙 SSO
AWS RAM	조직 내 리소스 공유 자동 승인
Service Catalog	조직 전체 포트폴리오 공유

Delegated Administrator (위임 관리)

관리 계정을 최소한으로 유지하기 위해, 서비스별 관리를 다른 계정에 위임.

Management Account (관리 계정)
   └── Delegated Admin
       ├── Security Hub → Audit Account
       ├── GuardDuty → Audit Account
       ├── Config Aggregator → Audit Account
       └── Cost & Usage → Finance Account

일상 운영을 관리 계정에서 안 해도 되어 보안 위험 감소.

계정 라이프사이클

Account Factory (Control Tower) / CreateAccount API 로 프로비저닝
Root 이메일/이름 지정
자동으로 조직 가입, 지정된 OU 로 이동
SCP/RCP 자동 상속
삭제/이관은 별도 API + 이관 절차

함정

[!WARNING] SCP 는 관리 계정에 적용 안 됨. 관리 계정에서 위험한 작업이 가능. 관리 계정은 최소 사용, 위임 관리자 활용.

[!CAUTION] SCP 는 권한을 부여하지 않는다. Allow 만 있는 SCP 는 아무 일도 안 일어남 (가드레일일 뿐, IAM Allow 별도 필요).

[!WARNING] 명시적 Deny 는 무엇으로도 못 뒤집는다. SCP/RCP/경계/리소스/자격 증명 어디든 Deny 가 있으면 그대로 거부.

[!IMPORTANT] 전역 서비스 (IAM, CloudFront, Route53) 는 리전 제약 SCP 에서 예외 처리 필요. 안 하면 IAM 조작 자체가 막힐 수 있음.

[!CAUTION] OU 최대 5단계 중첩. 지나치게 깊은 계층은 관리 부담. 보통 2-3 단계 (Environment / Business Unit).

[!WARNING] RCP 는 신규 (2024+). 지원 서비스 목록 확인 필수 ([[aws-s3|S3]], [[aws-sqs|SQS]], KMS, Secrets Manager, STS 부터 확장 중).

[!IMPORTANT] Control Tower 로 만든 랜딩 존을 임의 수정 = 다음 업데이트에서 롤백. 커스터마이징은 Account Factory Customization Framework (AFT) 로.

[AWS] Public Subnet vs Private Subnet

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Public Subnet 과 Private Subnet 은 [[aws-vpc|VPC]] 의 서브넷 유형 이름 같지만, 사실은 서브넷 자체의 속성이 아니라 라우트 테이블 (Route Table) 구성에 따른 결과적 분류.

Public Subnet: 라우트 테이블에 0.0.0.0/0 → Internet Gateway 라우트가 있는 서브넷
Private Subnet: 그런 라우트가 없는 서브넷 (인터넷 직접 접근 불가)

한 줄 요약: “Public / Private” 은 AWS API 나 서브넷 속성이 아니라, 라우트 테이블 설정으로 결정되는 관습적 분류.

왜 이 분류가 관습이 되었나

전통 3-tier 웹 아키텍처의 보안 원칙:

인터넷에 노출되는 것은 최소한만 (ALB, bastion 등)
실제 앱 서버, DB 는 인터넷에서 직접 접근 불가
앱 서버가 필요할 때만 outbound 로 인터넷 접근 (패키지 설치 등)

이 요구를 만족하려면 서브넷을 인터넷 접근 가능 / 불가능 두 그룹으로 나눠 다르게 라우팅. AWS 커뮤니티가 각각 “public subnet”, “private subnet” 이라고 부르기 시작한 것.

중요: AWS 콘솔의 서브넷 리소스에는 “public” / “private” 이라는 필드가 없다. 라우트 테이블 확인이 유일한 판별 방법.

Public Subnet 조건 (모두 만족해야)

인스턴스가 실제로 인터넷과 통신하려면:

VPC 에 Internet Gateway 부착
서브넷의 라우트 테이블에 0.0.0.0/0 → IGW 라우트 존재
인스턴스에 Public IPv4 또는 Elastic IP 부여
Security Group 이 인바운드/아웃바운드 허용
NACL 도 허용

이 5가지 중 하나라도 빠지면 인터넷 통신 안 됨. 흔한 실수: IGW 붙이고 라우트도 넣었지만 EC2 에 Public IP 가 없어서 접근 실패.

Auto-assign Public IP

서브넷 속성 MapPublicIpOnLaunch:

True: 이 서브넷에서 시작한 EC2 는 자동으로 Public IPv4 할당
False: 명시적 지정 필요 (또는 EIP 부착)

Default VPC 의 기본 서브넷: MapPublicIpOnLaunch = True (편의) 신규 커스텀 VPC 의 서브넷: False (안전)

Private Subnet 의 인터넷 접근

Private subnet 안 EC2 도 outbound 로 인터넷 접근이 필요한 경우 흔함:

OS 패키지 업데이트 (apt update, yum update)
Docker 이미지 pull
외부 API 호출 (Stripe, SendGrid 등)

해결책 4가지 (트레이드오프 있음):

1. NAT Gateway (표준)

Private Subnet 라우트 테이블:
  10.0.0.0/16 → local
  0.0.0.0/0 → NAT Gateway (public subnet 안)

NAT Gateway 라우트 테이블 (자기가 있는 public subnet):
  0.0.0.0/0 → IGW

Public subnet 안에 NAT Gateway 배치
Private subnet → NAT Gateway → IGW → 인터넷
인터넷 → private subnet 은 여전히 불가 (unsolicited inbound 차단)
요금: 시간당 + GB 처리 (누적 가능)

2. NAT Instance (레거시)

EC2 인스턴스 하나를 NAT 역할로 (source/dest check 비활성). 옛 방식. 신규는 NAT Gateway 사용.

3. VPC Endpoint (인터넷 우회)

AWS 서비스 접근만 필요하면 인터넷 대신 [[aws-vpc-endpoints|VPC Endpoint]]:

S3, DynamoDB → Gateway Endpoint (무료)
KMS, ECR, SSM 등 → Interface Endpoint

4. Egress-only Internet Gateway (IPv6 전용)

IPv6 에는 NAT 개념이 없음. 대신 “egress-only IGW” 로 outbound 만 허용.

아키텍처 (표준 3-tier)

flowchart TB
    Internet[인터넷]

    subgraph VPC["VPC (10.0.0.0/16)"]
        IGW["Internet Gateway"]

        subgraph AZa["AZ-a"]
            subgraph PubA["Public Subnet A<br/>10.0.1.0/24"]
                ALB1["ALB Node"]
                NAT["NAT Gateway"]
            end
            subgraph PrivAppA["Private App Subnet A<br/>10.0.11.0/24"]
                App1["App EC2"]
            end
            subgraph PrivDBA["Private DB Subnet A<br/>10.0.21.0/24"]
                DB1["RDS Primary"]
            end
        end

        subgraph AZb["AZ-b"]
            subgraph PubB["Public Subnet B<br/>10.0.2.0/24"]
                ALB2["ALB Node"]
            end
            subgraph PrivAppB["Private App Subnet B<br/>10.0.12.0/24"]
                App2["App EC2"]
            end
            subgraph PrivDBB["Private DB Subnet B<br/>10.0.22.0/24"]
                DB2["RDS Standby"]
            end
        end
    end

    Internet <--> IGW
    IGW <--> ALB1
    IGW <--> ALB2

    ALB1 --> App1
    ALB2 --> App2

    App1 --> DB1
    App2 --> DB1

    App1 -.->|"outbound<br/>인터넷"| NAT
    App2 -.-> NAT
    NAT --> IGW

세 계층의 역할:

Public Subnet (ALB, NAT Gateway, bastion): 인터넷과 직접 통신. 최소 리소스만.
Private App Subnet (EC2, ECS, Lambda): ALB 뒤 애플리케이션. Outbound 인터넷은 NAT 로.
Private DB Subnet (RDS, ElastiCache): 앱 서버만 접근. Outbound 도 대개 불필요.

라우트 테이블의 차이 (핵심)

Public Subnet 라우트 테이블:

Destination        Target
10.0.0.0/16        local
0.0.0.0/0          igw-abc123      ← Internet Gateway

Private Subnet 라우트 테이블 (NAT 있음):

Destination        Target
10.0.0.0/16        local
0.0.0.0/0          nat-xyz789      ← NAT Gateway (public subnet 안)

Private Subnet 라우트 테이블 (NAT 없음):

Destination        Target
10.0.0.0/16        local
                   (0.0.0.0/0 라우트 없음)

Private Subnet 은 정말 격리인가

주의: “Private Subnet 이면 안전하다” 는 오해.

Private subnet 안 EC2 도 다음이면 접근 가능:

다른 VPC ([[aws-vpc|VPC]] Peering / Transit Gateway 로 연결됨)
온프레미스 (Direct Connect / VPN 으로 연결됨)
VPC 내부 다른 서브넷 (라우트 + SG 가 허용)

격리는 Security Group / NACL 로 명시적 통제. Private subnet 만으로는 보안 완결 X.

서브넷 크기 계획

AWS 는 서브넷 앞 4개 + 마지막 1개 IP 를 예약:

서브넷 IP	용도
`.0`	네트워크 주소
`.1`	VPC router
`.2`	AWS DNS
`.3`	미래 사용 예약
`.255` (마지막)	브로드캐스트

예: 10.0.1.0/24 (256 IP) → 실제 사용 가능 251 IP

크기 결정:

/28 (16 IP) - 매우 작음, 실 사용 11개. VPC endpoint 서브넷 등
/24 (256 IP) - 작은 서브넷. 소규모 앱
/22 (1024 IP) - 중간. 대부분 워크로드
/20 (4096 IP) - Default VPC 서브넷 크기
/16 - VPC CIDR 상한 (서브넷은 /16 불가, 최대 /16 은 VPC 자체)

Kubernetes / EKS: Pod 마다 IP 소비 → 큰 서브넷 (/22 이상) 권장.

명명 관례

AWS 공식 이름은 없지만 관용:

<env>-public-<az> (예: prod-public-1a, prod-public-1b)
<env>-private-app-<az>
<env>-private-db-<az>

Terraform / CloudFormation 에서 tag 로 구분:

Tags:
  - Key: Tier
    Value: public / private-app / private-db
  - Key: Name
    Value: prod-private-app-1a

함정

[!WARNING] “Public / Private” 은 서브넷 속성이 아님. 라우트 테이블만이 진실. 헷갈리면 서브넷의 route table 을 실제 확인.

[!CAUTION] Public IP 없이 Internet Gateway 있는 서브넷 = 인터넷 통신 안 됨. IGW 라우트만으로는 부족, Public IPv4 / EIP 필요.

[!WARNING] NAT Gateway 는 public subnet 에 배치. Private subnet 에 NAT 를 놓으면 자기가 인터넷 접근 못함.

[!IMPORTANT] NAT Gateway 는 AZ 단위. HA 를 위해 각 AZ 마다 별도 NAT 배치. 하나에 몰면 그 AZ 장애 시 전체 outbound 마비 + 크로스 AZ 요금.

[!CAUTION] Private subnet 만으로 격리 완결 아님. 다른 VPC / 온프렘 / 같은 VPC 접근 가능성. SG / NACL 로 명시적 통제.

[!WARNING] AWS 예약 5개 IP 를 잊고 /28 로 만들면 실 사용 11개. 큰 서브넷 필요 시 /28 지양.

[!IMPORTANT] VPC Endpoint 로 상당 부분 NAT 대체 가능. S3 / DynamoDB / KMS / ECR 등이 주 outbound 이면 endpoint 로 NAT 요금 절감.

[AWS] Redshift ML

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Redshift ML 은 SQL 문 (CREATE MODEL) 만으로 머신러닝 모델을 학습, 배포, 추론 하는 기능. 데이터를 Redshift 밖으로 옮기지 않고 학습이 가능하며, 내부적으로 SageMaker Autopilot 이 최적 알고리즘 선택과 하이퍼파라미터 튜닝을 자동 수행. 학습된 모델은 Redshift 안에서 SQL 함수 로 등록되어 SELECT 안에서 그대로 호출된다.

핵심 통찰: 데이터 사이언티스트가 없어도, SQL 만 아는 애널리스트가 ML 을 사용할 수 있다.

왜 Redshift ML

전통적 ML 흐름의 문제:

1. 데이터를 [[aws-redshift|Redshift]] 에서 export
2. [[aws-s3|S3]] 에 저장
3. SageMaker notebook 에서 데이터 로드
4. 특징 엔지니어링 (Python, pandas)
5. 알고리즘 선택 + 학습
6. 모델 배포 (endpoint or Lambda)
7. 예측 결과를 다시 Redshift 로 가져오기

문제:

7 단계, 여러 팀 걸침
데이터 이동 시 지연 + 보안 문제
애널리스트가 SQL 이외 접근 어려움
결과 다시 저장하는 파이프라인

Redshift ML 의 답:

1. CREATE MODEL FROM (SELECT ... FROM warehouse) TARGET churned
   → 자동 학습 + 배포 (SQL 한 번)
2. SELECT predict_churn(...) FROM customers  → 즉시 예측

아키텍처

flowchart LR
    subgraph Redshift["Redshift Cluster / Serverless"]
        User[SQL 사용자]
        CM["CREATE MODEL"]
        UDF["ML 함수<br/>(predict_churn 등)"]
        Data[("데이터 테이블")]
    end

    subgraph AWS_ML["AWS ML 백엔드"]
        S3[("S3 (training data)")]
        Autopilot[SageMaker Autopilot]
        Deploy["모델 artifact<br/>(로컬 or endpoint)"]
    end

    User -->|"SQL"| CM
    CM -->|"export"| S3
    S3 --> Autopilot
    Autopilot -->|"학습 + 최적 알고리즘 선택"| Deploy
    Deploy -->|"UDF 로 등록"| UDF

    User -->|"SELECT predict_churn(row)"| UDF
    UDF --> Data

단계:

CREATE MODEL 실행 → 학습 데이터를 [[aws-s3|S3]] 로 export
SageMaker Autopilot 이 알고리즘 선택 + 하이퍼파라미터 튜닝
학습 완료 → 모델 artifact 저장
Redshift 안에 SQL UDF 로 등록
이후 사용자가 SELECT predict_xxx(cols) 로 그대로 호출

모델 유형

1. AUTO (Autopilot 완전 자동)

가장 흔한 선택. 문제 유형 파악부터 알고리즘, 하이퍼파라미터까지 자동.

CREATE MODEL customer_churn
FROM (
  SELECT age, tenure, monthly_charges, total_charges, ..., churned
  FROM customers
  WHERE churn_flag_known = TRUE
)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (
  S3_BUCKET 'my-redshift-ml',
  MAX_RUNTIME 3600  -- 학습 최대 1시간
);

자동 판단: 이진 분류, 다중 분류, 회귀
자동 선택: XGBoost, MLP, Linear Learner
자동 튜닝: HyperParameter Optimization
자동 검증: hold-out 셋으로 성능 측정

2. User-guided (알고리즘 지정)

성능이 예측 가능해야 할 때 알고리즘/하이퍼파라미터 직접 지정.

CREATE MODEL customer_churn_xgb
FROM (SELECT ... FROM customers)
TARGET churned
FUNCTION predict_churn_xgb
MODEL_TYPE XGBOOST
OBJECTIVE 'binary:logistic'
HYPERPARAMETERS DEFAULT EXCEPT (
    NUM_ROUND '200',
    ETA '0.1',
    MAX_DEPTH '6'
)
IAM_ROLE default
SETTINGS (S3_BUCKET 'my-bucket');

지원 알고리즘: XGBoost, MLP, Linear Learner, K-means (클러스터링).

3. BYOM (Bring Your Own Model)

외부에서 이미 학습한 SageMaker 모델을 Redshift 에서 호출.

Local Inference (Redshift 안에서):

CREATE MODEL my_own_model
FROM 'arn:aws:sagemaker:us-east-1:123:model/my-trained-xgb'
FUNCTION my_predict
IAM_ROLE default;

XGBoost, MLP, Linear Learner 만 로컬 추론 가능
Redshift 컴퓨트에서 직접 실행 -> 저지연

Remote Inference (SageMaker endpoint 호출):

CREATE MODEL remote_model
FUNCTION predict_remote(bigint, varchar, double)
RETURNS double
SAGEMAKER 'my-sagemaker-endpoint'
IAM_ROLE default
SETTINGS (MAX_BATCH_ROWS 100);

임의 알고리즘 (Python, PyTorch, TF 등) 사용 가능
호출당 SageMaker endpoint 요금 + 지연 (~ms-100ms)

4. LLM / Foundation Model (Bedrock 연동)

Amazon Bedrock 의 LLM 을 SQL 로 호출.

CREATE EXTERNAL MODEL llm_summarizer
FUNCTION summarize_text(varchar)
RETURNS varchar
IAM_ROLE default
MODEL_TYPE BEDROCK
SETTINGS (
  MODEL_ID 'anthropic.claude-v2:1',
  PROMPT 'Summarize the following text in one sentence: '
);

-- 사용
SELECT article_id, summarize_text(body) AS summary
FROM articles;

RESPONSE_TYPE: VARCHAR (단순 텍스트) 또는 SUPER (구조화된 응답).

용도:

텍스트 요약, 번역, 분류
감정 분석
임베딩 생성 (Bedrock Titan Embeddings)
RAG 파이프라인 (Redshift 데이터를 프롬프트 컨텍스트로)

SUPER 데이터 타입 활용

SUPER 는 Redshift 의 반정형 데이터 타입 (JSON-like). LLM 응답이나 복잡한 predict 입력에 유용.

-- LLM 응답을 SUPER 로 받아 구조화 필드 추출
SELECT article_id,
       llm_analyze(body).sentiment  AS sentiment,
       llm_analyze(body).topics     AS topics,
       llm_analyze(body).confidence AS confidence
FROM articles;

추론 성능

방식	지연	상황
Local (AUTO / XGBoost 등)	마이크로초 - 밀리초	대량 배치 예측
Remote (SageMaker endpoint)	수십 - 수백 ms	커스텀 알고리즘
Bedrock (LLM)	수백 ms - 초	LLM 태스크

배치 vs 단건:

SELECT predict(...) FROM huge_table -> 각 행마다 함수 호출, 병렬 실행
로컬 추론이면 매우 빠름 (Redshift 컴퓨트에서 직접)
원격 추론이면 batch 조율 필요 (MAX_BATCH_ROWS)

모델 관리

-- 모델 목록
SHOW MODEL ALL;

-- 특정 모델 상세
SHOW MODEL customer_churn;

-- 모델 삭제
DROP MODEL customer_churn;

-- 모델 상태 (학습 진행 중, 성공, 실패)
SELECT model_name, model_state, function_name, training_start_time
FROM SVV_ML_MODEL_INFO;

활용 사례

시나리오	모델 유형
이탈 예측 (Churn Prediction)	AUTO (이진 분류)
매출 예측 (Forecasting)	AUTO (회귀)
고객 세분화 (Segmentation)	User-guided (K-means)
부정 거래 감지 (Fraud)	AUTO 또는 BYOM (unbalanced 클래스)
추천 (LTV, Next best action)	User-guided (XGBoost regression)
텍스트 요약	Bedrock (LLM)
감정 분석	Bedrock 또는 SageMaker 커스텀
이미지 분류	BYOM Remote (SageMaker endpoint)

사용 예: 이탈 예측 파이프라인

-- 1. 모델 학습 (한 번)
CREATE MODEL customer_churn
FROM (
  SELECT
    age, tenure_months, monthly_charges,
    contract_type, payment_method,
    total_gb_used, support_tickets_count,
    churned  -- 라벨
  FROM analytics.churn_training_data
  WHERE observation_date < '2025-01-01'
)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'my-ml', MAX_RUNTIME 7200);

-- 2. 학습 완료 확인 (Autopilot 30분 - 몇 시간)
SHOW MODEL customer_churn;

-- 3. 예측 (매일 실행 가능)
CREATE TABLE churn_scores AS
SELECT
  customer_id,
  predict_churn(age, tenure_months, monthly_charges,
                contract_type, payment_method,
                total_gb_used, support_tickets_count) AS churn_probability
FROM customers
WHERE is_active = TRUE;

-- 4. 하위 시스템으로 전달 (예: 마케팅)
SELECT customer_id FROM churn_scores
WHERE churn_probability > 0.7
ORDER BY churn_probability DESC;

요금

학습: SageMaker Autopilot 학습 시간 (수 분 - 수 시간) × SageMaker 요금
로컬 추론: Redshift 컴퓨트 (기존 쿼리 비용에 포함)
원격 추론: SageMaker endpoint 시간 + 호출당 요금
Bedrock LLM: Bedrock 요금 (토큰당)
저장: S3 (모델 artifact)

함정

[!WARNING] AUTO 모드 학습 시간 예측 어려움. MAX_RUNTIME 을 설정해 폭주 방지 (기본 5400 초).

[!CAUTION] 원격 추론 (SageMaker endpoint) 은 매 예측마다 endpoint 호출. 대량 배치에는 로컬 추론 가능한 알고리즘 (XGBoost 등) 이 훨씬 저렴/빠름.

[!WARNING] 불균형 라벨 (예: 이탈 5%) 은 AUTO 가 자동 처리하지만, 검증 지표 (F1, AUC) 확인 필수. Accuracy 만 보면 오해.

[!IMPORTANT] Feature engineering 은 사전 SQL 로. Redshift ML 은 raw 데이터 -> 예측이 목적이므로, 복잡한 특징은 WITH / view 로 미리 만들어 놓기.

[!CAUTION] Bedrock LLM 은 토큰당 과금. 대량 처리 시 비용 폭탄. 샘플링 / 결과 캐시 필수.

[!WARNING] 모델 재학습 자동 아님. 데이터 drift 시 수동 CREATE MODEL 재실행. Airflow 등으로 스케줄링.

[!IMPORTANT] BYOM 로컬 추론은 지원 알고리즘 제한 (XGBoost, MLP, Linear Learner). 그 외는 원격 추론.

[AWS] Redshift Serverless

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon Redshift Serverless 는 [[aws-redshift|Redshift]] 를 클러스터 프로비저닝 없이 사용 하는 방식. 컴퓨트 (RPU) 가 워크로드에 맞춰 자동 확장/축소되며, 유휴 시 요금이 없다. 스토리지는 [[data-warehouse|DW]] 를 위한 관리형 계층 (RMS, Redshift Managed Storage) 이 [[aws-s3|S3]] 위에 별도로 존재한다.

한 줄 요약: 워크로드 예측 불가 / 스파이키 / 개발 및 애드혹 상황에서 클러스터 관리 부담 없이 [[mpp|MPP]] 를 이용.

왜 Serverless 인가

전통 Provisioned Redshift 의 문제:

유휴 시에도 인스턴스-시간 요금 (24 시간 켜져 있으면 그만큼)
트래픽 급증 시 수동으로 노드 추가 필요 (수 분 프로비저닝)
워크로드 관리 (WLM) 튜닝 부담
cluster resize 는 read-only 시간 발생

Serverless 의 해결:

초 단위 과금 (RPU-hour, 실제 실행 시간만)
자동 확장 (RPU 상한 안에서)
WLM 자동 (수동 튜닝 불필요)
유휴 시 0 원

아키텍처

flowchart TB
    Client["BI / JDBC / redshift-data API"]

    subgraph Namespace["Namespace<br/>(데이터베이스 + 스키마 + 오브젝트 + 사용자)"]
        DB1[("dev DB")]
        DB2[("analytics DB")]
        Users["Users / Roles"]
    end

    subgraph Workgroups["Workgroups (컴퓨트)"]
        WG1["Workgroup 'etl'<br/>Base 32 RPU, Max 512"]
        WG2["Workgroup 'bi'<br/>Base 16 RPU, Max 256"]
    end

    Client -->|"endpoint 접속"| WG1
    Client -->|"endpoint 접속"| WG2

    WG1 -.->|"쿼리 대상"| Namespace
    WG2 -.->|"쿼리 대상"| Namespace

    Namespace --> RMS[("Redshift Managed Storage<br/>(S3 위에 구축, SSD 캐시)")]

Namespace (논리적 저장 + 사용자)

데이터베이스 / 스키마 / 테이블 / 사용자 / 권한 의 논리 그룹.

Snapshot / 복원 / KMS 암호화 / [[aws-iam|IAM]] role 이 여기에 붙음
하나의 namespace 는 여러 workgroup 이 공유 가능
삭제 시 데이터 손실 (백업 별도)

Workgroup (컴퓨트 설정)

RPU 용량 + 네트워크 (VPC/보안 그룹) + 엔드포인트 설정 등 컴퓨트 관련 설정.

하나의 namespace 에 여러 workgroup (ETL 용 / BI 용 분리)
workgroup 마다 base capacity, max capacity, 사용량 한도 별도

분리 이유: 같은 데이터에 대해 워크로드별로 다른 컴퓨트 정책 적용.

RPU (Redshift Processing Unit)

Redshift Serverless 요금의 기본 단위.

1 RPU ≈ 소량의 CPU + 메모리 + 네트워크 조합 (구체 스펙 비공개, AWS 관리)
Base capacity: 워크그룹의 최소 RPU (기본 8, 최소 8, 최대 512)
Max capacity: 자동 확장 상한
실제 실행 초 단위로 과금

Base capacity 선택 감각

Base RPU	성격	대상
8	최소 (개발/테스트, 매우 작은 워크로드)	실험
16-32	기본 프로덕션	소-중규모
64-128	중대형 (concurrent 사용자 다수)	팀 BI
256-512	대형 배치 / 데이터 사이언스	대기업

[!IMPORTANT] Base 가 너무 낮으면 첫 쿼리 지연 (급격한 스케일 업 필요). 프로덕션은 최소 16-32 부터 시작 후 사용 패턴 관찰.

자동 확장 (Auto-Scaling)

Serverless 는 두 가지 방향으로 자동 확장.

1. Base 넘어서 위로 (concurrency scaling)

동시 쿼리 부하가 base capacity 를 초과하면 자동으로 추가 RPU 할당 (max capacity 까지).

판단 기준: 큐 길이, 예상 실행 시간, 자원 대기 시간
확장 속도: 초 단위
축소: 유휴 감지 후 자동으로 base 로 복귀

2. AI-driven Scaling (2024+)

과거 워크로드 패턴을 학습해 쿼리 시작 전에 미리 확장. Cold query 지연 감소.

결과: 사용자는 base/max 만 정하고, 실제 확장은 완전 자동.

요금 모델

총 요금 =
    (실행된 RPU 초당 요금)
  + (RMS 저장 요금, GB-월)
  + (Concurrency Scaling / Spectrum / Zero-ETL 등 별도)

과금 특징:

초 단위 (최소 60 초): 짧은 쿼리 여러 개도 정확히
base RPU × 실행 시간: 유휴는 청구 X
compute 와 storage 분리 청구: 저장 요금은 실행 여부 무관

계산 예 (us-east-1, 2026 대략):

Base 16 RPU × $0.375/RPU-hour × 하루 8 시간 실행 × 30일
= 16 × 0.375 × 8 × 30 = $1,440 /월

+ RMS 스토리지 500 GB × $0.024/GB-월 = $12
= 총 ~$1,452 /월

Provisioned RA3 대비:

하루 24 시간 균등 부하 -> Provisioned 저렴할 수 있음
하루 8 시간 스파이키 -> Serverless 저렴

RMS (Redshift Managed Storage)

Serverless / RA3 의 공통 스토리지 계층. [[aws-s3|S3]] 위에 구축된 컬럼형 저장소.

동작:

Hot 데이터: 로컬 SSD 캐시
Cold 데이터: S3 tiered
사용자는 계층 관리 불필요 (자동)
저장 요금은 실제 GB 사용량 기반

이점:

컴퓨트와 스토리지 독립 확장
스토리지 사실상 무제한
유휴 컴퓨트에도 데이터 유지 (Serverless 유휴 = 저장만 청구)

자세히: [[mpp|MPP]] “현대 MPP: Compute-Storage 분리”.

Serverless 도 Data Sharing 완전 지원.

다른 namespace / 다른 계정 / 다른 리전과 데이터 공유 (복사 없음)
Producer + Consumer 모델
각자 자기 컴퓨트로 쿼리, 데이터는 물리적으로 한 곳

활용:

팀 A 는 ETL workgroup, 팀 B 는 BI workgroup 이 같은 데이터 공유
개발 계정과 프로덕션 계정 간 데이터 공유

Provisioned RA3 vs Serverless

축	RA3 Provisioned	Serverless
워크로드	예측 가능한 지속 부하	스파이키, 간헐적
비용 최적	Reserved Instance 로 저렴	사용량 기반
관리	Cluster 관리 필요	AWS 자동
WLM	Manual + Auto	Auto only
유휴 요금	인스턴스-시간 지속	0 (base 는 실행 시만)
확장 속도	수 분 (resize)	초 단위
동시 사용자	Concurrency Scaling 별도	자동
최소 크기	노드 단위	8 RPU

결정 규칙:

새 프로젝트, 워크로드 미지수 -> Serverless 부터
하루 24 시간 균등 heavy 부하 -> Provisioned RA3 + RI (비용 30-70% 절감)
개발 / 테스트 / 애드혹 -> Serverless

사용 사례

1. Ad-hoc + 정기 배치 혼재

낮 (BI 대시보드) : ~30 개 동시 쿼리
저녁 (ETL 배치) : 대용량 스캔 4시간
새벽             : 유휴

Serverless 가 각 상황에 맞춰 자동 확장 + 유휴 절약.

프로듀서가 Provisioned, 컨슈머는 Serverless. 컨슈머는 저장 비용 없이 컴퓨트만.

3. 개발 / 테스트

프로덕션은 Provisioned 로 저렴하게, 개발 팀은 각자 Serverless workgroup.

성능 / 요금 관리

사용량 한도 (Usage Limits)

aws redshift-serverless create-usage-limit \
  --resource-arn arn:aws:redshift-serverless:...:workgroup/bi \
  --usage-type serverless-compute \
  --amount 500 \
  --period monthly \
  --breach-action log  # log / emit-metric / deactivate

월/주/일 RPU-hour 한도
초과 시 알림 / 워크그룹 비활성화
비용 폭탄 방지 필수

쿼리 모니터링

-- 최근 쿼리와 사용된 RPU
SELECT query_id, database_name, query_text,
       compute_seconds, compute_capacity
FROM SYS_QUERY_HISTORY
WHERE start_time > SYSDATE - 1
ORDER BY compute_seconds DESC LIMIT 20;

-- 워크그룹 사용량
SELECT * FROM SYS_SERVERLESS_USAGE
WHERE start_time > SYSDATE - 7;

통합

기능	Serverless 지원
[[aws-redshift-spectrum\|Spectrum]] (S3 외부 테이블)	O
[[aws-redshift\|Redshift]] Streaming Ingestion	O
Data Sharing	O (producer + consumer)
Zero-ETL (Aurora / RDS / DynamoDB)	O
[[aws-redshift-ml\|Redshift ML]]	O
Federated Query ([[postgresql\|Postgres]], MySQL)	O
VPC-only	O
[[aws-lake-formation\|Lake Formation]]	O

함정

[!WARNING] Base RPU 너무 낮음 = 첫 쿼리 지연 + 스케일 업 오버헤드. 프로덕션은 최소 16-32 부터.

[!CAUTION] Max capacity 무제한 설정 = 예상 밖 비용. Usage Limit 필수.

[!WARNING] Namespace 삭제 시 데이터 손실. 삭제 전 최종 snapshot.

[!IMPORTANT] Serverless 는 시간 균등 heavy 워크로드에 오히려 비쌈. RI 를 활용한 Provisioned RA3 가 30-70% 저렴할 수 있음. 예측 후 선택.

[!CAUTION] Cold query 지연. 오래 유휴 후 첫 쿼리는 스케일 업 시간 (수 초). AI-driven scaling 이 완화 중.

[!WARNING] Workgroup / Namespace 개념 혼동. Namespace = 저장 + 사용자, Workgroup = 컴퓨트 설정. 하나의 namespace 를 여러 workgroup 이 공유.

[AWS] Redshift Spectrum: S3 데이터 직접 쿼리

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Redshift Spectrum 은 [[aws-redshift|Redshift]] 에서 S3 에 있는 데이터를 로드하지 않고 직접 SQL 로 쿼리 하는 기능. 별도 Spectrum 실행 계층 (Spectrum layer) 이 S3 스캔/필터를 수행하고, 결과를 Redshift 컴퓨트로 넘겨 aggregation/join.

핵심 이점: 페타바이트 S3 데이터에 대해 Redshift 를 확장하지 않고도 쿼리. Cold 데이터는 S3 에, hot 데이터는 Redshift 내부에 두는 [[data-warehouse|lakehouse]] 패턴을 가능하게 함.

아키텍처

flowchart TB
    User["SQL Client<br/>(psql, BI)"] --> Leader["Redshift Leader Node"]

    Leader --> RedshiftLayer["Redshift Compute Nodes<br/>(내부 테이블 스캔 + JOIN)"]

    Leader --> SpectrumLayer["Spectrum Layer<br/>(수천 노드 auto-scale)"]

    RedshiftLayer --> RMS[("Redshift Managed Storage")]
    SpectrumLayer --> S3[("S3<br/>Parquet/ORC/JSON/CSV")]

    SpectrumLayer -->|"필터된 rows"| RedshiftLayer

    Glue[("Glue Data Catalog")] -.->|"external schema"| Leader

Redshift 클러스터: 필요 (RA3, DC2, Serverless)
Spectrum layer: AWS 관리, 자동 확장 (사용자 프로비저닝 X)
메타 저장: [[aws-glue|Glue Data Catalog]] (또는 Hive Metastore)
데이터: [[aws-s3|S3]] 그대로

언제 쓰나

상황	적합
데이터 레이크 (수 PB S3) + Redshift 조인	매우 적합
Cold historical 데이터를 Redshift RMS 에 넣기 아까움	적합
ETL 전 raw 데이터 탐색	적합
여러 소스 (S3 + Redshift 내부) 통합 쿼리	적합
Redshift 로드 없이 애드혹 리포팅	적합
짧은 반복 API 백엔드	부적합 (Redshift 내부 테이블)
Redshift 없는 순수 애드혹	부적합 ([[aws-athena\|Athena]])

External Schema & Table

External Schema

Glue Catalog 의 database 를 Redshift 에 mount.

CREATE EXTERNAL SCHEMA spectrum
FROM DATA CATALOG
DATABASE 'my_lake_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

IAM_ROLE: glue:GetTable* + s3:GetObject + s3:ListBucket
CREATE EXTERNAL DATABASE: Glue DB 가 없으면 자동 생성

External Table (Redshift 자체 등록)

CREATE EXTERNAL TABLE spectrum.sales_parquet (
  sales_id   BIGINT,
  user_id    BIGINT,
  product_id INT,
  amount     DECIMAL(10, 2),
  sale_ts    TIMESTAMP
)
PARTITIONED BY (year INT, month INT)
STORED AS PARQUET
LOCATION 's3://my-lake/sales_parquet/'
TABLE PROPERTIES ('numRows' = '500000000');

-- 파티션 등록
ALTER TABLE spectrum.sales_parquet
  ADD PARTITION (year=2026, month=7)
      LOCATION 's3://my-lake/sales_parquet/year=2026/month=7/';

또는 [[aws-glue|Glue Crawler]] 로 등록된 테이블을 external schema 로 자동 노출.

지원 파일 포맷

포맷	압축	Predicate Pushdown	Partitioning
[[apache-parquet\|Parquet]]	SNAPPY / GZIP / ZSTD	우수	O
ORC	SNAPPY / GZIP / ZSTD	우수	O
JSON	GZIP	제한	O
CSV / TSV	GZIP	제한	O
Avro	SNAPPY / GZIP / DEFLATE	제한	O
RegexSerDe	-	X	O
Apache Hudi	(Parquet 기반)	우수	O
Delta Lake	(Parquet 기반)	우수	O
Apache Iceberg	(Parquet 기반)	우수	O

[!IMPORTANT] Parquet + ZSTD + partitioning 이 사실상 표준. CSV 대비 10-100배 요금 절감 + 10-100배 성능.

요금

Spectrum layer: $5.00 / TB scanned (us-east-1, 2026).

10 MB 최소 per query
성공/실패 모두 청구
DDL 은 무료

추가 비용:

Redshift 컴퓨트 (RPU-hour or node-hour)
S3 저장, S3 GET/LIST
[[aws-glue|Glue Data Catalog]] 요청/저장
Cross-region 전송

예시 (Parquet + 파티션 프루닝 + 컬럼 프로젝션):

raw S3 데이터: 4 TB CSV (uncompressed)
동일 데이터 Parquet + ZSTD + 파티션: ~1 TB, 컬럼 100개 중 1개 쿼리

CSV 전체 스캔:  $5 × 4 TB = $20
Parquet + 프루닝 + 프로젝션:
  실 스캔 = 1 TB × (1/100) × (year 파티션 스킵) ≈ 5 GB
  $5 × 5/1024 TB = $0.024
  → 800배 절감

파티션 프루닝 (필수)

파티션 컬럼을 WHERE 절에 명시적으로 사용해야 스캔 대상이 줄어듬.

-- 파티션 프루닝 O (year=2026, month=7 파티션만 스캔)
SELECT SUM(amount)
FROM spectrum.sales_parquet
WHERE year = 2026 AND month = 7;

-- 파티션 프루닝 X (모든 파티션 스캔)
SELECT SUM(amount)
FROM spectrum.sales_parquet
WHERE sale_ts >= '2026-07-01' AND sale_ts < '2026-08-01';

-- 파티션 프루닝 X (함수 적용)
SELECT SUM(amount)
FROM spectrum.sales_parquet
WHERE YEAR(sale_ts) = 2026;

교훈: 파티션 컬럼은 원본 그대로 (year = 2026), 함수 wrap 금지.

Predicate Pushdown

Parquet/ORC 의 min/max 통계로 row group 을 스킵. Spectrum layer 가 S3 에서 read 하는 단계에서 필터.

-- Parquet row group min/max 로 대부분 스킵
SELECT * FROM spectrum.sales_parquet
WHERE amount > 1000000;

주의: 통계가 없으면 스킵 불가. Glue Crawler 는 통계를 생성하지 않음 -> Spark job 으로 write 시 통계 포함해야 함 (write_statistics=True, 기본).

Redshift 내부 테이블과의 JOIN

Spectrum 의 진짜 강점: S3 데이터를 Redshift 내부 dimension 과 조인.

-- Fact (S3, Spectrum) x Dimension (Redshift 내부)
SELECT
  d.category,
  SUM(f.amount) AS revenue
FROM spectrum.sales_parquet f      -- S3
JOIN internal.products d           -- Redshift RMS
  ON f.product_id = d.product_id
WHERE f.year = 2026 AND f.month = 7
GROUP BY d.category;

Fact 데이터가 큰 경우 (10 TB+), Redshift 에 로드하지 않고 S3 에 두는 것이 저장/관리 비용 이득.

Concurrency Scaling

동시 쿼리 부하 시 추가 Spectrum 컴퓨트 자동 프로비저닝.

Serverless: 자동
Provisioned RA3: 매일 1시간 무료, 이후 초당 노드 요금
별도 설정 없이 Spectrum 쿼리에도 적용

Materialized View (Spectrum 위에)

자주 쓰는 Spectrum 쿼리를 Redshift 내부에 pre-compute.

CREATE MATERIALIZED VIEW mv_sales_daily AS
SELECT
  year, month, product_id,
  SUM(amount) AS revenue,
  COUNT(*) AS n_sales
FROM spectrum.sales_parquet
WHERE year >= 2025
GROUP BY 1, 2, 3;

-- 주기적 refresh 또는 auto refresh
REFRESH MATERIALIZED VIEW mv_sales_daily;

이후 쿼리는 Redshift 내부 MV 를 스캔 (Spectrum 요금 0).

[[aws-athena|Athena]] vs Spectrum

같은 S3 데이터를 쿼리하는 두 가지 옵션. 근본적으로 다른 아키텍처.

축	Athena	Redshift Spectrum
엔진	Trino (Engine v3)	Redshift 자체
SQL 방언	Trino/Presto	PostgreSQL 계열 (Redshift)
클러스터 필요	X	O (Redshift)
요금	$5/TB scanned	$5/TB scanned + Redshift 컴퓨트
동시성	사실상 무제한 (serverless)	클러스터 한도 (concurrency scaling)
Redshift 내부 데이터와 JOIN	X (federated 필요)	네이티브
ETL / CTAS	지원	제한 (external table 은 read 중심)
JOIN 성능	중간	우수 (RA3 로컬 shuffle)
Iceberg 트랜잭션	완전 지원	읽기 위주
적합	애드혹, BI, S3-only	Redshift 기존 자산 + S3 확장

결정 규칙:

이미 Redshift 를 쓰고 S3 데이터를 조인해야 함 -> Spectrum
Redshift 없이 S3 만 쿼리 -> Athena
둘 다 쓸 수도 있음 (병존 흔함)

실전 예제

콜드 데이터 아카이빙 후 쿼리

2년 이상 지난 주문 → S3 Parquet (파티션: year/month)
                   → Glue Catalog 등록
                   → Redshift Spectrum external table

Redshift 내부: 최근 2년
Spectrum:       2년+ 이전
UNION ALL 로 통합 뷰

CREATE VIEW analytics.orders_all AS
SELECT * FROM internal.orders_recent
UNION ALL
SELECT * FROM spectrum.orders_archive;

-- 애널리스트는 orders_all 만 쿼리, 위치 신경 X

Nested Parquet (struct/list) 쿼리

-- 중첩 필드 접근
SELECT c.address.city, COUNT(*)
FROM spectrum.customers c
GROUP BY 1;

-- List 를 UNNEST
SELECT c.customer_id, tag
FROM spectrum.customers c, c.tags AS tag;

Parquet 의 struct/list 를 그대로 SQL 로. Redshift 내부는 flat 이라 이 부분은 Spectrum 만 가능한 워크로드.

성능 튜닝 체크리스트

[[apache-parquet|Parquet]] / ORC + 압축 (ZSTD 우선)
파티션 컬럼 을 WHERE 절에 그대로 (함수 wrap X)
파일 크기 256 MB - 1 GB (small files 회피)
컬럼 프로젝션 (SELECT * 금지)
통계 생성 (Spark write 시 자동, Crawler 는 안 함)
Materialized View 로 반복 쿼리 캐시
Concurrency Scaling 활성화
SVL_S3QUERY_SUMMARY 로 스캔량 모니터링

-- 실행된 Spectrum 쿼리와 스캔량
SELECT userid, query, s3_scanned_bytes, s3_scanned_rows,
       elapsed / 1000000.0 AS elapsed_sec
FROM SVL_S3QUERY_SUMMARY
WHERE starttime > SYSDATE - 1
ORDER BY s3_scanned_bytes DESC LIMIT 20;

함정

[!WARNING] SELECT * on unpartitioned CSV = 페타바이트 스캔 = 수천 달러. Workgroup 이 아니라 [[aws-redshift|Redshift]] usage limit 로 제한.

[!CAUTION] 파티션 컬럼에 함수 적용 = 파티션 프루닝 실패. WHERE year = 2026 그대로. WHERE CAST(year AS VARCHAR) = '2026' 금지.

[!WARNING] 작은 파일 (수천 개 × < 10 MB) = Spectrum 노드가 파일마다 GET/파싱 = 성능 붕괴. Compact 필수.

[!IMPORTANT] [[aws-glue|Glue Crawler]] 는 통계 미생성 -> Predicate pushdown 효과 감소. Spark write 시 write_statistics=True (기본) 확인.

[!CAUTION] Glacier 오브젝트 는 쿼리 실패. Lifecycle 로 Glacier 로 옮긴 파일을 external table 이 참조 -> “InvalidObjectState”. [[aws-s3-glacier|Restore]] 후에만.

[!WARNING] Cross-region S3 = 데이터 전송 요금 + 지연. Redshift 와 같은 region S3 유지.

[!IMPORTANT] Athena 와 Spectrum 을 오해: 이름은 같은 개념이지만 엔진과 SQL 방언이 다름. 쿼리를 서로 그대로 옮기면 안 됨.

[!CAUTION] External Table 스키마 변경 안 반영 = Redshift 캐시된 스키마와 실제 파일 스키마가 다르면 오류. ALTER TABLE ... SET LOCATION 또는 재등록.

[AWS] Region / Availability Zone / Data Center

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS 인프라의 물리 계층은 “Region → Availability Zone → Data Center” 3 단계 계층. 각 계층이 격리 (isolation), 지연 (latency), 가용성 (availability) 을 다른 방식으로 제공.

Region: 지리적으로 분리된 물리 위치 그룹 (예: 서울 ap-northeast-2, 도쿄 ap-northeast-1)
Availability Zone (AZ): 한 리전 안의 물리적으로 분리된 하나 이상의 데이터센터 클러스터
Data Center: 실제 물리 시설 (건물). AWS 는 이 계층을 사용자에게 노출하지 않음

한 줄 요약: Region 은 지리, AZ 는 리전 안의 물리적 격리 단위, DC 는 AWS 내부 구현 상세.

왜 이 계층인가

세 계층은 각각 다른 실패 모드 (failure mode) 에 대응.

계층	실패 상황	방어 방식
Data Center	한 건물의 정전, 화재	AZ 안에 여러 DC → 자동 fail-over
Availability Zone	AZ 전체 장애 (정전, 자연재해)	여러 AZ 배포 (Multi-AZ)
Region	지역 전체 (드물지만: 지진, 정전, 규제)	Multi-region (DR)
Provider (AWS 전체)	극단적 경우	Multi-cloud

각 계층 방어는 비용과 복잡도가 증가. 대부분 워크로드는 Multi-AZ 까지 로 충분.

Region (리전)

지리적으로 분리된 영역. 각 리전은 독립된 물리 인프라 + 지리적 위치.

특성

완전 격리 (독립성): 한 리전의 서비스가 다른 리전으로 자동 복제 X (S3 Cross-Region Replication 등 명시적 설정 필요)
자체 규제 준수: 데이터 sovereignty (예: EU 데이터가 EU 리전 밖으로 안 나감, 한국 개인정보보호법)
자체 서비스 카탈로그: 신규 서비스는 특정 리전부터 순차 출시
지연: 사용자 지리적 위치에 가까운 리전이 더 낮은 지연

리전 명명 규칙

형식: <대륙>-<방향>-<번호>

예시	위치
`us-east-1`	미국 동부 (버지니아 북부) - 최초 리전, 가장 큼
`us-east-2`	미국 동부 (오하이오)
`us-west-2`	미국 서부 (오리건)
`ap-northeast-2`	아시아 태평양 (서울)
`ap-northeast-1`	아시아 태평양 (도쿄)
`eu-west-1`	유럽 (아일랜드)
`eu-central-1`	유럽 (프랑크푸르트)

대표 리전 (2026 시점 기준)

최다 서비스: us-east-1 (버지니아 북부) - 신규 서비스 최초 출시, IAM 등 전역 서비스의 primary
가장 저렴: 오래된 리전 (us-east, us-west) 이 보통 저렴
격리 리전: AWS GovCloud (US), China (Beijing, Ningxia) - 별도 계정 필요

리전 선택 기준

사용자 지리적 위치 (지연)
데이터 sovereignty 규제
필요 서비스 가용성 (모든 서비스가 모든 리전에 없음)
비용 (리전별 단가 다름)
DR 파트너 리전 (활용도 큰 서비스면 최소 2 리전)

Availability Zone (AZ)

리전 안의 물리적으로 분리된 데이터센터 클러스터. 한 리전은 3+ AZ 로 구성.

특성

하나 이상의 데이터센터 로 구성 (AZ = DC 는 아님, AZ 는 DC 의 상위 집합)
독립 전력, 냉각, 네트워킹
지리적 분리 (동일 AZ 라도 여러 DC 가 수 km 떨어져 있을 수 있음)
AZ 간 저지연 고대역폭 사설 링크 (일반적으로 < 1 ms, 100+ Gbps)
AZ 장애의 독립성: 한 AZ 가 죽어도 다른 AZ 는 영향 X (설계 원칙)

AZ 개수

대부분 리전: 3 AZ
큰 리전 (us-east-1, us-west-2): 6 AZ
신규/소규모: 3 AZ 로 시작

AZ 명명: Name vs ID (중요 개념)

같은 물리 AZ 를 여러 방식으로 지칭.

AZ Name (사용자 관점)

형식: <region>-<az-letter> (예: ap-northeast-2a, ap-northeast-2b, ap-northeast-2c)
계정마다 무작위 매핑! 계정 A 의 ap-northeast-2a 와 계정 B 의 ap-northeast-2a 는 다른 물리 AZ 일 수 있음

왜 무작위 매핑인가: AWS 가 최초 몇 년간 대부분 사용자가 us-east-1a 만 쓰는 것을 발견. 리소스 편중 방지 위해 계정별로 AZ 이름을 물리 AZ 에 무작위 매핑.

AZ ID (물리적 고정 식별자)

형식: <region-code>-az<N> (예: apne2-az1, apne2-az2)
모든 계정에서 동일 물리 AZ 를 가리킴
크로스 계정 협업 시 AZ ID 로 소통해야 함

# AZ Name → ID 매핑 확인
aws ec2 describe-availability-zones --region ap-northeast-2 \
  --query 'AvailabilityZones[].[ZoneName,ZoneId]' \
  --output table

# 예 (계정 A):
# ap-northeast-2a → apne2-az1
# ap-northeast-2b → apne2-az2

# 계정 B (다를 수 있음):
# ap-northeast-2a → apne2-az3

실무 함의:

VPC 공유 (계정 A 의 subnet 을 계정 B 와 [[aws-organizations|RAM]] 공유): AZ Name 이 아닌 AZ ID 로 매칭
크로스 계정 데이터 전송 요금 절감: 같은 물리 AZ 사이 전송이 저렴 → AZ ID 로 확인
재난 복구 계획: “us-east-1a 장애” 라는 알림은 계정마다 다른 물리 AZ 일 수 있음

Data Center (DC)

AZ 를 구성하는 실제 물리 시설. AWS 는 이 계층을 사용자 API 로 노출 X.

특성

하나의 AZ 가 여러 DC 로 구성될 수 있음
각 DC 는 자체 물리 인프라 (전력, 냉각, 소방)
DC 간 저지연 고속 광케이블
지리 분산: 같은 AZ 라도 DC 들이 수 km 떨어져서 화재/폭발 상관 관계 최소화

사용자가 알 필요 없는 이유

AWS 가 DC 간 부하 분산과 fail-over 를 자동 관리
사용자는 AZ 만 지정하면 됨
DC 계층은 SLA 계산과 내부 리던던시 위한 것

Region / AZ / DC 계층 시각화

flowchart TB
    Global["AWS Global Infrastructure"]

    Global --> R1["Region: ap-northeast-2 (Seoul)"]
    Global --> R2["Region: us-east-1 (N. Virginia)"]
    Global --> R3["Region: eu-west-1 (Ireland)"]

    R1 --> AZ1["AZ: apne2-az1<br/>(사용자 계정: 2a 또는 2b 등)"]
    R1 --> AZ2["AZ: apne2-az2"]
    R1 --> AZ3["AZ: apne2-az3"]
    R1 --> AZ4["AZ: apne2-az4"]

    AZ1 --> DC1["DC 1 (건물 A)"]
    AZ1 --> DC2["DC 2 (건물 B)"]
    AZ1 --> DC3["DC 3 (건물 C)"]

    Note1["같은 AZ 안 DC 는<br/>< 1ms 지연"]
    Note2["다른 AZ 는<br/>< 2ms 지연"]
    Note3["같은 리전 안<br/>모든 AZ 인터커넥트"]

Multi-AZ 설계

프로덕션 워크로드의 최소 요건.

원칙

컴퓨트 (EC2, ECS, EKS) 를 최소 2 AZ 에 분산
데이터 저장 (RDS, ElastiCache) 는 Multi-AZ deployment 활성화
로드밸런서 (ALB, NLB) 는 자동 다중 AZ (사용할 AZ 선택)
Auto Scaling Group 은 여러 AZ 걸침

크로스 AZ 데이터 전송 요금

같은 AZ 안: 무료
다른 AZ (같은 리전): 양방향 GB 당 요금
다른 리전: 더 비싼 요금

실무 팁: 같은 flow 를 같은 AZ 안에서 완결하도록 설계 (예: AZ-local ALB → AZ-local EC2 → AZ-local RDS 라도 이상적).

Multi-Region 설계

DR (Disaster Recovery), 지연 최적화, 데이터 sovereignty.

RTO / RPO 목표별 전략

전략	RTO	RPO	비용
Backup & Restore	시간	시간	낮음
Pilot Light	수십 분	분	중간
Warm Standby	분	초	높음
Multi-Region Active-Active	초	초	매우 높음

크로스 리전 서비스

S3 Cross-Region Replication
DynamoDB Global Tables
Aurora Global Database
RDS Cross-Region Read Replica
Route 53 (Health Check + Failover)
CloudFront (전 세계 자동)

특수 위치 (Region/AZ 밖)

Local Zones

도시 근처 소규모 컴퓨트 확장. 리전에서 멀리 떨어진 도시 (예: LA, 마이애미, 서울) 에 배치.

사용자 근접 low-latency (< 10 ms)
Parent Region 에 종속 (Local Zone 은 Parent Region 의 확장)
서비스 제한 (모든 서비스 없음)
대표 사용: 로컬 media, 게임, live streaming

Wavelength Zones

5G 통신사 네트워크 안에 배치된 컴퓨트. 모바일 사용자에게 초저지연.

통신사 (Verizon, KDDI, SK Telecom 등) 파트너십
대표 사용: AR/VR, 자율주행, 산업 IoT
5G 네트워크 안에서 완결되는 앱

Outposts

AWS 하드웨어를 고객 데이터센터에 설치. AWS 인프라의 온프레미스 확장.

AWS 가 하드웨어 (rack) 배송 + 설치 + 유지관리
AWS 리전과 동일 API (EC2, EBS, S3, RDS 등)
대표 사용:
- 데이터가 물리적으로 특정 위치에 있어야 함 (규제)
- 매우 저지연 필요 (금융 거래)
- 대용량 데이터 처리 (지구 반대편 리전 대신 로컬)

요약

Region (일반)     → 지리적 분리, 리전 규모 전체 인프라
Local Zone       → 도시 근접 확장 (Parent Region 종속)
Wavelength Zone  → 5G 통신사 네트워크 안
Outposts         → 고객 데이터센터 안

실무 결정 규칙

Multi-AZ = 사실상 프로덕션 필수 (SLA 유지)
Multi-Region = 정말 필요할 때만 (복잡도 큼)
Local Zone = 특정 도시 사용자 저지연 필수 (게임, 미디어)
Wavelength = 5G 모바일 앱 저지연
Outposts = 규제 or 매우 저지연 or 데이터 sovereignty

함정

[!WARNING] AZ Name 은 계정별 무작위. 두 계정이 같은 물리 AZ 를 다른 이름으로 부를 수 있음. 크로스 계정 협업은 반드시 AZ ID 로.

[!CAUTION] Single AZ 프로덕션 = SLA 위반, AZ 장애 시 완전 다운. 최소 2 AZ 필수.

[!WARNING] 크로스 AZ 데이터 전송 요금. 인기 있지만 관측 안 하면 예상 밖 요금. 같은 AZ 안 flow 완결 우선.

[!IMPORTANT] us-east-1 은 신규 서비스가 먼저 출시 되지만 가장 많은 장애 이력. 크리티컬 워크로드는 다른 리전 검토.

[!CAUTION] Multi-Region 이 자동 아님. Region 간 리소스 복제는 명시적 설정 필요 (S3 CRR, Aurora Global 등).

[!WARNING] Local Zone / Wavelength 는 서비스 제한. 모든 EC2 인스턴스 타입, 모든 서비스 지원 X. 배포 전 확인 필수.

[!IMPORTANT] IAM, CloudFront, Route 53 등 전역 서비스 는 리전 X. 모든 리전에서 같은 상태 (하지만 API 는 us-east-1 에서 처리).

[AWS] S3 Glacier: Instant / Flexible / Deep Archive

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon S3 Glacier 는 [[aws-s3|S3]] 의 장기 아카이빙 스토리지 클래스 3종. 자주 접근하지 않는 데이터를 극도로 저렴하게 (Standard 대비 최대 95% 절감) 저장. 각 클래스는 검색 지연 (retrieval latency) 과 최소 저장 기간 (minimum storage duration) 이 다름.

주의: S3 Glacier storage class (현재 방식) 와 S3 Glacier Vault (legacy 별도 서비스) 는 다름. 신규는 storage class 로만.

세 가지 클래스 (2026 시점)

클래스	검색 지연	최소 저장 기간	저장 요금 (US East)	대표 용도
Glacier Instant Retrieval	밀리초	90일	~$0.004 / GB-월	분기별 접근 아카이브
Glacier Flexible Retrieval	분 ~ 시간	90일	~$0.0036 / GB-월	연 1-2회 접근
Glacier Deep Archive	12 ~ 48 시간	180일	~$0.00099 / GB-월	매우 드문 접근 (컴플라이언스)

최소 오브젝트 크기: 128 KB. 더 작아도 128 KB 로 청구. 메타데이터 오버헤드: 40 KB / object (8 KB @ Standard 요금 + 32 KB @ Glacier 요금).

클래스별 상세

S3 Glacier Instant Retrieval (IR)

밀리초 검색. Standard 와 접근 지연이 사실상 같음.

검색 = 즉시 (restore 불필요)
접근 요금이 있음 ($0.03 / GB), 저장은 매우 저렴
최소 저장 90일 (조기 삭제 시 pro-rated 요금)
최소 오브젝트 128 KB

적합: 의료 이미지, 미디어 백카탈로그, 컴플라이언스 로그 (분기/반기 조회).

S3 Glacier Flexible Retrieval (구 “S3 Glacier”)

3단계 retrieval tier 로 지연과 요금 트레이드오프.

Tier	지연	요금
Expedited	1-5 분	~$0.03 / GB
Standard	3-5 시간	~$0.01 / GB (기본)
Bulk	5-12 시간	무료

검색 = restore 요청 필요 (동기 아님)
최소 저장 90일
대용량 벌크 검색 (bulk tier) 이 무료 -> 정기 감사에 유리

적합: 백업 (분기/연 검증), 미디어 원본, 규제 데이터 아카이브.

S3 Glacier Deep Archive

최저가 스토리지. 12/48 시간 대기 감내 가능한 데이터.

Tier	지연	요금
Standard	12 시간	~$0.01 / GB
Bulk	48 시간	~$0.0025 / GB

최소 저장 180일
데이터 볼륨 극대: 페타바이트 저장 시 큰 차이

적합: 7년+ 재무/의료/법적 보존, 오프사이트 백업 대체.

저장 요금 시각화

$/GB-월 (2026, us-east-1)
Standard              ████████ ~$0.023
Standard-IA           ████     ~$0.0125
One Zone-IA           ███      ~$0.01
Glacier Instant       ██        ~$0.004
Glacier Flexible      █         ~$0.0036
Glacier Deep Archive  ·         ~$0.00099

검색 워크플로우 (Restore)

Flexible / Deep Archive 는 비동기 restore 가 필요.

sequenceDiagram
    participant App
    participant S3
    App->>S3: RestoreObject(tier=Standard, days=7)
    Note over S3: Glacier 백엔드에서 read (분/시간)
    S3-->>App: 202 Accepted
    Note over App: 폴링 or S3 이벤트 (Restore Completed)
    App->>S3: GetObject
    S3-->>App: 데이터 (7일 후 임시 사본 삭제)
    Note over S3: 원본은 Glacier 그대로 유지

aws s3api restore-object \
  --bucket my-archive \
  --key logs/2024/data.parquet \
  --restore-request '{
    "Days": 7,
    "GlacierJobParameters": {"Tier": "Standard"}
  }'

# 완료 확인
aws s3api head-object --bucket my-archive --key logs/2024/data.parquet
# 'Restore': 'ongoing-request="false", expiry-date="..."'

Days: Standard 클래스로 임시 사본을 유지할 기간
만료 = 임시 사본 삭제 (원본은 Glacier 에 그대로)
s3:ObjectRestore:Completed 이벤트로 자동 트리거 가능

Lifecycle Transitions

STANDARD -> IA -> Glacier 자동 이동.

Rules:
  - Id: archive-old
    Filter: { Prefix: logs/ }
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 90
        StorageClass: GLACIER              # Flexible
      - Days: 365
        StorageClass: DEEP_ARCHIVE
    Expiration:
      Days: 2555   # 7년
    AbortIncompleteMultipartUploads:
      DaysAfterInitiation: 7

전이 요금: $0.05 / 1000 requests. 파일 수가 많으면 무시 못 함.

컴플라이언스: Object Lock vs Vault Lock

S3 Object Lock (현재 표준)

WORM (Write Once Read Many) 을 스토리지 클래스와 무관하게 적용.

Mode: GOVERNANCE | COMPLIANCE
RetainUntilDate: "2031-07-30T00:00:00Z"

GOVERNANCE: 특정 IAM 권한으로 해제 가능
COMPLIANCE: root 도 삭제 불가 (SEC 17a-4, FINRA, CFTC 등 규제 대응)
Legal Hold: 날짜 무관 삭제 차단

Glacier 모든 클래스에 적용 가능. 신규는 Object Lock 만.

Vault Lock (Legacy Glacier Vaults)

별도 서비스 glacier API (S3 API 아님). 신규 프로젝트는 사용 안 함. S3 Object Lock 이 완전 대체.

Small Files 문제

40 KB 메타데이터 오버헤드 가 오브젝트 당 청구. 오브젝트 수천만 개 = 오버헤드 폭발.

1000만 objects × 40 KB = 400 GB metadata
- 8 KB × 1000만 @ Standard 요금
- 32 KB × 1000만 @ Glacier 요금

128 KB 미만 은 128 KB 로 청구. 작은 파일들을 묶어서 (tar/zip) 저장하는 것이 압도적으로 저렴.

데이터 접근 패턴별 선택

패턴	클래스
하루 여러 번	Standard
주 1회	Standard-IA
월 1-2회	One Zone-IA (내구성 감수)
분기 1회 (즉시 필요)	Glacier Instant Retrieval
연 1-2회 (몇 시간 감수)	Glacier Flexible Retrieval
5년+ 거의 접근 안 함	Glacier Deep Archive
예측 불가	Intelligent-Tiering (자동)

Intelligent-Tiering 과의 관계

S3 Intelligent-Tiering 은 여러 tier 를 자동 이동. Archive Access / Deep Archive Access tier 를 활성화하면 Glacier 클래스도 자동 관리:

IntelligentTieringConfiguration:
  Tierings:
    - Days: 90                       # 90일 미접근
      AccessTier: ARCHIVE_ACCESS      # Glacier Flexible 상당
    - Days: 180                       # 180일 미접근
      AccessTier: DEEP_ARCHIVE_ACCESS # Deep Archive 상당

접근 패턴을 몰라도 됨. 단, Archive tier 에 있는 오브젝트는 restore 가 필요 (즉시 접근 X).

요금 계산 예시

시나리오: 100 TB 로그, 1년 후 Deep Archive 로 옮김.

초기 12개월 (Standard):
  100 TB × 1024 × $0.023 × 12 = ~$28,262

Lifecycle 로 12개월 후 Deep Archive:
  전이 요금: 100M objects × $0.05/1000 = $5,000  (한 번)
  이후 저장: 100 TB × 1024 × $0.00099 × 12 = ~$1,216  /년

절감:
  Standard 계속:  ~$28,262 /년
  Deep Archive:   ~$1,216  /년
  → 95% 절감

단, 검색 요금 별도 발생. 접근 빈도가 실제로 낮아야 이득.

[[aws-athena|Athena]] / [[aws-redshift-spectrum|Spectrum]] 과의 관계

Glacier 클래스 오브젝트는 Athena / Redshift Spectrum 이 직접 쿼리 불가. 이유:

Athena / Spectrum 은 GET 을 즉시 시도, restore 대기 안 함
Instant Retrieval 도 다른 스토리지 클래스로 인식되어 쿼리 실패

해결:

쿼리 전 RestoreObject 수행
Restore 된 임시 사본 (Standard) 이 나오면 쿼리
만료 후 원본은 Glacier 에 그대로

또는 데이터를 미리 Standard 로 옮겨 놓기.

함정

[!WARNING] 최소 저장 기간 위반: 90일 (IR/Flexible) 또는 180일 (Deep Archive) 이내 삭제 시 남은 기간 pro-rated 요금 청구. 잦은 upload/delete 는 오히려 비쌈.

[!CAUTION] Expedited retrieval 요금 = Standard 대비 3배. 정기 감사에 Expedited 를 관행으로 쓰면 예상 밖 요금. Bulk (무료) 로 사전 계획.

[!WARNING] 40 KB 메타데이터 오버헤드 을 무시 = 파일 1억 개 = 4 TB 오버헤드. 작은 파일은 tar/zip 으로 묶어 저장.

[!IMPORTANT] 128 KB 최소 청구. 100 바이트 파일도 128 KB 로 계산. 작은 오브젝트를 Glacier 로 옮기면 오히려 비용 증가할 수 있음.

[!CAUTION] Restore 임시 사본 만료 후 재접근 시 다시 restore 필요 = 지연 재발. 접근 패턴 파악 후 Days 를 넉넉히.

[!WARNING] Athena / Spectrum 이 Glacier 오브젝트 만나면 쿼리 실패. Lifecycle 로 옮기기 전에 다운스트림 쿼리 패턴을 재검증.

[!IMPORTANT] Instant Retrieval 은 저장 요금이 Standard-IA 보다 비싸다 (약 2배). 접근이 정말 드물 때만 유리. 월 1회 이상이면 Standard-IA 가 저렴.

[!CAUTION] Legacy Glacier Vault 를 신규 프로젝트에 사용하지 말 것. S3 storage class 로만 사용. Vault 는 별도 API + Vault Lock 이지만 사용성/통합성이 떨어짐.

[!WARNING] Versioning + Lifecycle 조합 실수 = 이전 버전이 계속 Glacier 에 쌓임. NoncurrentVersionTransition / NoncurrentVersionExpiration 을 명시.

[AWS] S3: object storage, storage classes, lifecycle

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

S3 = AWS 의 object storage. bucket + key + object. 11 9’s durability (99.999999999%), 무한 확장. 2026 시점 인터넷의 핵심 스토리지 플랫폼.

사용 상황

상황	S3 선택 이유
정적 자산 (이미지, JS, CSS)	[[aws-cloudfront-cdn]] 와 조합
로그 장기 보관	Lifecycle 로 Glacier 자동 이동
ML 학습 데이터 / 모델	S3 → SageMaker 직접 연동
백업 / DR	Cross-Region Replication
데이터 레이크	S3 + Athena + Glue
사용자 파일 업로드	Presigned URL 로 서버 우회
컴플라이언스 아카이빙	Object Lock WORM

Storage Class

Class	용도	비용	검색 latency
Standard	자주 접근	$0.023/GB	ms
Intelligent-Tiering	자동 자주/덜 자주 분류	varies	ms
Standard-IA	가끔 접근	더 cheap, retrieval fee	ms
One Zone-IA	단일 AZ + 가끔 접근	더 cheap	ms
Glacier Instant Retrieval	archive + 즉시 접근	매우 cheap	ms
Glacier Flexible Retrieval	archive	매우 cheap	분~시간
Glacier Deep Archive	장기 archive	가장 cheap	12+ 시간

Intelligent-Tiering 은 접근 패턴 예측 불가 시 최적. 30일 미접근 시 IA 로 자동 이동.

세 Glacier 클래스 (Instant / Flexible / Deep Archive) 의 상세는 [[aws-s3-glacier|S3 Glacier]] 참조.

Lifecycle Policy

Rules:
  - Id: archive-old-logs
    Filter: { Prefix: logs/ }
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 90
        StorageClass: GLACIER
    Expiration:
      Days: 365
    AbortIncompleteMultipartUploads:
      DaysAfterInitiation: 7

비용 대폭 절감. 사용 안 하는 데이터를 자동 cheaper class 로.

AbortIncompleteMultipartUploads 는 반드시 설정. 미완료 multipart 가 비용 누수.

Replication (CRR / SRR)

flowchart LR
    SrcBucket["Source Bucket<br/>(us-east-1)"] -->|CRR| DstBucket["Dest Bucket<br/>(ap-northeast-2)"]
    SrcBucket2["Source Bucket A"] -->|SRR| DstBucket2["Dest Bucket B<br/>(같은 region)"]

종류	의미
CRR (Cross-Region Replication)	다른 리전으로 복제 (DR, 지연 감소)
SRR (Same-Region Replication)	같은 리전 내 복제 (로그 집계, 테스트)

Source bucket: Versioning 활성화 필수.
신규 객체만 복제 (기존 객체는 S3 Batch Operations 으로 별도 복제).
Delete Marker: 기본 복제 안 됨 (설정 가능).
복제 시간 SLA: 기본 15분 이내. S3 Replication Time Control (RTC) = 99.99% 를 15분 이내 보장 (추가 비용).

Versioning

aws s3api put-bucket-versioning --bucket my --versioning-configuration Status=Enabled

덮어쓰기 / 삭제 = 옛 버전 보존.
실수 복구 가능.
삭제 = Delete Marker 생성 (실제 삭제 아님).
비용: 모든 버전 저장. Lifecycle 로 오래된 버전 정리 필수.

Object Lock (WORM)

Mode: GOVERNANCE | COMPLIANCE
RetainUntilDate: "2027-06-25T00:00:00Z"

Write Once Read Many: 보존 기간 중 삭제/수정 불가.
GOVERNANCE: 특정 IAM 권한으로 삭제 가능.
COMPLIANCE: root user 도 삭제 불가. 금융/의료 컴플라이언스.
Legal Hold: 날짜 무관 삭제 차단.

Multipart Upload

sequenceDiagram
    Client->>S3: InitiateMultipartUpload (uploadId)
    par parallel parts
        Client->>S3: UploadPart 1
        Client->>S3: UploadPart 2
        Client->>S3: UploadPart N
    end
    Client->>S3: CompleteMultipartUpload (part etags)
    S3-->>Client: 완료

큰 파일 (100MB+) 권장, 5GB 초과 시 필수.
병렬 업로드 + 개별 파트 재시도 가능.
최소 파트 크기: 5MB (마지막 파트 제외).
미완료 Multipart: Lifecycle AbortIncompleteMultipartUploads 로 자동 정리.

Presigned URL

import boto3

s3 = boto3.client('s3')
url = s3.generate_presigned_url(
    'put_object',
    Params={'Bucket': 'my-bucket', 'Key': 'upload.zip'},
    ExpiresIn=3600   # 1시간
)

클라이언트가 S3 에 직접 업로드/다운로드 (서버 경유 없음).
임시 URL (만료 시간 설정).
서버 측에서 IAM 권한 위임.
GET (다운로드), PUT (업로드) 모두 지원.

Transfer Acceleration

# 엔드포인트: my-bucket.s3-accelerate.amazonaws.com
aws configure set default.s3.use_accelerate_endpoint true

CloudFront edge location 을 경유해 S3 에 전송.
글로벌 업로드 속도 최대 60% 향상 (지역별 편차 큼).
비용: 일반 전송 대비 추가 요금.
실제 개선 여부: S3 Transfer Acceleration Speed Comparison Tool 로 사전 확인.

S3 Access Points

버킷 하나를 여러 팀이 다른 정책으로 접근할 때.

aws s3control create-access-point \
  --name data-science-ap \
  --account-id 123456789 \
  --bucket my-data-lake \
  --vpc-configuration VpcId=vpc-abc

각 Access Point 는 고유한 ARN + endpoint + Policy.
VPC-only 접근 강제 가능.
버킷 Policy 가 복잡해지는 것을 Access Point Policy 로 분리.

Static Website Hosting

Bucket Property: Static Website Hosting
  Index document: index.html
  Error document: 404.html

CloudFront + OAC 조합:

CloudFront: 글로벌 CDN, HTTPS, 커스텀 도메인.
OAC (Origin Access Control): CloudFront 에서만 S3 접근 허용.
S3 직접 접근 차단 (Block Public Access 유지).

Event Notifications

flowchart LR
    Upload[Object 업로드] --> S3
    S3 -->|event| Lambda
    S3 -->|event| SQS
    S3 -->|event| SNS
    S3 -->|event| EventBridge

새 파일 → 처리 자동화.
이미지 thumbnail 생성, 비디오 transcoding, 데이터 처리.
[[aws-eventbridge]] 연동 시 content-based filtering 가능 (object key prefix 등).

S3 Select / S3 Object Lambda

S3 Select: CSV / JSON / Parquet 의 SQL 일부 query. 필요한 컬럼만 pull.
S3 Object Lambda: GET 요청 시 Lambda 가 transform (redact, watermark, format conversion).

보안

flowchart TD
    Q[보안 layer]
    Q --> Block["Block Public Access<br/>(계정/bucket)"]
    Q --> Bucket[Bucket Policy]
    Q --> IAM[IAM Policy]
    Q --> ACL["ACL (legacy)"]
    Q --> Enc["Server-Side Encryption<br/>(SSE)"]
    Q --> KMS[KMS 키]
    Q --> Object[Object Lock]

Encryption

종류	의미
`SSE-S3`	S3 관리 key (AES-256)
`SSE-KMS`	[[aws-kms]] 관리 key, 감사 가능
`SSE-C`	사용자 제공 key
`DSSE-KMS`	이중 암호화

2023년부터 기본 암호화 SSE-S3 자동 적용. 컴플라이언스 요구 시 SSE-KMS 전환.

Object Ownership + ACL

신규 버킷은 ACL 비활성화 + Object Ownership = BucketOwnerEnforced 권장. Cross-account 업로드 객체도 버킷 소유자가 자동 소유.

Inventory / Storage Lens / Analytics

도구	용도
S3 Inventory	객체 목록을 CSV/Parquet 으로 주기 출력 (대규모 버킷 감사)
S3 Storage Lens	조직 전체 스토리지 사용량 대시보드 (비용 최적화 insight)
S3 Analytics	접근 패턴 분석 → Standard-IA 전환 권고

# Storage Lens 기본 대시보드 (무료)
aws s3control get-storage-lens-dashboard \
  --config-id default-account-dashboard \
  --account-id 123456789

흔한 함정

[!WARNING]

Bucket 공개 사고 = “Block Public Access” 항상 켜기. CloudFront + OAC 권장.

Versioning 후 비용 = 옛 버전 누적. Lifecycle NoncurrentVersionExpiration 으로 정리.

Glacier 의 retrieval fee = Glacier 에서 빨리 꺼내면 비용 큼. 접근 빈도 고려.

Multipart upload 정리 안 함 = 미완료 multipart 가 비용 발생. Lifecycle AbortIncompleteMultipartUploads.

CRR 에서 기존 객체 미복제 = Replication 설정 이전 객체는 S3 Batch Operations 로 별도 복제.

S3 Event + Lambda 무한 루프 = Lambda 가 같은 버킷에 쓰면 이벤트 재발생. prefix/suffix 필터 필수.

Presigned URL 의 만료 후 클라이언트 캐싱 = 클라이언트가 URL 를 저장해 재사용 시 403. 짧은 만료 + 재발급 로직.

[AWS] Security Group vs NACL: stateful vs stateless 방화벽

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS VPC 에는 두 계층의 네트워크 방화벽이 존재.

항목	SG (Security Group)	NACL (Network ACL)
상태	Stateful	Stateless
적용 레벨	ENI / 인스턴스	Subnet
규칙 종류	Allow 만	Allow + Deny
규칙 평가	모든 규칙 종합	번호 순 (첫 매칭)
기본 Inbound	deny all	allow all
기본 Outbound	allow all	allow all
반환 트래픽	자동 허용	명시적 설정 필요

Stateful vs Stateless 심화

Stateful: Security Group

sequenceDiagram
    Client->>SG: "TCP SYN (port 80, inbound)"
    SG->>Server: forward (inbound rule 일치)
    Note over SG: "connection 상태 추적"
    Server->>SG: "TCP SYN-ACK (ephemeral port, outbound)"
    SG-->>Client: "forward (상태 추적, outbound 규칙 검사 안 함)"

SG 는 연결 상태를 추적. Inbound 를 허용하면 그 연결의 응답은 자동으로 허용. Outbound 규칙을 닫아도 기존 연결 응답은 통과.

Stateless: NACL

sequenceDiagram
    Client->>NACL: "TCP SYN (port 443, inbound)"
    NACL->>Server: "inbound rule 100: allow 443 -> 통과"
    Server->>NACL: "TCP SYN-ACK (ephemeral port 32768, outbound)"
    NACL->>NACL: "outbound rule 검사: 1024-65535 허용? -> 확인"
    NACL-->>Client: "outbound rule 있어야 통과"

NACL 은 각 패킷을 독립적으로 검사. 응답 트래픽도 별도 outbound rule 필요. 특히 ephemeral port 처리가 핵심.

Ephemeral Port 이해

클라이언트가 서버에 요청할 때 임시 포트를 사용:

Linux: 32768-60999
Windows: 49152-65535
AWS 권장: 1024-65535

# NACL Outbound rule (올바른 설정)
Rules:
  - RuleNumber: 100
    Direction: outbound
    Action: allow
    Protocol: tcp
    PortRange: { From: 1024, To: 65535 }   # ephemeral ports
    CidrBlock: 0.0.0.0/0

# 이것만 있으면 Inbound 요청의 응답도 통과

[!WARNING] NACL 에서 ephemeral port 누락 = 응답이 차단. NACL outbound 에 반드시 1024-65535 포트 범위 허용 규칙 추가.

Security Group 규칙

기본 설정 패턴

# 웹 서버 Security Group
WebServerSG:
  Inbound:
    - Protocol: tcp
      Port: 443
      CidrIp: 0.0.0.0/0         # 인터넷에서 HTTPS
    - Protocol: tcp
      Port: 80
      CidrIp: 0.0.0.0/0         # 인터넷에서 HTTP (리다이렉트용)
  Outbound:
    - Protocol: -1               # 모든 아웃바운드 (기본)
      CidrIp: 0.0.0.0/0

# DB 서버 Security Group
DatabaseSG:
  Inbound:
    - Protocol: tcp
      Port: 5432
      SourceSecurityGroupId: sg-webserver   # 웹 SG 에서만 PostgreSQL
  Outbound:
    - Protocol: -1
      CidrIp: 0.0.0.0/0

SG Referencing SG (핵심 기능)

IP 대신 다른 SG 를 source/destination 으로 지정. Dynamic IP 환경에서 강력.

DatabaseSG:
  Inbound:
    - Protocol: tcp
      Port: 5432
      SourceSecurityGroupId: sg-app         # app SG 가진 ENI 만 허용

flowchart LR
    AppInstance["앱 EC2<br/>sg-app"] -->|"port 5432"| DB["RDS<br/>sg-db"]
    DB -.->|"sg-app 만 허용"| DB
    Internet["인터넷"] -.-x|"차단"| DB

Auto Scaling 으로 앱 인스턴스 IP 가 변해도 sg-app 이 붙어있으면 자동 허용. IP 추적 불필요.

NACL 규칙 작성

번호 순 평가

NACL Inbound Rules:
  RuleNumber: 100
    Action: ALLOW
    Protocol: tcp
    PortRange: 443
    CidrBlock: 0.0.0.0/0

  RuleNumber: 200
    Action: ALLOW
    Protocol: tcp
    PortRange: 1024-65535    # ephemeral ports (응답)
    CidrBlock: 0.0.0.0/0

  RuleNumber: 300
    Action: DENY
    CidrBlock: 1.2.3.4/32   # 악의적 IP 차단

  RuleNumber: 32767
    Action: DENY
    Protocol: -1             # 기본 모두 차단
    CidrBlock: 0.0.0.0/0

[!IMPORTANT] 번호가 낮을수록 먼저 평가. 첫 번째 일치 규칙으로 결정. 100번에 ALLOW, 200번에 같은 IP 의 DENY 가 있으면 100번 ALLOW 가 우선.

특정 IP 차단 (NACL 만 가능)

NACL Rules:
  RuleNumber: 50
    Action: DENY
    CidrBlock: 1.2.3.0/24   # 악성 IP 범위 차단
  RuleNumber: 100
    Action: ALLOW
    CidrBlock: 0.0.0.0/0    # 나머지 허용

SG 는 Allow 만 지원하므로 특정 IP 차단에는 NACL 사용.

패킷 흐름: 전체 평가 순서

flowchart TD
    Internet["인터넷"] -->|"요청"| NACL_In["NACL Inbound<br/>(번호 순 평가)"]
    NACL_In -->|"ALLOW"| SG_In["SG Inbound<br/>(모든 규칙 종합)"]
    SG_In -->|"ALLOW"| Instance["EC2 / RDS"]
    Instance -->|"응답"| SG_Out["SG Outbound<br/>(stateful - 자동)"]
    SG_Out -->|"ALLOW"| NACL_Out["NACL Outbound<br/>(번호 순, ephemeral)"]
    NACL_Out -->|"ALLOW"| Internet

패킷이 통과하려면 NACL + SG 모두 통과해야 함.

레이어드 보안 설계

[인터넷]
    |
[NACL - subnet 경계]
 - 악성 IP 차단 (Deny)
 - 허용 포트 제한
    |
[Security Group - 인스턴스 경계]
 - 세밀한 포트 제어
 - SG-to-SG 참조
    |
[EC2/RDS/Lambda]

실전 사용 패턴:

NACL: subnet 레벨 coarse-grained 제어, 악성 IP 차단, 간단한 화이트리스트
SG: 인스턴스 레벨 fine-grained 제어, SG 참조, 대부분의 방화벽 규칙

변경 즉시 반영

SG 변경: 즉시 반영. 새로운 연결에 바로 적용. 기존 연결은 stateful 로 유지.

NACL 변경: 즉시 반영. 단, 기존 연결의 다음 패킷부터.

# SG 인바운드 규칙 추가
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# NACL 규칙 추가
aws ec2 create-network-acl-entry \
  --network-acl-id acl-12345 \
  --rule-number 100 \
  --protocol 6 \
  --rule-action allow \
  --ingress \
  --port-range From=443,To=443 \
  --cidr-block 0.0.0.0/0

Session Manager vs SSH: SG 설계

[!IMPORTANT] SSH 포트 22 를 인터넷에 오픈하지 말 것. AWS Systems Manager Session Manager 사용 시 SSH 포트 전혀 불필요.

# 잘못된 설계 (SSH 공개)
IngressRules:
  - Port: 22, CidrIp: 0.0.0.0/0   # 즉시 공격 대상

# 올바른 설계 (Session Manager)
IngressRules: []                    # 인바운드 없음
EgressRules:
  - Port: 443, CidrIp: 0.0.0.0/0  # SSM endpoint 접근용

비용

SG 와 NACL 모두 추가 비용 없음. VPC 의 기본 포함 기능.

함정

[!WARNING] NACL ephemeral port 누락: Stateless NACL 에서 응답 포트 (1024-65535) outbound 허용 없으면 응답 차단. SG 는 자동이지만 NACL 은 수동.

[!WARNING] SG outbound 모두 닫기: 일반적으로 outbound 는 모두 허용. 닫으면 외부 API 호출, DNS 조회 모두 차단. stateful 이므로 inbound 응답은 별개.

[!CAUTION] 너무 넓은 0.0.0.0/0 inbound: SSH/RDP 를 인터넷에 열면 즉시 brute force 공격 대상. Session Manager, Bastion Host, IP 제한 중 선택.

[!WARNING] SG 변경 후 기존 연결: SG 는 stateful 이므로 규칙 변경 후에도 기존 연결은 유지. 즉시 차단이 필요하면 인스턴스 재시작 또는 연결 강제 종료.

[!CAUTION] NACL 규칙 번호 간격: 10, 20, 30 처럼 촘촘하게 쓰면 중간 삽입 불가. 100, 200, 300 처럼 여유있게 번호 부여.

[!WARNING] SG 규칙 상한: 기본 60개 inbound + 60개 outbound. 너무 세분화된 규칙은 SG 여러 개로 분리하거나 NACL 사용.

[AWS] Security Group: ENI 레벨 stateful 방화벽

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS Security Group (SG) 은 AWS 리소스 (정확히는 ENI, Elastic Network Interface) 에 붙는 stateful 가상 방화벽. 인바운드/아웃바운드 트래픽을 IP + 포트 + 프로토콜 조합으로 제어하며, 연결 상태를 추적해 응답 트래픽은 자동으로 허용한다.

핵심 성질 세 가지:

Stateful - 요청을 허용하면 응답은 반대 방향 규칙 없이도 통과
Allow-only - Allow 규칙만. Deny 규칙 없음. 매칭 안 되면 암묵적 deny
ENI 레벨 - VPC / 서브넷이 아닌 각 [[aws-eni|ENI]] 에 부착 (인스턴스 × 여러 ENI 가능)

대비 개념:

[[aws-sg-vs-nacl|NACL]]: 서브넷 레벨, stateless, allow/deny 모두
[[aws-network-firewall|Network Firewall]]: VPC 레벨 관리형 방화벽
[[aws-waf|WAF]]: L7 HTTP 애플리케이션 방화벽

왜 ENI 레벨인가

전통 방화벽은 네트워크 경계 (subnet, VLAN) 에 배치. 하지만 클라우드에서는:

micro-segmentation: 같은 서브넷 안에서도 인스턴스별 다른 정책
동적 스케일링: 새 인스턴스가 뜨면 자동으로 방화벽 정책 상속
application-centric: “app 서버 → DB 서버 만 허용” 처럼 IP 대신 논리 그룹

SG 는 이걸 위해 ENI 단위로 붙는다. 인스턴스가 어느 서브넷에 있든, 몇 개의 ENI 를 갖든, 각 ENI 가 자기 SG 를 소유.

Stateful 의 의미 (핵심)

sequenceDiagram
    participant C as Client
    participant SG as SG (Stateful)
    participant S as Server (EC2)

    Note over SG: Inbound Rule: TCP 443 from 0.0.0.0/0<br/>Outbound Rule: (아무것도 없음)

    C->>SG: SYN → 443 (inbound)
    SG->>SG: "Inbound rule 매칭 → 허용<br/>+ connection 상태 기록"
    SG->>S: SYN forward

    S->>SG: SYN-ACK ← 443 → ephemeral (outbound)
    SG->>SG: "기존 connection 의 응답 → 자동 허용<br/>(outbound rule 검사 X)"
    SG-->>C: SYN-ACK forward

    Note over SG: 이후 이 세션의 모든 패킷은 자동 통과

의미: outbound 규칙을 아무것도 안 넣어도, inbound 로 허용된 연결의 응답은 자동으로 나감. 반대로 outbound 로 초기 요청한 연결의 응답은 inbound 규칙 없어도 들어옴.

NACL 과의 차이: NACL 은 각 패킷을 독립 검사 → response 도 별도 outbound 규칙 필요 → ephemeral port 범위 (1024-65535) 를 명시적으로 열어야 함. SG 는 이 부담이 없다.

규칙 구성

SG 규칙은 4개 필드:

필드	값
Type	Inbound / Outbound
Protocol	TCP / UDP / ICMP / All / 특정 프로토콜 번호
Port Range	단일 (`80`), 범위 (`8000-9000`), All (`-1`)
Source / Destination	CIDR (`10.0.0.0/16`) / 다른 SG ID / Prefix List

중요한 것: Source/Destination 에 다른 SG 를 참조 가능. 이게 AWS 만의 강력한 패턴.

SG Referencing (SG 체이닝) - AWS 특화 패턴

문제: IP 기반의 한계

전통 방화벽:

web-tier: 10.0.1.0/24 → app-tier: 10.0.2.0/24 → db-tier: 10.0.3.0/24
방화벽: "10.0.1.0/24 → 10.0.2.0/24 port 8080 허용"

문제:

오토스케일링으로 web-tier 가 다른 IP 대역에 확장되면 방화벽 규칙 수정
IP 대역 겹치면 실수 위험
신규 리전 확장 시 매번 반복

답: SG 를 Source 로 참조

web-sg = "web 서버들이 소속되는 SG"
app-sg = "app 서버들이 소속되는 SG"
  ├─ Inbound rule: port 8080, source = web-sg
  └─ 의미: "web-sg 를 부착한 어떤 ENI 든 8080 접근 허용"
db-sg = "DB 서버들이 소속되는 SG"
  └─ Inbound rule: port 5432, source = app-sg

이점:

IP 몰라도 됨 (스케일링/이동에 자동 대응)
논리적: “web → app → db” 흐름을 명확히 표현
규칙 수정 없이 새 인스턴스 자동 반영 (SG 만 부착하면 됨)

예: 3-Tier 웹 아키텍처

flowchart LR
    Client["인터넷"] --> ALB["ALB<br/>SG: alb-sg<br/>inbound 443 from 0.0.0.0/0"]

    ALB --> Web["Web tier EC2<br/>SG: web-sg<br/>inbound 8080 from alb-sg"]

    Web --> App["App tier EC2<br/>SG: app-sg<br/>inbound 8080 from web-sg"]

    App --> DB["RDS<br/>SG: db-sg<br/>inbound 5432 from app-sg"]

각 층이 바로 위층의 SG 만 허용. Client IP 나 서브넷 CIDR 을 몰라도 됨. 인스턴스 추가/삭제 자동 반영.

Default Security Group

각 VPC 생성 시 자동으로 하나 만들어짐 (default).

기본 규칙:

Inbound: 자기 SG 로부터 모든 트래픽 허용 (self-reference)
Outbound: 모든 트래픽 허용 (0.0.0.0/0)

의미: default SG 를 부착한 EC2 들은 서로 자유롭게 통신, 인터넷으로도 자유롭게 나감. 하지만 외부에서는 못 들어옴.

주의:

삭제 불가
수정은 가능하지만 실무는 default 를 그대로 두고 새 SG 를 만듦
여러 인스턴스가 실수로 default 만 갖고 있으면 서로 다 통신됨 = micro-segmentation 실패

신규 SG 의 기본값

새로 만든 SG (default 아닌 것):

Inbound: 규칙 없음 = deny all
Outbound: 0.0.0.0/0 모두 허용

즉 신규는 “인바운드 완전 차단, 아웃바운드 열림”. 필요한 인바운드만 명시 추가.

제한 (Quota)

항목	기본	조정
VPC 당 SG 수	2,500	상향 가능
SG 당 인바운드 규칙	60	상향 가능
SG 당 아웃바운드 규칙	60	상향 가능
ENI 당 SG 수	5	최대 16
SG 참조 (source/dest 로)	100 개 서로 다른 SG	-

총 유효 규칙 = SG 규칙 수 × ENI 당 SG 수 → 상한 60 × 5 = 300 (기본), 확장 시 60 × 16 = 960.

넘어서면: 인스턴스 시작 실패 또는 규칙 추가 실패. 규칙 통합 (여러 개를 하나로) 또는 SG 분리 필요.

Prefix List

여러 IP CIDR 을 하나의 논리 그룹으로 묶어 SG 규칙에 참조.

두 종류:

AWS 관리 Prefix List: com.amazonaws.<region>.s3 등 서비스 IP 대역
Customer 관리 Prefix List: 사용자 정의

예:

Customer Prefix List "office-networks":
  - 203.0.113.0/24  (서울 오피스)
  - 198.51.100.0/24 (도쿄 오피스)

SG rule: SSH 22 from prefix-list office-networks

오피스가 추가되면 prefix list 만 수정 → 참조하는 모든 SG 자동 반영.

AWS 관리 예: com.amazonaws.us-east-1.s3 는 S3 IP 대역을 자동으로 최신 유지. VPC Gateway Endpoint 없이 S3 접근 허용하려면 이 prefix list 참조.

서비스별 SG 특성

EC2

인스턴스에 여러 ENI, 각 ENI 에 여러 SG (최대 5)
인스턴스 자체가 SG 를 갖는 게 아니라 ENI 가.

RDS

하나의 RDS 인스턴스는 하나의 ENI (Multi-AZ 는 2개)
SG 는 이 ENI 에 부착
대개 db-sg 하나만 붙이고, source 는 app-sg 로

Lambda (in VPC)

Lambda 가 VPC 안에서 실행되면 Hyperplane ENI 사용 (자세히: [[aws-eni|ENI]])
SG 는 그 Hyperplane ENI 에 부착
Outbound 만 사용 (Lambda 는 서비스가 호출하므로 inbound 개념 X)

ECS / EKS (Fargate)

Task / Pod 마다 ENI (VPC CNI)
Task definition / Pod spec 에 SG 지정
Task 단위 micro-segmentation

ALB / NLB / GWLB

로드 밸런서 노드마다 ENI
SG 를 부착 (NLB 는 최근 지원)

관측: VPC Flow Logs

SG 로 허용/거부된 트래픽 관찰:

VPC Flow Log 활성화:
  → CloudWatch Logs / S3 로 flow 기록
  → 각 flow 의 srcaddr, dstaddr, srcport, dstport, action (ACCEPT / REJECT)

REJECT = SG 나 NACL 이 차단.

흔한 패턴

1. Bastion / SSH 접근 격리

bastion-sg: inbound 22 from 오피스 IP
private-app-sg: inbound 22 from bastion-sg

Bastion 만 오피스에서 접근, 내부는 bastion 을 경유.

2. Public Web + Private DB

alb-sg: inbound 443 from 0.0.0.0/0
web-sg: inbound 8080 from alb-sg
db-sg: inbound 5432 from web-sg

3. 자기 참조 (mesh)

cluster-sg: inbound "모든 포트" from cluster-sg (self-reference)

같은 SG 를 붙인 인스턴스끼리 자유 통신 (예: Kubernetes 노드끼리).

4. VPC Endpoint 접근 제어

endpoint-sg: inbound HTTPS 443 from app-sg
app-sg: outbound HTTPS 443 to endpoint-sg

SG vs NACL 요약

간단 비교. 자세히는 [[aws-sg-vs-nacl|SG vs NACL]].

축	SG	NACL
상태	Stateful	Stateless
적용 대상	ENI	Subnet
규칙	Allow 만	Allow + Deny
평가	모든 규칙 종합 (OR)	번호 순 (첫 매칭)
반환 트래픽	자동	명시적 규칙 필요
대표 용도	애플리케이션 격리	Subnet 경계, 특정 IP 차단

실무: SG 를 주로 쓰고, NACL 은 특별한 경우 (알려진 악성 IP 차단, 서브넷 격리) 에만.

함정

[!WARNING] Allow 만 존재. 특정 IP 차단이 필요하면 NACL. SG 는 화이트리스트만.

[!CAUTION] SG 규칙 수 제한 (60 in / 60 out). 큰 규칙 세트는 SG 를 분리하거나 prefix list 활용.

[!WARNING] default SG 를 그대로 둔 인스턴스 = 같은 default 인 것끼리 자유 통신. 예상 밖 접근성. 새 SG 를 만들어 명시적으로 부착.

[!IMPORTANT] RDS SG 를 CIDR (10.0.0.0/16) 로 열어두는 관행 = 다른 VPC 확장 시 커버 못 함. SG 참조 (from app-sg) 로 대체 권장.

[!CAUTION] SSH 22 를 0.0.0.0/0 으로 개방 = 공격 표면. [[aws-ssm-session-manager|SSM Session Manager]] 로 대체하고 22 는 닫기.

[!WARNING] Stateful 하지만 규칙 변경 시 기존 세션 재검사 (AWS 문서 기준 최근 개선). 오래된 관행 문서를 그대로 믿지 말 것.

[!IMPORTANT] SG 삭제 안 됨 다른 SG 나 ENI 가 참조 중이면. Dependency 정리 후 삭제.

[!CAUTION] Outbound 를 좁혔는데 서비스 안 됨 = 반환 트래픽은 자동이지만 외부로 요청 하는 흐름 (예: DB 가 외부 API 호출) 은 outbound 규칙 필요. 트래픽 방향 파악 필수.

[AWS] SES: Simple Email Service

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Amazon SES (Simple Email Service) 는 AWS 관리형 이메일 발송 / 수신 서비스. 대량 마케팅 메일, 트랜잭션 메일 (주문 확인, 비밀번호 재설정), 알림 메일을 SMTP 또는 API 로 발송하고, 원한다면 MX 레코드를 SES 로 향하게 해 수신도 가능.

핵심 정체성: 직접 SMTP 서버 (Postfix, Sendmail) 를 운영하지 않고 이메일 인프라를 AWS 에 위임.

왜 SES 인가

자체 SMTP 서버의 문제:

IP reputation 관리 = 대형 receiver (Gmail, Outlook) 가 새 IP 를 신뢰하기까지 warm-up 필요
Blocklist 관리 = Spamhaus 등재 시 즉시 배달 불가
SPF / DKIM / DMARC 설정 + 유지
bounce / complaint 처리 = 미처리 시 reputation 급락
재시도 / queue 관리
TLS 인증서 갱신

SES 의 답: 위 전부를 AWS 가 대신. 앱은 SendEmail API 만 호출.

아키텍처 (발송)

flowchart LR
    App["애플리케이션"]

    App -->|"SMTP or API"| SES["Amazon SES"]

    SES --> Identity{"검증된<br/>도메인/이메일?"}
    Identity -->|Yes| Reputation["Reputation 검사<br/>(bounce/complaint 율)"]
    Identity -->|No| Reject["Reject"]

    Reputation -->|OK| DKIMSign["DKIM 서명"]
    Reputation -->|경계| Throttle["throttle"]

    DKIMSign --> Send["수신자 mail server 로 SMTP"]

    Send --> Events["이벤트 발행<br/>(send/deliver/bounce/complaint/open/click)"]
    Events --> Kinesis[Kinesis]
    Events --> SNS[SNS]
    Events --> CW[CloudWatch Metrics]

발송 인터페이스

두 가지 API.

1. SMTP

표준 SMTP 프로토콜. 기존 mail 라이브러리 (nodemailer, django.core.mail, Rails ActionMailer 등) 그대로.

Endpoint: email-smtp.us-east-1.amazonaws.com
Port: 587 (STARTTLS) 또는 2587
Username/Password: SES SMTP credentials (IAM 사용자에서 생성)

적합: 이미 SMTP 클라이언트가 있는 앱, 서드파티 도구 (WordPress 등).

2. HTTPS API

SendEmail: 간단한 이메일 (subject + body + to)
SendRawEmail: 완전 MIME 제어 (첨부, HTML, multipart)
SendBulkTemplatedEmail: 템플릿 기반 대량 발송 (수신자당 개인화)

import boto3
ses = boto3.client('sesv2')

ses.send_email(
    FromEmailAddress='no-reply@example.com',
    Destination={'ToAddresses': ['user@example.com']},
    Content={
        'Simple': {
            'Subject': {'Data': '주문 확인'},
            'Body': {'Html': {'Data': '<h1>주문이 접수되었습니다</h1>'}}
        }
    },
    ConfigurationSetName='transactional'
)

적합: 서버리스 ([[aws-lambda|Lambda]]), IAM 기반 인증, 세밀한 제어.

Identity 검증

SES 는 아무 도메인이나 발송 불가. 소유권 검증된 identity 만 사용.

Email identity (단일 주소)

no-reply@example.com 하나만 검증. 빠름 (분 단위).

1. SES 에서 email identity 등록
2. AWS 가 검증 이메일 발송
3. 링크 클릭 → 검증 완료 (24시간 안)

적합: 프로토타입, 소규모.

Domain identity (도메인 전체)

example.com 전체 도메인 검증. 이후 도메인의 어떤 주소든 발송 가능.

1. SES 에서 domain identity 등록
2. AWS 가 DKIM 토큰 3 개 제공
3. Route 53 (또는 DNS 공급자) 에 CNAME 3 개 등록
4. AWS 가 자동 확인 → 검증 완료 (수 분 - 72시간)

적합: 프로덕션. noreply@, orders@, support@ 등 여러 주소 사용.

DKIM 옵션

Easy DKIM: AWS 가 키 쌍 생성, 고객은 CNAME 만
BYODKIM (Bring Your Own DKIM): 고객이 키 쌍 관리 (규제 목적)

SPF / DKIM / DMARC

이메일 도메인 인증 3대 표준. 셋 다 설정 권장.

표준	역할	설정 방법
SPF (Sender Policy Framework)	어떤 IP 가 이 도메인 대신 발송 가능한지 선언	DNS TXT: `v=spf1 include:amazonses.com ~all`
DKIM (DomainKeys Identified Mail)	발송자 도메인의 개인키로 서명, 수신자가 공개키로 검증	CNAME 3 개 (SES 가 제공)
DMARC	SPF/DKIM 실패 시 정책 (거부/격리/보고)	DNS TXT: `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com`

미설정 결과: Gmail / Outlook 이 스팸 폴더로 보냄. 최악의 경우 완전 차단.

Sandbox 모드 (신규 계정)

새 SES 계정은 sandbox 모드 로 시작. 제한:

수신자: 검증된 이메일 / 도메인 만 (Mailbox Simulator 예외)
속도: 200 emails / 24시간, 1 email / 초
수신 (receiving): 비활성
Suppression list 일괄 조작: 비활성

프로덕션 접근 요청:

AWS 콘솔 → SES → Account dashboard → Request production access
발송 유즈케이스, 웹사이트 URL, mail type (transactional / marketing), 대략 볼륨 명시
AWS Support 검토 (통상 24시간 안)

Reputation 관리 (매우 중요)

SES 는 계정 sender reputation 을 관리. 나쁘면 발송 정지.

지표

Bounce rate: 반송률 = (반송된 이메일 / 발송) × 100
Complaint rate: 스팸 신고율 = (신고 / 발송) × 100

임계값 (대략)

상태	Bounce	Complaint	결과
Healthy	< 2%	< 0.05%	정상
Under review	> 5%	> 0.1%	AWS 가 관찰
Paused	> 10%	> 0.5%	계정 발송 정지

정지된 계정은 개선 계획 제출 후 복구 요청 필요. 매우 신중.

대응

Suppression list: 반송/신고 이메일을 자동 억제 (재발송 안 함)
List cleaning: 발송 전 알려진 hard bounce 주소 제거
Unsubscribe 링크: 마케팅 메일 필수
DKIM/SPF/DMARC 완비 (수신자가 legitimate 로 인식)
Warm-up: 새 IP / 계정은 소량부터 시작해 점진 증가

Suppression List

바운스 / 신고된 주소는 자동으로 suppression list 에 등록되어 이후 발송 시도 자동 차단.

두 레벨:

Account-level: SES 계정에서 관리 (사용자가 조회/삭제 가능)
Global (AWS-wide): AWS 전체 suppression list (모든 계정 공유)

중요: hard bounce 는 재시도 안 되지만, 사용자가 이메일 주소 오타를 고치고 다시 등록하면 리스트에서 제거해야 함.

Configuration Set

Identity 에 적용되는 규칙 그룹.

포함:

Event destinations: 이벤트를 어디로 발행 (Kinesis / SNS / CloudWatch / Firehose)
- Send, Delivery, Open, Click, Bounce, Complaint, Reject
IP pool: 전용 IP 를 여러 목적별 pool 로 (트랜잭션 vs 마케팅)
Reputation tracking: 지표 추적
Sending options: 발송 활성/비활성

활용: 마케팅용 config set 은 open/click 추적, 트랜잭션용은 bounce/complaint 만 추적. 각 config set 이 다른 IP pool 사용.

Templates & Personalization

Template: "welcome-v2"
Subject: "환영합니다, {{name}}님"
Html: "<p>안녕하세요 {{name}}님, {{coupon}} 쿠폰을 드립니다.</p>"

SendBulkTemplatedEmail:
  Template: welcome-v2
  Destinations:
    - ToAddresses: [alice@example.com]
      ReplacementTemplateData: {"name": "Alice", "coupon": "SAVE10"}
    - ToAddresses: [bob@example.com]
      ReplacementTemplateData: {"name": "Bob", "coupon": "SAVE20"}

수신자당 개인화 + 대량 발송을 한 번의 API 호출로.

수신 (Receiving)

MX 레코드를 SES 로 향하게 하면 SES 가 도메인 이메일을 수신.

flowchart LR
    Sender["외부 발송자"] -->|SMTP| SES["SES Receiving"]

    SES --> Rules["Receipt Rules"]

    Rules -->|"recipient=support@"| S3[("S3 로 저장")]
    Rules -->|"recipient=noreply@"| SNS["SNS 알림"]
    Rules -->|"모든 spam"| Lambda["Lambda 처리"]
    Rules -->|"규제 대상"| WorkMail

Receipt Rules:

수신자 별 조건 (support@example.com, *@example.com 등)
액션: S3 저장, SNS 알림, Lambda 호출, Bounce, Stop rule set

용도:

고객 지원 티켓 시스템 (support@ → Lambda → Zendesk API)
알림 처리 (noreply-reply@ → 자동 답장)
규제 감사 (compliance@ → S3 아카이브)

주의: sandbox 계정은 수신 X. 프로덕션 접근 필요.

Virtual Deliverability Manager (VDM)

2023+ 추가 기능. Deliverability 분석 대시보드.

각 receiver (Gmail, Yahoo, Outlook) 별 배달률
Placement (inbox vs spam)
Reputation trend
문제 감지 시 권장 조치

Mail Manager (2024+)

Inbound 이메일 처리 파이프라인. 수신된 메일을 여러 단계 (스팸 필터, 정책, 라우팅) 로 처리.

이메일 게이트웨이 대체 (Proofpoint, Barracuda 등)
Rule 기반 라우팅 / 격리 / 아카이브

요금

발송: $0.10 / 1000 emails (EC2 에서 발송 시 첫 62,000 emails 무료)
수신: $0.10 / 1000 emails
첨부: $0.12 / GB
전용 IP: $24.95 / IP / 월

비교: Mailgun / SendGrid 등 SaaS 는 $10 - $50 / 월 (10K emails). SES 는 $1 정도로 훨씬 저렴.

실전 시나리오

1. 트랜잭션 이메일 (주문 확인)

[웹앱 checkout] → Lambda → SES SendEmail (config-set=transactional)
                                          → S3 로 이벤트 저장 (via Kinesis Firehose)

Transactional config set 은 open/click 추적 안 함 (개인정보 최소화)
Bounce/complaint 만 별도 처리

2. 마케팅 뉴스레터

[관리자] → SendBulkTemplatedEmail (config-set=marketing)
    → Dedicated IP pool
    → Kinesis Firehose → Redshift → 분석

마케팅 config set 은 open/click 추적
Dedicated IP 로 reputation 격리
Suppression list 로 unsubscribe 자동

3. 고객 지원 티켓

[사용자 이메일] → MX → SES Receiving → Lambda (본문 파싱) → Zendesk API
                                                         → S3 아카이브

support@example.com 을 SES 수신으로 → 자동 티켓 생성.

함정

[!WARNING] Sandbox 모드에서 프로덕션 배포 = 검증 안 된 주소에 발송 실패. 배포 전 반드시 프로덕션 접근 승인.

[!CAUTION] Bounce rate > 5% = AWS 관찰 시작. > 10% = 발송 정지. 리스트 정리 필수.

[!WARNING] DKIM / SPF / DMARC 미설정 = Gmail 스팸 폴더 or 완전 차단. 도메인 검증 후 3 종 세트 반드시 설정.

[!IMPORTANT] Marketing / Transactional 을 같은 IP = 마케팅 스팸이 트랜잭션 배달률까지 망침. Config set 으로 IP pool 분리.

[!CAUTION] Suppression list 무한 확대. 사용자가 오타 고쳐서 재등록하면 리스트에서 제거해야 배달됨. 관리 프로세스 필요.

[!WARNING] 첨부 크기 상한 (SES 는 raw email 40 MB 근처). 큰 파일은 [[aws-s3|S3]] Presigned URL 로 링크만.

[!IMPORTANT] 수신 (receiving) 은 sandbox 미지원. 프로덕션 접근 요청 필요.

[!CAUTION] SMTP credentials ≠ IAM access key. IAM 사용자에서 SMTP credentials 를 별도 생성해야 함 (같아 보여도 다름).

[AWS] SSM Automation: 운영 워크플로 런북

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

AWS SSM Automation 은 여러 단계로 이루어진 운영 워크플로를 런북 (runbook) 이라는 문서로 정의하고 실행 하는 [[aws-systems-manager|Systems Manager]] 기능. 각 단계는 [[aws-ec2|EC2]] 재시작, AMI 생성, [[aws-iam|IAM]] role 부여, [[aws-lambda|Lambda]] 호출, 다른 SSM 문서 실행 등을 조합할 수 있으며 조건 분기, 재시도, 승인 게이트 (approval), 병렬 실행을 지원.

한 줄 요약: [[aws-step-functions|Step Functions]] 의 인프라 운영 특화 버전. 서버/AWS API 를 조합한 복잡한 운영 작업을 코드화.

Automation vs 다른 SSM 기능

기능	성격	대표 사용
[[aws-ssm-run-command\|Run Command]]	단일 스크립트 다중 서버 실행	”nginx restart 전 서버 일괄”
[[aws-ssm-state-manager\|State Manager]]	원하는 상태 지속 유지	”SSM Agent 최신 유지”
Automation	여러 단계 + 여러 서비스 조합	”AMI 생성 → 인스턴스 교체 → DNS 업데이트 → 알림”

Run Command 는 “명령” 단위, Automation 은 “워크플로” 단위.

왜 Automation 인가

수동 운영 워크플로의 문제:

여러 서비스 조합 (EC2, EBS, IAM, ELB, Route53, Lambda …)
오류 시 롤백 로직 직접 구현
승인 게이트 (프로덕션 변경 전 관리자 승인) 없음
감사 및 재실행 어려움

Automation 의 답:

런북 (JSON/YAML) 으로 워크플로 코드화, 버전 관리
각 단계는 aws:executeAwsApi 로 AWS API 직접 호출 가능
aws:approve 로 인간 승인 스텝 삽입
aws:branch 로 조건 분기
실패 시 onFailure: Continue / Abort / RollbackAndContinue
CloudTrail 자동 감사

런북 구조

schemaVersion: '0.3'
description: 'EC2 를 재부팅하고 헬스체크 확인'

# 파라미터 (실행 시 입력)
parameters:
  InstanceId:
    type: String
    description: 재부팅할 EC2 ID
  HealthCheckUrl:
    type: String
    default: 'https://example.com/healthz'

# 실행할 IAM role (Automation 의 실행 컨텍스트)
assumeRole: '{{ automation:EXECUTION_ROLE_NAME }}'

# 단계 목록
mainSteps:
  - name: StopInstance
    action: aws:changeInstanceState
    inputs:
      InstanceIds: ['{{ InstanceId }}']
      DesiredState: stopped
    onFailure: Abort

  - name: WaitForStopped
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds: ['{{ InstanceId }}']
      PropertySelector: '$.Reservations[0].Instances[0].State.Name'
      DesiredValues: [stopped]

  - name: StartInstance
    action: aws:changeInstanceState
    inputs:
      InstanceIds: ['{{ InstanceId }}']
      DesiredState: running

  - name: WaitForRunning
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstanceStatus
      InstanceIds: ['{{ InstanceId }}']
      PropertySelector: '$.InstanceStatuses[0].InstanceStatus.Status'
      DesiredValues: [ok]

  - name: HealthCheck
    action: aws:runCommand
    inputs:
      DocumentName: AWS-RunShellScript
      InstanceIds: ['{{ InstanceId }}']
      Parameters:
        commands: ["curl -f {{ HealthCheckUrl }} || exit 1"]

  - name: NotifySlack
    action: aws:invokeLambdaFunction
    inputs:
      FunctionName: notify-slack
      Payload: '{"message": "EC2 {{ InstanceId }} restart OK"}'

주요 액션 (aws:*)

Automation 이 제공하는 빌트인 액션.

액션	용도
`aws:executeAwsApi`	임의 AWS API 호출 (가장 범용)
`aws:runCommand`	Run Command 실행 (스크립트 배포)
`aws:changeInstanceState`	EC2 start/stop/terminate
`aws:createImage`	AMI 생성
`aws:copyImage`	AMI 리전 복사
`aws:createStack` / `deleteStack`	CloudFormation 조작
`aws:invokeLambdaFunction`	Lambda 호출
`aws:invokeWebhook`	HTTP 호출 (Slack, Datadog 등)
`aws:executeStateMachine`	Step Functions 실행
`aws:branch`	조건 분기
`aws:approve`	인간 승인 게이트
`aws:pause`	특정 시각까지 대기
`aws:sleep`	N 초 대기
`aws:waitForAwsResourceProperty`	특정 리소스 상태까지 대기
`aws:executeAutomation`	다른 런북 호출 (재귀 조합)
`aws:executeScript`	Python/PowerShell 스크립트 직접 실행 (SSM 안에서)

실전 예제

예 1: 정기 AMI (Golden AMI) 생성

schemaVersion: '0.3'
description: '주간 golden AMI 생성'
parameters:
  SourceInstanceId: {type: String}
  ImageNamePrefix: {type: String, default: 'golden'}

mainSteps:
  - name: CreateAMI
    action: aws:createImage
    inputs:
      InstanceId: '{{ SourceInstanceId }}'
      ImageName: '{{ ImageNamePrefix }}-{{ global:DATE_TIME }}'
      NoReboot: false
    outputs:
      - Name: NewAmiId
        Selector: $.ImageId
        Type: String

  - name: WaitAMI
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeImages
      ImageIds: ['{{ CreateAMI.NewAmiId }}']
      PropertySelector: '$.Images[0].State'
      DesiredValues: [available]

  - name: TagAMI
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: CreateTags
      Resources: ['{{ CreateAMI.NewAmiId }}']
      Tags:
        - Key: Type
          Value: Golden
        - Key: CreatedBy
          Value: 'ssm-automation'

[[aws-eventbridge|EventBridge]] 스케줄러 → 매주 이 런북 실행 → 최신 golden AMI 자동 유지.

예 2: 승인 게이트가 있는 프로덕션 배포

mainSteps:
  - name: PreCheck
    action: aws:runCommand
    inputs:
      DocumentName: AWS-RunShellScript
      Targets: [{Key: 'tag:Env', Values: [prod]}]
      Parameters:
        commands: ["./pre-deploy-check.sh"]

  - name: WaitForApproval
    action: aws:approve
    inputs:
      NotificationArn: 'arn:aws:sns:...:deploy-approvers'
      Message: 'Pre-check 통과. 프로덕션 배포 승인 필요.'
      MinRequiredApprovals: 2
      Approvers:
        - 'arn:aws:iam::123:role/OpsLead'
        - 'arn:aws:iam::123:role/SREOncall'

  - name: RollingDeploy
    action: aws:runCommand
    inputs:
      DocumentName: 'app-deploy'
      Targets: [{Key: 'tag:Env', Values: [prod]}]
      Parameters:
        version: ['{{ Version }}']
      MaxConcurrency: '10%'
      MaxErrors: '20%'

Ops 리더 2명이 승인해야 실제 배포 진행. 승인 대기 중 자동 알림.

예 3: 셀프 힐링 (자가 복구)

CloudWatch Alarm → Automation 실행. 예: EBS 볼륨 사용률 80% 초과 → 자동 확장.

mainSteps:
  - name: GetCurrentSize
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: DescribeVolumes
      VolumeIds: ['{{ VolumeId }}']
    outputs:
      - Name: CurrentSize
        Selector: '$.Volumes[0].Size'
        Type: Integer

  - name: CalculateNewSize
    action: aws:executeScript
    inputs:
      Runtime: python3.11
      Handler: main
      Script: |
        def main(events, context):
            return {'NewSize': int(events['current'] * 1.5)}
      InputPayload:
        current: '{{ GetCurrentSize.CurrentSize }}'
    outputs:
      - Name: NewSize
        Selector: $.Payload.NewSize
        Type: Integer

  - name: ModifyVolume
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: ModifyVolume
      VolumeId: '{{ VolumeId }}'
      Size: '{{ CalculateNewSize.NewSize }}'

AWS 제공 런북 (사전 정의)

100+ 개의 표준 런북 이미 존재. AWS-* 접두사.

런북	용도
`AWS-RestartEC2Instance`	EC2 재부팅
`AWS-StopEC2Instance`	EC2 중지
`AWS-CreateImage`	AMI 생성
`AWS-UpdateLinuxAmi`	Linux AMI 패치 후 새 AMI 생성
`AWS-EnableS3BucketEncryption`	S3 버킷 암호화 활성
`AWS-DisablePublicAccessForSecurityGroup`	0.0.0.0/0 규칙 제거
`AWSSupport-TroubleshootSSH`	SSH 접속 문제 진단
`AWSSupport-CopyEBSSnapshot`	스냅샷 복사
`AWS-RestoreRdsFromSnapshot`	RDS 복원

활용: [[aws-config|AWS Config]] 규칙 위반 → 자동 remediation 런북 실행 (예: 퍼블릭 SG 발견 → 자동 제거).

실행 방법

1. AWS 콘솔

SSM → Automation → Execute automation. 폼에 파라미터 입력.

2. CLI

aws ssm start-automation-execution \
  --document-name "app-deploy-with-approval" \
  --parameters "Version=v1.2.3" \
  --target-parameter-name "InstanceId" \
  --targets "Key=tag:Env,Values=prod" \
  --max-concurrency 10 \
  --max-errors 2

3. [[aws-eventbridge|EventBridge]] 트리거

CloudWatch Alarm, S3 이벤트, 스케줄 등 → EventBridge Rule → Automation 실행.

4. [[aws-config|AWS Config]] Remediation

Config 규칙 위반 감지 → 자동 remediation 런북 지정.

실행 모드

AutoApprove: 승인 게이트 자동 통과 (테스트 / dev)
Rate Control: 대량 배포 시 concurrency + error threshold
Interactive: 매 스텝 실행 전 사용자 확인 (조사 목적)

요금

일부 무료: 매월 100,000 스텝 무료
초과 시: 스텝당 $0.002 (예: 스텝 10 개 런북 10 회 = 100 스텝)
하위 서비스 (EC2, Lambda 등) 요금 별도

함정

[!WARNING] 런북 assumeRole 권한 부족 = 스텝 중간 실패. IAM 정책은 사용하는 모든 API (ec2:*, iam:*, s3:* 등) 를 포함해야 함. 최소 권한 유지하되 필요 액션 다.

[!CAUTION] onFailure: Continue 남용 = 중요 스텝 실패해도 진행 → 반쯤 완료된 상태. 대부분 Abort 가 안전.

[!WARNING] aws:approve timeout (기본 7일). 승인자 알림 [[aws-sns|SNS]] 필수. 승인자가 놓치면 실행 만료.

[!IMPORTANT] aws:executeScript 는 Python 3.x / PowerShell 지원. 무거운 로직은 Lambda 로 분리해 aws:invokeLambdaFunction 이 좋음.

[!CAUTION] 런북 버전 명시. --document-version "$LATEST" 는 재현 불가. 프로덕션은 "3" 등 고정.

[!WARNING] 파라미터 검증 없음 = 잘못된 값 그대로 실행. 스크립트로 사전 검증 스텝 추가.

[!IMPORTANT] 잘못 만든 런북이 대량 리소스 파괴 가능. Dev 계정에서 충분히 테스트 후 프로덕션. Config remediation 연결 전 dry-run.

김신건의 로그 - 위키 / cloud

[AWS] Amazon Pinpoint: EoS & End User Messaging 마이그레이션

정의

End of Support 타임라인 (핵심)

무엇이 종료되고 무엇이 남는가

종료되는 것 (2026-10-30)

남는 것 (계속 유지)

마이그레이션 매핑

AWS End User Messaging

End User Messaging SMS

End User Messaging Push

End User Messaging Voice

이메일: Amazon SES

캠페인 / 저니 대체 아키텍처

OTP (One-Time Password)

Pinpoint 를 계속 쓰던 사용자를 위한 체크리스트

신규 프로젝트라면

함정

관련 위키

[AWS] Amazon Redshift

정의

왜 데이터 웨어하우스 인가

아키텍처

노드 유형 (2025-2026)

RA3 (권장)

DS2 (Deprecated)

DC2 (Deprecated)

Redshift Serverless

Provisioned RA3 vs Serverless

Managed Storage (RMS)

분산 스타일 (Distribution Style)

EVEN

KEY

ALL

AUTO

정렬 키 (Sort Key)

압축 (Encoding)

COPY (대량 로드)

Redshift Spectrum (S3 쿼리)

Data Sharing

Zero-ETL Integrations

Streaming Ingestion

Redshift ML

Concurrency Scaling

WLM (Workload Management)

VACUUM & ANALYZE

백업 & 복구

성능 튜닝

1. DISTKEY / SORTKEY 설계

2. COPY 성능

3. 쿼리 프로파일

4. Materialized View

5. Result Cache

보안

데이터 API (redshift-data)

함정

Redshift vs 다른 데이터 웨어하우스

관련 위키

[AWS] Athena: 서버리스 SQL on S3

정의

사용 상황

아키텍처

Engine v2 vs v3

요금 모델

1. On-demand (기본)

2. Capacity Reservation (예약)

3. Athena for Apache Spark

4. Federated Query

Workgroups

파일 포맷별 비용 영향

파티션 (Partitions)

Partition Projection

CTAS (CREATE TABLE AS SELECT)

Apache Iceberg (Athena 에서)

Federated Query

Query Result Reuse (2023+)

Prepared Statements & Views

Athena for Apache Spark

[[aws-athena|Athena]] vs [[aws-redshift-spectrum|Redshift Spectrum]] vs [[aws-redshift|Redshift]]

사용 예제

데이터 API (`redshift-data`)