2026-10-01（木）アーキテクチャ設計（Well-Architected）

1. 【この範囲の全体像】

本範囲（第13章、p.289-304）は、AWSが推奨する「優れた設計のベストプラクティス」を体系化した AWS Well-Architected フレームワーク（6つの柱） を網羅して扱います [p.11, p.289, p.290]。

試験全体の7割以上（セキュアな設計：30%、弾力性に優れた設計：26%、高パフォーマンスな設計：24%）がこの設計原則に直結しており [p.6]、単一サービスの個別仕様ではなく「サービスの組み合わせによる可用性の最大化」や「トレードオフの論理的判断」といった総合的なアーキテクチャ選定能力が問われます [p.6, p.290]。

「障害を前提とした設計（Design for Failure）」 [p.70] と「責任共有モデルに基づくセキュリティ・コストの最適化」を実務レベルで具現化するための、本試験最重要の章です [p.196, p.290]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
AWS Well-Architected フレームワーク [p.11, p.290]	運用の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の「6つの柱」からなる、クラウドインフラ設計を評価・改善するためのグローバル設計基準 [p.11, p.290]。
ステートレス（Stateless）設計 [p.69, p.291]	Webサーバーからセッションデータなどの状態を排除し、外部のデータベース（DynamoDBなど）やキャッシュ（ElastiCache）に外出しして処理する設計 [p.69, p.143, p.149]。EC2をいつでも安全に自動増減・破棄できる弾力性の基礎となる [p.68, p.69]。
疎結合（Decoupling） [p.22, p.220, p.291]	SQSやSNSなどのメッセージングサービスをシステムコンポーネント間に挟むことで、コンポーネント間の直接依存を排除し、一部の障害がシステム全体に連鎖するのを防ぐ設計原則 [p.22, p.220, p.228]。
最小権限の原則（Least Privilege） [p.181, p.298]	IAMポリシー等を用いて、ユーザーやアプリケーションに対して業務遂行に必要な「必要最小限のアクセス権限」のみをピンポイントで付与し、情報漏洩や誤操作リスクを極小化するセキュリティ原則 [p.181, p.184]。
保管時暗号化（Encryption at Rest） [p.199, p.202, p.299]	EBS、S3、RDS、DynamoDBなどのデータストアに格納されるデータをAWS KMSの暗号鍵を用いて物理的に暗号化し、物理ディスク盗難等の漏洩からデータを保護する施策 [p.89, p.111, p.134, p.199]。
結果整合性（Eventual Consistency） [p.144, p.297]	データの更新がミリ秒単位で全ての参照ノードに反映されるのを許容する代わりに、極小の遅延と高いスループットを維持する設計アプローチ。DynamoDBの読み取り等で選択される [p.144, p.297]。
需給の一致 (Matching Supply and Demand) [p.300]	実際のアクセス負荷の変動（需要）に合わせて、インフラのプロビジョニング量（供給）をAuto Scaling等を用いて自動的に伸縮（スケーリング）させるコスト最適化の鉄則 [p.68, p.300]。

3. 【試験で問われる比較ポイント】

① 信頼性・弾力性：スケーリングの境界（垂直 vs 水平） [p.58, p.66, p.68, p.69]

比較項目	スケールアップ（垂直スケーリング） [p.58, p.66]	スケールアウト（水平スケーリング） [p.66, p.68, p.69]
拡張方法	稼働中のEC2などのスペック（CPU・メモリ）を上位クラスへ上げる [p.58, p.66]。	ロードバランサー（ELB）配下のEC2などの「台数」を並列に増設する [p.66, p.68]。
耐障害性	低い（単一障害点（SPOF）となり、その1台が落ちるとシステム全体が停止する） [p.66]。	極めて高い（マルチAZ構成により、1台がダウンしても他ノードが処理を継続する） [p.70]。
停止時間	インスタンスタイプの変更時に一時的なダウンタイム（停止）を伴う [p.58, p.66]	システムを停止させることなく、無停止での動的拡張が可能 [p.68, p.69]。
試験での選択	原則として非推奨。並列処理（マルチAZ）に対応していないレガシーなシステムの移行など最終手段。	「アクセス急増に対応し、耐障害性を極大化し、自動復旧可能なWebインフラを構築したい」という試験の標準最適解 [p.68, p.70]。

② トレードオフとリソース選択：キャッシュ導入の境界 [p.147, p.149, p.160, p.295]

キャッシュ施策	Amazon ElastiCache [p.149, p.295]	Amazon CloudFront [p.160, p.295]	DynamoDB Accelerator (DAX) [p.147, p.295]
主な対象層	リレーショナルデータベース（RDSなど）の前段 [p.149]。	世界中のエンドユーザー（エッジロケーション） [p.160]。	DynamoDBテーブルの前段に特化 [p.147]。
プロトコル	Key-Value（Redis、Memcachedプロトコル） [p.149, p.150]。	HTTP / HTTPS（L7 Web通信） [p.170]。	DynamoDB専用API（SDK） [p.147]。
試験シグナル	「 RDBの読み込み負荷を下げ、セッションデータ等をミリ秒以下の応答で処理したい」 [p.69, p.149]。	「静的な画像、動画などのコンテンツ配信コストを下げ、世界中から低遅延で配信したい」 [p.160]。	「既存のDynamoDBへの読み込みを、ミリ秒からマイクロ秒単位へ劇的に高速化させたい」 [p.147]。

4. 【ひっかけ注意ポイント】

ひっかけ①：「ユーザーからのWeb参照負荷を処理するため、EC2インスタンス群を複数のアベイラビリティゾーン（マルチAZ）に配置し、ELBをアタッチして自動スケーリング構成を組んだ。これで、いつでもEC2が自動的に増減・削除（スケールイン）されても、エンドユーザーがWebサイトから突然切断されたりカートの中身が消えたりするようなトラブルは自動的に完全に防ぐことができる。」
- 真実: アプリケーションが「ステートフル（セッションデータをEC2内部に保持する）」設計のままであった場合、スケールインで削除されたインスタンスに接続していたユーザーのセッションやカートデータは即座に物理消去され、深刻な画面エラーを引き起こします [p.69]。
- 対策: 弾力性に優れたスケーリングを実現するためには、Webサーバーを「 ステートレス（状態を持たない） 」に設計し、セッションデータは必ず「Amazon DynamoDB」や「Amazon ElastiCache」に外出しして保存させます [p.69, p.143, p.149]。
ひっかけ②：「セキュリティコンプライアンス監査に準拠するため、S3バケットに保存されるすべてのログデータオブジェクトを『保管時暗号化（Encryption at Rest）』することにした。KMSによるサーバー側暗号化（SSE-KMS）を有効化し、IAMロールポリシーに s3:GetObject を定義してアタッチした。これで、EC2上のWebアプリケーションはS3内の暗号化ログファイルを問題なくいつでもデプロイ・参照できる。」
- 真実: 暗号キーに対する復号権限が不足しているため、S3へのAPIコール時にアクセス拒否（Access Denied）エラーが発生し、処理が異常停止します [p.184, p.200]。
- 理由: SecureString や KMS暗号化されたS3オブジェクトを読み取るためには、S3自体の読み取り権限（s3:GetObject）に加え、暗号を解くためのKMSマスターキーに対する「kms:Decrypt（復号）」アクションの実行権限が、対象のIAMロールポリシーに明示的にアタッチされている必要があるためです [p.184, p.200]。
ひっかけ③：「大規模なビッグデータ集計処理を行うバッチアプリケーションが、定常的に24時間稼働している。インフラの固定コストを極限まで下げるため、オンデマンド料金から最大90%引きとなる『スポットインスタンス』をこのバッチ専用EC2に適用し、途切れることなく定常的な計算処理を実行させた。」
- 真実: バッチ処理が途中で頻繁に強制中断され、データ処理の不整合や遅延といった重大なサービス運用上の破綻を招きます [p.60]。
- 理由: スポットインスタンスはAWSの余剰容量の状況に伴い、わずか「 2分前の警告 」で問答無用で強制物理シャットダウンされます [p.60]。そのため、途中で中断・再開ができないステートフルな定常バッチや、中断時のハンドリングが設計されていないワークロードに対して適用するのは致命的なコスト最適化のアンチパターンです [p.60]。
- 対策: 定常的に稼働し続けるインフラベースラインには、割引率が安定（最大72%引き）し容量も完全保証される「 Savings Plans 」または「 リザーブドインスタンス 」を適用します [p.60, p.61]。スポットインスタンスは、「いつでも並列で処理を中断・再開できる、SQS等と連携した疎結合なワーカー処理」や「一時的なテスト環境」にのみピンポイントで適用するのが鉄則です [p.60, p.220]。