AWS Well-Architected Framework
AWSが提唱するクラウドアーキテクチャのベストプラクティス集であるWell-Architected Frameworkを学びます。6つの柱それぞれの設計原則とベストプラクティスを理解し、IDサービスのアーキテクチャ評価に活用します。
所要時間
約45分
学べること
- Well-Architected Frameworkの目的と全体像
- 6つの柱の設計原則とベストプラクティス
- 各柱における具体的な実践手法
- Well-Architected レビューの進め方
- IDサービスのアーキテクチャを6つの柱で評価する方法
- IDサービス本番環境のAWSコスト全体像と最適化手法
前提知識
- AWSの基本サービスの理解
- クラウドアーキテクチャの基本概念
目次
- Well-Architected Frameworkとは何か
- 6つの柱の全体像
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
- Well-Architected レビュープロセス
- IDサービスでの活用
- まとめ
Well-Architected Frameworkとは何か
Well-Architected Frameworkは、AWSが長年のクラウド運用経験から体系化したアーキテクチャ設計のベストプラクティス集です。
目的
- ワークロードの設計品質を評価するための一貫した基準を提供
- アーキテクチャ上のリスクを特定し、改善の優先順位を明確化
- クラウドネイティブな設計判断の指針として活用
- チーム間で共通のレビュー言語を確立
フレームワークの構成
+--------------------------------------------------+
| Well-Architected Framework |
| |
| +----------+ +----------+ +----------+ |
| | 設計原則 | | 質問集 | | ベスト | |
| | (各柱) | | (評価用) | | プラクティス| |
| +----------+ +----------+ +----------+ |
| |
| 6つの柱 x 各柱の質問 x 具体的な実践手法 |
+--------------------------------------------------+
6つの柱の全体像
Well-Architected Framework
|
+----------+----------+----------+----------+----------+
| | | | | |
+----v---+ +---v----+ +---v----+ +---v----+ +---v----+ +---v----+
| 運用上の | | セキュ | | 信頼性 | | パフォ | | コスト | | 持続 |
| 優秀性 | | リティ | | | | ーマンス | | 最適化 | | 可能性 |
| | | | | | | 効率 | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
運用の データと 障害への リソースの 無駄な 環境への
自動化と システムの 耐性と 効率的な 支出の 影響の
継続的改善 保護 復旧能力 利用 削減 最小化
| 柱 | 焦点 | 主要な問い |
|---|---|---|
| 運用上の優秀性 | 運用プロセス | ワークロードを効果的に運用しているか？ |
| セキュリティ | データ・システム保護 | 情報とシステムをどう保護するか？ |
| 信頼性 | 障害耐性 | 障害からどう復旧するか？ |
| パフォーマンス効率 | リソース活用 | リソースを効率的に使っているか？ |
| コスト最適化 | 費用管理 | 不要なコストを排除しているか？ |
| 持続可能性 | 環境影響 | 環境への影響を最小限にしているか？ |
運用上の優秀性
設計原則
- 運用をコードとして実行する: IaCで環境を定義、スクリプトで運用手順を自動化
- 小規模で可逆的な変更を頻繁に行う: デプロイ頻度を上げ、変更リスクを低減
- 運用手順を頻繁に改善する: ゲームデーやカオスエンジニアリングで手順を検証
- 障害を予測する: 障害シナリオを想定し、対応手順を事前に準備
- 運用上の全ての障害から学ぶ: ポストモーテムで根本原因を分析し再発防止
主要ベストプラクティス
| 領域 | 実践内容 | AWSサービス |
|---|---|---|
| 組織 | 運用の優先順位とトレードオフの理解 | - |
| 準備 | ワークロードの可観測性の設計 | CloudWatch, X-Ray |
| 運用 | ランブック（手順書）の自動化 | Systems Manager |
| 進化 | メトリクスに基づく継続的改善 | CloudWatch Dashboards |
デプロイパイプラインの例:
コード変更 --> ビルド --> テスト --> ステージング --> 本番
| | | | |
Git Push CodeBuild 自動テスト カナリア 段階的
デプロイ ロールアウト
|
CloudWatch アラーム
異常時自動ロールバック
セキュリティ
設計原則
- 強力なアイデンティティ基盤を実装する: 最小権限の原則、職務分離
- トレーサビリティを有効にする: 全アクションのログ記録・監視
- 全レイヤーにセキュリティを適用する: 多層防御（ネットワーク、ホスト、アプリケーション）
- セキュリティのベストプラクティスを自動化する: 自動監査、自動修復
- 転送中および保管中のデータを保護する: 暗号化、アクセス制御
IDとアクセス管理
| 実践内容 | 説明 | AWSサービス |
|---|---|---|
| 最小権限 | 必要最小限の権限のみ付与 | IAM Policy |
| 一時的な認証情報 | 長期的なアクセスキーを排除 | IAM Roles, STS |
| MFA | 特権操作に多要素認証を要求 | IAM MFA |
| 権限の定期レビュー | 未使用の権限を特定・削除 | IAM Access Analyzer |
検知
| 実践内容 | 説明 | AWSサービス |
|---|---|---|
| ログの一元管理 | 全AWSアカウ ントのログを集約 | CloudTrail, S3 |
| 脅威検知 | 異常なAPIコールやネットワーク活動を検知 | GuardDuty |
| 設定監査 | リソース設定の継続的な準拠チェック | Config |
| セキュリティ評価 | セキュリティ状態の一元管理 | Security Hub |
インフラ保護
+--------------------------------------------------+
| VPC |
| +--------------------------------------------+ |
| | パブリックサブネット | |
| | +----------+ +----------+ | |
| | | ALB | | NAT GW | | |
| | | (WAF付き) | | | | |
| | +----+-----+ +----------+ | |
| +------|------------------------------------+| |
| | プライベートサブネット | |
| | +----v-----+ | |
| | | ECS | ← セキュリティグループ | |
| | | Fargate | (ALBからの443のみ許可) | |
| | +----+-----+ | |
| +------|------------------------------------+| |
| | 分離サブネット | |
| | +----v-----+ | |
| | | RDS | ← セキュリティグループ | |
| | | Aurora | (ECSからの5432のみ許可) | |
| | +----------+ | |
| +--------------------------------------------+ |
+--------------------------------------------------+
データ保護
| 対象 | 転送中の暗号化 | 保管時の暗号化 |
|---|---|---|
| API通信 | TLS 1.2以上 (ACM) | - |
| データベース | SSL接続強制 | KMSによる暗号化 |
| オブジェクトストレージ | HTTPS強制 | SSE-KMS |
| シークレット | TLS | Secrets Manager暗号化 |
信頼性
設計原則
- 障害からの自動復旧: ヘルスチェックと自動修復
- 復旧手順のテスト: 定期的な障 害訓練の実施
- 水平方向にスケール: 単一の大きなリソースではなく、複数の小さなリソースに分散
- キャパシティを推測しない: Auto Scalingで需要に応じた自動調整
- 自動化による変更管理: IaCとCI/CDによる変更の自動化
障害管理
障害の影響範囲と対策:
コンポーネント障害 ──→ ヘルスチェック + 自動復旧
(1つのタスク停止) (ECS: desired count維持)
AZ障害 ──→ マルチAZ構成
(1つのAZが利用不可) (ALB + 複数AZのタスク)
リージョン障害 ──→ マルチリージョン構成
(1つのリージョンが停止) (Route 53フェイルオーバー)
| 対策 | 説明 | AWSサービス |
|---|---|---|
| マルチAZ | 複数のAZにリソースを分散配置 | ALB, ECS, Aurora |
| Auto Scaling | 需要に応じた自動スケーリング | ECS Auto Scaling |
| ヘルスチェック | 異常検知と自動復旧 | ALB Health Check |
| バックアップ | 定期的なデータバックアップ | RDS自動バックアップ |
| ディザスタリカバリ | リージョン障害への対応計画 | Route 53, S3 Cross-Region |
復旧計画
| 戦略 | RPO | RTO | コスト | 説明 |
|---|---|---|---|---|
| バックアップ&リストア | 時間 | 時間 | 低 | バックアップから復元 |
| パイロットライト | 分 | 10分〜 | 中低 | 最小構成を常時稼働 |
| ウォームスタンバイ | 秒〜分 | 分 | 中高 | 縮小構成を常時稼働 |
| マルチサイトアクティブ | ほぼゼロ | ほぼゼロ | 高 | 複数サイトで同時稼働 |
パフォーマンス効率
設計原則
- 先進テクノロジーの民主化: マネージドサービスを活用し運用負荷を低減
- 数分でグローバルに展開: エッジロケーション、マルチリージョンを活用
- サーバーレスアーキテクチャの使用: サーバー管理の排除
- より頻繁に実験する: 異なる構成を容易にテスト
- 技術と手法の理解: ワークロードに最適な技術の選択
リソース選択
| リソース | 選択基準 | 選択肢 |
|---|---|---|
| コンピュート | ワークロード特性 | EC2, ECS, Lambda, Fargate |
| データベース | データモデル、アクセスパターン | RDS, DynamoDB, ElastiCache |
| ストレージ | アクセス頻度、耐久性要件 | S3, EBS, EFS |
| ネットワーク | レイテンシ、帯域幅要件 | CloudFront, Global Accelerator |
モニタリング
+--------------------------------------------------+
| CloudWatch |
| |
| メトリクス ─→ アラーム ─→ アクション |
| |
| ECS CPU使用率 > 80% |
| → SNS通知 + Auto Scaling |
| |
| API レイテンシ p99 > 500ms |
| → SNS通知 + ダッシュボード表示 |
| |
| RDS接続数 > 80% |
| → SNS通知 + 運用チームエスカレーション |
| |
| X-Ray トレース |
| → ボトルネック特定 + パフォーマンス分析 |
+--------------------------------------------------+
コスト最適化
設計原則
- クラウド財務管理を導入する: コスト意識を組織文化に組み込む
- 消費モデルを採用する: 使った分だけ支払う
- 全体的な効率を測定する: ビジネス成果あたりのコストを追跡
- 差別化されない重労働への支出をやめる: マネージドサービスを活用
- 費用を分析し帰属させる: コスト配分タグで可視化
コスト削減の手法
| 手法 | 削減率目安 | 適用条件 |
|---|---|---|
| Reserved Instances | 30〜60% | 安定稼働ワークロード（1年/3年） |
| Savings Plans | 30〜60% | 安定したコンピュート使用量 |
| Spot Instances | 60〜90% | 中断可能なワークロード |
| Right Sizing | 10〜30% | 過剰プロビジョニングの是正 |
| Auto Scaling | 変動 | 需要変動があるワークロード |
| Graviton | 20〜40% | ARM対応アプリケーション |
費用対効果の分析
コスト可視化:
+------------------+ +------------------+ +------------------+
| Cost Explorer | --> | コスト配分タグ | --> | Budgets |
| (コスト分析) | | (サービス別、 | | (予算アラート) |
| | | 環境別、 | | |
| | | テナント別) | | |
+------------------+ +------------------+ +------------------+
持続可能性
設計原則
- 影響を理解する: クラウドワークロードの環境負荷を把握
- 持続可能性の目標を設定する: 具体的な目標値を定めて追跡
- 利用率を最大化する: リソースのアイドル時間を最小化
- より効率的なハードウェア・ソフトウェアを採用する: 新しい世代のインスタンスを活用
- マネージドサービスを使用する: 共有インフラの効率性を活用
環境影響の最小化
| 実践内容 | 効果 | 具体的なアクション |
|---|---|---|
| 適切なリソースサイジング | 過剰プロビジョニングの排除 | Compute Optimizer活用 |
| 最新世代インスタンス | 電力効率の向上 | Graviton（ARM）への移行 |
| サーバーレス活用 | アイドル時 間の排除 | Lambda、Fargate活用 |
| データライフサイクル管理 | 不要データの削減 | S3ライフサイクルポリシー |
| リージョン選択 | 再生可能エネルギーの活用 | 低炭素リージョンの選択 |
Well-Architected レビュープロセス
レビューの進め方
1. 準備
チームメンバーの招集、対象ワークロードの特定
|
v
2. レビュー実施
Well-Architected Toolで6つの柱の質問に回答
|
v
3. リスク特定
高リスク（HRI）と中リスク（MRI）の項目を特定
|
v
4. 改善計画
リスクの優先順位付けと改善アクションの策定
|
v
5. 実施・追跡
改善の実施と効果の測定
|
v
6. 定期レビュー
四半期ごとに再評価
Well-Architected Tool
AWS Well-Architected Toolは、AWSコンソール上でレビューを実施・管理するサービスです。
| 機能 | 説明 |
|---|---|
| ワークロード定義 | レビュー対象の定義と管理 |
| レンズ選択 | AWS標準 + 業界別レンズ（SaaS、金融等） |
| 質問と回答 | 柱ごとの質問への回答記録 |
| リスクレポート | 高リスク/中リスク項目の一覧 |
| 改善プラン | リスクに対する改善アクションの追跡 |
| マイルストーン | 時系列でのアーキテクチャ改善の記録 |
IDサービスでの活用
idp-serverのアーキテクチャをWell-Architectedの6つの柱で評価します。
セキュリティ（最重要）
IDサービスはセキュリティが最も重要な柱です。
| 評価項目 | idp-serverでの実践 |
|---|---|
| IDとアクセス管理 | OAuth 2.0/OIDC準拠の認証・認可。マルチテナントによるテナント間分離 |
| 検知 | セキュリティイベントの発行と監視。不正アクセス検知 |
| インフラ保護 | FAPI準拠のTLS設定。WAFによるAPI保護。VPCによるネットワーク分離 |
| データ保護 | 秘密鍵のSecrets Manager管理。RDSの暗号化。転送中のTLS暗号化 |
| インシデント対応 | セキュリティイベントによる即時通知。監査ログの保全 |
高可用性設計
IDサービスの高可用性構成:
Route 53
|
+------v------+
| ALB | ← ヘルスチェック
| (マルチAZ) |
+------+------+
|
+-------+-------+
| |
+---v---+ +----v--+
| ECS | | ECS | ← マルチAZ、Auto Scaling
| AZ-a | | AZ-c | 最小2タスク
+---+---+ +---+---+
| |
+------+------+
|
+------v------+
| Aurora | ← マルチAZクラスター
| PostgreSQL | 自動フェイルオーバー
| Writer + | 自動バックアップ
| Reader |
+-------------+
| 柱 | 評価項目 | 対応状況 |
|---|---|---|
| 信頼性 | マルチAZ構成 | ECS Fargate + Aurora マルチAZ |
| 信頼性 | Auto Scaling | CPU/メモリに基づくタスク自動スケール |
| 信頼性 | ヘルスチェック | ALBヘルスチェック + ECSヘルスチェック |
| 信頼性 | バックアップ | Aurora自動バックアップ（35日保持） |
| パフォーマンス | リードレプリカ | Aurora Reader で読み取り負荷分散 |
| パフォーマンス | キャッシュ | ElastiCache でセッション/トークンキャッシュ |
| コスト最適化 | Right Sizing | Compute Optimizer での定期的な見直し |
| コスト最適化 | Reserved/Savings Plans | 安定稼働部分にSavings Plans適用 |
| 運用上の優秀性 | IaC | CDKによるインフラのコード管理 |
| 運用上の優秀性 | CI/CD | CodePipeline による自動デプロイ |
| 持続 可能性 | Graviton | ARM対応イメージでGravitonインスタンス利用 |
コストイメージ（idp-server本番環境）
各章で個別サービスの料金を解説していますが、ここではIDサービスの本番環境を構成した場合の全体コストを示します。
構成パターン別の月額コスト目安（東京リージョン）
【小規模】テナント数: 〜10、ユーザー数: 〜1万
想定リクエスト: 〜100 req/s
コンピュート: EKS Fargate × 2 Pod (1vCPU/2GB) 約 $140
コントロールプレーン: EKS 約 $73
データベース: Aurora Serverless v2 (0.5〜4 ACU) 約 $300
キャッシュ: ElastiCache cache.t4g.medium × 2 約 $114
ネットワーク: ALB 約 $25
DNS: Route 53 約 $1
──────────────────────────────────────────────────
合計: 約 $650/月
【中規模】テナント数: 〜100、ユーザー数: 〜10万
想定リクエスト: 〜500 req/s
コンピュート: EKS マネージドノード t3.xlarge × 3 約 $390
コントロールプレーン: EKS 約 $73
データベース: Aurora db.r6g.xlarge (Writer+Reader) 約 $960
キャッシュ: ElastiCache cache.r7g.large × 2 約 $368
RDS Proxy: 約 $290
ネットワーク: ALB + NAT Gateway 約 $80
監視: CloudWatch 約 $50
セキュリティ: WAF + KMS 約 $30
──────────────────────────────────────────────────
合計: 約 $2,240/月
【大規模】テナント数: 〜1000、ユーザー数: 〜100万
想定リクエスト: 〜5000 req/s
コンピュート: EKS マネージドノード r6g.xlarge × 6 約 $1,320
コントロールプレーン: EKS 約 $73
データベース: Aurora db.r6g.2xlarge (Writer+Reader×2) 約 $2,550
キャッシュ: ElastiCache cache.r7g.xlarge × 3 約 $1,100
RDS Proxy: 約 $760
ネットワーク: ALB + NAT Gateway + CloudFront 約 $200
監視: CloudWatch + X-Ray 約 $150
セキュリティ: WAF + Shield + KMS 約 $3,100
──────────────────────────────────────────────────
合計: 約 $9,250/月
コスト最適化の適用効果
| 施策 | 削減率 | 適用先 | 年間削減額（中規模の場合） |
|---|---|---|---|
| リザーブドインスタンス（1年） | 30〜40% | Aurora、ElastiCache、EC2ノード | 約$6,000〜8,000 |
| Savings Plans（1年） | 20〜30% | コンピュート全体 | 約$1,000〜1,500 |
| Gravitonインスタンス | 約20% | EC2ノード、Aurora、ElastiCache | 約$3,000〜4,000 |
| Aurora I/O-Optimized | I/O量次第 | Aurora（I/OがDB料金の25%超の場合） | ケースバイケース |
中規模環境の最適化例:
オンデマンド: $2,240/月 × 12 = $26,880/年
Graviton適用 (−20%): $1,790/月 × 12 = $21,480/年
+ RI/Savings Plans適用 (−30%): $1,250/月 × 12 = $15,000/年
─────────────
約44%のコスト削減
セキュリティ重視の設計判断
IDサービスでは、他の柱とのトレードオフが発生した場合、セキュリティを優先します。
トレードオフの判断基準:
セキュリティ vs コスト
→ セキュリティ優先（WAF、暗号化、監査ログは必須コスト）
セキュリティ vs パフォーマンス
→ セキュリティ優先（TLS 1.2強制、トークン検証は省略しない）
信頼性 vs コスト
→ 信頼性優先（マルチAZ構成は必須、ダウンタイムは許容しない）
パフォーマンス vs コスト
→ バランス（Auto Scalingで需要に応じた最適化）
まとめ
- Well-Architected Frameworkは、6つの柱でクラウドアーキテクチャを評価するベストプラクティス集
- 運用上の優秀性: IaCとCI/CDで運用を自動化し、継続的に改善
- セキュリティ: 多層防御、最小権限、暗号化、監査ログで情報とシステムを保護
- 信頼性: マルチAZ、Auto Scaling、自動復旧で障害に耐えるアーキテクチャを構築
- パフォーマンス効率: 適切なリソース選択とモニタリングで効率的に運用
- コスト最適化: Reserved Instances/Savings Plans、Right Sizingで無駄を排除
- 持続可能性: 最新世代インスタンスとサーバーレスで環境負荷を最小化
- IDサービスではセキュリティを最優先としつつ、高可用性とコスト効率のバランスを取る
次のステップ
- 大量データの設計パターン - 大量データを扱う場合のWell-Architected設計パターンを深掘り