【SAA-C03】直前チートシート (5/6) 管理・監視・移行／高可用性・DR・コスト最適化

この記事の位置づけ

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

管理・監視・移行

運用系は「問題文が何を聞いているか（誰が／設定／性能／どこが遅い／何を運ぶ）」でサービスが即決する消去法問題が中心。各表の左列を隠して右列が出るかを確認し、数値（5分/1分、90日、4KB/8KB、210TB、1週間…）は暗記で確実に取る。

監視4兄弟の使い分け：CloudWatch／CloudTrail／Config／X-Ray　A: 毎回級

「性能・状態」「誰が」「設定がどう変わった」「どこが遅い」の問いで即決する運用系の最頻出パターン

• CloudWatch＝リソースの性能・状態（メトリクス・ログ・アラーム・ダッシュボード）
• CloudTrail＝「誰が・いつ・どのAPIを呼んだか」の操作監査（S3バケット削除の犯人探し）
• Config＝「設定がどう変わったか・準拠しているか」（SG変更の履歴、非準拠検知→SSM Automationで自動修復）※詳細は他セクション
• X-Ray＝「アプリのどこで遅延・エラーが出ているか」（分散トレーシング、サービスマップ）
• 定石の組合せ：CloudTrail→EventBridge→Lambda/SNS（特定API呼出しに自動反応）、Config非準拠→SSM Automation
• 3つとも Organizations で組織全体に集約可：組織の証跡（CloudTrail）／Configアグリゲータ／CloudWatchクロスアカウントオブザーバビリティ

問いのキーワード → 正解

問題文の問い	正解	見るもの
誰がS3バケットを削除したか	CloudTrail	API呼出し履歴
SGがいつ0.0.0.0/0に変わったか	Config	設定変更のタイムライン
CPU 80%超で通知・自動対処	CloudWatchアラーム	メトリクス
マイクロサービスのどこでレイテンシ増	X-Ray	トレース・サービスマップ
ログ内の ERROR 件数で通知	CloudWatch Logs メトリクスフィルタ	ログ

引っかけ

• 「S3オブジェクト単位の操作を記録」→ CloudTrail データイベントを有効化（デフォルトの管理イベントでは記録されない）
• 「準拠状態を継続的に監視」→ Config ルール（Trusted Advisor は定期チェックであり継続監視ではない）
• 「設定変更の記録・現在の設定」に CloudTrail を選ばない（CloudTrail は API 呼出し、変更後の状態は Config）

CloudWatch メトリクス・アラーム　A: 毎回級

AWSリソースの数値監視と、閾値超過時の自動アクションの基盤

• EC2標準メトリクス＝CPU・ネットワーク・ディスクI/O・ステータスチェック。基本モニタリング5分、詳細モニタリング1分（有料）
• メモリ使用率・ディスク空き容量・スワップは標準に無し → CloudWatch統合エージェントでカスタムメトリクス（設定はParameter Storeに置くのが定石）
• カスタムメトリクス：標準解像度1分、高解像度は1秒（高解像度アラームは10秒/30秒周期）。メトリクス保持は最長15か月（1分粒度15日→5分粒度63日→1時間粒度455日に集約）
• アラーム状態＝OK／ALARM／INSUFFICIENT_DATA。アクション＝SNS通知・Auto Scaling・EC2アクション（停止/終了/再起動/復旧）・SSM OpsItem作成
• EC2自動復旧（recover）＝システムステータスチェック失敗時に別ホストへ移行。インスタンスID・パブリック/プライベートIP・EIP・EBS・プレイスメントグループは維持、RAMとインスタンスストアのデータは消える
• 複合アラーム（AND/OR）で通知ノイズ削減。異常検出（Anomaly Detection）はMLの想定帯を閾値に
• 請求アラームは us-east-1 の請求メトリクスで作る（予算通知の本命は Budgets）
• ダッシュボードはクロスアカウント・クロスリージョン可。Synthetics＝外形監視Canary、RUM＝実ユーザー監視

引っかけ

• 「メモリ使用率でスケール／アラーム」→ CloudWatchエージェント必須（標準メトリクスに無い）
• 「1分粒度で監視」→ 詳細モニタリングを有効化（デフォルト5分のまま選ぶ選択肢は誤り）
• 「ハードウェア障害時に同じIP・EBSのまま自動復旧」→ CloudWatchアラームのEC2復旧アクション（ASGの置換はインスタンスが変わる）

CloudWatch Logs・クロスアカウントオブザーバビリティ・Contributor Insights　A: 毎回級

ログの収集・検索・通知・転送と、複数アカウント横断の監視（スレッドで質問済み）

• 収集＝CloudWatchエージェント（EC2/オンプレ）。Lambda・VPCフローログ・Route 53・CloudTrailは直接送信可
• 保持期間はデフォルト無期限 → ロググループごとに1日〜10年を設定してコスト削減。長期保管はS3へエクスポート
• メトリクスフィルタ＝ログ中の文字列（ERROR等）をカウントしてメトリクス化→アラーム
• サブスクリプションフィルタ＝ログをリアルタイムに Kinesis Data Streams／Amazon Data Firehose（旧Kinesis Data Firehose）／Lambda／OpenSearch へ流す（S3に貯めるならFirehose）
• Logs Insights＝専用クエリ言語で検索・集計（複数ロググループ・複数アカウント横断可）。Live Tailでリアルタイム表示
• クロスアカウントオブザーバビリティ＝「監視アカウント」に「ソースアカウント」がメトリクス・ログ・トレースを共有。1画面でダッシュボード・アラーム・Logs Insights、スイッチロール不要。CloudWatchの機能であり別サービスではない
• Contributor Insights＝ログから上位N件の寄与者（最多アクセスIP・最も遅いURL）を可視化。DynamoDB版はホットキー検出
• データ保護ポリシーでPIIを自動マスク。Infrequent Accessログクラス＝取込み料が安い（目安：標準の半額）・機能限定

引っかけ

• 「複数アカウントのログを1ダッシュボード／串刺し検索」→ CloudWatchクロスアカウントオブザーバビリティ（Managed Grafanaは多データソースの可視化層、SSM Explorerは運用状態）
• 「ログをS3にほぼリアルタイムで長期保存」→ サブスクリプションフィルタ＋Firehose（Lambdaで自作しない）
• 「ログ保管コストが増大」→ 保持期間を設定（デフォルト無期限を放置しない）

CloudTrail　A: 毎回級

「誰が・いつ・どのAPIを呼んだか」の監査ログ

• イベント履歴＝直近90日を無料で閲覧（管理イベントのみ。データ/Insightsイベントは表示されない）。それ以上は証跡（Trail）を作りS3へ配信、必要ならCloudWatch Logsにも
• 管理イベント（デフォルト記録：コンソール操作・API）と、データイベント（S3オブジェクト操作・Lambda呼出し・DynamoDB項目操作：別途有効化・有料）
• Insightsイベント＝異常なAPI呼出し量・エラー率を検知（大量起動・大量削除）
• ログファイル整合性検証（SHA-256ダイジェスト）で改ざん検知。暗号化はSSE-S3既定・SSE-KMS可。別アカウントのS3＋Object Lockで保護が定石
• 組織の証跡＝Organizations全アカウントを1証跡で記録。マルチリージョン証跡でグローバルサービス（IAM/STS/CloudFront）も記録
• CloudTrail Lake＝イベントをSQLで直接分析できるデータストア。通常の証跡はAthenaで分析
• 配信はAPI呼出しから数分後（リアルタイムではない）。即時反応は EventBridge のAPIイベントで

引っかけ

• 「特定S3オブジェクトを誰がダウンロードしたか」→ データイベント有効化（管理イベントだけでは残らない）
• 「ログの改ざんを検知」→ ログファイル整合性検証（Object Lockは削除防止で、検証は別機能）
• 「過去1年のAPI呼出しを調べたい」→ 証跡がなければ不可（イベント履歴は90日まで）
• S3バケットキー有効化 → オブジェクト単位のKMS呼出しがCloudTrailに残らなくなる（厳密なキー監査要件なら注意）

Systems Manager 主要機能　A: 毎回級

EC2・オンプレサーバーの運用を「SSH無し・手作業無し」で回すツール群

• 前提＝SSM Agent＋IAMロール（AmazonSSMManagedInstanceCore）＋SSMエンドポイントへのアウトバウンドHTTPS 443。プライベートサブネットはVPCエンドポイント（ssm／ssmmessages／ec2messages）
• Session Manager＝ブラウザ/CLIからシェル接続。インバウンドポート開放なし・SSH鍵なし・踏み台不要、IAMで制御、操作ログをS3/CloudWatch Logsへ、ポートフォワーディング可
• Run Command＝多数のインスタンスにSSMドキュメント（AWS-RunShellScript等）を一括実行、タグ指定・レート制御
• Patch Manager＝パッチベースライン＋メンテナンスウィンドウでOSパッチ自動適用、準拠レポート。「今すぐパッチ」も可
• State Manager＝望ましい設定を定期的に強制維持。Automation＝ランブック（AMI更新・再起動・Configの自動修復）
• Parameter Store＝設定値・シークレットの階層保存。Standard：4KB・1万件・無料／Advanced：8KB・10万件・有料（パラメータポリシー＝有効期限はAdvanced限定、Advanced→Standardへの戻しは不可）。SecureStringはKMS暗号化
• Inventory（ソフトウェア一覧）、Fleet Manager、Compliance。オンプレサーバーもアクティベーションで管理（ハイブリッド）

「〜したい」→ SSMの機能

要件	機能
SSHポートを開けずにEC2へログイン	Session Manager
数百台にコマンドを一括実行	Run Command
OSパッチを定期・自動で	Patch Manager＋メンテナンスウィンドウ
設定ドリフトを自動で戻す	State Manager
手順（再起動・修復）を自動化	Automation ランブック
設定値・シークレットを安く保存	Parameter Store

引っかけ

• 「踏み台サーバー／SSH鍵管理をなくしたい」→ Session Manager（SGでポート22を開ける選択肢は不要）
• 「DBパスワードの自動ローテーション」→ Secrets Manager（Parameter Storeにネイティブのローテーション無し）
• 「Session Managerが繋がらない」→ IAMロール／SSM Agent／VPCエンドポイント（アウトバウンド）の不足を疑う
• 「パッチ適用に Ansible／手動スクリプト」→ 運用負荷で不正解、Patch Manager

移行・転送ツールの使い分け（DataSync／Storage Gateway／Snow／Transfer Family／DMS／MGN）　A: 毎回級

「何を・どれだけ・どの経路で」運ぶかで即決する比較表（毎回出る）

• DataSync＝オンライン一括／定期転送。エージェント（オンプレNFS/SMB/HDFS/オブジェクト・他クラウド）→S3（Glacier系ストレージクラスへ直接可）/EFS/FSx。AWS間（S3⇔EFS等）はエージェント不要
• DataSync：スケジュール実行・帯域制御・整合性検証・メタデータ保持、1タスクで10Gbps回線を使い切れる性能（目安）、DX/VPN・VPCエンドポイント経由可
• Storage Gateway＝継続的なハイブリッドアクセス（オンプレアプリには常時マウントされたローカルストレージに見える）
• Snowball Edge＝オフライン物理輸送。目安「ネット転送に1週間以上」「帯域不足」「数十TB〜PB」
• Transfer Family＝SFTP/FTPS/FTP/AS2（＋ブラウザ用Webアプリ）のマネージドエンドポイント→S3/EFS。取引先の既存SFTP手順を変えない。FTPはVPC内部アクセスのみ（パブリックエンドポイント不可）。認証はサービス管理／AD／カスタム（Lambda）
• DMS＝DB移行（稼働中・CDCで継続同期）、異種はSCT併用。MGN＝サーバー丸ごとリホスト
• 判断順：DB？→DMS／サーバー？→MGN／SaaS？→AppFlow／ファイル・オブジェクト？→回線で足りる：DataSync、足りない：Snowball、アプリが使い続ける：Storage Gateway、SFTP必須：Transfer Family

転送・移行サービス早見

サービス	向くもの	キーワード
DataSync	一回限り・定期の大量ファイル移行	「オンプレNFS/SMBをS3/EFS/FSxへ」「スケジュール」「検証」
Storage Gateway	移行後もオンプレアプリが使い続ける	「継続的」「ローカルキャッシュ」「テープ置換」
Snowball Edge	帯域不足・オフライン・エッジ処理	「1週間以上かかる」「ネットワーク断」
Transfer Family	取引先SFTP等の既存手順を維持	「SFTP」「FTPS」「AS2」
DMS（＋SCT）	データベース	「ダウンタイム最小」「異種エンジン」
MGN	OS込みサーバー	「リフト&シフト」「アプリ改修なし」
AppFlow	SaaS→S3/Redshift	「Salesforce」「ノーコード」

引っかけ

• 「既存のSFTPワークフローを変えずに」→ Transfer Family（DataSyncではない）
• 「定期的に大量データを同期」→ DataSync、「アプリがファイル共有として使い続ける」→ Storage Gateway
• 「EFS⇔EFS・S3⇔EFS の定期同期」→ DataSync（Storage Gatewayではない）
• 「期限が迫り回線が細い」→ Snowball Edge（Direct Connect新設は数週間〜数か月で間に合わない）

Storage Gateway 4タイプ　A: 毎回級

オンプレからは普通のストレージに見えて裏でS3に送る、ハイブリッドの常時接続（スレッドで質問済み）

• 配置＝オンプレのVM（VMware/Hyper-V/KVM）・EC2。ハードウェアアプライアンスは2025年5月に提供終了（既存利用者は2028年5月までサポート）。ローカルキャッシュで低遅延
• S3ファイルゲートウェイ＝NFS/SMBでS3をファイル共有として利用。ファイルは1:1でS3オブジェクトとしてそのまま見える（S3コンソール・Athenaから直接使える）。AD連携、ライフサイクルでGlacierへ
• ボリュームゲートウェイ キャッシュ型＝iSCSI。プライマリはS3、頻繁アクセス分だけローカル。オンプレ容量を節約。ボリューム最大32TiB
• ボリュームゲートウェイ 保管型＝iSCSI。プライマリはオンプレ、非同期でS3へEBSスナップショットとしてバックアップ（DR）。ボリューム最大16TiB
• テープゲートウェイ（VTL）＝物理テープ装置を仮想テープに置換。既存バックアップソフトのまま、S3→Glacier Flexible/Deep Archiveへアーカイブ
• FSxファイルゲートウェイ＝オンプレからFSx for Windowsへ低遅延アクセス（新規顧客への提供は終了、既存は継続利用可）
• ボリューム型のデータはEBSスナップショット形式で、S3オブジェクトとしては直接読めない（S3 APIで読むならファイルゲートウェイ）

キャッシュ型 vs 保管型 が頻出

タイプ	プロトコル	プライマリ	一言
S3ファイル	NFS・SMB	S3	S3オブジェクトとして見える
ボリューム（キャッシュ型）	iSCSI	S3	よく使う分だけ手元、容量節約
ボリューム（保管型）	iSCSI	オンプレ	全データ手元、S3へ非同期バックアップ
テープ	iSCSI-VTL	S3→Glacier	レガシーテープ置換

引っかけ

• 「オンプレのストレージ容量が足りない・拡張したい」→ キャッシュ型、「全データにローカル低遅延アクセスしつつDR」→ 保管型
• 「テープバックアップを廃止したいがバックアップソフトは変えない」→ テープゲートウェイ（S3ファイルゲートウェイではない）
• 「オンプレNFS/SMBをそのままクラウド連携」→ S3ファイルゲートウェイ（DataSyncは転送タスク、Gatewayは常時マウント）

CloudFormation（変更セット・ドリフト・DeletionPolicy・StackSets）　B: 頻出

IaCの本命。スタック運用の細部と、複数アカウント展開のStackSets（スレッドで質問済み）

• テンプレート（JSON/YAML）→スタック。Resources必須、Parameters（NoEcho）、Mappings（リージョン→AMI）、Conditions、Outputs（Export→Fn::ImportValueでクロススタック参照）、Transform（SAM）
• サービス自体は無料（作成したリソースは課金）。作成失敗時は自動ロールバック（無効化可）
• 変更セット＝更新前に「何が置換・削除されるか」をプレビュー。ドリフト検出＝コンソールでの手動変更をテンプレートと比較して検出
• DeletionPolicy：Delete（既定）／Retain／Snapshot（EBS・RDS・Redshift・ElastiCache・Neptune・DocumentDB）。RDS DBInstance/DBClusterだけは既定がSnapshot。UpdateReplacePolicy＝置換時の旧リソースの扱い
• スタックポリシー＝更新から特定リソースを保護、削除保護（Termination Protection）＝スタック削除を防止
• ネストスタック＝テンプレートの部品化。カスタムリソース＝Lambdaで未対応操作。CreationPolicy＋cfn-signal＝EC2初期化完了を待つ、DependsOn＝作成順序
• StackSets＝1テンプレートを複数アカウント×複数リージョンへ一括展開・一括更新。管理アカウントで定義し、展開先ごとに「スタックインスタンス」が作られる
• StackSets権限：セルフマネージド（IAMロールを手動）／サービスマネージド（Organizations連携、OUに新アカウント追加で自動展開）。Control Towerが内部で利用

DeletionPolicy の値

値	動作	使いどころ
Delete	スタック削除時にリソースも削除（既定。RDSのみ既定はSnapshot）	通常
Retain	リソースを残す	消えると困るS3・DynamoDB
Snapshot	削除前にスナップショット取得	RDS・EBS・Redshift
RetainExceptOnCreate	作成失敗のロールバック時のみ削除、以後は残す	ロールバックのゴミ防止

引っかけ

• 「複数アカウント・複数リージョンに同じ構成」→ StackSets（通常スタックは単一アカウント・単一リージョン）
• 「新アカウントがOUに追加されたら自動で標準構成」→ StackSets サービスマネージド＋Organizations
• 「スタック削除時にDBを残す／退避」→ DeletionPolicy Retain／Snapshot
• 「開発者がインフラを意識せずデプロイ」→ Elastic Beanstalk、「テンプレートで全リソース」→ CloudFormation。OpsWorks（Chef/Puppet）は提供終了で出ない

Systems Manager マルチアカウント運用：Explorer／OpsCenter／統合コンソール／DHMC　B: 頻出

複数アカウント・全EC2をSSMで漏れなく横断管理する仕組み（スレッドで質問済み）

• Explorer＝複数アカウント・複数リージョンの運用データ（パッチ状況・Configコンプライアンス・CloudWatchアラーム・OpsItem）を1画面に集約。Organizations連携で組織全体
• OpsCenter＝運用上の問題を「OpsItem」として一元管理・対応（EventBridge／CloudWatchアラームから自動起票）
• 統合コンソール（2024年11月〜）＝組織全体のノードを1画面で把握、SSM未管理のEC2も検出。Quick Setup＝SSM/CloudWatchエージェント等の推奨構成を複数アカウントへ一括
• DHMC（デフォルトホスト管理設定）＝アカウント×リージョン単位で1回有効化すると全EC2（新規起動含む）に自動でSSM管理権限。インスタンスプロファイルの個別アタッチ不要
• DHMC前提＝IMDSv2必須（IMDSv1非対応）、SSM Agent 3.2.582.0以降、反映まで最大30分。ssm:UpdateInstanceInformationを許可する既存インスタンスプロファイルがあればそちらが優先されDHMCは使われない（外すか権限を削る）
• Session Manager同様、DHMCでもインバウンドポート開放は不要

横断管理の目的 → サービス

目的	サービス
運用状態（パッチ率・OpsItem）を横断可視化	SSM Explorer／統合コンソール
メトリクス・ログ・トレースを横断検索	CloudWatch クロスアカウントオブザーバビリティ
設定変更履歴・準拠状況を横断	Config アグリゲータ
リソースをキーワードで横断検索（在庫確認）	Resource Explorer
AWS＋非AWSデータを1ダッシュボードに	Managed Grafana

引っかけ

• 「大量のEC2にIAMロールを個別設定せずSSM管理を漏れなく有効化」→ DHMC
• 「複数アカウントのリソースをまとめて検索」→ Resource Explorer（Configアグリゲータは検索ではなく準拠管理）
• 「運用タスクの状態管理」→ SSM Explorer、「アラーム・ログの串刺し」→ CloudWatch、「Prometheus等も統合」→ Grafana

X-Ray／Managed Grafana／Managed Prometheus　B: 頻出

分散トレーシングと、コンテナ・多データソース向けの可視化層（Grafanaはスレッドで質問済み）

• X-Ray＝リクエストをサービス横断で追跡、サービスマップでボトルネック・エラー箇所を特定。トレース保持30日
• 対応：Lambda（アクティブトレースをON）、API Gateway、EC2/ECS/EKS（X-Rayデーモン/エージェント、UDP 2000）、Elastic Beanstalk、SQS/SNS経由の伝播。アプリにSDK組込みが必要
• サンプリング（既定：毎秒1件＋残り5%）でコスト抑制。アノテーション＝インデックス化され検索可、メタデータ＝検索不可
• IAM＝デーモン/関数にX-Rayへの書込み権限（AWSXRayDaemonWriteAccess相当）
• Managed Grafana＝Grafanaのフルマネージド版。CloudWatch・Prometheus・X-Ray・OpenSearch・Athena・Redshift・Timestream等を1ダッシュボードに統合。複数アカウント・リージョン横断、認証はIAM Identity Center/SAML
• Managed Service for Prometheus＝Prometheus互換のメトリクス保存・PromQL・アラート。EKS/ECS（コンテナ）監視の定番、Grafanaで可視化
• 役割分担：収集＝CloudWatch/Prometheus、追跡＝X-Ray、見る層＝Grafana（Grafana自体はメトリクスを収集しない）

引っかけ

• 「マイクロサービス／Lambda連鎖のどこが遅いか」→ X-Ray（CloudWatchメトリクスでは特定できない）
• 「CloudWatchとオンプレPrometheusを同じダッシュボードで」→ Managed Grafana（CloudWatchダッシュボードはAWSデータ中心）
• 「Kubernetesの既存Prometheus監視をマネージド化」→ Managed Prometheus＋Managed Grafana

移行の7R・MGN・Application Discovery・Migration Hub　B: 頻出

「どう移すか」の戦略語と、移行を実行・追跡するサービス群（MGNはスレッドで質問済み）

• 7R＝Rehost（リフト&シフト：MGN）／Replatform（少し手を入れる：自前DB→RDS）／Repurchase（SaaSへ）／Refactor（サーバーレス・マイクロサービスに作り直し）／Retire／Retain／Relocate（VMware Cloud on AWSへそのまま）
• 「最小限の変更で」→ Rehost、「運用負荷を下げたいが改修は小さく」→ Replatform、「クラウドネイティブに」→ Refactor
• MGN（Application Migration Service）＝旧SMS/CloudEndure後継。移行元にReplication Agentを入れブロックレベルで継続レプリケーション→低コストのステージング領域→テスト起動→カットオーバー（数分）
• MGN対応＝物理/VM/他クラウド、vCenter経由のagentless可。リホスト専用（マネージド化・コンテナ化はしない）。DR用途の同技術はElastic Disaster Recovery（DRS）
• Application Discovery Service＝オンプレの棚卸し。Agentless Collector（VMware vCenter経由：概要）／Discovery Agent（各サーバーにインストール：プロセス・ネットワーク依存関係・性能）。結果はMigration Hubへ
• Migration Hub＝MGN・DMS等の移行進捗を一元追跡（ホームリージョンを設定）、Strategy Recommendationsで7Rを推奨
• Migration Evaluator＝TCO試算・ビジネスケース。VMware Cloud on AWS＝vSphereをそのまま（2024年以降はBroadcom販売だが試験では「Relocate」の代表例として出る）

7R早見

戦略	例	定番サービス
Rehost	OS込みでEC2へ	MGN
Replatform	自前DB→RDS、EC2→Beanstalk	DMS・RDS
Repurchase	自前CRM→SaaS	—
Refactor	モノリス→Lambda/コンテナ	Lambda・ECS
Relocate	vSphereごと移す	VMware Cloud on AWS
Retire／Retain	廃止／据置き	—

引っかけ

• 「アプリサーバーをそのままクラウドへ、ダウンタイム最小」→ MGN（DMSはDB専用、DataSyncはファイル専用でOS/アプリは運べない）
• 「移行前にサーバー間の依存関係を把握」→ Application Discovery Service（依存関係・性能まで取るならAgent型）
• 「複数ツールの移行状況を一元管理」→ Migration Hub（実際の移行は行わない）
• 「Oracle→Aurora PostgreSQL」→ SCT＋DMS、「MySQL→Aurora MySQL」→ DMSのみ

Snow Family　B: 頻出

ネットワークが現実的でないときの物理輸送＋エッジコンピューティング（スレッドで質問済み）

• Snowball Edge Storage Optimized＝210TB（NVMe、最大1.5GB/s）、大量データ移行向け。旧80TB版は2024年11月に受注終了（古い教材の「80TB」は旧世代）。Compute Optimized＝104 vCPU・416GB RAM・28TB NVMe、現場でEC2/Lambda/ML推論（GPU版は受注終了）
• 目安＝ネットワークで1週間以上かかる／帯域不足／ネットワーク断の現場。複数台の並列利用で数PB
• データは自動でKMS暗号化。取込み（インポート）も持出し（エクスポート）も可。到着後S3へ投入、Glacierへは直接不可 → S3のライフサイクルで移行
• 転送時間の計算：100TBを1Gbpsで理論値でも約9日超、実効なら2週間近い → Snowball（帯域×稼働率で計算させる問題）
• Snowmobile（100PB）・Snowcone（8TB）は提供終了。古い教材の選択肢に注意、現行はSnowball Edgeのみ（AWSは移行用途にDataSyncを推奨）
• OpsHubでGUI操作。DataSyncエージェントをSnowball上で動かしオンライン転送に切替も可

引っかけ

• 「SnowballからGlacier Deep Archiveへ直接投入」→ 不可（S3経由でライフサイクル）
• 「オフィスの回線が遅く、期限が迫る」→ Snowball Edge（DXは開通に数週間〜数か月）
• 「ネットワーク断の現場でデータを前処理」→ Snowball Edge Compute Optimized

Trusted Advisor・Health Dashboard　B: 頻出

AWS側から「あなたの環境の改善点」と「あなたに影響する障害・メンテ」を教えてくれる

• Trusted Advisor＝ベストプラクティスチェック。カテゴリ＝コスト最適化／パフォーマンス／セキュリティ／耐障害性／サービスクォータ／運用上の優秀性（旧5→現6）
• 代表チェック：低使用率EC2・アイドルELB・未関連付けEIP（コスト）、S3公開・SGの無制限ポート・ルートMFA（セキュリティ）、EBSスナップショット無し・RDS単一AZ（耐障害性）、クォータ80%超
• サポートプラン：Basic/Developerは一部（サービスクォータ全チェック＋セキュリティ・耐障害性の一部）のみ、自動更新なし。Business以上（現行名はBusiness Support+／Enterprise）で全チェック＋API＋EventBridge連携
• 「推奨するだけ」で自動変更はしない。適正サイズの具体推奨はCompute Optimizer、コスト分析はCost Explorer、S3特化はStorage Lens
• AWS Health Dashboard（旧Personal Health Dashboard）＝自アカウントのリソースに影響するAWS側の障害・計画メンテ（EC2リタイア予定等）を通知。全体の稼働状況ページとは別
• Health API・組織ビュー（Organizations）はBusiness/Enterprise。EventBridge連携でSNS/Slack通知や自動対処

目的 → 正解

目的	正解
未使用EIP・アイドルELBを見つける	Trusted Advisor
インスタンスタイプの適正サイズ推奨	Compute Optimizer
AWS側の障害・メンテ通知	Health Dashboard
クォータ到達前の警告	Trusted Advisor（Service Quotasでも）
SGルールが継続的に準拠しているか	Config ルール

引っかけ

• 「SGが0.0.0.0/0で22番を開けていないか継続監視」→ Config ルール（Trusted Advisorは定期チェック）
• 「Trusted Advisorの全チェックを使いたい」→ Business以上のサポートプランが必要
• 「EC2の計画リタイアを事前に知りたい」→ Health Dashboard（EventBridge→SNSで通知）

Service Catalog・License Manager　C: たまに

「承認済み構成だけ使わせる」ガバナンスと、BYOLライセンスの追跡

• Service Catalog＝承認済みCloudFormationテンプレート（製品）をポートフォリオにまとめ、エンドユーザーにセルフサービス提供。ガバナンスと俊敏性の両立
• 制約：起動制約（プロビジョニングに使うIAMロール→利用者に強い権限を渡さない）、テンプレート制約（パラメータ範囲を制限）、タグオプション
• ポートフォリオはアカウント間・Organizations内で共有可。Terraform製品も対応
• License Manager＝BYOLライセンス（vCPU・コア・ソケット・インスタンス数）を追跡・上限強制（ハードリミットで起動ブロック）
• Dedicated Hostと組合せてソケット/コア単位ライセンスを管理。オンプレはSSM Inventoryで把握、ライセンス設定はRAMで共有

引っかけ

• 「開発者にAWS標準構成のみデプロイさせたい／強いIAM権限を渡さずに」→ Service Catalog（IAMだけでは制御困難）
• 「ソケット/コア単位のライセンスを守りつつ使用数を管理」→ License Manager＋Dedicated Host

Resource Access Manager（RAM）　C: たまに

自分のリソースを複製せずに他アカウント・OU・組織全体へ共有する

• 共有しても所有権は元アカウント（複製しない）。RAM自体は無料
• 共有できる代表：VPCサブネット（VPC共有）、Transit Gateway、Route 53 Resolverルール、License Manager設定、マネージドプレフィックスリスト、キャパシティ予約、Dedicated Host、Aurora DBクラスター
• VPC共有＝1つのVPCのサブネットに複数アカウントがEC2/RDSを作る。所有者がルートテーブル・NACL・IGWを管理、参加者は自分のリソースだけ。ピアリングやCIDR重複の考慮が不要でIP設計が簡素化
• Organizations有効化で招待なしにOU単位で共有（サブネット共有はOrganizations内限定）

引っかけ

• 「アカウント間でサブネットを共有」→ RAM（VPCピアリングではない）
• 「1つのTransit Gatewayに複数アカウントのVPCを接続」→ RAMでTGWを共有
• 「RAMで共有すればIAM権限も付く」は誤り。各アカウントのIAMポリシーで別途許可が必要

Well-Architected Tool・6本柱　C: たまに

設計原則の合言葉と、自己レビュー用の無料ツール

• 6本柱＝運用上の優秀性／セキュリティ／信頼性／パフォーマンス効率／コスト最適化／持続可能性（2021年追加）。試験4分野はセキュリティ・信頼性・パフォーマンス・コストに対応
• Well-Architected Tool＝コンソール上の無料サービス。ワークロードを定義し柱ごとの質問に回答→高リスク（HRI）/中リスク項目と改善プランを出力、マイルストーンで履歴管理
• レンズ＝分野特化の追加観点（Serverless、SaaS、機械学習など）。カスタムレンズも可
• 設計原則の合言葉：単一障害点排除・疎結合・水平スケール・自動復旧・ステートレス・IaC・キャパシティを推測しない

引っかけ

• 「アーキテクチャをベストプラクティスに照らして自己レビュー」→ Well-Architected Tool（Trusted Advisorはリソース設定の自動チェック）
• 「柱は5つ」は古い。現在は持続可能性を含む6つ

高可用性・DR・コスト最適化・設計原則

分野2（弾力性26%）と分野4（コスト20%）の中核＋解法の型。最初の「問題文の読み方」で判断軸を思い出してから、DR→HA→コストの順に眺める。表は「比較の決め手」だけに絞ってある。

問題文の読み方（キーワード→正解の型）　A: 毎回級

SAA-C03はほぼ全問シナリオ。末尾の最上級表現と制約語で正解が決まる

• 65問（採点50＋非採点15）／130分＝1問2分、720/1000で合格、分野別足切りなし。未回答は不正解・誤答ペナルティなし→必ず全問マーク
• 配点：セキュア30／弾力性26／高性能24／コスト20。C01時代（コスト10%）から倍増、5問に1問がコスト
• 「MOST cost-effective」→要件を満たす中で最安（Spot・S3階層・サーバーレス・Gateway型エンドポイント）。要件を落とした安い選択肢は不正解
• 「LEAST operational overhead／運用負荷最小」→マネージド・サーバーレス（Aurora Serverless・Fargate・Lambda・DynamoDB・AWS Backup）。EC2自前構築・スクリプト運用を消す
• 「highly available」→複数AZ。「リージョン障害に耐える／DR」→マルチリージョン。「fault tolerant／ダウンタイムゼロ」→アクティブ/アクティブ
• 「without changing the application／改修なし」→インフラ側で解決（RDS Proxy・ENI付替え・Amazon MQ・Storage Gateway）
• 読む順：最後の1文（制約・最上級）→選択肢の差分→本文で裏取り。消去順：要件違反→存在しない機能（RDS Multi-AZ DBインスタンス配置のスタンバイからの読取等）→運用負荷・コストが高い自前構築
• 2択で迷ったら「よりマネージド・よりAWSネイティブ」。ただし「既存の〇〇をそのまま」なら互換サービス（Amazon MQ・FSx for Windows・Transfer Family）

引っかけ

• 「中断できない／期限内に必ず完了」→Spotは不正解。公式サンプルQ6：月末だけの超過はオンデマンド追加（追加RIは不要期間も払うので不正解）
• 「NOT／EXCEPT」「2つ選べ」の見落とし。複数選択は「1つの解を構成する2手順」（NAT GW作成＋ルート追加）が多い
• 日本語訳が不自然なら英語原文に切替。見慣れない難問は非採点かもしれないので時間をかけすぎない

EC2購入オプション（オンデマンド／RI／Savings Plans／Spot／専有／キャパシティ予約）　A: 毎回級

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

• オンデマンド：秒課金・コミットなし。短期・予測不能・中断不可の一時的な増加向け
• Savings Plans：「1時間あたり$X使う」の金額コミット（1年/3年）。Compute SP＝ファミリー・サイズ・リージョン・OS問わず、Fargate・Lambdaにも適用（最大66%）。EC2 Instance SP＝リージョン内の特定ファミリー固定（最大72%）
• RI：「このインスタンスを使う」の構成コミット。Standard（最大72%、変更不可、マーケットプレイスで売却可）／Convertible（最大66%、ファミリー変更可、売却不可）。前払い額が多いほど安い
• Spot：最大90%引き、2分前の中断通知。ステートレス・バッチ・CI/CD・ビッグデータ向け。Spot Fleet／ASG混合インスタンスポリシーで複数プールに分散し中断影響を減らす
• Dedicated Host：物理サーバー専有、ソケット/コア単位のBYOL（Windows Server・SQL Server・Oracle）。Dedicated Instance＝専有ハードだがホストの可視性なし
• キャパシティ予約：割引なし、特定AZの容量だけ確保（RI/SPと組合せて割引）。「長期契約はしたくないが容量は確保したい」
• 3層構成が定石：安定ベース→RI/SP、変動分→オンデマンド＋ASG、中断可→Spot。SPとRIは併用可でRIが先に適用。Organizations一括請求で組織内共有

購入オプション早見

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

引っかけ

• 「Fargate/Lambdaにも割引」「将来ファミリーが変わるかも」→Compute Savings Plans（EC2 Instance SP・Standard RIは不可）
• 「ライセンスがソケット/コア単位」→Dedicated Host（Dedicated Instanceではない）
• 「特定AZで容量を確実に確保」→キャパシティ予約 or ゾーンRI（Savings Plansは容量を確保しない）
• Scheduled RIは現在提供終了（購入不可）。古い教材の選択肢にだけ出る

S3ストレージクラスのコスト判断　A: 毎回級

「アクセス頻度×取り出し許容時間×再作成可否」で階層を選ぶ。耐久性は全クラス11ナイン

• Standard：最小保存なし・取り出し料なし・可用性99.99%・3AZ以上。Express One Zone：単一AZの1桁msレイテンシ（高頻度アクセスの分析/ML）
• Intelligent-Tiering：アクセスパターン不明/変動時のほぼ一択。取り出し料なし・最小保存なし、オブジェクト単位の監視料（128KB未満は対象外）。30日未アクセス→IA階層、90日→Archive Instant階層へ自動移動
• Standard-IA：最小30日・最小課金128KB・取り出し料あり・可用性99.9%・複数AZ。One Zone-IA：同条件で単一AZ、約20%安、可用性99.5%→再作成可能データ（サムネ・ログの二次コピー）向け
• Glacier Instant：ミリ秒取り出し、最小90日。Flexible：最小90日、分〜時間。Deep Archive：最小180日、12〜48時間、最安（7年の法令保管）
• ライフサイクル：Standard→IA系への移行は作成後30日以降のみ、Glacier系へは即時可。非現行バージョンの削除・未完了マルチパートの中止でもコスト削減
• Glacier系のオブジェクトはそのままGET不可→復元（Restore）で一時コピーを作る。Deep ArchiveからStandardへ直接は戻せない
• S3 Storage Lens：組織横断でS3利用状況を可視化（基本メトリクス無料・14日保持、高度版15か月）。可視化のみで自動移行はしない→自動最適化はIntelligent-Tiering

S3ストレージクラス比較

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

引っかけ

• 最小保存期間より前に削除・移行してもその期間分は課金。「毎日削除するデータをStandard-IAに」→かえって高い
• 「重要データ・復元不能」にOne Zone-IAは不正解（AZ消失でデータ消失）。「再作成可能」ならOK
• 「作成後10日でIAへ」は設定不可（30日ルール）。頻繁に取り出すデータをIAにすると取り出し料で逆に高い
• 「アクセス頻度が不明」→Intelligent-Tiering（Standard-IAではない）

DR戦略4種とRPO/RTO　A: 毎回級

RPO＝許容データ損失、RTO＝許容停止時間。小さいほど高コスト。要件の数値で4戦略から選ぶ

• バックアップ&リストア：最安。RPO/RTO＝時間単位。S3・スナップショット・AMI・AWS Backupのクロスリージョンコピーから CloudFormation で再構築
• パイロットライト：DBなどコア部分だけ別リージョンで常時レプリケーション（Aurora Global／RDSクロスリージョンレプリカ／S3 CRR）、アプリ層は停止/AMI。RPO分、RTO数十分
• ウォームスタンバイ：縮小版のフルスタックが常時稼働、DR時にスケールアップ。RPO秒〜分、RTO分。Route 53フェイルオーバーで切替
• マルチサイト アクティブ/アクティブ：複数リージョンで同時に本番稼働（Route 53レイテンシー/加重＋DynamoDB Global Tables＋Aurora Global）。RPO/RTOほぼゼロ、最高コスト
• 判別：「RTO数時間」→B&R、「RTO数十分・コスト抑制」→パイロットライト、「RTO数分」→ウォームスタンバイ、「ダウンタイムほぼゼロ」→マルチサイト
• AWS Elastic Disaster Recovery（DRS、旧CloudEndure）：オンプレ/他クラウド/EC2をブロックレベルで継続レプリケーション、低コストのステージングから数分で復旧（RPO秒・RTO分）。MGN＝移行、DRS＝DR
• DR準備：スタンバイリージョンのサービスクォータを事前引上げ、AMI/スナップショット/KMSキーはリージョン固有→事前コピー、Route 53のTTLを短く設定

DR戦略比較

戦略	RPO／RTO目安	常時稼働するもの	コスト
バックアップ&リストア	時間	バックアップのみ	最安
パイロットライト	分／数十分	DB等コアのみ	低
ウォームスタンバイ	秒〜分／分	縮小版フルスタック	中
マルチサイト A/A	ほぼゼロ	本番規模×複数リージョン	最高

引っかけ

• 「RPO 5分・RTO 1時間・コスト最小」→パイロットライト（ウォームスタンバイは過剰、B&RはRPO不足）
• パイロットライトとウォームスタンバイの違い＝ウォームはアプリ層も稼働していて即トラフィックを受けられる
• 「アクティブ/アクティブ」を「コスト効率」の文脈で選ばない。Multi-AZはリージョンDRではない
• 「RPO 1秒未満のマルチリージョンDB」→Aurora Global Database（RDSクロスリージョンリードレプリカでは遅延が大きい）

Multi-AZ vs マルチリージョン（HAの定石）　A: 毎回級

AZ障害→Multi-AZ、リージョン障害→マルチリージョン。まず単一障害点を全部消す

• AZ＝独立した電源・ネットワークを持つ1つ以上のDC、リージョン＝複数AZ。「highly available」＝最低2AZ
• Web層の定石：ALB＋ASGを複数AZのサブネットに配置しステートレス化。公式サンプルQ8「単一AZの2層構成をHAに」→ALB＋ASG複数AZ＋RDS Multi-AZをプライベートサブネットへ
• DB層：RDS Multi-AZ DBインスタンス配置＝別AZに同期スタンバイ、障害時DNS自動切替（通常60〜120秒）、スタンバイは読み取り不可＝性能向上なし。Multi-AZ DBクラスター配置＝読み取り可能スタンバイ2台・フェイルオーバー通常35秒未満（MySQL/PostgreSQL）。Aurora＝3AZ×2＝6コピー、レプリカが昇格先（30秒以内）。DynamoDB/S3は標準でマルチAZ
• 単一障害点の排除：NAT GWをAZごと、EFSマウントターゲットをAZごと、単一EC2はASG（最小1でも自動置換）or EC2自動復旧、ELBヘルスチェックをASGに設定して異常インスタンスを入替え
• ASGは複数AZに分散できるがリージョンはまたげない。ASG単体ではAZ間の負荷分散をしない（ELBが必要）
• マルチリージョン：Route 53フェイルオーバー/レイテンシー、Aurora Global、DynamoDB Global Tables、S3 CRR、Global Accelerator。AMI・スナップショットは別リージョンへコピー
• 「最小コストで可用性向上」→まずMulti-AZ。マルチリージョンは「リージョン障害」「グローバル低遅延」の要件があるときだけ

引っかけ

• 「読み取り性能を上げたい」にMulti-AZは不正解（リードレプリカ）。逆に「可用性」にリードレプリカも不正解
• 選択肢に「Multi-AZ」とあっても単一NAT GW・単一インスタンスが残っていれば不十分
• 「リージョン障害に耐える」にMulti-AZ・同一リージョン内のリードレプリカは不正解
• RDS Multi-AZは同一リージョン内。クロスリージョンはリードレプリカ or Aurora Global

データ層のクロスリージョンDR（Aurora Global／DynamoDB Global Tables／S3 CRR）　A: 毎回級

リージョンをまたぐデータ複製は手段が決まっている。RPO要件と「書き込みが必要か」で選ぶ

• Aurora Global Database：ストレージ層の物理レプリケーション、遅延は通常1秒未満、RPO約1秒・RTO 1分未満。セカンダリは読み取り専用（最大10リージョン、各リージョン最大16レプリカ）、マネージドスイッチオーバー（計画・データ損失なし）／フェイルオーバー（障害時）、Write Forwarding。リージョンDRの定番
• DynamoDB Global Tables：マルチリージョン・マルチアクティブ（全リージョンで読み書き）、DynamoDB Streams必須、競合はLast Writer Wins、リージョン間は結果整合（2025年〜マルチリージョン強い整合性MRSCオプションも）。PITRは最大35日
• S3 CRR：非同期、送信元・送信先ともバージョニング必須、有効化後の新規オブジェクトのみ（既存はバッチレプリケーション）、レプリケーションは連鎖しない、削除マーカー複製は任意。S3 RTCで99.99%を15分以内に複製
• RDSクロスリージョンリードレプリカ：非同期、DR時に昇格してスタンドアロン化。Redshift：自動スナップショットのクロスリージョンコピー
• EBSスナップショット／AMIのリージョン間コピー、AWS Backupのクロスリージョン・クロスアカウントコピー。暗号化済みは転送先リージョンのKMSキーで再暗号化
• ElastiCache Global Datastore（Valkey／Redis OSS）：クロスリージョンレプリケーション。S3 Multi-Region Access Point：複数リージョンのバケットを1つのグローバルエンドポイントに

クロスリージョン複製の手段

手段	複製方式	覚える値
Aurora Global Database	ストレージ層・物理	遅延<1秒、RPO≈1秒、RTO<1分、セカンダリ最大10リージョン
DynamoDB Global Tables	マルチアクティブ	Streams必須、Last Writer Wins
S3 CRR	非同期・新規のみ	バージョニング必須、RTC 15分
RDS クロスリージョンレプリカ	非同期	昇格でDR、遅延は大きめ
EBS/AMI コピー・AWS Backupコピー	スナップショット	リージョン固有→事前コピー

引っかけ

• 「RPO 1秒未満」「リージョン障害時1分以内に復旧」→Aurora Global（RDSクロスリージョンレプリカでは遅い）
• 「複数リージョンで書き込み」→DynamoDB Global Tables（Aurora Globalのセカンダリは読み取り専用）
• CRRは既存オブジェクトを自動でコピーしない。CRRは非同期＝レプリカ先は結果整合（S3本体は強い整合性）
• KMSキー・AMI・スナップショットはリージョン固有。DR先で復号するには事前コピー or マルチリージョンキー

データ転送コスト（AZ間・リージョン間・NAT・VPCエンドポイント）　A: 毎回級

インバウンド無料・同一AZプライベートIP無料。AZ/リージョンをまたぐと課金、NATはGB課金

• 無料：インターネット→AWSの受信、同一AZ内のプライベートIP通信、S3→CloudFront、Gateway型VPCエンドポイント（S3/DynamoDB）
• 課金：AZ間（双方向それぞれGB課金）、リージョン間、インターネットへの送信、パブリックIP/EIP経由は同一AZでも課金
• NAT Gateway：時間課金＋処理データGB課金。S3/DynamoDBへの通信はGateway型エンドポイントに逃がす（無料）＝「NAT料金が高い」の定番解答
• NAT配置：AZごと（HA・AZ間転送料なし）vs 1つ共有（安いがAZ間転送料＋単一障害点）。「コスト最優先・非本番」なら共有、「HA」ならAZごと
• CloudFront：S3→CloudFront無料、CloudFront→インターネットの単価はS3/EC2直接より安い、キャッシュでオリジン負荷減、価格クラスで配信地域を絞りさらに削減
• ELB：ALBのクロスゾーン負荷分散は既定で有効（ターゲットグループ単位で無効化可）・AZ間転送料なし、NLBは既定無効で有効化するとAZ間転送料。Direct Connectは大量の継続的送信でインターネットよりGB単価が安い
• VPCピアリング自体は無料だがAZ間/リージョン間の転送料は発生。S3 CRR等のリージョン間複製にも転送料

データ転送料金の原則

経路	料金
インターネット→AWS（受信）	無料
同一AZ・プライベートIP	無料
同一AZ・パブリックIP/EIP経由	課金
AZ間	双方向で課金
リージョン間	課金
AWS→インターネット	課金（CloudFront経由が安い）
S3→CloudFront	無料
NAT Gateway	時間＋GB課金
Gateway型エンドポイント（S3/DynamoDB）	無料

引っかけ

• 「プライベートサブネットからS3へ大量転送のコスト削減」→Gateway型エンドポイント（NAT GW増設・Interface型ではない）
• 「EC2同士の大量通信を安く」→同一AZ・プライベートIP（可用性とのトレードオフに注意）
• 「単一NAT GW共有」は安いが「HA」要件があれば不正解

疎結合：SQSバッファリングとファンアウト　A: 毎回級

書き込みバーストはキューで受け、ワーカーがDBの処理できる速度で書く

• 公式サンプルQ7：数十万件の投票書込みでRDSが追いつかない・ダウンタイム不可→SQS＋ワーカー（DBを大きくする・Lambda化・Multi-AZは解にならない）
• 標準キュー：ほぼ無制限スループット、少なくとも1回配信（重複あり）、ベストエフォート順序。FIFO：順序保証＋厳密に1回、名前は.fifo、MessageGroupId単位で順序、既定300msg/秒（バッチで3,000。高スループットモードなら数万/秒以上）
• 上限：メッセージ1 MiB（2025年8月〜、旧256KB。SNSも1 MiB。超えるデータはS3＋Extended Client Library）、保持既定4日・最大14日、可視性タイムアウト既定30秒・最大12時間、ロングポーリング最大20秒、遅延キュー最大15分
• DLQ：maxReceiveCount回失敗したメッセージを隔離し分析・再処理。ASGはApproximateNumberOfMessagesVisible（インスタンスあたりバックログ）でワーカーを増減。Lambdaのイベントソースマッピングでサーバーレス処理
• ファンアウト：SNSトピック→複数SQSキュー→各コンシューマーが独立・並列に処理（画像を同時にサムネ化・分析・保存）。SNSは保持しないので保持したいならSQSをサブスクライブ。EventBridgeは内容でルーティング＋SaaS連携
• Kinesis拡張ファンアウト：複数コンシューマーがそれぞれシャードあたり専用2MB/秒で低遅延読み取り。「1イベントを複数システムへ」→SNS＋SQS、「ストリームの複数コンシューマーの読み取り性能」→拡張ファンアウト
• Step Functions：複数Lambdaの順次実行・再試行・待機（LambdaからLambdaを直接連鎖させない）。既存JMS/AMQPアプリの改修なし移行→Amazon MQ

引っかけ

• 「同じメッセージが複数回処理される」→可視性タイムアウトを処理時間より長く＋冪等化（標準キューでは完全排除不可）
• 「順序・重複なし」→FIFO。「最大スループット」→標準（FIFOは既定300/秒、高スループットモードで拡張可）
• 「メッセージを保持して後で処理」→SQS（SNSは保持しない）。「1対多」→SNS。両方→SNS→SQS
• 書き込み集中にElastiCacheは効かない（読み取り負荷軽減用）

Glacier 3階層の取り出し時間とシナリオ判断　B: 頻出

取り出しの「許容時間」と「頻度」の2軸。ストレージ単価差は小さく、取り出し料と要件充足で決まる

• Instant Retrieval：ミリ秒、最小90日・最小128KB。四半期に1回程度のアクセスが想定ユースケース
• Flexible Retrieval：迅速1〜5分（有料・保証にはプロビジョンドキャパシティ）／標準3〜5時間／バルク5〜12時間（最安）。最小90日
• Deep Archive：標準12時間／バルク48時間。迅速なし。最小180日。「12時間以内の復元でよい・年1回以下」
• スレッドのシナリオ：「四半期に1回アクセス＋2時間以内に取得」→Instant Retrieval。Flexibleの標準3〜5時間は要件外、迅速取り出しはリクエスト課金が積み上がり、IRとFlexibleのストレージ単価差は約10%（目安）しかない
• 目安：「即時／四半期1回」→IR、「数時間待てる／年1〜2回」→Flexible、「12時間以上OK／年1回以下」→Deep Archive
• Glacier Vault Lock＝旧Glacierボールトのポリシー固定（WORM）。S3ならObject Lock

Glacier階層比較

階層	取り出し時間	最小保存	想定頻度
Glacier Instant Retrieval	ミリ秒	90日	四半期に1回
Glacier Flexible Retrieval	迅速1〜5分／標準3〜5h／バルク5〜12h	90日	年1〜2回
Glacier Deep Archive	標準12h／バルク48h	180日	年1回以下・7年保管

引っかけ

• 「数分で復元」要件にDeep Archiveは不可（最短12時間）。「10時間以内」→Flexible標準はOK、Deep Archive標準はNG
• 「即時アクセスが必要なアーカイブ」→Glacier Instant（Flexibleは分〜時間）
• Glacier系へ移行後は復元リクエストなしにGETできない

Route 53 フェイルオーバーとヘルスチェック　B: 頻出

DNSレベルの自動切替。フェイルオーバーにはヘルスチェック必須、Zone ApexにはAlias

• フェイルオーバールーティング：アクティブ/パッシブ。プライマリにヘルスチェック必須、異常時にセカンダリへ。セカンダリにS3静的サイト（Sorryページ）が定番
• アクティブ/アクティブはフェイルオーバーポリシーではなく、レイテンシー/加重＋ヘルスチェック（異常レコードを回答から除外）で実現
• Aliasレコード：ELB・CloudFront・S3静的サイト・API Gateway・Global Acceleratorを指す。Zone Apex（example.com）に使え、クエリ無料。CNAMEはApex不可
• ヘルスチェック：エンドポイント（HTTP/HTTPS/TCP、既定30秒、高速10秒）／計算済み／CloudWatchアラーム連動。チェッカーはインターネット側→プライベートIPのリソースはCloudWatchアラーム型で
• TTLを短く（例60秒）してフェイルオーバーを速く。DR用に事前設定しておく
• Amazon Application Recovery Controller（ARC、旧Route 53 ARC）：リージョン切替のルーティング制御・レディネスチェック。DNSキャッシュの切替遅延を避けたい→Global Accelerator（静的IP、秒単位のリージョンフェイルオーバー）
• ELB配下のEC2はELBヘルスチェック＋ASGのヘルスチェックタイプELBで異常インスタンスを入替え

引っかけ

• 「Zone Apexにロードバランサー」→Alias（CNAMEは不正解）
• 「プライベートサブネットのリソースを監視してフェイルオーバー」→CloudWatchアラーム連動ヘルスチェック（エンドポイント型は届かない）
• 「DR自動切替」→フェイルオーバールーティング＋ヘルスチェック。ヘルスチェックなしのシンプルルーティングは切り替わらない

AWS Backup と Vault Lock　B: 頻出

複数サービスのバックアップをポリシーで一元管理。Vault Lock＝WORM（ガバナンス／コンプライアンス）

• 対象：EC2/EBS/EFS/RDS/Aurora/DynamoDB/FSx/Storage Gateway/S3/Redshift/DocumentDB/Neptune等。バックアッププラン（頻度・保持・コールド階層移行）＋ボールト。「複数サービスのバックアップを1か所で」→AWS Backup
• クロスリージョン／クロスアカウントコピー、Organizationsのバックアップポリシーで全アカウント一括、Backup Audit Managerで監査証跡
• 個別機能の上限：RDS自動バックアップ最大35日（PITR）、DynamoDB PITR 35日→それ以上はAWS Backup or 手動スナップショット。DLM＝EBSスナップショット/AMI専用
• Vault Lock ガバナンスモード：IAM権限があれば解除可（誤操作防止・社内統制）。ChangeableForDaysを指定しない
• Vault Lock コンプライアンスモード：ChangeableForDays（最短3日＝72時間）の猶予後はrootもAWSも解除不可、保持期間満了まで削除不能。「法令で7年」「ランサムウェア対策」
• MinRetentionDays／MaxRetentionDays（最大36,500日）に合わないジョブは失敗。ロックは既存リカバリポイントに遡及しない
• S3 Object Lockも同じ2モード（ガバナンスはs3:BypassGovernanceRetentionで解除可、コンプライアンスは誰も不可）＋リーガルホールド。バージョニング必須

Vault Lock / Object Lock のモード比較

項目	ガバナンス	コンプライアンス
解除	IAM権限があれば可	猶予後は誰も不可（root/AWS含む）
ChangeableForDays	指定しない	必須・最短3日
目的	誤操作防止・社内統制	法令対応・ランサムウェア対策
S3 Object Lockの対応	BypassGovernanceRetentionで解除可	保持期間中は削除・短縮不可

引っかけ

• 「規制で誰にも消させない」→コンプライアンスモード。「管理者が必要なら解除できる」→ガバナンスモード
• コンプライアンスモードは即座に不変ではない（猶予最短3日）。消したくても消せない＝ストレージ費が続く
• 「EFSのバックアップをcronで手動コピー」は誤答（AWS Backup）。「バックアップの削除を防ぐ」→Vault Lock
• MGN＝移行、DRS＝DR、AWS Backup＝バックアップ。混同しない

ステートレス設計とセッション外部化　B: 頻出

サーバーに状態を持たせない→ASGで自由に増減・入替えできる

• セッション→ElastiCache（Valkey／Redis OSS）（レプリケーション・Multi-AZ自動フェイルオーバー・永続化）またはDynamoDB（TTLで自動削除）。ファイル→S3/EFS。ローカルディスクに置かない
• スレッド：「複数EC2でセッション共有＋耐障害性」→Valkey/Redis OSS（Memcachedは永続化・レプリケーションなし＝単純キャッシュ）
• ALBスティッキーセッション（Cookie）は次善策。スケールイン・障害時にセッションが失われ負荷も偏る→外部化が「よりよい」
• イミュータブルインフラ：ゴールデンAMI（EC2 Image Builder）＋起動テンプレート＋ASGで入替え。設定はユーザーデータでなくAMIに焼く（起動高速化）
• 水平スケール＋疎結合（SQS）＋冪等なワーカー。ELBヘルスチェックをASGに設定して異常インスタンスを自動置換
• 停止するとインスタンスストアは消える→一時データ専用。永続データはEBS/EFS/S3

引っかけ

• 「セッションをEC2ローカルに保存」「スティッキーセッションで解決」は要件が可用性・スケールなら不正解
• 「セッションストア＋フェイルオーバー」にMemcachedは不正解（Valkey/Redis OSS）
• 「メモリ上の状態を保持したまま停止してコスト削減」→EC2ハイバネーション（暗号化ルートEBS必須）。スナップショットではない（公式サンプルQ2）

Elastic IP と ENI の使い方　B: 頻出

パブリックIPの引き継ぎ＝EIP、プライベートIPの引き継ぎ＝セカンダリENI（同一AZ内）

• 停止/開始：パブリックIPは変わる（EIPなら維持）、プライベートIPは維持、インスタンスストアは消える。再起動ではすべて維持
• EIP：リージョンあたり既定5個。2024年2月〜パブリックIPv4は使用中でも$0.005/時課金（未アタッチのEIPはさらに無駄）。フローティングIPとして障害時に待機系へ付替え（パブリック側のフェイルオーバー）
• ENI：プライマリENIはデタッチ不可。セカンダリENIは同一AZ内の別インスタンスに付替え可→固定プライベートIPで接続される監視系の待機切替（公式サンプルQ3）
• ENIはAZ固有（別AZには移せない）。ホット（実行中）/ウォーム（停止中）/コールド（起動時）アタッチ
• EC2自動復旧（CloudWatchアラームアクション）：ハードウェア障害時に同じインスタンスID・プライベート/パブリック/EIP・EBSで別ホストに復旧
• 静的IPが必要なLB→NLB（AZごとにEIP）or Global Accelerator。ALBは固定IPなし

引っかけ

• 「プライベートIPを引き継いで待機系へ」→セカンダリENI付替え（EIPはパブリックIP、ALBでも不可）
• 「プライマリENIを付け替える」選択肢は存在しない機能→不正解
• 「起動を速くしたい」→ユーザーデータでのインストールではなくAMIに焼き込む

コンピュート・ストレージのコスト定石（gp3／Graviton／Fargate Spot／適正サイズ）　B: 頻出

「安いものに置き換える・使わない時は止める・サイズを合わせる」の3手

• gp2→gp3：約20%安、ベースライン3,000 IOPS/125MB/sを容量と無関係に確保、IOPS/スループットを独立追加。最頻出のストレージコスト削減策
• Graviton（ARM）：最大40%優れた価格性能比、インスタンス名に「g」（m7g/c7g/r7g/t4g）。RDS・ElastiCache・OpenSearch・Lambda・Fargateでも可。ARM対応可能なら移行が定番解答
• Fargate Spot：Fargate料金から最大70%引き、中断可能なコンテナタスク向け。Compute Savings PlansはFargate/Lambdaにも適用
• 適正サイズ：Compute Optimizer／Cost Explorerの推奨で縮小、T系バースト可能で低負荷を安く、スケジュール停止（Instance Scheduler、EventBridge＋Lambda）、ハイバネーション
• 本番/非本番で可用性要件を分ける：非本番はMulti-AZ不要・単一AZ・Spot可。RDS停止は最大7日、断続的DB→Aurora Serverless v2、予測不能→DynamoDBオンデマンド、安定→プロビジョンド＋Auto Scaling
• 断続的・短時間→Lambda、常時稼働・予測可能→EC2＋RI/SP、中断可バッチ→Spot/AWS Batch。Lambdaは常時高負荷だとEC2より高い
• ストレージ：未使用EBS/スナップショットの削除（DLM）、EBS Snapshots Archive（90日超保持で最大75%安）、EFS IA/Archive、S3 Intelligent-Tiering、CloudWatch Logs保持期間の設定（既定は無期限）

引っかけ

• 「最もコスト効率」でも「中断不可・常時稼働」ならSpotではない。「運用負荷最小」なら自前EC2よりマネージド
• 「Windows/商用ソフトのライセンス依存」はGravitonに移行できないケースあり（ARM非対応）
• 「Lambdaで15分超・常時高負荷」はコスト・制限で不正解→Fargate/EC2

コスト管理ツール（Cost Explorer／Budgets／CUR／Anomaly Detection／Compute Optimizer／配分タグ）　B: 頻出

「見る・警告する・詳細に分析する・異常を検知する・サイズを推奨する」で役割が分かれる

• Cost Explorer：可視化・傾向分析・最大12か月先の予測、サービス/タグ/アカウント別、RI/SPの推奨と使用率・カバレッジレポート
• Budgets：コスト・使用量・RI/SP使用率の予算と閾値アラート（SNS/Email）、予算アクション（IAMポリシー/SCP適用、EC2/RDS停止）。「支出が閾値を超えたら通知」
• Cost and Usage Report（CUR）：最も詳細な請求データをS3へ→Athena/QuickSightで分析。「時間単位・リソースID単位」
• Cost Anomaly Detection：MLで異常支出を検出・通知。Pricing Calculator：見積り。Trusted Advisor：未使用EIP・低使用率EC2・アイドルELBの検出（全項目はBusiness以上）
• Compute Optimizer：EC2/ASG/EBS/Lambda/ECS on Fargate/RDSをCloudWatchメトリクス（既定14日）でML分析し過剰/過小を推奨。Organizations横断可。推奨のみで自動変更しない
• コスト配分タグ：ユーザー定義タグは「有効化」して初めて請求データに反映、AWS生成タグ（aws:createdBy）。タグポリシー（Organizations）で統一。「部門別按分」→配分タグ＋Cost Explorer
• Organizations一括請求：1つの請求、ボリューム割引を合算、RI/SPを組織内で共有（無効化も可）。S3 Storage Lens：S3利用状況の組織横断可視化。CloudWatch請求アラームはus-east-1

コスト管理ツールの役割

ツール	役割	キーワード
Cost Explorer	可視化・予測・RI/SP推奨	傾向を見る
Budgets	予算とアラート・アクション	閾値超過で通知
CUR	最詳細データをS3へ	時間・リソース単位で分析
Cost Anomaly Detection	ML異常検知	異常な支出増
Compute Optimizer	適正サイズ推奨	過剰/過小プロビジョニング
Trusted Advisor	ベストプラクティスチェック	未使用リソース
コスト配分タグ	請求データの分類	部門別按分
S3 Storage Lens	S3利用の可視化	組織横断でS3コスト

引っかけ

• 「予算超過の通知」→Budgets（Cost Explorerは可視化・分析）。「最も粒度の細かいデータ」→CUR
• タグは付けただけでは請求に反映されない（コスト配分タグとして有効化が必要）。Organizationsだけでは部門別按分できない
• 「インスタンスタイプが適切か診断」→Compute Optimizer（自動変更はしない）。「異常な支出増を検知」→Cost Anomaly Detection

Well-Architected 6本柱と設計原則　C: たまに

試験の4分野はセキュリティ／信頼性／パフォーマンス効率／コスト最適化の4柱に対応

• 6本柱：運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性（2021年追加）
• 信頼性の原則：障害から自動復旧、復旧手順をテスト、水平スケールで可用性向上、キャパシティを推測しない、変更を自動化
• コスト最適化の原則：従量課金（消費モデル）、全体の効率を測定、差別化につながらない重労働をやめる（マネージド活用）、支出を分析・帰属（タグ）
• 設計の定石：単一障害点の排除、疎結合（SQS/SNS/EventBridge）、ステートレス、複数AZ、IaC（CloudFormation）、イミュータブルインフラ、多層防御・最小権限
• Well-Architected Toolでワークロードをレビュー、Trusted Advisorが柱ごとのチェックを自動化
• 弾力性（Resilient）＝可用性・耐障害性・疎結合。パフォーマンス（分野3）と混同しない

引っかけ

• 「信頼性」の設問で「性能向上策」を選ばない（分野2と分野3の混同）
• 「セッションをEC2ローカルに置く」「転送料削減のため単一AZに集約」は原則違反で不正解になりやすい

おわりに

前の回: 第4回 ／ 次の回: 第6回

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