はじめに
AWS Certified Solutions Architect – Associate（SAA-C03）で問われるサービスの使い分け・数値・引っかけを、試験直前に一気に見直せるように圧縮したチートシートです。長くなったので全 6 回に分けています。この第 1 回は**当日戦略と早見表（200 行）**で、直前 10 分はここだけ見れば足ります。
シリーズ目次
- 第1回 早見表200行と当日戦略（この記事）
- 第2回 コンピューティング・ストレージ
- 第3回 データベース・ネットワーキング
- 第4回 セキュリティ・アプリケーション統合・分析
- 第5回 管理・監視・移行／高可用性・DR・コスト最適化
- 第6回 補完：その他の頻出トピック
（第 2 回以降は分野別に「要点 → 比較表 → 引っかけ」。優先度 A（毎回級）→ B（頻出）→ C（たまに）の順に読む）
| 項目 | 目安 |
|---|---|
| 試験コード | SAA-C03 |
| 問題数／時間 | 65 問／130 分（採点対象 50 問＋未採点 15 問） |
| 合格スコア | 720／1000 |
| 配点 | セキュア設計 30%・弾力性 26%・高性能 24%・コスト最適化 20% |
数値・仕様は AWS 公式ドキュメントで確認したものを載せていますが、確認しきれなかった記述は末尾にまとめています。問題数・時間・配点・サービス仕様は改定されることがあるので、受験前に公式の試験ガイドで最終確認してください。
試験概要と当日戦略
会場で慌てないための確認と、公式サンプル問題が示す「正解の型」。
試験概要と当日戦略（SAA-C03） A: 毎回級
65問130分・720点合格・配点30/26/24/20%。未回答ペナルティなし→全問マーク。NOT／EXCEPT と「最も〜」の軸を落とさない
- 65問／130分（1問2分）。採点50問＋非採点15問（見分け不可→全問本気）。100〜1000点のスケールドスコア、720点で合格（分野別の足切りなし＝補償型採点）
- 配点：①セキュア設計30% ②弾力性26% ③高性能24% ④コスト最適化20%。迷ったら「より安全・より安い・より運用が軽い」を選ぶ
- 形式：択一（4択1つ）／複数選択（5択以上から2つ以上）。指示された数を厳守、部分点なし
- 未回答＝不正解、減点なし→必ず全問マーク。フラグで後回し可。1問90秒超えたら即フラグ
- 日本語受験でも画面上で英語原文に切替可。訳が不自然なら原文で MOST／LEAST／NOT／EXCEPT／Choose TWO を確認
- 解法手順：①要件語を拾う（最小運用負荷／最もコスト効率／最も安全／ダウンタイムなし）→②制約語で2択に消す→③マネージド・サーバーレス寄りを選ぶ
- 時間配分目安：1周目90分→残り40分でフラグ問題の見直し。結果は当日画面に出ず、5営業日以内にAWS認定アカウントへ掲載（メール通知。通常数時間〜翌日が多い）
- 当日：登録名と完全一致する身分証（顔写真・署名付き。予約確認メールの要件を再確認）、30分前到着。ESL延長30分は事前申請制。直前に新知識は詰めない
要件語→選ぶ方向（迷ったときの初期値）
| 問題文の要件語 | 選ぶ方向 |
|---|---|
| MOST operationally efficient／運用負荷最小 | マネージド・サーバーレス（Fargate／Lambda／Aurora／AWS Backup） |
| MOST cost-effective／最もコスト効率 | Spot・Savings Plans・gp3・Graviton・Intelligent-Tiering・Glacier |
| highly available／単一障害点なし | 複数AZ（ALB＋ASG、RDS Multi-AZ、NAT GWはAZごと） |
| without traversing the internet／インターネット非経由 | VPCエンドポイント／PrivateLink／Direct Connect |
| least privilege／最小権限 | IAMロール＋条件キー（IAMユーザーのアクセスキー配布は不正解） |
| near real time／秒単位RPO | Kinesis／Managed Flink／Aurora Global DB／DRS（バッチ・Athenaは不正解） |
引っかけ
- 「NOT／EXCEPT／LEAST」→ 条件が反転（正しい説明を選ぶ問題ではない。読み落とすと逆の選択肢を選ぶ）
- 「2つ選べ」で1つだけ正しい→ 0点（部分点なし、両方正しくて初めて得点）
- 「どれでも動く」4択→ 要件語（最小運用負荷・最安・最も安全）に最も合う1つ（動作するかではなく最適か）
- 「自前EC2／オンプレで構築・手動運用」の選択肢→ ほぼ不正解（運用負荷最小＝マネージド・サーバーレスが原則）
公式サンプル問題10問の正解パターン A: 毎回級
AWS公式サンプル10問は本番と同型。決定的な制約語→正解→消す選択肢を1行ずつ暗記
- 公式サンプル10問＋Skill Builder公式練習問題集20問（無料）は本番の文体そのもの。各問「決定的な制約語」を1つ拾えば2択に落ちる
- 制約語の型：cannot be directly accessible（NAT）／data in memory（ハイバネーション）／MAC・ライセンス固定（ENI付替え）／cannot be interrupted（Spot除外）／without downtime（Multi-AZ・レプリカ）
- 正解の共通構造：マネージド＋複数AZ＋疎結合（SQS）。単一AZ・単一インスタンス・手動運用・Spotで中断不可ワークロード は消す
- 自分の手順：①要件語→②制約語→③2択→④より運用負荷が低い方
公式サンプル10問：制約語→正解→消す選択肢（公式PDFと照合済み）
| # | 決定的な制約語 | 正解 | 消す選択肢 |
|---|---|---|---|
| 1 | プライベートサブネットから更新取得、外から直接到達不可 | パブリックサブネットにNAT GW＋プライベートルートテーブルに0.0.0.0/0→NAT（2つ選ぶ） | IGW直結、パブリックIP／EIP付与、プライベートサブネット内NATインスタンス |
| 2 | 2週間の停止中もメモリ上のデータを保持 | EC2ハイバネーション（RAMをEBSへ保存） | インスタンスストア、スナップショット、AZ変更 |
| 3 | 監視アプリをプライベートIPのままスタンバイへ迅速切替 | セカンダリENIをスタンバイへ付け替え（IP・MAC維持） | ALB、DHCP変更、EIP付替え（パブリックIPのみ） |
| 4 | S3静的サイトのJSが別バケットへの認証付きGETでブラウザエラー | 取得先バケットにCORS設定（許可オリジン） | バージョニング、バケットポリシー変更 |
| 5 | 暗号鍵をオンプレで管理、AWSに保存しない | SSE-C＋クライアントサイド暗号化（2つ選ぶ） | SSE-S3、SSE-KMS（鍵がAWS内）、Lambda暗号化 |
| 6 | 安定ベース＋月次の中断不可な夜間7時間バッチ | バッチ期間だけオンデマンド一時追加 | Spot、RI追加、全部オンデマンド |
| 7 | 投票の書込み急増でRDSが追いつかない、書込み損失不可 | SQSでバッファ→ワーカーがDBへ書込み | Lambda直接書込み、Multi-AZ（書込み性能は上がらない）、スケジュール再プロビジョニング |
| 8 | 単一AZの2層アプリを高可用に（2つ選ぶ） | 複数AZのALB＋ASG ＋ RDS Multi-AZ（プライベートサブネット） | 同一AZ内の冗長化、DBをパブリックサブネットへ |
| 9 | 正午の急増、起動に1分かかり追従が遅れる | ステップスケーリング＋インスタンスウォームアップ | NLB、キャッシュ、CloudFront |
| 10 | Aurora Multi-AZで読み取りI/Oが書込み遅延を起こす | Auroraレプリカ作成＋アプリで読み書きエンドポイントを使い分け | スタンバイへ読み取り（不可）、別DB分離、リードスルーキャッシュ |
引っかけ
- 「バッチは中断不可・一時的に追加容量が必要」→ オンデマンド一時追加（Spotは2分前通知で中断、RI追加は一時用途に不向き）
- 「再起動のたびにメモリへのデータロードに30分」→ EC2ハイバネーション（停止／再起動はRAMを失う。暗号化ルートEBS必須）
- 「読み取り負荷の分散」→ Auroraレプリカ＋リーダーエンドポイント（RDS Multi-AZのスタンバイは読めない）
- 「急増時にASGが起動し過ぎる」→ ステップスケーリング＋インスタンスウォームアップ（クールダウン延長・シンプルスケーリングでは不十分）
直前10分：キーワード → 正解 早見表
問題文の言い回しから正解を引く表。迷ったら「最もコスト効率」「運用負荷最小」「最も可用性」の修飾語を先に見る。
コンピューティング
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| RIで動く中断不可の夜間ジョブが月末だけ時間超過・最もコスト効率よく | オンデマンドを一時追加 | Spotは中断リスク、追加RIは不要期間も課金（公式サンプル問6） |
| 中断されてよいバッチ/CI/ML学習を最安で | スポットインスタンス（最大90%引） | 2分前通知で中断。「中断不可」「期限厳守」の文言があれば外す |
| Fargate/Lambdaにも割引・将来ファミリーやリージョンが変わるかも | Compute Savings Plans（最大66%） | EC2 Instance SP/Standard RIはファミリー固定で最大72% |
| ソケット/コア単位のBYOLライセンス・物理サーバー専有 | Dedicated Host | Dedicated Instanceはホスト可視性なしでライセンス紐付け不可 |
| 特定AZの容量を確保したいが長期契約はしない | オンデマンドキャパシティ予約（割引なし） | Savings Plansは割引のみで容量は確保しない |
| 2週間停止するがメモリ上のデータを保持したい | EC2ハイバネーション（RAMを暗号化EBSルートへ退避） | スナップショット/インスタンスストアではRAMは残らない（サンプル問2） |
| 固定プライベートIPで接続される監視EC2を待機系に即時切替 | セカンダリENIを待機EC2に付け替え | プライマリENIはデタッチ不可。EIP/ALBはパブリック側（サンプル問3） |
| 停止で消えてよい一時データ・最高IOPS | インスタンスストア | 停止/終了で消失（再起動は保持）。永続化はEBS |
| HPC・ノード間の超低レイテンシ通信 | クラスタープレイスメントグループ（単一AZ） | Spreadは逆に離す。Clusterは同時障害リスクあり |
| 少数の重要インスタンスを同時障害から守る | スプレッドプレイスメントグループ（AZあたり最大7台） | Kafka/Cassandra/HDFSの障害ドメイン分離ならパーティション（AZあたり最大7パーティション） |
| 起動に1分かかるアプリがASGで過剰スケール/タイムアウト | インスタンスウォームアップ＋ヘルスチェック猶予期間 | ElastiCacheやCloudFrontは無関係（サンプル問9） |
| 毎日決まった時刻に負荷増／CPUを一定に保つ／周期パターンを事前に | スケジュール／ターゲット追跡／予測スケーリング | 起動設定は非推奨、起動テンプレートを使う |
| メモリ使用率でスケール・アラーム | CloudWatchエージェントでカスタムメトリクス | EC2標準メトリクスにメモリ/ディスク使用率はない |
| ELBが異常判定してもASGがインスタンスを置換しない | ASGのヘルスチェックタイプをELBに変更 | 既定のEC2ステータスチェックではアプリ障害を検知しない |
| ハードウェア障害時に同じIP/EBSで自動復旧 | CloudWatchアラームのEC2復旧（recover）アクション | ASG置換は状態が失われる |
| 15分超の処理・GPU・常時稼働・ステートフル | Lambda不可→Fargate / AWS Batch / EC2 | Lambda上限: 15分、10GBメモリ、同時実行1,000/リージョン（既定・引上げ可） |
| Java Lambdaのコールドスタートが遅い | SnapStart（Java/Python/.NET対応） | 常にウォーム確保はProvisioned Concurrency（高コスト） |
| LambdaからRDSで接続枯渇（too many connections） | RDS Proxy | インスタンス拡大やLambda同時実行増は根本解決でない |
| VPC内LambdaからインターネットやS3に届かない | NAT Gateway（S3ならGateway型エンドポイント） | VPC設定だけではインターネット経路を持たない |
| Kubernetes既存資産・マルチクラウド方針・K8sスキルのチーム | EKS | 明記がなければECS（Fargate）が運用負荷最小。K8s内部実装は範囲外 |
| コンテナのサーバー管理をなくしたい・運用負荷最小 | ECS/EKS on Fargate | 常時高負荷ならEC2起動タイプ＋RI/SPが安い場合も |
| コンテナ内アプリがS3等にアクセスする権限 | ECSタスクロール | タスク実行ロールはECR pull/ログ用。インスタンスロールは過剰権限 |
| 開発者がインフラを意識せずWebアプリをデプロイ | Elastic Beanstalk | テンプレートで全リソース→CloudFormation。OpsWorks（Chef/Puppet）は2024年に提供終了、選択肢にあっても正解になりにくい |
| 同じテンプレートを複数アカウント・複数リージョンに一括展開・新規アカウントにも自動 | CloudFormation StackSets（サービスマネージド型＋Organizations） | 通常スタックは単一アカウント・単一リージョン。Nested Stackは部品化 |
| 同性能でコストを下げたい・ARM対応可／インスタンスサイズが適正か診断 | Graviton（g付き）へ移行／Compute Optimizer | Compute Optimizerは推奨のみで自動変更しない |
ストレージ
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| アクセスパターンが不明・変動する | S3 Intelligent-Tiering | IAは頻繁アクセスで取り出し料が逆に高い。監視料あり・取り出し料なし |
| 四半期に1回アクセス・ミリ秒で即時取得 | Glacier Instant Retrieval（最小90日） | Flexible標準は3〜5時間、迅速は追加課金。Flexibleとの単価差は約10% |
| 数時間待てるアーカイブ・年1〜2回 | Glacier Flexible Retrieval（迅速1〜5分/標準3〜5h/バルク5〜12h） | Deep Archiveは標準12h/バルク48h |
| 7〜10年の法令保管・最安・12時間以上待てる | Glacier Deep Archive（最小180日） | 「数分で復元」要件は満たせない |
| 再作成可能なデータ（サムネ・二次コピー）を安く | S3 One Zone-IA | 単一AZ・可用性99.5%。失えないデータには不可 |
| 最小保存期間前に削除/移行（毎日削除するデータをIAに） | 不正解・その期間分課金される | IA 30日/Glacier IR・Flexible 90日/Deep Archive 180日。IA最小課金128KB |
| 作成後10日でStandard-IAへライフサイクル移行 | 設定不可（Standard→IAは30日以降のみ） | Glacier系へは即日可。逆方向は復元コピーが必要 |
| 規制で改ざん・削除禁止（rootでも不可） | S3 Object Lock コンプライアンスモード | ガバナンスは特権ユーザーが解除可。バージョニング必須。既存バケットにも有効化可（2023年11月〜、旧問では「新規のみ」） |
| 誤削除防止・永続削除にMFA要求 | バージョニング＋MFA Delete | バージョニングは無効化不可（停止のみ）。CRR/SRRの前提条件 |
| S3をCloudFront経由のみに限定・直リンク防止 | OAC＋バケットポリシー＋ブロックパブリックアクセス | OAIは旧方式。静的サイトのHTTPSもCloudFront経由 |
| 認証情報のない相手に期限付きでファイルを渡す | 署名付きURL（発行者の権限で動く） | IAMユーザー作成やACL公開は誤り。複数ファイルはCloudFront署名付きCookie |
| 別ドメインのページのJavaScriptからS3へアクセス | S3バケットにCORS設定 | 公式サンプル問4。存在しない「execute権限」は誤答の目印 |
| 暗号化キーの使用を監査したい | SSE-KMS（CloudTrailに記録） | SSE-S3は無料だが監査不可 |
| オンプレ保管のキーで保存時暗号化 | SSE-C＋クライアントサイド暗号化 | SSE-S3/SSE-KMSはキーがAWS内（サンプル問5） |
| SSE-KMSで大量アクセス・KMS API料金が高額 | S3バケットキー | 既存オブジェクトには遡及しない。暗号化方式自体は変わらない |
| 取得時にPIIマスク・形式変換、加工コピーを持ちたくない | S3 Object Lambda | GET/LIST/HEADのみ。PUT時の加工は対象外 |
| 共有バケットのポリシー肥大化・チーム別に入口を分離 | S3アクセスポイント（VPCオリジン限定も可） | 加工はしない。複数リージョンを束ねるならMulti-Region Access Point |
| 組織全体のS3利用状況・コストを可視化 | S3 Storage Lens | 可視化専用。自動でクラス移行はしない（Intelligent-Tieringの役割） |
| 世界中から大容量ファイルを高速アップロード | Transfer Acceleration＋マルチパートアップロード | 100MB超は推奨・5GB超は必須。CRRはDR用 |
| 一貫した超高IOPS（数万〜25万）・サブミリ秒レイテンシのDB | io2 Block Express（最大256,000 IOPS） | gp3は最大80,000 IOPS/2,000MiB/s（2025年9月拡張。旧問では16,000が上限として出る）。HDD（st1/sc1）はブート不可 |
| EBSコストを下げたい | gp2→gp3（約20%安、ベースライン3,000 IOPS・125MiB/s） | サイズと独立にIOPS/スループット設定可 |
| 既存の非暗号化EBSを暗号化 | スナップショット→暗号化コピー→新ボリューム | 稼働中の直接暗号化は不可。EBSはAZ内・別AZはスナップショット経由 |
| 複数EC2（複数AZ・Linux）で共有ファイルシステム | EFS（NFS） | EBSはAZ内単一。Multi-Attachはio1/io2同一AZのみ。Windowsは不可 |
| Windows・SMB・Active Directory統合の共有／NFS+SMB+iSCSI・オンプレNetApp移行 | FSx for Windows File Server／FSx for NetApp ONTAP | EFSはLinux専用。FSx for WindowsはSMBのみ |
| HPC/ML学習データをS3と連携し高速並列処理 | FSx for Lustre | EFSやONTAPではない。HPCを見たらLustre |
データベース
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| 読み取り負荷を分散・レポート/分析クエリをオフロード | リードレプリカ（RDS MySQL/MariaDB/PostgreSQL/SQL Server最大15・Oracle最大5・Aurora最大15） | Multi-AZ DBインスタンス配置のスタンバイは読めない（サンプル問10のB）。Multi-AZ DBクラスター（2台のリーダブルスタンバイ）は読める |
| 可用性を上げたい・自動フェイルオーバー | RDS Multi-AZ（同期・同一リージョン） | リードレプリカは非同期・手動昇格。Multi-AZは性能向上しない |
| Aurora Multi-AZで読み取りI/Oが書き込みを遅くする | 同一クラスタにAuroraレプリカ追加＋リーダーエンドポイント | 別クラスタをレプリカとしてリンクは誤り（サンプル問10） |
| 既存RDSを暗号化したい | スナップショット→暗号化コピー→復元 | 暗号化は作成時のみ。別リージョンコピーは転送先KMSキー |
| 自動バックアップ35日超の保持 | 手動スナップショット or AWS Backup | 自動バックアップは0〜35日、PITR 5分粒度 |
| リージョン障害でRPO1秒未満・RTO1分未満 | Aurora Global Database | クロスリージョンリードレプリカは遅延大 |
| 断続的・予測不能・開発テストのRDBを安く | Aurora Serverless v2（開発RDSは停止最大7日も） | 常時高負荷ならプロビジョンドの方が安い |
| 誤ったDELETEを数時間前に巻き戻し（リストア不要） | Aurora Backtrack（Aurora MySQLのみ・最大72時間） | PITRは新インスタンスとして復元。Aurora PostgreSQLは非対応 |
| RDS MySQLでは足りない：128TiB・3AZ×2=6コピー・ストレージ自動拡張・ストレージ共有レプリカ | Aurora | RDS MySQLは64TiB・EBSベース。レプリカ数は今はRDSも15まで可能なので、決め手はストレージ/6コピー/レプリカ遅延。Auroraは約20%高い |
| Oracle→Aurora PostgreSQL（異種）をダウンタイム最小で | SCT＋DMS（フルロード+CDC） | 同種（MySQL→Aurora MySQL）はDMSのみ。並行稼働の差分反映=CDC |
| トラフィック予測不能・急増するNoSQL | DynamoDBオンデマンド | 安定負荷ならプロビジョンド＋Auto Scalingが安い |
| テーブル作成後に別のパーティションキーで検索を追加 | GSI | LSIは作成時のみ・同一パーティションキー。GSIは結果整合のみ |
| DynamoDB読み取りをマイクロ秒に・コード変更最小 | DAX | ElastiCacheは汎用。DAXは読み取り専用で書き込みは速くならない |
| セッション/一時データを期限で自動削除 | DynamoDB TTL | WCU消費なし・無料 |
| 複数リージョンで読み書き（Active-Active） | DynamoDB Global Tables（Streams必須） | 競合はLast Writer Wins |
| テーブル変更をトリガーに処理・変更前後を比較 | DynamoDB Streams＋Lambda（NEW_AND_OLD_IMAGES） | 保持24時間。長期/多コンシューマーはKinesis Data Streams for DynamoDB |
| アクセス頻度の低いDynamoDBテーブルのコスト削減／全成功か全失敗 | Standard-IAテーブルクラス／DynamoDBトランザクション | 項目上限400KB、超える場合はS3＋ポインタ |
| リーダーボード・Pub/Sub・永続化・フェイルオーバー | ElastiCache Redis（Valkey） | Memcachedは永続化/レプリカなし・マルチスレッドの単純キャッシュ |
| 複数EC2でセッション共有しステートレス化 | ElastiCache Redis or DynamoDB | スティッキーセッションはスケール/障害に弱い |
| 数十万件の書き込みバーストにRDSが追いつかない・ダウンタイムなし | SQSでバッファ＋ワーカーで平準化 | ElastiCache/DB拡大/Multi-AZは書き込みの解にならない（サンプル問7） |
| S3のログをたまにSQLで分析・サーバー管理なし | Athena | Redshift/EMRクラスタは過剰 |
| S3のデータとDWHのデータを結合してクエリ／急なクエリ増加 | Redshift Spectrum／Concurrency Scaling | OLTPにRedshiftは不可（列指向・OLAP専用） |
| MongoDB互換／グラフ（友達の友達）／時系列IoT／改ざん不能台帳／全文検索 | DocumentDB／Neptune／Timestream／QLDB／OpenSearch | 「Cassandra」→Keyspaces、「SQL Serverアプリ互換」→Babelfish。QLDBは2025年7月にサポート終了だが試験の選択肢にはまだ出る |
| 複雑なJOIN・ACIDのリレーショナル | RDS/Aurora（DynamoDBは不向き） | 「毎秒数十万・スキーマ変化・1桁ms」ならDynamoDB |
| パスワード不要でRDSに接続 | IAMデータベース認証（15分トークン） | 認証情報の保存・ローテーションはSecrets Manager |
ネットワーク
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| プライベートサブネットのEC2をインターネットへ（直接到達は不可） | パブリックサブネットにNAT GW＋プライベートのルートに0.0.0.0/0→NAT | NATをプライベートに置く/EC2にEIPは要件違反（サンプル問1） |
| NAT GWをAZ障害に耐えさせる | AZごとにNAT GWを配置 | 単一NAT共有は安いがAZ間転送料＋単一障害点。NATにSGは付けられない |
| NATの処理料が高い・S3/DynamoDBへインターネット非経由 | Gateway型VPCエンドポイント（無料） | Interface型は課金。オンプレからS3プライベート接続はInterface型 |
| 自社サービスを他VPC/多数の顧客アカウントに公開・CIDR重複 | PrivateLink（NLB＋Interfaceエンドポイント） | ピアリング/TGWはCIDR重複不可・推移しない |
| 特定IPを拒否したい | NACLのDenyルール（またはWAF IPセット） | SGはAllowのみ。SGはステートフル、NACLはステートレス |
| 戻りの通信が通らない | NACLアウトバウンドでエフェメラルポート1024-65535を許可 | NACLは番号順に評価し最初の一致で決定 |
| DB層はWeb層からのみ3306を許可 | DB SGのソースにWeb SGのIDを指定 | IP範囲指定より最小権限 |
| 数十のVPCとオンプレを相互接続・推移的ルーティング | Transit Gateway | ピアリングは1対1・非推移でフルメッシュは運用負荷大 |
| 来週までにオンプレ接続・安価・暗号化 | Site-to-Site VPN（1トンネル最大1.25Gbps・ECMPで束ねる） | DXは開通に数週間〜数か月 |
| 一貫した高帯域・低遅延・大量転送・データを暗号化 | Direct Connect（暗号化はDX上にVPN、またはMACsec） | DXはデフォルト非暗号化。冗長はDX×2かDX＋VPNバックアップ |
| 固定IPをホワイトリスト登録・UDP・超低遅延 | NLB（ALBの前段にNLBも可） | ALBは固定IPなし・HTTPのみ。NLBはクロスゾーン既定OFF |
| パス/ホストベースルーティング・WAF・Lambdaターゲット・Cognito認証 | ALB | WAFはNLB/EC2に直接付けられない |
| サードパーティFW/IDSアプライアンスを透過的に挿入 | Gateway Load Balancer（GENEVE 6081） | CLBは旧世代で答えにならない |
| Zone Apex（example.com）をELB/CloudFrontに向ける | Aliasレコード（クエリ無料） | CNAMEはApex不可 |
| 最も近いリージョンへ／国ごとにコンテンツ・法規制／バイアスで範囲調整／段階的移行・A/B | レイテンシー／位置情報／地理的近接性／加重ルーティング | 位置情報とレイテンシーの混同に注意 |
| アクティブ/パッシブDRの自動切替 | Route 53フェイルオーバー＋ヘルスチェック | プライベートリソースはCloudWatchアラーム連動型で監視 |
| オンプレ⇔VPCで相互に名前解決 | Route 53 Resolver インバウンド/アウトバウンドエンドポイント | プライベートホストゾーンはDNS属性有効化が前提 |
| 静的IP・TCP/UDP・ゲーム/VoIP/IoT・即時リージョンフェイルオーバー | Global Accelerator | CloudFrontはHTTPキャッシュでIP可変。キャッシュ要件ならCloudFront |
| 有料コンテンツ・複数ファイルの配信制限 | CloudFront署名付きCookie（単一ファイルは署名付きURL） | 国単位制限はCloudFront地域制限 |
| エッジでヘッダー操作/URL書換を安く | CloudFront Functions | オリジンリクエスト書換・外部API呼出しはLambda@Edge |
| CloudFront用のACM証明書 | us-east-1で発行 | EC2に直接インストール不可（ALBでTLS終端） |
| API Gatewayを社内IP/特定VPCからのみ | リソースポリシー（プライベートAPI＋VPCエンドポイント） | Cognito/Lambdaオーソライザーは「誰か」を検証、「どこから」はリソースポリシー |
| 複数アカウント・VPCのIPアドレス重複/枯渇を防ぐ | VPC IPAM | VPC CIDRは作成後変更不可（セカンダリ追加は可）。サブネットは1AZ |
| パケットの中身を検査／特定ドメインへのアウトバウンド制限／許可・拒否の記録 | Traffic Mirroring／Network Firewall／VPCフローログ | フローログはメタデータのみ。SGはドメイン指定不可 |
| IPv6のアウトバウンド専用 | Egress-Only Internet Gateway | NAT GWはIPv4用 |
セキュリティ・ID
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| EC2/Lambda/ECSから最もセキュアにAWSアクセス | IAMロール（インスタンスプロファイル/実行ロール/タスクロール） | アクセスキー埋込みは常に不正解 |
| Allowがあるのに拒否される | 明示的Deny／SCP／アクセス許可境界が原因 | 明示的Denyは常に勝つ。境界とSCPは上限（積集合）で許可は与えない |
| クロスアカウントでS3にアクセス | バケットポリシー＋呼出し側IAMポリシー両方（またはAssumeRole） | 同一アカウント内はどちらかのAllowでOK |
| 組織全体で特定リージョン/サービスを禁止・CloudTrail無効化禁止 | SCP | 権限は付与しない。管理アカウントには効かない |
| 複数アカウントへのSSO・社内ADの資格情報でコンソールへ | IAM Identity Center（SAML）＋許可セット | 各アカウントにIAMユーザー作成は誤り。マルチアカウント許可セットはOrganizationsの組織インスタンスが必要（単一アカウント向けのアカウントインスタンスもある） |
| 退職者のアクセスを即座に自動失効 | SCIM（自動プロビジョニング） | SAMLは認証のみ。SCIMなしだとユーザー削除は手動 |
| モバイル/Webアプリ利用者のサインインとS3への直接アクセス | Cognitoユーザープール（認証）＋IDプール（STS一時認証情報） | 社員SSOにCognito、アプリ利用者にIAMユーザーは誤り |
| オンプレADの認証をそのまま・AWS側に複製しない | AD Connector | 信頼関係/ドメイン参加/FSx連携が必要ならManaged Microsoft AD |
| サードパーティに権限委任（混乱した代理対策） | IAMロール＋ExternalId（信頼ポリシーのsts:ExternalId条件） | IAMユーザー発行ではない。AWSサービスが呼ぶロールの場合はaws:SourceArn/aws:SourceAccount条件 |
| ゼロからマルチアカウント環境を標準構成で・新規アカウント払い出し | Control Tower（予防＝SCP／発見＝Config、Account Factory） | Organizationsの代替ではなく上に構築される層 |
| 複数アカウントのWAF/Shield/SGルールを一括適用・新規にも自動 | Firewall Manager | 単一アカウントなら素のWAF。SCPはFWルールの中身は制御しない |
| サブネット/Transit Gatewayを他アカウントと共有 | RAM | VPCピアリングではない |
| SQLインジェクション/XSS/レートベース／L3-4 DDoS＋コスト保護＋対応チーム | WAF（ALB/CloudFront/API GW）／Shield Advanced | Shield Standardは無料・自動。WAFはNLBに不可 |
| 脅威検出／脆弱性CVE／S3のPII／根本原因調査／検出結果の集約 | GuardDuty／Inspector／Macie／Detective／Security Hub | Inspectorを「S3の個人情報」に選ぶのは誤り |
| 誰がAPIを呼んだか／設定がどう変わり準拠しているか／性能・アラーム | CloudTrail／Config／CloudWatch | Configを「APIコールの記録」に選ぶのは誤り |
| S3オブジェクト単位の操作記録 | CloudTrailデータイベント（既定オフ） | 管理イベントだけでは取れない。イベント履歴90日、証跡はS3へ |
| キーポリシー変更・他アカウント共有・削除制御 | KMSカスタマー管理キー（削除待機7〜30日） | AWS管理キー（aws/s3等）では不可。4KB超はエンベロープ暗号化 |
| 専有HSM・FIPS 140-2 Level 3・鍵を完全に自社管理 | CloudHSM（またはKMSカスタムキーストア） | 鍵をAWSの外に置く規制→XKS。可用性責任は自分側に移る |
| 暗号化データを別リージョンで復号／暗号化スナップショットを別リージョンへ | マルチリージョンキー／転送先リージョンのキーで再暗号化 | KMSキーはリージョン固有 |
| DBパスワードの自動ローテーション | Secrets Manager | Parameter Storeはローテーションなし。KMSは鍵であり値は保存しない |
| 安価に設定値・シークレットを保存 | Systems Manager Parameter Store（標準無料） | 「rotate」が出たらSecrets Manager |
| TLS証明書の自動更新 | ACM（ELB/CloudFront/API GWに紐付け） | インポート証明書は自動更新されない。EC2直接は不可 |
| HTTPS強制／暗号化なしPUT拒否／組織内のみ許可 | バケットポリシー条件 aws:SecureTransport / s3:x-amz-server-side-encryption / aws:PrincipalOrgID | エンドポイント経由のみはaws:SourceVpce |
| バックアップを7年誰にも消させない（ランサムウェア対策） | AWS Backup Vault Lock コンプライアンスモード（猶予最短3日=72時間） | ガバナンスはIAM権限で解除可。既存リカバリポイントに遡及しない |
| 複数アカウントのセキュリティログをOCSF正規化で長期保存・独自分析 | Security Lake | Security Hubは検出結果のダッシュボード |
統合・分析
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| 順序保証・厳密に1回処理 | SQS FIFO（300msg/s、バッチ3,000） | 最大スループット→標準キュー（少なくとも1回・重複あり） |
| 同じメッセージが複数回処理される | 可視性タイムアウトを処理時間より長く＋冪等化 | 既定30秒・最大12時間。メッセージ最大1MiB（2025年8月〜、旧問では256KB）・保持既定4日/最大14日 |
| 失敗を繰り返すメッセージを隔離・分析 | デッドレターキュー（maxReceiveCount） | Lambda非同期失敗もDLQ/送信先 |
| 空応答を減らしSQSコスト削減 | ロングポーリング（最大20秒） | ASGのスケール指標はキュー長÷インスタンス数 |
| 1イベントを複数システムで並列・独立処理 | SNS→複数SQS ファンアウト | SQS単体は1コンシューマー。SNSはメッセージを保持しない |
| イベントの中身で振り分け・SaaS連携・cron定期実行・複数アカウント集約 | EventBridge（パートナー/カスタムバス、クロスアカウント） | SNSはトピック単位。1ルール最大5ターゲット |
| Kinesisで多数コンシューマーが同じストリームを低遅延で読む | 拡張ファンアウト（コンシューマーごとシャードあたり2MB/s・HTTP/2プッシュ） | 標準はシャード2MB/sを全コンシューマーで共有 |
| 既存のJMS/AMQP/MQTTブローカーを改修なしで移行 | Amazon MQ（ActiveMQ/RabbitMQ） | 新規のクラウドネイティブはSQS/SNS |
| 複数Lambdaの順次実行・分岐・再試行・人手承認・長時間待機 | Step Functions（Standard最長1年/Express5分） | LambdaからLambda直接連鎖は非推奨 |
| リアルタイム（秒未満）・複数コンシューマー・再処理（リプレイ） | Kinesis Data Streams（保持24h〜365日） | SQSは消費後削除。スロットル→シャード分割/キー分散 |
| ストリームをS3/Redshift/OpenSearchへ最小運用でロード・Parquet変換 | Amazon Data Firehose（Lambdaで変換） | ニアリアルタイム・保持/再生なし・DynamoDB宛て不可。旧名Kinesis Data Firehose |
| 既存Kafkaアプリの移行／ストリームにSQLで集計・異常検知 | MSK／Managed Service for Apache Flink | 旧Kinesis Data Analytics |
| Athenaのコストと時間を下げる | Parquet/ORC＋圧縮＋パーティション（Glue/Firehoseで変換） | スキャン量課金（1TB約5USD） |
| サーバーレスETL・スキーマ自動検出・Data Catalog | Glue（クローラー） | 既存Hadoop/Sparkジョブ→EMR（タスクノードにSpot） |
| データレイクの列/行レベル権限を分析サービス横断で一元管理 | Lake Formation | IAMだけでは列/行レベル困難。取り込み雛形はブループリント |
| BI・ダッシュボード可視化 | QuickSight（SPICE） | DynamoDBは直接不可（Athena経由） |
| ログをリアルタイム検索・可視化／あいまい検索・関連度順の商品検索 | OpenSearch Service | AthenaはS3へのSQL、RDS LIKEは大規模で遅い |
| Salesforce等SaaSデータをS3/Redshiftへノーコード定期取込 | AppFlow | AppSync(GraphQL)/App2Container(範囲外)と混同しない |
| シンプルなLambdaプロキシを最安／APIキー・使用量プラン・キャッシュ／双方向チャット | HTTP API／REST API／WebSocket API | 統合タイムアウト既定29秒（Regional/PrivateのREST APIは2024年6月から引上げ可）→試験では長時間処理は非同期化が定石 |
| ユーザーごとに呼び出し回数を制限／特定エンドポイントだけ流量制限 | 使用量プラン＋APIキー／メソッドレベルのスロットリング | 超過は429。同一データの繰り返し→API Gatewayキャッシュ |
| API Gatewayからプライベートサブネット内のALB/NLBへ | VPCリンク | 一部ユーザーに先行公開→カナリアデプロイ |
| GraphQL・リアルタイム購読・オフライン同期 | AppSync | REST APIならAPI Gateway |
| 大量ユーザーへメール配信 | SES | SNSはアラーム通知程度のEmail/SMS |
| イベントをターゲットに渡す前に整形／APIのリクエスト・レスポンス形式変換 | EventBridge入力トランスフォーマー／API Gatewayマッピングテンプレート（VTL） | 「イベント・ルール」→EventBridge、「API・リクエスト」→API Gateway |
| PDF/請求書から表を抽出／感情分析／通話の文字起こし／社内文書検索／チャットボット | Textract／Comprehend／Transcribe／Kendra／Lex | 「運用負荷最小」ならSageMakerで自作は不正解 |
運用・移行
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| サーバーをOS丸ごとダウンタイム最小でリフト&シフト | MGN（Application Migration Service・継続ブロックレプリケーション） | DMSはDB専用、DataSyncはファイル専用 |
| ダウンタイム最小でDB移行・並行稼働で差分反映 | DMS フルロード＋CDC（ソース稼働のまま） | 異種エンジンはSCTを併用。同種ならSCT不要 |
| オンプレのファイルを一回/定期的に大量オンライン転送 | DataSync（NFS/SMB/HDFS→S3/EFS/FSx） | 継続的なアクセス→Storage Gateway。Glacier直接可 |
| オンプレアプリがNFS/SMBで使い続けながらS3に保存 | S3ファイルゲートウェイ | S3コンソールからオブジェクトとして見える |
| オンプレ容量を節約・全データはS3／全データはオンプレ・非同期でDRバックアップ | キャッシュ型ボリュームGW／保管型ボリュームGW | どちらもiSCSI、EBSスナップショットとして復元 |
| テープバックアップを既存ソフトのまま置換 | テープゲートウェイ（VTL→S3/Glacier/Deep Archive） | S3ファイルゲートウェイではない |
| 帯域不足でネット転送に1週間以上・数十TB〜PB | Snowball Edge（Storage Optimized 80TB／210TB版あり） | Glacierへ直接不可（S3経由ライフサイクル）。DX新設は間に合わない |
| 既存のSFTPワークフローを変えずにS3/EFSへ | Transfer Family（SFTP/FTPS/FTP/AS2） | DataSyncではない |
| 複数サービスのバックアップを一元管理・クロスリージョン/アカウントコピー | AWS Backup | EBSスナップショット/AMIのみならDLM。cron手動コピーは誤り |
| SSH/RDPポートを開けずEC2に接続・踏み台廃止 | Systems Manager Session Manager | SSMエージェント＋IAMロール、インバウンド不要、操作ログ記録 |
| 多数EC2のOSパッチを最小の運用負荷で | Patch Manager＋メンテナンスウィンドウ | Ansible/手動スクリプトは誤り。オンプレもハイブリッド管理可 |
| 大量EC2にインスタンスプロファイルを付けずSSM管理を自動有効化 | SSM デフォルトホスト管理設定（DHMC） | IMDSv2必須。既存プロファイルの権限が優先される |
| 複数アカウントのメトリクス/ログ/トレースを1画面で串刺し検索 | CloudWatchクロスアカウントオブザーバビリティ（監視アカウント） | CloudWatchの機能拡張であり別サービスではない |
| 複数アカウントのパッチ状況/OpsItemを一元管理 | Systems Manager Explorer / OpsCenter | 運用タスクの状態管理はSSM |
| Prometheus等AWS外のデータも統合した見栄えの良いダッシュボード | Managed Grafana | CloudWatchダッシュボードはAWSメトリクス中心 |
| 複数アカウント・リージョンのリソースをキーワード検索／設定履歴・準拠を横断 | Resource Explorer（集約インデックス）／Config Aggregator | Workload Discoveryはソリューションで試験対象外 |
| SGで0.0.0.0/0のSSHを継続監視・自動修復 | Configルール＋SSM Automation | Trusted Advisorは一時的チェック |
| マイクロサービスのどこが遅いか・分散トレーシング | X-Ray | 誰が削除→CloudTrail、設定変更→Config |
| CloudWatch Logsの保管コスト増大 | ロググループの保持期間設定（既定無期限）／S3エクスポート | サブスクリプションフィルタでKinesis/OpenSearchへ |
| 1分粒度のEC2メトリクスが必要 | 詳細モニタリング（有料） | 標準は5分。高解像度カスタムは1秒 |
| 承認済みCloudFormation製品だけ利用者にセルフサービス提供 | Service Catalog | IAMだけでは制御困難 |
| 未使用EIP/低使用率EC2/アイドルELBの検出 | Trusted Advisor（全項目はBusiness以上） | 適正サイズ推奨→Compute Optimizer、コスト可視化→Cost Explorer |
| 移行前にオンプレのサーバー依存関係を把握／移行進捗を一元管理 | Application Discovery Service／Migration Hub | vSphereそのまま→VMware Cloud on AWS |
| AWS側の障害/メンテが自アカウントに影響するか通知 | AWS Health Dashboard（EventBridge連携） | コンプライアンスレポート取得→Artifact |
| 起動を速くしたい・構成統一 | ゴールデンAMI（EC2 Image Builder）＋起動テンプレート | ユーザーデータで毎回インストールは遅い。AMIはリージョン固有（コピー） |
可用性・コスト
| 問題文のキーワード | 正解 | 理由・違い |
|---|---|---|
| MOST cost-effective／最もコスト効率が高い | 要件を満たす中で最安（Spot・S3階層・サーバーレス・Gateway型EP・gp3・単一NAT） | 要件（中断不可・HA・RPO）を落とした安い選択肢は不正解 |
| LEAST operational overhead／運用負荷が最小 | マネージド/サーバーレス（Aurora Serverless・Fargate・Lambda・DynamoDB・Firehose・AWS Backup） | EC2自前構築・スクリプト運用の選択肢を消す |
| highly available／高可用性 | 複数AZ（ALB＋ASG複数AZ・RDS Multi-AZ・NAT GWをAZごと・EFSマウントターゲット各AZ） | 「リージョン障害に耐える」ならマルチリージョン |
| MOST secure／最小権限 | IAMロール＋一時認証・最小ポートSG・プライベートサブネット・VPCエンドポイント・KMS・Secrets Manager | アクセスキー配布・0.0.0.0/0・パブリック配置を消す |
| without changing the application／アプリ改修なし | インフラ側で解決（RDS Proxy・ENI付替え・Storage Gateway・Amazon MQ・ALB認証・DMS） | アプリ変更を要する選択肢を消す |
| fault tolerant／障害時もダウンなし | Multi-site Active-Active・冗長構成 | HA（Multi-AZ）は短時間のフェイルオーバーを許容 |
| 単一AZの2層構成をHAに（2つ選べ） | ALB＋ASGを複数AZ／RDS Multi-AZをプライベートサブネットへ | 公式サンプル問8 |
| RTO時間単位・最安／RTO数十分・コスト抑制／RTO数分／ダウンタイムほぼゼロ | バックアップ&リストア／パイロットライト／ウォームスタンバイ／マルチサイト | RPO 5分・RTO 1時間・最小コスト→パイロットライト。マルチサイトは最高コスト |
| Multi-AZはDRか | いいえ。同一リージョン内HA。リージョンDRはAurora Global/DynamoDB Global Tables/S3 CRR/Route 53フェイルオーバー | AMI/スナップショット/KMSキーはリージョン固有→コピー必要 |
| DR先リージョンで起動できない | サービスクォータの事前引上げ・AMI/スナップショットの事前コピー・低TTL | タスク2.2に明記 |
| 安定ベース負荷＋変動分＋中断可の処理 | RI/Savings Plans＋オンデマンドASG＋Spot の3層 | 一時的な月末増にRI追加は不正解 |
| 将来インスタンスタイプを変えるかも | Convertible RI または Compute Savings Plans | Standard RIはファミリー変更不可（同一ファミリー内のサイズ/AZ変更やMarketplace売却は可）。特定AZ容量確保→ゾーンRI/キャパシティ予約 |
| NAT GWのデータ処理料削減 | S3/DynamoDBへはGateway型VPCエンドポイントへ逃がす | NAT増設ではない |
| AZ間データ転送料が高い | 同一AZ・プライベートIP通信（可用性とトレードオフ） | インバウンド無料・同一AZプライベートIP無料・パブリックIP経由は同一AZでも課金 |
| 配信コスト削減・オリジン負荷減 | CloudFront（S3→CloudFront転送無料、価格クラスで地域限定） | 大量の継続アウトバウンドはDXの方がGB単価安い |
| 部門別にコストを按分 | コスト配分タグ（有効化必須）＋Cost Explorer | タグを付けただけでは請求に反映されない |
| 予算超過前に通知／最も粒度の細かい明細／異常支出の検知／可視化・予測・RI推奨 | Budgets／Cost and Usage Report／Cost Anomaly Detection／Cost Explorer | Cost Explorerは事後分析 |
| RI/SPを複数アカウントで共有・ボリューム割引合算 | Organizations一括請求 | アカウント間の請求按分はタグで |
| 夜間・週末の非本番を安く | Instance Scheduler/EventBridge＋Lambdaで停止・RDS停止（最大7日）・ハイバネーション | 非本番はMulti-AZ不要・Spot可・小さいインスタンス |
| ログ/バックアップの保管コスト | 保持期間を要件に合わせて短縮（CloudWatch Logs・RDS・AWS Backupライフサイクル・EBS Snapshots Archive） | 未使用EBS/スナップショット/EIPの削除も定番 |
| 2択で迷ったら | よりマネージド・よりサーバーレス・よりAWSネイティブ | ただし「既存の○○をそのまま」なら互換サービス（MQ・DocumentDB・FSx for Windows・Transfer Family） |
| 消去法の順序 | 要件違反→存在しない機能（Multi-AZ DBインスタンスのスタンバイ読取・プライマリENI付替え・NLBにWAF）→運用負荷/コスト高の自前構築 | 問題文の最後の1文（制約語）に決め手がある |
| 複数選択（2つ選べ） | 1つの解を構成する2手順（NAT作成＋ルート更新）か独立した2解かを判断・指示数厳守 | 未回答は不正解・誤答ペナルティなし→全問マーク |
| NOT/EXCEPT・訳が不自然・サービス略称 | 最後の1文を2回読む・英語原文に切替・ヘルプの略称一覧 | 65問130分＝1問2分。迷ったらフラグで後回し。15問は非採点 |
| 旧名称・古い知識が選択肢に | SSO→IAM Identity Center、CloudWatch Events→EventBridge、OAI→OAC、KDA→Managed Flink、Kinesis Data Firehose→Amazon Data Firehose、gp2→gp3 | S3は全操作が強い整合性（「結果整合性でラグ」は誤り）。CLB/EC2-Classic/OpsWorksは答えにならない |
確認しきれなかった記述
AWS公式ドキュメントで裏取りできなかった記述。本文では「目安」扱い。ここに載っている数値だけは鵜呑みにしない。
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：Graviton「最大40%の価格性能比向上」: Graviton2 vs 同等x86のAWS公表値として広く知られるが今回は公式ページで直接確認していないため「目安」表記に変更
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：AZ再調整「起動が24時間失敗し続けると起動プロセスが停止（管理者サスペンション）」: 今回未確認のため「目安」表記
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：Beanstalk「IAMユーザー作成はできない」: 意味が不明瞭（Beanstalkが作成するのはインスタンスプロファイル/サービスロール）。試験上の重要度は低いので原文維持
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：OpsWorks Stacks の提供終了日（2024年5月EOL）: URL未取得。SAAでは名称レベルのみ
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：EKSコントロールプレーンの時間課金額（$0.10/時）、Batch/Image Builder/Beanstalk自体が無料である点: 一般に知られるが今回のフェッチでは未確認
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：Lambda 実行ロール以外の細部（Destinations の SNS 256KB上限など）は本文に入れていない
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：参考（本文に未反映）: Lambda クォータページに「Lambda Managed Instances は非同期/ESM で最長90分」の記載あり。SAA-C03 では従来どおり「Lambda＝最大15分」で解答するのが安全
- コンピューティング（EC2・Auto Scaling・Lambda・ECS/EKS/Fargate・Batch・Beanstalk）：Compute Optimizer の Lambda 対象範囲（arm64 移行推奨を含むか）など細部は未確認
- ストレージ：S3 ライフサイクル「Standard→Standard-IA/One Zone-IAは作成後30日以降のみ」: 現行の公式ドキュメント（英/日/ポルトガル語版の移行制約ページ）に該当記述が見当たらず、制約が撤廃された可能性あり。試験の定番知識として本文に残し「目安」と明記した
- ストレージ：EBS Snapshots Archive「最大75%安」は確認済みだが、旧記述の「24〜72時間」の下限24時間は公式に見当たらず「最大72時間」に修正
- ストレージ：Glacier Flexible Retrieval の最小課金サイズ（本文では未記載）: 公式は40KBのメタデータ加算のみで128KB最小課金は適用外
- ストレージ：EFS「GB単価はEBS gp3より数倍高い」: 価格ページは未取得（一般に約$0.30 vs $0.08/GB月＝約3.75倍の目安）
- ストレージ：AWS Backup対応サービス一覧（VMware/Redshift/Neptune等）: 個別ページ未確認（既知の対応表に基づく）
- ストレージ：RDS自動バックアップ最大35日: 本セクションでは未確認（DBセクションで確認済みの前提）
- ストレージ：Snowmobile の終了時期: 公式ブログ（2024年11月の更新告知）にはSnowmobileの言及がなく、開発者ガイドの「Snow Family全体が新規顧客に提供されない」記述で包含されると解釈
- ストレージ：S3 Object Lock 既存バケット有効化の開始時期（2022年12月）: What's New ページはrobots制限で未取得、現行ドキュメントで「既存バケットで有効化可」のみ確認
- ストレージ：Multi-Region Access Point・S3 Express One Zone・Storage Lensのエクスポート先などの細部: 公式ページ未取得（一般知識のまま）
- データベース：RDS ストレージ上限「最大64TiB（MySQL/MariaDB/PostgreSQL/Oracle）」：公式ページでは SQL Server 16TiB と縮小不可のみ確認。Oracle/SQL Serverは追加ボリュームで最大256TiBまで拡張可との記載あり（本文は「目安」と明記）
- データベース：RDS 自動バックアップの既定7日：コンソール既定として一般的だが今回の取得ページでは既定値の明記を確認できず
- データベース：Aurora が RDS MySQL より「約20%高い」：公式数値ではなく通説（「目安」と明記）
- データベース：Aurora Global Database の「RPO約1秒・RTO1分未満」：docsでは「遅延は通常1秒未満」「低RTO/RPO」の記述のみ（「目安」と明記）
- データベース：Aurora I/O-Optimized の「I/O課金が総額の25%超なら有利」：料金ページの取得に失敗（通説どおりだが「目安」と明記）
- データベース：DynamoDB の項目400KB・BatchWriteItem 25項目/16MB・BatchGetItem 100項目/16MB・モード切替24時間に1回・LSI 10GB・PITR 35日：ServiceQuotas ページの取得結果に該当箇所が含まれず未確認（いずれも公式で広く知られた値のため本文は維持）
- データベース：Kinesis Data Streams for DynamoDB の保持最大365日：Kinesis 側の一般仕様であり今回未確認
- データベース：ElastiCache Global Datastore の「通常1秒未満」、ElastiCache Serverless の Memcached 対応：未確認（本文は維持）
- データベース：Performance Insights の CloudWatch Database Insights への統合、DynamoDB リソースベースポリシー（2024〜）：未確認（本文は維持）
- データベース：RDS Proxy の対応エンジン：マーケティングページで MySQL/PostgreSQL/MariaDB/SQL Server/Aurora を確認。docs の取得結果には Oracle も含まれていたが要約の信頼性が低いため本文には追加せず
- データベース：Multi-AZ DBクラスターの「半同期（2台中1台のACK）」：マーケティングページでは「同期レプリケーション技術」とのみ記載、docs ページは取得失敗（本文は維持）
- データベース：Neptune/DocumentDB の最大15レプリカ、Redshift RA3 Multi-AZ 対応：今回未確認（本文は維持）
- ネットワーキング・コンテンツ配信：セッションのWebFetch上限（100件/時）により、以下は今回公式ページを開いて再確認できていない（いずれも既知の標準値と一致しており本文は維持。試験直前は「目安」として扱う）：NACLルール番号1〜32766、SGはENIあたり既定5個、リージョンあたりVPC既定5個、ELB登録解除の遅延 既定300秒（0〜3600）、ALBアイドルタイムアウト既定60秒、ELB DNS TTL 60秒、Route 53ヘルスチェック間隔 既定30秒・高速10秒、複数値回答は最大8件、CloudFrontデフォルトTTL 24時間・無効化は月1,000パス無料、Global Acceleratorの静的Anycast IP×2、Flow Logs集計間隔1分/10分（既定10分）、CloudFront Functions 2021年・Network Firewall 2020年開始、Client VPNの認証方式（AD/SAML/相互証明書）
- ネットワーキング・コンテンツ配信：「NLB：毎秒数百万リクエスト」「PrivateLinkで数千VPCへ提供可」「TGW：数千VPC」は公式のマーケティング表現に基づく規模感で、厳密な上限値ではない（目安）
- ネットワーキング・コンテンツ配信：Lambda@Edgeの「ビューワー系は短いタイムアウト」（ビューワー5秒・オリジン30秒）は今回のフェッチではボディサイズ制限のみ確認できたため、数値は本文に入れず定性表現のまま
- ネットワーキング・コンテンツ配信：Accelerated Site-to-Site VPN が TGW アタッチ専用である点、および DX MACsec が専用接続のみ対応である点は今回未フェッチ（既知情報と一致）
- セキュリティ・ID・ガバナンス（分野1・配点30%）：IAMクォータ「ユーザー5,000/アカウント、アクセスキー2つ/ユーザー、グループのネスト不可」：取得したクォータページの抜粋に数値が含まれず今回は未確認（従来の公式値と一致するため本文は維持。目安として扱う）
- セキュリティ・ID・ガバナンス（分野1・配点30%）：KMSカスタマー管理キーの自動ローテ範囲「90〜2,560日」：ローテーションページの抜粋で既定365日は確認できたが範囲の数値は抜粋外。KMS APIリファレンス（RotationPeriodInDays 90〜2560）と一致するため本文維持
- セキュリティ・ID・ガバナンス（分野1・配点30%）：KMS削除待機期間「7〜30日（既定30日）」・カスタマー管理キー「月$1」：フェッチ上限により今回未確認（公式値と一致すると認識、本文維持）
- セキュリティ・ID・ガバナンス（分野1・配点30%）：Parameter Store「スタンダード4KB／アドバンスト8KB」：フェッチ上限により今回未確認（公式値と一致すると認識、本文維持）
- セキュリティ・ID・ガバナンス（分野1・配点30%）：CloudTrailイベント履歴「90日無料」、S3バケットポリシー「20KB」：フェッチ上限により今回未確認（公式値と一致すると認識、本文維持）
- セキュリティ・ID・ガバナンス（分野1・配点30%）：AWS Private CAの名称変更・WAF保護対象の全リスト（Amplifyも対象）：検索結果のタイトルで現行名称は確認したが本文ページは未取得
- セキュリティ・ID・ガバナンス（分野1・配点30%）：Security Hubは2025年に「AWS Security Hub（新）」と「Security Hub CSPM」に再編されている。SAA-C03の出題範囲では従来の「検出結果集約＋ベンチマーク」で回答してよいが、名称は流動的
- セキュリティ・ID・ガバナンス（分野1・配点30%）：ACMの紐付け先「App Runner」：App Runnerはカスタムドメインで自動的にACM証明書を使う仕様で、ELB/CloudFront/API Gatewayのようにコンソールで証明書を選んで紐付ける形ではない（試験上は問題なし）
- アプリケーション統合・分析・ストリーミング：SQS: FIFO 重複排除 ID の5分窓、Extended Client Library 最大2GB（後者は docs の quotas ページに「up to 2 GB」と記載あり。5分窓は今回の取得ページに記載なし・一般に既知）
- アプリケーション統合・分析・ストリーミング：SQS/S3: 「S3 イベント通知の宛先は標準 SQS のみ（FIFO 不可）」は S3 docs を取得できず未確認（レート制限）。既知の制約として本文に残置
- アプリケーション統合・分析・ストリーミング：SNS FIFO: 1MiB 発表文は「Standard/FIFO トピックで SQS・Data Firehose・Lambda サブスクリプションをサポート」と読める記述があり、FIFO トピックが Lambda/Firehose を直接購読可能になった可能性あり。取得した fifo-message-delivery.html は「SQS のみ・Lambda は SQS 経由」のため、本文は docs 側に合わせた（試験も SQS FIFO 経由が正解パターン）
- アプリケーション統合・分析・ストリーミング：EventBridge: Scheduler「270 超のサービス」「数百万スケジュール」、ルールスケジュールの最小1分 は未取得（目安表記）
- アプリケーション統合・分析・ストリーミング：Step Functions: 「200 超のサービスと SDK 統合」（AWS は 220 超と表現）、ペイロード上限 256KB は quotas ページ未取得（既知）
- アプリケーション統合・分析・ストリーミング：API Gateway: キャッシュ TTL 既定300秒・0〜3,600秒、ペイロード10MB、HTTP API 最大約70%安（AWS 表記は最大71%）は REST quotas ページ未取得（既知の値）
- アプリケーション統合・分析・ストリーミング：Athena: 1TB あたり 5USD は料金ページ未取得（目安）
- アプリケーション統合・分析・ストリーミング：Amazon MQ: ActiveMQ アクティブ/スタンバイ＝別 AZ＋EFS、RabbitMQ クラスター＝マルチ AZ は docs 検索でページ存在を確認したが本文未取得
- アプリケーション統合・分析・ストリーミング：Lake Formation ブループリント3種（Database snapshot／Incremental database／Log file）は docs 検索でページ存在を確認したが本文未取得
- アプリケーション統合・分析・ストリーミング：QuickSight: DynamoDB は直接データソース不可（Athena コネクタ経由）は未取得（既知）
- アプリケーション統合・分析・ストリーミング：Kinesis: シャード書込1MB/秒・1,000レコード/秒、読取2MB/秒、保持24h〜365日、拡張ファンアウト 2MB/秒・約70ms は docs で確認済み。Firehose ソースに「IoT」「CloudWatch Logs」「MSK」は未取得（既知）
- 管理・監視・移行：Snowmobile の提供終了: 公式ブログ（Snow device updates）には Snowcone・旧Snowball Edge の終了のみ記載。Snowmobile 終了は2024年4月の報道（CNBC等）ベースで公式ページの明記は未確認（AWSサイトから製品ページは削除済み）
- 管理・監視・移行：Snow blog の要約に「2025年11月以降 Snowball Edge は既存顧客のみ」との記述があったが原文で未確認。試験対策上は「現行はSnowball Edge」で問題なし
- 管理・監視・移行：X-Ray のトレース保持30日・デーモンUDP 2000: 公式ページを直接開けず未確認（広く知られた公式仕様のため本文は維持）
- 管理・監視・移行：CloudWatch Logs Infrequent Access の取込み料「半額」: 料金ページ未確認のため「目安」表記に変更
- 管理・監視・移行：AWS Health API・組織ビューが Business/Enterprise 限定: 公式ページを直接開けず未確認（本文維持）
- 管理・監視・移行：OpsWorks Stacks の提供終了（2024年5月）: 未確認だが公式発表済みの周知事項として本文維持
- 管理・監視・移行：Trusted Advisor: ドキュメント上サポートプランが「Business Support+」「Unified Operations」等に改称され、Developer/従来Businessは2027年1月1日に廃止予定と記載。SAA-C03 の設問では従来の「Business以上」の理解で解ける
- 管理・監視・移行：Managed Grafana の認証（IAM Identity Center/SAML）、Contributor Insights、CloudTrail Insights・Lake、MGN agentless、Application Discovery Agentless Collector、RAM 共有対象一覧、Service Catalog Terraform対応: 今回は fetch 予算の制約で直接確認できず（いずれも既知の公式仕様のため本文維持）
- 高可用性・DR・コスト最適化・設計原則：「C01時代（コスト10%）から倍増」：SAA-C01の配分（コスト最適化10%）は公式旧試験ガイドに基づく記憶であり今回は未確認（C02で既に20%）。
- 高可用性・DR・コスト最適化・設計原則：Aurora「レプリカが昇格先（30秒以内）」：公式FAQ/ドキュメントの「通常30秒以内」に基づくが今回フェッチ未達。目安として扱うこと。
- 高可用性・DR・コスト最適化・設計原則：RDS Multi-AZ DBインスタンスのフェイルオーバー「60〜120秒」：ドキュメントの「typically 60–120 seconds」に基づくが今回フェッチ未達（「通常」を付記済み）。
- 高可用性・DR・コスト最適化・設計原則：S3 Storage Lens「無料14日保持・高度版15か月」：ドキュメント記載に基づくが今回フェッチ未達。
- 高可用性・DR・コスト最適化・設計原則：Compute Optimizer「既定14日」・対応リソース（RDS含む）：docs/blogのタイトルで対応は確認したが本文未確認。
- 高可用性・DR・コスト最適化・設計原則：EBS Snapshots Archive「最大75%安・90日」：What's New タイトルで75%は確認、最小保持90日は本文未確認。
- 高可用性・DR・コスト最適化・設計原則：Fargate Spot「最大70%引き」、Graviton「最大40%価格性能比」、gp3「約20%安」：AWS公表値として広く知られるが今回本文未確認。
- 高可用性・DR・コスト最適化・設計原則：Route 53ヘルスチェック間隔「既定30秒・高速10秒」、EIP既定5個/リージョン、RDS停止最大7日：既知の仕様だが今回本文未確認。
- 高可用性・DR・コスト最適化・設計原則：「IRとFlexibleのストレージ単価差は約10%」：us-east-1の価格（$0.004 vs $0.0036/GB）に基づく目安。リージョンで変動。
- 高可用性・DR・コスト最適化・設計原則：Scheduled RIの提供終了：ドキュメントページの存在は確認したが本文（「現在提供していない」旨）は未確認。
- 補完：その他の頻出トピック：Client VPN クライアントCIDRの /22〜/12 という範囲（公式ドキュメントの該当箇所を取得できず。本文では「目安」と明記）
- 補完：その他の頻出トピック：Glacier Select の新規顧客向け提供終了（S3 Select の終了は公式ドキュメントで確認したが、Glacier Select のページには終了通知が見当たらず。本文は「Glacier Select＝同様」の記述を維持）
- 補完：その他の頻出トピック：EBS Snapshots Archive「約75%安」はAWS公称の「最大75%」として表記（実額は容量・リージョン依存）
- 補完：その他の頻出トピック：S3 Select「最大400%高速／80%安」はAWSの当初発表値。現在は新規提供終了のため「AWS公称」と明記
- 補完：その他の頻出トピック：EC2 recover の Dedicated Host 非対応（ドキュメント要約では明示されず、要件ページの記載として一般に知られる内容を維持）
- 補完：その他の頻出トピック：簡易自動復旧の開始時期「2022/3」（What's New ページは robots.txt により取得不可。ドキュメントでデフォルト有効は確認済み）
- 補完：その他の頻出トピック：日本語受験時の英語原文切替、ESL延長30分の事前申請制、5営業日より早い実際の結果通知時間（受験者の一般的な経験則に基づく記述で、公式確認はしていない）
- 補完：その他の頻出トピック：エッジロケーションの「試験で問われる場合の数」：試験問題は旧数値（400以上等）を前提にしている可能性があるため、本文は現行の「750以上」に更新したが、選択肢では「リージョンより多い」で判断すること
おわりに
本番で迷ったら要件語（最小運用負荷・最もコスト効率・最も安全・ダウンタイムなし）を先に拾うところから始めてください。分野別の詳細は第 2 回以降へ。同じ形式の直前チートシートを AIF-C01 でも公開しています。