【SAA-C03】直前チートシート (2/6) コンピューティング・ストレージ

この記事の位置づけ

SAA-C03 直前チートシート全 6 回の第 2 回（コンピューティング・ストレージ）です。当日戦略・早見表 200 行・シリーズ目次は 第 1 回 にあります。各トピックは「要点 → 比較表 → 引っかけ」の順で、優先度 A（毎回級）→ B（頻出）→ C（たまに）の順に読んでください。数値・仕様は改定されることがあるので、受験前に公式の試験ガイドで最終確認を。

コンピューティング

コンピューティングは「①実行時間（Lambdaは15分の壁）②中断できるか（Spot可否）③運用負荷（マネージド／サーバーレス優先）④コミット期間（RI／Savings Plans）」の4軸で正解が決まる。A→B→Cの順に眺め、★はこのスレッドで自分が質問した項目（要点を圧縮再掲）。数値・上限は暗記対象。

問題文キーワード→正解（コンピューティング編）　A: 毎回級

制約語を見た瞬間に候補を絞る合言葉集。まず最後の1文の制約を読む

• 「運用負荷最小／サーバー管理不要」→ Lambda・Fargate（EC2自前構築の選択肢を消す）
• 「15分超」「常時稼働」「GPU」「ステートフル」→ Lambda不可 → Fargate／EC2／AWS Batch
• 「中断できない」「期限内に必ず完了」→ Spot不可 → オンデマンド or RI／SP
• 「中断OK・バッチ・CI・ステートレス」→ Spot（最大90%引）
• 「Fargate／Lambdaも割引」「ファミリー・リージョンが変わるかも」→ Compute Savings Plans
• 「Kubernetes」「マルチクラウド」明記→ EKS、書いてなければ ECS on Fargate
• 「起動に時間がかかりASGが過剰起動」→ インスタンスウォームアップ／「毎日決まった時刻」→ スケジュール／「CPU 50%維持」→ ターゲット追跡
• 「メモリ内データを保持したまま停止」→ ハイバネーション／「固定プライベートIPを待機系へ」→ セカンダリENI付替え

キーワード→正解の対応

問題文のキーワード	正解	消す選択肢
短時間・イベント駆動・断続的	Lambda	EC2常時稼働
長時間コンテナ・運用負荷最小	ECS/EKS on Fargate	EC2起動タイプ自前管理
完全制御・GPU・特殊要件	EC2（or ECS on EC2）	Lambda
中断可の大量並列バッチを安く	AWS Batch＋Spot	EC2常時稼働・Lambda
安定ベース負荷＋柔軟性	Compute Savings Plans	Standard RI
特定AZの容量だけ確保	キャパシティ予約	Savings Plans（容量は確保しない）
ソケット/コア単位ライセンス	Dedicated Host	Dedicated Instance
Java Lambdaのコールドスタート	SnapStart	Provisioned Concurrency（高コスト）
エッジで軽いヘッダー操作	CloudFront Functions	Lambda@Edge（過剰）
新AMIを全台に安全適用	ASG Instance Refresh	手動終了・再作成

引っかけ

• 「最もコスト効率が良い」でも要件（中断不可・HA・RPO）を落とした選択肢は不正解 → 公式サンプルQ6: 月末だけ超過する中断不可ジョブ → オンデマンド一時追加（Spot・追加RI・サイズ変更は×）
• 「できる」≠「最適」→ 技術的に可能でも運用負荷・コストが高い自前構築は消す
• 「Lambdaで動画トランスコード／数時間バッチ」→ 不可（Batch／Fargate／MediaConvert）

EC2購入オプション ★　A: 毎回級

「コミットの種類×中断可否」で選ぶ。金額コミット＝Savings Plans、構成コミット＝RI

• オンデマンド: 秒課金・コミットなし → 短期・予測不能・中断不可の一時的な増加（サンプルQ6の正解）
• RI: 1年／3年、全額前払いが最安。Standard 最大72%・ファミリー変更不可（同ファミリー内サイズ変更・AZ変更のみ）・マーケットプレイスで売却可／Convertible 最大66%・ファミリー/OS/テナンシー変更可・売却不可
• Savings Plans: 「$/時」の金額コミット。Compute SP 最大66%（ファミリー・サイズ・リージョン・OS・テナンシー問わず、Fargate／Lambdaにも適用）／EC2 Instance SP 最大72%（リージョン内の特定ファミリー固定、サイズ/OS/AZ/テナンシーは自由）
• Spot: 最大90%引、2分前の中断通知（休止を選ぶと即時開始で2分猶予なし）、中断時の挙動は終了/停止/休止を選択可。ASG混合インスタンス・複数プール・price-capacity-optimized配分で中断影響を分散、キャパシティ再調整で中断前に入替
• Dedicated Host: 物理サーバー専有、ソケット/コア/VM単位のBYOL（Windows Server／SQL Server／RHEL／SUSE）、ホストアフィニティ／Dedicated Instance: ハード専有だがソケット・コアの可視性なし・ソケット/コア単位BYOL不可（SQL Server License Mobility等の一部のみ）
• オンデマンドキャパシティ予約: 特定AZの容量だけ確保、割引なし、RI／SPと併用で割引。ゾーンRIは容量予約付き、リージョンRIは割引のみ
• 定石は3層: 24×365ベース→RI／SP、変動分→オンデマンド＋ASG、中断可→Spot
• RIとSPは併用可（RIが先に適用）。Organizations一括請求で組織内共有。RIはRDS／ElastiCache／Redshift／OpenSearchにも存在

購入オプション比較

オプション	割引	柔軟性・条件	使いどころ
オンデマンド	なし	コミットなし・秒課金	短期・予測不能・中断不可の一時増
Standard RI	最大72%	1/3年、ファミリー固定、売却可	構成が完全に固定
Convertible RI	最大66%	ファミリー/OS/テナンシー変更可、売却不可	構成が変わりうる長期
Compute SP	最大66%	$/時コミット、ファミリー・リージョン・OS不問、Fargate/Lambdaにも	柔軟性重視（現在の推奨）
EC2 Instance SP	最大72%	リージョン内の特定ファミリー固定	特定ファミリーで安定稼働
Spot	最大90%	2分前通知で中断	バッチ・CI・ステートレス・中断OK
Dedicated Host	—	物理サーバー専有、ソケット/コアBYOL	ライセンス・コンプライアンス
Dedicated Instance	—	ハード専有、ホスト可視性なし	物理分離だけ必要
キャパシティ予約	なし	AZの容量確保のみ、RI/SPと併用可	容量保証は欲しいがコミットしない

引っかけ

• 「ソケット/コア単位のライセンス持込」→ Dedicated Host（Dedicated Instanceはソケット/コアの可視性がなくライセンスを紐付けられない）
• 「Fargate/Lambdaへ移行予定でも割引」「ファミリー・リージョンを変えるかも」→ Compute SP（EC2 Instance SP／Standard RIは固定）
• 「容量を確保したいが長期契約は嫌」→ キャパシティ予約（Savings Plansは容量を確保しない）
• 「月末だけ処理時間超過・中断不可」→ オンデマンド一時追加（Spotは中断、追加RIは不要期間も課金、Scheduled RIは廃止済み）

Lambda 基本と制限値 ★　A: 毎回級

イベント駆動・短時間・サーバーレスの本命。「15分」と「10GB」を覚える

• 最大実行時間 15分（900秒、既定3秒）。メモリ 128MB〜10,240MB（1MB刻み）、CPUはメモリに比例 → メモリを増やすと速くなり総コストが下がることも
• /tmp 512MB〜10,240MB、zip 50MB（展開後250MB）、コンテナイメージ 10GB、レイヤー最大5、環境変数合計4KB
• ペイロード: 同期6MB（ストリーミング応答は200MB）／非同期1MB（2025年10月に256KB→1MBへ拡大。旧教材の「256KB」は古い）。同時実行 既定1,000/リージョン（引上げ可）、超過は429スロットリング
• 課金＝リクエスト数＋GB秒（1ms単位）。アイドル0円。arm64（Graviton）は実行単価が20%安（価格性能比は最大34%向上）、Compute SPも適用
• 実行ロール＝Lambdaが他サービスを呼ぶ権限／リソースベースポリシー＝誰がこのLambdaを呼べるか（lambda:InvokeFunction）
• 関数URL: API Gateway不要の直接HTTPSエンドポイント（認証は NONE／AWS_IAM のみ）
• 永続ストレージはEFSマウント可。シークレットは Secrets Manager／Parameter Store（コード・環境変数にハードコード×）
• 定番構成: API Gateway＋Lambda＋DynamoDB（＋Cognito、静的フロントはS3＋CloudFront）

引っかけ

• 「15分を超える処理」「GPU」「常時稼働」→ Lambda不可 → Batch／Fargate／EC2（Step Functionsで分割する手もある）
• 「実行時間が長く常時高負荷」→ LambdaはEC2/Fargateより高くなる（従量課金の逆転）
• 「Lambdaが遅い」→ まずメモリ増量（CPU比例）。タイムアウト延長だけでは根本解決にならない

Lambda 同時実行・コールドスタート・VPC ★　A: 毎回級

Reserved＝上限と確保（無料）、Provisioned＝常時ウォーム（有料）、SnapStart＝スナップショット復元

• 予約済み同時実行（Reserved）: 関数に上限を割当て＝他関数の枯渇防止＋DBへの過負荷制限。無料。0にすると関数停止
• プロビジョニング済み同時実行（Provisioned）: 初期化済み実行環境を事前確保しコールドスタート排除。有料、Application Auto Scalingでスケジュール可
• SnapStart: 初期化済みスナップショットから復元しコールドスタートを大幅短縮。Java 11+／Python 3.12+／.NET 8+ で利用可（Node.js不可）。Javaは追加料金なし、Python/.NETはキャッシュ＋復元に少額課金（Provisionedより安価）。Provisioned Concurrency・EFS・512MB超の/tmpとは併用不可。初期化時に生成した乱数・一意IDが使い回されるリスクに注意
• VPC内リソース（RDS／ElastiCache）にアクセス→ VPC設定（サブネット＋SG）が必要。VPC Lambdaは単体でインターネットに出られない → NAT GW or VPCエンドポイント
• Lambda→RDSの大量短命接続で接続枯渇 → RDS Proxy（接続プーリング、フェイルオーバー短縮）
• 非同期呼出しは2回自動リトライ後 DLQ（SQS/SNS）or Destinations（成功/失敗を SQS/SNS/Lambda/EventBridge、失敗のみS3へ）
• バージョン＋エイリアス、加重エイリアスでカナリアリリース

同時実行・コールドスタート対策の比較

機能	何をする	コスト	使いどころ
Reserved Concurrency	関数ごとの上限＝確保	無料	他関数・DBを守る、暴走防止
Provisioned Concurrency	事前初期化した環境を常時確保	有料（確保分）	レイテンシ厳格、確実にウォーム
SnapStart	初期化済みスナップショットから復元	Java無料／Python・.NETはキャッシュ+復元に少額（Provisionedより安い）	Java等のコールドスタート短縮

引っかけ

• 「Java Lambdaのコールドスタートが遅い・コストは抑えたい」→ SnapStart／「常にウォームを保証」→ Provisioned Concurrency（高コスト）
• 「VPC設定したらS3/外部APIに届かない」→ NAT GW か Gatewayエンドポイント（VPC設定だけではインターネット不可）
• 「Lambda増設でRDSが too many connections」→ RDS Proxy（インスタンス拡大は次善）
• 同時実行上限はリージョン全体で共有 → 1関数の暴走が他関数を巻き込む → Reservedで分離

EC2 Auto Scaling ポリシーとヘルスチェック ★　A: 毎回級

「何を見て台数を変えるか」の選択。ターゲット追跡が既定解、ウォームアップで過剰起動を防ぐ

• ASG: 最小/希望/最大。複数AZに分散（リージョン跨ぎ不可）。ASG自体は無料。起動テンプレートを使う（起動設定は非推奨・編集不可、2024/10/1以降に作成したアカウントでは作成不可）
• ターゲット追跡: 平均CPU 50%維持・ALBRequestCountPerTarget など目標値を維持（推奨・最もシンプル）
• ステップ: 閾値の段階ごとに台数変更／シンプル: 1閾値→1アクション＋クールダウン（既定300秒。クールダウンはシンプルのみ、ターゲット追跡/ステップはウォームアップで制御）
• スケジュール: 毎朝9時に増やす等の予測可能な負荷／予測スケーリング: MLで48時間先を1時間単位で予測し事前起動（24時間以上の履歴が必要、推奨2週間、6時間ごとに更新）
• インスタンスウォームアップ: 起動後N秒はメトリクス集計に含めず過剰スケールを防ぐ（サンプルQ9: 起動に1分かかるアプリ → ステップ＋ウォームアップ）
• ヘルスチェック: EC2（既定・OS/基盤のみ）／ELB（アプリ層の異常も検知して入替え）。猶予期間で起動直後をunhealthy扱いしない
• カスタムメトリクス: SQSキュー長÷インスタンス数（backlog per instance）でワーカーをスケール。メモリ使用率はCloudWatchエージェント必須
• HAの定石: ALB＋ASGを複数AZ＋RDS Multi-AZをプライベートサブネット（サンプルQ8）

スケーリングポリシー比較

ポリシー	トリガー	向く場面
ターゲット追跡	指標を目標値に維持（CPU50%・ALBリクエスト数/ターゲット）	迷ったらこれ（推奨）
ステップ	閾値の段階ごとに±N台/％	負荷の大きさで台数を変える。ウォームアップと併用
シンプル	1閾値→1アクション、クールダウン300秒	レガシー、ほぼ選ばない
スケジュール	cron/日時指定	毎朝9時・月末など予測可能な負荷
予測	MLで48時間先を予測し事前起動（履歴24時間以上）	日次/週次の周期パターン

引っかけ

• 「CPUを一定に保つだけ」→ ターゲット追跡／「毎日決まった時刻」→ スケジュール／「周期パターンを事前に」→ 予測（ステップ/シンプルは古い選択肢）
• 「ELBは異常と判定したのにASGが入替えない」→ ASGのヘルスチェックタイプをELBに（EC2タイプはアプリ障害を見ない）
• 「起動が遅くてタイムアウト・二重起動」→ ウォームアップ／猶予期間（ElastiCacheやCloudFrontは無関係：サンプルQ9）
• ASGだけではAZ間の負荷分散はしない（ELBが必要）。「メモリでスケール」は標準メトリクスに無い

ECS / EKS / Fargate 選定とIAMロール ★　A: 毎回級

「Kubernetesが必要か」→ECS/EKS、「サーバーを管理したいか」→EC2/Fargate の2段判断

• ECS: AWS独自オーケストレーション、学習コスト低、AWSに閉じた新規構築向け
• EKS: マネージドKubernetes（コントロールプレーンはAWS管理・時間課金あり）。既存K8s資産・マルチクラウド・K8sスキル保有チーム向け。ECS Anywhere／EKS Anywhereでオンプレも
• 起動タイプ: EC2（ノード自己管理、常時高負荷ならRI/SP/Spotで安い、GPU等の特殊要件）／Fargate（サーバーレス、タスク単位のvCPU/メモリ課金、運用負荷最小）。ECS・EKS両方でFargate可
• Fargate Spot: 最大70%引（中断OKのタスク）。Fargateのエフェメラルストレージは既定20GiB→最大200GiB、複数タスクの共有永続化はEFS
• IAM: タスクロール＝コンテナ内アプリの権限（S3等）／タスク実行ロール＝ECRプル・CloudWatch Logs出力／EC2起動タイプではインスタンスロールも別物
• ECR: マネージドレジストリ、イメージ脆弱性スキャン、ライフサイクルポリシー、クロスリージョンレプリケーション
• ALB連携: パスベースルーティングでマイクロサービス、動的ポートマッピング（EC2起動タイプ bridge）で1ホストに複数タスク
• App Runner: ソース/イメージからWeb/APIを最速デプロイ。App2Container・AWS Load Balancer Controller・VPC CNI はSAA範囲外

コンテナ選定の対比

軸	選択肢A	選択肢B
オーケストレーション	ECS：AWS独自・学習コスト低・AWS専用	EKS：Kubernetes標準・移植性・既存K8s資産
起動タイプ	EC2：ノード自己管理・GPU等特殊要件・RI/SP/Spotで安価	Fargate：サーバーレス・タスク単位課金・運用負荷最小
IAMロール	タスクロール：コンテナ内アプリの権限	タスク実行ロール：ECRプル・ログ出力
ストレージ	EBS：単一タスク	EFS：複数タスク・複数AZで共有

引っかけ

• 「Kubernetes」と明記→ EKS。書いてなければ ECS on Fargate が「運用負荷最小」
• 「コンテナからS3にアクセスできない」→ タスクロール（実行ロールやインスタンスロールではない）
• 「常時高負荷で稼働」→ FargateよりEC2起動タイプ＋RI/SPが安い場合あり
• 「複数タスク・複数AZで共有ファイル」→ EFS（EBSは単一タスク）

Lambda イベントソースと呼び出しモデル ★　B: 頻出

同期／非同期／ポーリングの3種で、リトライとエラー処理の場所が違う

• 同期: API Gateway・ALB・関数URL・SDK直接呼出し。エラー処理は呼び出し側、ペイロード6MB
• 非同期: S3イベント・SNS・EventBridge。Lambda内部キューに入り2回自動リトライ → DLQ／Destinations（ペイロード1MB）
• ポーリング（イベントソースマッピング）: SQS・Kinesis・DynamoDB Streams・MSK・Amazon MQ。Lambdaがバッチで取得し、成功でメッセージ削除/チェックポイント
• SQS→Lambda: 標準キューは自動スケールアウト、FIFOはMessageGroupId単位で順序。SQSの可視性タイムアウトは関数タイムアウトの6倍以上（＋バッチウィンドウ秒）が公式推奨、関数タイムアウト≦可視性タイムアウトは必須
• Kinesis／DynamoDB Streams: シャード単位で順序処理。失敗レコードはバッチ分割（bisect）・最大再試行回数・失敗先（SQS/SNS）を設定
• 定番トリガー: EventBridge（cron/rate）で定期実行、S3 PUTでサムネイル生成、DynamoDB Streamsで変更駆動
• Step Functions: 複数Lambdaの順次/並列/再試行/待機をオーケストレーション（Lambda→Lambda直接連鎖は×）

呼び出しモデル比較

呼び出し	主なソース	リトライ	失敗時
同期	API Gateway・ALB・関数URL	なし（呼び出し側）	呼び出し側でハンドリング
非同期	S3・SNS・EventBridge	2回自動	DLQ／Destinations（SQS/SNS/Lambda/EventBridge/S3）
ポーリング（ESM）	SQS・Kinesis・DynamoDB Streams・MSK	成功まで再試行（ストリームはバッチ分割・最大回数）	SQSはDLQ、ストリームは失敗先(SQS/SNS)

引っかけ

• 「Lambdaが同じイベントを2回処理した」→ 非同期/ポーリングは少なくとも1回配信 → 処理を冪等化（重複はバグではない）
• 「SQSメッセージが複数Lambdaで重複処理」→ 可視性タイムアウトを関数タイムアウトより長く
• 「S3イベントをFIFO SQSへ」は不可（標準キューのみ）。Destinationsの宛先もFIFO不可。「1イベントを複数処理へ」→ SNS/EventBridge経由

EC2 インスタンスファミリーと Graviton ★　B: 頻出

名前の1文字目で用途、「g」ならGraviton。ワークロード特性→ファミリーを即答

• 命名: c7g.xlarge ＝ ファミリー(c)・世代(7)・属性(g=Graviton, a=AMD, i=Intel, n=高ネットワーク, d=ローカルNVMe)・サイズ
• T: バースト可能（ベースライン＋CPUクレジット、unlimitedモードで超過分課金）。低負荷・開発向け、クラスタープレイスメント不可
• M: 汎用／C: コンピューティング最適化（HPC・エンコード・推論）／R・X: メモリ最適化（インメモリDB・SAP、Xは超大容量）
• I・D: ストレージ最適化（I=NVMe SSD高IOPS、D=HDD大容量）／P・G: GPU（学習/グラフィックス）／Inf・Trn: ML推論/学習チップ／Hpc: HPC専用
• Graviton（ARM）: 同性能で最大40%の価格性能比向上（目安）、名前に「g」（m7g, c7g, r7g, t4g）。RDS・ElastiCache・OpenSearch・Lambda(arm64)・Fargateでも選択可
• Nitro: 拡張ネットワーキング ENA（数十〜100Gbps級）／EFA: HPC・MLのOSバイパス低遅延（MPI/NCCL）／EBS最適化で専用帯域
• インスタンスストア: ホスト直結の一時ディスク、最高IOPS、停止/終了で消失（再起動は残る）。バッファ・キャッシュ・一時データ向け
• 適正サイズ: Compute Optimizer／Cost Explorerの推奨で縮小、Graviton移行、非本番はT系・小サイズ

インスタンスファミリー早見

ファミリー	最適化	典型用途
T	バースト（クレジット制）	低負荷Web・開発・テスト
M	汎用	バランス型アプリ・小規模DB
C	コンピューティング	HPC・エンコード・推論・ゲームサーバー
R / X	メモリ	インメモリDB・キャッシュ・SAP HANA
I / D	ストレージ（NVMe/HDD）	NoSQL・DWH・分散FS
P / G / Inf / Trn	GPU・MLチップ	ML学習/推論・グラフィックス
Hpc	HPC専用	tightly-coupled並列計算

引っかけ

• 「コストを下げたい、ARM対応可能」→ Graviton移行が定番解（x86依存ソフトなら不可）
• 「インメモリDB・大容量キャッシュ」→ R系（C系は×）。「HPCのノード間通信」→ EFA＋クラスタープレイスメント
• 「停止後もデータ保持」→ EBS。インスタンスストアは停止で消える（インスタンスストア型は停止できず終了のみ）
• 「ネットワーク書込み遅延」に拡張ネットワーキングを選ばせる誤答（原因がCPU処理なら効かない）

プレイスメントグループ ★　B: 頻出

近づける（Cluster）／分散DB向けに分ける（Partition）／1台ずつ離す（Spread）

• Cluster: 単一AZ内の物理的に近い場所に密集 → 低レイテンシ・高スループット（HPC、tightly-coupled並列）。EFAと併用。ハード障害で同時に落ちるリスク
• Partition: 独立ラック群（電源・NW別）に分散、AZあたり最大7パーティション（複数AZ跨ぎ可）。HDFS／Cassandra／Kafkaのレプリカを障害ドメインに分ける
• Spread: 1台ずつ別ハードウェアに厳密分散、AZあたり最大7インスタンス（複数AZ跨ぎ可、3AZなら計21台）。少数の重要インスタンスを同時障害から守る
• 異なるインスタンスタイプの混在は可。T系（バースト）・Mac1・M7i-flexはCluster非対応、Clusterは同一AZ必須。Dedicated Hostはプレイスメントグループ不可、停止/休止設定のSpotも不可
• 既存インスタンスは停止→プレイスメント変更→起動でグループへ移動可。1インスタンスは同時に1グループのみ、グループ同士の結合は不可

プレイスメントグループ比較

種類	配置	目的	制約
Cluster	単一AZに近接配置	低レイテンシ・高スループット	同時障害リスク、AZ跨ぎ不可
Partition	独立ラック群に分散	障害分離（分散DB向け）	AZごと最大7パーティション
Spread	個別ハードウェアに分散	個々の障害耐性	AZごと最大7インスタンス

引っかけ

• 「HPCで高速通信」→ Cluster（Spreadと真逆：Clusterは近づける、Spreadは離す）
• 「少数の重要インスタンスを守る」→ Spread（Partitionは分散システムのレプリカ配置が主眼）
• 「Kafka／Cassandra／Hadoopクラスタ」→ Partition
• Clusterは単一AZ → AZ障害で全滅。HA要件があればSpread／Partition＋複数AZ

Auto Scaling 運用機能（ライフサイクルフック／ウォームプール／Instance Refresh／終了ポリシー）★　B: 頻出

起動前後・終了前後に「待つ」「前もって温める」「安全に入れ替える」を制御

• ライフサイクルフック: Pending:Wait／Terminating:Wait で待機状態を挟み、起動時の初期化・終了前のログ退避を実行。既定タイムアウト1時間（グローバル上限は48時間 or ハートビート×100の小さい方）、EventBridge（→Lambda/SNS/SQS）に通知
• ウォームプール: 事前初期化済みインスタンスを停止（安価・推奨）/実行/休止状態で待機 → 起動時間の長いアプリのスケールアウトを高速化
• Instance Refresh: 起動テンプレート更新後にローリングで全インスタンスを入替え（最小正常率、チェックポイント、自動ロールバック）→ 新AMI適用の定番
• 終了ポリシー既定: インスタンス最多AZ → 最古の起動設定／起動テンプレート（旧バージョン）→ 次の課金時間に最も近いもの（同点はランダム）。OldestInstance／NewestInstance／OldestLaunchTemplate／AllocationStrategy等に変更可。AZ間の均衡は常に最優先
• スケールイン保護（インスタンス/ASG単位）、スタンバイ状態（メンテ中は外す）、デタッチ/アタッチ
• 混合インスタンスポリシー: 複数タイプ＋オンデマンド/Spot比率、属性ベースのタイプ選択、キャパシティ再調整で中断前に入替
• AZ再調整: AZ間の台数が偏ると自動で均す。起動が24時間失敗し続けると起動プロセスが停止される（目安）

引っかけ

• 「終了前にログを退避したい」→ ライフサイクルフック（Terminating:Wait）
• 「新AMIを全台に安全に適用」→ Instance Refresh（手動終了・再作成ではない）
• 「起動に数分かかるアプリのスケールアウトを速く」→ ウォームプール or ゴールデンAMI
• 「特定インスタンスをスケールインで消したくない」→ スケールイン保護

Lambda@Edge vs CloudFront Functions ★　B: 頻出

エッジ処理の使い分け。軽い→CloudFront Functions、重い・外部呼出し→Lambda@Edge

• CloudFront Functions: JavaScript（ES5.1準拠）、サブミリ秒、ビューワーリクエスト/レスポンスのみ、ネットワーク・ファイルアクセス・リクエストボディ不可、メモリ2MB・コード10KB。ヘッダー操作・URL書換・リダイレクト・簡易認可・キャッシュキー正規化（KeyValueStore対応）
• Lambda@Edge: Node.js／Python、4イベント（ビューワー/オリジン × リクエスト/レスポンス）、実行最大30秒、外部API・ネットワーク呼出し可、us-east-1でデプロイしエッジに複製
• コスト: CloudFront Functions は Lambda@Edge の約1/6（リクエスト課金のみ、無料枠あり／Lambda@Edgeはリクエスト＋実行時間）
• 典型: A/Bテスト・User-Agent別のオリジン切替・画像リサイズ → Lambda@Edge／単純なリダイレクト・ヘッダー付与 → CloudFront Functions

エッジ処理の比較

	CloudFront Functions	Lambda@Edge
言語	JavaScriptのみ	Node.js / Python
イベント	ビューワー リクエスト/レスポンスのみ	ビューワー＋オリジン × リクエスト/レスポンス（4種）
レイテンシ	サブミリ秒	ミリ秒〜秒（最大30秒）
ネットワーク・外部呼出し	不可	可
コスト	約1/6	高い
用途	ヘッダー操作・URL書換・リダイレクト	A/Bテスト・オリジン切替・画像加工

引っかけ

• 「オリジンリクエストを書き換える」「外部サービスを呼ぶ」→ Lambda@Edge（CloudFront Functionsはビューワーイベントのみ・ネットワーク不可）
• 「最も安価・低遅延でヘッダー操作」→ CloudFront Functions（Lambda@Edgeは過剰）
• 通常のLambdaはリージョン内実行。「エッジ」「ビューワーに近い場所で」が出たらこの2択

EC2 状態・ハイバネーション・ENI・AMI・IMDSv2　B: 頻出

停止で何が消え何が残るか、RAMを保つ休止、ENI付替え、AMIはリージョン固有

• 停止→開始: パブリックIPは変わる（EIPは維持）、プライベートIP維持、インスタンスストア消失、EBS保持（EBS料金は継続）。再起動はすべて維持
• 終了: ルートEBSは既定で削除（DeleteOnTermination）、追加EBSは既定で残る
• ハイバネーション: RAM内容を暗号化EBSルートに保存して停止、再開でRAM復元。起動時に有効化・暗号化ルート必須、最長60日（超える場合は一度起動→停止→再開）（サンプルQ2: 数週間停止するがメモリを保持 → 休止）
• ENI: プライマリENIはデタッチ不可、セカンダリENIは同一AZ内の別インスタンスへ付替え可 → 固定プライベートIPのフェイルオーバー（サンプルQ3）。ホット/ウォーム/コールドアタッチ
• AMI: リージョン固有 → 他リージョンへはコピー、他アカウントへ共有可（暗号化AMIはKMSキーも共有、パブリック共有不可）。ゴールデンAMIで起動短縮
• ユーザーデータ: 既定は初回起動時のみ実行（cloud-init設定で再起動/開始のたびに実行も可）、上限16KB（Base64前）。メタデータ 169.254.169.254、IMDSv2はセッショントークン必須（PUT→GET）でSSRF対策、起動テンプレートで必須化
• ステータスチェック: システム（AWS基盤）失敗 → CloudWatchアラームの自動復旧（recover）で同じID・IP・EBSのまま別ホストへ／インスタンス（OS）失敗 → 再起動
• EIPは停止/開始でも維持（リージョンあたり既定5個）。1インスタンスに付けられるIAMロールは1つ

操作ごとの保持/消失

操作	パブリックIP	プライベートIP	インスタンスストア	RAM
再起動	維持	維持	維持	消える
停止→開始	変わる（EIPは維持）	維持	消える	消える
休止→開始	変わる（EIPは維持）	維持	消える	復元される
終了	解放	解放	消える	消える（ルートEBSも既定で削除）

引っかけ

• 「メモリ上のデータを維持したまま数日停止」→ ハイバネーション（スナップショット／インスタンスストアではない）
• 「プライベートIPを引き継いで待機系へ即時切替」→ セカンダリENI付替え（EIPはパブリックIP、プライマリENIは外せない）
• 「起動を速くしたい」→ ユーザーデータでのインストールをやめAMIに焼き込む
• 「AMIを別リージョンで共有」は不可 → コピーが必要

ECS 運用詳細（ネットワークモード・キャパシティプロバイダー・Service Auto Scaling）　B: 頻出

タスク定義→サービス→クラスターの3層。awsvpcとキャパシティプロバイダーを押さえる

• 階層: タスク定義（コンテナ・CPU/メモリ・ロール）→ タスク（実行単位）→ サービス（希望数維持・ALB連携）→ クラスター
• ネットワークモード: awsvpc＝タスクごとにENI/SG（Fargate必須・推奨）／bridge＝動的ポートマッピング（EC2）／host／none
• キャパシティプロバイダー: FARGATE／FARGATE_SPOT／ASGプロバイダー（マネージドスケーリングでEC2台数も自動）。戦略で比率指定（例: ベースはFargate、超過分はFargate Spot）
• Service Auto Scaling（Application Auto Scaling）: ターゲット追跡（ECSServiceAverageCPUUtilization／MemoryUtilization／ALBRequestCountPerTarget）、ステップ、スケジュール（予測スケーリングも対応）でタスク数を増減
• タスク配置（EC2）: 戦略 binpack（コスト）／spread（AZ・インスタンス分散）／random、制約 distinctInstance／memberOf
• デプロイ: ローリング（最小/最大正常率）、Blue/Green（CodeDeploy＋ALBの2ターゲットグループ）
• ログ・監視: awslogsドライバー→CloudWatch Logs、Container Insights、ECS Exec（コンテナ内シェル）
• シークレット: Secrets Manager／Parameter Storeから環境変数に注入（タスク実行ロールに読取権限）

引っかけ

• 「タスクごとに個別のSG/IP」→ awsvpcモード（bridgeでは不可）
• 「EC2起動タイプでタスク数に合わせてEC2も自動増減」→ ASGキャパシティプロバイダー＋マネージドスケーリング
• 「Fargateで一部を安く」→ FARGATE_SPOTを戦略に混ぜる（中断可の処理のみ）

Elastic Beanstalk　B: 頻出

コードを上げるだけでELB＋ASG＋EC2（＋RDS）を組むPaaS。無料、裏はCloudFormation

• 環境ティア: Webサーバー環境（ELB＋ASG）／ワーカー環境（SQSキューをポーリングしてバックグラウンド処理、cron.yamlで定期実行）
• 対応: Java／.NET／PHP／Node.js／Python／Ruby／Go／Docker。.ebextensions で設定拡張、インフラ側も制御可
• デプロイポリシー: 一括（最速・ダウンタイム）／ローリング／追加バッチ付きローリング（容量維持）／イミュータブル（新ASGで安全・ロールバック容易）／トラフィック分割（カナリア）
• Blue/Green: 新環境を作り環境URL（CNAME）をスワップ → 即時切替・即時ロールバック
• RDSは環境内に作ると環境削除で消える → 本番は環境外に作って接続（疎結合）
• Beanstalk自体は無料（作られたEC2等は課金）。IAMユーザー作成はできない。アプリバージョンを保持しロールバック可

デプロイポリシー比較

ポリシー	ダウンタイム/容量	特徴
一括（All at once）	あり／一時的に全停止	最速・開発用
ローリング	なし／一時的に容量減	バッチごとに更新
追加バッチ付きローリング	なし／容量維持	先に追加起動してから更新
イミュータブル	なし／容量維持	新ASGで並行起動、失敗時は即破棄
トラフィック分割	なし／容量維持	新旧に一定割合を配分（カナリア）
Blue/Green	なし	環境URLスワップ、即時ロールバック

引っかけ

• 「開発者がインフラを意識せず標準Web構成をデプロイ」→ Beanstalk（CloudFormation自作ではない）
• 「ダウンタイムなし・失敗時に即ロールバック」→ イミュータブル or Blue/Green（一括デプロイは×）
• 「Chef/Puppet」→ OpsWorks（新規利用は終了方向、SAAでは名称のみ）、「テンプレートで全リソース」→ CloudFormation、「コンテナを最速で」→ App Runner
• 「環境を削除したらDBも消えた」→ RDSを環境外に置く

AWS Batch　B: 頻出

長時間・大量のバッチジョブをキュー管理し、EC2／Spot／Fargateを自動プロビジョニング

• 構成: ジョブ定義（Dockerイメージ・vCPU/メモリ・リトライ）→ ジョブキュー（優先度）→ コンピューティング環境（マネージド/アンマネージド、EC2／Spot／Fargate／EKS）
• 実行時間制限なし（Lambdaの15分制限を超える処理向け）。Batch自体は無料
• 配列ジョブ（数万の並列サブジョブ）、ジョブ依存関係（Aの後にB）、自動リトライ
• Spotを混ぜて安く（Spot容量最適化の配分戦略）。ジョブがある間だけ起動し、終わればゼロにスケールイン
• EventBridge（スケジュール）やS3イベント→ジョブ投入が典型。ログはCloudWatch Logs
• 用途: 画像/動画の一括変換、金融計算、ゲノム解析、MLの前処理

引っかけ

• 「Lambdaで数時間のバッチ」→ 不可 → Batch（またはFargate／EC2）
• 「大量の並列バッチを最もコスト効率良く」→ Batch＋Spot（EC2を常時稼働させない）
• 「Hadoop／Spark」と明記 → EMR（Batchは汎用コンテナジョブ）

AWS Compute Optimizer ★　C: たまに

利用実績をMLで分析し「大きすぎ/小さすぎ」を推奨する適正サイズ診断。推奨のみで自動変更なし

• 対象: EC2・EC2 Auto Scalingグループ・EBS・Lambda・ECS on Fargate・RDS（Aurora含む）。近年は商用ライセンス・NAT Gateway・DynamoDB・ElastiCache・MemoryDB・DocumentDB・WorkSpaces・SageMakerにも拡大（SAAでは前半6つを押さえれば十分）
• CloudWatchメトリクスを既定14日分析（拡張インフラストラクチャメトリクスは有料で最大93日≒3ヶ月）
• 判定: Under-provisioned／Over-provisioned／Optimized。Graviton移行時の削減見込みも提示
• Organizations統合で組織横断、委任管理者を指定可。基本機能は無料（拡張メトリクスのみ有料）
• 比較: Cost Explorer＝コスト可視化・RI/SP推奨、Trusted Advisor＝広範なベストプラクティスチェック、Cost Anomaly Detection＝異常支出のML検知

コスト系ツールの役割

ツール	役割
Compute Optimizer	EC2/EBS/Lambda/Fargate/RDSの適正サイズ推奨
Cost Explorer	コスト可視化・予測・RI/SP推奨
Trusted Advisor	コスト/セキュリティ/耐障害性/性能/クォータの総合チェック
Cost Anomaly Detection	異常支出のML検知・通知

引っかけ

• 「インスタンスタイプ／Lambdaメモリが適切か診断」→ Compute Optimizer（Trusted Advisorは低使用率検出止まり）
• 「推奨するだけで自動変更しない」→ 実際のリサイズは別途（起動テンプレート更新＋Instance Refresh等）
• 「メモリ使用率も加味した推奨」→ CloudWatchエージェントのメモリメトリクスが必要

EC2 Image Builder とゴールデンAMI　C: たまに

AMI／コンテナイメージのビルド→テスト→配布パイプラインを自動化。無料

• レシピ（ベースイメージ＋コンポーネント）→ パイプライン（スケジュール実行）→ テスト → 配布（複数リージョン／アカウントへ共有）
• OSパッチ済みゴールデンAMIを定期生成 → 起動テンプレート更新 → ASG Instance Refresh でイミュータブル更新の一連が定番
• コンテナイメージはECRへ出力。内部でSystems Manager Automationを利用。サービス自体は無料（EC2/EBS/S3の使用分のみ）
• ゴールデンAMIの効果: ユーザーデータでのインストールをなくし起動時間短縮、構成の統一、ASGスケールアウト高速化

引っかけ

• 「AMIのパッチ適用と配布を手作業なしで定期化」→ Image Builder（手動でAMI作成・コピーは×）
• 「起動が遅い」→ ゴールデンAMIに焼き込む（ユーザーデータ増強ではない）
• 暗号化AMIを他アカウントに共有 → KMSキーの共有も必要、パブリック共有は不可

ストレージ

S3（クラス→Glacier→ライフサイクル→暗号化→レプリケーション）→EBS→EFS/FSx→ハイブリッド転送の順。各表の「最小保存期間・取り出し時間・上限IOPS」の数値とAの引っかけを先に読む。スレッドで質問したBackup Vault Lock／バケットキー／Object Lambda・アクセスポイント／Storage Lens／FSx ONTAP／Storage Gateway／Snow／Glacier IR vs Flexibleは各トピックに圧縮して組み込み済み。

S3 ストレージクラス（8種）　A: 毎回級

「アクセス頻度×取り出し猶予×AZ数」で選ぶ。耐久性は全クラス11ナインで差がない

• 耐久性は全クラス 99.999999999%。違いは可用性・最小保存期間・取り出し料・AZ数だけ
• Standard: 可用性99.99%、3AZ以上、最小期間なし、取り出し料なし。短命データはここ
• Intelligent-Tiering: パターン不明/変動→ほぼ一択。オブジェクト単位の監視料（128KB未満は監視外で無料・常にFrequent階層）、取り出し料なし、最小期間なし。30日未アクセス→IA階層、90日→Archive Instant階層へ自動、アクセスで自動復帰。任意でArchive Access（90日〜）／Deep Archive Access（180日〜）階層も有効化可（こちらは復元操作が必要）
• Standard-IA: 99.9%、最小30日、最小課金128KB、取り出しGB課金。One Zone-IA: 単一AZ・99.5%・約20%安、再作成可能データ専用
• Glacier Instant Retrieval: ミリ秒取り出し、最小90日、最小128KB、四半期1回程度のアクセス
• Glacier Flexible Retrieval: 最小90日、取り出し1分〜12時間（迅速/標準/大容量）
• Glacier Deep Archive: 最小180日、取り出し12〜48時間、最安（7〜10年の法定保管）
• S3 Express One Zone: 単一AZ・ディレクトリバケット・1桁ms、ML/分析の高頻度アクセス向け

S3ストレージクラス比較

クラス	可用性	AZ	最小保存	取り出し	用途
Standard	99.99%	3+	なし	即時・無料	頻繁アクセス
Intelligent-Tiering	99.9%	3+	なし	即時・無料（監視料あり）	パターン不明・変動
Standard-IA	99.9%	3+	30日	即時・有料	月1程度・即時必要
One Zone-IA	99.5%	1	30日	即時・有料	再作成可能データ
Glacier Instant	99.9%	3+	90日	ミリ秒・有料	四半期1回
Glacier Flexible	99.99%	3+	90日	1分〜12h	年1〜2回・数時間待てる
Deep Archive	99.99%	3+	180日	12〜48h	年1回以下・最安

引っかけ

• 「毎日削除するデータをStandard-IAへ」→ 不正解（最小30日分課金で逆に高い。短命はStandard）
• 「失うと困るデータを最安で」→ One Zone-IAは不可（AZ消失でデータ消失。安さの理由が単一AZ）
• 「アクセス頻度が読めない」→ Intelligent-Tiering（IAは頻繁に取り出すと取り出し料で逆転）
• 「アーカイブだが即時に取り出したい」→ Glacier Instant Retrieval（Flexibleは数分〜時間）

Glacier 取り出しティアと復元　A: 毎回級

「何時間待てるか」と「年何回か」の2軸で3クラス×ティアを決める

• Flexible Retrieval: 迅速（Expedited）1〜5分／標準3〜5時間／大容量（Bulk）5〜12時間。Bulkが最安
• Deep Archive: 標準12時間以内／大容量48時間以内。迅速なし
• Instant Retrieval: ミリ秒、通常のGETで読める（復元操作不要）。ストレージ単価はFlexibleより約1割高いだけ（us-east-1: $0.004 vs $0.0036/GB月）
• Flexible/Deep ArchiveはRestoreObjectで一時コピーを作ってから読む（元はGlacierのまま、有効日数を指定）
• 迅速取り出しを保証したい→ プロビジョンドキャパシティ（別料金、1ユニットで5分ごとに3回以上の迅速取り出しを保証）
• スレッド例題: 四半期1回アクセス＋2時間以内の取得→ Instant Retrieval（Flexible標準3〜5hは要件外、迅速は割高で総コスト負け）
• 目安: 即時/四半期1回→IR、数時間OK/年1〜2回→Flexible、12h以上OK/年1回以下→Deep Archive
• 最小保存: IR・Flexible 90日、Deep Archive 180日

取り出しオプション

オプション	Flexible Retrieval	Deep Archive
迅速	1〜5分	なし
標準	3〜5時間	12時間
大容量	5〜12時間	48時間

引っかけ

• 「数分以内に復元」→ Flexible迅速 or Instant（Deep Archiveは最短12時間で不可）
• 「10時間以内に復元」→ Flexible標準はOK、Deep Archive標準はNG
• 「復元したらStandardに戻る」→ 誤り（一時コピーが期限付きで作られる。恒久的に戻すならコピー）
• 旧「Glacier」＝Flexible Retrieval。現行は3階層（Instant/Flexible/Deep Archive）の名前で出る

S3 ライフサイクルとバージョニング　A: 毎回級

移行（Transition）と失効（Expiration）を自動化。バージョニングは有効化後「停止」しかできない

• ルール＝移行（クラス変更）＋失効（削除）。プレフィックス/タグ/サイズで対象指定、非現行バージョンも対象化可
• Standard→Standard-IA/One Zone-IAは「作成後30日以降のみ」が試験定番の制約（目安: 現行ドキュメントの制約一覧には記載が見当たらないが、試験はこの前提で出る）。Glacier系へは0日で即移行可
• 移行は下位方向のみ（Standard→IA→Glacier系→Deep Archive）。上へ戻すのはコピー/復元。Deep Archiveからは他クラスへ移行不可
• 128KB未満のオブジェクトは既定でどのクラスへも移行しない（2024年9月〜全移行に既定適用。ObjectSizeGreaterThanで変更可だが小オブジェクトは移行リクエスト料で損）
• 未完了マルチパートアップロードの中止、期限切れ削除マーカーの掃除もライフサイクルで
• バージョニング: 有効化後は「停止」のみ（無効化不可）。削除は削除マーカー付与で復元可。旧バージョンも課金対象
• MFA Delete: バージョン完全削除・バージョニング状態変更にMFA必須（バケット所有者＝rootのみ、CLI/APIで有効化、コンソール不可）
• ストレージクラス分析でIA移行の適期を把握。Storage Lensは組織横断の利用状況可視化

引っかけ

• 「作成10日後にIAへ移行」→ 試験では設定不可扱い（30日ルール）。「即Glacierへ」は可
• 「誤削除対策」→ バージョニング＋MFA Delete。「規制で改ざん・削除禁止」→ Object Lock（AWS Backupのトピック参照）
• レプリケーションの前提はバージョニング（送信元・宛先とも）
• Glacier系へ移行済みオブジェクトは直接GET不可→ 復元リクエストが必要

S3 暗号化（SSE-S3/KMS/DSSE/C/CSE）とバケットキー　A: 毎回級

鍵を誰が持つかで4方式。SSE-KMSのKMS API料金はバケットキーで最大99%削減

• SSE-S3: S3管理のAES-256、無料、2023年からデフォルト有効。鍵利用の監査は不可
• SSE-KMS: KMSキー（カスタマー管理キー推奨）。キーポリシー・ローテーション・CloudTrail監査可。GET/PUTごとにKMS API課金＋KMSクォータ消費
• DSSE-KMS: 2層のサーバー側暗号化（多層暗号化を規制で要求される場合）
• SSE-C: 顧客がリクエストごとに鍵を送付、HTTPS必須、AWSは鍵を保存しない。「オンプレの鍵で保存時暗号化」の解の一つ（公式サンプル問題）
• クライアントサイド暗号化（CSE）: アップロード前に自分で暗号化、AWSは平文も鍵も見ない
• S3バケットキー: バケット単位の短期データキーをキャッシュしKMS呼び出しを削減（最大99%）。有効化後の新規オブジェクトから適用、既存分に遡及しない（既存はCopyObjectで適用）。KMSのCloudTrailイベントは減り、ARNがオブジェクト→バケット単位になる
• 強制: バケットポリシーで aws:SecureTransport=false をDeny（HTTPS強制）、s3:x-amz-server-side-encryption 条件で未暗号化PUTを拒否
• KMSキーはバケットと同一リージョン。SSE-KMSオブジェクトの読み取りは s3:GetObject＋kms:Decrypt の両方が必要

S3暗号化方式

方式	鍵の管理	監査	出題文言
SSE-S3	AWS	不可	「最小運用で暗号化」
SSE-KMS	KMS（自分のCMK）	CloudTrailで可	「鍵の使用を監査」「ローテーション」
SSE-C	顧客が毎回送付	—	「自社の鍵、AWSに保存させない」
CSE	顧客（AWS外で暗号化）	—	「AWSに平文を渡さない」

引っかけ

• 「暗号化キーの使用状況を監査したい」→ SSE-KMS一択（SSE-S3では不可）
• 「SSE-KMSでKMS料金が高い／スロットリング」→ バケットキー（SSE-S3へ変更は監査要件を落とす）
• 「オンプレ管理の鍵で暗号化」→ SSE-C or CSE（SSE-S3/KMSは鍵がAWS内）
• AccessDeniedの典型: S3権限はあるが kms:Decrypt がない

S3 レプリケーション（CRR/SRR）と整合性　A: 毎回級

S3本体は全操作で強い整合性。CRR/SRRは非同期・バージョニング必須・新規オブジェクトのみ

• 整合性: 2020年12月以降、PUT/上書き/削除/LISTすべて強い整合性（read-after-write）。追加料金・設定不要
• ただしCRR/SRRは非同期→レプリカ先は遅れる（結果整合性）。ここだけ区別
• CRR: 別リージョン（DR・低レイテンシ・データ主権）。SRR: 同一リージョン（ログ集約・本番/テスト同期）
• 前提: 送信元・宛先ともバージョニング有効＋レプリケーション用IAMロール。クロスアカウント可、宛先でオーナー変更可
• 既存オブジェクトは対象外→ S3バッチレプリケーションで後追い。レプリケーションの連鎖（A→B→C）はしない（レプリカの再複製はバッチレプリケーションのみ）
• 削除マーカーの複製は任意設定。宛先で別ストレージクラス指定可（DR先をDeep Archive等）
• Replication Time Control（RTC）: 新規オブジェクトの99.99%を15分以内に複製とSLA保証、監視メトリクス付き
• Multi-Region Access Point: 複数リージョンのバケットを1グローバルエンドポイントで最寄りへ（CRRと併用）

引っかけ

• 「結果整合性のラグ対策にSQS/DynamoDBを挟む」→ 不要・誤り（2019年以前の知識）
• 「レプリケーション有効化で既存データもコピーされる」→ 誤り（バッチレプリケーションが必要）
• 「SSE-KMSオブジェクトの複製」→ 宛先KMSキーの指定と権限が別途必要
• AZ障害はStandardの3AZで済んでいる。リージョン障害対策がCRR

EBS ボリュームタイプ　A: 毎回級

SSDはIOPS、HDDはスループットが指標。まずgp3、16,000超のIOPSはio2

• gp3: ベースライン3,000 IOPS／125MiB/sを容量と無関係に確保、IOPSとスループットを独立追加。gp2より約20%安→「gp2→gp3」がコスト定番。試験上の上限16,000 IOPS／1,000MiB/s（現行仕様は80,000 IOPS／2,000MiB/s／64TiBへ拡張済み）
• gp2: 3 IOPS/GiB（最大16,000）、バースト3,000、最大250MiB/s。容量を増やさないとIOPSが出ない旧世代
• io1: 50 IOPS/GiB、最大64,000／1,000MiB/s、16TiB。io2 Block Express: 500 IOPS/GiB、最大256,000 IOPS／4,000MiB/s、64TiB、耐久性99.999%、サブms
• st1（スループット最適化HDD）: 最大500 IOPS／500MiB/s。ビッグデータ・ログ・DWHのシーケンシャル大容量
• sc1（Cold HDD）: 最大250 IOPS／250MiB/s。最安、アクセス頻度が極めて低い
• HDD（st1/sc1）はブートボリューム不可、最小125GiB。サイズ上限は原則16TiB（gp3・io2は64TiB）
• Elastic Volumes: サイズ拡大・タイプ変更・IOPS変更はオンライン可、縮小は不可
• EBS最適化インスタンスでEBS専用帯域。RAID 0でIOPS合算（RAID 1は冗長）

EBSボリュームタイプ

タイプ	種別	上限IOPS	覚え方
gp3	汎用SSD	16,000（試験値／現行80,000）	3,000/125MiB/s標準装備・約20%安
gp2	汎用SSD	16,000	3 IOPS/GiB・旧世代
io1	PIOPS SSD	64,000	50 IOPS/GiB
io2 Block Express	PIOPS SSD	256,000	500 IOPS/GiB・99.999%・本番DB
st1	HDD	500	500MiB/s・シーケンシャル大容量
sc1	Cold HDD	250	250MiB/s・最安

引っかけ

• 「20,000 IOPSが必要なDB」→ io1/io2（gp3は試験上16,000まで）
• 「大量シーケンシャル読み取りを安く」→ st1（io系は過剰、sc1は性能不足）
• 「HDDでブート」→ 不可。「EBSのコスト削減」→ まずgp2→gp3
• 「複数EC2から同時アクセス」→ 基本EFS。EBSマルチアタッチはio1/io2・同一AZ・最大16台のNitroに限定（クラスタ対応FS必要）

EBS スナップショット・暗号化・インスタンスストア　A: 毎回級

スナップショットは増分でS3保存。既存の非暗号化は「スナップショット→コピー時に暗号化」。インスタンスストアは停止で消える

• スナップショット: 増分、S3に保存（リージョン単位）。途中のスナップショットを消しても復元可。別AZ/別リージョン/別アカウントへはスナップショット経由（EBS本体はAZ限定）
• 既存の非暗号化ボリュームは直接暗号化不可→ スナップショット→暗号化を指定してコピー→復元。暗号化ボリューム由来のスナップショット・復元は常に暗号化。既存ボリューム/スナップショットのKMSキー変更も不可（コピー時のみ）
• 暗号化スナップショットの共有はカスタマー管理KMSキーのみ（AWS管理キーは共有不可）、パブリック共有不可。リージョン間コピーは宛先リージョンのKMSキーで再暗号化
• アカウント設定「デフォルトで暗号化」でリージョン内の新規ボリュームを強制暗号化
• DLM（Data Lifecycle Manager）: スナップショット/AMIの作成・保持・削除・リージョン間コピーを自動化。Fast Snapshot Restore: 復元直後の初期化遅延をなくす
• EBS Snapshots Archive: 90日以上保持する低頻度スナップショットを最大75%安く（復元に最大72時間）。Recycle Binで誤削除を復旧
• インスタンスストア: ホスト直結の一時ディスク、最高IOPS、追加料金なし。停止・休止・終了で消える（再起動では残る）。一時キャッシュ・バッファ・レプリカ済みDB向け
• ルートEBSはDeleteOnTermination既定true、追加ボリュームは既定false

引っかけ

• 「メモリ上のデータも保持して停止」→ ハイバネーション（暗号化ルートEBS必須）。インスタンスストアやスナップショットではない（公式サンプル問題）
• 「停止後もデータ保持」→ EBS。「一時的で最速」→ インスタンスストア
• 「既存ボリュームで暗号化を有効化する設定変更」→ 存在しない（スナップショット経由）
• 「スナップショットは全部残さないと復元できない」→ 誤り（増分でも各スナップショットは自己完結）

EFS と S3/EBS/EFS の選び方　A: 毎回級

Linux向けマネージドNFS。複数AZ・数千台から同時マウント、使った分だけ課金

• NFSv4.1、Linux（POSIX）専用。複数AZの数千EC2/Lambda/ECS/EKS/Fargate/オンプレ（DX/VPN）から同時マウント。ペタバイト級に自動拡張
• マウントターゲットをAZごとに作成（ENI）＋SGでNFS 2049を許可。Regional（複数AZ）とOne Zone（単一AZ・安価）
• ストレージクラス: Standard／Infrequent Access（既定30日未アクセスで移行）／Archive（既定90日）。ライフサイクルで自動移行、「初回アクセスでStandardへ戻す」設定も可（既定は戻さない）。IA/Archiveで大幅削減
• パフォーマンスモード: 汎用（既定・低レイテンシ）／Max I/O（旧来の超高並列向け、Elastic/One Zoneでは不可）
• スループットモード: Elastic（推奨・自動）／Provisioned（一定の高スループット）／Bursting（容量比例）
• EFSアクセスポイント: アプリごとのルートディレクトリとPOSIXユーザーを強制（マルチテナント）
• 保存時暗号化は作成時にKMS指定、転送時はTLS。AWS Backup・EFSレプリケーション（別リージョン）・DataSync対応
• GB単価はEBS gp3より数倍高い。共有不要ならEBS、オブジェクトならS3

S3 vs EBS vs EFS

	S3	EBS	EFS
種別	オブジェクト	ブロック	ファイル（NFS）
接続	HTTP/API、無制限	単一EC2・単一AZ	複数EC2・複数AZ
容量	無制限	最大16TiB（gp3・io2は64TiB）	自動拡張・PB級
OS	問わない	問わない	Linuxのみ
典型	静的コンテンツ・バックアップ・データレイク	DB・ブート・高IOPS	共有Web/CMS・ホームディレクトリ

引っかけ

• 「Windowsで共有ファイル（SMB）」→ EFS不可 → FSx for Windows
• 「EBSを複数AZのEC2で共有」→ 不可 → EFS
• 「低頻度アクセスのファイルを安く」→ EFS IA/Archive＋ライフサイクル（S3へ移すはアプリ改修が必要）
• 「単一EC2の高IOPS DB」にEFS→ 不正解（EBS io2）

FSx ファミリー（Windows/Lustre/ONTAP/OpenZFS）　A: 毎回級

SMB/ADならWindows、HPCならLustre、マルチプロトコルならONTAP、ZFS移行ならOpenZFS

• FSx for Windows File Server: SMB、NTFS ACL、Active Directory統合（Managed AD/自社AD）、DFS名前空間、シャドウコピー、重複排除、Multi-AZ。Windows/Linux/macOSから接続可
• FSx for Lustre: HPC・ML学習・動画処理・金融モデリング向け並列FS、数百GB/s・数百万IOPS・サブms。S3をデータリポジトリにリンク（遅延ロード・結果をS3へ書き戻し）。Scratch（一時・非複製・安価）／Persistent（AZ内複製・長期）
• FSx for NetApp ONTAP: NFS・SMB・iSCSIのマルチプロトコル。スナップショット・FlexClone・重複排除・圧縮・容量プール階層化（低頻度データを自動で安い階層へ）。SnapMirrorでオンプレONTAP⇔AWSレプリケーション。Multi-AZ
• FSx for OpenZFS: NFS、低レイテンシ・高IOPS、ZFSスナップショット/クローン。オンプレZFS/Linuxファイルサーバーからの移行
• FSxファイルゲートウェイ: オンプレからFSx for Windowsへ低レイテンシアクセス（Storage Gatewayの一種）。2024年10月28日以降は新規作成不可（現行の推奨はFSx for Windowsへ直接接続）。旧問題には登場
• 全FSx: AWS Backup対応、KMS暗号化、VPC内ENI経由

FSx使い分け

FSx	プロトコル	OS/用途	決め手キーワード
Windows	SMB	Windowsアプリ共有	「SMB」「Active Directory」「NTFS ACL」
Lustre	Lustre（POSIX）	Linux HPC/ML	「HPC」「S3のデータを高速処理」「数百GB/s」
NetApp ONTAP	NFS/SMB/iSCSI	混在環境・NetApp移行	「NFSとSMB両方」「iSCSI」「SnapMirror」「オンプレNetApp」
OpenZFS	NFS	Linux・ZFS移行	「ZFS」「スナップショット/クローン」「低レイテンシNFS」

引っかけ

• 「WindowsとLinux両方から同じファイル」→ ONTAP（FSx for Windowsは基本SMBのみ）
• 「オンプレNetAppをそのまま移行」→ ONTAP（EFSではONTAP固有機能を引き継げない）
• 「S3のデータをHPC/MLで高速に読みたい」→ Lustre（EFSではない）
• 「Lustreで一時的な処理データを最安で」→ Scratch。「長期・HA」→ Persistent

Storage Gateway（4種）　A: 毎回級

オンプレにVM/アプライアンスを置き、ローカルストレージに見せてAWSへ繋ぐ「常時接続」型ハイブリッド

• S3ファイルゲートウェイ: NFS/SMBでS3をファイル共有として利用、ローカルキャッシュ。ファイル＝S3オブジェクトとしてそのまま見える（ライフサイクルでGlacierへも）。SMBはAD統合可
• FSxファイルゲートウェイ: オンプレSMBクライアント→FSx for Windows File Serverへ低レイテンシ（2024年10月28日以降は新規作成不可。試験の旧問題では選択肢に出る）
• ボリュームゲートウェイ（キャッシュ型）: プライマリはS3、頻繁アクセス分だけローカルキャッシュ。iSCSI。オンプレ容量の節約・拡張。1ボリューム最大32TiB（ゲートウェイあたり32ボリューム・計1PiB）
• ボリュームゲートウェイ（保管型/Stored）: 全データをローカルに保持し非同期でS3へEBSスナップショットとしてバックアップ。低レイテンシに全データ必要＋DR。1ボリューム最大16TiB（計512TiB）
• テープゲートウェイ: 既存バックアップソフトのテープを仮想テープライブラリ（VTL）に置換、S3→Glacier Flexible/Deep Archiveへアーカイブ
• ボリューム型/テープ型のデータはS3コンソールからオブジェクトとして見えない（EBSスナップショット/仮想テープ形式）
• 配置: VMware/Hyper-V/KVM、EC2、ハードウェアアプライアンス。ローカルキャッシュディスクが必要
• DataSyncとの違い: Storage Gateway＝常時マウントされた仮想ストレージ、DataSync＝一括/定期の転送タスク

Storage Gatewayタイプ

タイプ	プロトコル	プライマリデータ	決め手
S3ファイル	NFS/SMB	S3	「オンプレからS3をファイル共有」「S3上でオブジェクトとして扱う」
FSxファイル（新規終了）	SMB	FSx for Windows	「オンプレからFSx for Windowsへ」
ボリューム・キャッシュ型	iSCSI	S3（ローカルはキャッシュ）	「オンプレ容量が足りない」「拡張」
ボリューム・保管型	iSCSI	オンプレ（S3へ非同期バックアップ）	「全データを低遅延でローカルに」「DR」
テープ	iSCSI VTL	S3/Glacier	「物理テープ廃止」「バックアップソフトはそのまま」

引っかけ

• 「オンプレ容量を節約しつつ低遅延」→ キャッシュ型。「全データにローカル低遅延アクセス」→ 保管型
• 「テープ運用の置き換え」→ テープゲートウェイ（S3ファイルゲートウェイではない）
• 「一回限り/定期の大量移行」→ DataSync。「アプリが共有ストレージとして使い続ける」→ Storage Gateway
• 「S3のオブジェクトを他のアプリからも直接読みたい」→ S3ファイルゲートウェイ（ボリューム型は不可）

AWS Backup・Vault Lock・S3 Object Lock（WORM）　A: 毎回級

複数サービスのバックアップをプランで一元管理。ガバナンス＝権限があれば解除可、コンプライアンス＝猶予後は誰も解除不可

• AWS Backup対応: EC2/EBS/EFS/RDS/Aurora/DynamoDB/FSx全種/Storage Gateway/S3/Redshift/DocumentDB/Neptune/VMware等。バックアッププラン（頻度・保持・コールド移行）＋タグで自動割当
• 保管庫（Vault）単位でKMS暗号化・アクセスポリシー。クロスリージョン／クロスアカウントコピー、Organizationsのバックアップポリシーで全アカウント適用、Backup Audit Managerで監査
• コールドストレージへ移したリカバリポイントは最低90日保持（削除日はコールド移行日＋90日以上）
• Backup Vault Lock: ChangeableForDaysを指定→コンプライアンスモード（猶予最短3日、経過後はrootもAWSも解除不可。例外はアカウント閉鎖90日後の消去）、省略→ガバナンスモード（IAM権限で解除可）
• MinRetentionDays／MaxRetentionDays（最大36,500日）に反するジョブは失敗。ロック前の既存リカバリポイントには遡及しない
• S3 Object Lock: バージョニング必須。Governance（s3:BypassGovernanceRetention権限＋バイパスヘッダーで解除可）／Compliance（保持期間中はrootも削除・短縮不可、消すにはアカウント削除のみ）／リーガルホールド（期限なし・解除まで）。既存バケットにも有効化可
• Glacier Vault Lock: 旧Glacier保管庫のポリシーをロックする旧来の仕組み
• RDS自動バックアップは最大35日→それ以上はAWS Backup or 手動スナップショット。EBSだけならDLMでも可

WORM 3兄弟

機能	対象	モード
Backup Vault Lock	AWS Backupの保管庫	ガバナンス／コンプライアンス（ChangeableForDaysの有無で決定）
S3 Object Lock	S3オブジェクト	ガバナンス／コンプライアンス＋リーガルホールド
Glacier Vault Lock	S3 Glacier保管庫（旧）	ポリシーロック（変更不可）

引っかけ

• 「規制で7年間、誰にも消させない」→ コンプライアンスモード。「誤削除は防ぐが管理者は解除できる」→ ガバナンス
• 「ランサムウェア対策でバックアップの削除を防ぐ」→ Backup Vault Lock（コンプライアンス）
• 「複数サービスのバックアップを一元管理・監査」→ AWS Backup（サービス個別設定やcronスクリプトは不正解）
• Object Lockのガバナンスは「管理者も削除不可」ではない（バイパス権限があれば可）

DataSync と Transfer Family（オンライン転送）　A: 毎回級

DataSync＝大量ファイルのオンライン移行/定期同期、Transfer Family＝SFTP/FTPS/FTP/AS2の受け口をS3/EFSに

• DataSync: オンプレ（NFS/SMB/HDFS/オブジェクト）⇔S3/EFS/FSx（Windows/Lustre/OpenZFS/ONTAP）、AWSサービス間（S3⇔EFS⇔FSx、アカウント/リージョン間）、他クラウド（Azure Blob/GCS等）からも。オンプレ側はエージェントVM、同一アカウント内のAWS間はエージェント不要
• スケジュール実行・帯域制御・増分転送・整合性検証・メタデータ/POSIX権限保持。1タスクで10Gbps回線を使い切れる。DX/VPN＋VPCエンドポイント経由でプライベート転送可
• DataSyncはS3の任意クラス（Glacier/Deep Archive含む）へ直接書き込み可（Deep Archiveを「読む」ソースにはできない）。転送GB課金
• 「一回限り/定期の大量ファイル移行」「EFS↔EFSの定期同期」→ DataSync。「アプリがマウントし続ける」→ Storage Gateway
• Transfer Family: SFTP/FTPS/FTP/AS2のマネージドエンドポイント、保存先はS3またはEFS。認証はサービス管理（SSH鍵）/AD/カスタムIdP（Lambda・API Gateway）
• 「取引先のSFTPワークフローを変えずにS3へ」→ Transfer Family。FTP（非暗号化）はVPC内部アクセス限定で公開不可
• エンドポイントは時間課金＋転送GB課金。マネージドワークフローでアップロード後処理（タグ付け・コピー・Lambda）
• 選び方: DB→DMS（＋異種ならSCT）、サーバー→MGN、SaaS→AppFlow、ファイル→DataSync、SFTP→Transfer Family、オフライン大容量→Snow（既存顧客のみ）/Data Transfer Terminal

オンライン転送の使い分け

	DataSync	Storage Gateway	Transfer Family
役割	転送・移行・定期同期	常時ハイブリッドアクセス	プロトコルの受け口
プロトコル	NFS/SMB/HDFS/S3 API	NFS/SMB/iSCSI/VTL	SFTP/FTPS/FTP/AS2
典型	「数TBを期限内に移行」「毎晩同期」	「オンプレ容量拡張」「テープ置換」	「取引先SFTPをそのまま」

引っかけ

• 「大量データを今週中に、帯域は十分」→ DataSync（Direct Connect新設は開通に数週間〜月で間に合わない）
• 「Storage GatewayでEFSへ定期コピー」→ 誤り（EFS宛の転送はDataSync）
• 「SFTPサーバーをEC2で自前構築」→ 運用負荷で不正解（Transfer Family）
• 「DataSyncはGlacierへ直接書ける／Snowballは書けない」の対比を覚える

S3 性能・大容量転送（マルチパート／Transfer Acceleration／Express One Zone）　B: 頻出

プレフィックスで並列化、100MB超はマルチパート、遠距離アップロードはTransfer Acceleration

• オブジェクト最大50TB（2025年12月に5TBから拡張。試験値は5TB）。単一PUTは最大5GB。100MB以上でマルチパート推奨、5GB超は必須（並列・中断再開可）。コンソールは160GBまで
• プレフィックスあたり 3,500 PUT/COPY/POST/DELETE ／ 5,500 GET/HEAD /秒。プレフィックス分散で並列スケール（ランダムハッシュ接頭辞は旧手法・不要）。スケール中は一時的に503が出ることがある
• バイトレンジフェッチで並列ダウンロード・部分取得
• Transfer Acceleration: CloudFrontエッジ経由で長距離アップロードを高速化（bucket.s3-accelerate.amazonaws.com）。近距離では効果薄
• 配信はCloudFrontを前段に: S3→CloudFrontの転送無料、エッジキャッシュでGET負荷・転送コスト減
• S3 Express One Zone: 1桁ms・単一AZ・ディレクトリバケット。ML学習/分析の高頻度小オブジェクト
• S3バッチオペレーション: 数十億オブジェクトへ一括タグ付け/コピー/暗号化/Lambda実行/Glacier復元
• S3 Select: オブジェクトの一部をSQLで取得して転送量削減（新規顧客への提供は終了済み・既存顧客のみ。旧問題に登場）

引っかけ

• 「世界中から大容量ファイルをアップロード」→ Transfer Acceleration（CRRやCloudFront配信ではない）
• 「5GBを超えるファイルがアップロードできない」→ マルチパートアップロード
• 「503 Slow Down／リクエスト上限」→ プレフィックスを分ける（バケットやリージョンを増やすではない）

S3 アクセスポイント・Object Lambda・Storage Lens　B: 頻出

入口を分ける（Access Point）、取り出し時に加工（Object Lambda）、組織横断で見える化（Storage Lens）

• アクセスポイント: 1バケットに用途/チームごとの専用エンドポイント＋個別ポリシー。VPCオリジン限定可。有効権限＝バケットポリシー ∩ アクセスポイントポリシー
• 「バケットポリシーが肥大化」「チームごとに権限分離」→ アクセスポイント。VPC内限定＋Gatewayエンドポイントの組み合わせが定番
• Multi-Region Access Point: 複数リージョンのバケットを1グローバルエンドポイントで束ね最寄りへ
• Object Lambda: GET/LIST/HEAD時にLambdaでその場加工（PIIマスキング・画像リサイズ・CSV→JSON）。元オブジェクトは非破壊、加工済みコピー不要。アクセスポイント上に構築
• Object LambdaはPUTの加工には使えない。書き込み時の処理はS3イベント通知＋Lambda
• Storage Lens: 複数バケット/アカウント/組織全体のS3利用状況・コスト・暗号化/公開設定を可視化。無料メトリクス（クエリ可能期間14日）と有料の高度メトリクス（15か月・S3へエクスポート）
• Storage Lensは見える化のみ。自動でクラス変更しない（自動化はIntelligent-Tiering／ライフサイクル）

引っかけ

• 「取得時に個人情報をマスクして返す、元は変えない、コピーを増やさない」→ Object Lambda（加工済みコピーを別バケットは旧手法）
• 「自動でストレージクラスを最適化」→ Intelligent-Tiering（Storage Lensではない）
• 「S3内のPIIを検出」→ Macie（Storage Lensは利用状況を見るだけ）
• 「S3コストがどのバケットで発生か組織横断で把握」→ Storage Lens（Cost Explorerはサービス粒度）

S3 アクセス制御の定番（署名付きURL・CORS・イベント通知・静的ホスティング・Requester Pays）　B: 頻出

「一時的に」「別ドメインから」「アップロードを合図に」「サイト公開」「取り出し料は相手持ち」の即答集

• 署名付きURL: 期限付きでGET/PUTを許可。発行者の権限と認証情報の有効期限に依存（ロールの一時認証情報で発行すると先に失効）。CloudFront側は署名付きURL（単一）／署名付きCookie（複数）
• ブラウザのJavaScriptが別ドメインからS3へ→ バケットのCORS設定（公式サンプル問題）
• イベント通知の宛先: SNS／SQS標準（FIFO不可）／Lambda／EventBridge（高度なフィルタ・複数ターゲット・アーカイブ）。宛先側リソースポリシーでS3を許可
• 静的Webサイトホスティング: バケット名＝ドメイン名。WebサイトエンドポイントはHTTPS非対応→ CloudFront＋ACM（us-east-1）でHTTPS化。CloudFront経由に限定するならOAC＋バケットポリシー
• ブロックパブリックアクセス（アカウント/バケット）を維持し、公開はCloudFront OACか明示的バケットポリシーで最小限。ACLは無効化が既定
• Requester Pays: リクエスト・転送料を利用者負担、所有者はストレージ料のみ。匿名アクセス不可、大規模データセット共有向け
• HTTPS強制/暗号化強制はバケットポリシー条件（aws:SecureTransport／s3:x-amz-server-side-encryption）
• サーバーアクセスログは同一リージョン・同一アカウントの別バケットへ（同一バケットも技術的には可だがログの無限ループになり非推奨）。オブジェクト操作の監査はCloudTrailデータイベント

引っかけ

• 「他アカウントの担当者に一時的にファイルを渡す」→ 署名付きURL（IAMユーザー作成・バケット公開ではない）
• 「S3イベントをFIFO SQSへ」→ 不可（標準キュー or EventBridge経由）
• 「静的サイトを独自ドメインでHTTPS」→ CloudFront＋ACM（S3単体では不可）
• 「同じイベントを複数サービスへ」→ EventBridge または SNSファンアウト

Snow Family（オフライン大容量転送）　B: 頻出

ネットワークで1週間以上かかる・帯域が細い・オフライン→ 物理デバイスで運ぶ（試験知識。現行は新規顧客への提供終了）

• 試験の定番ラインナップ: Snowcone 8TB（軽量・DataSyncエージェント内蔵）／Snowball Edge Storage Optimized 80TB（最終世代は210TB）／Snowball Edge Compute Optimized（GPU可・エッジでEC2/Lambda）／Snowmobile 100PB（トラック）
• 目安: ネット転送に1週間以上、10TB超で帯域不足、ネットワーク未整備→ Snowball Edge。10PB超（旧）→ Snowmobile
• データはKMSで暗号化、S3へインポート。Glacier/Deep Archiveへ直接は不可→ S3経由でライフサイクル移行
• 取り込みも持ち出し（エクスポート）も可。エッジに常設しML推論/前処理も可（Compute Optimized）
• OpsHubのGUIで管理。複数台並行で数百TB〜PB
• 現状: Snowcone・Snowball Edge 80TB・Compute Optimized（52vCPU/GPU）は2024年11月に提供終了、Snowmobileも終了。2025年11月以降はSnow Family全体が新規顧客に提供されず既存顧客のみ（残るは210TB／104vCPU機）。新規の物理転送はAWS Data Transfer Terminal、オンラインはDataSync、エッジはOutpostsが公式代替。試験は「Snowball Edge＝大容量オフライン転送」で出る
• 比較: Snow＝オフライン、DataSync＝オンライン、DMS＝DB、MGN＝サーバー

引っかけ

• 「Snowballで直接Deep Archiveへ投入」→ 不可（S3→ライフサイクル）
• 「期限が迫り回線が細い」でDirect Connect新設→ 不正解（開通に数週間〜月）→ Snowball
• 「オンラインで期限内に間に合う」→ DataSync（Snowは往復配送の日数がかかる）

おわりに

前の回: 第1回 ／ 次の回: 第3回

早見表と他の回への目次は 第 1 回 にまとめています。