📌 結論：Well-Architected = 「6本柱の設計思想」
AWS Well-Architected フレームワークは、
AWSでシステムを構築する際の「設計の教科書」です。
🏠 家を建てるときに「耐震性」「防犯」「省エネ」を考えるように、
🖥️ システムを構築するときも6つの重要な観点で設計しましょう！
運用上の優秀性
システムを効率よく
運用・改善する力
運用・改善する力
セキュリティ
データとシステムを
守る力
守る力
信頼性
障害に負けず
動き続ける力
動き続ける力
パフォーマンス効率
リソースを効率的に
使う力
使う力
コスト最適化
無駄なく賢く
お金を使う力
お金を使う力
持続可能性
環境に優しく
効率的に運用する力
効率的に運用する力
⏱️ 3秒で分かる！Well-Architected
何？
AWSが公式に提供する
「システム設計のベストプラクティス集」
「システム設計のベストプラクティス集」
なぜ使う？
設計の落とし穴を避けて
「良いシステム」を作るため
「良いシステム」を作るため
どう使う？
6つの柱でチェックして
継続的に改善する
継続的に改善する
🏠 「理想の家」で理解する6本の柱
Well-Architectedフレームワークは、「理想の家を建てる」のと同じです！
どんなに立派な見た目でも、基礎がしっかりしていないと崩れてしまいます。
🏠 理想のシステム（Well-Architected）
管理人室（運用上の優秀性）
家全体を見守り、問題があればすぐ対応。定期的にメンテナンスして住み心地を改善。
Operational Excellence
セキュリティシステム（セキュリティ）
泥棒から家を守る防犯カメラ、鍵、警報システム。誰が入れるかを厳密に管理。
Security
耐震構造（信頼性）
地震や台風が来ても倒れない頑丈な構造。壊れてもすぐ修理できる設計。
Reliability
動線設計（パフォーマンス効率）
キッチンから食卓への最短ルート。無駄のない効率的な間取り設計。
Performance Efficiency
予算管理（コスト最適化）
必要な機能に適切な投資。高級材料を使う場所と節約する場所のバランス。
Cost Optimization
省エネ設計（持続可能性）
太陽光発電、断熱材、LED照明。環境に優しく、長期的にコストも削減。
Sustainability
😱 → 😊 Before/After：悪い設計 vs 良い設計
❌
悪い設計（Before）
- 😰 単一AZにすべてのリソースを配置 → 障害時に全停止
- 😰 rootアカウントを日常使用 → セキュリティリスク大
- 😰 手動でサーバー構築 → 再現性なし、ミス多発
- 😰 固定サイズのEC2のみ → リソースの無駄遣い
- 😰 ログを取っていない → 問題発生時に原因不明
- 😰 コスト管理なし → 請求書を見てびっくり
Well-Architected
適用 ➡️
適用 ➡️
✅
良い設計（After）
- 😊 マルチAZ構成 → 1つのAZが落ちても継続稼働
- 😊 IAMユーザー＋MFA → 最小権限で安全運用
- 😊 IaCで自動構築 → いつでも同じ環境を再現
- 😊 Auto Scaling → 負荷に応じて自動調整
- 😊 CloudWatch + CloudTrail → 全て記録・監視
- 😊 Cost Explorer + 予算アラート → コスト見える化
⚙️ 柱1：運用上の優秀性（Operational Excellence）
たとえ話：優秀なビル管理人
24時間ビルの状態を監視し、エレベーターの異常を即座に検知。
定期的なメンテナンスで故障を予防し、住人からのフィードバックで改善を続ける。
「問題が起きる前に対処する」「常に改善を続ける」のがプロの管理人です。
定期的なメンテナンスで故障を予防し、住人からのフィードバックで改善を続ける。
「問題が起きる前に対処する」「常に改善を続ける」のがプロの管理人です。
📊 運用の改善サイクル
監視・計測
→
分析・理解
→
改善・自動化
→
検証・学習
→
繰り返し
1
ビジネス成果でチームを編成
技術ではなくビジネス目標を共有するチームを作る。DevOpsの実践。
2
観測可能性を実装
システムの状態を常に把握できるようにメトリクス、ログ、トレースを収集。
3
安全に自動化
変更をスクリプト化し、人的ミスを排除。IaCでインフラもコード管理。
4
小さく可逆的な変更
大きな変更より小さな変更を頻繁に。問題時はすぐロールバック。
5
障害を予測して対処
GameDayやカオスエンジニアリングで障害時の対応を事前に訓練。
6
すべての運用イベントから学ぶ
障害後のポストモーテムで根本原因を分析し、再発防止策を実施。
🛠️
関連AWSサービス
CloudWatch
CloudTrail
Systems Manager
CloudFormation
CodePipeline
X-Ray
✅
実践チェックリスト
- CloudWatchでメトリクスとアラームを設定しているか？
- CloudFormation/Terraformでインフラをコード管理しているか？
- CI/CDパイプラインで自動デプロイしているか？
- 障害時のランブック（手順書）を用意しているか？
- 障害後のポストモーテム（振り返り）を実施しているか？
🚫
アンチパターン（やってはいけない）
❌
手動オペレーション依存
毎回手動でサーバー構築。人によって手順が違う。
❌
ログを見ていない
問題が起きてから「ログが無い」と気づく。
❌
大きなリリース
数ヶ月分の変更を一度にリリース。問題時に切り分け困難。
🔐 柱2：セキュリティ（Security）
たとえ話：銀行の金庫室
銀行の金庫室は何重もの防御で守られています。
入口には警備員（認証）、金庫には鍵（暗号化）、監視カメラ（ログ）、金庫室への入室記録（監査）。
「多層防御」「最小権限」「全て記録」がセキュリティの基本です。
入口には警備員（認証）、金庫には鍵（暗号化）、監視カメラ（ログ）、金庫室への入室記録（監査）。
「多層防御」「最小権限」「全て記録」がセキュリティの基本です。
🛡️ 多層防御（Defense in Depth）
エッジ層
WAF/Shield
WAF/Shield
→
ネットワーク層
VPC/SG
VPC/SG
→
認証・認可層
IAM/Cognito
IAM/Cognito
→
データ層
KMS暗号化
KMS暗号化
1
強力なアイデンティティ基盤
最小権限の原則。IAMポリシーで必要な権限のみ付与。MFAを必須化。
2
トレーサビリティを確保
CloudTrailで全てのAPI呼び出しを記録。誰が何をしたか追跡可能に。
3
全レイヤーでセキュリティ
ネットワーク、OS、アプリ、データの各層で防御。一点突破されても被害を限定。
4
セキュリティを自動化
Security Hubで自動チェック。GuardDutyで脅威を自動検出。
5
転送中・保存時のデータ保護
TLSで通信を暗号化。KMSでデータを暗号化。鍵は厳重に管理。
6
人をデータから遠ざける
直接アクセスを減らし、自動化されたツール経由でのみ操作。
🛠️
関連AWSサービス
IAM
KMS
GuardDuty
Security Hub
WAF
Secrets Manager
✅
実践チェックリスト
- rootアカウントにMFAを設定し、日常使用していないか？
- IAMポリシーで最小権限を付与しているか？
- CloudTrailを全リージョンで有効化しているか？
- S3バケットのパブリックアクセスをブロックしているか？
- 保存データをKMSで暗号化しているか？
🚫
アンチパターン（やってはいけない）
❌
rootアカウントの日常使用
何でもできるアカウントを毎日使うのは危険すぎる。
❌
広すぎる権限（*:*）
「とりあえず全部許可」は侵害時の被害を最大化。
❌
パスワードのハードコーディング
コードにパスワードを直接書く。GitHubに流出したら終わり。
💪 柱3：信頼性（Reliability）
たとえ話：病院の電源システム
病院の手術室は絶対に停電させてはいけません。
メイン電源が落ちても、バックアップ発電機が自動で起動。さらに非常用バッテリーもある。
「絶対に止まらない」「壊れても自動回復」が信頼性の本質です。
メイン電源が落ちても、バックアップ発電機が自動で起動。さらに非常用バッテリーもある。
「絶対に止まらない」「壊れても自動回復」が信頼性の本質です。
🔄 障害時の自動回復フロー
障害発生
→
ヘルスチェック
異常検知
異常検知
→
トラフィック
切り替え
切り替え
→
自動復旧
スケールアウト
スケールアウト
→
正常稼働
1
障害から自動回復
ヘルスチェックで異常を検知し、自動でインスタンス置換やフェイルオーバー。
2
復旧手順をテスト
DR訓練を定期実施。バックアップからの復元を実際に試す。
3
水平スケーリング
単一の巨大インスタンスではなく、小さなインスタンスを複数並べる。
4
キャパシティの推測をやめる
Auto Scalingで需要に応じて自動調整。過剰プロビジョニング不要。
5
変更管理を自動化
インフラ変更もCI/CDで自動化。人的ミスによる障害を防止。
🛠️
関連AWSサービス
ELB
Auto Scaling
Route 53
RDS Multi-AZ
S3 (99.999999999%)
AWS Backup
✅
実践チェックリスト
- マルチAZ構成になっているか？
- Auto Scalingでスケールアウト/インが設定されているか？
- バックアップを定期的に取得しているか？
- 復旧手順を実際にテストしているか？
- RTO/RPOの目標を定義し、達成できる設計か？
🚫
アンチパターン（やってはいけない）
❌
単一AZへの依存
1つのAZに全てを配置。AZ障害で全システムダウン。
❌
バックアップの未テスト
バックアップはあるが復元テストしたことがない。
❌
単一障害点（SPOF）
1台のサーバーに全てを依存。壊れたら終わり。
🚀 柱4：パフォーマンス効率（Performance Efficiency）
たとえ話：F1レーシングチーム
F1チームは常に最高のパフォーマンスを追求します。
コースに合わせてタイヤを選び、気温に合わせてセッティングを変え、データを分析して改善。
「適材適所」「常に最新技術を活用」「データ駆動の改善」がパフォーマンスの鍵です。
コースに合わせてタイヤを選び、気温に合わせてセッティングを変え、データを分析して改善。
「適材適所」「常に最新技術を活用」「データ駆動の改善」がパフォーマンスの鍵です。
1
高度な技術を民主化
機械学習やDBクラスターなど、マネージドサービスで簡単に利用可能に。
2
数分でグローバル展開
CloudFrontで世界中にエッジロケーション。ユーザーに近い場所から配信。
3
サーバーレスアーキテクチャ
LambdaやFargateでサーバー管理不要。コードに集中できる。
4
頻繁に実験する
異なるインスタンスタイプやサービスを比較。最適解を見つける。
5
メカニカルシンパシー
サービスの仕組みを理解して使う。Graviton2など最新技術を活用。
🛠️
関連AWSサービス
CloudFront
Lambda
ElastiCache
Global Accelerator
Compute Optimizer
Graviton (ARM)
✅
実践チェックリスト
- CloudFrontで静的コンテンツをキャッシュしているか？
- ElastiCacheでDBクエリ結果をキャッシュしているか？
- Compute Optimizerでインスタンスサイズの推奨を確認しているか？
- 適切なストレージタイプ（gp3/io2等）を選択しているか？
- パフォーマンステストを定期的に実施しているか？
💰 柱5：コスト最適化（Cost Optimization）
たとえ話：賢い買い物上手
賢い買い物上手は、必要なものを必要な分だけ、最適な価格で購入します。
まとめ買い割引（Reserved）、タイムセール（Spot）、使った分だけ（従量課金）を使い分け。
「無駄を省く」「適切な価格で調達」「常にコストを意識」が節約の秘訣です。
まとめ買い割引（Reserved）、タイムセール（Spot）、使った分だけ（従量課金）を使い分け。
「無駄を省く」「適切な価格で調達」「常にコストを意識」が節約の秘訣です。
💡 コスト削減の4つの戦略
適正サイズ化
Right Sizing
Right Sizing
予約購入
Reserved/Savings
Reserved/Savings
スポット活用
最大90%OFF
最大90%OFF
無駄の削除
未使用リソース
未使用リソース
1
クラウド財務管理を実装
コストをチームに可視化。予算を設定し、アラートを出す。
2
消費モデルを採用
使った分だけ払う。開発環境は夜間停止。
3
全体的な効率を測定
リクエストあたりのコストなど、ビジネス指標とコストを関連付け。
4
差別化につながらない作業をやめる
マネージドサービスを活用。OS管理よりビジネスロジックに集中。
5
支出を分析し帰属させる
タグ付けでコストを追跡。どのチーム、どのプロジェクトが使っているか把握。
🛠️
関連AWSサービス
Cost Explorer
Budgets
Trusted Advisor
Savings Plans
Spot Instances
Cost Allocation Tags
✅
実践チェックリスト
- AWS Budgetsで予算アラートを設定しているか？
- Cost Explorerで定期的にコストを確認しているか？
- タグでリソースにコスト配分しているか？
- Reserved/Savings Plansを検討しているか？
- 未使用のリソース（停止中EC2、未接続EBS等）を削除しているか？
🌱 柱6：持続可能性（Sustainability）
たとえ話：エコな暮らし
エコな暮らしとは、限られた資源を効率よく使うこと。
LED照明に替える、使わない部屋の電気を消す、太陽光パネルを設置する。
「効率化」「無駄の削減」「再生可能エネルギー」で地球にも財布にも優しく。
LED照明に替える、使わない部屋の電気を消す、太陽光パネルを設置する。
「効率化」「無駄の削減」「再生可能エネルギー」で地球にも財布にも優しく。
1
影響を理解する
ワークロードの環境負荷を測定。Customer Carbon Footprint Toolを活用。
2
持続可能性の目標を設定
具体的な削減目標を立て、進捗を追跡する。
3
使用率を最大化
リソースをできるだけ効率よく使う。アイドル状態を減らす。
4
効率的なハードウェア/ソフトウェアを採用
Graviton（ARM）は電力効率が良い。最新インスタンスを使う。
5
マネージドサービスを使う
AWSが効率化した共有インフラを利用。自前運用より効率的。
🛠️
関連AWSサービス
Graviton
Lambda
S3 Intelligent-Tiering
Sustainability Regions
Carbon Footprint Tool
S3 Glacier
✅
実践チェックリスト
- Gravitonインスタンスへの移行を検討しているか？
- S3 Intelligent-Tieringで自動的にストレージクラスを最適化しているか？
- 再生可能エネルギーを多く使用するリージョンを検討しているか？
- 開発環境を夜間・週末に停止しているか？
⚖️ 6本柱のトレードオフ関係
運用上の優秀性
セキュリティ
信頼性
Well-Architected
バランス
⚖️
バランス
⚖️
パフォーマンス効率
コスト最適化
持続可能性
🏦
ミッションクリティカルシステム
優先：信頼性 セキュリティ
許容：コスト増加
銀行のコアシステムなど。止まると損害が甚大なため、冗長構成にコストをかける。
許容：コスト増加
銀行のコアシステムなど。止まると損害が甚大なため、冗長構成にコストをかける。
🧪
開発・テスト環境
優先：コスト最適化
許容：信頼性低下
一時的な環境。Spotインスタンスや単一AZでコストを抑える。
許容：信頼性低下
一時的な環境。Spotインスタンスや単一AZでコストを抑える。
🛍️
ECサイト（セール期間）
優先：パフォーマンス 信頼性
許容：一時的なコスト増
セール期間中は売上が重要。余剰キャパシティを確保してチャンスロスを防ぐ。
許容：一時的なコスト増
セール期間中は売上が重要。余剰キャパシティを確保してチャンスロスを防ぐ。
⚠️ 重要：セキュリティと運用上の優秀性はトレードオフしない！
この2つは常に確保すべき基盤です。妥協してはいけません。
🎯 ユースケース別：優先すべき柱
Webアプリケーション
優先度バランス
データ分析基盤
優先度バランス
金融システム
優先度バランス
ゲームサーバー
優先度バランス
🔍 Well-Architected レビューの進め方
1
ワークロードを定義
レビュー対象のシステム範囲を明確にする。「ECサイトのバックエンド」など。
⬇️
2
各柱の質問に回答
Well-Architected Toolの質問に答える。チーム全員で議論しながら進める。
⬇️
3
リスクを特定
回答に基づいて高リスク・中リスクの項目が表示される。改善が必要な箇所を把握。
⬇️
4
改善計画を作成
リスクの優先度をつけ、改善項目をバックログに追加。担当者と期限を決める。
⬇️
5
改善を実施＆再レビュー
改善を実施し、定期的に再レビュー。継続的な改善サイクルを回す。
🚀 今日から始める3ステップ
1
Well-Architected Toolを開く
AWSコンソールから「Well-Architected Tool」を検索。
無料で使えます！
2
ワークロードを登録
レビューしたいシステムを登録。
まずは1つだけでOK。
3
質問に回答開始
各柱の質問に答えていく。
分からなければスキップしてOK！
📊 6本柱 完全比較表
| 比較項目 | ⚙️ 運用 | 🔐 セキュリティ | 💪 信頼性 | 🚀 パフォーマンス | 💰 コスト | 🌱 持続可能性 |
|---|---|---|---|---|---|---|
| 🎯 目的 | 効率的な運用 | 保護する | 止まらない | 速くする | 節約する | 環境に優しく |
| 🏠 家のたとえ | 管理人室 | 防犯システム | 耐震構造 | 動線設計 | 予算管理 | 省エネ設計 |
| ❓ 主な質問 | 監視できてる？ | 誰がアクセス？ | 障害時どうする？ | 遅くない？ | 無駄はない？ | 効率的？ |
| 🛠️ 代表サービス | CloudWatch Systems Manager |
IAM GuardDuty |
Auto Scaling Multi-AZ |
CloudFront ElastiCache |
Cost Explorer Savings Plans |
Graviton S3 Glacier |
🛠️ 便利なAWSツール
AWS Well-Architected Tool
無料のセルフレビューツール。質問に答えるだけでリスクを可視化。改善計画の作成もサポート。
AWS Trusted Advisor
リアルタイムでベストプラクティスをチェック。コスト、セキュリティ、パフォーマンスの推奨を提供。
AWS Cost Explorer
コストを視覚化して分析。傾向を把握し、将来のコストを予測。最適化の機会を発見。
AWS Compute Optimizer
EC2、Lambda、EBSの最適なサイズを推奨。過剰プロビジョニングを防止。
❓ よくある質問（FAQ）
🤔
Well-Architectedレビューは監査ですか？
いいえ、監査ではありません。
レビューは「改善のための対話」です。合格・不合格ではなく、リスクを発見して改善することが目的。チームで建設的に議論しましょう。
レビューは「改善のための対話」です。合格・不合格ではなく、リスクを発見して改善することが目的。チームで建設的に議論しましょう。
🤔
6本柱すべて完璧にしないとダメ？
いいえ、ビジネス要件に応じてバランスを取ります。
ただし、セキュリティと運用上の優秀性は妥協しないでください。他の柱はトレードオフを考慮して優先度を決めましょう。
ただし、セキュリティと運用上の優秀性は妥協しないでください。他の柱はトレードオフを考慮して優先度を決めましょう。
🤔
どのくらいの頻度でレビューすべき？
大きな変更時 + 定期的（四半期〜半年ごと）が推奨です。
新機能追加、アーキテクチャ変更、本番リリース前などのマイルストーンでレビュー。加えて定期的な見直しも重要です。
新機能追加、アーキテクチャ変更、本番リリース前などのマイルストーンでレビュー。加えて定期的な見直しも重要です。
🤔
すでに稼働中のシステムにも使える？
はい、むしろ稼働中のシステムこそ重要です。
既存システムの課題を発見し、改善計画を立てられます。新規構築時だけでなく、継続的な改善に活用しましょう。
既存システムの課題を発見し、改善計画を立てられます。新規構築時だけでなく、継続的な改善に活用しましょう。
🎓 まとめ
6本の柱
運用・セキュリティ・信頼性
パフォーマンス・コスト・持続可能性
すべてがバランス良く大切
パフォーマンス・コスト・持続可能性
すべてがバランス良く大切
理想の家づくり
良いシステム設計は
理想の家を建てるのと同じ
基礎からしっかり
理想の家を建てるのと同じ
基礎からしっかり
継続的改善
一度で完璧は無理
定期的にレビューして
少しずつ良くしていく
定期的にレビューして
少しずつ良くしていく