김신건의 로그 - 위키 / cloud

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

koa (김신건) — Fri, 17 Jul 2026 00:00:00 GMT

정의

CloudWatch = AWS 의 모니터링 + 로그 + 알람 통합 서비스.
메트릭 수집, 로그 집계, 대시보드, 알람, 이상 감지를 하나의 서비스에서 제공.

사용 상황

상황	해결책
EC2 / Lambda CPU 급등 감지	Alarm + SNS 알림
서비스 응답 P99 추적	Custom Metric + Dashboard
에러 로그 실시간 분석	Logs Insights 쿼리
여러 alarm 동시 발생 노이즈	Composite Alarm 으로 통합
이상 패턴 자동 감지	Anomaly Detection
EC2 메모리 / 디스크 수집	CloudWatch Agent
ECS / EKS 컨테이너 모니터링	Container Insights
여러 메트릭 결합 계산	Metric Math

관측 가능성 3가지 축

flowchart TD
    App[서비스]
    App --> M["Metrics: 수치 시계열"]
    App --> L["Logs: 이벤트 기록"]
    App --> T["Traces: X-Ray SDK"]
    M --> CW[CloudWatch]
    L --> CW
    T --> XR["X-Ray"]
    CW --> D["Dashboard / Alarm"]
    XR --> D

Metrics + Logs 는 CloudWatch 가 담당, Traces 는 X-Ray (별도 서비스).
세 축이 모두 있어야 진단 가능한 시스템.

4가지 구성

flowchart LR
    CW[CloudWatch]
    CW --> M[Metrics]
    CW --> L[Logs]
    CW --> A[Alarms]
    CW --> D[Dashboards]
    CW --> SY["Synthetics (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 호출 없음. 대량 메트릭의 비용 절감.

Metric Math

여러 메트릭을 수식으로 결합, 새로운 파생 메트릭 계산.

Metrics:
  - Id: errors
    MetricStat:
      Metric: { MetricName: Errors, Namespace: MyApp }
      Stat: Sum
      Period: 60
  - Id: requests
    MetricStat:
      Metric: { MetricName: Requests, Namespace: MyApp }
      Stat: Sum
      Period: 60
  - Id: error_rate
    Expression: "errors / requests * 100"
    Label: "Error Rate"

수식 예시	용도
`errors / requests * 100`	에러율 계산
`SUM([m1, m2, m3])`	여러 서비스 합산
`ANOMALY_DETECTION_BAND(m1, 2)`	이상 감지 밴드
`FILL(m1, 0)`	누락 데이터 0 채움

CloudWatch Agent

EC2 / 온프레미스에서 OS 레벨 메트릭 수집.
기본 메트릭에 포함되지 않는 메모리, 디스크 사용률 을 수집하려면 필수.

{
  "metrics": {
    "namespace": "MyApp/EC2",
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"]
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/", "/data"]
      },
      "cpu": {
        "measurement": ["cpu_usage_idle", "cpu_usage_iowait"],
        "totalcpu": true
      }
    }
  }
}

SSM Parameter Store 에 설정 저장 → 전체 fleet 동기화 가능.

Container Insights

ECS / EKS 컨테이너 환경의 CPU, 메모리, 네트워크, Pod 상태 자동 수집.

지원 환경	메트릭 예시
ECS	TaskCPUUtilization, ServiceCount
EKS	pod_cpu_utilization, node_memory_utilization

# EKS 에 Container Insights 활성화
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability

컨테이너 레벨 성능 문제 진단. Auto Scaling 트리거로 활용 가능.

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 등 으로 세분.

비용 최적화

전략	효과
PutMetricData 대신 EMF	API 호출 비용 절감
Dimension cardinality 제한	메트릭 수 통제
Log retention 정책 설정	S3 export 후 삭제
High resolution 필요한 것만 선택	1초 해상도 비용 절감
Metric Math 활용	파생 메트릭 별도 저장 불필요

흔한 함정

[!WARNING]

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

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

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

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

EC2 메모리/디스크 미수집 = 기본 메트릭에 없음. CloudWatch Agent 필수.

Log Group 별도 retention = Log Group 마다 개별 설정해야 함. 전체 계정 기본값 없음.

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

koa (김신건) — Fri, 17 Jul 2026 00:00:00 GMT

정의

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

사용 상황

상황	Lambda 적합성
REST API (API Gateway + Lambda)	적합, 짧은 처리
S3 업로드 후 이미지 리사이즈	적합, 이벤트 처리
DynamoDB Streams 변경 감지	적합, poll 처리
SQS 메시지 소비	적합, 자동 스케일
웹소켓 상시 연결 유지	부적합, ECS 권장
15분 초과 ML 추론	부적합, ECS/Batch 권장
GPU 워크로드	부적합, EC2 권장

트리거 종류

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

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

함수 작성

// 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"]
    L --> I2["Instance 2"]
    L --> IN["Instance N"]
    Note["account quota: 1000 기본"]

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

Cold Start

sequenceDiagram
    participant Trigger
    participant Lambda
    Trigger->>Lambda: invoke
    Note over Lambda: container 없음
    Lambda->>Lambda: init 50-1000ms
    Lambda->>Lambda: handler 실행
    Lambda-->>Trigger: 응답
    Note over Lambda: 5분 idle 후 종료

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 도 비례 증가. 성능 결정의 단일 dial.

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

가격

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

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

Layers (공유 코드)

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

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

Lambda URLs

API Gateway 없이 Lambda 에 직접 HTTPS endpoint 부여.

# Lambda URL 생성
aws lambda create-function-url-config \
  --function-name my-function \
  --auth-type NONE

# 반환: https://<id>.lambda-url.<region>.on.aws/

항목	내용
Auth	NONE (공개) 또는 AWS_IAM
비용	API Gateway 보다 저렴
기능	단순 HTTP 만 지원
적합	웹훅, 간단한 API
부적합	복잡한 라우팅, 인증 미들웨어

Lambda @ Edge / CloudFront Functions

CloudFront 엣지 로케이션에서 실행 하는 Lambda.

	Lambda @ Edge	CloudFront Functions
실행 위치	Regional edge	450+ POP
런타임	Node.js, Python	JS (제한)
실행 시간	최대 30초	1ms
메모리	최대 10GB	2MB
용도	인증, 변환	단순 리다이렉트

// Lambda @ Edge: 요청 헤더에 인증 토큰 확인
exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const token = request.headers['authorization']?.[0]?.value;

  if (!token || !isValid(token)) {
    return { status: '401', body: 'Unauthorized' };
  }
  return request;
};

Lambda Extensions

Lambda lifecycle 에 훅 해서 실행되는 사이드카.

Extension Layer
├── Init Phase: extension 초기화
├── Invoke Phase: 함수와 병렬 실행
└── Shutdown Phase: 종료 전 처리 (flush logs 등)

용도	예시
로그 수집	Datadog, New Relic agent
시크릿 캐시	Secrets Manager 사전 fetch
코드 검사	RASP (보안 에이전트)

Lambda Powertools

AWS 공식 생산성 라이브러리 (Node.js / Python / Java).




const logger = new Logger({ serviceName: 'order-api' });
const tracer = new Tracer({ serviceName: 'order-api' });
const metrics = new Metrics({ namespace: 'MyApp' });

export const handler = async (event: APIGatewayEvent) => {
  logger.info('Processing order', { orderId: event.pathParameters?.id });
  metrics.addMetric('OrderProcessed', MetricUnit.Count, 1);
  // ...
};

기능	역할
Logger	구조화 JSON 로깅, correlation ID
Tracer	X-Ray 자동 계측
Metrics	EMF 기반 커스텀 메트릭
Idempotency	중복 실행 방지
Parameters	SSM / Secrets Manager 캐시

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 기본. 갑작스런 spike 시 throttling.

Lambda URL + NONE auth = 공개 endpoint. WAF 연결 또는 IAM 인증 필요.

임시 파일 /tmp 한도 = 512MB 기본 (최대 10GB). 큰 파일 처리 시 S3 사용.

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

koa (김신건) — Fri, 17 Jul 2026 00:00:00 GMT

정의

Step Functions = 서버리스 워크플로 오케스트레이션. Amazon States Language (ASL, JSON) 으로 상태 기계 정의.
각 단계의 재시도, 에러 처리, 분기, 병렬 실행을 코드 없이 선언적으로 구성.

사용 상황

상황	Step Functions 활용
주문 처리 (결제 → 재고 → 배송)	Task 체인 + Catch/Retry
인간 승인 후 진행	Wait for Callback
CSV 파일 행 병렬 처리	Distributed Map
마이크로서비스 Saga 패턴	Catch + 보상 Task
ML 파이프라인 (전처리 → 학습 → 배포)	Parallel + Task
주기적 배치	EventBridge Scheduler + SFN

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`	종료

Parallel State

여러 브랜치를 동시에 실행, 모두 완료되면 다음 단계 진행.

{
  "Type": "Parallel",
  "Branches": [
    {
      "StartAt": "SendEmailNotification",
      "States": {
        "SendEmailNotification": {
          "Type": "Task",
          "Resource": "arn:lambda:...:email",
          "End": true
        }
      }
    },
    {
      "StartAt": "UpdateAnalytics",
      "States": {
        "UpdateAnalytics": {
          "Type": "Task",
          "Resource": "arn:lambda:...:analytics",
          "End": true
        }
      }
    }
  ],
  "Next": "Done"
}

브랜치 중 하나라도 실패하면 전체 Parallel 실패. 각 브랜치에 Catch 권장.

Choice State

{
  "Type": "Choice",
  "Choices": [
    {
      "Variable": "$.orderAmount",
      "NumericGreaterThan": 1000,
      "Next": "PremiumProcessing"
    },
    {
      "Variable": "$.paymentMethod",
      "StringEquals": "CRYPTO",
      "Next": "CryptoGateway"
    }
  ],
  "Default": "StandardProcessing"
}

Choice 는 End: true 나 Retry 없음. 반드시 Default 설정 권장.

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.

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:getObject",
    "Parameters": {
      "Bucket": "my-bucket",
      "Key": "data/records.csv"
    }
  },
  "MaxConcurrency": 1000,
  "ToleratedFailurePercentage": 5
}

Wait for Callback

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

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

Saga 패턴 아키텍처

flowchart TD
    Start --> Order["주문 생성"]
    Order -->|성공| Payment["결제 처리"]
    Order -->|실패| End1["종료: 실패"]
    Payment -->|성공| Inventory["재고 예약"]
    Payment -->|실패| CancelOrder["주문 취소"]
    Inventory -->|성공| Ship["배송 처리"]
    Inventory -->|실패| RefundPay["결제 환불"]
    RefundPay --> CancelOrder
    Ship --> Done["완료"]

각 단계 실패 시 보상 트랜잭션 역순 실행. Step Functions 의 Catch 로 구현.
자세히는 [[saga-pattern]], [[outbox-pattern]].

모니터링

도구	용도
CloudWatch Logs	실행 이력, 상태 전환 로그
X-Ray	각 Task 의 latency / 오류 추적
CloudWatch Metrics	ExecutionsStarted, ExecutionsFailed 등

# SAM/CloudFormation 에서 로깅 활성화
StateMachine:
  Type: AWS::Serverless::StateMachine
  Properties:
    Logging:
      Level: ALL
      IncludeExecutionData: true
      Destinations:
        - CloudWatchLogsLogGroup:
            LogGroupArn: !GetAtt SFNLogGroup.Arn

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.

Choice 의 Default 없음 = 매칭 실패 시 runtime error.

Parallel 브랜치에서 외부 상태 변경 = 보상 트랜잭션 없으면 partial 업데이트 위험.

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

koa (김신건) — Thu, 16 Jul 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)	극저지연 (us)	중간
가격	LCU (요청 + 데이터)	LCU	시간 + GB

{}

사용 상황

상황	선택
HTTP/HTTPS 마이크로서비스 라우팅	ALB
path/host 기반 분기 (microservices)	ALB
WAF, Cognito OIDC 인증 앞단	ALB
Lambda 직접 호출	ALB
극저지연 TCP 트래픽 (게임, 금융)	NLB
static IP 필요 (방화벽 화이트리스트)	NLB
AWS PrivateLink 엔드포인트	NLB
수백만 동시 연결	NLB

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

Target group을 서비스별로 분리하면 ALB 하나로 멀티 서비스 라우팅 가능.

ALB Listener 규칙 우선순위

규칙은 1~50000 우선순위로 평가. 낮을수록 먼저.

# 규칙 추가 예시
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:...:listener/... \
  --priority 10 \
  --conditions '[{"Field":"path-pattern","Values":["/api/*"]}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"arn:..."}]'

조건 (Field)	예시
`path-pattern`	`/api/`, `/static/`
`host-header`	`api.example.com`
`http-header`	`X-Custom-Header: value`
`source-ip`	`10.0.0.0/8`
`query-string`	`env=canary`

HTTPS / TLS 설정

# HTTPS Listener 생성
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:...:certificate/... \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=arn:...

# HTTP → HTTPS redirect
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol HTTP --port 80 \
  --default-actions \
    Type=redirect,RedirectConfig='{Protocol=HTTPS,StatusCode=HTTP_301}'

[!TIP] SSL Policy 는 최소 ELBSecurityPolicy-TLS13-1-2-2021-06 권장. TLS 1.0/1.1 비활성.

Sticky Session

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

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

세션 sticky는 stateful 앱에서만. 가능하면 stateless 설계 권장.

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 만.

NLB + PrivateLink

NLB를 VPC Endpoint Service 로 노출. 다른 VPC/계정에서 프라이빗 접근.

flowchart LR
    ConsumerVPC["Consumer VPC"] -->|"VPC Endpoint"| PrivateLink["AWS PrivateLink"]
    PrivateLink --> NLB
    NLB --> ServiceVPC["Service VPC (Provider)"]

# Endpoint Service 생성 (NLB 기반)
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:...:loadbalancer/net/...

SaaS 서비스가 고객 VPC에 안전하게 서비스 제공 시 표준 패턴.

Cross-Zone Load Balancing

기본값:

ALB: 활성화
NLB: 비활성화 (AZ 내 균등 분산)

# NLB cross-zone 활성화
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

NLB cross-zone 활성화 시 AZ 간 데이터 전송 비용 발생.

Connection Draining (Deregistration Delay)

Target 제거 전 기존 연결을 안전하게 종료.

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes Key=deregistration_delay.timeout_seconds,Value=30

기본 300초. 빠른 배포 환경에서는 30-60초로 줄이기.

Access Log

# Access Log 활성화 (S3)
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes \
    Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=my-alb-logs \
    Key=access_logs.s3.prefix,Value=alb

로그 필드: time, elb, client:port, target:port, request, target_status_code, user_agent.

Athena로 분석:

SELECT client_ip, request_url, target_status_code, COUNT(*) as cnt
FROM alb_logs
WHERE time > '2026-07-16'
GROUP BY 1, 2, 3
ORDER BY cnt DESC
LIMIT 100;

CloudWatch 핵심 메트릭

메트릭	의미
`RequestCount`	총 요청 수
`TargetResponseTime`	백엔드 응답 시간
`HTTPCode_Target_5XX_Count`	백엔드 5xx 에러
`HTTPCode_ELB_5XX_Count`	ALB 자체 5xx
`HealthyHostCount`	헬시 타겟 수
`UnHealthyHostCount`	비헬시 타겟 수

UnHealthyHostCount > 0 알림 필수. 배포 중 타겟이 줄어들면 즉각 탐지.

흔한 함정

[!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 권장 (가격 약간 더).

ALB 규칙 한도 = Listener당 규칙 100개 제한. path 패턴 조합 주의.

Health Check 경로 인증 = /health 에 인증 걸면 ALB가 401 받아 unhealthy 판정. 인증 제외.

NLB 의 Source IP 보존 = NLB는 기본적으로 클라이언트 IP 보존. ALB는 X-Forwarded-For 헤더.

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

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

정의

CloudFront = AWS 의 글로벌 CDN. 전세계 ~600 PoP (Points of Presence) 에서 사용자에게 가까운 edge 로 콘텐츠 제공. 지연 감소 + origin 부하 감소.

동작 흐름

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

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

Origin 종류

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

Cache Behavior

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

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

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

Cache Key 설계

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

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

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

OAC (Origin Access Control)

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

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

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

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

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

# Boto3 Python
from botocore.signers import CloudFrontSigner
import rsa

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

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

Signed URL vs Signed Cookie:

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

Edge Compute

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

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

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

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

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

TLS / 인증서

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

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

캐시 무효화 (Invalidation)

배포 후 캐시 즉시 갱신.

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

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

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

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

비용 구조

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

비용 최적화:

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

CloudFront + WAF 조합

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

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

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

흔한 함정

[!WARNING]

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

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

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

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

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

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

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

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

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

정의

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

사용 상황

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

인스턴스 타입 명명

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

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

Graviton (ARM) vs Intel/AMD

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

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

Purchase Options

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

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

Spot Instance

sequenceDiagram
    participant User
    participant AWS

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

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

AMI (Amazon Machine Image)

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

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

User Data (부팅 스크립트)

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

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

Instance Metadata Service (IMDS)

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

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

EBS Volume 타입

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

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

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

Security Group

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

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

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

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

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

Systems Manager Session Manager

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

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

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

필요 IAM 권한:

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

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

Placement Groups

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

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

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

CloudWatch 모니터링

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

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

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

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

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

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

Auto Recovery

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

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

흔한 함정

[!WARNING]

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

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

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

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

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

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

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

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

[AWS] EKS: managed Kubernetes

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

정의

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

control plane (etcd, API server, scheduler, controller manager) 을 AWS 가 완전 관리. 업그레이드, HA, 패치 포함. 사용자는 worker node 와 workload 만 책임.

아키텍처

flowchart TB
    User["kubectl / CI-CD"] --> CP["EKS Control Plane\n(AWS managed, Multi-AZ)"]
    CP --> NG["Managed Node Group\n(EC2 Auto Scaling)"]
    CP --> SN["Self-managed Nodes\n(EC2 직접)"]
    CP --> FG["Fargate Profile\n(serverless)"]
    NG --> Pods1[Pods]
    SN --> Pods2[Pods]
    FG --> Pods3[Pods]
    CP --> Addons["EKS Add-ons\n(CNI, CoreDNS, CSI)"]

Worker 3가지

종류	의미	관리 주체
Managed Node Group	EC2, AWS 가 자동 관리 + Auto Scaling	AWS
Self-managed Nodes	EC2, 사용자 직접 ami/lifecycle 관리	사용자
Fargate	노드 없음, 서버리스, pod 단위 과금	AWS

Karpenter = managed node group 의 진화. 더 빠른 scaling (초 단위) + spot 자동 활용 + 노드 통합(consolidation).

IAM Roles for Service Accounts (IRSA)

Pod 별 IAM 권한 부여의 표준. node IAM role 을 공유하지 않고 SA 단위로 분리.

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

sequenceDiagram
    participant Pod
    participant OIDC as "EKS OIDC Provider"
    participant STS as "AWS STS"
    participant S3

    Pod->>OIDC: JWT token (ServiceAccount)
    OIDC-->>Pod: signed token
    Pod->>STS: AssumeRoleWithWebIdentity(token)
    STS-->>Pod: temporary credentials
    Pod->>S3: API call (credentals)

OIDC provider 를 EKS cluster 에 연결 (cluster 당 1회)
SA 에 annotate 된 role 을 STS 로 assume
pod 내 SDK 가 자동으로 credentials 갱신

[!IMPORTANT] IRSA 가 2026 현재 표준. 옛 node IAM role 공유 방식은 node 위 모든 pod 가 동일 권한 = 최소 권한 원칙 위반.

EKS Pod Identity (2023+)

IRSA 의 간소화 버전. OIDC provider 설정 없이도 동작. EKS Pod Identity Agent add-on 필요.

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

항목	IRSA	Pod Identity
OIDC provider 필요	예	아니오
설정 복잡도	중간	낮음
교차 계정	가능	가능
add-on 필요	아니오	예 (agent)

EKS Add-ons

AWS 가 관리하는 권장 add-on. EKS 콘솔 / API 로 버전 관리.

Add-on	역할
VPC CNI	Pod IP 할당 (AWS VPC native)
CoreDNS	클러스터 내부 DNS
kube-proxy	서비스 네트워크 규칙
EBS CSI driver	Persistent Volume (EBS)
EFS CSI driver	공유 스토리지 (EFS)
AWS Load Balancer Controller	ALB/NLB 자동 프로비저닝
ADOT	OpenTelemetry 수집
GuardDuty Agent	컨테이너 위협 탐지
Karpenter	노드 자동 프로비저닝

VPC CNI 와 IP 관리

EKS 기본 CNI = AWS VPC CNI. Pod 가 VPC IP 를 직접 할당.

장점: VPC 내 native. SG, NetworkPolicy, VPC flow logs 그대로 적용. AWS LB 통합 자연스러움.

단점: IP 소모가 큼. EC2 instance type 별 ENI / IP 한도 존재.

c5.large = 최대 3 ENI × 10 IP = 30 Pod 한도
m5.4xlarge = 8 ENI × 30 IP = 240 Pod 한도

해결책:

secondary CIDR 추가 (100.64.0.0/16 등)
prefix delegation 활성 (ENI 당 /28 블록 할당, Pod 한도 대폭 확대)
대안 CNI: Cilium (eBPF, overlay), Calico

비용

항목	요금
Control Plane	$0.10/시간/cluster (~$73/월)
Managed Node Group	EC2 온디맨드 / 스팟 가격
Fargate	vCPU $0.04048/시간 + 메모리 $0.004445/GB/시간
EKS Anywhere	별도 라이선스

비용 최적화:

Karpenter + Spot instance 조합으로 node 비용 60-80% 절감 가능
Fargate 는 소규모 intermittent workload 에 적합, 상시 고밀도 워크로드는 EC2 가 저렴
미사용 cluster 는 node group 을 0으로 (control plane 비용은 유지)

EKS Anywhere

온프레미스에서 동일 EKS API 로 K8s 운영. AWS Outposts 와는 별개.

VMware vSphere, bare metal, Nutanix 등 지원
EKS Anywhere 라이선스 + 지원 비용
GitOps 기반 클러스터 관리 (Flux)

EKS vs ECS 선택

자세한 내용은 [[aws-ecs-fargate]] 참조.

flowchart TD
    Q{"워크로드 성격"}
    Q -->|"AWS 전용, 빠른 시작, 단순 컨테이너"| ECS["ECS\n(운영 오버헤드 낮음)"]
    Q -->|"K8s 생태계, 이식성, 복잡한 마이크로서비스"| EKS["EKS\n(표준 K8s API)"]
    EKS --> Fargate["Fargate 모드\n(노드 관리 불필요)"]
    EKS --> EC2["EC2 노드\n(제어권 최대)"]

업그레이드 전략

EKS 버전은 3개 마이너 버전 지원. 평균 4개월마다 신버전 출시.

Control plane 먼저 업그레이드 (마이너 버전 1씩, n+1 만 허용)
Add-on 업그레이드 (버전 호환성 확인)
Node group 순차 업그레이드 (롤링)

flowchart LR
    CP["Control Plane\n1.29 → 1.30"] --> Addons["Add-ons 업그레이드\n(CNI, CoreDNS, kube-proxy)"]
    Addons --> NG["Node Group\n1.29 → 1.30\n(롤링 교체)"]
    NG --> Done["완료"]

[!WARNING] control plane 과 node 버전 차이 최대 2 minor. node 가 너무 뒤처지면 업그레이드 불가.

모니터링 / 관찰성

CloudWatch Container Insights = EKS 메트릭 + 로그 통합
  - pod CPU/메모리 사용률
  - node 수준 지표
  - 네임스페이스 집계

Prometheus + Grafana = 커스텀 메트릭
  - kube-state-metrics (deployment replicas, pod phase)
  - node-exporter (node 시스템 지표)

AWS Distro for OpenTelemetry (ADOT)
  - traces → X-Ray / Jaeger
  - metrics → CloudWatch / Prometheus

로그 수집 전략:

Fargate: AWS for FluentBit 사이드카 자동 (CloudWatch Logs)
EC2 node: DaemonSet (FluentBit, Fluentd) 또는 ADOT

Karpenter 핵심 개념

Karpenter = node 자동 프로비저닝. managed node group 보다 훨씬 빠른 스케일링.

# NodePool 예시
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

장점:

수초 내 노드 프로비저닝 (managed group 의 3-5분 대비)
spot 자동 활용 + on-demand fallback
미사용 노드 자동 통합 (consolidation) 으로 비용 절감

흔한 함정

[!WARNING]

VPC IP 고갈: pod 수 × ENI 한도. secondary CIDR 또는 prefix delegation 사전 적용.

EKS 버전 업그레이드 순서: control plane → add-on → node 순. minor 한 번씩만.

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

Fargate + DaemonSet 미지원: log/metric 수집을 sidecar 컨테이너로 각 pod 에 붙여야 함.

IRSA OIDC provider: cluster 당 1회 생성. 누락 시 AssumeRoleWithWebIdentity 실패.

[!CAUTION] aws-auth ConfigMap 잘못 수정 시 cluster 접근 완전 차단. IAM Identity Center 또는 EKS access entries 로 대체 권장.

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

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

정의

EventBridge = AWS 의 통합 event bus. 옛 CloudWatch Events 의 후계. AWS service 이벤트 + custom 이벤트 + SaaS 이벤트 를 한 곳에서 라우팅하는 서버리스 이벤트 플랫폼.

사용 상황

상황	EventBridge 선택 이유
마이크로서비스 간 느슨한 결합	source 가 target 을 몰라도 됨, 독립 배포
SaaS 이벤트 수신	Partner Sources (Datadog, MongoDB, Auth0, …)
배치 스케줄링	Scheduler 로 cron / rate / one-time
Cross-account 이벤트 전파	조직 전체 bus 설정 가능
AWS 서비스 이벤트 반응	EC2 상태 변경, S3 업로드, CodePipeline 알림
ETL 파이프라인	Pipes 로 source → filter → enrich → target

SNS + SQS 가 메시지 큐 / fan-out 에 특화 라면, EventBridge 는 이벤트 라우팅 플랫폼. 복잡한 content-based filtering 과 SaaS 통합이 강점.

Event Bus 종류

종류	의미
Default	AWS service 이벤트 (EC2, S3, CodePipeline 등)
Custom	자체 이벤트 (`PutEvents` API 로 전송)
Partner	SaaS (Datadog, MongoDB, Auth0, Zendesk, …)

Custom bus 는 계정당 100개 생성 가능. 이름, region, account 로 식별.

Event 형식

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

source: 이벤트 출처 (역 DNS 권장, myapp.orders).
detail-type: 이벤트 종류. detail: 자유 형식 payload.
최대 256KB. 초과 시 S3 에 payload 를 올리고 URL 만 이벤트에.

Event Pattern 심화

Rule 이 어떤 이벤트를 처리할지 결정하는 JSON 필터. Pattern 이 이벤트의 상위 집합 이면 매칭.

{
  "source": ["myapp.orders"],
  "detail-type": ["Order Created"],
  "detail": {
    "total": [{ "numeric": [">=", 10000] }],
    "status": [{ "anything-but": ["CANCELLED", "REFUNDED"] }],
    "region": [{ "prefix": "us-" }],
    "tag": [{ "exists": false }]
  }
}

Operator	의미
`prefix`	특정 문자열로 시작
`suffix`	특정 문자열로 끝
`anything-but`	제외 목록
`numeric`	숫자 비교 (`>`, `>=`, `<`, `<=`, `=`)
`exists`	필드 존재 여부 (true / false)
`equals-ignore-case`	대소문자 무시
`cidr`	IP 대역 매칭
`or`	여러 조건 중 하나

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]

하나의 Bus 에 여러 Rule.
하나의 Rule 에 최대 5개 Target.
Target 마다 Input Transformer 로 payload 변환 가능.

Input Transformer

Rule 의 Target 으로 보내기 전에 이벤트 payload 를 변환.

{
  "InputPathsMap": {
    "order": "$.detail.order_id",
    "total": "$.detail.total"
  },
  "InputTemplate": "\"Order <order> 금액 <total>원 생성됨\""
}

JMESPath 로 필드 추출 후 template 에 삽입. Lambda 호출 없이 payload 를 단순화.

Target 종류

Lambda (동기 / 비동기 선택 가능)
SQS / SNS
Step Functions
ECS Task / EKS / Batch
Kinesis Data Streams / Firehose
API Destination (외부 HTTP 엔드포인트)
다른 EventBridge Bus / 다른 계정의 Bus
CodePipeline, CodeBuild, SSM Run Command

Retry + Dead Letter Queue

Target 호출 실패 시 EventBridge 가 자동 재시도.

항목	기본값
최대 재시도 기간	24시간
최대 재시도 횟수	185회
재시도 알고리즘	exponential back-off
DLQ 지원	SQS Dead Letter Queue

Target:
  Arn: arn:aws:lambda:us-east-1:123:function:my-func
  DeadLetterConfig:
    Arn: arn:aws:sqs:us-east-1:123:my-dlq
  RetryPolicy:
    MaximumRetryAttempts: 3
    MaximumEventAgeInSeconds: 3600

[!IMPORTANT] DLQ 는 운영 필수. 실패 이벤트를 DLQ 로 보내고 [[aws-cloudwatch]] Alarm 연동. FailedInvocations 지표를 모니터링.

EventBridge Scheduler (2022+)

CloudWatch Events Schedule 의 후계. 훨씬 정교하고 수백만 스케줄 지원.

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

방식	예시
cron	`cron(0 9 * * ? *)`
rate	`rate(5 minutes)`
one-time	`at(2026-12-25T00:00:00)`

Flexible Time Window: FLEXIBLE 로 지정된 분 범위 안에서 실행 분산 (부하 burst 방지). EventBridge Rule 의 Schedule 과 달리 UTC 외 timezone 지원, 하나의 Target 에 직접 IAM Role 부여 가 가능.

Schema Registry

이벤트 계약을 중앙에서 관리.

이벤트 schema 중앙 보관.
다국어 코드 생성 (Java, Python, TypeScript).
contract 변경 추적 (자동 versioning).
AWS service 이벤트 schema 는 자동 등록 (Schema Discovery 활성화 시).

Schemas:
  - Name: myapp.orders@OrderCreated
    Version: 2
    Content: |
      {
        "$schema": "...",
        "properties": {
          "detail": {
            "properties": {
              "order_id": { "type": "string" },
              "total": { "type": "number" }
            }
          }
        }
      }

Pipes (2022+)

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

Pipe = source → filter → enrich → target 의 one-stop ETL 파이프라인. Rule 방식 대비:

Rule: bus → N targets 의 fan-out.
Pipe: 1:1 스트리밍 처리, polling source 에서 직접 읽기 (SQS, Kinesis, DDB Stream).

Enrichment 에서 Lambda 를 껴서 payload 변환 + 외부 조회.

Cross-account 이벤트 라우팅

flowchart LR
    AppA["App (Account A)"]
    BusA["Custom Bus A"]
    BusB["Event Bus B<br/>(Account B)"]
    Lambda["Lambda<br/>(Account B)"]
    AppA -->|PutEvents| BusA
    BusA -->|"Rule: forward"| BusB
    BusB --> Lambda

소스 계정 Bus: resource-based policy 에서 Account B 에게 events:PutEvents 허용.
Rule 설정: 소스 Bus 에 “대상 Bus 로 forward” Rule 추가.
대상 계정 Bus: 수신 후 자체 Rule 로 Lambda / SQS 등 트리거.
조직 전체: Default Bus 의 Organization policy 로 전체 계정 수신 허용.

이벤트 Archive + Replay

Archive:
  Name: order-events-archive
  EventSourceArn: arn:aws:events:...:event-bus/my-bus
  EventPattern: |
    { "source": ["myapp.orders"] }
  RetentionDays: 90

이벤트를 Archive 에 저장 후 재생 (Replay) 가능.
새 Rule 추가 후 과거 이벤트를 replay → consumer 검증.
장애 복구: 실패 시간대 이벤트만 선택 replay.

모니터링

지표 (namespace: AWS/Events)	의미
`FailedInvocations`	Target 호출 최종 실패 수
`DeadLetterInvocations`	DLQ 로 전송된 이벤트 수
`ThrottledRules`	Rule 평가 제한 횟수
`MatchedEvents`	Rule 에 매칭된 이벤트 수
`TriggeredRules`	Rule 트리거 횟수
`InvocationAttempts`	Target 호출 시도 총 수

aws cloudwatch get-metric-statistics \
  --namespace AWS/Events \
  --metric-name FailedInvocations \
  --dimensions Name=EventBusName,Value=my-bus \
  --start-time 2026-07-01T00:00:00Z \
  --end-time 2026-07-02T00:00:00Z \
  --period 3600 \
  --statistics Sum

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

항목	EventBridge	SNS	SQS
Filtering	content-based (복잡)	attribute-based (단순)	없음
Fan-out	Rule 당 5 Target	12.5M subscriber	1:1
SaaS 통합	✓ Partner Sources	✗	✗
Scheduler	✓	✗	✗
Event Replay	✓ Archive 설정 시	✗	✗
Schema Registry	✓	✗	✗
비용 기준	이벤트 수	이벤트 수	메시지 수
주요 용도	이벤트 라우팅	fan-out / pub-sub	작업 큐 / 버퍼링

흔한 함정

[!WARNING]

Rule pattern 의 잘못된 JSON = silently no match. MatchedEvents 0 이면 pattern 검토.

Cross-account 이벤트 = source bus 의 resource policy 와 target bus 의 PutEvents 권한 둘 다 필요.

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

Target retry 한도 = 24시간 재시도 후 드롭. DLQ 미설정 시 이벤트 유실.

Pipes Enrichment 오류 = 이벤트 드롭. Enrichment Lambda 는 idempotent 보장.

Scheduler timezone = 기본 UTC. schedule-expression-timezone 명시 필수.

Input Transformer template 오류 = 이벤트 전달 실패. 미리 콘솔에서 테스트.

256KB 초과 payload = 전송 실패. 대용량은 S3 URL + pointer 패턴.

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

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

정의

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

사용 상황

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

객체

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

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

Policy 구조

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

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

Policy 종류

종류	의미
AWS Managed	AWS 가 관리 (`AmazonS3ReadOnlyAccess`)
Customer Managed	사용자 정의, 재사용 가능
Inline	User/Group/Role 에 직접 임베드 (재사용 불가)
Permission Boundary	최대 권한 상한 (Role 이 가질 수 있는 최대)
Service Control Policy	Organization 수준 전체 상한
Resource-based Policy	자원에 붙음 (S3 Bucket Policy, Lambda Permission 등)
Session Policy	AssumeRole 시 임시로 줄이는 정책

권한 평가 알고리즘

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 가 모든 것을 이김. Organization SCP → Permission Boundary → Identity Policy 순으로 모두 통과해야 Allow.

Role 과 AssumeRole

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

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

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

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

ABAC: Attribute-Based Access Control

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

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

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

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

Condition Keys 상세

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

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

IRSA / Pod Identity (EKS)

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

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

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

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

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

Identity Center (옛 SSO)

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

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

Access Analyzer

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

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

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

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

Credential Report + Access Advisor

Credential Report (계정 전체)

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

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

IAM Access Advisor (사용자별)

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

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

Best Practice

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

흔한 함정

[!WARNING]

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

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

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

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

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

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

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

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

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

정의

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

사용 상황 (cold start 가 문제인 경우)

상황	영향	권장 완화
동기 API Gateway 요청	첫 요청 latency spike	Provisioned Concurrency
사용자 직접 호출 (실시간)	체감 느림	Provisioned Concurrency / SnapStart
배치 비동기 처리	일반적으로 무시 가능	불필요
SQS / EventBridge 트리거	큐 쌓임 정도만 영향	Bundle 최적화로 충분
Java 기반 함수	cold start 1000ms+	SnapStart 필수
VPC 내 Lambda	예전엔 +5-15초 (현재 거의 없음)	최신 Hyperplane 사용

Cold start 가 p99 수준에서 실제 사용자 경험에 미치는지 먼저 측정. 과도한 최적화 전에 데이터를 봐야 함.

단계

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	AWS
Runtime 부팅	~50ms	AWS
코드 load	~50ms (의존성 크기 비례)	AWS + 사용자
Init code 실행	사용자 책임	사용자

Execution Environment Lifecycle

flowchart LR
    Init["INIT phase<br/>(cold start 비용)"] --> Invoke1["INVOKE 1<br/>(handler 실행)"]
    Invoke1 --> Invoke2["INVOKE 2-N<br/>(warm 재사용)"]
    Invoke2 --> Shutdown["SHUTDOWN<br/>(idle timeout)"]

INIT: MicroVM 생성 + 런타임 부팅 + 사용자 init code 실행. 1회만.
INVOKE: 매 호출마다 handler 함수 실행. INIT 없음.
SHUTDOWN: idle 후 (보통 5-15분) 환경 회수. 다음 호출 = 새 INIT.
재사용: /tmp (512MB-10GB), 전역 변수, DB 연결 등 재사용 가능.

Runtime 별 cold start (직관)

완화 전략

1. Provisioned Concurrency

N 개 인스턴스를 항상 warm 상태로 유지. cold start 0.

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

10 인스턴스 항상 warm.
Cold start 완전 제거.
비용: idle 상태에서도 과금. API, 실시간 처리에 적합.

[!TIP] latency 예측 가능성이 필요한 API 에만. batch / async 는 불필요. Application Auto Scaling 으로 트래픽 패턴에 맞게 자동 조절 가능.

# Auto Scaling 연동
aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --resource-id function:my-func:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --min-capacity 2 \
  --max-capacity 50

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 깨짐).
AfterRestore hook 으로 snapshot 복원 후 초기화 재실행 가능.

@LambdaHook(hookType = AfterRestore.class)
public static void afterRestore(Context context) {
    // snapshot 복원 후 실행: DB 연결 재수립 등
    dbConnection = createNewConnection();
}

3. 코드 최적화

// ❌ handler 안에서: 매 호출마다 새 연결
export const handler = async (event) => {
  const db = new DBClient();
  const result = await db.query(...);
};

// ✅ handler 밖 (init 시 1회): 연결 재사용
const db = new DBClient();
export const handler = async (event) => {
  const result = await db.query(...);
};

DB 연결, HTTP 클라이언트, SDK 초기화 = handler 밖으로.
Lazy initialization: 실제 필요할 때까지 지연.
불필요한 import 제거.

4. Bundle 크기 줄이기

도구	효과
esbuild	tree-shake + minify, 가장 빠름
webpack	동일 효과, 설정 더 복잡
Layer 분리	큰 의존성 (AWS SDK 등) 을 Layer 로 분리
Lambda Container Image	ECR 레이어 캐싱 활용
`.zip` 압축 최적화	`node_modules` 필요 파일만 포함

목표: zip 10MB 이하, 가능하면 5MB 이하.

5. ARM64 (Graviton2)

aws lambda update-function-configuration \
  --function-name my-func \
  --architectures arm64

x86_64 대비 cold start 10-20% 개선.
비용 약 20% 절감.
대부분의 런타임 지원 (Node, Python, Java, Go, Ruby).
ARM 네이티브 바이너리 확인 필수 (native addon 있을 경우).

Warm 유지 anti-pattern

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

[!CAUTION] 옛 워크어라운드. 현재는 Provisioned Concurrency 가 정통. ping 방식의 문제:

동시 N 인스턴스 warm 보장 안 됨 (1개만 warm).

트래픽 급증 시 여전히 cold start 발생.

불필요한 비용 + 복잡도.

측정 + 모니터링

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

def handler(event, context):
    invoke_time = time.time()
    print(f"HANDLER t={invoke_time}, delta={invoke_time - INIT_TIME:.3f}s")

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

[[aws-cloudwatch]] 지표

지표	의미
`InitDuration`	cold start 소요 시간 (REPORT 로그)
`Duration`	handler 실행 시간
`ConcurrentExecutions`	동시 실행 수
`ProvisionedConcurrencyUtilization`	Provisioned 사용률
`Throttles`	제한된 요청 수

# X-Ray 활성화: init / handler 구간별 tracing
aws lambda update-function-configuration \
  --function-name my-func \
  --tracing-config Mode=Active

Lambda Power Tuning

AWS Lambda Power Tuning (오픈소스 Step Functions 워크플로우) 으로 메모리 vs 비용 vs 속도 최적화점 탐색.

# Step Functions 로 실행, 각 메모리 설정에서 N 회 테스트
{
  "lambdaARN": "arn:aws:lambda:...:my-func",
  "powerValues": [128, 256, 512, 1024, 2048, 3008],
  "num": 10,
  "payload": {},
  "parallelInvocation": true,
  "strategy": "cost"
}

메모리 증가 = vCPU 비율 증가 = 실행 시간 감소.
비용 최적 메모리 != 가장 저렴한 메모리. 빠른 실행이 총 비용 낮출 수 있음.

VPC Lambda 의 cold start (옛 vs 현재)

시점	Cold Start (VPC)	원인
~2019	5-15초	ENI 직접 생성
2019+ (Hyperplane)	~1초 추가	ENI 사전 생성 + 재사용
2024+ (Firecracker warm pool)	일반과 거의 동일	warm ENI pool

[!TIP] 현재는 VPC Lambda cold start 가 거의 문제 없음. 단, 서브넷 IP 고갈 은 여전히 주의.

Container Image vs ZIP

항목	ZIP	Container Image
최대 크기	50MB (압축) / 250MB (비압축)	10GB (ECR)
빌드 속도	빠름	느림 (Docker build)
Cold start	빠름	느릴 수 있음 (초기 pull)
Layer 재사용	Lambda Layer	Docker layer 캐싱
로컬 테스트	SAM / AWS CLI	Docker 로 완전 동일 환경
의존성 관리	번들러 필요	Dockerfile 로 단순

대규모 ML 모델이나 복잡한 네이티브 의존성: Container Image. 일반 서버리스 API: ZIP + esbuild.

흔한 함정

[!WARNING]

Cold start 측정 안 하고 최적화 = 실제 병목이 아닐 수 있음. 먼저 InitDuration 측정.

Provisioned Concurrency 과다 설정 = 불필요한 비용. 실제 동시 요청 수 기반으로 설정.

SnapStart 의 snapshot 내 UUID/시간 = 복원 후 중복. AfterRestore 훅에서 재생성.

Handler 밖 초기화 실패 = 함수 전체 장애. init code 는 방어적으로 작성.

ARM64 로 전환 후 native addon 오류 = sharp, bcrypt 등 아키텍처별 바이너리 재빌드 필요.

Bundle 크기 과다 = 코드 load 시간 증가. @aws-sdk/client-s3 만 import (전체 SDK 금지).

VPC Lambda 서브넷 IP 고갈 = ENI 생성 실패. /24 이상 서브넷 권장.

[AWS] RDS Multi-AZ + Read Replica

koa (김신건) — Thu, 16 Jul 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 x 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 없이)

VPC 내 배치

RDS 인스턴스는 항상 VPC Private Subnet 에 배치. 퍼블릭 서브넷 배치는 절대 금지.

DB Subnet Group: 2개 이상 AZ 의 Private Subnet 지정. Multi-AZ 사용 시 필수 조건.
Security Group: EC2 SG 에서 RDS SG 로만 인바운드 허용. IP 기반 아님.
Bastion Host / SSM: 직접 접속이 필요할 때 SSH Tunnel 또는 AWS SSM Session Manager 활용.

flowchart LR
    App["EC2 / Lambda<br/>(Private Subnet)"] -->|"3306 / 5432"| RDSProxy["RDS Proxy<br/>(Private Subnet)"]
    RDSProxy --> RDS["RDS Primary<br/>(Private Subnet, AZ-a)"]
    RDS -->|"sync"| Standby["Standby<br/>(Private Subnet, AZ-b)"]
    Bastion["Bastion / SSM<br/>(Public Subnet)"] -.->|"SSH Tunnel"| RDS

파라미터 그룹

RDS 인스턴스 파라미터 와 클러스터 파라미터 (Aurora) 가 분리됨.

파라미터	영향	재시작 필요
`max_connections`	동시 접속 수	아니오
`innodb_buffer_pool_size`	InnoDB 캐시 크기	예
`slow_query_log`	느린 쿼리 기록	아니오
`log_bin_trust_function_creators`	함수 생성 권한 완화	아니오
`character_set_server`	서버 기본 문자셋	예

[!IMPORTANT] Static 파라미터 변경은 인스턴스 재시작 이 필요. 프로덕션에서 갑작스럽게 적용되지 않도록 Maintenance Window 시간 확인.

모니터링 (CloudWatch)

지표	설명	권장 임계치
`CPUUtilization`	CPU 사용률	> 80% 지속 시 업사이즈 검토
`FreeStorageSpace`	남은 스토리지	< 20% 알람 설정
`DatabaseConnections`	현재 연결 수	max_connections 80% 경보
`ReplicaLag`	Read Replica 복제 지연	> 1s 시 read-your-writes 위험
`ReadIOPS` / `WriteIOPS`	IOPS	프로비저닝 IOPS 한도 대비 확인
`FreeableMemory`	여유 메모리	< 200MB 알람

Enhanced Monitoring: OS 레벨 (메모리, 프로세스) 지표 추가 (1-60초 간격). Performance Insights: 쿼리별 대기 분석, DB 부하 시각화 (7일 무료, 2년 유료).

업그레이드 전략

유형	방법	다운타임
Minor 버전	자동 또는 수동	수 초 (재시작)
Major 버전	Blue-Green 권장	Blue-Green = 수 초
Aurora Major	Blue-Green 또는 snapshot 복원	계획 다운타임 필요

Blue-Green 업그레이드 절차 (RDS 네이티브 지원):

Green = 신 버전 복제 클러스터 자동 생성
복제 완료 후 동기화 확인
Switchover: 트래픽 전환 (수 초)
검증 후 Blue 삭제

[!WARNING] Aurora Major 버전 업그레이드 (예: MySQL 5.7 -> 8.0) 는 호환성 확인 필수. 스토어드 프로시저, 뷰, 트리거의 deprecated 문법 검토 필요.

비용 최적화

항목	방법
인스턴스 사이즈	CloudWatch CPU/메모리 모니터링 후 rightsizing
Multi-AZ	Dev/Test 환경은 Single-AZ 로 50% 절감
Read Replica	리전 내 Reserved Instance 적용 가능
Aurora 스토리지	사용량 기반 과금 (max 설정 없음), 읽기 IOPS 별도 과금 주의
Backup 보존	자동 백업 보존 기간 최소화 (1-35일, 기본 7일)
Aurora Serverless v2	간헐적 워크로드에서 ACU 절감 (0.5 ACU 까지 스케일 다운)

흔한 함정

[!WARNING]

Multi-AZ != Read Replica: Multi-AZ 의 Standby 는 읽기 불가. Read Replica 는 별도.

Aurora major version upgrade: 다운타임 있음. 충분한 테스트 필요.

Read Replica lag: async 복제 특성상 read-your-writes 가 깨질 수 있음.

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

파라미터 그룹 수정 후 재시작 누락: Static 파라미터 변경이 반영 안 된 채로 운영 지속.

인스턴스 클래스 선택 가이드

Aurora 와 RDS 모두 인스턴스 클래스 가 성능을 결정.

클래스 계열	특징	적합한 워크로드
`db.t4g.*`	버스트 가능 (Graviton2)	Dev / Test, 낮은 기준 부하
`db.m7g.*`	범용 (Graviton3)	웹 애플리케이션
`db.r7g.*`	메모리 최적화	대용량 인메모리 캐시, Analytics
`db.x2g.*`	고메모리 (SAP HANA급)	초대형 인메모리 DB

[!IMPORTANT] t 클래스는 CPU 크레딧 소진 시 성능 저하. 프로덕션 지속 부하에는 m 또는 r 계열 사용.

Reserved Instance (1년/3년 약정) 사용 시 On-Demand 대비 최대 70% 절감. 안정적인 워크로드라면 RI 를 우선 검토.

접속 보안 베스트 프랙티스

항목	권장
암호화 (전송)	SSL/TLS 강제 (`require_secure_transport = ON`)
암호화 (저장)	RDS 생성 시 Encryption at rest 활성화 (KMS)
인증	IAM DB 인증 (MySQL/PG 지원, 패스워드 불필요)
Secrets	AWS Secrets Manager + 자동 rotation
네트워크	VPC Private Subnet + Security Group 최소 권한

-- IAM 인증 토큰으로 접속 (MySQL 예시)
-- 1. IAM 역할에 rds-db:connect 권한 부여
-- 2. 토큰 발급
MYSQL_PWD=$(aws rds generate-db-auth-token \
  --hostname mydb.xxx.us-east-1.rds.amazonaws.com \
  --port 3306 \
  --username iam_user)

-- 3. SSL + 토큰으로 접속
mysql -h mydb.xxx.us-east-1.rds.amazonaws.com \
  --ssl-ca=global-bundle.pem \
  -u iam_user \
  --password="$MYSQL_PWD"

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

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

정의

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

사용 상황

상황	S3 선택 이유
정적 자산 (이미지, JS, CSS)	[[aws-cloudfront-cdn]] 와 조합
로그 장기 보관	Lifecycle 로 Glacier 자동 이동
ML 학습 데이터 / 모델	S3 → SageMaker 직접 연동
백업 / DR	Cross-Region Replication
데이터 레이크	S3 + Athena + Glue
사용자 파일 업로드	Presigned URL 로 서버 우회
컴플라이언스 아카이빙	Object Lock WORM

Storage Class

Class	용도	비용	검색 latency
Standard	자주 접근	$0.023/GB	ms
Intelligent-Tiering	자동 자주/덜 자주 분류	varies	ms
Standard-IA	가끔 접근	더 cheap, retrieval fee	ms
One Zone-IA	단일 AZ + 가끔 접근	더 cheap	ms
Glacier Instant Retrieval	archive + 즉시 접근	매우 cheap	ms
Glacier Flexible Retrieval	archive	매우 cheap	분~시간
Glacier Deep Archive	장기 archive	가장 cheap	12+ 시간

Intelligent-Tiering 은 접근 패턴 예측 불가 시 최적. 30일 미접근 시 IA 로 자동 이동.

Lifecycle Policy

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

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

AbortIncompleteMultipartUploads 는 반드시 설정. 미완료 multipart 가 비용 누수.

Replication (CRR / SRR)

flowchart LR
    SrcBucket["Source Bucket<br/>(us-east-1)"] -->|CRR| DstBucket["Dest Bucket<br/>(ap-northeast-2)"]
    SrcBucket2["Source Bucket A"] -->|SRR| DstBucket2["Dest Bucket B<br/>(같은 region)"]

종류	의미
CRR (Cross-Region Replication)	다른 리전으로 복제 (DR, 지연 감소)
SRR (Same-Region Replication)	같은 리전 내 복제 (로그 집계, 테스트)

Source bucket: Versioning 활성화 필수.
신규 객체만 복제 (기존 객체는 S3 Batch Operations 으로 별도 복제).
Delete Marker: 기본 복제 안 됨 (설정 가능).
복제 시간 SLA: 기본 15분 이내. S3 Replication Time Control (RTC) = 99.99% 를 15분 이내 보장 (추가 비용).

Versioning

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

덮어쓰기 / 삭제 = 옛 버전 보존.
실수 복구 가능.
삭제 = Delete Marker 생성 (실제 삭제 아님).
비용: 모든 버전 저장. Lifecycle 로 오래된 버전 정리 필수.

Object Lock (WORM)

Mode: GOVERNANCE | COMPLIANCE
RetainUntilDate: "2027-06-25T00:00:00Z"

Write Once Read Many: 보존 기간 중 삭제/수정 불가.
GOVERNANCE: 특정 IAM 권한으로 삭제 가능.
COMPLIANCE: root user 도 삭제 불가. 금융/의료 컴플라이언스.
Legal Hold: 날짜 무관 삭제 차단.

Multipart Upload

sequenceDiagram
    Client->>S3: InitiateMultipartUpload (uploadId)
    par parallel parts
        Client->>S3: UploadPart 1
        Client->>S3: UploadPart 2
        Client->>S3: UploadPart N
    end
    Client->>S3: CompleteMultipartUpload (part etags)
    S3-->>Client: 완료

큰 파일 (100MB+) 권장, 5GB 초과 시 필수.
병렬 업로드 + 개별 파트 재시도 가능.
최소 파트 크기: 5MB (마지막 파트 제외).
미완료 Multipart: Lifecycle AbortIncompleteMultipartUploads 로 자동 정리.

Presigned URL

import boto3

s3 = boto3.client('s3')
url = s3.generate_presigned_url(
    'put_object',
    Params={'Bucket': 'my-bucket', 'Key': 'upload.zip'},
    ExpiresIn=3600   # 1시간
)

클라이언트가 S3 에 직접 업로드/다운로드 (서버 경유 없음).
임시 URL (만료 시간 설정).
서버 측에서 IAM 권한 위임.
GET (다운로드), PUT (업로드) 모두 지원.

Transfer Acceleration

# 엔드포인트: my-bucket.s3-accelerate.amazonaws.com
aws configure set default.s3.use_accelerate_endpoint true

CloudFront edge location 을 경유해 S3 에 전송.
글로벌 업로드 속도 최대 60% 향상 (지역별 편차 큼).
비용: 일반 전송 대비 추가 요금.
실제 개선 여부: S3 Transfer Acceleration Speed Comparison Tool 로 사전 확인.

S3 Access Points

버킷 하나를 여러 팀이 다른 정책으로 접근할 때.

aws s3control create-access-point \
  --name data-science-ap \
  --account-id 123456789 \
  --bucket my-data-lake \
  --vpc-configuration VpcId=vpc-abc

각 Access Point 는 고유한 ARN + endpoint + Policy.
VPC-only 접근 강제 가능.
버킷 Policy 가 복잡해지는 것을 Access Point Policy 로 분리.

Static Website Hosting

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

CloudFront + OAC 조합:

CloudFront: 글로벌 CDN, HTTPS, 커스텀 도메인.
OAC (Origin Access Control): CloudFront 에서만 S3 접근 허용.
S3 직접 접근 차단 (Block Public Access 유지).

Event Notifications

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

새 파일 → 처리 자동화.
이미지 thumbnail 생성, 비디오 transcoding, 데이터 처리.
[[aws-eventbridge]] 연동 시 content-based filtering 가능 (object key prefix 등).

S3 Select / S3 Object Lambda

S3 Select: CSV / JSON / Parquet 의 SQL 일부 query. 필요한 컬럼만 pull.
S3 Object Lambda: GET 요청 시 Lambda 가 transform (redact, watermark, format conversion).

보안

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

Encryption

종류	의미
`SSE-S3`	S3 관리 key (AES-256)
`SSE-KMS`	[[aws-kms]] 관리 key, 감사 가능
`SSE-C`	사용자 제공 key
`DSSE-KMS`	이중 암호화

2023년부터 기본 암호화 SSE-S3 자동 적용. 컴플라이언스 요구 시 SSE-KMS 전환.

Object Ownership + ACL

신규 버킷은 ACL 비활성화 + Object Ownership = BucketOwnerEnforced 권장. Cross-account 업로드 객체도 버킷 소유자가 자동 소유.

Inventory / Storage Lens / Analytics

도구	용도
S3 Inventory	객체 목록을 CSV/Parquet 으로 주기 출력 (대규모 버킷 감사)
S3 Storage Lens	조직 전체 스토리지 사용량 대시보드 (비용 최적화 insight)
S3 Analytics	접근 패턴 분석 → Standard-IA 전환 권고

# Storage Lens 기본 대시보드 (무료)
aws s3control get-storage-lens-dashboard \
  --config-id default-account-dashboard \
  --account-id 123456789

흔한 함정

[!WARNING]

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

Versioning 후 비용 = 옛 버전 누적. Lifecycle NoncurrentVersionExpiration 으로 정리.

Glacier 의 retrieval fee = Glacier 에서 빨리 꺼내면 비용 큼. 접근 빈도 고려.

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

CRR 에서 기존 객체 미복제 = Replication 설정 이전 객체는 S3 Batch Operations 로 별도 복제.

S3 Event + Lambda 무한 루프 = Lambda 가 같은 버킷에 쓰면 이벤트 재발생. prefix/suffix 필터 필수.

Presigned URL 의 만료 후 클라이언트 캐싱 = 클라이언트가 URL 를 저장해 재사용 시 403. 짧은 만료 + 재발급 로직.

[AWS] SQS: managed queue, FIFO, DLQ

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

정의

SQS (Simple Queue Service) = AWS 의 완전 관리형 메시지 큐. infinite scale, no provisioning, pay-per-request. 프로듀서와 컨슈머를 비동기로 분리.

Standard vs FIFO

항목	Standard	FIFO
처리량	거의 무한	300 msg/s (배치 시 3000/s)
순서	best-effort	엄격 (group 안)
중복	at-least-once (드물게 중복)	exactly-once (5분 dedup 윈도우)
URL suffix	`.amazonaws.com/...`	`.fifo` 필수
가격	저렴	약간 비쌈

선택 기준: 순서/중복 허용 가능 = Standard. 결제/주문 등 순서 중요 = FIFO.

흐름

sequenceDiagram
    participant P as Producer
    participant SQS
    participant C as Consumer

    P->>SQS: SendMessage(body)
    SQS-->>P: messageId
    C->>SQS: ReceiveMessage(WaitTimeSeconds=20)
    SQS-->>C: message + receiptHandle
    Note over SQS,C: visibility timeout 시작 (기본 30초)
    C->>C: 메시지 처리
    C->>SQS: DeleteMessage(receiptHandle)

Visibility Timeout

컨슈머가 메시지를 가져간 후 다른 컨슈머에게 숨겨지는 시간.

flowchart LR
    Recv["ReceiveMessage"] -->|"invisible (기본 30s)"| Hidden["처리 중\n다른 consumer 안 보임"]
    Hidden -->|"DeleteMessage 성공"| Done["제거됨"]
    Hidden -->|"timeout 만료"| Visible["다시 visible\n= retry"]
    Visible -->|"maxReceiveCount 초과"| DLQ["DLQ 로 이동"]

설정 원칙: 처리 예상 시간 × 2 + 여유 로 설정. Lambda timeout 과 함께 고려.

# 처리 중 timeout 연장 (최대 12시간)
sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=receipt_handle,
    VisibilityTimeout=600  # 10분으로 연장
)

DLQ (Dead Letter Queue)

# CloudFormation / CDK 설정
RedrivePolicy:
  deadLetterTargetArn: arn:aws:sqs:ap-northeast-2:123:my-dlq
  maxReceiveCount: 5

maxReceiveCount 초과 후 자동으로 DLQ 로 이동
원인 분석 후 StartMessageMoveTask 로 원본 큐에 재처리
DLQ 자체에도 DLQ 설정 가능 (중첩 방지)

DLQ 에 메시지 쌓이면 CloudWatch alarm 필수. 무한 재처리 방지.

Long Polling

sqs.receive_message(
    QueueUrl=queue_url,
    WaitTimeSeconds=20,        # long poll (최대 20초)
    MaxNumberOfMessages=10,    # 배치 (최대 10개)
)

메시지 없으면 최대 20초 대기 후 반환
short polling (기본 0초) 대비 API 호출 횟수 대폭 감소, 비용 절감
거의 항상 WaitTimeSeconds=20 권장

SQS + Lambda 이벤트 소스

AWS 가 자동으로 poll + batch + invoke + delete 처리.

# SAM / CloudFormation
EventSourceMapping:
  EventSourceArn: arn:aws:sqs:...:my-queue
  FunctionName: my-func
  BatchSize: 10
  MaximumBatchingWindowInSeconds: 5
  FunctionResponseTypes:
    - ReportBatchItemFailures   # 부분 실패 처리

ReportBatchItemFailures: batch 중 일부만 실패 시 해당 메시지만 DLQ 로 이동. 나머지는 정상 처리.

def handler(event, context):
    failures = []
    for record in event['Records']:
        try:
            process(record['body'])
        except Exception:
            failures.append({'itemIdentifier': record['messageId']})
    return {'batchItemFailures': failures}

FIFO + MessageGroupId

sqs.send_message(
    QueueUrl=fifo_queue_url,
    MessageBody=json.dumps(payload),
    MessageGroupId='user-42',           # 같은 group = 순서 보장
    MessageDeduplicationId='unique-id'  # 5분 dedup 윈도우
)

같은 MessageGroupId = 한 컨슈머가 순서대로 처리
다른 MessageGroupId = 병렬 처리 가능
ContentBasedDeduplication 활성 시 body hash 로 자동 dedup

배치 처리

# 최대 10개 한번에 전송 (비용 절감)
entries = [
    {'Id': str(i), 'MessageBody': json.dumps(msg)}
    for i, msg in enumerate(messages)
]
sqs.send_message_batch(QueueUrl=queue_url, Entries=entries)

SendMessageBatch: 최대 10개, 최대 256KB
DeleteMessageBatch: 소비 후 일괄 삭제
배치 API = 단건 대비 API 호출 최대 10배 절감

재시도 전략 설계

flowchart TB
    Recv["메시지 수신"] --> Process["처리"]
    Process -->|"성공"| Delete["DeleteMessage"]
    Process -->|"실패"| Retry{"재시도 횟수\n< maxReceiveCount?"}
    Retry -->|"예"| Timeout["visibility timeout 만료\n다시 visible"]
    Timeout --> Recv
    Retry -->|"아니오"| DLQ["DLQ 이동"]
    DLQ --> Alert["CloudWatch Alarm\n운영자 알림"]
    Alert --> Inspect["원인 분석"]
    Inspect --> Redrive["StartMessageMoveTask\n(재처리)"]

exponential backoff: Lambda + SQS 조합에서 재시도 간격을 늘리려면 visibility timeout 을 처리에서 수동으로 늘림.

import time

def handler(event, context):
    for record in event['Records']:
        receive_count = int(record['attributes']['ApproximateReceiveCount'])
        try:
            process(record['body'])
        except RetryableError:
            # 재시도 횟수에 따라 timeout 연장 (backoff)
            backoff = min(2 ** receive_count * 30, 900)  # 최대 15분
            sqs.change_message_visibility(
                QueueUrl=QUEUE_URL,
                ReceiptHandle=record['receiptHandle'],
                VisibilityTimeout=backoff
            )
            raise

모니터링 / 운영

필수 CloudWatch 메트릭:

메트릭	의미	alarm 기준
`ApproximateNumberOfMessages`	큐 적체량	임계값 초과 시
`ApproximateAgeOfOldestMessage`	가장 오래된 메시지 age	처리 지연 탐지
`NumberOfMessagesSent`	발행량	급감 시 producer 이상
`NumberOfMessagesDeleted`	처리 완료량	급감 시 consumer 이상

# DLQ alarm 예시 (CDK)
new cloudwatch.Alarm(this, 'DlqAlarm', {
  metric: dlq.metricApproximateNumberOfMessagesVisible(),
  threshold: 1,
  evaluationPeriods: 1,
  alarmDescription: 'DLQ 에 메시지 발생',
});

SQS vs Kafka 비교

항목	SQS	Kafka
운영 부담	0 (managed)	클러스터 관리 필요
처리량	무한 (auto)	노드 수 비례
Retention	최대 14일	무제한 (디스크)
Replay	DLQ redrive 만	consumer offset 자유 조정
Fan-out	[[aws-sns]] 와 결합	consumer group
순서	FIFO group 안에서	partition 안에서
비용 구조	사용량 비례	인프라 비례

선택 기준: AWS only + 단순 큐 + 운영 최소화 = SQS. 영속 + 재처리 + 대규모 throughput + 이벤트 스트리밍 = [[kafka]].

비용

$0.40 / 백만 요청 (Standard)
$0.50 / 백만 요청 (FIFO)
첫 100만 요청/월 무료
256KB 이상 메시지: 256KB 단위로 청구

비용 최적화:

Long polling (WaitTimeSeconds=20) 으로 빈 poll API 호출 최소화
배치 전송/수신으로 API 호출 횟수 절감
Lambda 이벤트 소스로 폴링 완전 위임

흔한 함정

[!WARNING]

at-least-once 중복 처리: Standard 큐에서 드물게 중복 발생. consumer 는 반드시 idempotent 하게. [[idempotency-keys]] 패턴 활용.

Visibility timeout 너무 짧음: 처리 도중 메시지가 다시 visible 되어 다른 컨슈머가 중복 처리.

DLQ 미설정: 실패 메시지가 무한 재시도, 큐 처리 지연 전파.

FIFO 에서 MessageGroupId 없이 전송: 모든 메시지가 단일 group = 단일 컨슈머 = 300 msg/s 한계.

배치 Lambda 에서 전체 예외: 일부 실패 시 batch 전체 재시도. ReportBatchItemFailures 설정 필수.

[!CAUTION] FIFO 큐 이름은 반드시 .fifo suffix. 생성 후 변경 불가. 설계 단계에서 결정 필요.

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

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

정의

STS (Security Token Service) = 임시 자격 증명 발급. short-lived (15분-12시간) credentials. 장기 access key 없이 안전하게 AWS 서비스에 접근.

사용 상황

상황	방법
CI/CD에서 deploy	GitHub OIDC + AssumeRoleWithWebIdentity
멀티 계정 AWS 조직	Cross-account AssumeRole
SaaS → 고객 계정 접근	AssumeRole + External ID
EC2/Lambda에서 API 호출	Instance Profile (자동 갱신)
EKS Pod에서 S3, DynamoDB	IRSA (AssumeRoleWithWebIdentity)
MFA 필요 작업	GetSessionToken
회사 SSO 로그인	AssumeRoleWithSAML

5가지 API

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

세션 유효 시간

API	최소	최대	비고
`AssumeRole`	15분	12시간	role `MaxSessionDuration` 설정 필요
`AssumeRoleWithWebIdentity`	15분	12시간
`AssumeRoleWithSAML`	15분	12시간
`GetSessionToken`	15분	36시간	MFA 필수 작업
Role Chaining	15분	1시간 고정	연장 불가

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
    participant GH as "GitHub Actions"
    participant OIDC as "GitHub OIDC"
    participant STS
    participant AWSOIDC as "AWS OIDC Provider"

    GH->>OIDC: JWT token 요청
    OIDC-->>GH: OIDC token
    GH->>STS: AssumeRoleWithWebIdentity
    STS->>AWSOIDC: token 검증
    AWSOIDC-->>STS: OK
    STS-->>GH: 임시 credentials
    GH->>STS: API 호출

EKS IRSA (위와 동일)

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

SAML Federation

기업 IdP (Okta, Active Directory, Azure AD) 로 로그인 후 AWS 콘솔, API 접근.

sequenceDiagram
    participant User
    participant IdP as "Identity Provider"
    participant STS
    participant Console as "AWS Console"

    User->>IdP: SSO 로그인
    IdP-->>User: SAML assertion
    User->>STS: AssumeRoleWithSAML
    STS-->>User: 임시 credentials
    User->>Console: 콘솔 접속

Trust policy 핵심 필드:

{
  "Principal": {
    "Federated": "arn:aws:iam::123:saml-provider/MyIdP"
  },
  "Action": "sts:AssumeRoleWithSAML",
  "Condition": {
    "StringEquals": {
      "SAML:aud": "https://signin.aws.amazon.com/saml"
    }
  }
}

IdP에서 role ARN을 attribute로 매핑. 사용자가 IAM user 없이 AWS 접근 가능.

Instance Profile (EC2, Lambda, ECS)

인스턴스에 붙이는 IAM role. IMDS를 통해 credentials 자동 갱신 (만료 5분 전).

Trust policy:

{
  "Principal": { "Service": "ec2.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

EC2 내부에서 현재 credentials 확인:

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -sH "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

SDK 사용 시 credentials 명시 불필요. 자동 갱신.

서비스	Principal
EC2	`ec2.amazonaws.com`
Lambda	`lambda.amazonaws.com`
ECS Task	`ecs-tasks.amazonaws.com`
CodeBuild	`codebuild.amazonaws.com`

Role Chaining

A role이 B role을 assume. 세션 최대 1시간 고정 (MaxSessionDuration 무관).

flowchart LR
    User["개발자"] -->|"AssumeRole"| RoleA["Role A (개발 계정)"]
    RoleA -->|"AssumeRole"| RoleB["Role B (운영 계정)"]
    RoleB --> Limit["세션: 최대 1시간"]

# Role A credentials 로 Role B assume
aws sts assume-role \
  --role-arn arn:aws:iam::PROD:role/deploy \
  --role-session-name chain-session \
  --duration-seconds 3600

[!WARNING] Role chaining 시 1시간 제한은 MaxSessionDuration 과 무관. 12시간 설정해도 체인이면 1시간. 배포 파이프라인이 1시간 초과할 경우 재assume 로직 필요.

Session Policy

AssumeRole 시 inline permission 추가 제한. role 권한 AND session policy = 실제 권한. 확대 불가.

aws sts assume-role \
  --role-arn arn:role/x \
  --role-session-name session \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }]
  }'

CI/CD에서 최소 권한 세션 발급, 임시 작업자에게 제한된 권한 부여 시 유용.

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 → 세분화 권한.

감사 (CloudTrail)

AssumeRole 이벤트는 CloudTrail에 자동 기록.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --max-results 20

주요 필드:

필드	의미
`userIdentity.arn`	누가 assume 했는지
`requestParameters.roleArn`	어느 role
`requestParameters.externalId`	External ID 사용 여부
`responseElements.assumedRoleUser`	결과 세션 ARN

// CloudWatch Logs Insights 쿼리 예시
{
  "filter": "eventName = 'AssumeRole'",
  "stats": "count(*) by userIdentity.arn"
}

[!TIP] 비정상 cross-account assume 감지용 EventBridge 룰 설정 권장. 알 수 없는 Account → SNS 알림.

Session 강제 만료

침해된 role 세션을 즉각 무효화:

# DenyAll inline policy 추가 (토큰 발급 시간 이전 세션 차단)
aws iam put-role-policy \
  --role-name compromised-role \
  --policy-name AWSRevokeOlderSessions \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "DateLessThan": {
          "aws:TokenIssueTime": "2026-07-16T12:00:00Z"
        }
      }
    }]
  }'

# 정리 후 삭제
aws iam delete-role-policy \
  --role-name compromised-role \
  --policy-name AWSRevokeOlderSessions

STS session 자체는 만료 전 취소 불가. 이 방식으로 실질적 무효화.

흔한 함정

[!WARNING]

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

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

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

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

Role Chaining 1시간 제한 간과 = 배포 파이프라인이 1시간 넘으면 자동 실패. 재assume 로직 추가.

SCP가 AssumeRole 차단 = OU 레벨 SCP 에서 sts:AssumeRole 거부 정책 확인 필수.

세션 tag 상속 누락 = TransitiveTagKeys 지정 안 하면 chaining 시 tag 사라짐.

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

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

정의

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

구조

flowchart TB
    VPC["VPC (10.0.0.0/16)"]
    VPC --> AZa["AZ ap-northeast-2a"]
    VPC --> AZb["AZ ap-northeast-2c"]
    AZa --> PubA["Public Subnet\n10.0.1.0/24"]
    AZa --> PrvA["Private Subnet\n10.0.10.0/24"]
    AZb --> PubB["Public Subnet\n10.0.2.0/24"]
    AZb --> PrvB["Private Subnet\n10.0.20.0/24"]
    PubA --> IGW["Internet Gateway\n(양방향 인터넷)"]
    PubB --> IGW
    PrvA --> NATA["NAT Gateway\n(AZ-a)"]
    PrvB --> NATB["NAT Gateway\n(AZ-c)"]
    NATA --> PubA
    NATB --> PubB

Subnet 종류

종류	정의	용도
Public	route table 에 IGW 항목 있음	ALB, Bastion, NAT GW
Private	IGW 없음, NAT GW 경유	EC2, EKS node, RDS
Isolated	외부 route 전혀 없음	DB, 내부 서비스

Route Table

subnet 별로 route table 연결. 규칙은 가장 구체적인 prefix 가 우선.

# Public subnet route table
Destination       Target
10.0.0.0/16       local          # VPC 내부 통신
0.0.0.0/0         igw-xxx        # 인터넷

# Private subnet route table
Destination       Target
10.0.0.0/16       local
0.0.0.0/0         nat-xxx        # NAT 경유 아웃바운드
192.168.0.0/16    pcx-xxx        # VPC Peering 대상
10.1.0.0/16       tgw-xxx        # Transit Gateway

NAT Gateway vs NAT Instance

아웃바운드 전용 인터넷 접근 (private subnet → 인터넷).

항목	NAT Gateway	NAT Instance
관리	AWS	사용자
가격	비쌈 (시간당 $0.059 + GB당 $0.059)	EC2 온디맨드
가용성	AZ 별 redundant	EC2 단일 장애점
처리량	최대 100 Gbps 자동 확장	EC2 type 한정
SG 적용	불가	가능

[!CAUTION] NAT Gateway 비용이 VPC 의 가장 큰 함정. GB 당 비용 + 시간당 비용 누적. S3/DynamoDB 는 VPC Endpoint 로 반드시 우회.

VPC Endpoint

Private subnet 에서 AWS 서비스를 인터넷 없이 접근.

flowchart LR
    Pod["Private Subnet EC2"] -.->|"NAT Gateway\n$$ 비용 발생"| NAT
    NAT --> S3["S3"]
    Pod -->|"VPC Endpoint\n무료 + 빠름"| S3

종류	대상	비용
Gateway Endpoint	S3, DynamoDB	무료
Interface Endpoint	대부분의 AWS 서비스	시간당 + 처리량 비용

Gateway Endpoint 추가만으로 S3/DynamoDB 트래픽이 NAT 우회 + 무료. 모든 VPC 에 기본 추가.

Connectivity 옵션

옵션	방향	용도
Internet Gateway (IGW)	양방향	public subnet 인터넷
NAT Gateway	아웃바운드만	private → 인터넷
VPC Peering	양방향	1:1 VPC 연결 (same/cross account)
Transit Gateway	양방향	Hub-spoke, 다수 VPC + on-prem
Site-to-Site VPN	양방향	on-prem 연결 (암호화)
Direct Connect	양방향	전용 회선, 대역폭 보장
VPC Endpoint (PrivateLink)	단방향	AWS 서비스 / SaaS

flowchart LR
    OnPrem["On-Premises"] -->|"Direct Connect\n(전용 회선)"| DX["DX Location"]
    DX --> VGW["Virtual Private Gateway"]
    OnPrem -->|"Site-to-Site VPN"| VGW
    VGW --> VPC1["VPC 1"]
    TGW["Transit Gateway"] --> VPC1
    TGW --> VPC2["VPC 2"]
    TGW --> VPC3["VPC 3"]
    VGW --> TGW

VPC Peering vs Transit Gateway

항목	VPC Peering	Transit Gateway
연결 수	1:1	N:N (hub-spoke)
전이적 라우팅	불가	가능
비용	데이터 전송만	시간당 + 처리량
교차 계정	가능	가능
교차 리전	가능	가능

2-3개 VPC = Peering 충분. 4개 이상 또는 온프레미스 연결 = Transit Gateway.

Security Group vs NACL

자세한 비교는 [[aws-sg-vs-nacl]].

항목	Security Group	NACL
계층	Stateful	Stateless
적용 대상	ENI / instance	Subnet
규칙 종류	allow 만	allow + deny
기본 동작	deny all (inbound)	allow all
규칙 평가	모든 규칙 OR	번호 순서대로

IPv4 CIDR 설계

RFC 1918 사설 대역
10.0.0.0/8        크고 광범위 (AWS 기업 권장)
172.16.0.0/12     중간
192.168.0.0/16    작음 (홈/소규모)

권장 VPC CIDR: /16 (65,534 IP)
권장 Subnet CIDR: /24 (254 IP)

IPAM (IP Address Manager): AWS Organizations 전체의 CIDR 충돌 방지 중앙 관리.

[!IMPORTANT] VPC 의 CIDR 충돌이 peering / Transit Gateway 의 가장 큰 함정. 한번 생성한 VPC CIDR 는 변경 불가. Organization 차원에서 사전 IPAM 계획 필수.

비용

항목	요금
VPC 생성	무료
IGW	무료
NAT Gateway	$0.059/시간 + $0.059/GB
VPC Peering 데이터	AZ 간 $0.01/GB, 리전 간 표준 요금
Transit Gateway	$0.05/attachment/시간 + $0.02/GB
Interface Endpoint	$0.01/시간/AZ + $0.01/GB
Gateway Endpoint	무료

NAT Gateway 비용 최적화:

S3, DynamoDB → Gateway Endpoint 로 대체
ECR → Interface Endpoint (대용량 이미지 pull 시 효과적)
단일 AZ 테스트 환경에서는 NAT Instance 고려

VPC Flow Logs

VPC 내 모든 ENI 트래픽 기록. 보안 감사, 트래픽 분석, 침해 탐지.

# VPC 수준 Flow Log 활성화
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-xxx \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::123:role/flow-log-role

로그 필드 (기본): version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action (ACCEPT/REJECT), log-status.

Flow Log 를 S3 에 저장 후 Athena 로 쿼리 가능 (대용량 분석).

설계 패턴

3-tier 아키텍처

flowchart TB
    Internet["인터넷"] --> IGW["Internet Gateway"]
    IGW --> PubSubnet["Public Subnet\nALB / Bastion / NAT GW"]
    PubSubnet --> AppSubnet["Private Subnet (App)\nEC2 / ECS / EKS Node"]
    AppSubnet --> DBSubnet["Isolated Subnet (DB)\nRDS / ElastiCache"]

원칙: 외부 접근이 필요한 것만 Public. 앱 서버는 Private. DB 는 인터넷 접근 완전 차단.

Multi-Account 설계

Organization
├── 네트워크 계정 (Transit Gateway 허브)
│   └── TGW ← 모든 VPC 연결
├── 프로덕션 계정
│   └── VPC (10.0.0.0/16) → TGW
├── 스테이징 계정
│   └── VPC (10.1.0.0/16) → TGW
└── 개발 계정
    └── VPC (10.2.0.0/16) → TGW

AWS Organizations + RAM (Resource Access Manager) 로 TGW 를 여러 계정에 공유.

PrivateLink

자체 서비스를 VPC 내에서 비공개로 제공. 인터넷 경유 없이 다른 VPC 또는 계정에 서비스 노출.

flowchart LR
    ConsumerVPC["소비자 VPC"] -->|"Interface Endpoint"| PL["AWS PrivateLink"]
    PL --> NLB["NLB (공급자 VPC)"]
    NLB --> Service["내부 서비스"]

SaaS 공급자: 고객 VPC 에 endpoint 서비스 제공
내부 공유 서비스: 여러 팀 VPC 에서 중앙 API 접근
AWS 서비스 (ECR, SSM, Secrets Manager 등) 비공개 접근

흔한 함정

[!WARNING]

NAT Gateway 비용 폭증: GB 당 과금. S3 endpoint 미설정 시 대규모 비용. 예산 alarm 설정 필수.

단일 AZ NAT: AZ 장애 시 해당 AZ private subnet 전체 아웃바운드 차단. AZ 별 NAT 권장.

CIDR 너무 작음: EKS pod IP 고갈. /16 이상 권장. 서브넷은 secondary CIDR 로 확장 가능.

Public subnet 에 DB 배치: 보안 모델 오류. DB 는 Private/Isolated 에 배치.

NACL 에서 임시 포트 block: stateless 이므로 응답 트래픽 허용 규칙 별도 필요 (1024-65535).

[!CAUTION] VPC 삭제는 내부 리소스 모두 삭제. 기본 VPC 수정 후 복구 어려움. 기본 VPC 를 그대로 사용하지 않고 전용 VPC 설계 권장.

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

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

정의

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

사용 상황

상황	핵심 개념
멀티 아키 이미지 빌드 (AMD64 + ARM64)	Image Index, BuildKit + QEMU
이미지 공급망 보안	Cosign 서명, SBOM
이미지 경량화	Dockerfile 레이어 최적화
취약점 스캔 자동화	Trivy, Grype
Registry 비용 최적화	Lifecycle Policy
Docker 외 런타임 사용 (K8s, K3s)	containerd, CRI-O

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)

Dockerfile 레이어 최적화

레이어는 캐시됨. 변경 빈도 낮은 것을 위에.

# 잘못된 순서 (매번 deps 재설치)
FROM node:20-alpine
COPY . .
RUN npm install

# 올바른 순서 (package.json 변경 없으면 캐시 재사용)
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .

# 멀티스테이지: 빌드 산출물만 최종 이미지에 포함
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

레이어 크기 확인:

docker history myapp:latest
dive myapp:latest   # dive 툴로 레이어별 상세 분석

BuildKit + QEMU (멀티 아키 빌드)

# buildx + QEMU 설치
docker buildx create --name multi-arch --driver docker-container --use
docker run --privileged --rm tonistiigi/binfmt --install all

# AMD64 + ARM64 동시 빌드 + push
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag myregistry/myapp:1.0.0 \
  --push \
  .

CI/CD (GitHub Actions) 에서:

- uses: docker/setup-qemu-action@v3
- uses: docker/setup-buildx-action@v3
- uses: docker/build-push-action@v6
  with:
    platforms: linux/amd64,linux/arm64
    push: true
    tags: myregistry/myapp:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

Image 취약점 스캔 (Trivy)

# 이미지 스캔
trivy image --severity HIGH,CRITICAL nginx:1.27

# CI에서 CRITICAL 발견 시 실패
trivy image \
  --exit-code 1 \
  --severity CRITICAL \
  --ignore-unfixed \
  myapp:latest

# SBOM 출력
trivy image --format cyclonedx --output sbom.json myapp:latest

flowchart LR
    Build["docker build"] --> Scan["trivy scan"]
    Scan --> Pass{결과}
    Pass -->|"CRITICAL 없음"| Push["registry push"]
    Pass -->|"CRITICAL 발견"| Fail["빌드 실패"]

Cosign 이미지 서명

공급망 보안. 이미지 무결성, 출처 검증.

# keyless 서명 (OIDC 기반, Sigstore)
cosign sign \
  --yes \
  myregistry/myapp@sha256:abc123...

# 검증
cosign verify \
  --certificate-identity-regexp "https://github.com/myorg/myrepo/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  myregistry/myapp:latest

GitHub Actions에서 자동 서명:

- uses: sigstore/cosign-installer@v3
- name: Sign image
  env:
    COSIGN_EXPERIMENTAL: 1
  run: |
    cosign sign --yes ${{ env.REGISTRY }}/${{ env.IMAGE }}@${{ steps.build.outputs.digest }}

keyless 서명은 private key 관리 불필요. OIDC token으로 Fulcio CA가 단기 인증서 발급.

SBOM (Software Bill of Materials)

이미지에 포함된 소프트웨어 목록. 취약점 추적, 규정 준수.

# syft로 SBOM 생성
syft myapp:latest -o cyclonedx-json > sbom.json
syft myapp:latest -o spdx-json > sbom.spdx.json

# SBOM을 OCI Artifact로 registry에 첨부
cosign attach sbom \
  --sbom sbom.json \
  myregistry/myapp@sha256:abc123...

# Grype로 SBOM 기반 취약점 스캔
grype sbom:sbom.json

Registry Lifecycle Policy (ECR 예시)

오래된 이미지 자동 삭제로 스토리지 비용 절감.

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "30일 이상 된 untagged 이미지 삭제",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 30
      },
      "action": { "type": "expire" }
    },
    {
      "rulePriority": 2,
      "description": "최근 10개 tagged 이미지 유지",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["v"],
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": { "type": "expire" }
    }
  ]
}

흔한 함정

[!WARNING]

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

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

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

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

root로 실행 = Dockerfile 에 USER nonroot 없으면 컨테이너가 root 권한으로 실행. 보안 위험.

base image 업데이트 안 함 = OS 취약점 방치. 정기 FROM ubuntu:24.04 재빌드.

빌드 시 secrets 레이어에 남음 = RUN --mount=type=secret 사용. ENV로 비밀 전달 금지.

SBOM/서명 없는 배포 = K8s Policy (Kyverno) 로 서명 없는 이미지 배포 차단 권장.

[IaC] AWS CDK: TypeScript 로 CloudFormation 생성

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

정의

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

[[aws-cloudformation|CloudFormation]] YAML 을 직접 쓰는 대신 프로그래밍 언어로 인프라를 선언. 타입 안전성, 추상화, 재사용, 테스트 가능.

흐름

flowchart LR
    Code["TypeScript / Python\n(CDK App)"] --> Synth["cdk synth\n(CFN template 생성)"]
    Synth --> Diff["cdk diff\n(변경 미리보기)"]
    Diff --> Deploy["cdk deploy\n(CloudFormation 호출)"]
    Deploy --> CFN["CloudFormation Stack"]
    CFN --> AWS["AWS Resources"]

Construct Level (L1, L2, L3)

CDK 의 핵심 추상화 단위는 Construct. 3단계 레벨로 분류.

Level	이름	의미	예시
L1	CloudFormation Resources	CFN 그대로, 자동 생성	`CfnBucket`, `CfnFunction`
L2	Curated Constructs	추상화 + 기본값 제공	`Bucket`, `Function`, `Table`
L3	Patterns	합성 (여러 L2 묶음)	`LoadBalancedFargateService`

flowchart TB
    L3["L3 Pattern\nLoadBalancedFargateService"] --> L2a["L2 Construct\nApplicationLoadBalancer"]
    L3 --> L2b["L2 Construct\nFargateService"]
    L2a --> L1a["L1 CfnLoadBalancer"]
    L2b --> L1b["L1 CfnService"]
    L1a --> CFN["CloudFormation Resource"]
    L1b --> CFN

예시: S3 + Lambda





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'),
      environment: {
        BUCKET_NAME: bucket.bucketName,
      },
    });

    // IAM 자동 생성: bucket policy + role + policy
    bucket.grantReadWrite(fn);
  }
}

bucket.grantReadWrite(fn) 한 줄 = bucket resource policy + Lambda IAM role + policy 연결 자동. 가장 강력한 추상화.

L3 패턴 예시: ALB + Fargate



new ApplicationLoadBalancedFargateService(this, 'Service', {
  cluster,
  taskImageOptions: {
    image: ContainerImage.fromRegistry('nginx:latest'),
    containerPort: 80,
  },
  desiredCount: 3,
  cpu: 256,
  memoryLimitMiB: 512,
  publicLoadBalancer: true,
});

ALB + Target Group + Fargate Task Definition + ECS Service + Security Group + IAM Role 을 한 번에 생성.

CDK 명령

cdk init app --language=typescript    # 프로젝트 초기화
cdk bootstrap                         # CDK metadata bucket 생성 (account+region 당 1회)
cdk synth                             # CFN template 생성 (cdk.out/)
cdk diff                              # 현재 배포 vs 변경 예정 diff
cdk deploy MyStack                    # 배포
cdk deploy --all                      # 전체 stack 배포
cdk destroy MyStack                   # 삭제
cdk ls                                # stack 목록

Aspects: 전체 적용 정책

Aspect = CDK tree 를 순회하며 모든 construct 에 적용하는 visitor.



class EnforceEncryption implements IAspect {
  visit(node: IConstruct): void {
    if (node instanceof CfnBucket) {
      node.bucketEncryption = {
        serverSideEncryptionConfiguration: [{
          serverSideEncryptionByDefault: { sseAlgorithm: 'AES256' },
        }],
      };
    }
  }
}

// 앱 전체에 적용
Aspects.of(app).add(new EnforceEncryption());

사용 사례: 전사 보안 정책 강제, 태그 자동 추가, cost center 라벨링.

Snapshot 테스트




test('snapshot', () => {
  const app = new App();
  const stack = new MyStack(app, 'TestStack');
  const template = Template.fromStack(stack);

  // 특정 리소스 확인
  template.hasResourceProperties('AWS::S3::Bucket', {
    VersioningConfiguration: { Status: 'Enabled' },
  });

  // 전체 스냅샷 (변경 추적)
  expect(template.toJSON()).toMatchSnapshot();
});

CI 에 스냅샷 테스트 필수. 의도치 않은 인프라 변경을 PR 단계에서 캐치.

CDK vs Terraform vs Pulumi

항목	CDK	Terraform	Pulumi
언어	TS/Python/Java/Go	HCL	TS/Python/Go/C#
Multi-cloud	AWS 위주	예	예
State	CFN managed	별도 backend	Pulumi Cloud
추상화	L1/L2/L3	provider	코드
타입 안전성	완전 (TS)	제한적	완전
테스트	jest / pytest	terratest	언어 내장
AWS 새 서비스 대응	즉시	provider 업데이트 필요	provider 업데이트 필요
학습 곡선	AWS 잘 알면 낮음	HCL 별도 학습	코드 자유도 높음

판단 기준:

AWS-only + 개발자 친화성 + 타입 안전성 → CDK
Multi-cloud + 인프라 팀 중심 → Terraform
Multi-cloud + 완전한 프로그래밍 언어 → Pulumi

Custom Construct 패턴

재사용 가능한 인프라 패턴을 Construct 로 추상화.





// 재사용 가능한 Lambda + SQS Construct
export class WorkerConstruct extends Construct {
  public readonly queue: Queue;
  public readonly fn: Function;

  constructor(scope: Construct, id: string, props: { handler: string }) {
    super(scope, id);

    this.queue = new Queue(this, 'Queue', {
      visibilityTimeout: cdk.Duration.seconds(300),
    });

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

    this.fn.addEventSource(new SqsEventSource(this.queue, {
      batchSize: 10,
      reportBatchItemFailures: true,
    }));
  }
}

// 사용: 두 줄로 SQS + Lambda 구성 완료
const worker = new WorkerConstruct(this, 'ImageProcessor', {
  handler: 'image.handler',
});

Pipelines (CI/CD)

CDK Pipelines = 코드로 선언한 배포 파이프라인.


const pipeline = new CodePipeline(this, 'Pipeline', {
  pipelineName: 'MyPipeline',
  synth: new ShellStep('Synth', {
    input: CodePipelineSource.gitHub('org/repo', 'main'),
    commands: ['npm ci', 'npx cdk synth'],
  }),
});

// 스테이지 추가
pipeline.addStage(new MyAppStage(this, 'Prod', {
  env: { account: '123', region: 'ap-northeast-2' },
}));

self-mutating: pipeline 자체도 코드에서 관리. 파이프라인 정의 변경 시 자동 업데이트.

CDK for Terraform (cdktf)



class MyStack extends TerraformStack {
  constructor(scope: App, id: string) {
    super(scope, id);
    new S3Bucket(this, 'data', { bucket: 'myapp-data' });
  }
}

CDK 의 언어 (TS/Python) + Terraform 의 multi-cloud backend. HashiCorp 와 협력.

비용

CDK 자체는 무료. 생성되는 AWS 리소스 요금 + bootstrap bucket (S3) 비용.

비용 최적화:

cdk deploy --hotswap: Lambda / ECS 변경을 CFN 대신 직접 배포 (개발 속도 향상)
bootstrap bucket 의 오래된 asset 주기적 정리
cdk diff 로 불필요한 replacement 사전 차단

흔한 함정

[!WARNING]

cdk bootstrap 누락: account+region 당 1회 필요. CI/CD 파이프라인에서 첫 실행 시 실패.

CFN limit 500 resource: 대형 stack 은 Nested stack 으로 분리.

CDK Asset S3 누적: bootstrap bucket 에 Lambda zip 등 asset 누적. 정기 정리 또는 lifecycle 설정.

L2 기본값 함정: Bucket 은 public access block 기본 활성. 의도한 설정인지 확인.

snapshot 테스트 미적용: stack 변경 시 의도치 않은 resource 재생성 (replacement) 놓침.

[!CAUTION] RemovalPolicy.DESTROY 는 stack 삭제 시 S3 버킷, RDS 등 데이터 포함 삭제. 프로덕션 리소스는 반드시 RETAIN.

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

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

정의

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

사용 상황

상황	이유
반복/조건 분기가 많은 인프라	언어 자유도 활용
내부 플랫폼 도구 (self-service portal)	Automation API
멀티 스택, 환경 분리	Stack + ESC
기존 Terraform 마이그레이션	import + 호환 provider
인프라에 unit test 적용	Pulumi testing SDK
Policy as Code	CrossGuard

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 (diff)"]
    Preview --> Up["pulumi up (실제 변경)"]
    Up --> State[("stack state<br/>backend")]
    State --> Drift["drift detection"]

명령

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", { assumeRolePolicy: "..." });
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
멀티 클라우드	예	예

Stack 관리

Stack = 환경 단위 (dev, staging, prod). 각 stack은 독립적 state.

pulumi stack init staging
pulumi stack select dev
pulumi stack ls
pulumi stack rm old-stack --force

Stack 별 config

const config = new pulumi.Config();
const region = config.require("region");       // 없으면 에러
const debug = config.getBoolean("debug") ?? false;

# dev 스택
pulumi config set region ap-northeast-2 --stack dev

# prod 스택
pulumi config set region us-east-1 --stack prod

Stack References (cross-stack output)

// 네트워크 스택에서 VPC ID 읽기
const netStack = new pulumi.StackReference("org/network/prod");
const vpcId = netStack.getOutput("vpcId");

const cluster = new aws.ecs.Cluster("app", {
  tags: { VpcId: vpcId.apply(id => String(id)) },
});

스택 간 의존성을 명시적으로 표현. Terraform data.terraform_remote_state 와 동일 패턴.

Component Resources

재사용 가능한 고수준 추상화.

class SecureBucket extends pulumi.ComponentResource {
  public readonly bucket: aws.s3.Bucket;
  public readonly bucketName: pulumi.Output<string>;

  constructor(name: string, opts?: pulumi.ComponentResourceOptions) {
    super("myapp:index:SecureBucket", name, {}, opts);

    this.bucket = new aws.s3.Bucket(name, {
      acl: "private",
      serverSideEncryptionConfiguration: {
        rule: {
          applyServerSideEncryptionByDefault: {
            sseAlgorithm: "AES256",
          },
        },
      },
    }, { parent: this });

    this.bucketName = this.bucket.id;
    this.registerOutputs({ bucketName: this.bucketName });
  }
}

// 사용
const dataBucket = new SecureBucket("data");

CrossGuard (Policy as Code)

인프라 정책을 코드로. 배포 전 자동 검사.

// policy-pack/index.ts


new PolicyPack("aws-security", {
  policies: [
    {
      name: "s3-no-public-read",
      description: "S3 버킷 public read 금지",
      enforcementLevel: "mandatory",
      validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, report) => {
        if (bucket.acl === "public-read") {
          report("public-read ACL 은 금지입니다.");
        }
      }),
    },
  ],
});

pulumi up --policy-pack ./policy-pack

단위 테스트

// __tests__/infra.test.ts


pulumi.runtime.setMocks({
  newResource: (type, name, inputs) => ({ id: `${name}-id`, state: inputs }),
  call: (token, args, provider) => ({ result: args }),
});


test("S3 bucket 암호화 활성화", async () => {
  const bucket = new SecureBucket("test");
  const sse = await bucket.bucket.serverSideEncryptionConfiguration.get();
  expect(sse?.rule?.applyServerSideEncryptionByDefault?.sseAlgorithm).toBe("AES256");
});

npx vitest run     # 또는 jest

Automation API


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

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

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

Pulumi ESC (Environments, Secrets, Configuration)

환경별 비밀, 설정을 중앙 관리. OIDC로 동적 credentials 발급.

# esc-env.yaml
values:
  aws:
    login:
      fn::open::aws-login:
        oidc:
          duration: 1h
          roleArn: arn:aws:iam::123:role/pulumi-esc
          sessionName: pulumi-esc

  environmentVariables:
    AWS_ACCESS_KEY_ID: ${aws.login.accessKeyId}
    AWS_SECRET_ACCESS_KEY: ${aws.login.secretAccessKey}
    AWS_SESSION_TOKEN: ${aws.login.sessionToken}

esc env open myorg/prod
esc run myorg/prod -- pulumi up

GitHub Actions CI/CD

name: Pulumi Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: pulumi/actions@v5
        with:
          command: up
          stack-name: prod
          cloud-url: s3://my-pulumi-state
        env:
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
          AWS_REGION: ap-northeast-2

흔한 함정

[!WARNING]

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

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

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

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

ComponentResource 에서 parent: this 누락 = state 에 고아 리소스. 항상 { parent: this } 전달.

pulumi destroy 순서 = 의존 stack 먼저 destroy. StackReference 있으면 역순.

drift 탐지 = pulumi refresh 로 실제 인프라 상태와 state 동기화.

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

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

정의

Terraform State = 코드 (의도) vs 실제 인프라 매핑. JSON 파일. 모든 Terraform 작업의 핵심. plan, apply, destroy 모두 state 를 기반으로 diff 계산.

사용 상황

상황	Terraform State 주요 고려사항
팀 협업	Remote backend 필수 (S3/TFC), local file 금지
여러 환경 분리	Workspace 또는 별도 backend key
기존 인프라 도입	`terraform import` 로 state 등록
인프라 드리프트 감지	`terraform plan -refresh-only` 정기 실행
대규모 모노리식 state	레이어별 state 분할 전략
Secret 관리	output sensitive + [[aws-secrets-manager]] 또는 Vault

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/ID
Metadata	의존성 그래프, 버전 정보
Performance	refresh 캐시 (매번 AWS API 호출 안 해도 됨)
Sensitive	output value 보관 (평문)

State 파일 내부 구조

{
  "version": 4,
  "terraform_version": "1.8.0",
  "serial": 42,
  "lineage": "550e8400-...",
  "outputs": {
    "vpc_id": {
      "value": "vpc-0abc123",
      "type": "string",
      "sensitive": false
    }
  },
  "resources": [
    {
      "mode": "managed",
      "type": "aws_s3_bucket",
      "name": "data",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "my-data-bucket",
            "bucket": "my-data-bucket",
            "region": "us-east-1"
          }
        }
      ]
    }
  ]
}

serial: apply 마다 증가. 충돌 감지.
lineage: state 파일 고유 ID. 다른 state 교체 방지.
sensitive 출력값도 JSON 에 평문 저장. Backend 암호화 필수.

Backend 종류

flowchart TB
    B[Backend]
    B --> Local[local file<br/>팀 사용 금지]
    B --> S3["S3 + DynamoDB lock<br/>(AWS 표준)"]
    B --> TFC["Terraform Cloud / HCP Terraform"]
    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:us-east-1:123:key/..."
    dynamodb_table = "tf-lock"
  }
}

컴포넌트	역할
S3 bucket	state 저장 + versioning 활성화
KMS	server-side 암호화
DynamoDB	distributed lock (conditional write)

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 (CAS: Compare-And-Swap).

Lock 강제 해제 (비정상 종료 후):

terraform force-unlock LOCK_ID

Drift Detection

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

상황	원인	대응
state < 실제	콘솔 직접 수정	`terraform refresh` + 코드 반영
state > 실제	수동 삭제	`terraform state rm` 후 재적용
정기 감지	드리프트 자동화	CI 에서 `plan -refresh-only` 스케줄링

Prod 수동 변경 감지. 정기 drift check 는 CI 파이프라인에 포함.

State 분할 전략

flowchart TD
    Mono["모노리식 State<br/>(모든 리소스 한 파일)"]
    Split["레이어별 State 분할"]
    Mono --> Split
    Split --> Net["network/<br/>VPC, Subnet, Route"]
    Split --> Compute["compute/<br/>EKS, EC2, ASG"]
    Split --> App["app/<br/>Lambda, RDS, ElastiCache"]
    Split --> Shared["shared/<br/>IAM, KMS, ECR"]

레이어	예시 리소스	변경 빈도
network	VPC, Subnet, Route Table	매우 낮음
shared	IAM Role, KMS Key, ECR	낮음
compute	EKS, EC2, Auto Scaling	중간
app	Lambda, RDS, ElastiCache	높음

분할 이점: plan 시간 단축, 블라스트 반경 감소, 팀별 소유권 분리. 분할 방법: terraform_remote_state 로 다른 state 의 output 참조.

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "my-tf-state"
    key    = "prod/network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_eks_cluster" "main" {
  vpc_config {
    subnet_ids = data.terraform_remote_state.network.outputs.private_subnet_ids
  }
}

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 > backup.tfstate          # state 다운로드 (백업)
terraform state push backup.tfstate            # state 업로드 (위험, 수동)

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

[!CAUTION] state push 는 serial 번호 역전 방지 없이 덮어씀. 잘못된 state 로 인프라 삭제 위험.

Import (기존 리소스 등록)

CLI import (Terraform 1.5+)

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 apply

구버전 CLI import

terraform import aws_s3_bucket.legacy my-legacy-bucket

코드는 직접 작성. import 후 terraform plan 으로 drift 없는지 확인.

Workspace (환경 분리)

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

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

resource "aws_instance" "web" {
  instance_type = local.env == "prod" ? "c5.xlarge" : "t3.small"
}

한 backend 에 여러 state 관리. 단, separate backend (별도 S3 key) 가 더 안전. Workspace 는 동일 AWS 계정에서 사용 → 실수로 Prod 에 staging 적용 위험.

Terragrunt 연계

Terraform 의 DRY wrapper. 여러 환경/레이어의 중복 backend 설정 제거.

# terragrunt.hcl
remote_state {
  backend = "s3"
  config = {
    bucket  = "my-tf-state-${get_aws_account_id()}"
    key     = "${path_relative_to_include()}/terraform.tfstate"
    region  = "us-east-1"
    encrypt = true
    dynamodb_table = "tf-lock"
  }
}

environments/
  prod/
    network/   ← terragrunt.hcl 상속
    compute/
    app/
  staging/
    network/
    compute/

CI/CD 연계

단계	명령	설명
PR	`terraform plan`	diff 리뷰, 변경 범위 확인
Merge	`terraform apply -auto-approve`	자동 적용
정기	`terraform plan -refresh-only`	drift 감지
공유	plan 결과를 PR comment 로	Atlantis / Spacelift / TFC

Atlantis 나 Terraform Cloud 는 PR 이벤트에 plan 자동 실행 + 승인 후 apply.

State 의 위험

[!WARNING]

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

수동 state 편집 = 형식 깨짐 위험. 반드시 terraform state 명령 사용.

State 손실 = 추적 불가 (코드와 실제 매핑 소실). S3 versioning + 정기 백업.

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

Local backend 를 팀이 공유 = git 에 state 올리면 secret 노출 + 충돌. Remote backend 전환.

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

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

AWS API Gateway 는 REST / HTTP / WebSocket API 를 관리하는 완전관리형 서비스. 인증, 스로틀링, 캐싱, 요청/응답 변환, 로깅을 단일 서비스로 제공. Lambda 와 결합해 서버리스 백엔드의 진입점이 된다.

API 타입 비교

항목	REST API	HTTP API	WebSocket API
출시	2015	2019	2018
비용	$3.50/million	$1.00/million	$1.00/million
지연시간	높음	낮음	-
JWT authorizer	Lambda만	내장	Lambda만
WAF 통합	가능	가능 (v2)	아니오
Request validator	있음	없음	없음
Usage Plan/API Key	있음	없음	없음
Response 캐싱	있음	없음	-
프라이빗 endpoint	가능	가능	-

[!IMPORTANT] 신규 프로젝트는 HTTP API 우선 검토. 기능 격차를 확인 후 REST API 선택.

아키텍처: Lambda 프록시 통합

flowchart LR
    Client["클라이언트"] -->|"HTTPS (TLS)"| APIGW["API Gateway"]
    APIGW -->|"JWT / Lambda 인증"| Auth["Authorizer"]
    Auth -->|"allow"| APIGW
    APIGW -->|"Lambda Proxy 요청"| Lambda["Lambda"]
    Lambda -->|"응답"| APIGW
    APIGW -->|"HTTP 응답"| Client

    APIGW -.->|"실패 시"| APIGW

Lambda proxy 통합: API Gateway 가 원본 요청을 그대로 Lambda 에 전달 (path, headers, body, queryStringParameters 포함). Lambda 는 statusCode, headers, body 를 포함한 JSON 을 반환.

통합 타입

Lambda Proxy

{
  "httpMethod": "POST",
  "path": "/users",
  "headers": { "Authorization": "Bearer ..." },
  "queryStringParameters": { "page": "1" },
  "body": "{\"name\": \"alice\"}"
}

Lambda 응답:

{
  "statusCode": 201,
  "headers": { "Content-Type": "application/json" },
  "body": "{\"id\": \"u123\"}"
}

HTTP Proxy

외부 URL 로 요청 그대로 포워딩. 변환 없음.

# 통합 설정
integration:
  type: HTTP_PROXY
  uri: "http://internal-alb.example.com/{proxy}"
  httpMethod: ANY

VPC Link

프라이빗 [[aws-vpc|VPC]] 내 [[aws-alb-nlb|ALB/NLB]] 와 연결. 인터넷 노출 없이 내부 서비스 연결.

flowchart LR
    APIGW["API Gateway"] -->|"VPC Link"| VL["VPC Link"]
    VL --> NLB["NLB (private)"]
    NLB --> SVC["내부 서비스"]

AWS 서비스 직접 통합

Lambda 없이 DynamoDB, SQS, S3 등 직접 호출.

integration:
  type: AWS
  uri: "arn:aws:apigateway:us-east-1:dynamodb:action/PutItem"
  credentials: "arn:aws:iam::123:role/apigw-dynamo-role"

인증/인가

Lambda Authorizer (커스텀)

def handler(event, context):
    token = event['authorizationToken']
    # JWT 검증 또는 DB 조회
    effect = "Allow" if valid(token) else "Deny"
    return {
        "principalId": "user123",
        "policyDocument": {
            "Version": "2012-10-17",
            "Statement": [{
                "Action": "execute-api:Invoke",
                "Effect": effect,
                "Resource": event['methodArn']
            }]
        },
        "context": { "userId": "u123" }   # Lambda 로 전달 가능
    }

캐싱: Lambda Authorizer 결과를 TTL 동안 캐시. 기본 300초. 비용 절감 + 지연시간 단축.

JWT Authorizer (HTTP API 전용)

authorizer:
  type: JWT
  jwtConfiguration:
    issuer: "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_xxx"
    audience: ["client-id-1"]
  identitySource: "$request.header.Authorization"

Cognito, Auth0, Okta 등 OIDC 호환 IdP 와 바로 연동. Lambda 불필요.

IAM + SigV4

AWS SDK / CLI 로 서명된 요청. 내부 서비스 간 통신에 적합.

스로틀링 설정

flowchart TD
    Req["요청"] --> AccLim["계정 레벨<br/>10,000 rps / 5,000 burst"]
    AccLim --> APILim["API/Stage 레벨<br/>사용자 지정"]
    APILim --> MethodLim["메서드 레벨<br/>사용자 지정"]
    MethodLim --> UsagePlan["Usage Plan<br/>API Key 별 quota"]

레벨	기본값	변경
계정 전체	10,000 rps / burst 5,000	Support 티켓으로 증가
Stage/API	계정 한도 공유	콘솔/API 로 설정
메서드	Stage 한도 공유	각 메서드별 오버라이드
Usage Plan	일/월 quota, rps	API Key 단위

429 Too Many Requests 반환 시 Retry-After 헤더 제공.

스테이지 관리

prod (v1)   →  stage variables: LOG_LEVEL=WARN
staging     →  stage variables: LOG_LEVEL=DEBUG
dev         →  stage variables: LOG_LEVEL=DEBUG

Stage Variable: 스테이지별 환경 변수. Lambda alias 로 활용 가능.
Canary deployment: 스테이지에서 일부 트래픽만 새 버전으로.
Deployment: Stage 에 변경사항 반영 (명시적 배포 필요).

캐싱 (REST API)

# 캐시 활성화
aws apigateway update-stage \
  --rest-api-id abc123 \
  --stage-name prod \
  --patch-operations \
    op=replace,path=/cacheClusterEnabled,value=true \
    op=replace,path=/cacheClusterSize,value=0.5

캐시 크기	비용/시간
0.5 GB	$0.020
1.6 GB	$0.038
6.1 GB	$0.200
13.5 GB	$0.250

[!WARNING] 캐시는 REST API 전용. HTTP API 에는 없음. 비용이 추가되므로 고트래픽 GET 엔드포인트에만 적용.

요청/응답 변환 (REST API)

Velocity Template Language (VTL) 로 매핑:

#set($inputRoot = $input.path('$'))
{
  "userId": "$inputRoot.id",
  "email": "$inputRoot.contact.email"
}

HTTP API 는 변환 불가 (Lambda 내부에서 처리).

사용 패턴

BFF (Backend for Frontend)

flowchart LR
    Web["Web 클라이언트"] --> GWAY["API Gateway<br/>BFF"]
    Mobile["Mobile 클라이언트"] --> GWAY
    GWAY --> UserSvc["User Service<br/>Lambda"]
    GWAY --> OrderSvc["Order Service<br/>Lambda"]
    GWAY --> PaySvc["Payment Service<br/>Lambda"]

Microservice Gateway

각 마이크로서비스에 별도 API Gateway 대신 단일 진입점 제공.

이벤트 수신 (SNS/SQS 연결)

Client → API Gateway → SQS → Lambda consumer

비동기 처리 패턴. 즉시 202 Accepted 반환, 실제 처리는 SQS 로.

비용 구조

항목	REST API	HTTP API
첫 3억 요청/월	$3.50/million	$1.00/million
3억 초과	$1.51/million	$0.90/million
캐싱	별도 시간당 요금	없음
데이터 전송	AWS 표준	AWS 표준

비용 절감 팁:

HTTP API 우선 사용 (70% 저렴)
캐싱으로 Lambda 호출 감소
REST API 의 Usage Plan 으로 초과 사용 방지

대안 비교

옵션	특성	적합한 경우
API Gateway HTTP	낮은 비용, JWT 내장	신규 서버리스 API
API Gateway REST	풍부한 기능, WAF, 캐싱	레거시 마이그레이션, API Key 관리
**[[aws-alb-nlb	ALB]]**	고성능, 저렴, L7 LB
AppSync	GraphQL 특화, 실시간	GraphQL API, 모바일
CloudFront + Functions	초저지연 엣지	간단 API 변환

함정

[!WARNING] Lambda 콜드 스타트: API Gateway 자체는 콜드 스타트 없음. [[aws-lambda-cold-start|Lambda Cold Start]] 가 응답 지연 원인. Provisioned Concurrency 로 완화.

[!WARNING] payload 크기 제한: REST/HTTP API 10 MB, WebSocket 128 KB. 대용량 파일은 S3 Presigned URL 로 직접 업로드.

[!CAUTION] 프라이빗 API 와 VPC Endpoint: VPC 내부에서만 접근 가능한 API 는 Interface VPC Endpoint 필요. 구성 복잡.

[!WARNING] REST API 와 HTTP API 기능 격차: REST API 의 Request Validator, Usage Plan, 캐싱, WAF IP Set 참조 등은 HTTP API 에 없음. 마이그레이션 전 기능 확인 필수.

[!CAUTION] 스테이지 변수와 Lambda alias: Stage variable 로 Lambda alias 참조 시 Lambda resource policy 에 API Gateway 권한 별도 추가 필요.

[!WARNING] CORS 설정 누락: HTTP API 는 CORS 자동 설정 지원. REST API 는 수동 설정 필요 (OPTIONS 메서드, Access-Control-Allow-Origin 헤더).

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

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

ECS (Elastic Container Service) = AWS 의 컨테이너 오케스트레이션. K8s 보다 단순하고 AWS 네이티브.

Fargate = ECS (또는 EKS) 의 서버리스 실행 환경. EC2 인스턴스 관리 없이 Task 단위 vCPU/Memory 예약 + 과금.

ECS 계층 구조

flowchart TB
    Cluster["Cluster (논리 그룹)"]
    Cluster --> SvcA["Service A<br/>(Deployment 역할)"]
    Cluster --> SvcB["Service B"]
    SvcA --> T1["Task (실행 인스턴스)"]
    SvcA --> T2["Task"]
    SvcB --> T3["Task"]
    T1 --> C1["Container 1<br/>(nginx)"]
    T1 --> C2["Container 2<br/>(sidecar)"]

객체	역할	K8s 비교
Cluster	논리 그룹 (EC2 / Fargate 혼합 가능)	Cluster
Task Definition	컨테이너 스펙 (버전 관리됨)	Pod spec (manifiest)
Task	실행 중인 Task Definition 인스턴스	Pod
Service	desired count 유지, LB 통합, 롤링 배포	Deployment

Task Definition 상세

{
  "family": "web",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123:role/ecsTaskRole",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123.dkr.ecr.us-east-1.amazonaws.com/web:latest",
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "environment": [
        { "name": "APP_ENV", "value": "production" }
      ],
      "secrets": [
        { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:us-east-1:123:secret:prod/db" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/web",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3
      }
    }
  ]
}

IAM Role 두 가지 구분:

executionRoleArn: ECS agent 가 ECR 이미지 pull, CloudWatch 로그 쓰기에 사용
taskRoleArn: 컨테이너 내 앱이 AWS 서비스 (DynamoDB, S3 등) 접근에 사용

Fargate vs EC2 Launch Type

항목	EC2 Launch Type	Fargate
노드 관리	사용자 직접 관리	AWS 관리
운영 부담	패치, 스케일링, AMI	없음
가격 모델	EC2 인스턴스 시간	Task vCPU + Memory 시간
비용 (대규모)	저렴 (밀도 최적화)	일반적으로 비쌈
GPU 지원	가능	일부만
호스트 접근	SSH 가능	불가
시작 속도	빠름 (사전 프로비전)	약간 느림 (콜드 스타트)
Spot 사용	가능	Fargate Spot
적합	비용 최적화, GPU, 밀도	운영 단순화, 변동 워크로드

[!TIP] 소규모 팀 / 운영 부담 최소화 = Fargate. 대규모 / 비용 최적화 = EC2 Launch Type (Bin packing).

Fargate 가격 구조

vCPU 시간: $0.04048/vCPU/시간
Memory:    $0.004445/GB/시간

예: 0.5 vCPU + 1 GB Memory, 720시간/월
  = (0.5 * $0.04048 * 720) + (1 * $0.004445 * 720)
  = $14.57 + $3.20 = ~$17.77/월

Fargate Spot: 70% 할인. 2분 사전 통지 후 중단 가능. Stateless/Batch 에 적합.

Service 설정 (Deployment)

service:
  cluster: prod
  taskDefinition: "web:42"
  desiredCount: 3
  launchType: FARGATE
  networkConfiguration:
    awsvpcConfiguration:
      subnets: [subnet-private-a, subnet-private-b]
      securityGroups: [sg-app]
      assignPublicIp: DISABLED
  loadBalancers:
    - targetGroupArn: "arn:aws:elasticloadbalancing:..."
      containerName: web
      containerPort: 8080
  deploymentConfiguration:
    minimumHealthyPercent: 100    # 롤링 중 최소 가용 비율
    maximumPercent: 200           # 롤링 중 최대 Task 수
  deploymentController:
    type: ECS                     # 기본 (CODE_DEPLOY 로 Blue/Green 가능)

ALB 통합 아키텍처

flowchart LR
    Internet["인터넷"] --> ALB["ALB<br/>(443/80)"]
    ALB -->|"Target Group"| Task1["Task (AZ-a)"]
    ALB -->|"Target Group"| Task2["Task (AZ-b)"]
    ALB -->|"Target Group"| Task3["Task (AZ-a)"]
    Task1 --> RDS["RDS Aurora"]
    Task2 --> RDS
    Task3 --> RDS
    Task1 -.-> SM["Secrets Manager"]
    Task2 -.-> SM

ALB 가 Task IP 를 직접 Target 으로 등록 (awsvpc network mode)
Service 가 새 Task 등록 / 구 Task 드레이닝 자동 처리
Draining 기간: 기본 300초 (graceful shutdown)

Service Auto Scaling

# Target Tracking (권장)
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id "service/prod/web" \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 20

aws application-autoscaling put-scaling-policy \
  --policy-name "cpu-tracking" \
  --service-namespace ecs \
  --resource-id "service/prod/web" \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 30
  }'

스케일링 타입	특성	사용 케이스
Target Tracking	목표값 유지 자동	기본 선택 (CPU 70% 유지)
Step Scaling	지표 임계값별 단계	정밀 제어 필요 시
Scheduled	시간표 기반	예측 가능한 트래픽 패턴

ECR 연동

# ECR 로그인
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin 123.dkr.ecr.us-east-1.amazonaws.com

# 이미지 빌드 + 푸시
docker build -t web:latest .
docker tag web:latest 123.dkr.ecr.us-east-1.amazonaws.com/web:latest
docker push 123.dkr.ecr.us-east-1.amazonaws.com/web:latest

# 새 Task Definition revision 으로 서비스 업데이트
aws ecs update-service \
  --cluster prod \
  --service web \
  --task-definition web:43 \
  --force-new-deployment

Blue/Green 배포 (CodeDeploy)

sequenceDiagram
    participant CD as CodeDeploy
    participant ALB
    participant Blue as "Blue (구 버전)"
    participant Green as "Green (신 버전)"

    CD->>Green: "새 Task 시작"
    CD->>ALB: "Test listener (8080) -> Green"
    Note over CD: "스모크 테스트"
    CD->>ALB: "Production listener (443) -> Green"
    CD->>Blue: "드레이닝 후 종료"

deploymentController: type: CODE_DEPLOY 로 ALB 두 Target Group 사용. 롤백 1초.

ECS Anywhere

온프레미스 서버나 Edge 머신을 ECS 클러스터에 등록해 관리.

# ECS Anywhere 에이전트 설치 스크립트 생성
aws ecs create-cluster --cluster-name hybrid-cluster
aws ssm create-activation \
  --default-instance-name "on-prem-node" \
  --iam-role ECSAnywhereInstanceRole \
  --registration-limit 5

ECS vs EKS 선택 기준

항목	ECS	EKS
학습 곡선	낮음	높음
AWS 종속성	높음	낮음
K8s 이식성	없음	높음
운영 복잡도	낮음	높음 (Control plane 관리)
Cluster 비용	무료	$0.10/시간
Ecosystem	제한적	방대 (Helm, Operator 등)
적합	AWS 네이티브, 빠른 시작	멀티 클라우드, 표준화, 큰 규모

함정

[!WARNING] Fargate Spot 중단 대응 미흡: 2분 전 SIGTERM 보내고 중단. 컨테이너가 SIGTERM 처리 안 하면 데이터 손실. Graceful shutdown 구현 필수.

[!CAUTION] awsvpc 네트워크 모드 ENI 한도: EC2 launch type 시 인스턴스 타입별 ENI 수 제한. c5.large 는 ENI 3개 = Task 3개 상한. 인스턴스 타입 선택 시 ENI 한도 확인.

[!WARNING] CloudWatch Logs 비용: 모든 컨테이너 로그가 CloudWatch Logs 로. 고트래픽 서비스에서 로그 비용이 컴퓨팅 비용 초과 가능. fluent-bit sidecar + S3/OpenSearch 로 라우팅 권장.

[!CAUTION] Task Definition secrets 키 오타: secrets 필드에 Secrets Manager ARN 오타 시 Task 시작 실패 (ECS_EXEC 로 디버깅). executionRole 에 secretsmanager:GetSecretValue 권한 필요.

[!WARNING] Service 업데이트 후 롤링 지연: minimumHealthyPercent=100 + maximumPercent=200 시 기존 Task 유지 + 새 Task 추가 후 헬스체크 통과하면 구 Task 종료. 헬스체크가 길면 배포 느림.

[!IMPORTANT] Fargate Task 시작 지연: 첫 Task 시작에 10-30초 소요 (이미지 풀 포함). [[aws-auto-scaling|Auto Scaling]] 반응 시간 고려, 사전에 여유 Task 유지.

[AWS] Secrets Manager + Parameter Store

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

AWS Secrets Manager = 회전이 필요한 비밀 (DB 패스워드, API key) 을 안전하게 저장/관리하는 서비스. Lambda 기반 자동 회전과 [[aws-kms]] 암호화 내장.

Parameter Store (SSM) = 설정값 + 비밀값의 계층형 저장소. 대부분 무료, 간단한 구성 관리에 적합.

Secrets Manager vs Parameter Store

항목	Secrets Manager	Parameter Store
가격	$0.40/secret/월 + $0.05/10k API	Standard 무료, Advanced $0.05/1만
자동 회전	내장 (Lambda)	아니오
버전 관리	자동 (AWSPENDING / AWSCURRENT / AWSPREVIOUS)	수동
크기 제한	64 KB	4 KB (standard) / 8 KB (advanced)
[[aws-kms]] 암호화	기본 적용	SecureString 타입만
타입	JSON / 문자열	String / StringList / SecureString
교차 계정	가능	제한적
RDS 통합	내장 rotation	수동

어떤 걸 언제 쓸까?

flowchart TD
    Q{"비밀의 종류"}
    Q -->|"DB password / API key (자동 회전 필요)"| SM["Secrets Manager"]
    Q -->|"앱 설정값, feature flag"| PS["Parameter Store Standard"]
    Q -->|"암호화 필요한 설정값"| PSSec["Parameter Store SecureString"]
    Q -->|"크기 > 4KB (인증서 등)"| SM
    SM --> Cost["$0.40/secret/월"]
    PS --> Free["무료"]
    PSSec --> KMSCost["KMS 비용만"]

Secrets Manager: 기본 사용

Secret 저장

# JSON 형식 (DB 자격증명)
aws secretsmanager create-secret \
  --name "prod/db/credentials" \
  --description "RDS Aurora production" \
  --secret-string '{"username":"admin","password":"s3cr3t"}'

# 회전 주기 설정 (30일)
aws secretsmanager rotate-secret \
  --secret-id "prod/db/credentials" \
  --rotation-rules AutomaticallyAfterDays=30

Secret 조회

import boto3, json

sm = boto3.client('secretsmanager', region_name='us-east-1')

def get_secret(secret_name: str) -> dict:
    response = sm.get_secret_value(SecretId=secret_name)
    return json.loads(response['SecretString'])

creds = get_secret('prod/db/credentials')
db_password = creds['password']

[!IMPORTANT] 매 요청마다 API 호출 금지. 애플리케이션 시작 시 캐싱 후 TTL 기반 갱신 권장.

Secret 캐싱 패턴

from aws_secretsmanager_caching import SecretCache

cache = SecretCache()   # 기본 TTL 3600초

def get_cached_secret(name: str) -> str:
    return cache.get_secret_string(name)

aws-secretsmanager-caching 라이브러리가 공식 지원. Lambda 에서 전역 캐시로 콜드 스타트 이후 재사용.

자동 회전 흐름

sequenceDiagram
    participant SM as Secrets Manager
    participant L as Rotation Lambda
    participant DB as 데이터베이스
    participant App as 애플리케이션

    Note over SM: 30일 경과 / 수동 트리거
    SM->>L: createSecret (AWSPENDING 생성)
    L->>DB: 새 패스워드 생성 요청
    DB-->>L: OK
    SM->>L: setSecret (DB 에 새 패스워드 적용)
    L->>DB: ALTER USER ... PASSWORD
    SM->>L: testSecret (새 패스워드 검증)
    L->>DB: 로그인 테스트
    SM->>L: finishSecret (AWSCURRENT 교체)
    Note over SM: AWSPENDING -> AWSCURRENT
    Note over SM: 구 AWSCURRENT -> AWSPREVIOUS
    App->>SM: GetSecretValue (AWSCURRENT 조회)
    SM-->>App: 새 패스워드

버전 레이블

레이블	의미
`AWSPENDING`	회전 준비 중인 새 값
`AWSCURRENT`	현재 활성 값
`AWSPREVIOUS`	직전 값 (롤백 보험)

RDS 자동 회전 설정

# RDS MySQL 자동 회전 활성화
aws secretsmanager rotate-secret \
  --secret-id "prod/rds/mysql" \
  --rotation-lambda-arn "arn:aws:lambda:us-east-1:123:function:SecretsManagerRDSMySQLRotationSingleUser" \
  --rotation-rules '{"AutomaticallyAfterDays": 30}'

AWS 가 지원하는 내장 rotation Lambda:

SecretsManagerRDSMySQLRotationSingleUser
SecretsManagerRDSPostgreSQLRotationSingleUser
SecretsManagerRDSAuroraRotation
SecretsManagerRedshiftRotation

IAM 접근 제어

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSecretOnly",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:123:secret:prod/*"
    }
  ]
}

[!CAUTION] secretsmanager:* 권한 금지. 최소 권한으로 GetSecretValue 만 부여. secret ARN 패턴으로 범위 제한.

Parameter Store: 계층 구조

# 계층형 경로로 환경별 설정 관리
/prod/app/db/host
/prod/app/db/port
/prod/app/api/key      # SecureString
/staging/app/db/host
/dev/app/db/host

# 경로 아래 모든 파라미터 조회
aws ssm get-parameters-by-path \
  --path /prod/app \
  --recursive \
  --with-decryption    # SecureString 복호화

Parameter 타입

# String (평문)
aws ssm put-parameter \
  --name "/prod/app/db/host" \
  --value "db.prod.internal" \
  --type String

# SecureString (KMS 암호화)
aws ssm put-parameter \
  --name "/prod/app/api/key" \
  --value "sk-xxxx" \
  --type SecureString \
  --key-id "alias/prod-params"

# StringList (쉼표 구분)
aws ssm put-parameter \
  --name "/prod/app/allowed-ips" \
  --value "10.0.0.1,10.0.0.2" \
  --type StringList

EKS 통합 패턴

패턴	도구	특징
K8s Secret 으로 sync	External Secrets Operator	GitOps 친화
Pod 에 파일로 마운트	Secrets Store CSI Driver	파일 마운트
코드에서 직접 조회	AWS SDK + IRSA	단순, 캐싱 주의

# External Secrets Operator 예시
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: prod/db/credentials
        property: password

Cross-region 복제

# Secret 을 다른 리전에 복제
aws secretsmanager replicate-secret-to-regions \
  --secret-id "prod/db/credentials" \
  --add-replica-regions '[{"Region":"eu-west-1"}]'

리전 장애 시에도 비밀 접근 유지. 복제된 시크릿은 읽기 전용 (쓰기는 primary 에만).

비용 최적화

방법	절감 효과
Parameter Store Standard 사용	비밀이 아닌 설정값에 무료
Secret 캐싱 라이브러리	API 호출 수 대폭 감소
공유 Secret 사용	여러 환경 값 JSON 으로 통합
TTL 기반 갱신	불필요한 빈번 조회 방지

대안 비교

솔루션	특성	적합한 경우
Secrets Manager	자동 회전, 관리형	AWS 네이티브, 멀티 서비스
Parameter Store	저렴, 계층형	설정값, feature flag
HashiCorp Vault	멀티 클라우드, 세밀한 정책	멀티 클라우드, 복잡한 정책
환경 변수 (직접)	단순	개발 환경 한정

함정

[!WARNING] Hardcoded fallback 금지: 코드에 평문 비밀값 절대 금지. 코드베이스 검색으로 password = 같은 패턴 CI 차단.

[!WARNING] 회전 실패 모니터링 부재: rotation Lambda 실패 시 AWSPENDING 상태 고착, 서비스 다운 위험. CloudWatch Alarm + SNS 알림 필수.

# 회전 실패 CloudWatch Alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "secrets-rotation-failure" \
  --metric-name "RotationFailed" \
  --namespace "AWS/SecretsManager" \
  --statistic Sum \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions "arn:aws:sns:us-east-1:123:alerts"

[!CAUTION] Cross-region 없이 단일 리전: Secret 은 리전별 서비스. 리전 장애 = 비밀 접근 불가. 크리티컬 서비스는 multi-region 복제.

[!WARNING] Parameter Store 4KB 한도: 인증서, 큰 JSON 설정은 Advanced (8KB) 또는 Secrets Manager (64KB) 사용.

[!CAUTION] 매 요청마다 GetSecretValue 호출: Lambda 가 요청마다 API 호출 시 throttling + 비용 폭증. 전역 캐시 또는 공식 캐싱 라이브러리 필수.

[!WARNING] Secret 삭제 즉시 불가: DeleteSecret 기본 복구 기간 30일. 즉시 삭제는 --force-delete-without-recovery 옵션 필요.

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

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

AWS VPC 에는 두 계층의 네트워크 방화벽이 존재.

항목	SG (Security Group)	NACL (Network ACL)
상태	Stateful	Stateless
적용 레벨	ENI / 인스턴스	Subnet
규칙 종류	Allow 만	Allow + Deny
규칙 평가	모든 규칙 종합	번호 순 (첫 매칭)
기본 Inbound	deny all	allow all
기본 Outbound	allow all	allow all
반환 트래픽	자동 허용	명시적 설정 필요

Stateful vs Stateless 심화

Stateful: Security Group

sequenceDiagram
    Client->>SG: "TCP SYN (port 80, inbound)"
    SG->>Server: forward (inbound rule 일치)
    Note over SG: "connection 상태 추적"
    Server->>SG: "TCP SYN-ACK (ephemeral port, outbound)"
    SG-->>Client: "forward (상태 추적, outbound 규칙 검사 안 함)"

SG 는 연결 상태를 추적. Inbound 를 허용하면 그 연결의 응답은 자동으로 허용. Outbound 규칙을 닫아도 기존 연결 응답은 통과.

Stateless: NACL

sequenceDiagram
    Client->>NACL: "TCP SYN (port 443, inbound)"
    NACL->>Server: "inbound rule 100: allow 443 -> 통과"
    Server->>NACL: "TCP SYN-ACK (ephemeral port 32768, outbound)"
    NACL->>NACL: "outbound rule 검사: 1024-65535 허용? -> 확인"
    NACL-->>Client: "outbound rule 있어야 통과"

NACL 은 각 패킷을 독립적으로 검사. 응답 트래픽도 별도 outbound rule 필요. 특히 ephemeral port 처리가 핵심.

Ephemeral Port 이해

클라이언트가 서버에 요청할 때 임시 포트를 사용:

Linux: 32768-60999
Windows: 49152-65535
AWS 권장: 1024-65535

# NACL Outbound rule (올바른 설정)
Rules:
  - RuleNumber: 100
    Direction: outbound
    Action: allow
    Protocol: tcp
    PortRange: { From: 1024, To: 65535 }   # ephemeral ports
    CidrBlock: 0.0.0.0/0

# 이것만 있으면 Inbound 요청의 응답도 통과

[!WARNING] NACL 에서 ephemeral port 누락 = 응답이 차단. NACL outbound 에 반드시 1024-65535 포트 범위 허용 규칙 추가.

Security Group 규칙

기본 설정 패턴

# 웹 서버 Security Group
WebServerSG:
  Inbound:
    - Protocol: tcp
      Port: 443
      CidrIp: 0.0.0.0/0         # 인터넷에서 HTTPS
    - Protocol: tcp
      Port: 80
      CidrIp: 0.0.0.0/0         # 인터넷에서 HTTP (리다이렉트용)
  Outbound:
    - Protocol: -1               # 모든 아웃바운드 (기본)
      CidrIp: 0.0.0.0/0

# DB 서버 Security Group
DatabaseSG:
  Inbound:
    - Protocol: tcp
      Port: 5432
      SourceSecurityGroupId: sg-webserver   # 웹 SG 에서만 PostgreSQL
  Outbound:
    - Protocol: -1
      CidrIp: 0.0.0.0/0

SG Referencing SG (핵심 기능)

IP 대신 다른 SG 를 source/destination 으로 지정. Dynamic IP 환경에서 강력.

DatabaseSG:
  Inbound:
    - Protocol: tcp
      Port: 5432
      SourceSecurityGroupId: sg-app         # app SG 가진 ENI 만 허용

flowchart LR
    AppInstance["앱 EC2<br/>sg-app"] -->|"port 5432"| DB["RDS<br/>sg-db"]
    DB -.->|"sg-app 만 허용"| DB
    Internet["인터넷"] -.-x|"차단"| DB

Auto Scaling 으로 앱 인스턴스 IP 가 변해도 sg-app 이 붙어있으면 자동 허용. IP 추적 불필요.

NACL 규칙 작성

번호 순 평가

NACL Inbound Rules:
  RuleNumber: 100
    Action: ALLOW
    Protocol: tcp
    PortRange: 443
    CidrBlock: 0.0.0.0/0

  RuleNumber: 200
    Action: ALLOW
    Protocol: tcp
    PortRange: 1024-65535    # ephemeral ports (응답)
    CidrBlock: 0.0.0.0/0

  RuleNumber: 300
    Action: DENY
    CidrBlock: 1.2.3.4/32   # 악의적 IP 차단

  RuleNumber: 32767
    Action: DENY
    Protocol: -1             # 기본 모두 차단
    CidrBlock: 0.0.0.0/0

[!IMPORTANT] 번호가 낮을수록 먼저 평가. 첫 번째 일치 규칙으로 결정. 100번에 ALLOW, 200번에 같은 IP 의 DENY 가 있으면 100번 ALLOW 가 우선.

특정 IP 차단 (NACL 만 가능)

NACL Rules:
  RuleNumber: 50
    Action: DENY
    CidrBlock: 1.2.3.0/24   # 악성 IP 범위 차단
  RuleNumber: 100
    Action: ALLOW
    CidrBlock: 0.0.0.0/0    # 나머지 허용

SG 는 Allow 만 지원하므로 특정 IP 차단에는 NACL 사용.

패킷 흐름: 전체 평가 순서

flowchart TD
    Internet["인터넷"] -->|"요청"| NACL_In["NACL Inbound<br/>(번호 순 평가)"]
    NACL_In -->|"ALLOW"| SG_In["SG Inbound<br/>(모든 규칙 종합)"]
    SG_In -->|"ALLOW"| Instance["EC2 / RDS"]
    Instance -->|"응답"| SG_Out["SG Outbound<br/>(stateful - 자동)"]
    SG_Out -->|"ALLOW"| NACL_Out["NACL Outbound<br/>(번호 순, ephemeral)"]
    NACL_Out -->|"ALLOW"| Internet

패킷이 통과하려면 NACL + SG 모두 통과해야 함.

레이어드 보안 설계

[인터넷]
    |
[NACL - subnet 경계]
 - 악성 IP 차단 (Deny)
 - 허용 포트 제한
    |
[Security Group - 인스턴스 경계]
 - 세밀한 포트 제어
 - SG-to-SG 참조
    |
[EC2/RDS/Lambda]

실전 사용 패턴:

NACL: subnet 레벨 coarse-grained 제어, 악성 IP 차단, 간단한 화이트리스트
SG: 인스턴스 레벨 fine-grained 제어, SG 참조, 대부분의 방화벽 규칙

변경 즉시 반영

SG 변경: 즉시 반영. 새로운 연결에 바로 적용. 기존 연결은 stateful 로 유지.

NACL 변경: 즉시 반영. 단, 기존 연결의 다음 패킷부터.

# SG 인바운드 규칙 추가
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# NACL 규칙 추가
aws ec2 create-network-acl-entry \
  --network-acl-id acl-12345 \
  --rule-number 100 \
  --protocol 6 \
  --rule-action allow \
  --ingress \
  --port-range From=443,To=443 \
  --cidr-block 0.0.0.0/0

Session Manager vs SSH: SG 설계

[!IMPORTANT] SSH 포트 22 를 인터넷에 오픈하지 말 것. AWS Systems Manager Session Manager 사용 시 SSH 포트 전혀 불필요.

# 잘못된 설계 (SSH 공개)
IngressRules:
  - Port: 22, CidrIp: 0.0.0.0/0   # 즉시 공격 대상

# 올바른 설계 (Session Manager)
IngressRules: []                    # 인바운드 없음
EgressRules:
  - Port: 443, CidrIp: 0.0.0.0/0  # SSM endpoint 접근용

비용

SG 와 NACL 모두 추가 비용 없음. VPC 의 기본 포함 기능.

함정

[!WARNING] NACL ephemeral port 누락: Stateless NACL 에서 응답 포트 (1024-65535) outbound 허용 없으면 응답 차단. SG 는 자동이지만 NACL 은 수동.

[!WARNING] SG outbound 모두 닫기: 일반적으로 outbound 는 모두 허용. 닫으면 외부 API 호출, DNS 조회 모두 차단. stateful 이므로 inbound 응답은 별개.

[!CAUTION] 너무 넓은 0.0.0.0/0 inbound: SSH/RDP 를 인터넷에 열면 즉시 brute force 공격 대상. Session Manager, Bastion Host, IP 제한 중 선택.

[!WARNING] SG 변경 후 기존 연결: SG 는 stateful 이므로 규칙 변경 후에도 기존 연결은 유지. 즉시 차단이 필요하면 인스턴스 재시작 또는 연결 강제 종료.

[!CAUTION] NACL 규칙 번호 간격: 10, 20, 30 처럼 촘촘하게 쓰면 중간 삽입 불가. 100, 200, 300 처럼 여유있게 번호 부여.

[!WARNING] SG 규칙 상한: 기본 60개 inbound + 60개 outbound. 너무 세분화된 규칙은 SG 여러 개로 분리하거나 NACL 사용.

[AWS] SNS: pub-sub 알림, fan-out 패턴

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

SNS (Simple Notification Service) = pub-sub 메시징. Publisher 가 Topic 에 발행하면 모든 Subscriber 에 동시에 fan-out. 알림, 이벤트 배포, 마이크로서비스 디커플링에 활용.

구조

{}

flowchart LR
    P["Publisher<br/>(앱, AWS 서비스)"] -->|"Publish"| Topic["SNS Topic"]
    Topic --> S1["SQS Queue"]
    Topic --> S2["Lambda"]
    Topic --> S3["Email"]
    Topic --> S4["SMS / Mobile Push"]
    Topic --> S5["HTTP/HTTPS"]
    Topic --> S6["Kinesis Firehose"]

핵심: SNS 자체는 메시지를 저장하지 않음. 전달 후 소멸. 내구성 필요하면 SQS 구독.

Subscriber 종류

종류	사용 케이스	내구성
[[aws-sqs	SQS]]	큐 fan-out, 내구성
[[aws-lambda	Lambda]]	비동기 처리
Email	운영 알림	낮음
SMS	모바일 알림	낮음
Mobile Push	APNS, FCM	낮음
HTTP/HTTPS	Webhook	낮음
Kinesis Firehose	데이터 파이프라인	높음

Standard vs FIFO Topic

항목	Standard Topic	FIFO Topic
메시지 순서	best-effort	엄격 (MessageGroupId)
중복	가능	5분 중복 제거
처리량	무제한 (초당 수십만)	300 TPS
구독 가능 타입	전부	SQS FIFO 만
이름 접미사	없음	`.fifo` 필수
비용	표준	약간 높음

# FIFO Topic 생성
aws sns create-topic \
  --name "OrderEvents.fifo" \
  --attributes '{"FifoTopic":"true","ContentBasedDeduplication":"true"}'

Message Filtering

Subscriber 마다 FilterPolicy 로 받을 메시지 선택. Topic 이 전부 보내도 필터에 맞는 것만 전달.

{
  "FilterPolicy": {
    "event_type": ["order.created", "order.paid"],
    "region": ["us-east-1", "us-west-2"],
    "amount": [{ "numeric": [">", 100] }]
  }
}

flowchart LR
    Topic["SNS Topic"] --> S1["SQS: 주문처리<br/>event_type=[order.created]"]
    Topic --> S2["SQS: 정산<br/>event_type=[order.paid]"]
    Topic --> S3["Lambda: 분석<br/>필터 없음 (전부)"]

FilterPolicy 매칭 방식:

문자열 정확 일치: ["value1", "value2"]
숫자 범위: [{"numeric": [">", 100, "<=", 500]}]
prefix 매칭: [{"prefix": "order."}]
exists: [{"exists": true}]
필터 없음: 모든 메시지 수신

[!WARNING] FilterPolicy 잘못 설정 시 메시지 silently drop. CloudWatch NumberOfNotificationsFilteredOut 메트릭 모니터링 필수.

SNS + SQS Fan-out 패턴

SNS 의 fan-out + SQS 의 내구성 결합. 가장 많이 쓰이는 패턴.

flowchart LR
    OrderSvc["Order Service"] -->|"OrderCreated 이벤트"| Topic["SNS Topic"]
    Topic --> Q1["SQS: 배송처리"]
    Topic --> Q2["SQS: 분석"]
    Topic --> Q3["SQS: 알림"]
    Q1 --> ShippingLambda["배송 처리 Lambda"]
    Q2 --> AnalyticsLambda["분석 Lambda"]
    Q3 --> NotifyLambda["알림 Lambda"]

이점:

독립 스케일링: 각 SQS / Lambda 독립 처리
내구성: SQS 에 메시지 보존, 처리 실패 시 재시도
디커플링: Order Service 는 하위 서비스 모름
DLQ: 각 SQS 에 Dead Letter Queue 연결 가능

Dead Letter Queue 설정

# SNS Subscription 에 DLQ 설정
aws sns set-subscription-attributes \
  --subscription-arn "arn:aws:sns:..." \
  --attribute-name RedrivePolicy \
  --attribute-value '{
    "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123:sns-dlq"
  }'

DLQ 는 전달 실패 메시지 보관. 실패 원인 분석 후 재처리.

Lambda 통합: 동시성 주의

sequenceDiagram
    participant SNS
    participant Lambda

    SNS->>Lambda: 배치 (최대 10,000 메시지 burst)
    Lambda-->>SNS: 처리 중 (동시 실행 증가)
    Note over Lambda: 계정 동시성 한도 도달 시 throttling
    SNS->>Lambda: 재시도 (exponential backoff)
    Note over SNS: 최대 3번 재시도, 실패 시 DLQ

[!CAUTION] SNS -> Lambda 직접 연결 시 대량 메시지에 Lambda 동시성 폭증. SQS 버퍼를 중간에 넣어 조절 권장.

HTTP 구독: 서명 검증

SNS 는 HTTP endpoint 에 메시지 전송 시 서명 포함.

import json, base64, urllib.request
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding

def verify_sns_signature(message: dict) -> bool:
    # SigningCertURL 에서 인증서 다운로드
    cert_url = message['SigningCertURL']
    # SNS URL 검증
    assert cert_url.startswith('https://sns.'), "Invalid cert URL"
    # 서명 검증 (cryptography 라이브러리 사용)
    ...

[!WARNING] HTTP endpoint 는 SNS 인척 위조 가능. 반드시 SNS 서명 검증 구현.

메시지 구조

{
  "Type": "Notification",
  "MessageId": "12345",
  "TopicArn": "arn:aws:sns:us-east-1:123:OrderEvents",
  "Subject": "Order Created",
  "Message": "{\"orderId\":\"o-001\",\"amount\":150}",
  "Timestamp": "2026-07-15T10:00:00.000Z",
  "MessageAttributes": {
    "event_type": {
      "Type": "String",
      "Value": "order.created"
    }
  }
}

Raw Message Delivery: SQS / HTTP 구독에서 SNS 래퍼 없이 원본 메시지만 전달. SQS 에서 json.loads 두 번 하는 실수 방지.

# Raw delivery 활성화
aws sns set-subscription-attributes \
  --subscription-arn "arn:aws:sns:..." \
  --attribute-name RawMessageDelivery \
  --attribute-value true

비용 구조

항목	비용
API 요청 (Publish)	$0.50/million
SQS 전달	무료
Lambda 전달	무료
Email 전달	처음 1,000 건 무료, 이후 $2/100k
SMS (한국)	$0.0843/건
HTTP/HTTPS 전달	처음 100k 건 무료, 이후 $0.60/million
Mobile Push	처음 100만 건 무료

비용 최적화:

SQS/Lambda 구독 선호 (무료)
SMS 는 Direct SMS 대신 SNS + Mobile Push 고려
Message Filtering 으로 불필요한 메시지 전달 줄임

서비스	특성	적합한 경우
SNS	단순 fan-out, 저렴, 고처리량	알림 발송, fan-out
**[[aws-eventbridge	EventBridge]]**	복잡한 라우팅, schema registry, SaaS 통합
**[[aws-sqs	SQS]]**	큐, pull 기반, 내구성
Kinesis	스트리밍, 재처리 가능	대용량 스트림, 분석

실전 선택 기준:

단순 알림 / 높은 fan-out -> SNS
복잡한 이벤트 라우팅 / 외부 SaaS 연동 -> EventBridge
순서 보장 / 내구성 / consumer 속도 제어 -> SQS

실전 패턴: 주문 이벤트 처리

import boto3

sns = boto3.client('sns')

def publish_order_event(order_id: str, event_type: str, amount: float):
    sns.publish(
        TopicArn='arn:aws:sns:us-east-1:123:OrderEvents',
        Message=json.dumps({
            'orderId': order_id,
            'amount': amount
        }),
        Subject=event_type,
        MessageAttributes={
            'event_type': {
                'DataType': 'String',
                'StringValue': event_type
            },
            'amount': {
                'DataType': 'Number',
                'StringValue': str(amount)
            }
        }
    )

함정

[!WARNING] HTTP subscriber 서명 검증 누락: SNS 에서 온 척 위조 webhook 가능. 반드시 SigningCertURL 에서 인증서 받아 서명 검증.

[!WARNING] Standard topic 중복 메시지: at-least-once 전달. Subscriber 는 idempotent 로 설계. MessageId 로 중복 처리.

[!CAUTION] SNS -> Lambda 직접: 동시성 폭증: 대량 이벤트 시 Lambda 동시성 한도 초과. SQS 버퍼 삽입으로 back-pressure 적용.

[!WARNING] DLQ 미설정: 전달 실패 메시지 손실. SNS Subscription 에 SQS DLQ 설정 필수.

[!CAUTION] FIFO Topic - SQS FIFO 만 구독 가능: Email, HTTP, Lambda, SMS 는 FIFO Topic 구독 불가. FIFO 순서 보장 필요 시 SQS FIFO 경유.

[!WARNING] FilterPolicy 비어있음 vs 없음: {} (빈 FilterPolicy) = 모든 메시지 차단. Attribute 없는 메시지도 차단. 없애거나 속성이 없어도 통과하도록 설정.

[AWS] CloudFormation

koa (김신건) — Tue, 14 Jul 2026 00:00:00 GMT

정의

AWS CloudFormation 은 JSON 또는 YAML 템플릿으로 AWS 인프라를 선언적으로 프로비저닝하는 IaC (Infrastructure as Code) 서비스입니다. 원하는 최종 상태를 기술하면 CloudFormation 이 생성/수정/삭제를 순서에 맞게 자동으로 수행합니다.

한 줄 요약: “YAML/JSON 로 AWS 리소스를 선언하면, CloudFormation 이 의존성을 분석해 올바른 순서로 만들어준다”.

왜 CloudFormation 인가

수동 콘솔 조작의 문제

재현 불가: 콘솔 클릭 내용은 기억 의존. 새 환경 구성 매번 다르게 됨
드리프트: 누군가 콘솔에서 수정 → 개발/스테이징/프로덕션 환경 간 차이 발생
감사 어려움: 누가 언제 무엇을 바꿨는지 추적 불가
삭제 어려움: 어떤 리소스가 세트인지 몰라 삭제 시 일부 누락

CloudFormation 접근

코드로 상태 관리: Git 저장소에 템플릿 → 버전 관리 + PR 리뷰
반복 가능한 배포: 같은 템플릿으로 Dev / Staging / Prod 동일하게 구성
Drift Detection: 실제 상태와 템플릿 차이 자동 감지
Rollback: 업데이트 실패 시 이전 상태 자동 복원
의존성 자동 처리: RDS 가 VPC 보다 먼저 생성되지 않도록 자동 순서 결정

핵심 개념

Stack

CloudFormation 의 배포 + 관리 단위. 하나의 템플릿이 하나의 Stack 에 대응.

리소스들을 하나의 단위로 생성 / 수정 / 삭제
Stack 삭제 → 포함된 모든 리소스 삭제 (DeletionPolicy: Retain 예외)
Stack 이름은 리전 내 고유

Stack 상태:

상태	의미
`CREATE_COMPLETE`	생성 완료
`UPDATE_IN_PROGRESS`	업데이트 중
`UPDATE_ROLLBACK_COMPLETE`	업데이트 실패, 롤백 완료
`DELETE_FAILED`	삭제 실패 (리소스 의존성 등)

StackSet

여러 AWS 계정 + 여러 리전 에 동일 스택 배포. 조직 전체 보안 기준선 적용에 활용.

Management Account (Admin)
├── StackSet "SecurityBaseline"
│   ├── Account A, us-east-1
│   ├── Account A, ap-northeast-2
│   ├── Account B, us-east-1
│   └── Account B, ap-northeast-2

AWS Organizations 통합 시 신규 계정 자동 포함 가능.

ChangeSet

배포 전 변경 미리보기. 실제 적용 전에 “무엇이 어떻게 바뀌는지” 확인.

# ChangeSet 생성
aws cloudformation create-change-set \
  --stack-name my-stack \
  --template-body file://template.yaml \
  --change-set-name my-changes

# 변경 내용 확인
aws cloudformation describe-change-set --change-set-name my-changes

# 실제 적용
aws cloudformation execute-change-set --change-set-name my-changes

CI/CD 파이프라인에서 ChangeSet 생성 → 검토 게이트 → Execute 흐름을 권장합니다.

아키텍처 / 라이프사이클

flowchart LR
  Template["YAML / JSON 템플릿"] -->|create-stack| CFN["CloudFormation"]
  CFN -->|프로비저닝| Resources["AWS 리소스들"]
  Resources -.->|"Drift Detection"| CFN
  CFN -->|update-stack| Resources
  CFN -->|delete-stack| Delete["리소스 삭제"]

StackSet 배포 구조

flowchart TD
  Admin["Management Account"] -->|StackSet| SA["Stack Instance A<br/>계정 111"]
  Admin -->|StackSet| SB["Stack Instance B<br/>계정 222"]
  Admin -->|StackSet| SC["Stack Instance C<br/>계정 333"]
  SA --> ResA[리소스들]
  SB --> ResB[리소스들]
  SC --> ResC[리소스들]

템플릿 구조

AWSTemplateFormatVersion: '2010-09-09'
Description: '앱 인프라 스택'

# 배포 시 입력 받는 파라미터
Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, staging, prod]
    Default: dev
  InstanceType:
    Type: String
    Default: t3.small

# 조건식 (Intrinsic Function 조합)
Conditions:
  IsProd: !Equals [!Ref Environment, prod]

# 필수 섹션: 실제 리소스 정의
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub '${AWS::StackName}-data-${AWS::Region}'
      VersioningConfiguration:
        Status: !If [IsProd, Enabled, Suspended]
    DeletionPolicy: Retain   # 스택 삭제 시 버킷 보존

  LambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: !Sub '${AWS::StackName}-handler'
      Runtime: nodejs20.x
      Handler: index.handler
      Code:
        S3Bucket: !Ref MyBucket
        S3Key: lambda.zip
      Role: !GetAtt LambdaRole.Arn   # 다른 리소스 속성 참조
    DependsOn: LambdaRole

# 다른 스택에서 참조할 수 있도록 내보내기
Outputs:
  BucketName:
    Value: !Ref MyBucket
    Export:
      Name: !Sub '${AWS::StackName}-BucketName'
  FunctionArn:
    Value: !GetAtt MyFunction.Arn

Intrinsic Functions

함수	용도	예시
`!Ref`	리소스 ID / 파라미터 값 참조	`!Ref MyBucket`
`!GetAtt`	리소스 속성 참조	`!GetAtt LambdaRole.Arn`
`!Sub`	문자열 치환 (변수 포함)	`!Sub '${AWS::StackName}-bucket'`
`!If`	조건 분기	`!If [IsProd, Enabled, Disabled]`
`!Join`	문자열 결합	`!Join ['-', [a, b, c]]`
`!Select`	목록에서 선택	`!Select [0, !GetAZs '']`
`!ImportValue`	다른 스택 Output 참조	`!ImportValue OtherStack-BucketName`
`!Split`	문자열 분리	`!Split [',', !Ref CsvList]`
`!FindInMap`	Mappings 섹션 값 조회	`!FindInMap [RegionMap, !Ref AWS::Region, AMI]`

Pseudo Parameters (자동 제공)

${AWS::AccountId}: 현재 계정 ID
${AWS::Region}: 현재 리전
${AWS::StackName}: 현재 스택 이름
${AWS::StackId}: 스택 ARN
${AWS::NoValue}: 속성 제거 (Condition 과 함께 사용)

Drift Detection

Drift: 템플릿 정의와 실제 리소스 상태의 차이.

# Drift 감지 시작
aws cloudformation detect-stack-drift --stack-name my-stack

# 감지 상태 확인
aws cloudformation describe-stack-drift-detection-status \
  --stack-drift-detection-id <id>

# 드리프트된 리소스 상세 보기
aws cloudformation describe-stack-resource-drifts --stack-name my-stack

Drift 주요 원인:

누군가 AWS 콘솔에서 수동으로 설정 변경
외부 스크립트 / Terraform 등 다른 도구로 리소스 수정
AWS 서비스 자동 업데이트

[!IMPORTANT] Drift 감지는 자동 아님. 수동 실행 또는 Lambda + EventBridge 로 주기적 스캔 설정 필요.

Rollback

스택 업데이트 중 실패 → 이전 상태 자동 복원 (기본).

주요 상태 전이:

UPDATE_IN_PROGRESS → 실패 → UPDATE_ROLLBACK_IN_PROGRESS → UPDATE_ROLLBACK_COMPLETE
UPDATE_ROLLBACK_FAILED: 롤백 자체도 실패. continue-update-rollback 명령 + 수동 복구 필요.

DisableRollback 옵션으로 실패 시 리소스 보존 가능 (디버그용, 프로덕션 비권장).

Nested Stacks vs Cross-Stack References

Nested Stacks

부모 스택이 자식 스택을 리소스로 포함하는 방식:

# parent-stack.yaml
Resources:
  NetworkStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/my-bucket/network.yaml

  AppStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/my-bucket/app.yaml
      Parameters:
        VpcId: !GetAtt NetworkStack.Outputs.VpcId

장점: 단일 배포 단위, 부모 업데이트로 전체 라이프사이클 관리. 단점: 중첩 깊이 제한 (10 수준), 자식 스택도 스택 한도 (2000개/리전) 에 포함.

Cross-Stack References

별도 스택 간 Export / ImportValue 로 값 전달:

# network-stack.yaml Outputs
Outputs:
  VpcId:
    Value: !Ref MyVPC
    Export:
      Name: !Sub '${AWS::StackName}-VpcId'

# app-stack.yaml
Resources:
  MyInstance:
    Properties:
      VpcId: !ImportValue 'network-stack-VpcId'

장점: 스택 독립 배포, 팀별 소유권 분리, 변경 충격 격리. 단점: 다른 스택이 ImportValue 중인 Export 삭제 불가, 리전 간 교차 참조 불가.

CDK 와의 관계

[[aws-cdk|AWS CDK]] 는 TypeScript / Python 등 프로그래밍 언어로 인프라를 정의하고, 내부적으로 CloudFormation 템플릿을 생성해 배포합니다.

CDK 코드 (TypeScript)
    → cdk synth
    → CloudFormation 템플릿 (YAML)
    → cdk deploy
    → CloudFormation 스택 생성
    → AWS 리소스

CDK 는 CloudFormation 의 프로그래밍 언어 인터페이스입니다. 실제 프로비저닝 엔진은 CloudFormation 이며, AWS 콘솔의 CloudFormation 스택에서 CDK 배포 결과를 확인할 수 있습니다.

CloudFormation vs 대안 IaC

| 축 | CloudFormation | [[terraform|Terraform]] | [[aws-cdk|CDK]] | [[pulumi|Pulumi]] | |:---|:---|:---|:---|:---| | 제공사 | AWS 관리형 | HashiCorp / OpenTofu | AWS | Pulumi Corp | | 언어 | YAML / JSON | HCL | TS / Python / Java / Go | TS / Python / Go / C# | | 대상 클라우드 | AWS 전용 | Multi-cloud | AWS 위주 | Multi-cloud | | State 관리 | CFN 서비스 내장 | 자체 tfstate 파일 | CFN 서비스 내장 | Pulumi Cloud | | 변경 미리보기 | ChangeSet | terraform plan | cdk diff | pulumi preview | | 새 AWS 서비스 | 즉시 지원 | Provider 업데이트 필요 | 즉시 지원 | Provider 업데이트 필요 | | 타입 안전성 | 없음 | HCL 제한적 | 완전 (TS) | 완전 | | 테스트 | 어려움 | terratest | jest / pytest | 언어 내장 |

판단 기준:

AWS-only, AWS 관리 상태 선호, YAML 거부감 없음 → CloudFormation
AWS-only + 개발자 친화성 + 타입 안전성 + 테스트 → CDK
Multi-cloud, 인프라 팀 중심, 넓은 에코시스템 → Terraform
Multi-cloud + 완전한 프로그래밍 언어 → Pulumi

비용

CloudFormation 자체는 무료. 생성되는 AWS 리소스 요금만 부과.

예외:

StackSets: 배포 Operation 당 소량 요금 (서비스 관리형 모드)
CloudFormation Guard: 오픈소스 정책 검사 도구, 실행 비용 없음

함정

[!CAUTION] 리소스 Update 가 Replacement 유발. UpdateRequiresReplacement 속성 변경 시 기존 리소스 삭제 후 재생성. 예: RDS 인스턴스 식별자 변경 → DB 데이터 포함 삭제. ChangeSet 으로 반드시 미리 확인.

[!WARNING] IAM Circular Dependency. Lambda → IAM Role → Lambda 처럼 순환 참조 발생 시 스택 생성 교착 상태. DependsOn 명시 또는 별도 스택으로 분리해 해결.

[!CAUTION] 스택당 리소스 500개 한계 (소프트 한도 200개). 대형 인프라는 Nested Stacks 또는 독립 스택 여러 개로 분리.

[!WARNING] Cross-Stack Export 삭제 불가. 다른 스택이 !ImportValue 로 참조 중인 Export 를 삭제하면 오류. 스택 간 의존성 설계 초기에 명확히 계획.

[!IMPORTANT] Rollback 실패 시 수동 복구 필요. UPDATE_ROLLBACK_FAILED 상태에서는 continue-update-rollback 명령 실행 후 문제 리소스 수동 정리. 해결 못하면 스택이 잠길 수 있음.

[!WARNING] Stack 삭제 = 리소스 삭제. 실수로 스택 삭제 시 RDS, S3 등 데이터 포함 삭제. 중요 리소스에 DeletionPolicy: Retain 또는 Snapshot 설정 필수.

[AWS] WAF (Web Application Firewall)

koa (김신건) — Tue, 14 Jul 2026 00:00:00 GMT

정의

AWS WAF (Web Application Firewall) 는 HTTP/HTTPS 요청을 검사하는 Layer 7 방화벽 서비스입니다. CloudFront, ALB, API Gateway 등 앞단에 붙어 SQL injection, XSS, 악의적 봇, 비정상 Rate 등을 요청 단위로 차단합니다.

한 줄 요약: 개별 웹 요청의 URL, 헤더, 바디, 쿠키를 룰로 필터링하는 앱 계층 방화벽.

Layer 3/4 방화벽의 한계

[[aws-sg-vs-nacl|Security Group / NACL]] 은 IP/포트/프로토콜 레벨만 처리합니다:

HTTP URL 경로 기반 차단 불가: /admin 만 막고 싶어도 IP 막는 수 밖에 없음
요청 헤더/바디 검사 불가: SQL injection payload 감지 없음
사용자별 Rate Limit 불가: 동일 IP 에서 초당 1000 요청이 와도 허용
국가/지역 기반 필터 불가

WAF 는 HTTP 요청을 7계층에서 분해해서 룰과 매칭합니다.

핵심 개념

Web ACL

WAF 의 최상위 단위. 여러 Rule / Rule Group 을 포함하고 각 AWS 리소스에 연결합니다.

Default Action: 매칭 룰 없을 때 Allow 또는 Block 결정
하나의 Web ACL 을 여러 리소스에 공유 가능
리전 또는 글로벌 (CloudFront 전용) 스코프

Rule Group

Rule 을 묶는 컨테이너. 우선순위 숫자로 평가 순서 결정 (낮을수록 먼저).

세 종류:

AWS Managed Rules: AWS 관리, 자동 업데이트, 즉시 사용 가능
AWS Marketplace Rules: Fortinet, F5, Imperva 등 3rd-party 벤더
Custom Rules: 직접 작성

Rule

매칭 조건 + 액션 단위.

Statement (매칭 조건):

Statement	설명
`ByteMatchStatement`	특정 문자열 포함 여부
`SqliMatchStatement`	SQL injection 패턴
`XssMatchStatement`	XSS 패턴
`IPSetReferenceStatement`	IP 집합 (최대 10,000 IP)
`GeoMatchStatement`	국가 코드
`RateBasedStatement`	IP 당 요청 수 (5분 창)
`RegexMatchStatement`	정규식
`AndStatement` / `OrStatement`	조건 조합
`NotStatement`	조건 부정

검사 대상 필드: URI, Query String, Header, Cookie, HTTP Method, Body, JSON Body.

Action: Allow, Block, Count, Challenge, CAPTCHA

Count: 실제 차단 않고 카운트만. False Positive 분석에 활용.
Challenge: JS 챌린지로 봇 여부 판별.
CAPTCHA: 사람인지 확인.

WCU (Web ACL Capacity Units)

각 룰마다 WCU 비용이 있고, Web ACL 은 최대 5000 WCU 까지.

SqliMatchStatement: 10~20 WCU
XssMatchStatement: 40 WCU
RateBasedStatement + 조건 결합: 규칙별 추가
Managed Rule Group: 각 그룹에서 선언한 WCU 합산

복잡한 커스텀 룰은 WCU 를 빠르게 소진합니다.

통합 대상

리소스	특이사항
CloudFront	Web ACL 은 `us-east-1` 에 생성 필수
ALB	동일 리전에 생성
API Gateway (REST / HTTP API)	Stage 단위 연결
AppSync
Cognito User Pool
App Runner
Verified Access

아키텍처

flowchart LR
  Internet[인터넷] --> Resource["CloudFront / ALB / API GW"]
  Resource --> WAF[Web ACL]
  WAF -->|Allow| Origin[Origin 서버]
  WAF -->|Block| Blocked[4xx 응답]
  WAF -.->|로그| Logs["Kinesis / S3 / CloudWatch"]

요청 평가 흐름

flowchart TD
  Req[HTTP 요청] --> R1["Rule Group (우선순위 100)"]
  R1 -->|Match| A1[액션 실행]
  R1 -->|No Match| R2["Rule Group (우선순위 200)"]
  R2 -->|Match| A2[액션 실행]
  R2 -->|No Match| Default[Default Action]

AWS Managed Rules

무료 포함 (별도 비용 없음, WCU 만 소비):

그룹	내용
`AWSManagedRulesCommonRuleSet`	OWASP Top 10, SQLi, XSS, LFI, RFI
`AWSManagedRulesKnownBadInputsRuleSet`	Log4Shell, Spring4Shell 등 CVE
`AWSManagedRulesAmazonIpReputationList`	AWS 위협 인텔리전스 IP 목록
`AWSManagedRulesAnonymousIpList`	VPN, Tor, proxy
`AWSManagedRulesLinuxRuleSet`	Linux OS 관련 취약점
`AWSManagedRulesSQLiRuleSet`	SQL injection 전용 (더 세밀)
`AWSManagedRulesBotControlRuleSet`	별도 요금, 봇 분류/차단
`AWSManagedRulesFraudControlAccountTakeoverPreventionRuleSet`	별도 요금, 계정 탈취 방지

Override Action: 특정 룰을 Count 로 전환해 테스트 가능. 배포 전 False Positive 파악에 필수.

커스텀 Rule 예시

{
  "Name": "BlockSQLi",
  "Priority": 10,
  "Statement": {
    "OrStatement": {
      "Statements": [
        {
          "SqliMatchStatement": {
            "FieldToMatch": { "QueryString": {} },
            "TextTransformations": [{"Priority": 0, "Type": "URL_DECODE"}]
          }
        },
        {
          "SqliMatchStatement": {
            "FieldToMatch": { "Body": {"OversizeHandling": "CONTINUE"} },
            "TextTransformations": [{"Priority": 0, "Type": "HTML_ENTITY_DECODE"}]
          }
        }
      ]
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlockSQLi"
  }
}

Rate-based Rule

IP 당 5분 창 기준 요청 수로 차단:

{
  "Name": "RateLimitPerIP",
  "Priority": 5,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} }
}

IP 당 5분에 2000 요청 초과 시 차단. 집계 키를 FORWARDED_IP 나 HTTP_HEADER 로 변경 가능.

Geo Blocking

{
  "Name": "GeoBlockKP",
  "Statement": {
    "GeoMatchStatement": { "CountryCodes": ["KP", "IR"] }
  },
  "Action": { "Block": {} }
}

Bot Control

AWSManagedRulesBotControlRuleSet (별도 요금, 월 + 요청 당):

Common 레벨: User-Agent, IP 기반 봇 감지. 크롤러, 스캐너, 스크래퍼.
Targeted 레벨: JavaScript challenge, CAPTCHA 포함. 정교한 봇도 탐지.

레벨별 차이:

레벨	비용	탐지 범위
`COMMON`	낮음	일반 봇, User-Agent 기반
`TARGETED`	높음	정교한 봇, JS 실행 가능 여부 검사

Fraud Control

ATP (Account Takeover Prevention): 로그인 폼 브루트포스, 비밀번호 스터핑 방어
ACFP (Account Creation Fraud Prevention): 가짜 계정 대량 생성 방어

별도 요금이며, 특정 URI 경로 (로그인/회원가입 엔드포인트) 에만 적용.

로깅

WAF 요청 로그 대상:

Kinesis Data Firehose: S3 / Redshift / OpenSearch 실시간 전송
CloudWatch Logs: 로그 그룹 직접 전송
S3: 직접 저장

로그 필터: 특정 조건 (Block 된 것만 등) 매칭 요청만 로깅해 비용 절감.

샘플링: Sampled Requests (최근 500개 샘플) 는 무료로 콘솔에서 확인 가능.

비용 모델

항목	요금 (USD, ap-northeast-2 기준)
Web ACL 월	5.00 USD
Rule Group 월	1.00 USD / 그룹
요청 처리	0.60 USD / 100만 요청
Bot Control Common	10.00 USD / 월 + 1.00 USD / 100만 요청
Bot Control Targeted	10.00 USD / 월 + 1.50 USD / 100만 요청
ATP / ACFP	10.00 USD / 월 + 추가 요청 요금

참고: 요금은 변동될 수 있으므로 AWS 공식 페이지 확인.

WAF vs 유사 서비스

서비스	역할	계층
WAF	개별 HTTP 요청 검사, 룰 기반 필터링	Layer 7
**[[aws-shield	Shield]]**	대용량 DDoS 트래픽 볼륨 완화
**[[aws-network-firewall	Network Firewall]]**	VPC 수준 DPI, 도메인 필터, IPS (Suricata)
**[[aws-guardduty	GuardDuty]]**	이상 행위 탐지, 위협 인텔리전스 (차단 아님)

판단 기준:

웹 앱 SQL injection / XSS / 봇 방어 → WAF
수 Gbps 볼륨 DDoS 완화 → Shield
VPC 내부 East-West + IPS → Network Firewall
위협 탐지 + 가시성 (이상 행위 알림) → GuardDuty

실제 운영에서는 조합: CloudFront + WAF + Shield Advanced + GuardDuty.

실전 배포 패턴

CloudFront + WAF (권장)

[사용자] → CloudFront + Web ACL → ALB → EC2/ECS

엣지에서 먼저 차단하므로 Origin 까지 트래픽 전달 최소화. 글로벌 지연 없음.

ALB 전용

[사용자] → ALB + Web ACL → Target Group

CloudFront 없는 구성, 리전 내 요청만 처리.

API Gateway 보호

[클라이언트] → API Gateway + Web ACL → Lambda / 백엔드

Rate Limit + IP 차단으로 API 남용 방어.

함정

[!WARNING] Managed Rule False Positive. AWSManagedRulesCommonRuleSet 이 정상 요청을 차단할 수 있습니다. 첫 배포는 반드시 Override Action: Count 로 실행 후 로그 분석.

[!CAUTION] WCU 5000 한계. 복잡한 커스텀 룰 + 여러 Managed Rule Group 조합 시 WCU 초과. 불필요 룰 제거 또는 단순화 필요.

[!WARNING] CloudFront WAF 는 us-east-1 고정. 다른 리전에 Web ACL 을 만들면 CloudFront 에 연결 불가.

[!CAUTION] 로그 비용 폭발. 대용량 트래픽에서 전체 로그 활성화 시 Kinesis / S3 비용 급증. 로그 필터 또는 샘플링 먼저 설정.

[!IMPORTANT] Rate-based rule 집계 지연. 5분 창 기반이라 순간 버스트는 차단이 늦을 수 있습니다. 짧은 burst 방어에는 [[aws-shield|Shield]] 보완.

[!WARNING] Managed Rule 자동 업데이트 주의. AWS 가 룰 업데이트 시 신규 룰이 정상 트래픽을 막을 수 있습니다. SNS 알림 구독 + 스테이징 환경에서 먼저 적용 후 프로덕션 반영.

[AWS CAF] Business Perspective

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Business Perspective 는 [[aws-caf|AWS CAF]] 6 관점 중 비즈니스 성과 에 초점을 맞춘 관점입니다. 클라우드 투자가 디지털 전환 목표와 비즈니스 성과 (revenue, cost, agility, innovation) 를 실제로 견인하도록 보장합니다.

주요 stakeholder: CEO, CFO, COO, CIO, CTO.

핵심 질문

클라우드로 어떤 비즈니스 성과를 달성할 것인가?
투자 대비 성과 (ROI) 는?
어떤 제품/서비스를 클라우드로 만들 것인가?
조직의 데이터/역량을 어떻게 수익화 할 것인가?

주요 Capabilities (역량)

Business perspective 는 8-10 개 capability. 대표:

1. Strategy Management (전략 관리)

디지털 전환 목표를 회사 전략과 정렬. 클라우드가 어떤 비즈니스 문제 를 해결하는가 정의.

성숙도 지표:

Initial: 클라우드 사용은 있지만 전략 없음
Optimized: 전략 정기 리뷰, KPI 로 측정

2. Portfolio Management (포트폴리오 관리)

어떤 앱/서비스를 클라우드로, 어떤 순서로. 우선순위 결정 프레임워크 (6R: Rehost, Replatform, Refactor, Repurchase, Retire, Retain).

3. Innovation Management (혁신 관리)

클라우드가 새 비즈니스 모델/서비스를 가능하게 하는지 관리. 실험 (experimentation), MVP, 학습 문화.

4. Product Management (제품 관리)

디지털 제품/서비스의 lifecycle (착상 -> 개발 -> 배포 -> 은퇴). Product manager 역할 강화.

5. Strategic Partnership (전략적 파트너십)

AWS, SI, ISV 파트너와의 관계. Managed service provider (MSP), 컨설팅, 트레이닝 파트너.

6. Data Monetization (데이터 수익화)

조직의 데이터를 비즈니스 가치 로 전환. 데이터 제품, ML/AI 인사이트, 개인화, 예측.

7. Business Insights (비즈니스 인사이트)

BI, 대시보드, 분석. 데이터 기반 의사결정 문화.

8. Data Science (데이터 과학)

ML/AI 역량 개발. SageMaker, Bedrock 등 활용.

Cloud Value Framework (4 pillar)

AWS 가 제시하는 클라우드 가치의 4 축:

1. Cost Savings (비용 절감)

CapEx -> OpEx: 서버 구입 대신 사용료
Reserved / Savings Plans 로 예측 가능 워크로드 절감
Serverless / Spot 로 유휴 자원 제거
데이터센터 운영/부동산 절감

전형적 30-40% TCO 절감 (마이그레이션 규모에 따라).

2. Staff Productivity (스태프 생산성)

관리형 서비스 (RDS, Kinesis, Lambda) 로 운영 부담 감소
IaC + CI/CD 로 배포 시간 단축
관측 도구로 문제 진단 가속
팀이 저부가가치 운영 대신 앱 개발/비즈니스 집중

3. Operational Resilience (운영 회복력)

Multi-AZ / Multi-region HA
자동 백업, DR
자동 failover
다운타임 비용 절감 (예: 1시간 다운타임 = 수백만 USD 손실)

4. Business Agility (비즈니스 민첩성)

새 서비스 프로비저닝 몇 분 (기존 몇 주/월)
신규 시장/지역 진출 빠름 (multi-region)
실험 비용 낮음 (실패 부담 낮음)
경쟁 대응 속도

정성적 가치이나 흔히 정량화된 revenue 증가로 이어짐.

KPI 예시

비용 관련

TCO reduction: on-prem 대비 3-5년 절감
Unit economics: 사용자당 인프라 비용
Cost of goods sold (COGS) 감소

Agility 관련

Time to market: 신규 서비스 출시 시간
Deployment frequency: 배포 횟수 (DORA metric)
Lead time: 아이디어 -> 프로덕션

Innovation 관련

Number of experiments: 분기별 실험 수
New products launched: 신규 제품 수
Revenue from new products: 신규 제품 매출

실전 활동

Envision phase

비즈니스 전략 워크숍 (경영진)
산업/경쟁사 벤치마킹
클라우드 채택 비즈니스 케이스 (business case)
ROI 시뮬레이션

Align phase

Portfolio 우선순위 매트릭스 (impact vs effort)
Cloud value framework 4 축 갭 분석
Product roadmap (12-24 개월)

Launch phase

첫 pilot 성과 측정 (KPI baseline vs target)
성공 스토리 조직 내 공유
팀 인센티브 정렬

Scale phase

지속 성과 대시보드
재투자 결정 (성공한 것에 더)
신규 비즈니스 기회 발굴

CAF 6 관점 관계도

Business Perspective 는 다른 5개 관점과 상호 의존합니다.

flowchart TD
    Biz["Business Perspective\n전략/투자/포트폴리오"]
    People["People Perspective\n조직/역량/문화"]
    Gov["Governance Perspective\n거버넌스/재무/리스크"]
    Plat["Platform Perspective\n기술/아키텍처"]
    Sec["Security Perspective\n보안/컴플라이언스"]
    Ops["Operations Perspective\n운영/지원"]
    Biz -->|"목표 정의"| People
    Biz -->|"예산/우선순위"| Gov
    Biz -->|"제품 요구사항"| Plat
    Biz -->|"리스크 허용 범위"| Sec
    Biz -->|"서비스 수준 목표"| Ops
    People -->|"역량 피드백"| Biz
    Gov -->|"재무 성과 측정"| Biz

6 관점 한눈에

관점	초점	주요 Stakeholder
Business	비즈니스 성과, ROI, 전략	CEO, CFO, COO
People	조직 변화, 역량 개발, 문화	CHRO, CIO
Governance	재무 관리, 리스크, 포트폴리오	CFO, CDO
Platform	아키텍처, 기술 플랫폼, 모던화	CTO, Architect
Security	보안, 컴플라이언스, 신뢰	CISO
Operations	운영, 모니터링, 지속 최적화	VP Ops, IT Ops

Business Case 구성

클라우드 전환 전 비즈니스 케이스 작성 프레임워크:

1. 현재 상태 분석 (As-Is)

온프레미스 비용 항목:
- 하드웨어 (서버, 스토리지, 네트워크): CapEx
- 데이터센터 (공간, 전력, 냉각): OpEx
- 소프트웨어 라이선스: CapEx/OpEx
- 인력 (서버 관리, DB 관리): OpEx
- 유지보수 계약: OpEx

2. 미래 상태 예측 (To-Be)

클라우드 비용 예측:
- 컴퓨팅 (EC2, Reserved/Savings Plans)
- 스토리지 (S3, EBS, RDS)
- 네트워크 (데이터 전송, CDN)
- 관리형 서비스 (RDS, EKS, SageMaker)
- 지원 (AWS Support plan)

마이그레이션 비용:
- 컨설팅/SI 비용
- 내부 인력 시간
- 교육/인증
- 병렬 운영 기간

3. 비용 절감 계산

항목	절감 근거	일반적 절감률
서버 구매 비용 제거	하드웨어 수명 주기 없음	30-40%
데이터센터 운영	공간/전력/냉각 없음	20-30%
인력 최적화	관리형 서비스 활용	10-20%
유휴 자원 제거	Auto Scaling, 정확한 사이징	15-25%

ROI 계산 방법론

3년 TCO 비교 모델

총 절감 = (현재 3년 비용) - (클라우드 3년 비용 + 마이그레이션 비용)

ROI % = (순 절감액 / 마이그레이션 비용) x 100

손익분기점 = 마이그레이션 비용 / 월간 절감액

Cloud Value Framework 지표 정량화

가치 축	정량화 방법	예시
비용 절감	TCO 분석, 3-5년 비교	연간 $2M 절감
생산성 향상	배포 빈도, 장애 복구 시간	배포 10배 증가
운영 회복력	다운타임 비용, SLA 개선	연간 다운타임 99시간 → 1시간
비즈니스 민첩성	Time-to-market, 실험 수	신규 기능 출시 6주 → 1주

[!IMPORTANT] AWS 의 TSO Logic 또는 AWS Migration Evaluator 로 데이터 기반 TCO 분석 가능.

포트폴리오 우선순위 결정 (6R)

마이그레이션 대상 앱의 전략 분류:

flowchart TD
    App["애플리케이션 평가"]
    App --> Q1{"비즈니스 가치?"}
    Q1 -->|"낮음, 중복"| Retire[Retire 폐기]
    Q1 -->|"중간, 외부 대체 가능"| Repurchase[Repurchase SaaS 전환]
    Q1 -->|높음| Q2{"클라우드 최적화 필요?"}
    Q2 -->|"즉시 리프트"| Rehost["Rehost\nLift and Shift"]
    Q2 -->|"일부 최적화"| Replatform["Replatform\nLift Tinker Shift"]
    Q2 -->|"전면 재설계"| Refactor["Refactor\nRe-architect"]
    Q2 -->|"당장 이전 불가"| Retain["Retain\n현재 유지"]

전략	설명	마이그레이션 속도
Rehost	VM을 그대로 클라우드로 (VMware, MGN)	빠름
Replatform	DB를 RDS로, 앱 서버를 컨테이너로	중간
Refactor	마이크로서비스, 서버리스로 재설계	느림
Repurchase	CRM/ERP를 SaaS로 대체	빠름
Retire	불필요한 앱 폐기	즉시
Retain	현재 환경 유지 (추후 재평가)	해당 없음

성숙도 평가 모델

CAF 는 4단계 성숙도를 정의합니다:

단계	명칭	특성
1	Project	개별 팀 클라우드 실험
2	Foundation	기반 구축, 공통 플랫폼
3	Migration	조직적 마이그레이션 진행
4	Reinvention	클라우드 네이티브, 지속 혁신

Business Perspective 성숙도 지표:

Level 1: 클라우드 사용하지만 비즈니스 목표 연결 없음
Level 2: 클라우드 전환 로드맵 존재, C-level 인식
Level 3: KPI 로 성과 측정, 조직 전반 채택
Level 4: 클라우드 우선 문화, 지속적 혁신 사이클

흔한 실패 패턴

[!WARNING] 비즈니스 목표 없이 기술 도입. “우리도 클라우드 써야지” 만으로는 ROI 안 나옴. 명확한 문제 정의부터.

[!CAUTION] 비용 절감만 목표. Cost savings 는 4 축 중 하나. Agility / innovation 무시하면 경쟁력 손실.

[!WARNING] 경영진 이탈. 전환 3 년차에 경영진 관심 감소하며 지원 축소. 지속 참여 필수.

[!IMPORTANT] 정성적 가치도 정량화 시도. Agility, resilience 를 매출 영향으로 환산.

[!CAUTION] 마이그레이션 비용 과소평가: 컨설팅, 교육, 병렬 운영 기간, 내부 인력 시간 모두 계산에 포함해야. 첫 1-2년은 비용 증가 후 절감 시작.

[AWS CAF] Governance Perspective

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Governance Perspective 는 [[aws-caf|AWS CAF]] 6 관점 중 클라우드 이니셔티브의 관리 (orchestration) 를 담당합니다. 조직의 이익을 극대화하면서 전환 관련 리스크를 최소화 하는 것이 목표입니다.

주요 stakeholder: Chief Transformation Officer, CIO, CTO, CFO, CDO (Data), CRO (Risk).

왜 Governance 인가

Governance 없이 클라우드 도입 시:

비용 폭주 (unmanaged 사용, tag 없음)
shadow IT (팀이 각자 계정 만들어 카오스)
컴플라이언스 위반 (감시 없이 리소스 배포)
중복 투자 (같은 문제 여러 팀이 각자 해결)
리스크 무방비 (재해복구, 백업, 보안 정책 없음)

주요 Capabilities

1. Program and Project Management

클라우드 전환 프로그램 관리. 여러 프로젝트 orchestration.

Portfolio 관리
Roadmap 조정
Dependency 관리
Stakeholder 커뮤니케이션

2. Benefits Management

투자 대비 실현 가치 (benefits) 추적. 계획 vs 실현 gap 분석.

KPI 정의 및 측정
Business case 검증
Continuous improvement

3. Risk Management

전환 관련 리스크 식별 + 관리:

기술 리스크: 이관 실패, 성능 저하
비즈니스 리스크: 다운타임, 매출 영향
컴플라이언스 리스크: 규제 위반
재무 리스크: 예상 초과 비용
인력 리스크: 스킬 갭

Mitigation plan 마련.

4. Cloud Financial Management (FinOps)

클라우드 비용의 계획, 예측, 최적화, 책임 (accountability).

FinOps 3 원칙 (FinOps Foundation):

Inform (정보): 비용 가시성, 벤치마킹, 할당
Optimize (최적화): RI/SP, right-sizing, waste 제거
Operate (운영): 지속 개선, 팀 accountability

AWS 도구:

AWS Cost Explorer: 비용 분석
AWS Budgets: 예산 + 알림
AWS Cost Anomaly Detection: 이상 감지
AWS Compute Optimizer: right-sizing 추천
Savings Plans / Reserved Instances: 예약 할인
AWS CUR (Cost and Usage Report): 상세 데이터
AWS Billing Conductor: 사내 재청구

5. Application Portfolio Management

6R Migration Strategy:

Rehost (lift-and-shift): 그대로 이관
Replatform (lift-tinker-shift): 약간 조정
Refactor (re-architect): 클라우드 네이티브 재설계
Repurchase (drop and shop): SaaS 로 대체
Retire (은퇴): 안 씀
Retain (유지): on-prem 유지

각 앱을 6R 매트릭스에 매핑.

6. Data Governance

데이터의 lifecycle, 소유권, 품질, 접근 통제 관리.

Data catalog (AWS Glue Data Catalog)
Data lineage
Data quality metrics
Data classification (PII, sensitive)
Data access controls (Lake Formation)
Retention policy

7. Data Curation

데이터를 유용한 상태로 유지: cleansing, enrichment, standardization.

계정 전략

Governance 의 실제 실현.

AWS Organizations

Multi-account 계층:

Organization Root
├── Management Account (billing, org-level policies)
├── Log Archive Account (CloudTrail, Config 중앙)
├── Security Account (Security Hub, GuardDuty)
├── Sandbox OU (실험)
├── Dev OU
├── Staging OU
└── Production OU
    ├── Business Unit A
    └── Business Unit B

Service Control Policies (SCP)

Org / OU 단위로 AWS API 제한.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["ec2:RunInstances"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": ["t3.micro", "t3.small", "t3.medium"]
        }
      }
    }
  ]
}

Sandbox OU 에는 큰 인스턴스 금지 등.

AWS Control Tower

Landing Zone 자동화 서비스:

계정 프로비저닝 자동화
표준 가드레일 (SCP + Config Rules)
로그 중앙화
컴플라이언스 대시보드

Tagging Strategy

리소스 tag 필수. 비용 할당 + 관리:

project: platform
environment: prod
owner: alice@company.com
cost-center: engineering
data-classification: pii
compliance: hipaa

Tag 강제: [[aws-config|Config]] rule required-tags + SCP.

Chargeback / Showback

각 팀/사업부에 클라우드 비용 할당:

Showback: 정보 제공만 (책임 의식)
Chargeback: 실제 내부 청구

Tag 기반 Cost Allocation Report -> AWS Billing Conductor 로 커스텀 청구서.

Risk Register

주요 리스크를 문서화 + 대응:

Risk: 마이그레이션 중 다운타임
Impact: 매출 감소 (시간당 X USD)
Likelihood: Medium
Mitigation: Blue/green, 야간 이관, rollback plan
Owner: Platform team lead

Change Management

프로덕션 변경 프로세스:

Change Advisory Board (CAB) - 클라우드에서는 자동화 지향
Automated approval (low-risk)
Peer review (medium)
Manual approval (high-risk)

실전 활동

Envision

현재 IT governance 진단
Risk register 초안
FinOps 팀 계획

Align

Landing Zone 설계 (Control Tower)
SCP 정책 초안
Tagging strategy
예산 목표

Launch

Landing Zone 배포
첫 workload 의 tag / 비용 할당 검증
Governance dashboard

Scale

전사 Control Tower 확장
FinOps 자동화
지속 개선 (Cost review 월간)

Cost Optimization 5 원칙 (AWS)

Right-sizing: 실 사용량 기반 인스턴스 크기
Reserved capacity: 예측 가능 부하는 RI / Savings Plans
Elastic scaling: HPA, Auto Scaling
Storage lifecycle: S3 IA/Glacier, snapshot 정리
Waste elimination: 유휴 리소스, 미사용 EIP

흔한 실패 패턴

[!WARNING] Governance 없이 시작. 첫 6개월 편해 보이지만 3년차에 카오스. 초기부터 Landing Zone.

[!CAUTION] 비용 관리를 IT 만의 문제로. 팀별 accountability 없이는 관리 안 됨.

[!WARNING] SCP 를 과도 제한. 팀 자율성 저해, shadow IT 유발. Balance 필요.

[!IMPORTANT] Tag 없으면 비용 할당 불가. 초기부터 mandatory tags 강제.

[!CAUTION] 재무팀 vs 엔지니어링팀 간극. Cost 대화가 언어 다름. FinOps 팀이 다리.

[AWS CAF] Operations Perspective

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Operations Perspective 는 [[aws-caf|AWS CAF]] 6 관점 중 클라우드 서비스가 비즈니스가 요구하는 수준으로 딜리버리되도록 보장 하는 관점입니다. 자동화 + 최적화 로 신뢰성 있게 확장.

주요 stakeholder: 인프라/운영 리더, SRE (Site Reliability Engineer), IT service manager.

주요 Capabilities

1. Observability

시스템 상태 가시성. Metrics, Logs, Traces.

AWS 도구:

[[aws-cloudwatch|CloudWatch]] Metrics, Logs, Alarms, Dashboards
CloudWatch Application Signals (2024+)
X-Ray (tracing)
[[opentelemetry|OpenTelemetry]] (표준)
Managed Prometheus, Managed Grafana

3 pillars of observability:

Metrics: 수치 시계열 (CPU%, requests/s)
Logs: 이벤트 (structured JSON)
Traces: 요청 흐름 (분산 트레이싱)

2. Event Management (AIOps)

이벤트 상관 + 자동 대응.

Alert de-duplication
Alert routing (PagerDuty, Opsgenie)
Auto-remediation (Lambda + Systems Manager)
ML 기반 이상 감지

3. Incident and Problem Management

사고 대응 프로세스.

Incident: 실시간 문제 (down)
Problem: 근본 원인 조사
PIR (Post-Incident Review): Blameless postmortem

단계:

Detection
Triage (severity 판단)
Response (mitigation)
Communication (상태 페이지, stakeholder)
Resolution
PIR

4. Change and Release Management

프로덕션 변경 관리.

Change Advisory Board (전통) -> Automated (클라우드)
Blue/green, canary
Rollback 자동화
Change failure rate 추적 (DORA metric)

5. Performance and Capacity Management

성능 목표 (SLO) 정의 + 용량 계획.

SLO (Service Level Objective): 예 99.9% 가용성
SLI (Service Level Indicator): 측정 지표
Error budget: SLO 대비 여유
Capacity planning: 미래 부하 예측

6. Configuration Management

리소스 설정 관리:

[[aws-config|Config]] 로 리소스 상태 추적
Systems Manager Parameter Store
IaC (immutable, versioned)

7. Patch Management

OS/앱 패치:

Systems Manager Patch Manager
자동 스케줄 (매주 등)
Compliance 상태 리포트

8. Availability and Continuity Management

가용성 + 재해복구.

RTO (Recovery Time Objective): 복구까지 시간
RPO (Recovery Point Objective): 데이터 손실 허용 시간
Multi-AZ, Multi-region
DR runbook

9. Application Performance Monitoring (APM)

앱 성능 관측.

Latency percentiles (p50, p95, p99)
Throughput
Error rate
Apdex score
User experience

SRE (Site Reliability Engineering)

Google 이 만든 클라우드 시대 운영 접근법. Operations perspective 의 실현.

핵심 원칙:

Automation: 반복 작업 자동화 (toil 제거)
Measurement: 모든 것 측정 (SLI/SLO/SLA)
Error budget: 100% 가용성 목표 X (혁신과 안정성 균형)
Blameless postmortem: 사람 아닌 시스템 문제로

Toil: 자동화 가능한 반복 수동 작업. SRE 는 toil 50% 이하 유지 목표.

SLO / SLI / SLA

SLI (Indicator): 측정 지표. 예: “요청의 99% 가 200ms 이하로 응답”

SLO (Objective): 내부 목표. 예: 99.9% availability/month

SLA (Agreement): 고객과의 계약. 위반 시 배상.

Error Budget = 100% - SLO. 예: SLO 99.9% -> error budget 0.1% = 43분/월.

Budget 남으면: 새 기능 배포 OK
Budget 소진: 안정성 개선 우선

DORA Metrics

Elite performing team 지표 (Google DevOps Research):

Deployment Frequency: 몇 번 배포 (일/주)
Lead Time for Changes: 코드 커밋 -> 프로덕션
Change Failure Rate: 배포가 문제 유발 %
Time to Restore Service: 사고 복구 시간

Elite: 하루 여러 번 배포, 리드타임 < 1시간, 실패율 < 15%, MTTR < 1시간.

Operational Runbook

표준 운영 절차 문서화. 특정 상황에 따라야 할 단계.

Runbook: RDS Failover
1. CloudWatch alarm 확인 (CPU / Connections)
2. Read replica lag 확인
3. Manual failover 필요 시:
   aws rds failover-db-cluster --db-cluster-identifier prod-db
4. Application 재시작 (필요 시)
5. PIR 준비

Systems Manager Automation runbook 으로 자동화 가능.

Chaos Engineering

의도적 실패 주입 으로 시스템 회복력 검증.

AWS Fault Injection Simulator (FIS): EC2 stop, latency 주입 등
Netflix Chaos Monkey (원조)
Game days (팀 훈련)

Reliability capability 검증.

Automation Priorities

Deployment: CI/CD, IaC
Testing: 자동 통합/E2E 테스트
Monitoring: 알람 자동
Remediation: 자동 복구 (예: EC2 replace)
Scaling: Auto Scaling, HPA
Backup / Restore
Patching

Well-Architected Operational Excellence

Platform perspective 의 6 pillar 중 하나. Operations 는 이 pillar 의 실현.

설계 원칙:

Perform operations as code
Make frequent, small, reversible changes
Refine operations procedures frequently
Anticipate failure
Learn from all operational failures

실전 활동

Envision

현재 운영 성숙도 진단 (DORA)
SLO 정의
Incident history 분석

Align

Observability 스택 설계
On-call 계획
Runbook 저장소

Launch

CloudWatch dashboard + alarm
On-call rotation 시작
첫 GameDay

Scale

자동 remediation 확대
SRE 팀 성숙
DORA metric 지속 개선

흔한 실패 패턴

[!WARNING] 관측 없이 배포. 문제 발생 시 진단 불가. Metrics/logs/traces 첫날부터.

[!CAUTION] Alert fatigue. 노이즈 알람 많으면 진짜 사고 놓침. SLO 기반 알람만.

[!WARNING] Runbook 없이 사고. 매번 처음처럼. 반복되는 문제는 runbook + 자동화.

[!IMPORTANT] PIR 를 blame 세션으로. 사람 지목은 문화 파괴. 시스템/프로세스 개선 초점.

[!CAUTION] DR 안 훈련. 실제 사고 시 실패. 정기 DR drill.

[AWS CAF] People Perspective

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

People Perspective 는 [[aws-caf|AWS CAF]] 6 관점 중 비즈니스 와 기술 사이의 다리 역할을 하는 관점입니다. 문화, 조직 구조, 리더십, 인력 (workforce) 을 다루며, “변화 (change) 가 일상 (business-as-normal) 이 되는” 조직 문화로의 진화를 촉진합니다.

주요 stakeholder: CIO, COO, CTO, cloud director, cross-functional/enterprise-wide leaders.

왜 People 관점이 중요한가

기술적으로 성숙한 조직도 사람 관점 미숙 이면 실패:

스킬 갭 -> 프로덕션 문제
저항 문화 -> 도입 지연
사일로 조직 -> 협업 저해
리더십 부재 -> 방향성 상실

“기술은 쉽고, 사람이 어렵다” 는 격언이 여기 해당.

주요 Capabilities

1. Culture Evolution (문화 진화)

실험, 학습, 실패 허용 문화로 진화. 위계적 승인 -> 자율적 결정.

측정:

실험 횟수/분기
Blameless postmortem 실행
팀 자율성 지수

2. Transformational Leadership (변혁적 리더십)

경영진의 클라우드 전환 명확한 커밋. 리더 자체가 클라우드/디지털에 대한 이해 필수.

활동:

리더 클라우드 교육 (AWS Cloud Practitioner 등)
정기 town hall 에서 비전 반복
성공 스토리 공유

3. Cloud Fluency (클라우드 유창성)

모든 직원이 클라우드 기초 이해. IT 팀만이 아니라 재무/HR/영업도.

Cloud 101 교육
용어집 (glossary)
사내 뉴스레터

4. Workforce Transformation (인력 전환)

스킬 갭 매핑 + 재교육 계획.

현재 스킬 인벤토리
Target 스킬 매핑
Learning path 별 교육
AWS Certifications (Cloud Practitioner, Solutions Architect Associate, …)
외부 채용 vs 내부 재교육

5. Organizational Design (조직 설계)

클라우드 지향 팀 구조. Product team, DevOps team, Cloud Center of Excellence (CCoE).

전통:

Dev team -----> QA team -----> Ops team -----> Prod

클라우드 지향:

Product team (Dev + QA + Ops)
   ↓
CCoE (표준, 도구, 지원)

6. Organizational Alignment (조직 정렬)

여러 팀이 같은 목표 / 인센티브. 사일로 감소.

7. Team Enablement (팀 인에이블먼트)

셀프서비스 도구, 문서, 지원. 팀이 자율적으로 클라우드 활용.

Cloud portal (IaC 템플릿, 표준)
사내 Slack channel (#cloud-help)
Office hours

8. Continuous Learning (지속 학습)

기술은 계속 변함. 학습이 상시 프로세스.

Learning budget 개인/팀별
Conference/summit 참가
Book club, tech talk
Certification renewal

Cloud Center of Excellence (CCoE)

People perspective 의 핵심 조직 단위. 클라우드 관련 전문성 + 표준 + 지원 을 담당.

책임

Landing Zone / 계정 관리
표준 (naming, tagging, security)
Reusable IaC 모듈
교육 프로그램
팀 지원 (컨설팅, 페어링)
FinOps 리더십

조직 배치

Federated CCoE: 중앙 팀 + 각 사업부 embed. 규모 있는 조직.

Central CCoE: 하나의 중앙 팀. 시작 단계.

Hub-and-spoke: 중앙 CCoE + 각 팀의 champion. 균형.

AWS Certifications Path

Foundational:

AWS Certified Cloud Practitioner (모든 직원 권장)

Associate (기술직):

Solutions Architect Associate
Developer Associate
SysOps Administrator Associate

Professional (시니어):

Solutions Architect Professional
DevOps Engineer Professional

Specialty (전문):

Security, Advanced Networking, Machine Learning, Data Analytics, Database

AI 시리즈 (2024+):

AWS Certified AI Practitioner
AWS Certified Machine Learning Engineer Associate
AWS Certified Machine Learning Specialty

Learning Resources

AWS Skill Builder: 무료/유료 온라인 과정 (500+)
AWS Training Partners: 강의실 교육
AWS re:Invent, re:Inforce: 연례 컨퍼런스
AWS Immersion Days: 실습 세미나
AWS Well-Architected Labs: 실전 시나리오
AWS Workshops: 자율 실습

실전 활동

Envision

조직 문화 진단 (survey)
현재 스킬 인벤토리
리더십 커밋 확보

Align

CCoE 구조 설계
팀별 target skill 매핑
Learning path 정의

Launch

첫 팀 재교육 (pilot)
CCoE 시범 운영
문화 이니셔티브 (postmortem, tech talk)

Scale

전사 확장
지속 인에이블먼트 (매년 certification renewal)
채용 브랜딩 (클라우드 인재)

문화 변화 사례

DevOps 문화

Dev + Ops 팀 통합
“You build it, you run it”
Blameless postmortem

실험 문화

Two-pizza team
Feature flag 로 A/B
실패는 학습 기회

Data-driven 문화

결정을 데이터로
Dashboard 상시 참조
가설 -> 실험 -> 검증

흔한 실패 패턴

[!WARNING] 교육 없이 도입. IT 팀이 EC2, S3 밖에 몰라 클라우드 네이티브 서비스 (Lambda, EKS, Bedrock) 활용 못 함.

[!CAUTION] CCoE 를 통제 조직으로. Enabler 여야 하는데 “허가 게이트” 로 전락하면 팀 자율성 저해.

[!WARNING] 문화 변화는 몇 년 걸림. 기술 도입 (몇 개월) 대비 훨씬 오래. 인내와 리더십 지속.

[!IMPORTANT] 리더가 first mover. 임원 교육을 먼저 (Cloud Practitioner 등). 모범 없이 아래 요구 안 됨.

[!CAUTION] 인재 유출 리스크. 재교육받은 인재를 경쟁사가 스카웃. 커리어 트랙 + 대우 정비.

김신건의 로그 - 위키 / cloud

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

정의

사용 상황

관측 가능성 3가지 축

4가지 구성

Metrics

Embedded Metric Format (EMF)

Metric Math

CloudWatch Agent

Container Insights

Logs

Logs Insights (쿼리)

Subscription Filter

Alarms

Composite Alarm

Anomaly Detection

CloudWatch vs 3rd-party

비용 최적화

흔한 함정

관련 위키

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

정의

사용 상황

트리거 종류

함수 작성

실행 모델

Concurrency

Cold Start

Cold Start 완화

Memory & CPU

가격

Layers (공유 코드)

Lambda URLs

Lambda @ Edge / CloudFront Functions

Lambda Extensions

Lambda Powertools

Lambda 의 적합 / 부적합

흔한 함정

관련 위키

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

정의

사용 상황

ASL 예시

시각화

State 종류

Parallel State

Choice State

Standard vs Express

Map (배열 처리)

Distributed Map (2022+)

Wait for Callback

Saga 패턴 아키텍처

모니터링

Step Functions vs Temporal

흔한 함정

관련 위키

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

정의

사용 상황

ALB (Application Load Balancer)

NLB (Network Load Balancer)

선택 트리

Target Group

ALB Listener 규칙 우선순위

HTTPS / TLS 설정

Sticky Session

WAF 통합 (ALB 만)

ALB → Lambda

NLB + PrivateLink

Cross-Zone Load Balancing

Connection Draining (Deregistration Delay)

Access Log

CloudWatch 핵심 메트릭

흔한 함정

관련 위키

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

정의

동작 흐름

Origin 종류