2026-09-01（火）復習週＋模試1
1. 【頻出ひっかけパターンTOP5】
ひっかけ①：「開発環境のコストを削減するため、夜間や週末はEC2インスタンスを『停止（Stopped）』ステータスに変更した。これにより、このインスタンスに関連するAWSからのすべてのインフラ課金を完全に『100%ゼロ』に抑えることができる。」
- 真実: インフラ課金は完全にはゼロになりません [p.59, p.83]。
- 理由: EC2インスタンスを停止（Stopped）すると、CPUやメモリといった計算資源への課金は即座にストップします [p.59]。しかし、インスタンスのオペレーティングシステムや永続データを保持している「Amazon EBSボリューム（仮想ディスク）」の容量保管料金は、インスタンスの稼働・停止状態に関わらず、削除（Terminated）しない限り定常的に発生し続けます [p.59, p.83]。試験では「コストを完全に排除するために、不要になった一時検証環境は『終了（Terminated）』させる」という選択肢が正解になるケースが多いため、停止と終了の課金仕様の境界線を明確に意識してください [p.59, p.65]。
ひっかけ②：「急激なアクセススパイクが発生するWebアプリケーションにおいて、フロントエンドを構成するEC2インスタンス群が自動で即座にスケールアウト（台数増）できるよう、Auto Scalingのクールダウン期間（冷却期間）の設定値を極限までゼロに近づけてマッピングする。」
- 真実: 非常に危険な設計（アンチパターン）であり、インフラコストの暴走やシステムダウンを招きます [p.68, p.71]。
- 理由: クールダウン期間とは、「Auto Scalingによって新しいEC2が追加された後、そのインスタンスがOSブートを完了し、ロードバランサーのヘルスチェックを通過してトラフィックを実際に処理し始める（CPU負荷が下がる）まで、追加のスケーリング活動を一時的に差し止める待機時間」です [p.57, p.68, p.71]。この期間を極端に短く、またはゼロにしてしまうと、新規インスタンスが起動処理中（まだ負荷を肩代わりできない状態）であるにも関わらず、Auto Scalingグループが「依然として全体のCPU負荷が高い」と誤判定し、何台ものEC2インスタンスを無制限に連続起動させてしまう「スケーリングの暴走（過剰プロビジョニング）」を引き起こします [p.68]。
ひっかけ③：「コンテナ化された複数のマイクロサービスを実行しているECSクラスター（EC2起動タイプ）において、コンテナ内からAmazon S3バケットへ分析ログを安全にアップロードさせるため、コンテナが乗っているホストとなるEC2インスタンス（コンテナインスタンス）に、S3へのフルアクセス権限を記載したIAMロール（インスタンスプロファイル）をアタッチする。」
- 真実: セキュリティガバナンスにおける重大なアンチパターンです [p.74]。
- 理由: ホストであるEC2インスタンス自体に強いIAMロールを付与してしまうと、その同じホスト上で稼働している「本来S3にアクセスする必要が一切ない他の無関係なコンテナ（タスク）」からも、ホストの資格情報を盗用してS3のデータに不正アクセスできてしまいます [p.74]。AWSのセキュリティ原則である「最小権限の原則」に適合させるための正しいベストプラクティスは、ホストEC2には強い権限を与えず、「タスク定義（Task Definition）」の中に、個々のコンテナタスク専用の「IAMタスクロール（Task Role）」を個別に定義・マッピングすることです [p.74, p.76]。
ひっかけ④：「深夜にオンプレミスからS3バケットに転送されてくる最大15GBの大容量CSVファイルを加工・分析するETLバッチ処理をコスト最適に自動化したい。このバッチ処理プログラムは、テスト環境において実行完了までに『平均して18分〜20分』を要することが分かっているため、イベント駆動で最も安価な『AWS Lambda』を深夜起動のトリガーとして設計する。」
- 真実: Lambdaの物理的な制限（仕様限界）により、バッチ処理は途中で確実に強制異常終了されます [p.80]。
- 理由: AWS Lambdaは、実行時間をどれほど引き延ばす設定を行っても、「1回の起動につき最大15分（900秒）」という厳格なタイムアウト上限がシステム的に適用されています [p.80]。15分を超える連続的な計算や重いETLバッチジョブは、Lambda単体で最後まで実行しきることはできません [p.80]。このような「15分の壁」を越える中長時間の処理要件（明確なタイムアウトシグナル）が出た場合は、サーバー管理不要のサーバーレスコンテナである 「 Amazon ECS on AWS Fargate 」 を採用するか、バッチ専用サービスである 「 AWS Batch 」 を選択するのが絶対的な正解マッピングとなります [p.74, p.75]。
ひっかけ⑤：「EC2インスタンスに割り当てたIAMロール（一時資格情報）から現在の認可情報をプログラムで取得するため、またはインスタンス起動時に適用された自マシンのプライベートIPアドレスを動的に特定するため、ゲストOS内のターミナルから http://169.254.169.254/latest/user-data/ に向けてcurlコマンドを送信する。」
- 真実: メタデータとユーザーデータの取得用URI（パス）を混同しています [p.62]。
- 理由: EC2内部から「自身のIPアドレス、インスタンスID、IAM一時資格情報」などのシステム側の構成・管理情報を動的に取得するオブジェクトは「インスタンスメタデータ（Instance Metadata）」 であり、アクセス先のパスは http://169.254.169.254/latest/meta-data/ です [p.62]。
一方で、末尾が
/user-data/となるパスは、インスタンス起動時にOSの初期化のために一度だけ自動実行させたシェルスクリプトや初期設定ファイルを再取得するものであり、マシンの動的属性（IPやIAM情報）は格納されていません [p.62, p.63]。この2つの境界線は試験でも非常によくシャッフルされます [p.62]。
2. 【混同しやすいサービスの比較表】
① EC2購入オプションの決定的な違い [p.60-61, p.65, p.83]
「どれほどコストを削減したいか」と「処理が途中で強制中断されることを許容できるか」のトレードオフです [p.60]。
| 購入オプション [p.60] | コスト削減率 | 中断（シャットダウン）のリスク | 契約期間のコミットメント | 試験での決定的な選定シグナル（なぜ選ぶのか） |
|---|---|---|---|---|
| オンデマンド (On-Demand) |
0% （ベースライン） |
一切なし（ユーザーが明示的に停止・削除するまで稼働を完全保証） [p.60]。 | なし （秒単位・時間単位の従量課金） [p.59, p.60]。 |
「 いつ使い終わるか予測できない一時的なテスト」「深夜の数時間だけ稼働させる単発バッチ」「稼働を1秒も止められない新規開発環境 」 [p.60]。 |
| スポット (Spot) |
最大90%OFF [p.60] | あり（AWS側の余剰キャパシティが逼迫すると、2分前の猶予通知の後に自動回収される） [p.60, p.65]。 | なし （空き資源をオークション形式で安価に利用） [p.60]。 |
「 処理が途中で突然シャットダウンされても、後から安全に再試行（リトライ）可能な、状態を持たないステートレスな並列バッチや機械学習の計算処理 」 [p.60, p.65, p.83]。 |
| リザーブドインスタンス (RI) |
最大72%OFF [p.61] | 一切なし（オンデマンドと同じ稼働保証） [p.60]。 | 1年間 または 3年間 の継続利用をコミット [p.61]。 | 「 24時間365日、常に同じスペック（特定のファミリーや世代サイズ）で定常稼働し続ける本番環境のデータベース（RDS等）やコアサーバー 」 [p.61, p.65]。 |
| Savings Plans (SP) |
最大72%OFF [p.61] | 一切なし（オンデマンドと同じ稼働保証）。 | 1年間 または 3年間、1時間あたりの「消費金額（例: $10/時）」をコミット [p.61]。 | 「 将来的にEC2からFargate（コンテナ）やLambda（サーバーレス）へとインフラをモダン化・移行する計画があるが、長期のコスト一括割引も並行して受けたい場合 」 （SPはコンピューティング間で枠の変更・流用が自在に可能なため、RIよりも変更柔軟性が圧倒的に高い） [p.61]。 |
② プレイスメントグループ3つの配置戦略 [p.63-64]
「ネットワーク性能を極限まで引き上げるか」「物理ハードウェア障害を徹底的に分散排除するか」の使い分けです [p.63]。
| 戦略 [p.63] | 物理的な配置ルール [p.63] | 規模・アタッチ制限 [p.63, p.64] | 試験での決定的な選定シグナル（なぜ選ぶのか） |
|---|---|---|---|
| クラスター (Cluster) |
単一アベイラビリティゾーン（AZ）内の、同じ高速ネットワークスイッチに属する物理的に最も近いラックの筐体群にEC2を凝縮配置する [p.63, p.64]。 | 単一AZ内での起動に限定（マルチAZ配置は不可） [p.63, p.64]。 | 「 インスタンス間（ミリ秒未満）の極めて低い通信遅延（超低レイテンシー）と、非常に高いネットワーク帯域（スループット）を同時に要求される、HPC（ハイパフォーマンスコンピューティング）や分散計算処理 」 [p.63]。 |
| スプレッド (Spread) |
起動するすべてのEC2インスタンスが、物理的な電源やネットワークスイッチ系統が完全に異なる 「完全に独立したラック」へ1台ずつバラバラに分散配置される [p.63, p.64]。 | アベイラビリティゾーンごとに「最大7台」までの起動制限がある [p.63, p.64]。 | 「 台数は少数（7台以下）だが、ハードウェアの同時故障（単一障害点）を何が何でも絶対に防ぎたい、極めてクリティカルな少数のWebサーバーや基幹マスターDBサーバー 」 [p.63, p.64]。 |
| パーティション (Partition) |
AZ内のハードウェアを論理的な「パーティション（グループ）」に区分けし、EC2群が互いに異なるパーティションのラック群に収まるように自動分離する [p.63, p.64]。 | パーティション間でのハードウェアの重複はゼロ。大規模スケールに対応可能 [p.63]。 | 「 Hadoop、HDFS、Apache Kafka、Cassandra などの大規模な分散データ処理・複製プラットフォームにおいて、データノードが属するラック単位の障害から保護したい場合 」 [p.63]。 |
3. 【弱点確認クイズ】
問1（○×問題）
オートスケーリングをデプロイしたWebアプリケーション環境を設計している。EC2インスタンスの起動時ユーザーデータ（User Data）に「マシンの初期化、およびAmazon S3からの共通設定ファイルのダウンロードとマウントを行うシェルスクリプト」を定義した。 このユーザーデータは、Auto Scalingによって負荷急増時にインスタンスが新規に自動起動されるたび、および既存インスタンスが一度手動で「再起動（Reboot）」を施されるたびに、常に自動的に実行（ダウンロード）される仕様である。 （○ か × か） [p.57, p.62]
問2（4択問題）
ある医療プラットフォームにおいて、大量のDNAシーケンス解析バッチジョブ（ゲノム解析プログラム）を複数のEC2インスタンスを用いて実行しています。この解析プロセスは、計算中にインスタンス同士が数マイクロ秒未満の極めて高いスループットと、超低遅延ネットワーク性能で互いに密結合にデータをやり取りしなければ、全体の計算効率が破滅的に低下する仕様となっています。 この要求される極めて高度な結合パフォーマンスを確実に提供できる、最適なEC2配置設計はどれですか。 [p.63, p.64]
- A. すべての計算用EC2インスタンスを「スプレッドプレイスメントグループ」にアタッチして同一AZ内で起動する [p.63, p.64]。
- B. 異なる2つのリージョンにEC2を分散させ、VPCピアリングで相互を閉域直結してパケットを往来させる [p.40, p.63]。
- C. すべての計算用EC2インスタンスを「クラスタープレイスメントグループ」にアタッチして単一のアベイラビリティゾーン内で起動する [p.63, p.64]。
- D. インスタンスタイプに
m6i.metal（ベアメタル）を選択し、各AZに1台ずつ独立させて起動する [p.58, p.60]。
問3（○×問題）
Auto Scaling グループを適用して可用性を最大化したEC2 Webサービスを構築する際、接続してきた顧客の「ログインセッション情報」や、顧客がブラウザから画面上にアップロードした「一時的なプロフィール画像データ」を、該当する個々のEC2インスタンスのローカルメモリやマウントされているEBSボリューム（仮想物理ディスク）内に直接書き込んで保存・処理する「ステートフル（状態保持）設計」にすることで、急激なアクセススパイク発生時であっても完璧にデータを消失・不整合なく高可用に維持することができる。 （○ か × か） [p.59, p.69]
問4（4択問題）
Amazon ECSクラスター上で、S3バケットへのファイルアップロード、およびAmazon DynamoDBテーブルへの監査データの書き出しを行うためのコンテナアプリケーションを実行します。 責任共有モデルおよびAWSのセキュリティベストプラクティスである「最小権限の原則」に最も適合する、このコンテナタスクに対する正しいアクセス認可設計（IAMポリシーの適用マッピング）はどれですか。 [p.74, p.76]
- A. ECSのコンテナインスタンス（ホストとなるEC2）に紐付けられている「インスタンスロール（インスタンスプロファイル）」に、S3への書き込みとDynamoDBへの書き出しを許可するポリシーをアタッチする [p.74]。
- B. コンテナアプリケーションを構成する「タスク定義（Task Definition）」内の「タスクロール（Task Role）」に対し、該当のS3バケットおよびDynamoDBテーブルのみへの最小操作を許可するIAMポリシーをアタッチする [p.74, p.76]。
- C. AWSコンソールからルートユーザー（Root User）のアクセスキーを直接Javaプログラムコードの定数に記述し、全リソースへのフルアクセス認可を確立させる [p.20, p.176, p.183]。
- D. コンテナを実行する「ECSサービス（Service）」のセキュリティグループにおいて、S3およびDynamoDBのVPCエンドポイントのCIDR範囲へのアウトバウンドポート（443）の通信のみを許可する [p.36, p.74]。
問5（○×問題）
AWS Lambdaはサーバーレスで完全自動スケールアウトする強力なコンピューティングサービスであるが、そのプログラム関数が「VPCの外部（デフォルト）」で実行されている場合は、自社VPC内のプライベートサブネットに完全に隠蔽・配置されているリレーショナルデータベース（Amazon RDS等）と、安全に直接TCP接続を確立させてクエリ（SQL）を処理することは物理的に不可能である。 （○ か × か） [p.81]
【弱点確認クイズの解答と解説】
解答1：×
- 解説: ユーザーデータは、「インスタンスの初回起動（新規デプロイ）時の最初のブート時」に一度だけ自動実行される仕様です [p.62]。Auto Scalingによって新しく追加（スケールアウト）されたEC2の「初回起動時」にはユーザーデータは当然実行されますが、すでに起動している既存のインスタンスを単純に 「再起動（Reboot）」させたタイミングにおいては、ユーザーデータのシェルスクリプトは自動実行（再処理）されません [p.62]。再起動時にも構成を確実にフックさせたい場合は、OS側のcronやシステムデーモン（systemd）にスクリプト起動ルールを組み込んでおく必要があります。
解答2：C
- 解説: 正解は C. クラスタープレイスメントグループ です [p.63, p.64]。 問題文の決定的なシグナルは 「 極めて低いレイテンシー（低遅延）」「超高帯域スループット」「密結合な分散計算 」 の3点です [p.63]。これを唯一無二の物理配置でサポートする、同じ高速ネットワークスイッチの最短物理距離にインスタンスをパイル（凝縮）する戦略は クラスタープレイスメントグループ です [p.63, p.64]。なお、A（スプレッド）は逆にハードウェアを物理的に完全に離れたラックに分散させる（耐障害性重視の）戦略であるため、通信の高速化には寄与せず不適合となります [p.63]。
解答3：×
- 解説: 誤りです [p.59, p.69]。 インスタンスの内部に動的なファイルやメモリセッション情報を直接保持する「ステートフル設計」は、Auto Scaling環境における最大のアンチパターンです [p.69]。Auto Scalingは、アクセスの減少（スケールイン時）やインスタンスの物理障害時の自動復旧（自己修復プロセス）において、該当するEC2インスタンスをいつでも予告なしに丸ごと自動破棄（終了・削除）します [p.59, p.68, p.69]。その際、EBS内やメモリ内にのみ保存されていたユーザーデータやログイン状態はすべて物理的に消滅（消失）してしまいます [p.59, p.69]。 そのため、高可用設計（Reliability）においては、データはすべてインスタンスの外部にある共有共通サービス（セッションは ElastiCache / DynamoDB へ、画像などのファイルは Amazon S3 / EFS へ）に完全に追い出し、EC2自体は「いつでも使い捨て・追加が可能な状態」を維持する「ステートレス設計（無状態化）」 を施すのが絶対的なルールとなります [p.69-70]。
解答4：B
- 解説: 正解は B. タスクロール（Task Role）の個別適用 です [p.74, p.76]。 コンテナアプリケーションから他のAWSマネージドサービスへの操作を認可する際、最も安全に最小権限の境界（セキュリティ）を適用できるアタッチメント箇所は、ECSのタスク定義内の 「 タスクロール（Task Role） 」 です [p.74, p.76]。A（インスタンスロールへの付与）は同一EC2ホスト上の無関係なコンテナにも権限をバイパスさせてしまうためアンチパターンとなります [p.74]。Cのコードへのアクセスキー直書きはセキュリティ上の致命的な脆弱性であり論外です [p.20, p.183]。Dのセキュリティグループはあくまでネットワーク通信（ポート）の制御を担うだけであり、API操作自体の可否（認可アクション）はコントロールできません [p.36, p.181]。
解答5：○
- 解説: 記述の通りです [p.81]。デフォルト状態（VPC設定なし）のLambda関数は、AWSがグローバルに用意した共通の仮想パブリック領域からキックされます [p.81]。そのため、インターネットからのすべての通信経路を物理的に遮断しているプライベートサブネット内のデータベース（RDS等）へ、TCP接続のハンドシェイクを到達させることはできません [p.38, p.81]。これをセキュアに接続解決するためには、Lambda関数に対して 「VPC設定」を施し、特定のVPC、プライベートサブネット、およびデータベースへのアクセスを許可したセキュリティグループを安全にマッピング・設定（Lambda in VPC） してデプロイする必要があります [p.36, p.81]。
🏆 これで、第3章コンピューティングと関連サービス（EC2、EBS最適化、プレイスメントグループ、ELB＆Auto Scaling、ECSサーバーレスコンテナ、Lambda）の重要「ひっかけパターン」および「混同しやすい比較論点」の完全総復習が完了しました！
このコンピューティング（EC2/Lambda）と、前回のネットワーク（VPC）の境界線を自分の言葉で完全に説明できるようになれば、SAA-C03試験における得点力はすでに合格ラインを大きく超えています。
模擬試験の復習、および本試験への挑戦に向けて、最高の準備が整いました。あなたの努力が素晴らしい結果となって結実することを心から応援しております！🏁