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

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

---

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

---

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

パフォーマンス向上を最大化する「トレードオフ」と「リソース選択」 [p.295, p.297]

試験問題が「どのようなパフォーマンス課題」を抱えているかというシグナルから、最適な製品・構成を切り分けます [p.295, p.297]。

パフォーマンス効率を上げる施策	メリット（向上する性能）	トレードオフとなる項目（デメリット）	主な試験シナリオと選定シグナル
データベースの 結果整合性の適用 [p.144, p.297]	読み取りパフォーマンスの極大化とスループットコスト（RCU消費量）の半減 [p.144, p.297]。	変更されたデータが瞬時に読み出しに反映されない（ミリ秒レベルのわずかなタイムラグ） [p.144, p.297]。	「 最新値が数秒遅れて反映されても業務上支障がない（例：商品カタログ、ソーシャルゲームの全体ランキングなど）状況において、最小のプロビジョニングスループットで最大のパフォーマンスを出したい 」 [p.144, p.297]。
データベース前段への インメモリキャッシュ導入 [p.147, p.149, p.295]	ミリ秒〜マイクロ秒単位の超高速応答と、オリジナルDB（RDSやDynamoDB）への読み込み負荷の激減 [p.147, p.149]。	インフラ構成の複雑化（キャッシュミスのハンドリング実装負荷）および追加の構成費用 [p.149]。	「 データベースへの急激なアクセススパイクが発生しており、ミリ秒未満の極小レイテンシーでの表示を達成しつつDBサーバーの処理負荷をバイパスしたい 」 [p.147, p.149]。
ストレージの io2（プロビジョンドIOPS SSD）アタッチ [p.89, p.130]	ミリ秒未満の応答レイテンシーと、最大64,000 IOPS / ボリュームという極めて高いI/Oスループットの安定提供 [p.89, p.91]。	汎用SSD（gp3）に比べて高コストであり、設定したIOPS値に応じて継続的な固定課金が発生する [p.89]。	「 本番環境の基幹系データベース（OracleやSQL Serverなど）において、ミリ秒以下の極めて高いストレージ書き込み応答性能をブレなく発揮させたい 」 [p.89, p.130]。
S3 Select による データ抽出の最適化 [p.112]	ネットワークデータ転送量（Egress料金）の劇的な削減と、クエリ実行パフォーマンスの向上 [p.112]。	アプリケーションがデータの一部をSQL（簡単な条件）で絞り込める形式（CSV、JSON、Parquet）に制限される [p.112]。	「 Amazon S3バケット内に保存されたギガバイト規模のログファイルから、特定の日付の特定の列データのみを効率よく抽出して、転送遅延と計算処理コストを極小化したい 」 [p.112]。

---

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

• ひっかけ①：「ユーザーからの商品一覧画面への参照アクセスが爆発的に急増し、オリジナルデータベース（Amazon RDS）の読み出し遅延が発生した。このパフォーマンス遅延を即座に解消し、システムの読み込み能力を物理上限まで引き上げるため、RDSインスタンスの『インスタンスタイプ』を、現状よりも1段階ハイスペックなコンピューティング最適化タイプにスケールアップ（垂直スケーリング）した。」

  • 真実: コストが極めて高騰する割に、パフォーマンスの根本解決には至らない設計アンチパターンです [p.58, p.66, p.295]。
  • 解決理由: RDSのスケールアップは一時的な対処に過ぎず、ハードウェア上限に当たればそれ以上の拡張は不可能です [p.66]。また、スケールアップの適用中には一時的な停止（ダウンタイム）が発生します [p.58, p.66]。
  • 対策: 高パフォーマンスな読み出し効率を追求する場合、オリジナルDBのスケールアップではなく、データ整合性のトレードオフを考慮した 「 RDS リードレプリカの追加（水平スケーリング） 」 や、前段への 「 Amazon ElastiCache（インメモリキャッシュ） 」 のデプロイを選択マッピングするのが、コスト効率とパフォーマンスを両立させるAWSのベストプラクティスです [p.132, p.149, p.295]。

• ひっかけ②：「オンプレミスのファイルサーバーからAWSへの移行にあたり、複数のEC2インスタンスから同時に高速書き込み・共有参照を行う高パフォーマンスな共通データ領域を確保したい。ネットワーク共有可能で無制限に自動スループットスケールされる特性を重視し、ストレージとして『Amazon EFS（Provisioned Throughput）』を選択し、そこにデータベース用の物理テーブルスペース・データボリュームを配置した。」

  • 真実: データベースのパフォーマンスが極限まで低下し、システム停止を招くおそれがあります [p.88, p.95, p.295]。
  • 理由: Amazon EFSはネットワーク共有ストレージ（NFSプロトコル）であり、ファイル共有には優れていますが、ミリ秒以下の極めて高いランダムアクセス応答が求められるデータベースの「ブロックレベルI/O」を処理する設計にはなっていません [p.88, p.95]。
  • 対策: データベースなどの極小ブロック・高IOPSを維持すべきトランザクション処理ワークロードに対しては、EFSではなく、必ずEC2インスタンス専用にプロビジョニングされたブロックストレージである 「 Amazon EBS（プロビジョンドIOPS SSD：io2） 」 をマウント構成する、または 「 EBS最適化インスタンス 」 を定義するのが正しいリソース選択です [p.89, p.91, p.130]。

---