2026-09-30（水）アーキテクチャ設計（Well-Architected）

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

---

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

---

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

Well-Architectedに基づく主要設計アプローチの徹底使い分け [p.291-304]

比較テーマ	アプローチA	アプローチB	決定的な選定シグナル（試験問題のキーワード） [p.307-312]
スケーリング [p.58, p.66, p.291]	スケールアップ（垂直拡張） インスタンスのスペック（CPU/メモリ）を上げる [p.58, p.291]。	スケールアウト（水平拡張） 同一スペックのサーバーを複数台並列に並べる [p.66, p.291]。	🎯 「 障害発生時にもサービスを完全停止させることなく、耐障害性（高可用）とスループットを動的にスケールさせたい 」 ➔ 単一障害点（SPOF）を排除し自律復旧が可能な スケールアウト（水平） を選択 [p.66, p.307, p.308]。
データベースの信頼性 [p.131-133]	RDS Multi-AZ（同期複製） 異なるAZにスタンバイDBを配置 [p.131]。	リードレプリカ（非同期複製） 参照専用の複製インスタンスを配置 [p.132, p.133]。	🎯 「 マスターDBの物理障害やAZ全体の被災時、データロストなしで短時間で全自動フェイルオーバー（自動復旧）させたい 」 ➔ RDS Multi-AZ を選択 [p.131, p.307]（リードレプリカは参照負荷分散用 [p.132]）。
S3データ保護アクセス [p.39, p.107, p.111]	S3バケットをパブリック公開 パブリックアクセスを許可する [p.109, p.111]。	CloudFront + OAC（Origin Access Control） S3への直接アクセスを完全遮断 [p.111, p.161]。	🎯 「 S3上の静的ファイルを安全に外部配信したいが、セキュリティ上、S3バケットそのものは完全プライベートに維持したい 」 ➔ CloudFront + OAC で、暗号化された配信経路経由のみに通信を制限する [p.111, p.161]。
コスト最適化（EC2/Lambda） [p.60, p.61, p.301]	Compute Savings Plans 1年または3年の定常使用コミット [p.61, p.301]。	スポットインスタンス AWS予備容量の入札（最大90%引） [p.60, p.301]。	🎯 「 一時的に中断されても、次の起動時に最初から再実行・リカバリが効くステートレスなバッチ処理を最安で実行したい 」 ➔ スポットインスタンス を選択 [p.60, p.234, p.301]（本番Webなど停止不可ならSP [p.61, p.301]）。

---

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

• ひっかけ①：データベースの可用性・フェイルオーバー要件に対して「リードレプリカの増設」を選ばせる罠 [p.131, p.132, p.133]

  • 罠パターン: 「データベース（RDS）の物理的な被災時に備え、ダウンタイムを最小限（数分以内）に抑えて自動フェイルオーバーできる耐障害性の高い構成にするため、別のアベイラビリティゾーンにリードレプリカを2台作成した。」
  • なぜ間違いか: リードレプリカは仕様上 「 非同期複製 」 であり、主目的は「Selectクエリ（読み取り）の負荷分散・スケールアウト」です [p.132, p.133]。プライマリDB被災時に、DNSレコードを自動で書き換えて60〜120秒で全自動復旧（フェイルオーバー）を果たす機能境界を持つのは、同期複製を行う 「 RDS Multi-AZ 」 のみです [p.131]。
  • ベストプラクティス: 自動フェイルオーバー（耐障害性）の要件には Multi-AZ を選択し、読み取りクエリのパフォーマンス処理の要件には リードレプリカ を選定して、要件ごとに厳密に切り分けてマッピングします [p.131, p.132]。

• ひっかけ②：OS内部のメトリクス（メモリ使用率）を「標準のCloudWatchメトリクス」で監視・自動スケーリングさせようとする罠 [p.245, p.247]

  • 罠パターン: 「EC2上のアプリケーションのメモリ枯渇（RAM上限超過）によるクラッシュを防ぐため、追加モジュールやエージェントの設定を行うことなく、CloudWatch標準アラームを設定してメモリ使用率が80%を超えたらAuto Scalingが起動するようにした。」
  • なぜ間違いか: AWSの責任共有モデルおよびハイパーバイザー（外側）の物理仕様制限により、CPU使用率やネットワークI/Oは標準で自動取得できますが、ゲストOS内部のプライベート空間である「メモリ（RAM）使用率」や「ファイルシステム空き容量」は標準モニタリングでは100%取得できません [p.196, p.245, p.247]。
  • ベストプラクティス: OS内部の状態監視を行う場合は、必ず対象のEC2に 「 CloudWatchエージェント（Agent） 」 をインストールし、カスタムメトリクスとしてCloudWatch側にプッシュ送信させるアーキテクチャを指定してください [p.245, p.247]。

• ひっかけ③：定常稼働するサーバーレス処理（LambdaやFargate）に対し、「EC2リザーブドインスタンス(RI)」でコスト削減を推奨する罠 [p.61, p.301]

  • 罠パターン: 「年間を通じて完全に予測可能な定常負荷として、コンテナ（AWS Fargate）および AWS Lambda が定常的に動作している。インフラ全体の運用コストを最大化（削減）するため、EC2 リザーブドインスタンスを購入した。」
  • なぜ間違いか: リザーブドインスタンス（RI）は、原則としてEC2やRDSなどの「仮想サーバーインスタンス」単体にのみ紐づく割引モデルであり、FargateやLambdaなどのサーバーレスコンピューティングに対しては割引が一切適用されません [p.61, p.301]。
  • ベストプラクティス: FargateやLambdaを含むサーバーレス構成、またはEC2の種類が柔軟に変動するようなモダン環境の定常コストを削減するには、割引対象が極めて柔軟で自動適用される 「 Compute Savings Plans 」 をマッピングするのが絶対の正解です [p.61, p.301]。

---