김신건의 로그 - 위키 / cloud

[AWS] API Gateway: REST/HTTP API 관리

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

AWS API Gateway 는 REST/HTTP/WebSocket API 를 관리하는 완전관리형 서비스. 백엔드 통합, 인증, 스로틀링, 캐싱, 로깅 제공.

두 종류

REST API

초기 버전 (2015~)
풍부한 기능: usage plan, API key, request validator, WAF 통합
비용 높음 ($3.50 per million calls)
레거시 옵션, 신규는 HTTP API 권장

HTTP API

2019~
비용 70% 저렴 ($1.00 per million)
지연시간 낮음
JWT authorizer 내장 (Cognito, Auth0)
CORS 자동
WebSocket 지원

통합 타입

[[aws-lambda|Lambda]] proxy: 요청 그대로 Lambda 로
HTTP proxy: 다른 URL 로 프록시
AWS 서비스: DynamoDB, SQS 등 직접 통합
VPC Link: 프라이빗 [[aws-alb-nlb|ALB/NLB]] 연결

인증

IAM: SigV4 서명
Cognito User Pool
JWT Authorizer (HTTP API 만)
Lambda Authorizer (커스텀)
API Key + Usage Plan

스로틀링

계정 레벨: 10,000 rps (soft limit)
API 레벨, 스테이지 레벨, 리소스 레벨
Usage Plan 으로 API Key 별 quota

캐싱 (REST API)

TTL 기반 응답 캐싱. 백엔드 부하 감소, 응답 속도 향상.

함정

VPC 접근: 사설 API 는 VPC Endpoint 로. HTTP API 는 VPC Link.
payload 크기: 10 MB 제한, WebSocket 128 KB
cold start: HTTP API 자체는 없음, Lambda 통합 시 Lambda 콜드 스타트

참고

[[aws-lambda|Lambda]]
[[aws-alb-nlb|ALB / NLB]]
[[aws-lambda-cold-start|Lambda Cold Start]]

[AWS] ALB vs NLB: L7 vs L4 로드 밸런서

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

	ALB	NLB	(Classic ELB)
Layer	L7 (HTTP)	L4 (TCP/UDP)	L4 + L7 (legacy)
라우팅	path / host / header	port	단순
TLS termination	O	O (TLS listener)	O
WebSocket	O	O	부분
gRPC	O	O	X
처리량	큼	매우 큼	보통
Static IP	NO	예 (EIP)	NO
Latency	중간 (ms)	극저지연 (µs)	중간
가격	LCU (요청 + 데이터)	LCU	시간 + GB

{}

ALB (Application Load Balancer)

flowchart LR
    Client -->|HTTP| ALB
    ALB -->|/api/* | Tg1["Target Group 1<br/>(api pods)"]
    ALB -->|/web/*| Tg2["Target Group 2<br/>(web pods)"]
    ALB -->|host: admin.x.com| Tg3["Target Group 3<br/>(admin)"]

기능:

Path-based / Host-based / Header / Query routing
WebSocket / HTTP/2 (gRPC)
WAF 통합
Cognito / OIDC 인증 (앞단)
Lambda 직접 target
IP 또는 instance target

NLB (Network Load Balancer)

flowchart LR
    Client -->|TCP/UDP| NLB["NLB<br/>(static IP, AZ 별)"]
    NLB --> Tg[Target Group]
    Tg --> EC2[(EC2 / IP)]

기능:

극저지연: 마이크로초.
static IP: AZ 별 EIP 고정 (방화벽 허용 친화).
millions of conn.
TLS termination 옵션.
TCP / UDP / TLS listener.

[!IMPORTANT] gRPC, WebSocket idle 대응 은 NLB 가 ALB 보다 안정. 정 idle timeout 길게.

선택 트리

flowchart TD
    Q1{프로토콜}
    Q1 -->|HTTP / HTTPS / gRPC| Q2{L7 라우팅 필요?}
    Q1 -->|TCP / UDP| NLB[NLB]
    Q2 -->|예| ALB[ALB]
    Q2 -->|아니오 + 극저지연| NLB
    Q2 -->|아니오 + 일반| ALB

Target Group

TargetType: instance | ip | lambda
HealthCheck:
  Protocol: HTTP
  Path: /health
  Interval: 30s
  HealthyThreshold: 2
  UnhealthyThreshold: 3

Sticky Session

Stickiness:
  Type: lb_cookie     # ALB 가 쿠키 박음
  Duration: 1d

또는 application-controlled (app 이 cookie 박음).

WAF 통합 (ALB 만)

flowchart LR
    Client --> WAF[AWS WAF]
    WAF --> ALB
    ALB --> Target
    Note[ALB 앞단 WAF: SQLi, XSS, rate limit, bot]

ALB → Lambda

TargetType: lambda
Targets:
  - { Id: arn:aws:lambda:us-east-1:123:function:myFunc }

API Gateway 대신 ALB + Lambda 도 가능. 더 cheap, REST API 만.

흔한 함정

[!WARNING]

ALB Idle Timeout 60s = WebSocket / SSE 가 silent close. ping/pong 또는 timeout 늘림.

NLB + auto-scaling = NLB 의 target deregistration delay. 트래픽 차단 후 수십 초 까지 일부 요청.

HTTP/2 → 백엔드는 HTTP/1.1 = ALB 가 down-grade. gRPC backend 는 NLB 또는 HTTP/2 enable.

NLB cross-zone disabled = AZ 간 불균등 분포. enable 권장 (가격 약간 더).

[AWS] Auto Scaling: EC2 ASG, target tracking, predictive

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Auto Scaling Group (ASG) = EC2 instance 자동 증감. desired / min / max + scaling policy.

구조

flowchart TB
    ASG[Auto Scaling Group<br/>min=2, max=20, desired=5]
    ASG --> LT["Launch Template<br/>(instance type, AMI, SG, ...)"]
    ASG --> Tg["Target Group<br/>(ALB/NLB)"]
    ASG --> Az[Multi-AZ<br/>az-a, az-b, az-c]
    ASG --> Policy[Scaling Policy]
    Policy --> TT[Target Tracking]
    Policy --> Step[Step]
    Policy --> Sched[Scheduled]
    Policy --> Pred[Predictive]

Scaling Policy 4종

1. Target Tracking (권장)

TargetTrackingConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: ASGAverageCPUUtilization
  TargetValue: 50.0

“CPU 평균 50% 유지하도록 알아서 증감”.

2. Step Scaling

CPU 70-80% → +1
CPU 80-90% → +2
CPU 90%+   → +5

세밀 제어. 복잡.

3. Scheduled

# 매일 오전 9시에 desired=10
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web \
  --schedule "cron(0 9 * * ? *)" \
  --desired-capacity 10

예측 가능한 트래픽 (예: 직장인 사용 패턴, 새벽 light).

4. Predictive Scaling

머신러닝으로 과거 패턴 예측 → 미리 증가. AWS managed.

Lifecycle

sequenceDiagram
    ASG->>EC2: Launch
    EC2->>EC2: bootstrap (UserData)
    EC2->>ALB: 등록
    Note over ALB,EC2: ALB health check
    ALB-->>ASG: in service
    Note over ASG: 정상 동작
    ASG->>EC2: Terminate (scale-in)
    EC2->>ALB: deregister
    Note over EC2: graceful shutdown<br/>(connection draining)
    EC2->>EC2: stop

Lifecycle Hooks

LifecycleHook:
  LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
  HeartbeatTimeout: 300
  NotificationTargetARN: arn:aws:sns:...

Launching: instance 시작 직후, 트래픽 받기 전. 데이터 워밍업, init.
Terminating: terminate 직전. log flush, draining.

Cooldown vs Warmup

	Cooldown	Warmup
의미	다음 scaling 까지 대기	instance 가 준비되기 까지
기본	300s	0 (Target Tracking 자동)

ASG + Spot

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 2          # 최소 on-demand
    OnDemandPercentageAboveBaseCapacity: 25
    SpotAllocationStrategy: capacity-optimized-prioritized
  LaunchTemplate:
    Overrides:
      - InstanceType: m6i.large
      - InstanceType: m6a.large
      - InstanceType: m6g.large

2 on-demand 보장 + 나머지 70% spot 비용 절감.

EC2 Auto Scaling vs Application Auto Scaling

	EC2 ASG	App Auto Scaling
대상	EC2	ECS, DynamoDB, Aurora, …
정책	동일	동일
단위	instance	task / capacity unit

흔한 함정

[!WARNING]

Health check 정의 잘못 = 정상 instance 도 unhealthy 판정 → 무한 replace.

Cooldown 너무 짧음 = scaling oscillation.

Spot 100% = capacity 부족 시 instance launch 실패. 최소 on-demand 안전망.

ALB connection draining 부재 = scale-in 시 진행 중 요청 끊김.

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

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

CloudFront = AWS 의 글로벌 CDN. 전세계 엣지 (~600 PoP) 에서 사용자에게 가까이.

동작

sequenceDiagram
    participant Client
    participant Edge as CloudFront Edge (가장 가까운 PoP)
    participant Regional as Regional Edge Cache
    participant Origin as Origin (S3, ALB, custom)

    Client->>Edge: request
    alt cache HIT
        Edge-->>Client: 즉시 응답
    else cache MISS
        Edge->>Regional: forward
        alt regional HIT
            Regional-->>Edge: 응답
            Edge-->>Client: 응답
        else regional MISS
            Regional->>Origin: forward
            Origin-->>Regional: 응답
            Regional-->>Edge: cache
            Edge-->>Client: 응답
        end
    end

Origin 종류

Origin	사용
S3	정적 파일
ALB / NLB	동적
Custom (anywhere)	외부 (자체 호스팅)
Lambda Function URL	서버리스
MediaPackage	비디오

Cache Behavior

flowchart LR
    Behavior[Cache Behavior<br/>Path pattern 기준]
    Behavior --> Static["/static/* → S3 origin, cache 1d"]
    Behavior --> API["/api/* → ALB origin, no-cache"]
    Behavior --> Default["* → S3 origin, cache 1h"]

Cache Key

CachePolicy:
  Headers: [Accept-Language, Authorization]
  Cookies: [session]
  QueryStrings: [version]

너무 많은 key = cache hit rate 떨어짐. 최소.

aws cloudfront sign --url https://d111.cloudfront.net/private/video.mp4 \
  --key-pair-id K123 \
  --private-key file://private_key.pem \
  --date-less-than 2026-06-26

사용자별 임시 URL.
동영상 / 다운로드 / 보호된 콘텐츠.

OAC (Origin Access Control)

S3 origin 의 공개 차단 + CloudFront 만 접근:

S3 Bucket policy:
  - Principal: cloudfront.amazonaws.com
    Condition:
      AWS:SourceArn: arn:aws:cloudfront:::distribution/EXX

옛 OAI (Origin Access Identity) 의 후계. S3 의 모든 PUT/GET 권한 분리.

Edge Compute

	CloudFront Functions	Lambda@Edge
Runtime	JavaScript only	Node, Python
실행 위치	edge (가장 빠름)	regional edge
Cold start	0	가능
시간 한도	< 1ms	5s (viewer) / 30s (origin)
메모리	2MB	128MB-10GB
가격	매우 저렴	Lambda 가격
사용	header rewrite, redirect, A/B	복잡 처리 (auth, transform)

TLS / SNI

AWS Certificate Manager (ACM) 무료 인증서.
반드시 us-east-1 (Northern Virginia) 에서 발급 (CloudFront 글로벌).
SNI 기본 활성 (옛 dedicated IP 옵션 비싸다).

흔한 함정

[!WARNING]

Origin 의 cache header 무시 = CloudFront 가 cache 안 함. Cache-Control: max-age=... 명시.

S3 origin 공개 = CloudFront 우회 가능. OAC 필수.

invalidation 비용 = 1000 path 까지 무료, 이후 $0.005/path. wildcards (/*) 가 효율적.

TLS cert 가 wrong region = us-east-1 에서만 발급. 다른 region 의 cert 는 사용 불가.

[AWS] CloudWatch: 메트릭, 로그, 알람

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

CloudWatch = AWS 의 모니터링 + 로그 + 알람 통합 서비스.

4가지 구성

flowchart LR
    CW[CloudWatch]
    CW --> M[Metrics]
    CW --> L[Logs]
    CW --> A[Alarms]
    CW --> D[Dashboards]
    CW --> SY["Synthetics<br/>(canaries)"]
    CW --> RUM["RUM (Real User Monitoring)"]

Metrics

종류	의미
Standard resolution	1분 단위
High resolution	1초 단위 (별도 비용)
Built-in	AWS service 자동
Custom	`PutMetricData` API

cw.put_metric_data(
    Namespace='MyApp',
    MetricData=[{
        'MetricName': 'OrdersPlaced',
        'Value': 1,
        'Unit': 'Count',
        'Dimensions': [
            { 'Name': 'Region', 'Value': 'us-east-1' },
            { 'Name': 'Service', 'Value': 'order-api' }
        ]
    }]
)

Embedded Metric Format (EMF)

{
  "_aws": {
    "Timestamp": 1719318060000,
    "CloudWatchMetrics": [{
      "Namespace": "MyApp",
      "Dimensions": [["Service"]],
      "Metrics": [
        { "Name": "Latency", "Unit": "Milliseconds" }
      ]
    }]
  },
  "Service": "api",
  "Latency": 125,
  "user_id": "u_42"
}

로그로 출력하면 CloudWatch 가 자동으로 메트릭 추출. PutMetricData API 호출 없음. 대량 메트릭의 비용 절감.

Logs

flowchart LR
    App[App] -->|stdout| Container
    Container -->|awslogs driver| LG[Log Group]
    LG --> LS[Log Stream]
    LG --> Insights[Logs Insights]
    LG --> Sub[Subscription Filter]
    Sub --> Lambda[Lambda]
    Sub --> Kinesis[Kinesis]

Logs Insights (쿼리)

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)
| sort @timestamp desc
| limit 50

Subscription Filter

로그 → Lambda / Kinesis 실시간 stream. 외부 시스템 (Datadog, ELK) 으로 export.

Alarms

Alarm:
  MetricName: CPUUtilization
  Namespace: AWS/EC2
  Statistic: Average
  Period: 60
  EvaluationPeriods: 5
  Threshold: 80
  ComparisonOperator: GreaterThanThreshold
  AlarmActions: [arn:aws:sns:...]

5번 연속 1분 평균 CPU > 80% → SNS 알림.

Composite Alarm

AlarmRule: |
  ALARM("HighCPU") AND
  ALARM("HighLatency") AND
  NOT ALARM("Maintenance")

복수 alarm 결합. 유의미한 사고 만 알림 (false positive 감소).

Anomaly Detection

Metrics:
  - Id: m1
    MetricStat: { ... }
  - Id: ad1
    Expression: ANOMALY_DETECTION_BAND(m1, 2)

머신러닝으로 정상 범위 학습 + 이상치 감지.

CloudWatch vs 3rd-party

	CloudWatch	Datadog / NewRelic
AWS 통합	최고	통합 plugin
UI	기본	우수
가격	metric 수에 비례 (큼)	호스트 기반 (큼)
Distributed tracing	X-Ray 별도	통합
APM	제한	완전

대부분의 큰 회사 = CloudWatch 기본 + Datadog 등 비싼 도구 으로 세분.

흔한 함정

[!WARNING]

메트릭 비용 폭증 = 각 dimension 조합 = 별도 metric. cardinality 관리.

Log retention 기본 영원 = 무한 비용. retention 정책 필수.

PutMetricData API call 비용 = EMF 로 log 로 메트릭.

Alarm 의 INSUFFICIENT_DATA = 데이터 부족으로 alarm 못 보내. TreatMissingData 명시.

[AWS] EBS vs Instance Store: 영속 vs 임시 스토리지

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

	EBS	Instance Store
영속성	영속	임시 (instance 종료 시 손실)
위치	네트워크 attached	노드 직결 NVMe
분리	다른 instance 에 attach 가능	불가
Snapshot	가능	불가
가격	매월	EC2 가격에 포함
Latency	네트워크 hop	매우 낮음
처리량	옵션	매우 높음

EBS Volume 종류

종류	용도	IOPS 한도	처리량
gp3 (기본)	일반	16,000 (별도 구매로 80k)	1,000 MB/s
gp2	옛 일반 (gp3 권장)	16,000	250 MB/s
io2	고성능	256,000	4,000 MB/s
io2 Block Express	극고성능	256k+	4 GB/s
st1	throughput HDD (DW)	low	500 MB/s
sc1	cold HDD	low	250 MB/s

[!TIP] 2026 시점 gp3 가 기본. gp2 보다 저렴 + 더 유연. 새 volume 은 gp3 로.

gp3 의 분리 가격

기본: 3,000 IOPS + 125 MB/s 무료
추가: IOPS $0.005/PIOPS-월, 처리량 $0.04/MBps-월

gp2 는 size 비례 IOPS. gp3 는 size 와 IOPS 분리 → 작은 volume + 큰 IOPS 가능.

Snapshot

sequenceDiagram
    User->>EBS: CreateSnapshot
    EBS->>S3: 증분 백업
    Note over EBS,S3: 첫 snapshot 전체, 이후 변경 부분만
    User->>EBS: 복원 from snapshot
    Note over EBS: 점진적 hydration (read 시 download)

S3 저장 (지역 안에 복제).
증분: 같은 volume 의 변경 block 만.
Fast Snapshot Restore (FSR) 옵션: 즉시 full performance.

Instance Store

m6id.large    ← 'd' 가 NVMe 포함
i4i.large     ← 'i' family 가 storage 특화

intanc instance type 별 고정.
수십 GB ~ 수십 TB NVMe.
극저지연 + 극고처리량.

적합

용도	이유
Shuffle 데이터 (Spark)	잠시면 됨
캐시 (Redis L1)	다시 채울 수 있음
임시 build / compile	빠름
데이터베이스의 replica	다시 sync 가능

부적합

용도	이유
Primary DB 데이터	instance 종료 시 손실
사용자 업로드	영속 필요

비교 직관

Multi-Attach (io2 만)

aws ec2 modify-volume --volume-id vol-xxx --multi-attach-enabled

같은 EBS volume → 여러 EC2 동시 attach (최대 16개)
분산 파일시스템 (GFS2, OCFS2) 필요. 단순 ext4 가 동시 mount 면 손상.

흔한 함정

[!WARNING]

gp2 사용 (옛) = gp3 가 저렴. 마이그레이션 (downtime 없음).

Snapshot 지역 간 복제 안 함 = region 장애 시 손실.

Instance Store 를 영속처럼 = stop/start = 데이터 손실 (reboot 은 OK).

IOPS 너무 작음 = 워크로드 IOPS 측정 후 결정.

[AWS] EC2 Instance Types: family, generation, sizing

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

EC2 인스턴스 수백 종. family + generation + modifier + size. 워크로드에 맞춰 right-sizing.

Family

Family	용도	예
t	burstable	t4g.micro
m	general	m7i, m7a, m7g
c	compute	c7i (CPU 강)
r	memory	r7i (RAM 강)
x, u	extreme memory	x2gd (1.5TB+)
i	storage (NVMe)	i4i
d	dense HDD	d3
p, g, inf, trn	GPU/AI	p5 (H100), trn1 (training)
hpc	HPC	hpc7g
mac	macOS	mac2 (Apple Silicon)

세대 + Modifier

m7g.large
│ │ │
│ │ └── size
│ └──── generation 7
└────── family + modifier
        m = general
        i = Intel
        a = AMD
        g = Graviton (ARM)
        n = enhanced network
        d = local NVMe

Modifier	의미
`i`	Intel Xeon
`a`	AMD EPYC
`g`	AWS Graviton (ARM)
`n`	enhanced network
`d`	local NVMe SSD
`z`	high frequency
`e`	extended memory

Size

Size	vCPU (m7i)	RAM
nano	2	0.5GB
micro	2	1GB
small	2	2GB
medium	2	4GB
large	2	8GB
xlarge	4	16GB
2xlarge	8	32GB
4xlarge	16	64GB
8xlarge	32	128GB
…	…	…
48xlarge	192	768GB

Graviton vs Intel vs AMD (비용 비교)

Burstable (t family) 의 CPU Credit

sequenceDiagram
    Idle->>Bank: CPU credit 적립 (baseline 이하)
    Burst->>Bank: credit 소비 (baseline 초과 시)
    Bank-->>Throttle: credit 0 → throttle

타입	Baseline CPU
t4g.nano	5%
t4g.micro	10%
t4g.small	20%
t4g.medium	20% (2 vCPU)

[!CAUTION] 지속적 부하 에 burstable 사용 = credit 소진 → baseline 으로 throttle. unlimited 모드 또는 m family.

Right-sizing

flowchart TD
    Q[현재 사용량 측정]
    Q --> Compute[CPU/Memory 평균 + p99]
    Compute --> Decide{사용률}
    Decide -->|< 30%| Down[size 줄임]
    Decide -->|30-70%| Keep[유지]
    Decide -->|> 70%| Up[size 늘림 또는 family 변경]

도구:

AWS Compute Optimizer (자동 권장)
CloudWatch metric
3rd-party (CloudHealth, Spot.io)

Nitro

AWS 의 경량 하이퍼바이저. 모든 새 generation (>= 2018) 이 Nitro. 거의 bare-metal 성능.

특징:

빠른 시작
Nitro Enclaves (격리 컴퓨팅)
Nitro SSD (NVMe)
네트워크 / 스토리지 전용 카드

흔한 함정

[!WARNING]

새 워크로드를 Intel 만 = Graviton 비용 절감 기회 놓침.

t family 의 지속 부하 = credit 소진 + throttle.

너무 큰 size = 비용 폭증. right-sizing 정기.

잘못된 family = 메모리 워크로드에 c family → swap 폭증.

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

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

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

인스턴스 타입 명명

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.0×	~0.9×	~0.8×
성능 (workload)	기준	비슷	비슷 또는 우수
호환성	모든 OS	모든 OS	ARM 빌드 필요

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

Purchase Options

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

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

Spot Instance

sequenceDiagram
    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 비활성 강력 권장.

흔한 함정

[!WARNING]

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

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

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

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

[AWS] ECS + Fargate: 컨테이너 오케스트레이션

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

ECS (Elastic Container Service) = AWS 의 컨테이너 오케스트레이션. K8s 보다 단순. Fargate = ECS / EKS 의 서버리스 실행 환경 (EC2 관리 없음).

ECS 구조

flowchart TB
    Cluster[Cluster] --> Service1[Service A]
    Cluster --> Service2[Service B]
    Service1 --> Task1["Task<br/>(컨테이너 묶음)"]
    Service1 --> Task2[Task]
    Task1 --> Cont1[Container 1]
    Task1 --> Cont2[Container 2]

객체	의미
Cluster	논리 그룹
Task Definition	YAML 같은 spec (K8s Pod 비슷)
Task	실행된 인스턴스
Service	desired count, LB 통합 (K8s Deployment 비슷)

Task Definition

{
  "family": "web",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "nginx:1.27",
      "portMappings": [{ "containerPort": 80 }],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/web",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Launch Types

	EC2	Fargate
노드 관리	사용자	AWS
가격	EC2 시간	Task 의 CPU/Memory 시간
시작 속도	빠름 (예약 EC2)	약간 느림
GPU	가능	일부
호스트 권한	가능	제한
Spot	가능	Fargate Spot
비용	일반적으로 저렴 (밀도)	운영 비용 0

[!TIP] 작은 팀 / 가변 워크로드 = Fargate. 큰 규모 / 비용 최적화 = EC2.

Service (Deployment 비슷)

service:
  cluster: prod
  taskDefinition: web:42
  desiredCount: 3
  deploymentConfiguration:
    minimumHealthyPercent: 100
    maximumPercent: 200
  loadBalancers:
    - targetGroupArn: arn:aws:elasticloadbalancing:...
      containerName: nginx
      containerPort: 80

ECS vs EKS

항목	ECS	EKS
학습 곡선	낮음	높음
표준	AWS 전용	K8s 표준 (이식성)
운영	단순	복잡
가격	cluster 무료	$0.10/h per cluster
ecosystem	작음	방대
적합	AWS lock-in OK, 빠른 시작	멀티 클라우드 / 큰 규모

ECS Anywhere

자체 데이터센터 / edge 의 외부 머신을 ECS 에서 관리. 온프레미스 + 클라우드 통합.

흔한 함정

[!WARNING]

Fargate Spot 의 중단 = stateless 만. batch 에 권장.

awsvpc network mode 의 ENI 한도 = EC2 instance type 별 최대 ENI 수. 한 노드에 수십 task 가능한지 확인.

CloudWatch Logs 비용 = 모든 컨테이너 로그가 CW Logs 로. fluent-bit + S3 으로 비용 절감.

Service Auto Scaling = target tracking 기본. step / scheduled 도 가능.

[AWS] EKS: managed Kubernetes

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

EKS (Elastic Kubernetes Service) = AWS 의 managed K8s control plane. worker node 는 사용자 (또는 Fargate). AWS IAM / VPC / ALB 등 AWS 통합.

아키텍처

flowchart TB
    User[kubectl] --> CP["EKS Control Plane<br/>(AWS managed)"]
    CP --> NG["Managed Node Group<br/>(EC2)"]
    CP --> SN[Self-managed Nodes]
    CP --> FG["Fargate Profile<br/>(serverless)"]
    NG --> Pods1[Pods]
    SN --> Pods2[Pods]
    FG --> Pods3[Pods]

Worker 3가지

종류	의미
Managed Node Group	EC2, AWS 가 자동 관리 + Auto Scaling
Self-managed Nodes	EC2, 사용자 직접
Fargate	노드 없음, 서버리스

Karpenter 가 managed node group 의 진화. 더 빠른 scaling + spot 자동 활용.

EKS 비용

Control Plane: $0.10/시간 = ~$73/월 (cluster 당)
Worker: EC2 또는 Fargate 비용 별도

VPC CNI

EKS 의 기본 CNI = AWS VPC CNI. Pod 가 VPC IP 직접 (NAT 없음).

장점:

VPC 내 native: SG / NetworkPolicy / VPC flow logs 그대로
AWS Load Balancer 통합

단점:

IP 고갈 (Pod 수 × instance 수)
EC2 instance type 별 ENI / IP 한도

대안: Cilium (eBPF), Calico.

IAM Roles for Service Accounts (IRSA)

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

→ pod 가 IAM role assume → AWS API 호출 권한 자동.

[!IMPORTANT] IRSA 가 2026 표준. 옛 node IAM role 공유 보다 세분화 + 보안.

EKS Pod Identity (2023+)

IRSA 의 간소화 버전. OIDC provider 없이도 동작:

aws eks create-pod-identity-association \
  --cluster-name prod \
  --namespace default \
  --service-account s3-uploader \
  --role-arn arn:aws:iam::123:role/s3-uploader

EKS Add-ons

AWS 가 관리하는 권장 add-on:

VPC CNI
CoreDNS
kube-proxy
EBS CSI driver
AWS Load Balancer Controller
ADOT (AWS OpenTelemetry)
GuardDuty Agent

EKS vs ECS

자세한 건 [[aws-ecs-fargate]]. 요약:

flowchart TD
    Q{선택}
    Q -->|AWS only OK + 빠른 시작| ECS[ECS]
    Q -->|K8s 표준 / 이식성 / 큰 생태계| EKS[EKS]

흔한 함정

[!WARNING]

VPC IP 고갈 = pod 수 × ENI 한도. secondary CIDR 추가 또는 prefix delegation 활성.

EKS 버전 업그레이드 = control plane → node → add-on 순서. minor 한 번 (n+1 만).

kubeconfig 의 AWS auth = aws eks update-kubeconfig. IAM 변경 시 인증 깨짐.

Fargate + DaemonSet = Fargate 가 DaemonSet 미지원. log/metric sidecar 가 각 Fargate task 안.

[AWS] EventBridge: 이벤트 버스, 스케줄러, partner sources

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

EventBridge = AWS 의 통합 event bus. 옛 CloudWatch Events 의 후계. AWS service 이벤트 + custom 이벤트 + SaaS 이벤트 를 한 곳에서.

Event Bus 종류

종류	의미
Default	AWS service 이벤트 (EC2, S3, CodePipeline 등)
Custom	자체 이벤트
Partner	SaaS (Datadog, MongoDB, Auth0, …)

Event 형식

{
  "version": "0",
  "id": "...",
  "detail-type": "Order Created",
  "source": "myapp.orders",
  "account": "123",
  "time": "2026-06-25T12:00:00Z",
  "region": "us-east-1",
  "resources": [],
  "detail": {
    "order_id": "o_42",
    "user_id": "u_99",
    "total": 5000
  }
}

Rule + Target

flowchart LR
    Event[Event] --> Bus[Event Bus]
    Bus --> Rule1["Rule 1<br/>(pattern)"]
    Rule1 --> Target1[Lambda]
    Rule1 --> Target2[SQS]
    Bus --> Rule2["Rule 2<br/>(다른 pattern)"]
    Rule2 --> Target3[Step Functions]

{
  "source": ["myapp.orders"],
  "detail-type": ["Order Created"],
  "detail": {
    "total": [{ "numeric": [">=", 10000] }]
  }
}

Content-based filtering. 복잡한 매칭 가능 (prefix, suffix, anything-but, numeric, exists, …).

Target 종류

Lambda
SQS / SNS
Step Functions
ECS Task / EKS / Batch
Kinesis / Firehose
API Destination (외부 HTTP)
다른 EventBridge bus / Event Bus in 다른 account

EventBridge Scheduler (2022+)

aws scheduler create-schedule \
  --name daily-report \
  --schedule-expression "cron(0 9 * * ? *)" \
  --schedule-expression-timezone "Asia/Seoul" \
  --target '{
    "Arn": "arn:lambda:...",
    "RoleArn": "arn:role:..."
  }' \
  --flexible-time-window '{ "Mode": "OFF" }'

CloudWatch Events Schedule 의 후계 + 더 정교. 수백만 schedule, cron / rate / one-time.

Schema Registry

Schemas:
  - myapp.orders.OrderCreated@v2
    - 필드: order_id (string), total (number), ...

이벤트 schema 중앙 보관.
다국어 코드 생성 (Java, Python, TS).
contract 변경 추적.

Pipes (2022+)

flowchart LR
    Source["Source<br/>(SQS, Kinesis, DDB Stream, ...)"] --> Filter[Filter]
    Filter --> Enrich["Enrich (Lambda)"]
    Enrich --> Target["Target<br/>(Lambda, SQS, SF, ...)"]

Pipe = source → filter → enrich → target 의 one-stop ETL.

EventBridge vs SNS

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

요약:

SNS = 대량 fan-out (12.5M subscriber)
EventBridge = 복잡 라우팅 + filtering + SaaS 통합

흔한 함정

[!WARNING]

Rule pattern 의 잘못된 JSON = silently no match. CloudWatch 로 DeliveryFailure 모니터링.

Cross-account 이벤트 = source bus 의 permission policy 와 target bus 의 PutEvents 권한.

Schema 변경 = registry 의 versioning 활용. consumer 영향 평가.

Target 의 retry 한도 = 24시간 retry. DLQ 필수.

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

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

IAM (Identity and Access Management) = AWS 의 권한 관리 전부. User, Group, Role, Policy.

객체

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 묶음
Role	임시 권한 받는 entity (EC2, Lambda, 외부 계정 등)
Policy	권한 표현 (JSON)

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" }
      }
    }
  ]
}

Policy 종류

종류	의미
AWS Managed	AWS 가 관리 (`AmazonS3ReadOnlyAccess`)
Customer Managed	사용자 정의, 재사용 가능
Inline	User/Group/Role 에 직접 임베드 (재사용 불가)
Permission Boundary	최대 권한 상한
Service Control Policy (SCP)	Organization 수준
Resource-based Policy	자원에 붙음 (S3 bucket policy 등)

권한 평가 알고리즘

flowchart TD
    Q1{Explicit Deny?}
    Q1 -->|예| Deny[DENY]
    Q1 -->|아니오| Q2{Explicit Allow?}
    Q2 -->|아니오| Deny
    Q2 -->|예| Q3{SCP 차단?}
    Q3 -->|예| Deny
    Q3 -->|아니오| Q4{Permission Boundary 안?}
    Q4 -->|아니오| Deny
    Q4 -->|예| Allow[ALLOW]

Explicit Deny 가 모든 것을 이김.

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

IRSA / Pod Identity (EKS)

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

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시간).

Best Practice

✓ Root user 의 MFA + 일상 사용 금지
✓ User 대신 SSO (Identity Center)
✓ Role 우선 (long-term credentials 회피)
✓ Least privilege (필요한 권한만)
✓ Permission Boundary 로 *최대* 제한
✓ Access Analyzer 로 unused 권한 식별
✓ IAM Access Advisor 로 미사용 확인
✓ MFA 강제
✓ Credentials rotation 정기

흔한 함정

[!WARNING]

Root user 의 access key = 누출 = 모든 권한. delete 후 SSO.

"*" 권한 남발 = 사고. 작은 권한 부터.

Long-term access key = git 누출 사고. Role + STS.

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

[AWS] KMS: 암호화 키 관리, envelope encryption

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

KMS (Key Management Service) = 암호화 키 중앙 관리. envelope encryption + IAM 통합 + 감사 로그.

키 종류

종류	의미
AWS Managed Key	AWS 가 service 별 자동 (`aws/s3`, `aws/secretsmanager`)
Customer Managed Key (CMK)	사용자 관리. 정책, 회전, 권한
AWS Owned Key	service 가 공유 사용 (보이지 않음)
External (BYOK)	사용자가 키 자체 가져옴
CloudHSM-backed	HSM 에 보관

Envelope Encryption

flowchart LR
    Plain["plaintext data (1GB)"]
    Plain --> Encrypt["AES-GCM 암호화"]
    DK["data key (DEK)"] --> Encrypt
    Encrypt --> Cipher["ciphertext"]
    DK -->|KMS 로 암호화| KMS[KMS encrypt with CMK]
    KMS --> EncDK["encrypted data key"]
    Cipher --> Store["저장: ciphertext + encrypted DK"]

KMS 가 데이터 자체를 암호화 하지 않음.
클라이언트가 작은 data key (DEK) 로 데이터 암호화.
KMS 는 DEK 만 암호화.
큰 데이터의 KMS 호출 회수 절감.

흐름

sequenceDiagram
    App->>KMS: GenerateDataKey(KeyId=arn:cmk)
    KMS-->>App: { plaintext: DEK, ciphertext: encrypted_DEK }
    App->>App: encrypt data with DEK (AES-GCM)
    App->>App: DEK 메모리에서 삭제
    App->>S3: PUT { encrypted_data, encrypted_DEK }
    
    Note over App,S3: 나중에 복호화
    App->>S3: GET encrypted_data + encrypted_DEK
    App->>KMS: Decrypt(encrypted_DEK)
    KMS-->>App: plaintext DEK
    App->>App: decrypt data

Key Policy + IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow root",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow encrypt/decrypt",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123:role/app" },
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*"
    }
  ]
}

Key Policy 와 IAM Policy 둘 다 허용 해야 동작.

Key Rotation

EnableKeyRotation: true   # 1년마다 자동 회전

이전 키 버전 보존: 옛 ciphertext 복호화 가능.
수동 회전: 새 CMK 생성 + alias 옮김.

Encryption at Rest 자동

서비스	KMS 통합
S3	SSE-KMS
EBS	volume 단위
RDS	DB 전체
DynamoDB	자동
Lambda env vars	자동
Secrets Manager	자동

“encryption at rest 켜기” 의 거의 모든 내부 구현 이 KMS.

CloudTrail 로그

KMS API 호출 (Encrypt, Decrypt, GenerateDataKey) 모두 기록
누가 / 언제 / 어떤 키 / 어떤 자원

가격

$1/CMK/월
$0.03 / 10k API
Envelope encryption 으로 API 호출 절감 이 핵심.

흔한 함정

[!WARNING]

모든 곳에 Decrypt 권한 = 한 곳 침해 = 전부 복호화. 최소 권한.

Cross-region 사용 시도 = KMS key 는 region 별. region 간 암호화는 별도 키.

Key 삭제 = 7-30일 대기 후 영구 삭제. 복구 불가.

CloudHSM 으로 마이그레이션 = 어렵다. 시작 전 결정.

[AWS] Lambda Cold Start: 원인과 완화

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Cold Start = Lambda 가 처음 호출 또는 idle 후 다시 호출 시 컨테이너 + 런타임 + 사용자 코드 init 의 시간.

단계

flowchart TB
    Inv[Invocation] --> Box{Warm container?}
    Box -->|Yes| Handle[handler 실행<br/>~ms]
    Box -->|No| Cold[Cold Start]
    Cold --> S1[1. Firecracker microVM 생성]
    Cold --> S2[2. Runtime 부팅]
    Cold --> S3[3. 사용자 코드 download/extract]
    Cold --> S4[4. Init handler 실행]
    S4 --> Handle

단계	시간 (Node)
MicroVM 생성	~50ms
Runtime 부팅	~50ms
코드 load	~50ms (의존성 크기 비례)
Init code	사용자 책임

Runtime 별 cold start (직관)

완화 4 단계

1. Provisioned Concurrency

aws lambda put-provisioned-concurrency-config \
  --function-name my-func \
  --qualifier prod \
  --provisioned-concurrent-executions 10

10 instance 미리 워밍.
콜드 스타트 0.
비용: idle 도 청구.

[!TIP] latency 예측 가능 필요 한 API 만. batch / async 는 불필요.

2. Lambda SnapStart (Java)

flowchart LR
    Build["배포 시<br/>handler init 실행 → snapshot"] -.-> Inv["호출 시<br/>snapshot 복원 → handler 즉시 실행"]

Java cold start 1500ms → 150ms.
snapshot 안에 DB 연결 같은 unique value 주의 (uniqueness 깨짐).

3. 코드 최적화

// ❌ handler 안에서
export const handler = async (event) => {
  const db = new DBClient();   // 매 호출 새 연결!
  ...
};

// ✅ handler 밖 (init 시 1회)
const db = new DBClient();
export const handler = async (event) => {
  ...
};

4. Bundle 크기 줄이기

도구	효과
esbuild	tree-shake + minify
webpack	동일
Layer 분리	큰 의존성을 layer 로
Lambda Container Image	tag 단위 캐싱

Warm 유지 (anti-pattern)

# CloudWatch Events 로 5분마다 ping
schedule: rate(5 minutes)
target: lambda function

[!CAUTION] 옛 워크어라운드. 현재는 Provisioned Concurrency 가 정통. ping 방식은 불안정 + 동시 N 인스턴스 보장 안 됨.

측정

import time
import os
print(f"INIT, container: {os.environ.get('AWS_LAMBDA_LOG_STREAM_NAME')}, t={time.time()}")

def handler(event, context):
    print(f"HANDLER, t={time.time()}")

CloudWatch Logs 에서 INIT vs HANDLER 의 시간 차 = cold start.

VPC Lambda 의 cold start (옛 vs 현재)

시점	Cold Start (VPC)
~2019	5-15초 (ENI 생성)
2019+ (Hyperplane)	~1초 추가
2026 (Firecracker + warm pool)	거의 일반과 동일

[AWS] Lambda: 서버리스 함수, 트리거, 동시성

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

AWS Lambda = 서버리스 함수 실행. 이벤트 트리거 → 함수 실행 → 결과 / 비동기 처리. 서버 관리 0.

트리거 종류

flowchart LR
    HTTP[API Gateway / ALB] --> L[Lambda]
    SQS --> L
    SNS --> L
    Kinesis --> L
    DDB[DynamoDB Streams] --> L
    S3[S3 events] --> L
    EB[EventBridge] --> L
    CW[CloudWatch Events] --> L
    Cognito --> L
    LB[ALB target group] --> L

트리거	모델
API Gateway / ALB	sync (HTTP)
SQS	async (poll)
Kinesis / DynamoDB Streams	poll + ordered
S3 / SNS / EventBridge	event
Cron (EventBridge Scheduler)	scheduled

함수 작성

// Node.js
export const handler = async (event, context) => {
  console.log('event', event);
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'hello' }),
  };
};

# Python
def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'hello'})
    }

실행 모델

모드	의미
Request-Response (sync)	호출자가 응답 대기
Async	invoke 후 즉시 반환, 재시도 자동
Stream (Kinesis)	batch 처리

Concurrency

flowchart LR
    Req[1000 동시 요청] --> L[Lambda]
    L --> I1["Instance 1<br/>(1 req 동시)"]
    L --> I2[Instance 2]
    L --> IN[Instance N]
    Note["account-wide quota: 1000 (default)<br/>증가 요청 가능"]

종류	의미
Unreserved (기본)	account 공통 풀
Reserved concurrency	함수에 한도 / 보장 분리
Provisioned concurrency	미리 워밍업 + 콜드 스타트 0

Cold Start

sequenceDiagram
    Trigger->>Lambda: invoke
    Note over Lambda: container 없음
    Lambda->>Lambda: init (시작) ~50-1000ms
    Lambda->>Lambda: handler 실행
    Lambda-->>Trigger: 응답
    Note over Lambda: ~5분 idle 후 instance 종료

Runtime	평균 cold start
Node 22	~150ms
Python 3.13	~200ms
Go	~50ms
Rust	~30ms
Java	500ms-2s (가장 느림)
Java + SnapStart	~150ms

Cold Start 완화

Provisioned Concurrency: 항상 N개 워밍업.
Lambda SnapStart (Java): snapshot 으로 빠르게.
smaller package (코드 / dependency).
avoid VPC (옛 cold start 5초+, 현재는 빠름).
함수 분리 (큰 모놀리스 함수 회피).

Memory & CPU

Memory 늘리면 CPU 도 비례 증가. gp 결정의 단일 dial.

Memory	vCPU
128 MB	0.083
1024 MB	0.6
1769 MB	1.0 (full vCPU)
10240 MB	5.78

가격

요금 = (실행 시간 ms) × (Memory GB) × $0.0000166667
+ (실행 횟수) × $0.20/M

짧고 자주 호출되면 호출 비용, 긴 실행 이면 시간 비용. 모니터링 필요.

Layers (공유 코드)

Layers:
  - arn:aws:lambda:us-east-1:123456789012:layer:common-deps:5

여러 함수가 공유.
의존성 분리 → 함수 코드 작아짐.
5 layer per function 한도.

Lambda 의 적합 / 부적합

적합	부적합
짧은 처리 (< 15분)	장시간 처리 (> 15분)
비동기 이벤트 처리	지속 연결 (WebSocket idle)
API endpoint	극저지연 (cold start 부담)
ETL batch	큰 메모리 (10GB 초과)
스케일 spike 흡수	GPU 워크로드

흔한 함정

[!WARNING]

VPC 안 Lambda 의 cold start = ENI 생성. 현대는 빠르지만 옛 사고 기억.

handler 안에 DB 연결 = cold start 마다 새 연결. handler 밖 전역 으로 (warm reuse).

timeout 너무 짧음 = 무거운 처리 fail. 모니터링 + 늘림.

동시성 한도 = account 한도 1000 (default). 갑작스런 spike 시 throttling.

[AWS] RDS Multi-AZ + Read Replica

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

RDS (Relational Database Service) = AWS 의 managed RDB. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora (AWS 자체).

Multi-AZ Deployment

flowchart LR
    Primary["Primary (AZ a)<br/>Master"]
    Primary -->|sync 복제| Standby["Standby (AZ b)<br/>passive"]
    Primary --> Client
    Note["Standby = 읽기 불가<br/>(HA 용)"]

동기 복제.
AZ 장애 시 자동 failover (1-2분).
Read 분산 불가 (Standby = passive).

Read Replica

flowchart LR
    Primary["Primary"]
    Primary -.async 복제.-> R1["Read Replica 1"]
    Primary -.async.-> R2["Read Replica 2"]
    Primary -.async (cross-region).-> R3["Read Replica 3<br/>(다른 region)"]
    Client -->|writes| Primary
    Client -->|reads| R1 & R2 & R3

비동기 복제 (lag 가능).
읽기 부하 분산.
Cross-region 가능 (DR).
Standalone DB 로 승격 가능.

Aurora vs RDS MySQL/PostgreSQL

	RDS MySQL/PG	Aurora MySQL/PG
스토리지	EBS	AWS 자체 분산 (3 AZ × 2 복제)
처리량	표준	3-5배 빠름
백업	snapshot	continuous 백업 (PITR)
Read Replica	5개 한도	15개 + reader endpoint
Failover	1-2분	< 30초
가격	약간 cheap	약간 비쌈
Serverless	옵션	Aurora Serverless v2

[!IMPORTANT] 2026 신규 = 거의 항상 Aurora. RDS MySQL/PG 보다 비싸지만 더 빠른 + 안정.

Aurora 분산 스토리지

flowchart TB
    Compute["Compute (DB engine)"]
    Compute --> Storage["Cluster Volume (자체)"]
    Storage --> AZa1["AZ a copy 1"]
    Storage --> AZa2["AZ a copy 2"]
    Storage --> AZb1["AZ b copy 1"]
    Storage --> AZb2["AZ b copy 2"]
    Storage --> AZc1["AZ c copy 1"]
    Storage --> AZc2["AZ c copy 2"]

6 copy, 3 AZ.
quorum (4/6 write, 3/6 read).
2 copy 손실 OK (가용성), 3 copy 손실 OK (durability).

RDS Proxy

flowchart LR
    Lambda --> RDSProxy["RDS Proxy<br/>(connection pool)"]
    EC2 --> RDSProxy
    RDSProxy -->|pool 재사용| RDS[(RDS)]

Connection pool 을 AWS managed 로.
Lambda 의 connection 폭증 해결.
failover 시간 단축.

Aurora Serverless v2

자동 scaling (0.5 ACU - 128 ACU).
cold start 없음 (v1 의 결함 해결).
가변 워크로드 / dev / test.

Aurora Global Database

flowchart LR
    Primary["Primary Cluster (us-east-1)"]
    Primary -.<1s 복제.-> Sec1["Secondary (eu-west-1)"]
    Primary -.-> Sec2["Secondary (ap-northeast-1)"]
    Note["DR: < 1분 failover<br/>Read: 글로벌 분산"]

백업

종류	의미
Automated backup	매일 + WAL. PITR (Point-in-Time Recovery)
Manual snapshot	수동, 영구
Aurora Backtrack	옛 시점으로 DB 자체 회귀 (snapshot 없이)

흔한 함정

[!WARNING]

Multi-AZ ≠ Read Replica = Multi-AZ 의 standby 는 읽기 불가. RR 가 별도.

Aurora major version upgrade = downtime 있음. 충분한 테스트.

Read Replica lag = async 복제. read-your-writes 가 깨질 수 있음.

Aurora storage 비용 = 사용량만큼 (max 와 무관). 단 읽기 IOPS 비용 도 별도.

[AWS] Route 53: DNS, routing policies, health checks

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Route 53 = AWS 의 글로벌 DNS + health check + 라우팅 정책. 단순 DNS 뿐 아니라 글로벌 트래픽 분산.

Hosted Zone

Hosted Zone: example.com
└── Record:
    A      api.example.com   →  192.0.2.1
    CNAME  www.example.com   →  example.com
    MX     example.com       →  mail.example.com
    TXT    _verification     →  "google-site-verification=..."

Alias Record (AWS 전용)

A alias api.example.com → AWS Load Balancer (xx.amazonaws.com)

CNAME 보다:

root domain 가능 (CNAME 은 root 불가)
무료 query
IP 자동 갱신

라우팅 정책 7가지

flowchart TB
    Q[Routing Policy]
    Q --> Simple[Simple]
    Q --> Weighted[Weighted<br/>10% canary]
    Q --> Latency[Latency<br/>가장 빠른 region]
    Q --> Failover[Failover<br/>primary + secondary]
    Q --> Geo[Geolocation<br/>국가별]
    Q --> GeoProx[Geoproximity<br/>바이어스 적용]
    Q --> MV[Multi-Value Answer<br/>여러 IP 반환]

Weighted (Canary)

api.example.com (200)
  → 10% → 신 ALB
  → 90% → 옛 ALB

Latency-Based

flowchart LR
    Client[Asia 사용자] -->|DNS query| R53[Route 53]
    R53 -->|measure latency| Asian[Asia ALB]
    R53 -->|measure| US[US ALB]
    R53 -->|measure| EU[EU ALB]
    R53 -->|가장 빠른 = Asia| Client
    Client --> Asian

Failover

primary: api-prod.example.com (health check)
secondary: api-dr.example.com (health check)

primary unhealthy → secondary 자동 응답.

Health Check

HealthCheck:
  Type: HTTPS
  ResourcePath: /health
  FullyQualifiedDomainName: api.example.com
  RequestInterval: 30
  FailureThreshold: 3
  Regions: [us-east-1, us-west-2, ap-northeast-1]  # 다중 region 동시 체크

3개 region 의 과반 이상 unhealthy → unhealthy 판정.

DNSSEC

aws route53 enable-hosted-zone-dnssec --hosted-zone-id Z0123

DNS 응답에 디지털 서명 → DNS 위조 (cache poisoning) 방어.

Private Hosted Zone

domain: internal.local
visibility: VPC associated

VPC 안에서만 resolve. 내부 service 명명에 활용.

흔한 함정

[!WARNING]

TTL 너무 큼 = failover 시 옛 IP 캐시 → 다운타임 길음. 일반 60s.

CNAME root domain 시도 = 거절. Alias 또는 redirect (CloudFront).

Health check 의 IP-only = TLS 검증 안 됨. HTTPS health check 권장.

다중 region failover 의 RTO = TTL + health check interval. 분 단위 가능.

[AWS] S3: object storage, storage classes, lifecycle

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

S3 = AWS 의 object storage. bucket + key + object. 11 9’s durability, 무한 확장. 2026 시점 인터넷의 핵심 스토리지.

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+ 시간

Lifecycle Policy

Rules:
  - Id: archive-old-logs
    Filter: { Prefix: logs/ }
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 90
        StorageClass: GLACIER
    Expiration:
      Days: 365

비용 대폭 절감. 사용 안 하는 데이터를 자동 cheaper class 로.

Versioning

aws s3api put-bucket-versioning --bucket my --versioning-configuration Status=Enabled

덮어쓰기 / 삭제 = 옛 버전 보존.
실수 복구 가능.
비용 2배 (옛 버전도 저장).

Object Lock (WORM)

Mode: GOVERNANCE | COMPLIANCE
RetainUntilDate: 2027-06-25

Write Once Read Many.
컴플라이언스 (금융 / 의료).
COMPLIANCE: root user 도 삭제 불가.

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 초과 시 필수.
병렬 + 재시도 가능.

Presigned URL

url = s3.generate_presigned_url(
    'put_object',
    Params={'Bucket': 'my', 'Key': 'upload.zip'},
    ExpiresIn=3600
)

클라이언트가 S3 에 직접 업로드/다운로드 (서버 우회).
임시 URL.

Static Website Hosting

Bucket Property: Static Website Hosting
  Index document: index.html
  Error document: error.html

CloudFront 추가 = 글로벌 CDN 정적 사이트.

Event Notifications

flowchart LR
    Upload[Object 업로드] --> S3
    S3 -->|event| Lambda
    S3 -->|event| SQS
    S3 -->|event| SNS
    S3 -->|event| EventBridge

새 파일 → 처리 자동.
이미지 thumbnail 생성, 비디오 transcoding, 데이터 처리.

S3 Select / S3 Object Lambda

S3 Select: CSV/JSON/Parquet 의 SQL 일부 query.
S3 Object Lambda: GET 시 Lambda 가 transform (redact, watermark).

보안

flowchart TD
    Q[보안 layer]
    Q --> Block["Block Public Access (계정/bucket)"]
    Q --> Bucket[Bucket Policy]
    Q --> IAM[IAM Policy]
    Q --> ACL["ACL (legacy)"]
    Q --> Enc["Server-Side Encryption (SSE)"]
    Q --> KMS[KMS 키]
    Q --> Object[Object Lock]

Encryption

종류	의미
`SSE-S3`	S3 관리 key
`SSE-KMS`	KMS 관리 key
`SSE-C`	사용자 제공 key
`DSSE-KMS`	이중 암호화

흔한 함정

[!WARNING]

Bucket 공개 사고 = “Block Public Access” 항상 켜기. CloudFront + OAC 권장.

Versioning 후 비용 = 옛 버전 누적. lifecycle 로 정리.

Lifecycle 의 retrieval fee = Glacier 에서 빨리 꺼내면 비용 큼.

Multipart upload 정리 안 함 = 미완료 multipart 가 비용 발생. lifecycle AbortIncompleteMultipartUpload.

[AWS] Secrets Manager + Parameter Store

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

	Secrets Manager	Parameter Store (SSM)
가격	$0.40/secret/월 + $0.05/10k API	대부분 무료 (standard)
자동 회전	예 (Lambda)	아니오
버전 관리	자동	수동
크기	64KB	4KB (standard) / 8KB (advanced)
사용	DB password, API key (회전 필요)	config, feature flag

어떤 걸 언제?

flowchart TD
    Q{종류}
    Q -->|회전 필요한 비밀| SM[Secrets Manager]
    Q -->|회전 없는 설정값| PS[Parameter Store standard]
    Q -->|"민감 설정값 (회전 없음)"| PSSec[Parameter Store SecureString]
    Q -->|kubernetes secret 으로 sync| ESO[External Secrets Operator]

Secret 사용

import boto3, json
sm = boto3.client('secretsmanager')
secret = json.loads(sm.get_secret_value(SecretId='prod/db')['SecretString'])
db_password = secret['password']

자동 회전

sequenceDiagram
    SM->>Lambda: rotation 시작 (예: 30일마다)
    Lambda->>DB: 새 password 생성
    Lambda->>DB: 새 password 설정
    Lambda->>SM: AWSPENDING → AWSCURRENT
    Lambda->>SM: 옛 AWSCURRENT → AWSPREVIOUS
    Note over Lambda,DB: 새 password 검증

단계	label
생성	`AWSPENDING`
활성화	`AWSCURRENT`
보존	`AWSPREVIOUS`
폐기	(없음)

EKS 와의 통합

패턴	도구
Sync to K8s Secret	External Secrets Operator
Mount as volume	Secrets Store CSI Driver
Direct fetch in pod	aws-sdk + IRSA

Parameter Store: 계층

/prod/db/host
/prod/db/port
/prod/api/key
/dev/db/host

aws ssm get-parameters-by-path --path /prod/db --recursive

흔한 함정

[!WARNING]

Hardcoded fallback = 코드에 secret 평문. 절대 금지.

Cross-region replication 없음 = region 장애 시 secret 미접근. Multi-region 권장.

Rotation 실패 모니터링 부재 = 옛 password 만료 → 서비스 다운.

Parameter Store 의 4KB 한도 = 큰 비밀 (인증서) 은 advanced 또는 Secrets Manager.

[AWS] Security Group vs NACL: stateful vs stateless 방화벽

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

	SG (Security Group)	NACL (Network ACL)
상태	Stateful	Stateless
적용	ENI / instance	subnet
규칙	allow 만	allow + deny
평가	모든 규칙	번호 순
기본	inbound deny + outbound allow all	allow all

Stateful vs Stateless 의 의미

sequenceDiagram
    Client->>SG: TCP SYN (port 80 inbound)
    SG->>Server: forward
    Note over SG: connection 기억
    Server->>SG: SYN-ACK (응답)
    SG-->>Client: forward (state 인식, outbound 규칙 무시)

Stateful (SG): 들어온 연결 = 나가는 응답 자동 허용.
Stateless (NACL): 모든 패킷 양방향 규칙 필요. ephemeral port (1024-65535) 까지.

SG 예시

SecurityGroup:
  Description: web servers
  IngressRules:
    - Protocol: tcp
      Port: 443
      CidrIp: 0.0.0.0/0
    - Protocol: tcp
      Port: 22
      CidrIp: 10.0.0.0/16    # 내부 SSH
  EgressRules:
    - Protocol: -1            # 모든 outbound (기본)
      CidrIp: 0.0.0.0/0

SG referencing SG (강력!)

IngressRules:
  - Protocol: tcp
    Port: 5432
    SourceSecurityGroupId: sg-web   # web SG 가진 instance 만 허용

IP 가 아니라 다른 SG 자체. dynamic 환경에서 IP 추적 없이 권한 제어.

NACL 예시

Rules:
  - RuleNumber: 100
    Action: allow
    Protocol: 6   # TCP
    PortRange: { From: 443, To: 443 }
    CidrBlock: 0.0.0.0/0
  - RuleNumber: 200
    Action: allow
    Protocol: 6
    PortRange: { From: 1024, To: 65535 }   # ephemeral
    CidrBlock: 0.0.0.0/0
  - RuleNumber: 32767
    Action: deny
    Protocol: -1

평가 순서

flowchart TD
    Packet[Packet 도착]
    Packet --> SG_In[SG inbound 규칙 평가]
    SG_In --> NACL_In["NACL inbound 평가 (번호 순)"]
    NACL_In --> Routing[VPC routing]
    Routing --> NACL_Out[NACL outbound]
    NACL_Out --> SG_Out[SG outbound]

Default Deny vs Allow

	SG	NACL
기본 inbound	deny all	allow all
기본 outbound	allow all	allow all
명시 deny	불가	가능

SG 는 허용만 추가. NACL 은 deny 도 가능 → 특정 IP 차단 같은 용도.

흔한 함정

[!WARNING]

NACL 의 ephemeral port 누락 = 응답이 차단. SG 처럼 stateful 이 아님.

SG 의 outbound 닫음 = NAT 응답 차단. 일반 적으로 outbound 는 기본 allow.

SG 변경 즉시 반영 = 새 연결만. 기존 연결은 남아있을 수 있음.

너무 넓은 0.0.0.0/0 = SSH 22 public = 즉시 공격. Session Manager 사용.

[AWS] SNS: pub-sub fan-out

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

SNS (Simple Notification Service) = pub-sub fan-out. 한 message → 여러 subscriber 에 동시 배포.

구조

{}

flowchart LR
    P[Publisher] --> Topic[SNS Topic]
    Topic --> S1[SQS Queue 1]
    Topic --> S2[SQS Queue 2]
    Topic --> S3[Lambda]
    Topic --> S4[Email]
    Topic --> S5[SMS / Mobile Push]
    Topic --> S6[HTTP/HTTPS endpoint]

Subscriber 종류

종류	사용
SQS	큐 fan-out
Lambda	비동기 처리
Email	알림
SMS	알림 (전세계)
Mobile Push	APNS, FCM
HTTP/HTTPS	webhook
Kinesis Data Firehose	데이터 흐름

Standard vs FIFO Topic

	Standard	FIFO
순서	best-effort	strict (group)
중복	가능	5분 dedup
처리량	무한	300/s
Subscriber	모든 종류	SQS FIFO 만

Message Filtering

"FilterPolicy": {
  "event_type": ["order.created", "order.paid"],
  "region": ["us-east-1"]
}

Subscriber 마다 받을 메시지 필터. 한 topic 에 다양한 event 보내고 각 subscriber 가 관심사만.

SNS + SQS Fan-out 패턴

flowchart LR
    Order[Order Service] -->|publish OrderCreated| Topic
    Topic --> Q1[Queue: shipping]
    Topic --> Q2[Queue: analytics]
    Topic --> Q3[Queue: notification]
    Q1 --> Shipping[Shipping consumer]
    Q2 --> Analytics[Analytics consumer]
    Q3 --> Notify[Notification consumer]

Pub-sub + queue durability. SNS 의 fan-out + SQS 의 영속.

	SNS	EventBridge
Subscriber 수	12.5M / topic	5 target / rule
Filtering	단순 (key=value)	advanced (content-based, schema)
Schema Registry	없음	있음
가격	저렴	약간 비쌈
사용	high fan-out	복잡 라우팅 / 외부 SaaS

흔한 함정

[!WARNING]

HTTP subscriber 인증 없음 = aws에서 온 척 한 webhook 위조. SNS signature 검증 필수.

Standard topic의 중복 = subscriber 가 idempotent.

Filter policy 잘못 = silently drop. CloudWatch 메트릭으로 확인.

DLQ 미설정 = subscriber 실패 시 재시도 후 손실. SNS subscription DLQ.

[AWS] SQS: managed queue, FIFO, DLQ

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

SQS = AWS 의 완전 관리형 메시지 큐. infinite scale, no provisioning, pay-per-request.

Standard vs FIFO

	Standard	FIFO
처리량	거의 무한	300 msg/s (batching 시 3000)
순서	best-effort	strict (group 안)
중복	at-least-once (드물게 중복)	exactly-once (5분 dedup)
가격	cheap	약간 비쌈

흐름

{}

sequenceDiagram
    P->>SQS: SendMessage
    SQS-->>P: messageId
    C->>SQS: ReceiveMessage (long poll)
    SQS-->>C: message + receiptHandle
    Note over SQS: message *invisible* (visibility timeout)
    C->>C: 처리
    C->>SQS: DeleteMessage(receiptHandle)

Visibility Timeout

flowchart LR
    Recv[Receive] -->|invisible 30s 기본| Hidden[다른 consumer 안 보임]
    Hidden -->|delete 받음| Removed[제거]
    Hidden -->|timeout 만료| Visible[다시 보임 = retry]

처리 시간 + 안전 마진 으로 설정. 짧으면 중복 처리, 길면 재시도 지연.

DLQ (Dead Letter Queue)

RedrivePolicy:
  deadLetterTargetArn: arn:aws:sqs:...:my-dlq
  maxReceiveCount: 5

5회 처리 실패 → DLQ 로. 운영자 검사 후 redrive.

Long Polling

sqs.receive_message(
    QueueUrl=q,
    WaitTimeSeconds=20,   # long poll (max 20s)
    MaxNumberOfMessages=10,
)

메시지 없으면 20초 기다림. 짧은 polling 보다 API call 절감 + latency 낮음.
거의 항상 사용.

SQS + Lambda

EventSourceMapping:
  EventSourceArn: arn:aws:sqs:...
  FunctionName: my-func
  BatchSize: 10
  MaximumBatchingWindowInSeconds: 5

AWS 가 자동으로 batch poll + Lambda 호출 + delete.

FIFO + MessageGroupId

sqs.send_message(
    QueueUrl=q,
    MessageBody='...',
    MessageGroupId='user-42',          # 같은 group = 순서 보장
    MessageDeduplicationId='unique-id'
)

같은 group = 한 consumer 가 순서대로.
다른 group = 병렬.

Standard vs Kafka

	SQS	Kafka
운영	0 (managed)	큼
처리량	무한 (auto)	노드 수 비례
Retention	최대 14일	무제한 (디스크)
Replay	DLQ 만	자유
Fan-out	SNS 와 결합	consumer group
비용	사용량 비례	인프라 비례

AWS only + 단순 큐 = SQS. 영속 + 재처리 + 큰 throughput = Kafka (또는 MSK).

흔한 함정

[!WARNING]

At-least-once 중복 = consumer idempotent 필요. [[idempotency-keys]].

Visibility timeout 짧음 = 처리 도중 message 가 다른 consumer 에게 다시. 처리 시간 모니터링.

DLQ 미설정 = 실패 message 영원히 재시도.

FIFO 의 group 부재 = 모든 message 가 한 group 으로 = 단일 consumer = 처리량 30 msg/s.

[AWS] Step Functions: 워크플로 오케스트레이션

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Step Functions = 서버리스 워크플로 오케스트레이션. Amazon States Language (ASL, JSON) 으로 상태 기계 정의.

ASL 예시

{
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:validate",
      "Next": "ChargePayment",
      "Retry": [{
        "ErrorEquals": ["Lambda.ServiceException"],
        "MaxAttempts": 3,
        "BackoffRate": 2.0
      }],
      "Catch": [{
        "ErrorEquals": ["ValidationError"],
        "Next": "OrderFailed"
      }]
    },
    "ChargePayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:charge",
      "Next": "ReserveInventory",
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "RefundPayment"
      }]
    },
    "ReserveInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:reserve",
      "Next": "ShipOrder"
    },
    "ShipOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:ship",
      "End": true
    },
    "OrderFailed": { "Type": "Fail", "Cause": "Validation" },
    "RefundPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:refund",
      "Next": "OrderFailed"
    }
  }
}

시각화

flowchart TD
    Start --> Validate[ValidateOrder]
    Validate -->|성공| Charge[ChargePayment]
    Validate -->|ValidationError| Fail[OrderFailed]
    Charge -->|성공| Reserve[ReserveInventory]
    Charge -->|에러| Refund[RefundPayment]
    Reserve --> Ship[ShipOrder]
    Refund --> Fail
    Ship --> End[(End)]

자세한 saga 흐름은 [[saga-pattern]].

State 종류

Type	의미
`Task`	Lambda, ECS, Glue, SNS, SQS 등
`Choice`	if-else 분기
`Wait`	대기 (sec, timestamp)
`Parallel`	동시 실행
`Map`	배열 iterate
`Pass`	데이터 변환만
`Succeed` / `Fail`	종료

Standard vs Express

	Standard	Express
실행 시간	최대 1년	5분
가격 모델	per-transition	duration
적합	long-running (인간 승인)	짧은 API
실행 이력	90일	짧음
Throughput	2000/s	100,000+/s

Map (배열 처리)

{
  "Type": "Map",
  "ItemsPath": "$.orders",
  "MaxConcurrency": 10,
  "Iterator": {
    "StartAt": "ProcessOne",
    "States": {
      "ProcessOne": {
        "Type": "Task",
        "Resource": "arn:lambda:...",
        "End": true
      }
    }
  }
}

수만 ~ 수십만 항목 병렬 처리.

Distributed Map (2022+)

수백만 항목까지. S3 prefix 의 모든 객체 처리 같은 큰 batch.

Wait for Callback

{
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
  "Parameters": {
    "FunctionName": "manual-approval-notifier",
    "Payload": { "taskToken.$": "$$.Task.Token" }
  }
}

인간 승인 / 외부 API 응답 대기. 토큰을 외부에 넘기고 완료 알림 대기.

Step Functions vs Temporal

	Step Functions	Temporal
운영	managed (AWS)	self-host 또는 Temporal Cloud
코드	JSON ASL	언어 코드 (TS, Go, Java, …)
학습 곡선	중간	높음
가격	per-transition	hosted 또는 자체
적합	AWS-native	멀티 클라우드 / 복잡 코드

흔한 함정

[!WARNING]

Retry / Catch 미정의 = 한 단계 실패 = 전체 fail. 명시 정책.

Express 의 5분 한도 = 모르고 사용하면 truncation. Standard 권장 (모르면).

상태 사이 데이터 전달 너무 큼 = 256KB 한도. S3 reference.

시각화만 의존 = 복잡 workflow 의 디버깅 어려움. CloudWatch Logs + X-Ray.

[AWS] STS / AssumeRole: 임시 자격, cross-account

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

STS (Security Token Service) = 임시 자격 증명 발급. short-lived (15분-12시간) credentials.

5가지 API

API	사용
`AssumeRole`	IAM role assume
`AssumeRoleWithWebIdentity`	OIDC (EKS IRSA, GitHub OIDC)
`AssumeRoleWithSAML`	SAML SSO
`GetSessionToken`	MFA token
`GetCallerIdentity`	누구인지

AssumeRole 흐름

sequenceDiagram
    autonumber
    participant User
    participant STS
    participant TargetRole
    participant S3

    User->>STS: AssumeRole(arn:role/admin)
    Note over STS: 신뢰 관계 + 권한 확인
    STS-->>User: { AccessKeyId, SecretAccessKey, SessionToken, Expiration }
    User->>S3: GET object (임시 credentials)
    S3-->>User: object
    Note over User: 1시간 후 만료
    User->>STS: AssumeRole 다시

Cross-Account AssumeRole

flowchart LR
    Acct1["Account 1<br/>(User alice)"] -->|AssumeRole| Acct2Role["Account 2<br/>Role: data-reader"]
    Acct2Role -->|trust policy| Trust["Principal: arn:aws:iam::1:user/alice"]
    Acct2Role -->|permission| S3["S3 in Account 2"]

Trust Policy (Account 2 role)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::ACCOUNT-1:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "shared-secret-string" }
    }
  }]
}

[!IMPORTANT] External ID 가 confused deputy 공격 방어. SaaS 가 우리 계정 접근 시 반드시.

Web Identity (OIDC) - GitHub Actions

permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/github-actions
      aws-region: us-east-1

GitHub 의 OIDC token → AWS role assume. long-term access key 없이.

sequenceDiagram
    GH[GitHub Actions] ->>OIDC: token 발급 (jwt)
    GH->>STS: AssumeRoleWithWebIdentity(token)
    STS->>AWS_OIDC: token 검증 (jwks)
    AWS_OIDC-->>STS: OK
    STS-->>GH: temporary credentials
    GH->>AWS: API 호출

EKS IRSA (위와 동일)

자세한 건 [[aws-eks]] 의 IRSA 절.

Session Tags

aws sts assume-role \
  --role-arn arn:role/x \
  --role-session-name session \
  --tags Key=Team,Value=backend

"Condition": {
  "StringEquals": { "aws:PrincipalTag/Team": "backend" }
}

같은 role 의 세션마다 다른 tag → 세분화 권한.

흔한 함정

[!WARNING]

External ID 누락 = 3rd party 신뢰 약함.

장기 access key 와 혼용 = role 의 의미 깨짐.

세션 만료 갱신 안 함 = 1시간 후 API 호출 실패. SDK 의 자동 refresh 확인.

trust policy 의 너무 넓은 Principal = 모든 user 가 assume.

[AWS] VPC: subnet, route, NAT, peering

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

VPC (Virtual Private Cloud) = AWS 안의 논리적 격리 네트워크. CIDR 정의 + subnet 분할 + 라우팅.

구조

flowchart TB
    VPC["VPC (10.0.0.0/16)"]
    VPC --> AZa["AZ a"]
    VPC --> AZb["AZ b"]
    AZa --> PubA["Public Subnet (10.0.1.0/24)"]
    AZa --> PrvA["Private Subnet (10.0.10.0/24)"]
    AZb --> PubB["Public Subnet (10.0.2.0/24)"]
    AZb --> PrvB["Private Subnet (10.0.20.0/24)"]
    PubA --> IGW[Internet Gateway]
    PubB --> IGW
    PrvA --> NAT[NAT Gateway]
    PrvB --> NAT
    NAT --> PubA

Subnet 종류

종류	정의
Public	route to IGW
Private	route 없음 또는 NAT 경유
Isolated	route 완전 없음

Route Table

Destination       Target
10.0.0.0/16       local        ← VPC 안 통신
0.0.0.0/0         igw-xxx       ← Public subnet (인터넷)
0.0.0.0/0         nat-xxx       ← Private subnet (NAT 경유)
192.168.0.0/16    pcx-xxx       ← peering 다른 VPC

NAT Gateway vs NAT Instance

	NAT Gateway	NAT Instance
관리	AWS	사용자
가격	비싸다 (시간 + GB)	EC2 시간
가용성	AZ 별 (multi-AZ 권장)	EC2 다운 = 다운
처리량	up to 100 Gbps	EC2 type

[!CAUTION] NAT Gateway 비용 이 VPC 의 가장 큰 함정. GB 당 비용 + 시간당 비용. 자세한 정리는 VPC Endpoint (S3/DynamoDB 등) 로 NAT 우회.

VPC Endpoint

flowchart LR
    Pod[Pod in Private Subnet] -.NAT 경유.-> S3
    Pod -->|"VPC Endpoint (gateway)"| S3

종류	의미
Gateway Endpoint	S3, DynamoDB 전용 (무료)
Interface Endpoint	다른 AWS service (PrivateLink)

Gateway Endpoint 추가 만으로 S3/DynamoDB 트래픽이 NAT 우회 + 무료.

Connectivity 옵션

옵션	의미
Internet Gateway	외부 인터넷
NAT Gateway	private → 인터넷
VPC Peering	1:1 VPC 연결
Transit Gateway	Hub-spoke, 다수 VPC + on-prem
VPN Gateway	사이트 VPN
Direct Connect	전용 회선 (큰 대역폭)
VPC Endpoint (PrivateLink)	AWS service / 다른 VPC 의 SaaS

Security Group vs NACL

자세한 건 [[aws-sg-vs-nacl]].

	SG	NACL
Layer	Stateful	Stateless
대상	ENI / instance	Subnet
규칙	allow 만	allow + deny
기본	deny all	allow all

IPv4 CIDR 선택

권장: RFC 1918 사설 대역
10.0.0.0/8       (큰)
172.16.0.0/12    (중간)
192.168.0.0/16   (작은)

피하기: 다른 시스템과 겹칠 가능성

[!IMPORTANT] VPC 의 CIDR 충돌 이 peering / TGW 의 가장 큰 함정. organization 차원 IPAM 으로 사전 분배.

흔한 함정

[!WARNING]

NAT Gateway 비용 폭증 = GB 당. S3 endpoint 누락 시 대규모 비용.

단일 AZ NAT = AZ 장애 시 해당 AZ private subnet 모두 인터넷 차단. multi-AZ.

CIDR 너무 작음 = EKS pod IP 고갈. /16 권장.

Public subnet 에 모든 것 = 잘못된 보안 모델. 기본 private + 필요한 것만 public.

[Container] OCI Image: spec, manifest, layer 표준

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

OCI (Open Container Initiative) = 컨테이너 표준 (Linux Foundation, 2015). image format + runtime + distribution 3가지 spec.

3개 OCI Spec

Spec	의미
Image	tarball + JSON metadata 구조
Runtime	`runc` 같은 컨테이너 실행 표준
Distribution	`docker push/pull` 같은 레지스트리 API

Image 구조

manifest.json
  - config.json (image config)
  - layers
    - layer0.tar.gz
    - layer1.tar.gz
    - layer2.tar.gz

flowchart TB
    Idx["Image Index (멀티 아키)"]
    Idx --> Mfst_amd64[Manifest amd64]
    Idx --> Mfst_arm64[Manifest arm64]
    Mfst_amd64 --> Cfg_a[Config JSON]
    Mfst_amd64 --> L1_a[Layer tarball 1]
    Mfst_amd64 --> L2_a[Layer tarball 2]

Image Index (멀티 아키)

{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:abc...",
      "platform": { "os": "linux", "architecture": "amd64" }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:def...",
      "platform": { "os": "linux", "architecture": "arm64" }
    }
  ]
}

한 tag (nginx:1.27) 으로 여러 아키 자동 선택. pull 시 클라이언트 아키 매칭.

Manifest

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:abc..."
  },
  "layers": [
    { "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:111..." },
    { "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:222..." }
  ]
}

Image vs OCI Artifact

flowchart LR
    OCI[OCI Distribution] --> Image["OCI Image (전통 컨테이너)"]
    OCI --> Artifact["OCI Artifact (임의 데이터)"]
    Artifact --> Helm[Helm chart]
    Artifact --> WASM[WebAssembly]
    Artifact --> SBOM[SBOM]
    Artifact --> Sig[Cosign signature]

OCI registry 가 컨테이너 image 만이 아닌 일반 artifact store 로 진화. Helm chart, WASM, SBOM, signature 모두.

구현체

	의미
`runc`	OCI Runtime 의 표준 구현
`containerd`	container 라이프사이클 (Docker / K8s 가 사용)
`CRI-O`	K8s 전용 OCI runtime
`podman`	Docker 호환, daemonless
`buildah`	image build 전용
`skopeo`	image 복사 / 검사

Content-Addressed Storage

image digest = sha256(manifest JSON)
layer digest = sha256(layer tarball)

tag 는 변할 수 있지만 digest 는 불변. 프로덕션 배포 는 항상 digest 로:

nginx:1.27                            ← tag (mutable)
nginx@sha256:abc123...                ← digest (immutable)

흔한 함정

[!WARNING]

Tag mutability = 어제 build 한 image 가 오늘 다른 내용. digest pinning.

Image scan 누락 = 취약점 image. Trivy / Grype / Clair.

Cross-arch test 안 함 = AMD64 만 build → ARM 노드 실패.

Layer 너무 많음 = layer 한도 (보통 127). 가능하면 묶기.

[IaC] AWS CDK: TypeScript 로 CloudFormation 생성

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

AWS CDK = TS/Python/Java/Go 로 AWS 인프라 정의 → CloudFormation 으로 컴파일 → 배포. AWS 전용.

흐름

flowchart LR
    Code["TypeScript (CDK)"] --> Synth["cdk synth<br/>(CFN template 생성)"]
    Synth --> Deploy["cdk deploy<br/>(CloudFormation)"]
    Deploy --> CFN[CloudFormation Stack]
    CFN --> AWS[AWS Resources]

예시





export class MyStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const bucket = new Bucket(this, 'Data', {
      versioned: true,
      encryption: BucketEncryption.KMS_MANAGED,
      removalPolicy: RemovalPolicy.RETAIN,
    });

    const fn = new Function(this, 'Processor', {
      runtime: Runtime.NODEJS_22_X,
      handler: 'index.handler',
      code: Code.fromAsset('lambda'),
    });

    bucket.grantReadWrite(fn);   // ← IAM 자동 생성!
  }
}

bucket.grantReadWrite(fn) 한 줄 = bucket policy + IAM role + 권한 → 자동 생성. 가장 강력한 추상화.

Construct Level (L1, L2, L3)

Level	의미
L1 (Cfn)*	CloudFormation 그대로 (`CfnBucket`)
L2	추상화 (`Bucket`, `Function`)
L3 (Patterns)	합성 (`LoadBalancedFargateService`)

// L3 example: ALB + Fargate 한 줄
new ApplicationLoadBalancedFargateService(this, 'Service', {
  cluster,
  taskImageOptions: {
    image: ContainerImage.fromRegistry('nginx'),
  },
  desiredCount: 3,
});

CDK 명령

cdk init app --language=typescript
cdk synth                    # CFN template 생성
cdk diff                     # 현 stack vs 예정 변경
cdk deploy MyStack
cdk destroy MyStack
cdk bootstrap                # CDK 의 metadata bucket 생성 (account 당 1회)

CDK vs Terraform vs Pulumi

항목	CDK	Terraform	Pulumi
언어	TS/Python/Java/Go	HCL	TS/Python/Go
Multi-cloud	AWS only	예	예
State	CFN (managed)	별도 backend	별도 backend
추상화	L1/L2/L3	provider	코드
학습 곡선	AWS 잘 알면 쉬움	HCL 학습	코드 자유
AWS 통합	최고	예	예

CDK for Terraform (cdktf)


new S3Bucket(this, 'data', {
  bucket: 'myapp-data',
  ...
});

코드 (TS/Python) + Terraform backend. CDK 의 언어 + Terraform 의 multi-cloud.

흔한 함정

[!WARNING]

cdk bootstrap 한 번 필요 = account+region 당. CI/CD 에서 잊음.

CFN limit = stack 당 500 resource. Nested stack 으로.

CDK Asset 의 S3 누적 = bootstrap bucket 비용. 정기 정리.

Snapshot 테스트 (jest) = 큰 stack 의 변경 추적. CI 에 필수.

[IaC] Pulumi: 코드로 인프라 (TS/Python/Go)

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Pulumi = 일반 프로그래밍 언어로 IaC. TypeScript, Python, Go, .NET, Java. Terraform 의 HCL DSL 대신 코드 자유도.

TS 예시



const config = new pulumi.Config();
const env = pulumi.getStack();

const bucket = new aws.s3.Bucket("data", {
  bucket: `myapp-data-${env}`,
  tags: { Environment: env, ManagedBy: "pulumi" },
});

new aws.s3.BucketVersioningV2("data-version", {
  bucket: bucket.id,
  versioningConfiguration: { status: "Enabled" },
});

export const bucketName = bucket.id;

흐름

flowchart LR
    Code[index.ts] --> Preview[pulumi preview<br/>diff]
    Preview --> Up[pulumi up<br/>실제 변경]
    Up --> State[(stack state<br/>backend)]

명령

pulumi new aws-typescript    # 새 프로젝트
pulumi stack init dev        # 새 stack (Terraform workspace 비슷)
pulumi config set region us-east-1
pulumi config set --secret db-password xxx
pulumi preview               # diff
pulumi up                    # apply
pulumi destroy
pulumi stack output bucketName
pulumi import aws:s3/bucket:Bucket data my-legacy-bucket

Backend (state)

Backend	의미
Pulumi Cloud	managed (기본, free tier)
AWS S3	self-host
Azure Blob / GCS	self-host
Local file	개발

pulumi login s3://my-pulumi-state
pulumi login --local

차이: HCL vs 코드

// Pulumi: 조건/반복은 코드 그대로
const instances = ["alice", "bob", "charlie"].map((name) =>
  new aws.iam.User(name, { name })
);

// 의존성 자동
const role = new aws.iam.Role("app", { ... });
new aws.iam.RolePolicyAttachment("attach", {
  role: role.name,    // pulumi.Output<string>, 의존성 자동
  policyArn: policy.arn,
});

Pulumi vs Terraform

항목	Pulumi	Terraform
언어	TS/Python/Go/.NET/Java	HCL
표현력	높음 (코드 자유)	DSL 한정
학습 곡선	일반 코드 알면 쉬움	HCL 학습
테스트	unit test 가능	tflint, terratest 등 별도
생태계	작음	가장 큼
가격	Cloud paid (free tier)	OSS / OpenTofu
멀티 클라우드	예	예

Automation API


const stack = await automation.LocalWorkspace.createOrSelectStack({
  stackName: "prod",
  projectName: "myapp",
  program: async () => {
    new aws.s3.Bucket("data", { ... });
  },
});

await stack.up({ onOutput: console.log });

Terraform 의 CLI 의존성 없이 Pulumi 를 프로그램 안에서 호출. self-service portal 같은 내부 도구 에 강력.

흔한 함정

[!WARNING]

pulumi.Output 처리 미숙 = .apply(), interpolate 사용. promise/await 와 다름.

Secret 코드에 평문 = pulumi config set --secret.

Stack 간 reference = StackReference 로 cross-stack output 읽기.

변수 vs config = config 가 stack 별. 변수는 코드.

[IaC] Terraform State: backend, locking, drift, import

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Terraform State = 코드 ↔ 실제 인프라 매핑. JSON 파일. 모든 Terraform 작업의 핵심.

State 가 하는 일

flowchart LR
    Code["main.tf<br/>(의도)"] --> Plan
    State["terraform.tfstate<br/>(알려진 실제)"] --> Plan
    Real["AWS 실제"] --> Refresh
    Refresh --> State
    Plan --> Diff[Diff]
    Diff --> Apply[apply]
    Apply --> Real
    Apply --> State

역할	의미
Mapping	resource 이름 ↔ AWS ARN
Metadata	dependency, version
Performance	refresh 캐시
Sensitive	output value 보관 (평문)

Backend 종류

flowchart TB
    B[Backend]
    B --> Local[local file<br/>team 금지]
    B --> S3[S3 + DynamoDB lock]
    B --> TFC[Terraform Cloud / HCP]
    B --> GCS[GCS]
    B --> Azure[Azure Blob]
    B --> Consul[Consul]

S3 + DynamoDB (AWS 표준)

terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/web/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    kms_key_id     = "arn:aws:kms:..."
    dynamodb_table = "tf-lock"
  }
}

컴포넌트	역할
S3 bucket	state 저장 + versioning
KMS	암호화
DynamoDB	distributed lock

State Locking

sequenceDiagram
    Dev1->>Lock: acquire (DynamoDB CAS)
    Lock-->>Dev1: OK
    Dev1->>State: write
    Dev2->>Lock: acquire
    Lock-->>Dev2: 이미 잠겨있음
    Dev1->>Lock: release
    Dev2->>Lock: acquire
    Lock-->>Dev2: OK

동시 apply 충돌 방지. DynamoDB 의 conditional write.

Drift Detection

flowchart LR
    State["state"] --> Compare
    Real["AWS 실제"] --> Refresh --> Compare
    Compare --> Drift{차이?}
    Drift -->|있음| Refresh[수동 사람이 AWS 직접 수정한 경우]

terraform plan -refresh-only
# 코드 변경 없이 실제 vs state 차이만 확인

prod 의 수동 변경 감지. 정기 drift check.

State 조작 명령

terraform state list                          # 모든 리소스
terraform state show aws_s3_bucket.data       # 단일 정보
terraform state mv old.name new.name          # rename
terraform state rm aws_s3_bucket.old          # state 에서만 제거 (AWS 안 지움)
terraform state pull > out.tfstate            # download
terraform state push out.tfstate              # upload (위험!)

terraform import aws_instance.web i-1234abcd  # 기존 리소스 등록

Import (기존 리소스 등록)

import {
  to = aws_s3_bucket.legacy
  id = "my-legacy-bucket"
}

resource "aws_s3_bucket" "legacy" {
  bucket = "my-legacy-bucket"
}

terraform plan -generate-config-out=generated.tf

옛 리소스를 Terraform 관리로 옮길 때.

Workspace (환경 분리)

terraform workspace new prod
terraform workspace new staging
terraform workspace select prod

locals {
  env = terraform.workspace   # "prod" / "staging"
}

한 backend 의 여러 state. 단 separate backend 가 더 안전.

State 의 위험

[!WARNING]

State 의 secret 평문 = terraform output 의 password 등 그대로. 접근 제한 + KMS.

수동 state 편집 = 망가짐. 반드시 명령으로.

State 손실 = 추적 불가. S3 versioning + 정기 백업.

여러 사람 동시 apply = lock 없으면 state 깨짐. DynamoDB lock 필수.

[IaC] Terraform: HCL, provider, state

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Terraform = 선언적 인프라 코드. HCL (HashiCorp Configuration Language) 로 리소스 정의 → AWS/GCP/Azure 등 provider 가 실제 생성.

[!NOTE] 2024 라이센스 변경 (BSL) 으로 OpenTofu fork 등장. OSS 분기. 2026 시점 OpenTofu 도 안정적.

흐름

flowchart LR
    Code[main.tf] --> Init[terraform init<br/>provider download]
    Init --> Plan[terraform plan<br/>diff 표시]
    Plan --> Review[Review by team]
    Review --> Apply[terraform apply<br/>실제 변경]
    Apply --> State[(terraform.tfstate)]

HCL 예시

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-lock"
    encrypt        = true
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  type    = string
  default = "us-east-1"
}

resource "aws_s3_bucket" "data" {
  bucket = "myapp-data-${terraform.workspace}"
  
  tags = {
    Environment = terraform.workspace
    ManagedBy   = "terraform"
  }
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration { status = "Enabled" }
}

output "bucket_name" {
  value = aws_s3_bucket.data.id
}

핵심 명령

terraform init       # provider + module download
terraform fmt        # 코드 포맷
terraform validate   # 문법
terraform plan       # diff (실행 X)
terraform apply      # 실제 변경
terraform destroy    # 모두 삭제
terraform show       # state 출력
terraform state list # 리소스 목록
terraform import     # 기존 리소스 → state 등록
terraform workspace  # 환경 분리

State

flowchart LR
    Code["코드 (의도)"] --> Compare
    State["state (실제 알려진 상태)"] --> Compare
    Compare["diff 계산"] --> Plan

저장	적합
Local file	팀 작업 금지
S3 + DynamoDB lock	AWS 표준
Terraform Cloud / HCP	managed
GCS / Azure Blob	GCP / Azure

자세한 건 [[terraform-state]].

Module (재사용)

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"
  
  name = "prod-vpc"
  cidr = "10.0.0.0/16"
  azs  = ["us-east-1a", "us-east-1b", "us-east-1c"]
  ...
}

Terraform Registry (수천 모듈), 자체 모듈, Git 소스 가능.

Lifecycle Meta-arguments

resource "aws_instance" "web" {
  ...
  lifecycle {
    create_before_destroy = true   # 새 생성 후 옛 삭제
    prevent_destroy       = true   # apply -destroy 차단
    ignore_changes        = [tags] # 특정 필드 무시
  }
}

for_each / count

# count: 단순 N
resource "aws_instance" "web" {
  count = 3
  ami = "ami-..."
}

# for_each: 명시적 키 (변경 안전)
resource "aws_iam_user" "team" {
  for_each = toset(["alice", "bob", "charlie"])
  name     = each.key
}

Terraform vs Pulumi vs CDK

	Terraform	Pulumi	AWS CDK
언어	HCL	TS/Python/Go/.NET	TS/Python/Java
Multi-cloud	예	예	AWS only
학습 곡선	중간	높음 (코드 자유)	중간
생태계	가장 큼	성장	AWS 강

흔한 함정

[!WARNING]

State git commit = secret 노출. 원격 backend + 암호화.

apply 직전 plan 안 봄 = 의도하지 않은 destroy.

destroy 사고 (production) = prevent_destroy lifecycle + IAM 보호.

버전 미고정 = provider 새 버전 = 다른 결과. ~> 또는 lock file.

김신건의 로그 - 위키 / cloud

[AWS] API Gateway: REST/HTTP API 관리

정의

두 종류

REST API

HTTP API

통합 타입

인증

스로틀링

캐싱 (REST API)

함정

참고

[AWS] ALB vs NLB: L7 vs L4 로드 밸런서

정의

ALB (Application Load Balancer)

NLB (Network Load Balancer)

선택 트리

Target Group

Sticky Session

WAF 통합 (ALB 만)

ALB → Lambda

흔한 함정

관련 위키

[AWS] Auto Scaling: EC2 ASG, target tracking, predictive

정의

구조

Scaling Policy 4종

1. Target Tracking (권장)

2. Step Scaling

3. Scheduled

4. Predictive Scaling

Lifecycle

Lifecycle Hooks

Cooldown vs Warmup

ASG + Spot

EC2 Auto Scaling vs Application Auto Scaling

흔한 함정

관련 위키

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

정의

동작

Origin 종류

Cache Behavior

Cache Key

Signed URL / Signed Cookie

OAC (Origin Access Control)

Edge Compute

TLS / SNI

흔한 함정

관련 위키

[AWS] CloudWatch: 메트릭, 로그, 알람

정의

4가지 구성

Metrics

Embedded Metric Format (EMF)

Logs

Logs Insights (쿼리)

Subscription Filter

Alarms

Composite Alarm

Anomaly Detection

CloudWatch vs 3rd-party

흔한 함정

관련 위키

[AWS] EBS vs Instance Store: 영속 vs 임시 스토리지

정의

EBS Volume 종류

gp3 의 분리 가격

Snapshot

Instance Store

적합

부적합

비교 직관

Multi-Attach (io2 만)

흔한 함정

관련 위키

[AWS] EC2 Instance Types: family, generation, sizing

정의

Family

세대 + Modifier