← Theory 목록으로

Session 10: 아키텍처 사례 연구

E-Commerce, IoT, 데이터 메시, 비용 최적화

1. E-Commerce 실시간 분석

대규모 이커머스 플랫폼의 실시간 분석 아키텍처입니다. 클릭스트림, 주문, 재고 데이터를 실시간으로 처리하여 개인화 추천과 대시보드를 제공합니다.

실시간 분석 아키텍처
┌─────────────────────────────────────────────────────────────────────────────┐
│                    E-Commerce Real-time Analytics                            │
│                                                                              │
│  Data Sources                                                                │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐                        │
│  │ Web/App │  │  Orders │  │Inventory│  │  Logs   │                        │
│  │Clickstr.│  │   DB    │  │   DB    │  │         │                        │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘                        │
│       │            │            │            │                              │
│       ▼            ▼            ▼            ▼                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │                    Amazon Kinesis Data Streams                          ││
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐                  ││
│  │  │ clickstream  │  │   orders     │  │  inventory   │                  ││
│  │  │   (100 shards)│  │  (20 shards) │  │  (10 shards) │                  ││
│  │  └──────────────┘  └──────────────┘  └──────────────┘                  ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                              │                                              │
│              ┌───────────────┼───────────────┐                              │
│              ▼               ▼               ▼                              │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐               │
│  │ Managed Flink   │ │ Kinesis Firehose│ │    Lambda       │               │
│  │                 │ │                 │ │                 │               │
│  │ • 실시간 집계   │ │ • S3 적재       │ │ • 알림 트리거   │               │
│  │ • 세션 분석     │ │ • Parquet 변환  │ │ • 재고 부족     │               │
│  │ • 이상 탐지     │ │ • 파티셔닝      │ │ • 대량 주문     │               │
│  └────────┬────────┘ └────────┬────────┘ └────────┬────────┘               │
│           │                   │                   │                         │
│           ▼                   ▼                   ▼                         │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐               │
│  │   OpenSearch    │ │   S3 Data Lake  │ │      SNS        │               │
│  │   (Dashboard)   │ │   (Analytics)   │ │   (Alerts)      │               │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘               │
└─────────────────────────────────────────────────────────────────────────────┘

1.2 실시간 처리 코드

Flink SQL - 실시간 매출 집계
-- 1. 소스 테이블 정의
CREATE TABLE orders (
    order_id STRING,
    customer_id STRING,
    product_id STRING,
    amount DECIMAL(10,2),
    category STRING,
    order_time TIMESTAMP(3),
    WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (
    'connector' = 'kinesis',
    'stream' = 'orders',
    'aws.region' = 'ap-northeast-2',
    'format' = 'json'
);

-- 2. 실시간 매출 집계 (1분 윈도우)
CREATE TABLE sales_per_minute (
    window_start TIMESTAMP,
    window_end TIMESTAMP,
    category STRING,
    total_sales DECIMAL(12,2),
    order_count BIGINT,
    avg_order_value DECIMAL(10,2)
) WITH (
    'connector' = 'opensearch',
    'hosts' = 'https://search-xxx.ap-northeast-2.es.amazonaws.com:443',
    'index' = 'sales-realtime'
);

INSERT INTO sales_per_minute
SELECT 
    TUMBLE_START(order_time, INTERVAL '1' MINUTE) as window_start,
    TUMBLE_END(order_time, INTERVAL '1' MINUTE) as window_end,
    category,
    SUM(amount) as total_sales,
    COUNT(*) as order_count,
    AVG(amount) as avg_order_value
FROM orders
GROUP BY 
    TUMBLE(order_time, INTERVAL '1' MINUTE),
    category;

-- 3. 이상 탐지 (급격한 주문 증가)
CREATE TABLE anomaly_alerts (
    alert_time TIMESTAMP,
    category STRING,
    current_count BIGINT,
    avg_count DOUBLE,
    alert_type STRING
) WITH (
    'connector' = 'kinesis',
    'stream' = 'alerts',
    'format' = 'json'
);

INSERT INTO anomaly_alerts
SELECT 
    window_end as alert_time,
    category,
    order_count as current_count,
    avg_order_count as avg_count,
    'HIGH_ORDER_VOLUME' as alert_type
FROM (
    SELECT 
        TUMBLE_END(order_time, INTERVAL '5' MINUTE) as window_end,
        category,
        COUNT(*) as order_count,
        AVG(COUNT(*)) OVER (
            PARTITION BY category 
            ORDER BY TUMBLE_END(order_time, INTERVAL '5' MINUTE)
            ROWS BETWEEN 12 PRECEDING AND 1 PRECEDING
        ) as avg_order_count
    FROM orders
    GROUP BY TUMBLE(order_time, INTERVAL '5' MINUTE), category
)
WHERE order_count > avg_order_count * 2;  -- 평균의 2배 초과

핵심 설계 포인트

확장성
  • • Kinesis 샤드 수로 처리량 조절
  • • Flink 병렬 처리
  • • OpenSearch 노드 확장
내결함성
  • • Kinesis 24시간 데이터 보존
  • • Flink 체크포인트
  • • S3 백업 (Firehose)

2. IoT 데이터 레이크

제조업 IoT 센서 데이터를 수집하여 예측 정비와 품질 분석을 수행하는 아키텍처입니다.

IoT 데이터 레이크 아키텍처
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Manufacturing IoT Data Lake                               │
│                                                                              │
│  Edge Layer                                                                  │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  Factory Floor                                                          ││
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐                    ││
│  │  │Sensor 1 │  │Sensor 2 │  │Sensor N │  │ PLC     │                    ││
│  │  │Temp/Vib │  │Pressure │  │ ...     │  │         │                    ││
│  │  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘                    ││
│  │       └────────────┴────────────┴────────────┘                          ││
│  │                           │                                              ││
│  │                    ┌──────▼──────┐                                      ││
│  │                    │ Greengrass  │  Edge Processing                     ││
│  │                    │ • 필터링    │  • 로컬 ML 추론                       ││
│  │                    │ • 집계      │  • 오프라인 버퍼                      ││
│  │                    └──────┬──────┘                                      ││
│  └───────────────────────────┼─────────────────────────────────────────────┘│
│                              │ MQTT                                         │
│                              ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │                    AWS IoT Core                                         ││
│  │  ┌──────────────────────────────────────────────────────────────────┐  ││
│  │  │  IoT Rules Engine                                                 │  ││
│  │  │  ├── Rule 1: All data → Kinesis Data Firehose → S3              │  ││
│  │  │  ├── Rule 2: Anomaly → Lambda → SNS (Alert)                     │  ││
│  │  │  └── Rule 3: Aggregated → Timestream (Time-series)              │  ││
│  │  └──────────────────────────────────────────────────────────────────┘  ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                              │                                              │
│              ┌───────────────┼───────────────┐                              │
│              ▼               ▼               ▼                              │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐               │
│  │   S3 Data Lake  │ │   Timestream    │ │   SageMaker     │               │
│  │                 │ │                 │ │                 │               │
│  │ Raw → Curated   │ │ Time-series DB  │ │ Predictive      │               │
│  │ → Analytics     │ │ Real-time Query │ │ Maintenance     │               │
│  └────────┬────────┘ └────────┬────────┘ └────────┬────────┘               │
│           │                   │                   │                         │
│           └───────────────────┴───────────────────┘                         │
│                              │                                              │
│                              ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │                    Grafana Dashboard                                    ││
│  │  • 실시간 센서 모니터링  • 이상 탐지 알림  • 예측 정비 일정            ││
│  └─────────────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────────────┘

2.2 데이터 레이어 설계

3-Layer Data Lake
s3://iot-data-lake/
├── raw/                          # Bronze Layer
│   └── sensor_data/
│       └── year=2024/month=01/day=15/hour=10/
│           └── data-00001.json.gz
│
├── curated/                      # Silver Layer
│   └── sensor_readings/
│       └── device_type=temperature/
│           └── year=2024/month=01/
│               └── data.parquet
│
└── analytics/                    # Gold Layer
    ├── hourly_aggregates/
    │   └── year=2024/month=01/
    │       └── aggregates.parquet
    └── anomaly_events/
        └── year=2024/month=01/
            └── anomalies.parquet

// Glue ETL - Raw to Curated

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
from pyspark.sql.functions import *

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

# Raw 데이터 읽기
raw_df = glueContext.create_dynamic_frame.from_catalog(
    database="iot_raw",
    table_name="sensor_data"
).toDF()

# 데이터 정제 및 변환
curated_df = raw_df \
    .filter(col("value").isNotNull()) \
    .filter(col("value").between(-100, 500)) \
    .withColumn("reading_date", to_date("timestamp")) \
    .withColumn("reading_hour", hour("timestamp")) \
    .dropDuplicates(["device_id", "timestamp"])

# Parquet로 저장 (파티셔닝)
curated_df.write \
    .mode("append") \
    .partitionBy("device_type", "year", "month") \
    .parquet("s3://iot-data-lake/curated/sensor_readings/")

job.commit()

핵심 설계 포인트

Edge 처리
  • • Greengrass로 로컬 필터링/집계
  • • 네트워크 비용 절감
  • • 오프라인 시 로컬 버퍼링
시계열 최적화
  • • Timestream: 실시간 쿼리
  • • S3 + Athena: 장기 분석
  • • 시간 기반 파티셔닝

3. 엔터프라이즈 데이터 메시

대기업의 분산된 데이터 도메인을 연결하는 데이터 메시 아키텍처입니다. 각 도메인이 데이터 제품을 소유하고 중앙 거버넌스를 통해 공유합니다.

데이터 메시 아키텍처
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Enterprise Data Mesh                                      │
│                                                                              │
│  Central Governance (Account: 000000000000)                                  │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐         ││
│  │  │ Lake Formation  │  │  Glue Catalog   │  │   DataZone      │         ││
│  │  │ (Permissions)   │  │  (Metadata)     │  │   (Discovery)   │         ││
│  │  └─────────────────┘  └─────────────────┘  └─────────────────┘         ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                              │ RAM Sharing                                   │
│              ┌───────────────┼───────────────┬───────────────┐              │
│              ▼               ▼               ▼               ▼              │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ │
│  │ Sales Domain    │ │ Marketing Domain│ │ Finance Domain  │ │ HR Domain │ │
│  │ (111111111111)  │ │ (222222222222)  │ │ (333333333333)  │ │(444444444)│ │
│  │                 │ │                 │ │                 │ │           │ │
│  │ Data Products:  │ │ Data Products:  │ │ Data Products:  │ │ Data Prod:│ │
│  │ • orders        │ │ • campaigns     │ │ • revenue       │ │ • headcnt │ │
│  │ • customers     │ │ • attribution   │ │ • costs         │ │ • payroll │ │
│  │ • pipeline      │ │ • segments      │ │ • forecasts     │ │           │ │
│  │                 │ │                 │ │                 │ │           │ │
│  │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │           │ │
│  │ │ S3 + Glue   │ │ │ │ S3 + Glue   │ │ │ │ Redshift    │ │ │           │ │
│  │ │ + Athena    │ │ │ │ + Athena    │ │ │ │ + Spectrum  │ │ │           │ │
│  │ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │ │           │ │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘ └───────────┘ │
│                                                                              │
│  Consumer Account (555555555555)                                             │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  Analytics Team                                                         ││
│  │  ┌─────────────────────────────────────────────────────────────────┐   ││
│  │  │  Resource Links (via Lake Formation)                            │   ││
│  │  │  • sales.orders        → SELECT (columns: id, amount, date)    │   ││
│  │  │  • marketing.campaigns → SELECT (all columns)                  │   ││
│  │  │  • finance.revenue     → SELECT (row filter: region='APAC')    │   ││
│  │  └─────────────────────────────────────────────────────────────────┘   ││
│  │                                                                         ││
│  │  Athena → Cross-domain JOIN queries                                    ││
│  └─────────────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────────────┘

3.2 데이터 제품 정의

Data Product as Code

// Terraform - Data Product 정의

# 데이터 제품: Sales Orders
module "data_product_orders" {
  source = "./modules/data-product"

  name        = "orders"
  domain      = "sales"
  owner       = "sales-data-team"
  description = "Customer order transactions"

  # 스토리지
  s3_bucket = aws_s3_bucket.sales_data.id
  s3_prefix = "products/orders/"

  # 스키마
  glue_database = aws_glue_catalog_database.sales.name
  glue_table    = "orders"

  # 품질 규칙
  quality_rules = [
    "IsComplete \"order_id\"",
    "IsUnique \"order_id\"",
    "ColumnValues \"amount\" > 0",
    "Freshness \"created_at\" <= 24 hours"
  ]

  # 공유 설정
  share_with_accounts = [
    { account_id = "555555555555", permissions = ["SELECT"] }
  ]

  # 컬럼 수준 보안
  column_permissions = {
    "555555555555" = {
      include_columns = ["order_id", "amount", "order_date", "region"]
      exclude_columns = ["customer_email", "customer_phone"]
    }
  }

  # SLA
  sla = {
    freshness_hours = 24
    availability    = 99.9
  }
}

# Lake Formation 권한 자동 설정
resource "aws_lakeformation_permissions" "orders_share" {
  for_each = toset(module.data_product_orders.consumer_accounts)

  principal   = "arn:aws:iam::${each.value}:root"
  permissions = ["SELECT", "DESCRIBE"]

  table_with_columns {
    database_name = module.data_product_orders.glue_database
    name          = module.data_product_orders.glue_table
    column_names  = module.data_product_orders.allowed_columns[each.value]
  }
}

데이터 메시 원칙

도메인 소유권
  • • 각 도메인이 데이터 제품 소유
  • • 품질, SLA 책임
  • • 독립적인 기술 스택
연합 거버넌스
  • • Lake Formation 중앙 권한
  • • 공통 메타데이터 표준
  • • DataZone 데이터 카탈로그

4. 핵심 요약

아키텍처 패턴 요약

E-Commerce 실시간 분석

  • • Kinesis → Flink → OpenSearch (실시간 대시보드)
  • • Kinesis → Firehose → S3 (배치 분석용 백업)
  • • Flink SQL로 윈도우 집계, 이상 탐지
  • • Lambda로 알림 트리거 (재고 부족, 대량 주문)

IoT 데이터 레이크

  • • Greengrass Edge 처리 (필터링, 로컬 ML)
  • • IoT Core Rules → Firehose/Lambda/Timestream
  • • 3-Layer: Raw(JSON) → Curated(Parquet) → Analytics
  • • Timestream: 실시간 시계열 쿼리

엔터프라이즈 데이터 메시

  • • 도메인별 AWS 계정 분리
  • • Lake Formation + RAM으로 Cross-account 공유
  • • DataZone으로 데이터 제품 검색
  • • 컬럼/행 수준 보안으로 세분화된 접근 제어

🎯 시험 포인트

실시간 vs 배치

Flink = 실시간 집계, Glue = 배치 ETL

IoT 아키텍처

Greengrass(Edge) → IoT Core → Kinesis/S3

시계열 데이터

Timestream = 실시간, S3+Athena = 장기 분석

데이터 메시

Lake Formation + RAM = Cross-account 공유

아키텍처 선택 가이드

요구사항권장 아키텍처핵심 서비스
실시간 대시보드스트리밍 분석Kinesis + Flink + OpenSearch
IoT 센서 데이터IoT 데이터 레이크IoT Core + Timestream + S3
대규모 배치 분석데이터 레이크S3 + Glue + Athena
BI/리포팅데이터 웨어하우스Redshift + QuickSight
멀티 도메인 공유데이터 메시Lake Formation + DataZone
ML 파이프라인MLOpsSageMaker Pipelines + Feature Store

🎓 AWS Data Engineer 시험 준비 완료!

10개 세션을 통해 AWS 데이터 플랫폼의 핵심 개념과 서비스를 학습했습니다.

Session 1-2

수집

Session 3

저장

Session 4-5

처리

Session 6-7

분석

Session 8-10

거버넌스/운영

5. 비용 최적화 전략

데이터 플랫폼 비용은 스토리지, 컴퓨팅, 데이터 전송으로 구성됩니다. 각 영역별 최적화 전략을 살펴봅니다.

비용 구성 요소
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Data Platform Cost Breakdown                              │
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  Storage (30-40%)                                                       ││
│  │  ├── S3 Standard: $0.023/GB/month                                       ││
│  │  ├── S3 IA: $0.0125/GB/month (45% 절감)                                 ││
│  │  ├── S3 Glacier: $0.004/GB/month (83% 절감)                             ││
│  │  └── Redshift RA3: $0.024/GB/month (Managed Storage)                    ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  Compute (40-50%)                                                       ││
│  │  ├── Glue ETL: $0.44/DPU-hour                                           ││
│  │  ├── Athena: $5/TB scanned                                              ││
│  │  ├── Redshift: $0.25-$13.04/hour (노드 타입별)                          ││
│  │  ├── EMR: EC2 비용 + EMR 비용                                           ││
│  │  └── Kinesis: $0.015/shard-hour + $0.014/million PUT                    ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  Data Transfer (10-20%)                                                 ││
│  │  ├── 같은 리전 내: 무료 (대부분)                                        ││
│  │  ├── 리전 간: $0.02/GB                                                  ││
│  │  ├── 인터넷 아웃바운드: $0.09/GB (첫 10TB)                              ││
│  │  └── VPC Endpoint: 무료 (S3 Gateway)                                    ││
│  └─────────────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────────────┘

5.1 스토리지 최적화

S3 라이프사이클 정책
# S3 Intelligent-Tiering + Lifecycle
resource "aws_s3_bucket_lifecycle_configuration" "data_lake" {
  bucket = aws_s3_bucket.data_lake.id

  # Raw 데이터: 빠른 전환
  rule {
    id     = "raw-data-lifecycle"
    status = "Enabled"

    filter {
      prefix = "raw/"
    }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER_IR"  # 즉시 검색 가능
    }

    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }

    expiration {
      days = 2555  # 7년 보존 후 삭제
    }
  }

  # Curated 데이터: 자주 접근
  rule {
    id     = "curated-data-lifecycle"
    status = "Enabled"

    filter {
      prefix = "curated/"
    }

    transition {
      days          = 90
      storage_class = "INTELLIGENT_TIERING"
    }
  }

  # 불완전 멀티파트 업로드 정리
  rule {
    id     = "abort-incomplete-multipart"
    status = "Enabled"

    abort_incomplete_multipart_upload {
      days_after_initiation = 7
    }
  }
}

# S3 Intelligent-Tiering 아카이브 설정
resource "aws_s3_bucket_intelligent_tiering_configuration" "data_lake" {
  bucket = aws_s3_bucket.data_lake.id
  name   = "archive-config"

  tiering {
    access_tier = "ARCHIVE_ACCESS"
    days        = 90
  }

  tiering {
    access_tier = "DEEP_ARCHIVE_ACCESS"
    days        = 180
  }
}

예상 절감

  • • Standard → IA: 45% 절감
  • • Standard → Glacier: 83% 절감
  • • Intelligent-Tiering: 자동 최적화

주의사항

  • • IA: 최소 30일 저장
  • • Glacier: 검색 비용 발생
  • • 접근 패턴 분석 필요

5.2 컴퓨팅 최적화

서비스별 최적화
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Compute Cost Optimization                                 │
│                                                                              │
│  Athena                                                                      │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  Before: SELECT * FROM logs (1 TB CSV) = $5.00                         ││
│  │  After:  SELECT col1, col2 FROM logs_parquet                           ││
│  │          WHERE date = '2024-01-15' (10 GB) = $0.05                      ││
│  │                                                                          ││
│  │  최적화: Parquet + 파티셔닝 + 컬럼 선택 = 99% 절감                      ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                                                                              │
│  Glue ETL                                                                    │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  • Auto Scaling 활성화: 필요한 만큼만 DPU 사용                          ││
│  │  • Flex 실행: 비프로덕션 작업에 50% 절감                                ││
│  │  • Job Bookmark: 증분 처리로 처리량 감소                                ││
│  │  • 적절한 Worker Type: G.1X vs G.2X                                     ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                                                                              │
│  Redshift                                                                    │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  • Reserved Instances: 1년 약정 시 ~30% 절감                            ││
│  │  • Serverless: 가변 워크로드에 적합                                     ││
│  │  • Pause/Resume: 비사용 시간 비용 절감                                  ││
│  │  • Spectrum: 콜드 데이터는 S3에서 직접 쿼리                             ││
│  └─────────────────────────────────────────────────────────────────────────┘│
│                                                                              │
│  Kinesis                                                                     │
│  ┌─────────────────────────────────────────────────────────────────────────┐│
│  │  • On-demand: 예측 불가 트래픽                                          ││
│  │  • Provisioned: 안정적 트래픽 (샤드 수 최적화)                          ││
│  │  • Enhanced Fan-out: 필요시만 사용                                      ││
│  │  • 데이터 보존 기간 최소화                                              ││
│  └─────────────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────────────┘

5.3 비용 모니터링

// Cost Explorer 태그 기반 분석

# 리소스 태깅 전략
resource "aws_s3_bucket" "data_lake" {
  bucket = "data-lake-prod"

  tags = {
    Project     = "data-platform"
    Environment = "production"
    Team        = "data-engineering"
    CostCenter  = "DE-001"
    Application = "analytics"
  }
}

# AWS Budgets 알림
resource "aws_budgets_budget" "data_platform" {
  name         = "data-platform-monthly"
  budget_type  = "COST"
  limit_amount = "10000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name   = "TagKeyValue"
    values = ["user:Project$data-platform"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["data-team@example.com"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_sns_topic_arn   = [aws_sns_topic.budget_alerts.arn]
  }
}

비용 최적화 체크리스트

스토리지
  • ☐ S3 라이프사이클 정책
  • ☐ Intelligent-Tiering 활성화
  • ☐ 불필요한 버전 삭제
  • ☐ 압축 포맷 사용 (Parquet)
컴퓨팅
  • ☐ Reserved Instances 검토
  • ☐ Serverless 옵션 평가
  • ☐ Auto Scaling 활성화
  • ☐ 비사용 리소스 정리

6. 핵심 요약 & 시험 준비

아키텍처 사례 핵심 포인트

E-Commerce 실시간 분석

  • • Kinesis → Flink → OpenSearch (실시간 대시보드)
  • • Kinesis → Firehose → S3 (배치 분석용 백업)
  • • Flink SQL로 윈도우 집계, 이상 탐지
  • • Lambda로 알림 트리거

IoT 데이터 레이크

  • • Greengrass Edge 처리 (필터링, 로컬 ML)
  • • IoT Core Rules → Firehose/Lambda/Timestream
  • • 3-Layer: Raw → Curated → Analytics
  • • Timestream: 실시간 시계열 쿼리

엔터프라이즈 데이터 메시

  • • 도메인별 AWS 계정 분리
  • • Lake Formation + RAM으로 Cross-account 공유
  • • DataZone으로 데이터 제품 검색
  • • 컬럼/행 수준 보안

비용 최적화

  • • S3 라이프사이클: 60%+ 스토리지 비용 절감
  • • Athena: Parquet + 파티셔닝 = 99% 절감
  • • Redshift: Reserved Instances, Spectrum
  • • 태그 기반 비용 추적

🎯 시험 포인트

실시간 vs 배치

Flink = 실시간 집계, Glue = 배치 ETL

IoT 아키텍처

Greengrass(Edge) → IoT Core → Kinesis/S3

시계열 데이터

Timestream = 실시간, S3+Athena = 장기 분석

데이터 메시

Lake Formation + RAM = Cross-account 공유

AWS Data Engineer 시험 준비 완료!

10개 세션을 통해 AWS 데이터 플랫폼의 핵심 개념과 서비스를 학습했습니다.

시험 영역
  • • 데이터 수집 (22%)
  • • 데이터 변환 (30%)
  • • 데이터 저장 (22%)
  • • 데이터 분석 및 시각화 (14%)
  • • 데이터 보안 및 거버넌스 (12%)
핵심 서비스
  • • Kinesis, MSK, DMS, AppFlow
  • • Glue, EMR, Step Functions
  • • S3, Redshift, DynamoDB
  • • Athena, QuickSight, OpenSearch
  • • Lake Formation, Macie, KMS
세션 요약

1-2

수집

3

저장

4-5

처리

6-7

분석

8-10

거버넌스/운영

아키텍처 선택 가이드

요구사항권장 아키텍처핵심 서비스
실시간 대시보드스트리밍 분석Kinesis + Flink + OpenSearch
IoT 센서 데이터IoT 데이터 레이크IoT Core + Timestream + S3
대규모 배치 분석데이터 레이크S3 + Glue + Athena
BI/리포팅데이터 웨어하우스Redshift + QuickSight
멀티 도메인 공유데이터 메시Lake Formation + DataZone
ML 파이프라인MLOpsSageMaker Pipelines + Feature Store

7. 산업별 아키텍처 패턴

각 산업별로 데이터 플랫폼의 요구사항과 최적의 아키텍처 패턴이 다릅니다. 주요 산업별 특성과 권장 아키텍처를 살펴봅니다.

이커머스 / 리테일
┌─────────────────────────────────────────────────────────────────────────────┐
│                    E-Commerce Data Platform                                  │
│                                                                              │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │   Website   │    │  Mobile App │    │    POS     │    │  Inventory  │  │
│  │  Clickstream│    │   Events    │    │   System   │    │   System    │  │
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘    └──────┬──────┘  │
│         │                  │                  │                  │          │
│         └──────────────────┼──────────────────┼──────────────────┘          │
│                            ▼                  ▼                              │
│                    ┌───────────────┐  ┌───────────────┐                     │
│                    │    Kinesis    │  │   DMS/CDC     │                     │
│                    │  Data Streams │  │               │                     │
│                    └───────┬───────┘  └───────┬───────┘                     │
│                            │                  │                              │
│         ┌──────────────────┼──────────────────┼──────────────────┐          │
│         ▼                  ▼                  ▼                  ▼          │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │  Real-time  │    │   S3 Data   │    │  Redshift   │    │ Personalize │  │
│  │  Dashboard  │    │    Lake     │    │    DWH      │    │   (추천)    │  │
│  └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘  │
│                                                                              │
│  Use Cases:                                                                  │
│  • 실시간 재고 추적 및 자동 발주                                            │
│  • 개인화 상품 추천 (Amazon Personalize)                                    │
│  • 고객 세그먼테이션 및 타겟 마케팅                                         │
│  • 가격 최적화 및 프로모션 효과 분석                                        │
│  • 장바구니 이탈 분석 및 리타겟팅                                           │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

핵심 요구사항

  • • 실시간 재고 동기화
  • • 밀리초 단위 추천 응답
  • • 피크 시즌 확장성
  • • 옴니채널 데이터 통합

권장 서비스

  • • Kinesis + Lambda (실시간)
  • • Personalize (추천)
  • • ElastiCache (세션/캐시)
  • • Redshift (분석)
금융 서비스
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Financial Services Data Platform                          │
│                                                                              │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │  Core       │    │   Trading   │    │   Market    │    │  Customer   │  │
│  │  Banking    │    │   System    │    │   Data      │    │   Data      │  │
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘    └──────┬──────┘  │
│         │                  │                  │                  │          │
│         ▼                  ▼                  ▼                  ▼          │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │                    AWS PrivateLink / VPC                            │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│         │                  │                  │                  │          │
│         ▼                  ▼                  ▼                  ▼          │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │   S3 with   │    │   Kinesis   │    │  Lake       │    │   Macie     │  │
│  │  SSE-KMS    │    │  Encrypted  │    │ Formation   │    │   (PII)     │  │
│  └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘  │
│                                                                              │
│  Compliance Requirements:                                                    │
│  • PCI-DSS: 카드 데이터 암호화, 접근 로깅                                   │
│  • SOX: 감사 추적, 데이터 무결성                                            │
│  • GDPR: 개인정보 보호, 삭제권                                              │
│  • Basel III: 리스크 데이터 집계                                            │
│                                                                              │
│  Use Cases:                                                                  │
│  • 실시간 사기 탐지 (Fraud Detection)                                       │
│  • 신용 리스크 모델링                                                       │
│  • 규제 보고서 자동화                                                       │
│  • AML (자금세탁방지) 모니터링                                              │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

보안 요구사항

  • • 전송/저장 시 암호화 필수
  • • 세분화된 접근 제어
  • • 완전한 감사 추적
  • • 데이터 마스킹/토큰화

권장 서비스

  • • KMS (암호화 키 관리)
  • • Macie (PII 탐지)
  • • CloudTrail (감사)
  • • Lake Formation (접근 제어)
헬스케어 / 생명과학
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Healthcare Data Platform                                  │
│                                                                              │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │    EHR      │    │   Medical   │    │  Genomics   │    │   IoMT      │  │
│  │   System    │    │   Imaging   │    │    Data     │    │  Devices    │  │
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘    └──────┬──────┘  │
│         │                  │                  │                  │          │
│         ▼                  ▼                  ▼                  ▼          │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │              AWS HealthLake (FHIR 표준)                             │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│         │                  │                  │                  │          │
│         ▼                  ▼                  ▼                  ▼          │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │ Comprehend  │    │  SageMaker  │    │   Athena    │    │  QuickSight │  │
│  │   Medical   │    │  (ML 모델)  │    │   (분석)    │    │  (시각화)   │  │
│  └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘  │
│                                                                              │
│  Compliance: HIPAA, HITECH, FDA 21 CFR Part 11                              │
│                                                                              │
│  Use Cases:                                                                  │
│  • 환자 360도 뷰 (통합 의료 기록)                                           │
│  • 의료 영상 AI 분석                                                        │
│  • 임상 시험 데이터 관리                                                    │
│  • 약물 상호작용 예측                                                       │
│  • 인구 건강 분석                                                           │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

HealthLake

  • • FHIR R4 표준
  • • HIPAA 적격
  • • 자동 NLP 추출

Comprehend Medical

  • • 의료 엔티티 추출
  • • ICD-10 코드 매핑
  • • PHI 탐지

Omics

  • • 유전체 데이터 저장
  • • 워크플로우 실행
  • • 변이 분석

산업별 아키텍처 비교

산업핵심 요구사항주요 서비스규제
이커머스실시간, 확장성Kinesis, PersonalizePCI-DSS
금융보안, 감사KMS, Macie, Lake FormationPCI-DSS, SOX, GDPR
헬스케어상호운용성, 프라이버시HealthLake, Comprehend MedicalHIPAA, HITECH
제조IoT, 예측 정비IoT Analytics, TimestreamISO 27001
미디어대용량, 스트리밍MediaConvert, ElementalCOPPA

8. 종합 핵심 요약 및 시험 대비

아키텍처 케이스 스터디 종합

데이터 레이크 아키텍처

  • • S3 = 중앙 저장소 (Raw → Processed → Curated)
  • • Glue = ETL + Data Catalog
  • • Lake Formation = 중앙 집중식 권한 관리
  • • Athena = 서버리스 쿼리

실시간 처리

  • • Kinesis Data Streams: 실시간 수집 (샤드 기반)
  • • Kinesis Data Firehose: 자동 배치 + 변환 + 전달
  • • MSK: Kafka 호환, 대용량 처리
  • • Lambda: 이벤트 기반 처리

비용 최적화

  • • S3 Lifecycle: Standard → IA → Glacier
  • • Athena: 파티셔닝 + 컬럼나 포맷 (Parquet)
  • • Redshift: RA3 + Reserved Instances
  • • Glue: Auto Scaling + DPU 최적화

산업별 특화

  • • 이커머스: Personalize (추천), 실시간 재고
  • • 금융: KMS + Macie + 감사 로깅
  • • 헬스케어: HealthLake (FHIR), HIPAA 준수
시험 핵심 포인트

데이터 레이크 계층

Raw → Processed → Curated (Bronze/Silver/Gold)

Kinesis vs MSK

Kinesis = AWS 네이티브, MSK = Kafka 호환 필요 시

Firehose 특징

자동 배치, Lambda 변환, 직접 S3/Redshift 전달

Lake Formation

컬럼/행 수준 보안, 태그 기반 접근 제어

Athena 최적화

파티셔닝 + Parquet + 압축 = 비용 90% 절감

Redshift RA3

컴퓨팅/스토리지 분리, Managed Storage

HIPAA 서비스

HealthLake, Comprehend Medical, S3 암호화

PII 탐지

Macie = S3 스캔, Comprehend = 텍스트 분석

시나리오별 서비스 선택 가이드

Q: 실시간 클릭스트림 분석이 필요합니다

A: Kinesis Data Streams → Kinesis Data Analytics (SQL/Flink) → OpenSearch/QuickSight

Q: 기존 Kafka 워크로드를 AWS로 마이그레이션

A: Amazon MSK (Managed Kafka) - 기존 코드 변경 최소화

Q: 로그 데이터를 S3에 자동으로 저장

A: Kinesis Data Firehose - 자동 배치, 압축, 포맷 변환

Q: 데이터 레이크에서 세분화된 접근 제어

A: Lake Formation - 컬럼/행 수준 보안, 태그 기반 접근 제어

Q: S3 데이터에서 PII 자동 탐지

A: Amazon Macie - ML 기반 민감 데이터 자동 탐지

Q: 의료 데이터 FHIR 표준 저장

A: AWS HealthLake - FHIR R4 네이티브, HIPAA 적격

전체 과정 핵심 체크리스트

수집 & 저장
  • ☐ Kinesis (실시간) vs Firehose (배치)
  • ☐ S3 스토리지 클래스 선택
  • ☐ Glue Data Catalog 활용
  • ☐ 파티셔닝 전략
처리 & 변환
  • ☐ Glue ETL (Spark 기반)
  • ☐ EMR (대규모 처리)
  • ☐ Lambda (이벤트 기반)
  • ☐ Step Functions (오케스트레이션)
분석 & 시각화
  • ☐ Athena (서버리스 쿼리)
  • ☐ Redshift (DWH)
  • ☐ OpenSearch (검색/로그)
  • ☐ QuickSight (BI)
거버넌스 & 보안
  • ☐ Lake Formation (접근 제어)
  • ☐ Macie (PII 탐지)
  • ☐ KMS (암호화)
  • ☐ CloudTrail (감사)

🎓 AWS Data Analytics Specialty 시험 팁

  • • 각 서비스의 핵심 사용 사례와 제한 사항을 명확히 이해
  • • 비용 최적화 시나리오 문제 빈출 (파티셔닝, 압축, 스토리지 클래스)
  • • 보안/규정 준수 관련 서비스 조합 숙지
  • • 실시간 vs 배치 처리 선택 기준 명확히
  • • 서비스 간 통합 패턴 (Kinesis → S3 → Athena 등)

9. 마이그레이션 전략 심화

온프레미스 데이터 플랫폼을 AWS로 마이그레이션하는 전략과 도구를 상세히 살펴봅니다.

데이터 웨어하우스 마이그레이션
┌─────────────────────────────────────────────────────────────────────────────┐
│                    DWH Migration to Redshift                                 │
│                                                                              │
│  Phase 1: Assessment                                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │  • Schema Conversion Tool (SCT) 분석                                │   │
│  │  • 워크로드 복잡도 평가                                              │   │
│  │  • 데이터 볼륨 및 증가율 분석                                        │   │
│  │  • 의존성 매핑 (ETL, BI 도구)                                       │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│                                    │                                         │
│                                    ▼                                         │
│  Phase 2: Schema Conversion                                                  │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │  • AWS SCT로 DDL 변환                                               │   │
│  │  • 데이터 타입 매핑                                                  │   │
│  │  • 저장 프로시저/함수 변환                                           │   │
│  │  • DISTKEY/SORTKEY 설계                                             │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│                                    │                                         │
│                                    ▼                                         │
│  Phase 3: Data Migration                                                     │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │  • AWS DMS로 초기 로드                                              │   │
│  │  • CDC로 변경 데이터 동기화                                          │   │
│  │  • S3 → Redshift COPY 명령                                          │   │
│  │  • 데이터 검증                                                       │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│                                    │                                         │
│                                    ▼                                         │
│  Phase 4: Cutover                                                            │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │  • 병렬 실행 및 결과 비교                                            │   │
│  │  • 성능 튜닝                                                         │   │
│  │  • 애플리케이션 전환                                                 │   │
│  │  • 롤백 계획                                                         │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

// DMS 태스크 설정 (Terraform)

# DMS 복제 인스턴스
resource "aws_dms_replication_instance" "main" {
  replication_instance_id     = "dms-replication"
  replication_instance_class  = "dms.r5.xlarge"
  allocated_storage           = 100
  
  vpc_security_group_ids = [aws_security_group.dms.id]
  replication_subnet_group_id = aws_dms_replication_subnet_group.main.id
  
  multi_az               = true
  publicly_accessible    = false
  
  tags = {
    Name = "DWH Migration"
  }
}

# 소스 엔드포인트 (Oracle)
resource "aws_dms_endpoint" "source" {
  endpoint_id   = "oracle-source"
  endpoint_type = "source"
  engine_name   = "oracle"
  
  server_name   = var.oracle_host
  port          = 1521
  database_name = var.oracle_db
  username      = var.oracle_user
  password      = var.oracle_password
  
  extra_connection_attributes = "useLogMinerReader=N;useBfile=Y"
}

# 타겟 엔드포인트 (Redshift)
resource "aws_dms_endpoint" "target" {
  endpoint_id   = "redshift-target"
  endpoint_type = "target"
  engine_name   = "redshift"
  
  server_name   = aws_redshift_cluster.main.endpoint
  port          = 5439
  database_name = "analytics"
  username      = var.redshift_user
  password      = var.redshift_password
  
  redshift_settings {
    bucket_name             = aws_s3_bucket.dms_staging.id
    service_access_role_arn = aws_iam_role.dms_redshift.arn
  }
}

# 복제 태스크
resource "aws_dms_replication_task" "full_load_cdc" {
  replication_task_id      = "oracle-to-redshift"
  migration_type           = "full-load-and-cdc"
  replication_instance_arn = aws_dms_replication_instance.main.replication_instance_arn
  source_endpoint_arn      = aws_dms_endpoint.source.endpoint_arn
  target_endpoint_arn      = aws_dms_endpoint.target.endpoint_arn
  
  table_mappings = jsonencode({
    rules = [
      {
        rule-type = "selection"
        rule-id   = "1"
        rule-name = "include-all-tables"
        object-locator = {
          schema-name = "SALES"
          table-name  = "%"
        }
        rule-action = "include"
      }
    ]
  })
  
  replication_task_settings = jsonencode({
    TargetMetadata = {
      BatchApplyEnabled = true
    }
    FullLoadSettings = {
      TargetTablePrepMode = "DROP_AND_CREATE"
    }
    Logging = {
      EnableLogging = true
    }
  })
}

9.1 Hadoop/Spark 마이그레이션

EMR/Glue로 전환
┌─────────────────────────────────────────────────────────────────────────────┐
│                    Hadoop to AWS Migration Options                           │
│                                                                              │
│  On-Premises Hadoop                    AWS Options                           │
│  ┌─────────────────┐                                                        │
│  │                 │                                                        │
│  │  HDFS           │ ───────────▶  S3 (Data Lake)                          │
│  │                 │                                                        │
│  │  MapReduce      │ ───────────▶  EMR / Glue ETL                          │
│  │                 │                                                        │
│  │  Hive           │ ───────────▶  Athena / EMR Hive / Redshift Spectrum   │
│  │                 │                                                        │
│  │  Spark          │ ───────────▶  EMR Spark / Glue Spark                  │
│  │                 │                                                        │
│  │  HBase          │ ───────────▶  DynamoDB / EMR HBase                    │
│  │                 │                                                        │
│  │  Kafka          │ ───────────▶  MSK / Kinesis                           │
│  │                 │                                                        │
│  │  Oozie          │ ───────────▶  Step Functions / MWAA                   │
│  │                 │                                                        │
│  └─────────────────┘                                                        │
│                                                                              │
│  Migration Strategy:                                                         │
│  1. Lift & Shift: EMR로 기존 워크로드 이전 (최소 변경)                      │
│  2. Re-platform: Glue/Athena로 서버리스 전환                                │
│  3. Re-architect: 클라우드 네이티브 재설계                                  │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

// HDFS to S3 마이그레이션 스크립트

#!/bin/bash
# HDFS to S3 Migration using DistCp

# 1. S3 버킷 생성 및 정책 설정
aws s3 mb s3://my-data-lake-bucket --region ap-northeast-2

# 2. DistCp를 사용한 데이터 복사 (EMR에서 실행)
hadoop distcp \
  -Dfs.s3a.access.key=${AWS_ACCESS_KEY} \
  -Dfs.s3a.secret.key=${AWS_SECRET_KEY} \
  -Dfs.s3a.endpoint=s3.ap-northeast-2.amazonaws.com \
  -update \
  -delete \
  -p \
  -m 100 \
  hdfs:///data/warehouse/ \
  s3a://my-data-lake-bucket/warehouse/

# 3. 데이터 검증
aws s3 ls s3://my-data-lake-bucket/warehouse/ --recursive --summarize

# 4. Hive 메타스토어 마이그레이션
# Glue Data Catalog로 테이블 정의 이전
python migrate_hive_to_glue.py \
  --hive-metastore jdbc:mysql://hive-metastore:3306/hive \
  --glue-database my_database \
  --s3-location s3://my-data-lake-bucket/warehouse/

9.2 마이그레이션 체크리스트

단계별 체크리스트

사전 준비

  • ☐ 현재 아키텍처 문서화
  • ☐ 데이터 인벤토리 작성
  • ☐ 의존성 매핑
  • ☐ 성능 베이스라인 측정
  • ☐ 비용 분석

설계

  • ☐ 타겟 아키텍처 설계
  • ☐ 서비스 선택
  • ☐ 네트워크 설계
  • ☐ 보안 설계
  • ☐ 마이그레이션 순서 결정

실행

  • ☐ 파일럿 마이그레이션
  • ☐ 데이터 전송
  • ☐ 스키마 변환
  • ☐ ETL 코드 변환
  • ☐ 테스트

전환

  • ☐ 병렬 실행
  • ☐ 데이터 검증
  • ☐ 성능 검증
  • ☐ 컷오버
  • ☐ 롤백 계획
마이그레이션 도구용도특징
AWS DMS데이터베이스 마이그레이션CDC 지원, 최소 다운타임
AWS SCT스키마 변환DDL/DML 자동 변환
DataSync파일 전송NFS/SMB → S3
Transfer FamilySFTP/FTPS기존 프로토콜 유지
Snowball대용량 오프라인페타바이트 규모

10. 시험 대비 최종 정리

자주 출제되는 시나리오

Q: 실시간 클릭스트림을 수집하여 S3에 저장하고 분석하려면?

A: Kinesis Data Firehose → S3 (Parquet 변환) → Athena 쿼리

Q: 기존 Kafka 클러스터를 AWS로 마이그레이션하면서 코드 변경을 최소화하려면?

A: Amazon MSK (Managed Kafka) - Kafka API 호환

Q: S3 데이터 레이크에서 컬럼 수준 접근 제어가 필요하면?

A: Lake Formation - 컬럼/행 수준 보안, 태그 기반 접근 제어

Q: Athena 쿼리 비용을 줄이려면?

A: 파티셔닝 + Parquet/ORC 포맷 + 압축 + 필요한 컬럼만 SELECT

Q: Redshift에서 컴퓨팅과 스토리지를 독립적으로 확장하려면?

A: RA3 노드 타입 - Managed Storage 사용

Q: S3에서 민감한 개인정보(PII)를 자동으로 탐지하려면?

A: Amazon Macie - ML 기반 민감 데이터 자동 탐지

Q: 의료 데이터를 FHIR 표준으로 저장하고 분석하려면?

A: AWS HealthLake - FHIR R4 네이티브, HIPAA 적격

Q: Glue ETL 작업의 비용을 최적화하려면?

A: Auto Scaling 활성화 + 적절한 DPU 수 설정 + Job Bookmarks

서비스별 핵심 키워드

Kinesis Data Streams

샤드, 실시간, 24시간~365일 보존

Kinesis Data Firehose

자동 배치, 변환, Near-realtime

Glue

ETL, Data Catalog, Crawler, DPU

Athena

서버리스, Presto, 스캔 기반 과금

Redshift

MPP, DISTKEY, SORTKEY, RA3

Lake Formation

중앙 권한, 컬럼/행 보안, 태그

QuickSight

SPICE, ML Insights, 임베디드

OpenSearch

검색, 로그, UltraWarm, ISM

🎓 시험 당일 체크리스트

  • ☐ 각 서비스의 핵심 사용 사례 복습
  • ☐ 비용 최적화 패턴 (파티셔닝, 압축, 스토리지 클래스)
  • ☐ 보안 서비스 조합 (KMS, Macie, Lake Formation)
  • ☐ 실시간 vs 배치 선택 기준
  • ☐ 서비스 간 통합 패턴
  • ☐ 마이그레이션 도구 (DMS, SCT, DataSync)