✍️ 필사 모드: AWS Well-Architected Framework 완전 가이드 2025: 6개 기둥, 실전 적용, 비용/보안/성능

TL;DR

• 6개 기둥: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability
• 트레이드오프: 모든 기둥을 100% 만족시킬 수 없음. 비즈니스 우선순위에 따라 결정
• Well-Architected Tool: AWS 콘솔에서 무료 자체 평가
• Sustainability (2021 추가): 환경 영향 고려. 효율적 코드 = 적은 탄소
• 모든 클라우드에 적용 가능: AWS의 프레임워크지만 GCP/Azure에서도 유효

1. Well-Architected Framework란?

1.1 배경

AWS가 수만 고객의 아키텍처를 본 후 정리한 모범 사례 가이드. 처음 5개 기둥, 2021년 Sustainability 추가하여 6개.

1.2 6개 기둥 (2025)

1.3 일반 원칙

5가지 일반 원칙 (모든 기둥에 적용):

1. 추측 대신 측정 — 데이터 기반 결정
2. 프로덕션 규모로 테스트 — staging은 작은 시스템, 프로덕션처럼 테스트
3. 자동화로 실험 빈도 증가 — 수동 작업 = 인적 실수
4. 진화하는 아키텍처 허용 — 한 번 만든 것이 영원하지 않음
5. 게임 데이로 운영 개선 — Chaos engineering

2. 기둥 1: Operational Excellence

2.1 핵심

"비즈니스 가치를 전달하기 위해 시스템을 효과적으로 운영하고 모니터링하며, 지속적으로 개선하는 능력."

2.2 설계 원칙

1. 운영을 코드로 (Operations as Code) — 인프라, 정책, 절차를 모두 코드화
2. 작고 빈번한 변경 — 큰 배포는 위험. 작은 단위로 자주
3. 운영 절차를 자주 개선 — 회고, 룬북 업데이트
4. 장애 예측 — 가능한 실패 모드 파악
5. 모든 운영 실패에서 배움 — 포스트모템

2.3 실전 체크리스트

계획:

• 비즈니스 목표가 명확한가?
• 메트릭으로 성공을 측정할 수 있는가?
• 운영 우선순위가 정의되어 있는가?

준비:

• 모든 인프라가 IaC (CloudFormation/Terraform)로?
• CI/CD 파이프라인이 있는가?
• 모니터링과 알림이 설정되어 있는가?

운영:

• 룬북이 최신 상태인가?
• On-call 절차가 명확한가?
• 장애 대응 시간이 측정되는가?

진화:

• 정기적인 retrospective?
• 카오스 엔지니어링 실시?
• 메트릭 기반 개선?

2.4 AWS 도구

• CloudFormation / CDK — IaC
• Systems Manager — 자동화 (런북, 패치)
• CloudWatch — 모니터링, 알림
• X-Ray — 분산 트레이싱
• Config — 리소스 변경 추적

3. 기둥 2: Security

3.1 핵심

"데이터, 시스템, 자산을 보호하면서 클라우드 기술로 비즈니스 가치를 전달."

3.2 설계 원칙

1. 강력한 신원 기반 구현 — IAM, MFA, 최소 권한
2. 모든 레이어에서 보안 적용 — Defense in depth
3. 저장 중 + 전송 중 데이터 암호화 — Encryption everywhere
4. 데이터에 사람 접근 제한 — 자동화 우선
5. 보안 이벤트 대비 — IR (Incident Response) 계획
6. 공유 책임 모델 이해 — AWS는 클라우드의 보안, 고객은 클라우드 안의 보안

3.3 IAM 모범 사례

❌ root 계정 사용
❌ 액세스 키를 코드에
❌ * 권한 부여
❌ 공유 사용자

✅ MFA 모든 사용자
✅ Role 기반 권한 (IAM Roles)
✅ 최소 권한 원칙
✅ Access Analyzer 사용
✅ 임시 자격증명 (STS)

3.4 데이터 보호

저장 중 (At rest):

• S3: 기본 SSE-S3, 또는 SSE-KMS
• EBS: 기본 암호화 활성화
• RDS: KMS 키로 암호화
• DynamoDB: 항상 암호화 (기본)

전송 중 (In transit):

• TLS 1.2+ 필수
• VPC 내부도 암호화 (Service mesh, mTLS)
• VPN/Direct Connect

3.5 네트워크 보안

[Public Subnet]    ← Internet Gateway
    ↓
[Private Subnet]   ← NAT Gateway (egress only)
    ↓
[Isolated Subnet]  ← DB만, 인터넷 없음

Security Group + NACL:

• Security Group: 인스턴스 레벨, stateful
• NACL: 서브넷 레벨, stateless

3.6 AWS 보안 도구

4. 기둥 3: Reliability

4.1 핵심

"워크로드가 의도된 대로 정확하고 일관되게 기능을 수행하는 능력."

4.2 설계 원칙

1. 장애에서 자동 복구 — Auto-healing
2. 복구 절차 테스트 — Chaos engineering
3. 수평 확장으로 가용성 증가 — 단일 큰 인스턴스 X
4. 용량 추측 중단 — Auto Scaling
5. 자동화로 변경 관리 — IaC

4.3 AWS 가용성 모델

Region: 지리적 영역 (us-east-1, ap-northeast-2) Availability Zone (AZ): Region 안의 격리된 데이터센터 (보통 3-6개) Edge Location: CloudFront PoP

Multi-AZ: 여러 AZ에 분산 → 한 AZ 장애에도 살아남음. Multi-Region: 여러 region → 자연재해, 광역 장애 대비.

4.4 가용성 목표

현실:

• 99.9% = 단일 인스턴스로 달성 어려움
• 99.99% = Multi-AZ + Auto Scaling
• 99.999% = Multi-Region + 정교한 failover

4.5 실전 패턴

ELB + Auto Scaling Group + Multi-AZ:

        [Route 53]
            ↓
       [ALB (multi-AZ)]
       /        |        \
   [EC2 az-a] [EC2 az-b] [EC2 az-c]
       ↓        ↓        ↓
       [RDS Multi-AZ Standby]

한 EC2 죽으면: ASG가 자동으로 새 인스턴스 시작. 한 AZ 죽으면: ALB가 다른 AZ로 트래픽 라우팅. Primary RDS 죽으면: Standby로 자동 failover.

4.6 RTO와 RPO

RTO (Recovery Time Objective): 복구까지 허용 시간 RPO (Recovery Point Objective): 허용 가능한 데이터 손실

비즈니스가 견딜 수 있는 RTO/RPO를 정한 후 그에 맞는 전략 선택.

5. 기둥 4: Performance Efficiency

5.1 핵심

"시스템 요구사항을 충족하기 위해 컴퓨팅 리소스를 효율적으로 사용하고, 수요 변화와 기술 진화에 따라 그 효율성을 유지하는 능력."

5.2 설계 원칙

1. 고급 기술의 민주화 — AI/ML, 빅데이터를 모두 사용 가능
2. 글로벌 배포 — 사용자에 가까이
3. 서버리스 우선 — 관리 부담 감소
4. 더 자주 실험 — 비교 테스트
5. 기술 친화 — 워크로드에 맞는 도구 선택

5.3 컴퓨트 선택

5.4 스토리지 선택

5.5 데이터베이스 선택

5.6 캐싱

계층적 캐싱:

1. CloudFront (CDN) — 전 세계 edge
2. API Gateway 캐시 — API 응답
3. ElastiCache (Redis) — 애플리케이션 캐시
4. DynamoDB DAX — DynamoDB 캐시
5. RDS Read Replica — 읽기 부하 분산

효과: 응답 시간 90%+ 감소, DB 부하 극단 감소.

6. 기둥 5: Cost Optimization

6.1 핵심

"최소 비용으로 비즈니스 가치를 전달하는 시스템."

6.2 설계 원칙

1. 클라우드 재정 관리 구현 — FinOps
2. 소비 모델 채택 — 사용한 만큼만
3. 전체 효율 측정 — Cost per business metric
4. 데이터센터 운영의 무거운 짐 해소 — 관리형 서비스 사용
5. 비용 분석과 책임 — 태깅, 분배

6.3 가격 모델

Compute (EC2):

• On-Demand: 가장 비쌈, 유연
• Reserved Instance (1-3년): 최대 75% 절감
• Savings Plans: 더 유연한 약정
• Spot: 최대 90% 절감, 중단 가능

스토리지 (S3):

• Standard: 자주 접근
• Standard-IA: 가끔 접근, 30% 저렴
• Glacier: 장기 보관, 95% 저렴
• Glacier Deep Archive: 최저가, 95%+ 저렴

6.4 비용 절감 전략

1. 우측 사이징 (Right-sizing):

aws compute-optimizer get-ec2-instance-recommendations

50% 사용률 EC2를 → 더 작은 인스턴스로.

2. Auto Scaling:

• 트래픽 적을 때 자동 축소
• 트래픽 많을 때 자동 확장
• 비용 = 사용량에 비례

3. Spot Instances:

• 배치 작업, CI/CD에 적합
• 90% 절감 가능
• 중단에 대비한 설계 필요

4. Reserved Instances / Savings Plans:

• 안정적 워크로드에 적합
• 1년 약정: 30% 절감
• 3년 약정: 60% 절감

5. S3 Lifecycle Policies:

{
  "Rules": [{
    "Id": "MoveToIA",
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER" },
      { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
    ]
  }]
}

6. 데이터 전송 비용 줄이기:

• 같은 region 내 transfer는 무료/저렴
• CloudFront 사용 (S3 직접보다 저렴)
• VPC Endpoints (NAT Gateway 회피)

6.5 비용 모니터링

6.6 태깅 전략

Environment: production
Project: ecommerce
Owner: team-checkout
CostCenter: 1234

→ Cost Explorer에서 태그별 비용 분석 가능.

7. 기둥 6: Sustainability (2021 추가)

7.1 핵심

"환경 영향, 특히 에너지 소비와 효율성을 다룸."

7.2 설계 원칙

1. 영향 이해 — 어디서 탄소를 배출하나?
2. 지속가능성 목표 설정 — 측정 가능한 목표
3. 사용량 극대화 — 유휴 자원 최소화
4. 새 효율적 기술 채택 — Graviton, ARM
5. 관리형 서비스 사용 — AWS의 효율성 활용
6. 다운스트림 영향 줄이기 — 사용자에게 효율적

7.3 지속가능성 메트릭

• 탄소 발자국 (Carbon Footprint)
• 사용자당 에너지 (가장 효율적)
• 유휴 자원 비율
• 데이터 전송 최적화

7.4 실전 적용

1. 효율적인 instance type 선택:

• Graviton (ARM) — Intel/AMD 대비 60% 더 효율적
• 같은 성능에 적은 전력

2. 자동 스케일링:

• 사용 안 할 때 종료
• 야간 자동 종료 (개발 환경)

3. Object Lifecycle:

• 오래된 데이터를 cold storage로
• 사용 안 하는 데이터 삭제

4. CDN 사용:

• 사용자에 가까이 → 적은 네트워크 = 적은 에너지

5. Region 선택:

• 재생 에너지 비율이 높은 region 선택
• AWS Customer Carbon Footprint Tool

7.5 AWS의 약속

• 2025년까지 100% 재생 에너지
• 2040년까지 net-zero carbon
• 효율적 데이터센터 설계

8. 트레이드오프 다루기

8.1 기둥 간 충돌

보안 vs 성능:

• 강한 암호화 → 약간의 CPU 비용
• 결정: 데이터 민감도에 따라

비용 vs 신뢰성:

• Multi-region = 비용 2배+
• 결정: SLA에 따라

성능 vs 비용:

• 큰 인스턴스 = 빠름 + 비쌈
• 결정: 응답 시간 요구사항

운영 우수성 vs 비용:

• 모든 자동화 = 초기 비용
• 결정: 장기 ROI

8.2 의사결정 프레임워크

각 결정에 대해:

1. 비즈니스 목표: 무엇이 중요한가?
2. 각 기둥에 대한 영향: 어떤 기둥이 영향 받나?
3. 트레이드오프: 무엇을 포기하나?
4. 위험: 잘못되면?
5. 반복 가능성: 결정 변경 비용?

8.3 예시

시나리오: e-commerce 사이트, 일일 100만 사용자

9. Well-Architected Tool 사용

9.1 무료 자체 평가

AWS 콘솔에서 Well-Architected Tool 사용:

1. 워크로드 정의 (이름, 환경, region)
2. 6개 기둥에 대한 질문 답변 (~50개)
3. 개선 영역 식별
4. 우선순위 결정
5. 개선 후 재평가

9.2 Lens

Lens = 특정 워크로드/기술에 특화된 추가 가이드.

9.3 Well-Architected Review

AWS Solutions Architect와 함께 (무료 또는 파트너):

1. 아키텍처 검토
2. 6개 기둥 평가
3. 우선순위 권장사항
4. 개선 로드맵

10. 안티패턴 카탈로그

10.1 운영 안티패턴

❌ 수동 배포 — 인적 실수의 원인 ✅ CI/CD 파이프라인

❌ 로컬에서만 테스트 ✅ 프로덕션 유사 환경에서 테스트

❌ 장애 후 회고 없음 ✅ Blameless postmortem

10.2 보안 안티패턴

❌ 루트 계정 사용 ✅ IAM 사용자 + Role

❌ 모든 사용자에게 : 권한 ✅ 최소 권한 원칙

❌ 하드코딩된 자격증명 ✅ Secrets Manager / Parameter Store

❌ HTTP만 사용 ✅ HTTPS 강제, HSTS

10.3 신뢰성 안티패턴

❌ 단일 AZ 배포 ✅ Multi-AZ 최소

❌ 백업 없음 또는 복원 테스트 없음 ✅ 정기 백업 + 복원 훈련

❌ 단일 장애점 (single point of failure) ✅ 모든 컴포넌트 다중화

10.4 성능 안티패턴

❌ 대형 인스턴스로 모든 것 ✅ 워크로드별 적절한 인스턴스

❌ 캐싱 없음 ✅ CloudFront + ElastiCache

❌ 모든 것이 동기 ✅ 적절한 비동기 처리

10.5 비용 안티패턴

❌ 모든 것을 On-Demand ✅ Reserved/Savings/Spot 혼합

❌ 태그 없음 ✅ 일관된 태깅 전략

❌ 사용 안 하는 자원 방치 ✅ 정기적 정리, AWS Trusted Advisor

퀴즈

참고 자료

• AWS Well-Architected Framework
• Well-Architected Tool
• AWS Architecture Center
• AWS Solutions Library
• AWS Customer Carbon Footprint Tool
• Cloud Adoption Framework
• The Twelve-Factor App — 클라우드 네이티브 원칙
• Site Reliability Engineering Book — Google
• AWS This is My Architecture — 실전 사례
• re:Invent 발표 영상들
• AWS Trusted Advisor