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)
| 기둥 | 핵심 질문 |
|---|---|
| **Operational Excellence** | 어떻게 효율적으로 운영하나? |
| **Security** | 어떻게 데이터와 시스템을 보호하나? |
| **Reliability** | 장애에서 어떻게 회복하나? |
| **Performance Efficiency** | 자원을 어떻게 효율적으로 사용하나? |
| **Cost Optimization** | 어떻게 가치 대비 비용을 최소화하나? |
| **Sustainability** | 환경 영향을 어떻게 최소화하나? |
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 보안 도구
| 도구 | 용도 |
|---|---|
| **IAM** | 접근 제어 |
| **GuardDuty** | 위협 탐지 (ML 기반) |
| **Security Hub** | 보안 발견 사항 통합 |
| **Inspector** | 취약점 스캔 |
| **Macie** | S3 민감 데이터 탐지 |
| **WAF** | 웹 애플리케이션 방화벽 |
| **Shield** | DDoS 보호 |
| **Secrets Manager** | 비밀 관리 |
| **KMS** | 키 관리 |
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% | 87.6시간 | 7.2시간 |
| 99.9% (3 nines) | 8.76시간 | 43.8분 |
| 99.95% | 4.38시간 | 21.9분 |
| 99.99% (4 nines) | 52.6분 | 4.38분 |
| 99.999% (5 nines) | 5.26분 | 26.3초 |
**현실**:
- 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 | 비용 |
|---|---|---|---|
| **Backup & Restore** | 시간 | 시간 | 낮음 |
| **Pilot Light** | 분 | 분 | 보통 |
| **Warm Standby** | 분 | 초 | 높음 |
| **Multi-Site Active-Active** | 0 | 0 | 매우 높음 |
비즈니스가 견딜 수 있는 RTO/RPO를 정한 후 그에 맞는 전략 선택.
5. 기둥 4: Performance Efficiency
5.1 핵심
> "시스템 요구사항을 충족하기 위해 컴퓨팅 리소스를 효율적으로 사용하고, 수요 변화와 기술 진화에 따라 그 효율성을 유지하는 능력."
5.2 설계 원칙
1. **고급 기술의 민주화** — AI/ML, 빅데이터를 모두 사용 가능
2. **글로벌 배포** — 사용자에 가까이
3. **서버리스 우선** — 관리 부담 감소
4. **더 자주 실험** — 비교 테스트
5. **기술 친화** — 워크로드에 맞는 도구 선택
5.3 컴퓨트 선택
| 옵션 | 사용 사례 |
|---|---|
| **Lambda** | 짧은 작업, 이벤트 드리븐 |
| **Fargate** | 컨테이너, 서버 관리 X |
| **EC2** | 긴 작업, 커스텀 환경 |
| **ECS/EKS** | 컨테이너 오케스트레이션 |
| **Batch** | 대량 배치 작업 |
| **Lightsail** | 단순 웹 호스팅 |
5.4 스토리지 선택
| 옵션 | 용도 |
|---|---|
| **S3** | 객체 저장, 백업, 정적 파일 |
| **EBS** | EC2 블록 스토리지 |
| **EFS** | 공유 파일시스템 (NFS) |
| **FSx** | Windows/Lustre 파일시스템 |
| **Glacier** | 장기 아카이브 |
5.5 데이터베이스 선택
| 옵션 | 사용 사례 |
|---|---|
| **RDS** | 전통적 관계형 |
| **Aurora** | 고성능 RDS 호환 |
| **DynamoDB** | NoSQL, 단일 ms latency |
| **DocumentDB** | MongoDB 호환 |
| **ElastiCache** | Redis/Memcached 캐시 |
| **Neptune** | 그래프 DB |
| **Timestream** | 시계열 |
| **OpenSearch** | 검색, 로그 분석 |
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 비용 모니터링
| 도구 | 용도 |
|---|---|
| **Cost Explorer** | 비용 분석 시각화 |
| **Budgets** | 예산 알림 |
| **Cost and Usage Reports** | 상세 데이터 |
| **Trusted Advisor** | 비용 최적화 권장 |
| **Compute Optimizer** | EC2 사이즈 추천 |
| **Savings Plans Recommendations** | 절감 추천 |
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만 사용자
| 기둥 | 우선순위 | 결정 |
|---|---|---|
| Reliability | 높음 | Multi-AZ, Auto Scaling |
| Performance | 높음 | CloudFront + ElastiCache |
| Security | 높음 | WAF, KMS, MFA |
| Cost | 중간 | Reserved + Spot 혼합 |
| Operational | 중간 | IaC, CI/CD |
| Sustainability | 낮음 | Graviton 사용 |
9. Well-Architected Tool 사용
9.1 무료 자체 평가
AWS 콘솔에서 **Well-Architected Tool** 사용:
1. 워크로드 정의 (이름, 환경, region)
2. 6개 기둥에 대한 질문 답변 (~50개)
3. **개선 영역 식별**
4. 우선순위 결정
5. **개선 후 재평가**
9.2 Lens
**Lens** = 특정 워크로드/기술에 특화된 추가 가이드.
| Lens | 대상 |
|---|---|
| **Serverless Lens** | Lambda, API Gateway 기반 |
| **SaaS Lens** | 멀티테넌트 SaaS |
| **Machine Learning Lens** | ML 워크로드 |
| **Foundational Technical Review** | AWS Partner |
| **IoT Lens** | IoT 시스템 |
| **Streaming Media 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**
퀴즈
**답**: (1) **Operational Excellence** — 효율적 운영, (2) **Security** — 데이터/시스템 보호, (3) **Reliability** — 장애 회복, (4) **Performance Efficiency** — 자원 효율, (5) **Cost Optimization** — 가치 대비 비용, (6) **Sustainability** — 환경 영향 (2021 추가). 5개에서 시작했지만 환경 의식 증가로 Sustainability 추가. 모든 기둥이 동시에 100% 만족 불가 → 비즈니스 우선순위에 따라 트레이드오프.
**답**: **RTO (Recovery Time Objective)**: 장애 후 **복구까지 허용 시간**. 예: "30분 안에 복구해야 함." **RPO (Recovery Point Objective)**: **허용 가능한 데이터 손실**. 예: "최대 5분치 데이터까지 잃어도 OK." 둘 다 비즈니스 요구사항에서 도출. RTO/RPO가 작을수록 비용 폭증 (실시간 복제 = 비싸지만 RPO 0). 대부분의 시스템은 RTO 30분, RPO 1시간 정도.
**답**: Spot은 **언제든 종료될 수 있음** (보통 2분 알림). 안전한 사용: (1) **상태 비저장 워크로드** — 종료 시 데이터 손실 없음, (2) **체크포인트** — 작업 진행 상태 저장, (3) **Spot Fleet** — 여러 instance type 혼합, (4) **Auto Scaling Group with Mixed Instances** — On-Demand + Spot 자동 균형, (5) **Graceful shutdown 핸들러** — 종료 알림 받으면 정리. CI/CD, 배치 작업, 분석 작업에 이상적. **90% 비용 절감** 가능.
**답**: (1) **Graviton (ARM) 사용** — Intel 대비 60% 더 효율적, (2) **Auto Scaling** — 사용 안 할 때 자동 축소, (3) **S3 Lifecycle** — 오래된 데이터를 cold storage로, (4) **CDN** — 사용자에 가까이 = 적은 네트워크, (5) **재생 에너지 region 선택** — AWS Customer Carbon Footprint Tool 활용, (6) **유휴 자원 정리** — 사용 안 하는 EBS volumes, idle EC2. **효율적 코드 = 적은 탄소** = 더 적은 비용. 비용 절감과 자연스럽게 연결됩니다.
**답**: **Multi-AZ**: 한 region 안의 여러 가용 영역(AZ)에 배포. 한 AZ 장애에 자동 failover. 대부분 AWS 서비스가 지원 (RDS, ELB, ASG). 비용 증가 X (또는 약간). **Multi-Region**: 여러 region에 배포. 자연재해, 광역 장애, 규제 준수에 대비. 비용 2배+, 데이터 동기화 복잡 (DynamoDB Global Tables, Aurora Global Database). **99.99% 가용성은 Multi-AZ로 충분**, 99.999%는 Multi-Region 필요.
참고 자료
- [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)
- [Well-Architected Tool](https://aws.amazon.com/well-architected-tool/)
- [AWS Architecture Center](https://aws.amazon.com/architecture/)
- [AWS Solutions Library](https://aws.amazon.com/solutions/)
- [AWS Customer Carbon Footprint Tool](https://aws.amazon.com/aws-cost-management/aws-customer-carbon-footprint-tool/)
- [Cloud Adoption Framework](https://aws.amazon.com/professional-services/CAF/)
- [The Twelve-Factor App](https://12factor.net/) — 클라우드 네이티브 원칙
- [Site Reliability Engineering Book](https://sre.google/sre-book/table-of-contents/) — Google
- [AWS This is My Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) — 실전 사례
- [re:Invent 발표 영상들](https://www.youtube.com/c/AmazonWebServices)
- [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
현재 단락 (1/348)
- **6개 기둥**: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimizatio...