관리형 서비스

학습 목표

RDS·ElastiCache의 HA·연결·VPC 배치를 설계할 수 있다.

S3 오브젝트 스토리지와 스토리지 클래스·라이프사이클을 워크로드에 맞게 선택할 수 있다.

SQS·SNS로 비동기·fan-out 메시징을 설계할 수 있다.

Lambda 이벤트 모델·cold start·VPC 연동 트레이드오프를 설명할 수 있다.

직접 운영 vs 관리형 선택 기준을 비용·운영·제어 관점에서 비교할 수 있다.

문제 상황

• EC2에 PostgreSQL 직접 — 패치·백업·장애 복구 올인
• RDS public 접근 허용 — 16편 VPC 설계 무력화
• 캐시 없이 DB 조회 폭주 — p99 급등·connection pool 고갈
• 로그·백업을 EBS에 쌓음 — 용량·비용 선형 증가
• 주문 API 동기로 이메일·정산 처리 — 타임아웃·재시도 폭주
• Lambda VPC 연결 — cold start↑·ENI 한도·NAT 비용

앞서 VPC·subnet·SG — 관리형 서비스도 동일 네트워크 경계 안에 둔다. 이번 편은 DB·스토리지·메시징·Serverless 대표 관리형 스택이다.

1. RDS와 ElastiCache

RDS(Relational Database Service) — MySQL·PostgreSQL·Aurora 등 관리형 RDB. 패치·백업·스냅샷·Multi-AZ failover를 AWS가 담당.

옵션
Single-AZ	개발·비용 최소 — AZ 장애 다운
Multi-AZ	동기 standby — 자동 failover (수 분)
Read replica	읽기 분산·리전 복제 — failover 대상 아님 (설정 가능)
Aurora	스토리지 자동 확장·reader endpoint

# code/rds.example.tf
resource "aws_db_subnet_group" "main" {
  name       = "app-db"
  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
}

resource "aws_db_instance" "main" {
  identifier             = "app-postgres"
  engine                 = "postgres"
  instance_class         = "db.t4g.medium"
  allocated_storage      = 100
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.rds.id]
  multi_az               = true
  backup_retention_period = 7
  storage_encrypted      = true
  publicly_accessible    = false
}

배치
Subnet	private only — db subnet group multi-AZ
SG	5432 from app SG only
Endpoint	writer vs reader — ORM·pool 분리
K8s	Secret에 DSN — ConfigMap 금지

ElastiCache — Redis·Memcached 관리형 인메모리 캐시.

App read:
  1. GET cache key
  2. hit  → return
  3. miss → SELECT DB → SET cache (TTL) → return

패턴
Cache-aside	앱이 캐시 직접 관리 — 가장 흔함
Write-through	쓰기 시 캐시+DB 동시
TTL	stale 허용 범위 명시
invalidation	업데이트 시 키 삭제·버전

실수
캐시 = source of truth	영속 데이터 유실
RDS·Redis 같은 SG 과다 개방	least privilege
connection storm	pool 크기·RDS max_connections

• Database 시리즈 — 복제·트랜잭션·인덱스 심화
• 16편 — RDS private subnet·SG 참조

2. S3 오브젝트 스토리지

S3 — 무제한 스케일 오브젝트 스토리지. 버킷·키·버전·라이프사이클.

용도	패턴
정적 자산	CloudFront + S3 — 이미지·SPA 빌드
백업·로그	앱 → S3 — Glacier 이관
데이터 레이크	ingest → S3 → Athena·Spark
아티팩트	CI 빌드 산출물·Terraform state (잠금 별도)

# code/s3-bucket.example.tf
resource "aws_s3_bucket" "app_assets" {
  bucket = "myapp-assets-prod"
}

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

resource "aws_s3_bucket_server_side_encryption_configuration" "app_assets" {
  bucket = aws_s3_bucket.app_assets.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

스토리지 클래스
Standard	자주 접근
Standard-IA	월 1회 미만 — 최소 보관·검색 요금
Glacier	아카이브 — 복구 시간 분~시간
Intelligent-Tiering	접근 패턴 자동 이동

보안
Block Public Access	기본 ON 유지
IAM·bucket policy	least privilege
presigned URL	시간 제한 업로드·다운로드
VPC Endpoint	NAT 우회 — 16편

• K8s — CSI driver로 S3 마운트 (특수 케이스)
• EBS·PV (9편) — 블록 스토리지 vs S3 오브젝트

3. SQS와 SNS

메시징 — 동기 API 결합 완화·피크 흡수·재시도 분리.

서비스
SQS	큐 — 1 consumer 그룹·at-least-once
SNS	토픽 pub/sub — fan-out
조합	SNS → 여러 SQS — 서비스 별 독립 처리

# code/sqs-sns.example.tf
resource "aws_sns_topic" "orders" {
  name = "orders-events"
}

resource "aws_sqs_queue" "billing" {
  name = "orders-billing"
}

resource "aws_sns_topic_subscription" "billing" {
  topic_arn = aws_sns_topic.orders.arn
  protocol  = "sqs"
  endpoint  = aws_sqs_queue.billing.arn
}

개념
Visibility timeout	처리 중 숨김 — 실패 시 재노출
DLQ	N회 실패 → 격리·조사
FIFO	순서·exactly-once (처리량 제한)
idempotency	at-least-once → 중복 처리 대비 필수

Order API → SNS topic "order.placed"
              ├→ SQS billing queue   → worker
              ├→ SQS email queue     → worker
              └→ SQS analytics queue → Lambda

vs K8s
관리형 큐	운영 부담↓ — 벤더 락인
Kafka·RabbitMQ in cluster	제어↑·운영 직접
EDA	Architecture 이벤트 기반 설계

4. Lambda와 Serverless

Lambda — 이벤트 트리거 시 코드 실행. 서버 프로비저닝 없음·사용량 과금.

트리거	예
API Gateway	HTTP API·BFF
SQS	큐 폴링 워커
S3	업로드 후 리사이즈·스캔
EventBridge	스케줄·크로스 서비스 라우팅

# code/lambda.example.tf
resource "aws_lambda_function" "processor" {
  function_name = "order-processor"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "handler.main"
  runtime       = "python3.12"
  timeout       = 30
  memory_size   = 256

  vpc_config {
    subnet_ids         = [aws_subnet.private_a.id]
    security_group_ids = [aws_security_group.lambda.id]
  }
}

resource "aws_lambda_event_source_mapping" "sqs" {
  event_source_arn = aws_sqs_queue.billing.arn
  function_name    = aws_lambda_function.processor.arn
  batch_size       = 10
}

트레이드오프
Cold start	메모리↑·SnapStart (Java)·프로비저닝
VPC 연결	RDS 접근 가능 — ENI·지연↑
Timeout	최대 15분 — 장기 배치 부적합
State	무상태 — DB·S3·DynamoDB에 상태

Serverless 적합	부적합
이벤트 처리·웹훅	장시간 CPU 바운드
간헐 트래픽	예측 가능 고정 부하 (EC2·K8s 저렴)
파일 변환·ETL 조각	저지연 항상 온 API (warm 필요)

• PaaS (15편) — Lambda는 FaaS 층
• 14편 IaC — Lambda·IAM 함께 코드화

5. VPC와 연동

관리형 서비스마다 VPC 안에 둘지·밖에서 API로 붙일지가 다르다.

서비스	VPC 내	접근
RDS	subnet group 필수	private endpoint
ElastiCache	subnet group	SG 6379
S3	리전 서비스	endpoint·IAM
SQS/SNS	리전 API	IAM·resource policy
Lambda	선택 VPC	RDS 시 필요

EKS (private) ──SG──► RDS / ElastiCache
                    ──IAM──► S3 / SQS / SNS
Lambda (VPC)    ──SG──► RDS
Lambda (no VPC) ──API──► public AWS endpoints only

Endpoint	효과
S3 Gateway	NAT 비용↓
SQS/SNS Interface	private subnet에서 API 호출
RDS	퍼블릭 엔드포인트 비활성 권장

6. 직접 운영 vs 관리형

	EC2 + OSS	관리형
운영	패치·백업·HA 직접	AWS 담당
제어	버전·튜닝 자유	파라미터 그룹 범위
비용	인스턴스 고정	인스턴스+I/O·요청
팀 규모	DBA 있으면 혼합	소규모 팀 선호

선택 힌트
표준 RDB 요구	RDS
초고 QPS 캐시	ElastiCache
대용량 파일·로그	S3
비동기 decouple	SQS/SNS
짧은 이벤트 핸들러	Lambda

7. 실무 체크리스트

항목	확인
RDS	Multi-AZ? backup retention? public false?
Cache	TTL·invalidation? hot key?
S3	encryption·versioning·lifecycle? public block?
Queue	DLQ? visibility timeout ≥ 처리 시간?
Lambda	idempotent? VPC 필요 여부? timeout·memory?
IAM	resource policy·least privilege?
비용	NAT·GB 이송·Lambda GB-sec 모니터?

8. 정리

• RDS Multi-AZ + private subnet — 앱 데이터 계층 표준
• ElastiCache cache-aside — 읽기 부하·지연 완화
• S3 — 오브젝트·백업·정적 자산·데이터 레이크
• SQS/SNS — 비동기·fan-out·DLQ·멱등
• Lambda — 이벤트 드리븐·VPC 트레이드오프 이해
• 다음 — Well-Architected 6 pillars·실무 체크리스트

다음에 다룰 것

• 운영·보안·안정성·성능·비용·지속가능성
• Well-Architected 실무 점검

---

해당 내용은 AWS RDS User Guide, Amazon S3 User Guide, AWS Lambda Developer Guide 의 내용을 기반으로 합니다.