Files
llm-wiki/raw/official-docs/scorecard-aws-well-architected.md
T

107 lines
8.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: AWS Well-Architected Framework — 공식 페이지
source_type: official-doc
url: https://aws.amazon.com/architecture/well-architected/
archive_url:
status: raw
confidence: high
tags: [scorecard, readiness, well-architected, aws, ca-skeleton, official-doc]
related_projects: [ca-skeleton]
related_branches: [feature-implementation-readiness-scorecard]
created: 2026-05-25
last_reviewed: 2026-05-27
---
# AWS Well-Architected Framework — 공식 페이지
> Layer: `raw/official-docs/` — AWS Well-Architected 공식 페이지 발췌. ca-tmpl 결정(15 area binary pass/fail) 대안인 질문 기반 review 모델 평가용.
## Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-implementation-readiness-scorecard]] | 15 area × binary pass/fail 채택 — AWS WAR 의 질문 기반 + HRI flag 모델을 비교 대안으로 명시하여 binary 선택 근거 강화 |
추가 foundational 인용:
- [[raw/project-notes/ca-skeleton-operational-contract]] — §27 "100점 Readiness Scorecard" 조항이 WAR-style 의 회색 지대 평가와 달리 **binary adoption gate** 임을 명문화하기 위한 1차 근거
## 컨텍스트
`feature-implementation-readiness-scorecard` 의 ca-tmpl 은 **15 area × binary pass/fail + 1:1 branch evidence mapping + manual evidence column** 을 택했다. AWS Well-Architected 는 **6 pillar × 질문 기반 review + HRI(High Risk Issues) flagging** 으로 작동하는 비-binary 평가 모델이다. 두 접근의 trade-off 를 명문화.
## 출처 / Source
- 원본 URL: https://aws.amazon.com/architecture/well-architected/
- 아카이브 URL: (미수집)
- 저자 / 조직: AWS (Amazon Web Services)
- 발행일: 지속적으로 갱신 (6-pillar 버전, Sustainability pillar 포함)
- 마지막 확인일: 2026-05-27
## 핵심 인용 / Key quotes (verbatim)
> [§AWS Well-Architected and the Six Pillars] "Built around six pillars—operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability"
> [§Framework Overview] "By answering a few foundational questions, learn how well your architecture aligns with cloud best practices and gain guidance for making improvements."
> [§Overview] "The AWS Well-Architected Tool, available at no cost in the AWS Management Console, provides a mechanism for regularly evaluating workloads"
> [§Overview] "[The Tool provides] a mechanism for regularly evaluating workloads, identifying high-risk issues, and recording improvements."
> [§Framework Overview] "The AWS Well-Architected Framework describes key concepts, design principles, and architectural best practices for designing and running workloads in the cloud."
## Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SC-AWS-WAR-C1 | AWS Well-Architected Framework 는 6개 pillar (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability) 로 구성됨 | [§AWS Well-Architected and the Six Pillars] "Built around six pillars—operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability" | `official-vendor-doc` | AWS Cloud workload 설계 평가 | 6 pillar 가 모든 cloud / on-prem 환경의 universal taxonomy 라는 뜻은 아님 — AWS 특화 |
| SC-AWS-WAR-C2 | WAR 의 평가 방식은 "foundational questions 에 답하는" 질문 기반 방식이며, 결과로 cloud best practice 와의 정렬도를 학습하고 개선 가이드를 얻음 | [§Framework Overview] "By answering a few foundational questions, learn how well your architecture aligns with cloud best practices and gain guidance for making improvements." | `official-vendor-doc` | WAR review session (architect 가 응답) | 질문 응답이 자동 채점되어 binary pass/fail 점수로 환산된다는 뜻 아님 — 질문 응답 기반 평가 |
| SC-AWS-WAR-C3 | AWS Well-Architected Tool 은 AWS Management Console 에서 무료로 제공되며, workload 를 정기적으로 평가하는 메커니즘을 제공 | [§Overview] "The AWS Well-Architected Tool, available at no cost in the AWS Management Console, provides a mechanism for regularly evaluating workloads" | `official-vendor-doc` | AWS Management Console 사용 환경 | Tool 자체가 CI/CD 파이프라인에 binary gate 로 통합된다는 의미는 아님 |
| SC-AWS-WAR-C4 | WAR Tool 은 (a) workload 정기 평가, (b) high-risk issues 식별, (c) improvements 기록의 세 가지 기능을 제공 | [§Overview] "[The Tool provides] a mechanism for regularly evaluating workloads, identifying high-risk issues, and recording improvements." | `official-vendor-doc` | WAR Tool 사용 review | HRI 가 binary pass/fail 의 fail 항목과 동일 의미라는 뜻 아님 — HRI 는 위험 flag, fail 점수 아님 |
| SC-AWS-WAR-C5 | WAR Framework 는 cloud workload 설계/운영의 (a) key concepts, (b) design principles, (c) architectural best practices 를 기술 | [§Framework Overview] "The AWS Well-Architected Framework describes key concepts, design principles, and architectural best practices for designing and running workloads in the cloud." | `official-vendor-doc` | cloud workload 일반 가이던스 | Framework 가 비-AWS workload 에도 그대로 적용 가능하다는 보장은 아님 |
## Usage Boundaries / 적용 경계
- **이 자료가 직접 증명하는 것**:
- `SC-AWS-WAR-C1`: 6 pillar 의 정확한 명칭과 구성
- `SC-AWS-WAR-C2`: WAR 의 평가 모델이 "질문 기반" 이라는 사실 (= ca-tmpl 의 binary 모델과의 본질적 차이)
- `SC-AWS-WAR-C3` ~ `C4`: WAR Tool 의 가용성과 HRI 식별 기능
- `SC-AWS-WAR-C5`: Framework 가 best practice 를 "describes" 한다 (= prescriptive binary gate 가 아닌 descriptive guidance)
- **이 자료가 증명하지 않는 것**:
- WAR 가 binary scoring 보다 우월/열등하다는 비교 판단 (두 모델은 목적이 다름)
- HRI 의 정확한 분류 기준 / 가중치 / 등급 정의 (별도 WAR Tool 문서 참조 필요)
- 6 pillar 각각의 design principle / question 목록 (각 pillar 별 백서 별도 존재)
- 본 페이지가 ca-tmpl 의 15 area taxonomy 와 1:1 매핑 가능한 6 pillar 라는 사실 (taxonomy 의 단위가 다름)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
- ca-tmpl 의 15 area 중 어느 area 가 WAR pillar 어디에 매핑되는지 (수작업 매핑)
- HRI 가 ca-tmpl 의 "미통과 area 를 숨기는 것 금지" Forbidden 항목과 어떻게 다른지 (HRI = flag, ca-tmpl fail = release-blocking)
- WAR Sustainability pillar 가 ca-tmpl 에 추가 area 로 들어갈 가치가 있는지
## 메모 / Notes (내 프로젝트 해석)
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- AWS WAR 핵심 특징 (인용 + 해석):
- **질문 기반** (`SC-AWS-WAR-C2`) — review session 에서 architect 가 질문 list 에 답함.
- **HRI 식별** (`SC-AWS-WAR-C4`) — 점수가 아니라 위험 항목 flag.
- **non-binary** — "improvement opportunity" 단계가 존재 (`SC-AWS-WAR-C5` 의 "guidance for making improvements" 에서 추론).
- 본 skeleton 의 차이:
- **binary pass/fail** (15 area 전부 pass = 100). 부분 점수 없음.
- **1:1 branch evidence mapping** — 각 area 를 owner branch 에 묶음.
- **manual evidence column 필수** — 자동화는 optional.
- trade-off:
- WAR 모델 장점: 현실 아키텍처는 회색 지대가 많고 점진적 개선이 자연스러움 (`SC-AWS-WAR-C5` 의 descriptive 성격).
- 본 skeleton 의 binary 모델 장점: **"adoption ready" 선언이 모호하지 않음**. 통과 못한 area 를 숨길 수 없음 (= 본 branch 의 Forbidden 항목 "미통과 항목을 숨기고 100점으로 선언").
- 결론: 본 skeleton 은 **adoption gate** 성격이므로 binary 가 합당. WAR-style 은 **운영 중 지속적 개선** 에 적합. 같은 도구의 다른 목적.
## Related / 관련
- 같은 주제 다른 official-doc:
- [[raw/official-docs/scorecard-cis-benchmarks-slsa]] — Group G-G 대안 3 (외부 표준 점수 체계)
- [[raw/official-docs/scorecard-opentelemetry-maturity]] — Group G-G 대안 2 (signal lifecycle 모델)
- 인용하는 branch:
- [[raw/branch-notes/feature-implementation-readiness-scorecard]] — Group G-G 대안 1 (질문 기반 HRI flag)
- canonical contract 섹션:
- [[raw/project-notes/ca-skeleton-operational-contract]] §27 "100점 Readiness Scorecard"
- 인용하는 wiki: (미작성)