この記事の位置づけ
SAA-C03 直前チートシート全 6 回の第 6 回（補完：その他の頻出トピック）です。当日戦略・早見表 200 行・シリーズ目次は 第 1 回 にあります。各トピックは「要点 → 比較表 → 引っかけ」の順で、優先度 A（毎回級）→ B（頻出）→ C（たまに）の順に読んでください。数値・仕様は改定されることがあるので、受験前に公式の試験ガイドで最終確認を。
補完：その他の頻出トピック
既存セクションに無かった20トピックを補完。冒頭2つは「試験の型」（当日戦略・公式サンプル問題）、以降は出題頻度順にA→B→C。スレッドで扱ったMGN／プレイスメントグループ／ECR／Snow Family／CloudEndure→DRSの説明と整合させている。※2024〜2026年に新規提供終了となったサービス（S3 Select・Forecast・Fraud Detector・Elastic Transcoder・Snowcone／Snowmobile・Pinpoint等）は、試験では旧知識で出題され得るため「試験の正解」と「現状」を併記。
共有責任モデル A: 毎回級
AWS＝クラウド「の」セキュリティ（物理・HW・マネージド基盤のOS）、利用者＝クラウド「内」（データ・IAM・EC2のOS・暗号化の有効化）
- AWS責任：DC物理・ハード・ネットワーク・ハイパーバイザ・リージョン／AZ、マネージドサービス基盤のパッチ（RDS／Lambda／Fargate／DynamoDB／S3のOS・ミドル）
- 利用者責任：データ分類・暗号化の有効化・鍵管理・IAM／MFA・SG／NACL・EC2のゲストOSパッチ・アプリ・ネットワーク設定・ログ有効化（CloudTrail／VPCフローログ）
- 共有（境界がサービスで動く）：パッチ管理（EC2のOS＝利用者、RDSのOS＝AWS、DBエンジン更新は利用者がウィンドウ指定）、設定管理、教育
- サービス種別で境界：IaaS（EC2）→利用者責任が広い／マネージド（RDS・EMR）→OSはAWS／サーバーレス（Lambda・S3・DynamoDB）→利用者はデータ・IAM・コードのみ
- 利用者側の道具：Inspector（EC2脆弱性）、Patch Manager、Config、GuardDuty、Trusted Advisor。AWS側の証拠はArtifactで取得
サービス種別ごとの責任分界
| 項目 | EC2 | RDS／EMR | Lambda／S3／DynamoDB |
|---|---|---|---|
| 物理・HW・ネットワーク | AWS | AWS | AWS |
| OSパッチ | 利用者 | AWS | AWS |
| エンジン／ランタイム更新 | 利用者 | AWS（利用者がウィンドウ指定） | AWS |
| アプリ・コード | 利用者 | 利用者（SQL・スキーマ） | 利用者 |
| データ・暗号化ON・IAM・SG | 利用者 | 利用者 | 利用者 |
引っかけ
- 「RDSのOSにセキュリティパッチを適用したい」→ AWSが実施（利用者はメンテナンスウィンドウ指定のみ。EC2のOSパッチと混同しない）
- 「S3のデータが暗号化されない責任はAWS」→ 利用者（暗号化・バケットポリシー・パブリックアクセスブロックは利用者の設定）
- 「EC2ゲストOSの脆弱性対応はAWS」→ 利用者（Inspector＋Patch Managerで自分で対処）
- 「物理ディスク廃棄・DC入退室の統制」→ AWS（利用者はArtifactで監査証拠を取得するだけ）
IAMポリシー条件キーの定番 A: 毎回級
バケットポリシー読解＝条件キー当て。PrincipalOrgID／SecureTransport／MultiFactorAuthPresent／SourceVpce／x-amz-server-side-encryption
- aws:PrincipalOrgID＝o-xxxx：組織内アカウントからのみ許可（アカウントID列挙不要、新規アカウントも自動対象）。OU単位は aws:PrincipalOrgPaths
- aws:SecureTransport=false を Deny：HTTPS強制（転送中暗号化）。aws:MultiFactorAuthPresent=false を Deny（BoolIfExists）：MFAなしの削除等を拒否
- aws:SourceIp：呼び出し元パブリックIPで制限（NotIpAddressでDeny）。VPCエンドポイント経由は aws:SourceVpce／aws:SourceVpc（プライベートIPなのでSourceIpは効かない）
- s3:x-amz-server-side-encryption が aws:kms 以外（またはNull=true）を Deny：暗号化なしPUT拒否。鍵指定は s3:x-amz-server-side-encryption-aws-kms-key-id
- aws:RequestedRegion：SCPで利用リージョン制限。aws:ResourceTag／aws:PrincipalTag／ec2:ResourceTag：ABAC（タグ一致で許可）
- aws:SourceArn／aws:SourceAccount：AWSサービスが代理で呼ぶときの混乱した代理対策（次項）
- 評価順（同一アカウント内）：明示Deny＞RCP（リソースコントロールポリシー）＞SCP＞リソースポリシー＞アイデンティティポリシー＞Permissions Boundary＞セッションポリシー。リソースポリシーのAllowはそれ単独で許可になり得る。同一Statement内の条件はすべてAND
条件キー→用途→典型の文言
| 条件キー | 用途 | 典型の文言 |
|---|---|---|
| aws:PrincipalOrgID | 組織内限定 | Organizations内のすべてのアカウントから |
| aws:SecureTransport | HTTPS強制 | 転送中の暗号化を必須に |
| aws:MultiFactorAuthPresent | MFA必須 | MFAなしでの削除を禁止 |
| aws:SourceIp／NotIpAddress | IP制限 | 社内の固定IPからのみ |
| aws:SourceVpce／SourceVpc | エンドポイント限定 | VPCエンドポイント経由のみ |
| s3:x-amz-server-side-encryption | 暗号化必須 | 暗号化なしのPUTを拒否 |
| aws:RequestedRegion | リージョン制限 | 東京以外での作成を禁止（SCP） |
| aws:ResourceTag／PrincipalTag | ABAC | タグが一致するリソースのみ操作可 |
引っかけ
- 「組織内の全アカウントからのみバケット共有」→ aws:PrincipalOrgID（アカウントID列挙は新規追加で漏れる）
- 「VPCエンドポイント経由以外を拒否」→ aws:SourceVpce（aws:SourceIpはVPC内からのリクエストを判定できない）
- 「暗号化されていないアップロードを拒否」→ s3:x-amz-server-side-encryption 条件でDeny（デフォルト暗号化設定は既存オブジェクトに遡及しない）
- 「HTTPを拒否」→ aws:SecureTransport=false をDeny（SSE-S3を有効化しても転送中は暗号化されない）
ExternalId／混乱した代理（Confused Deputy）対策 A: 毎回級
第三者への権限委任＝クロスアカウントロール＋sts:ExternalId。AWSサービス経由の代理呼び出しは aws:SourceArn／aws:SourceAccount で限定
- 混乱した代理：攻撃者が他社のロールARNをサードパーティSaaSに登録→SaaSが善意で他社ロールをAssumeRole→他社リソースへアクセス
- 対策＝ExternalId：サードパーティが顧客ごとに発行する識別子。ロールの信頼ポリシーに Condition StringEquals sts:ExternalId。AssumeRole時に一致しなければ拒否
- ExternalIdは秘密（パスワード）ではなく識別子。MFAの代替でもない。発行者はサードパーティ側（顧客が勝手に決めない）
- 構成：自アカウントにロール作成→信頼ポリシーのPrincipalにサードパーティのアカウントID＋ExternalId条件→権限ポリシーは最小に
- AWSサービスがリソースを呼ぶ場合（S3→SNS通知、CloudTrail→S3、Config→S3）：リソースポリシーに aws:SourceArn／aws:SourceAccount で自分のリソース発の呼び出しに限定
- STS一時認証情報：AssumeRole 15分〜最大12時間（ロール設定）、ロールチェーンは1時間上限。IAMユーザーの長期アクセスキー共有は常に不正解
引っかけ
- 「監視SaaSに自アカウントのCloudWatch読み取りを許可」→ クロスアカウントロール＋ExternalId（IAMユーザーを作ってアクセスキーを渡すのは長期キー流出リスクで不正解）
- 「S3イベント通知先SNSトピックのポリシーを安全に」→ aws:SourceArn（バケットARN）＋aws:SourceAccount（Principalがs3.amazonaws.comだけだと他人のバケットからも発行可）
- 「ExternalIdを設定すれば権限は気にしなくてよい」→ 誤（ExternalIdは誰のためのAssumeRoleかの識別。権限はロールのポリシーで最小化）
EC2ステータスチェックと自動復旧（recover／reboot） A: 毎回級
システムチェック失敗（AWS側HW）→recover（ID・IP・EBS維持）、インスタンスチェック失敗（OS側）→reboot。ASGの置換は新IP・状態喪失
- システムステータスチェック（StatusCheckFailed_System）：ホストHW・電源・NW・ハイパーバイザの障害。対処＝停止→起動で別ホストへ、またはCloudWatchアラームの復旧（recover）アクション
- インスタンスステータスチェック（StatusCheckFailed_Instance）：ゲストOS側（NW設定ミス、メモリ枯渇、カーネルパニック、FS破損）。対処＝再起動・OS修正、アラームの再起動（reboot）アクション。※2024〜「アタッチ済みEBSステータスチェック（StatusCheckFailed_AttachedEBS）」も追加
- recoverで保持：インスタンスID、プライベート／パブリックIP、EIP、EBS、メタデータ、プレイスメントグループ、AZ。失う：インスタンスストアのデータ、メモリ（OS稼働時間もリセット）
- recoverの条件：EBS-backedのみ（起動時にインスタンスストアを付けたものは簡易自動復旧の対象外）、対応インスタンスタイプ、メタル・Dedicated Hostは対象外。2022/3〜「簡易自動復旧」がデフォルト有効（アラーム不要）。復旧はシステムチェック失敗時のみ動作（インスタンスチェック失敗では動かない）
- アラームのEC2アクション4種：recover／reboot／stop／terminate。recoverは StatusCheckFailed_System のアラームにのみ設定可（stop／terminate はCPU使用率などインスタンス単位メトリクスにも設定可）
- ASGのヘルスチェック：既定はEC2ステータス。アプリ層の異常も置換対象にするなら HealthCheckType=ELB＋猶予期間（HealthCheckGracePeriod）
2種類のステータスチェック
| システムチェック失敗 | インスタンスチェック失敗 | |
|---|---|---|
| 原因 | AWS側：ホストHW・電源・NW・ハイパーバイザ | 利用者側：OS設定ミス・メモリ枯渇・カーネル・FS |
| 対処 | 停止→起動（別ホスト）／recover | 再起動／OS修正／reboot |
| アラームアクション | recover | reboot |
| 保持されるもの | ID・IP・EIP・EBS（インスタンスストアは消失） | すべて維持（再起動のため） |
引っかけ
- 「ハード障害時に同じプライベートIP・同じEBSで自動復旧、運用負荷最小」→ CloudWatchアラームのrecoverアクション（ASGは新インスタンス＝新IP、ローカル状態は失われる）
- 「OSがハングして応答なし（インスタンスチェック失敗）」→ rebootアクション（recoverはシステムチェック失敗用でOS障害には効かない）
- 「インスタンスストアのデータも復旧後に残る」→ 誤（インスタンスストアはホスト依存、別ホストでの復旧＝消える）
- 「ALBが503を返してもASGが置換しない」→ ASGのヘルスチェックタイプをELBに（EC2チェックだけではアプリ異常を検知しない）
機械学習・メディア系マネージドサービスの用途マッチング A: 毎回級
文書の表→Textract、音声→文字→感情＝Transcribe→Comprehend、社内文書検索→Kendra。運用負荷最小ならSageMaker自作は不正解
- 画像／動画：Rekognition＝物体・顔検出／顔比較・有名人・不適切コンテンツ検出（モデレーション）・画像内の短い文字。Custom Labelsで独自分類
- 文書：Textract＝スキャン／PDFから文字・フォーム（キー：値）・表を構造化抽出（OCR＋レイアウト）。請求書・領収書・身分証の専用API
- テキスト（NLP）：Comprehend＝感情・エンティティ・キーフレーズ・言語判定・PII検出／マスク・トピック。Comprehend Medical＝医療用語・PHI
- 音声：Transcribe＝音声→テキスト（話者識別・カスタム語彙・PII削除・リアルタイム）。Polly＝テキスト→音声（SSML・Neural）。Translate＝翻訳（カスタム用語）
- 対話：Lex＝チャット／音声ボット（インテント・スロット、Alexaと同技術、Connectと統合）。Connect＝クラウドコンタクトセンター
- 検索・推薦・予測：Kendra＝企業内文書のML検索（自然言語の質問に回答、S3／SharePoint等コネクタ、アクセス権反映）。Personalize＝リアルタイムレコメンド。Forecast＝時系列予測（※新規顧客向け提供終了、試験では「時系列予測＝Forecast」で可）。Fraud Detector＝不正検知（※2025/11〜新規顧客向け提供終了、代替はSageMaker）
- 自作：SageMaker＝モデルの構築・学習・デプロイ（Ground Truth＝ラベリング、Canvas＝ノーコード、JumpStart）。Bedrock＝基盤モデルAPI（生成AI、出題は少）。A2I＝人によるレビュー
- メディア：MediaConvert＝ファイル動画の形式・解像度変換（旧Elastic Transcoderは2025/11/13サポート終了→MediaConvertへ移行）。MediaLive＝ライブエンコード、MediaPackage＝配信パッケージ。Kinesis Video Streams＝カメラ映像取込→Rekognition Video
キーワード→サービス即答表
| 問題文のキーワード | サービス |
|---|---|
| 画像の物体・顔・不適切コンテンツ | Rekognition |
| 文書からフォーム・表を抽出 | Textract |
| 感情分析・PII検出・キーフレーズ | Comprehend |
| 音声→テキスト（文字起こし） | Transcribe |
| テキスト→音声 | Polly |
| 多言語翻訳 | Translate |
| チャットボット・音声ボット | Lex |
| 社内文書のインテリジェント検索 | Kendra |
| レコメンデーション | Personalize |
| 時系列予測（需要・売上） | Forecast（新規提供終了、試験知識として） |
| 独自モデルの学習・デプロイ | SageMaker |
| 生成AI基盤モデルAPI | Bedrock |
| 動画ファイルの変換 | MediaConvert（Elastic Transcoderは2025/11終了） |
| カメラ映像の取込・保存・分析 | Kinesis Video Streams |
引っかけ
- 「コールセンター録音から顧客感情を分析」→ Transcribe→Comprehend（Comprehend単体は音声を読めない、Lexは対話用）
- 「請求書PDFの表・項目を抽出してDBへ」→ Textract（RekognitionのDetectTextは看板等の短文、表構造は取れない）
- 「社内のPDF・Wikiに自然言語で質問して回答」→ Kendra（OpenSearchはキーワード全文検索／ログ分析、Kendraは意味検索）
- 「ECサイトのおすすめを数週間で、運用負荷最小」→ Personalize（SageMakerで自作は期間・運用負荷で不正解）
Outposts／Local Zones／Wavelength とグローバルインフラ A: 毎回級
自社DC内に置く規制→Outposts、特定都市で1桁ms→Local Zones、5G端末→Wavelength、ネットワークの無い現場→Snowball Edge（試験知識。2025/11〜新規顧客は不可）
- リージョン＝複数AZ（通常3以上）、AZ＝1つ以上のDC群（独立電源・NW、AZ間は低遅延専用線）、エッジロケーション＝CloudFront／Route 53／Global Accelerator／Shield のPOP（750以上、100以上の都市。リージョンより桁違いに多い）＋リージョナルエッジキャッシュ15
- Local Zones：リージョンの拡張を大都市近郊に配置。VPCのサブネットを延伸してEC2／EBS／ECS／EKS／ALBをローカルで実行。1桁msレイテンシ（ゲーム、リアルタイム制作、ライブ）。親リージョンでオプトイン
- Wavelength：通信事業者の5G網内（KDDI、Verizon等）にAWSコンピュート。Wavelength Zone＝VPCのサブネット。モバイル端末から超低遅延（AR／VR、コネクテッドカー、ライブ配信）。2025年も新ゾーン追加中
- Outposts：AWSのラック（42U）／サーバー（1U・2U）を自社DCに設置、AWSが管理・保守。ラックはEC2／EBS／S3 on Outposts／RDS／ElastiCache／ECS／EKS／EMR／ALB、サーバーはEC2／ECS等の小規模用途。親リージョンとの常時接続（サービスリンク）必須。3年契約（全額／一部／前払いなし）
- 用途の軸：Outposts＝データレジデンシー・既存オンプレ機器との超低遅延／Local Zones＝地理的に近い一般ユーザー／Wavelength＝携帯回線ユーザー／Snowball Edge Compute Optimized＝ネットワークが無い・断続的な現場（スレッド既出）。※現状：Snowcone・Snowmobile・旧Snowball Edgeモデルは提供終了、Snowball Edge（210TB／104vCPU）は2025/11/7以降既存顧客のみ。新規はDataSync／Data Transfer Terminal／Outposts
- Global Accelerator：エニーキャスト固定IP2つでAWSバックボーンへ（TCP／UDP、リージョン間フェイルオーバー）。CloudFront＝HTTPキャッシュ配信。どちらもエッジロケーション利用
エッジ4兄弟の比較
| Outposts | Local Zones | Wavelength | Snowball Edge | |
|---|---|---|---|---|
| 場所 | 自社DC内 | AWS施設（都市近郊） | 通信事業者の5G網内 | 現場（可搬） |
| 目的 | データ主権・既存機器と超低遅延 | 都市ユーザーへ1桁ms | モバイル端末へ超低遅延 | オフライン転送・切断環境処理 |
| 接続 | 親リージョン常時接続必須 | 親リージョンのVPC延伸 | 親リージョンのVPC延伸 | 接続不要 |
| 課金 | 3年契約（HW） | 従量 | 従量 | デバイス日額・ジョブ（新規顧客は不可） |
引っかけ
- 「規制でデータを自社DCから出せないが、AWSのAPI・ツールで運用したい」→ Outposts（Direct Connectは回線だけ、Local ZonesはAWS施設）
- 「特定都市のユーザーへ1桁msでゲーム／レンダリング」→ Local Zones（CloudFrontはキャッシュ配信でコンピュートは近づかない、リージョン追加は数十ms）
- 「5Gスマホ向けAR／自動運転の超低遅延処理」→ Wavelength（Local Zonesは有線・一般インターネット経由）
- 「通信インフラの無い鉱山・船舶でローカル処理」→ Snowball Edge Compute Optimized（Outpostsはリージョン接続が必須。試験ではSnowball Edgeが正解、Snowconeは提供終了済み）
AWS Elastic Disaster Recovery（DRS） A: 毎回級
旧CloudEndure DR。エージェントで継続ブロックレプリケーション→低コストのステージング→数分でフルEC2起動（RPO秒／RTO分）。MGN＝一回限りの移行
- 対象：オンプレ物理／仮想サーバー、他クラウド、他リージョン・他AZのEC2。AWS Replication Agentをインストールして継続的ブロックレベルレプリケーション（MGNと同じ技術基盤、スレッド既出）
- ステージングエリア：小さなレプリケーションサーバー＋EBSだけで待機＝本番サイズの費用不要（Pilot Light並みのコストでWarm Standby級のRTO）
- 復旧：フェイルオーバー時にフルサイズEC2を数分で起動。ポイントインタイム復旧（ランサムウェア感染前の時点へ）、非破壊のDRドリル、フェイルバック対応
- 数値：RPO＝秒単位、RTO＝分単位。CloudEndure DRの後継（2021）
- MGNとの違い：MGN＝移行（カットオーバー後にレプリケーション終了）／DRS＝DR（レプリケーションを継続、何度でも復旧）
- DR戦略との対応：Backup&Restore（AWS Backup／スナップショット、RPO・RTO時間）→Pilot Light（DBのみ複製）→Warm Standby（縮小版常時稼働）→Multi-Site（RPO≈0）。DRSはPilot Lightのコストで分単位RTO
- DB単体のDR：Aurora Global Database（RPO 1秒・RTO 1分未満）、RDSクロスリージョンリードレプリカ、DynamoDB Global Tables、S3 CRR＋RTC（15分）
引っかけ
- 「オンプレ物理サーバーをAWSにDR、RPO秒・RTO分・平常時コスト最小」→ DRS（AWS Backupはスナップショット間隔＝RPO時間、Storage Gatewayはデータのみでサーバーは起動できない）
- 「サーバーを一度だけAWSへ移してオンプレを廃止」→ MGN（DRSは継続レプリケーション前提で移行用途ではない）
- 「EC2を別リージョンへ数分で復旧、平常時に本番サイズは起動したくない」→ DRSクロスリージョン（Warm Standbyは縮小版でも常時稼働費用が発生）
- 「Auroraのリージョン障害対策でRTO分単位」→ Aurora Global Database（DRSはサーバー単位、マネージドDB基盤には使わない）
AWS Client VPN と VPN CloudHub A: 毎回級
個人PC→VPC＝Client VPN（OpenVPN、証明書／AD／SAML認証）。拠点→VPC＝Site-to-Site VPN。複数拠点間をAWS経由で結ぶ＝CloudHub
- Client VPN：マネージドOpenVPNエンドポイント。リモートユーザーのPC／スマホ→VPC（さらにピアVPC・オンプレ・インターネットへもルート可）。TLS、フルマネージド、自動スケール
- 認証3種：相互認証（ACMのクライアント証明書）／AD認証（Directory Service・AD Connector）／SAML 2.0フェデレーション（IAM Identity Center・Okta等）。MFA対応。認可ルールでADグループ別に到達先を制限
- 設定値：クライアントCIDRは /22〜/12（目安）でVPC・オンプレと重複不可、作成後は変更不可。エンドポイントをサブネットに関連付け、SGを適用、ルートテーブルで到達先定義。スプリットトンネル＝VPC宛だけVPN経由
- Site-to-Site VPN：VGW（またはTGW）↔カスタマーゲートウェイ、IPsec、トンネル2本（冗長）、標準トンネルは1本あたり最大1.25Gbps（大帯域トンネルは最大5Gbps。TGW＋ECMPで束ねる）、静的／BGP
- VPN CloudHub：1つのVGWに複数拠点のCGWを接続（各拠点は別ASNでBGP）→拠点同士がAWS経由で通信（ハブ&スポーク）。拠点間に専用線が無い場合の低コスト構成。大規模・複数VPCならTransit Gateway
- Direct Connect：専用線（1／10／100／400Gbps、ホスト接続50Mbps〜25Gbps）、暗号化なし→DX上でVPN、DX Gatewayで複数リージョンのVPCへ。LAG／複数ロケーションで冗長
- 課金：Client VPNはエンドポイント関連付け時間＋接続時間。S2S VPNは接続時間＋データ転送
接続方式の比較
| Client VPN | Site-to-Site VPN | CloudHub | Direct Connect | |
|---|---|---|---|---|
| 接続元 | 個人のPC／端末 | 拠点ネットワーク（CGW） | 複数拠点（CGW×N） | 拠点（専用線） |
| プロトコル | OpenVPN／TLS | IPsec（2トンネル） | IPsec＋BGP | 専用線（暗号化なし） |
| 認証 | 証明書／AD／SAML | 事前共有鍵・証明書 | BGP ASN（拠点ごと） | — |
| 帯域 | 端末次第 | 1.25Gbps/トンネル（大帯域は5Gbps） | 同左 | 1〜400Gbps 安定 |
引っかけ
- 「在宅勤務者がノートPCからVPC内のアプリへ安全に接続」→ Client VPN（Site-to-Site VPNは拠点ルーター（CGW）前提、個人PCは不可）
- 「既存のAD／IdPでVPN利用者を管理、退職者を即失効」→ Client VPNのAD／SAML認証（証明書配布のみだと失効管理が手間）
- 「複数支社が互いに通信、支社間に回線なし、低コスト」→ VPN CloudHub（拠点はVPCピアリング不可、DXは高コスト）
- 「DXの通信を暗号化」→ DX上にSite-to-Site VPN（DXは暗号化されない、MACsecは10G／100G／400G専用線の一部ロケーションのみ）
IAM Access Analyzer と IAM Credential Report B: 頻出
外部から到達可能なS3／ロール／KMS等を継続検出＝Access Analyzer、全ユーザーの鍵・MFA・最終使用の棚卸＝Credential Report
- Access Analyzer（外部アクセス）：信頼ゾーン（アカウントまたはOrganizations）の外の主体からアクセス可能なリソースを検出。対象：S3、IAMロール、KMSキー、Lambda、SQS、Secrets Manager、SNS、EBS／RDSスナップショット、ECR、EFS、DynamoDB等。無料・継続監視、Security Hub／EventBridgeへ通知
- Access Analyzer（未使用アクセス、有料）：未使用のロール・アクセスキー・パスワード・権限を日数指定で検出→最小権限へ
- ポリシー検証：作成時の文法・セキュリティ警告。ポリシー生成：CloudTrailの実アクセスから最小権限ポリシーを自動生成。カスタムポリシーチェック：パブリックアクセスを許すかを事前検証
- Credential Report：アカウント内全IAMユーザーの認証情報CSV（パスワード有効／最終使用、アクセスキー1・2の作成日／最終使用／ローテーション、MFA有効）。4時間ごとに生成可。監査・未使用キー削除に
- Access Advisor（最終アクセス情報）：ユーザー／ロールが最後に使ったサービスと日時→不要なサービス権限を削除
- Trusted Advisorのセキュリティ：ルートMFA、公開されたアクセスキー、S3バケットの公開権限、SGの無制限ポート。フル機能はBusinessサポート以上
引っかけ
- 「他アカウント／インターネットから読める設定のS3・KMS・ロールを継続検出」→ IAM Access Analyzer（Macieは中身の機密データ、GuardDutyは脅威ログ分析、Inspectorは脆弱性）
- 「90日以上使われていないアクセスキーを洗い出す」→ Credential Report（またはAccess Analyzerの未使用アクセス。CloudTrail全件検索は非効率）
- 「実際に使った権限だけにロールを絞る」→ Access Analyzerのポリシー生成／Access Advisor（Trusted Advisorは権限内容を見ない）
AWS Artifact と Audit Manager B: 頻出
AWS側の第三者監査レポート（SOC／PCI／ISO）を取得＝Artifact、自社利用の監査証拠を自動収集・評価＝Audit Manager
- AWS Artifact：SOC 1／2／3、PCI DSS AOC、ISO 27001／27017／27018、FedRAMP、HIPAA等のAWS側コンプライアンスレポートをセルフサービスでダウンロード。無料。契約（BAA、NDA、GDPR DPA）の締結・管理も
- Audit Manager：Config・CloudTrail・Security Hub・IAM等から証拠を継続自動収集し、フレームワーク（PCI DSS、SOC 2、HIPAA、GDPR、CIS、NIST）に対応した評価レポートを作成。カスタムフレームワーク可。Organizations横断
- 使い分け：Artifact＝AWSが監査を受けた証拠（共有責任のAWS側）／Audit Manager＝自社の設定・運用が準拠している証拠（利用者側）
- 隣接：Config＝設定ルール準拠と履歴（Conformance Pack）、Security Hub＝セキュリティ標準（CIS・PCI・AWS基礎）チェックの集約、Trusted Advisor＝ベストプラクティス
引っかけ
- 「監査人にAWSのSOC 2レポートを提出」→ AWS Artifact（Audit Managerは自社側の証拠、Configはリソース設定）
- 「PCI監査向けに自社のAWS利用証拠を継続収集し工数削減」→ Audit Manager（Artifactは静的レポートの取得のみ）
- 「HIPAA対応のためBAAを締結」→ Artifact Agreements（サポートケースではない）
Service Quotas（DR先リージョンの上限事前引上げ） B: 頻出
クォータはアカウント×リージョン単位。スタンバイリージョンは事前に引上げ、AMI／スナップショット／KMSキー／EIPはリージョン固有でコピーが必要
- 旧「サービス制限」。Service Quotasコンソールで一覧・引上げ申請・使用率アラーム（CloudWatch）。調整可能（大半）と固定（IGW 1／VPC等）がある
- 代表値：EC2オンデマンドはvCPUベース上限（新規アカウントは小さい）、EIP 5／リージョン、VPC 5／リージョン、Lambda同時実行 1,000／リージョン（新規は少）、IAMロール 1,000／アカウント（引上げ可）、SG 5／ENI・ルール60／SG、S3汎用バケット 10,000／アカウント（2024/11に100→10,000へ引上げ、さらに申請可）
- Organizations連携：クォータリクエストテンプレートで新規アカウントに自動適用。Trusted Advisor「サービス制限」チェックは使用率80%超を警告
- DR・マルチリージョン：スタンバイ側のクォータは別カウント→DR演習前に引上げ。リージョン固有で複製が必要＝AMI（コピー）、EBSスナップショット（コピー）、KMSキー（マルチリージョンキー）、ACM証明書（再発行）、Parameter Store／Secrets（レプリケーション）、EIP
- グローバル：IAM、Route 53、CloudFront、Organizations、WAF（CloudFront用）
引っかけ
- 「DR時にスタンバイリージョンでASGがスケールアウトできない」→ 事前にService Quotasで引上げ（Savings Plansは上限を上げない。キャパシティ予約は上限内で容量確保するだけ）
- 「暗号化AMIを別リージョンで起動」→ AMIをコピー＋コピー先リージョンのKMSキーで再暗号化（AMI・スナップショットはリージョン固有）
- 「上限に近づいたら通知」→ Service Quotasのアラーム／Trusted Advisor（Cost Explorerは無関係）
Amazon SES と SNS Email の区別 B: 頻出
顧客への大量／トランザクションメール＝SES、運用アラームの通知メール＝SNS。SMSはSNS（またはEnd User Messaging）、メール受信処理はSES
- SES：送受信のメールサービス。SMTPインターフェース／API、テンプレート、バウンス・苦情の通知、DKIM／SPF／DMARC、専用IP、送信統計。サンドボックス（検証済み宛先のみ・200通／24時間）→本番アクセス申請
- SES受信：受信ルールでS3保存／Lambda起動／SNS通知（メール添付をS3へ、自動処理）
- SNS Email：トピック購読者へのプレーンテキスト通知。購読者の確認（confirm）必須、HTML不可、差出人カスタマイズ不可。運用通知（CloudWatchアラーム）向け
- SNS：A2A（SQS／Lambda／HTTP／Firehose）＋A2P（SMS／Email／モバイルPush）。FIFOトピック（→SQS FIFO、順序保証）、メッセージフィルタリング
- Pinpoint：マーケティングキャンペーン（セグメント・分析、マルチチャネル）。※2025/5/20新規受付終了・2026/10/30サポート終了。後継＝Amazon Connectアウトバウンドキャンペーン、SMS／Push／OTPはAWS End User Messaging、メールはSES。WorkMail：企業向けメールボックス（※2026/4/30新規受付終了・2027/3/31サポート終了）
引っかけ
- 「注文確認・パスワードリセットのメールを数百万ユーザーへ」→ SES（SNSは購読確認が必要、HTML・差出人カスタマイズ不可）
- 「CloudWatchアラームを運用チームにメール」→ SNS（アラームアクションはSNSトピック、SESは通知サービスではない）
- 「顧客からのメールを受信して添付をS3に保存」→ SES受信ルール（SNSはメールを受信できない）
- 「SMSで通知」→ SNS（SESはメール専用。大規模SMS／OTPは現行 AWS End User Messaging）
Managed Service for Apache Flink（旧Kinesis Data Analytics）と Kinesis Video Streams B: 頻出
ストリームへのSQL／Flinkでリアルタイム集計・異常検知＝Managed Flink、カメラ映像の取込＝Kinesis Video Streams→Rekognition Video
- Managed Service for Apache Flink：Kinesis Data Streams／MSK／Amazon Data Firehose（旧Kinesis Data Firehose、2024/2改称）からのストリームをリアルタイム処理（ウィンドウ集計、結合、異常検知、ETL）。出力→Data Streams／Firehose／S3／OpenSearch／DynamoDB／Lambda。サーバーレス（KPU課金、自動スケール）。Studioノートブックで対話型SQL／Python
- 旧名：Kinesis Data Analytics（for Apache Flink）。SQLアプリ版は終了（2025/10/15新規作成停止、2026/1/27に削除・終了）。問題文で「Kinesis Data Analytics」と出たら同じものと読む
- Kinesis Video Streams：カメラ・デバイスからの動画／音声／レーダーを取込・保存（保持期間指定）・再生（HLS／DASH）。Rekognition Video／SageMakerと連携し顔・物体検出。WebRTCで双方向低遅延（見守り・インターホン）
- 使い分け：Data Streams＝生ストリーム取込（順序・複数コンシューマ・拡張ファンアウト、最大365日）／Firehose＝配信＋簡易変換（Lambda）／Managed Flink＝ストリーム上の計算／MSK＝Kafka互換／KVS＝映像
- 隣接：Athena＝S3のバッチSQL、EMR Spark Streaming＝自前運用（運用負荷大）
引っかけ
- 「IoTセンサーのストリームを1分ウィンドウで集計し閾値超えを即通知」→ Managed Flink（Firehoseは変換のみで集計不可、Athenaはバッチ）
- 「防犯カメラ映像をリアルタイムで顔認識」→ Kinesis Video Streams＋Rekognition Video（Data Streamsは1レコード1MB、映像に不向き）
- 「既存のFlink／Kafkaアプリを運用負荷最小で」→ Managed Flink＋MSK（EMRで自前運用は不正解）
- 「Kinesis Data AnalyticsでSQL」→ 現名Managed Service for Apache Flink（SQLアプリは2026/1終了、Flink SQL／Studioで代替）
拡張ネットワーキング（ENA）／EFA B: 頻出
ENA＝拡張ネットワーキング（最大100Gbps、現行世代は標準）、EFA＝ENA＋OSバイパスでHPC／ML分散学習（クラスタープレイスメントと併用）
- ENA（Elastic Network Adapter）：SR-IOVで高PPS・低レイテンシ・低ジッタ、最大100Gbps（一部400Gbps以上）。現行世代AMIは標準有効、追加料金なし。旧Intel VF（82599）は10Gbps
- EFA（Elastic Fabric Adapter）：ENAの機能＋OSバイパス（libfabric）でMPI／NCCLのノード間通信を高速化。HPC（CFD、気象）、ML分散学習（p4d／p5、trn1）。追加料金なし
- EFAの制約：Linux中心（WindowsはCDI用途のみ）、対応インスタンスタイプ、OSバイパス通信はAZ・VPCをまたげない（同一サブネット推奨）、SGは自身へのin／out全許可が必要、Outposts不可。クラスタープレイスメントグループで最短距離に配置
- ENI：通常の仮想NIC。プライベートIP／EIP／MAC／SGを持ち別インスタンスへ付け替え可（AZ固定）。MAC固定ライセンス・フェイルオーバー用
- 帯域はインスタンスサイズに比例、「up to」はバースト値。ボトルネックがCPU／ディスクならネットワーク強化は無意味
- プレイスメント復習（スレッド既出）：Cluster＝近接・低遅延（単一AZ）、Spread＝分散（AZあたり7台）、Partition＝ラック群（Kafka／HDFS、AZあたり7パーティション）
引っかけ
- 「HPC／MPIでノード間レイテンシ最小」→ クラスタープレイスメント＋EFA対応インスタンス（Spreadは離す設計、ENAだけではOSバイパスなし）
- 「アプリのCPU使用率100%で遅い」→ インスタンスタイプ変更（拡張ネットワーキング有効化は原因が違うので効果なし）
- 「複数AZにまたがるHPCクラスタ」→ 不可（EFA／クラスタープレイスメントは単一AZ）
- 「MACアドレス紐付きライセンスの迅速な引継ぎ」→ セカンダリENIをスタンバイへ付け替え（AMI再作成はMACが変わる）
Amazon Data Lifecycle Manager（DLM） B: 頻出
EBSスナップショット／AMIの作成・保持・削除・コピーをタグ＋スケジュールで自動化（無料）。EBS専用、RDS等も含むならAWS Backup
- DLM：ポリシー（対象タグ、間隔、保持数／期間、クロスリージョン／クロスアカウントコピー、Fast Snapshot Restore）でEBSスナップショットとEBS-backed AMIを自動管理。追加料金なし（スナップショット保存料のみ）
- 対象はEBSボリューム・EC2インスタンス（AMI）のみ。RDS／DynamoDB／EFS／FSx／S3等は対象外
- AWS Backup：EBS／EC2／RDS／Aurora／DynamoDB／EFS／FSx／S3／Storage Gateway／Redshift／DocumentDB／Neptune／VMwareを一元管理。バックアッププラン・ボールト・Vault Lock（WORM、スレッド既出）・クロスアカウント／リージョン・Organizations一括
- EBSスナップショット：増分・S3に保存、暗号化ボリュームのスナップショットは暗号化、未暗号化→コピー時に暗号化可。AWS管理キー暗号化は他アカウントに共有不可→CMKで再暗号化。Snapshots Archive（最低90日、最大75%安、復元は最大72時間）。Recycle Bin（誤削除保護）
- スナップショットからの初回読み込みは遅い（レイジーロード）→ Fast Snapshot Restoreで即フル性能
引っかけ
- 「EBSだけを毎日スナップショット、7世代保持、最小コスト」→ DLM（AWS Backupでも可だが「EBSのみ・簡易」ならDLM）
- 「DLMでRDSもバックアップ」→ 誤（DLMはEBS／AMI専用。複数サービス横断はAWS Backup）
- 「規制でバックアップの改ざん・削除を不可に」→ AWS Backup Vault Lockコンプライアンスモード（DLMにWORMなし）
- 「スナップショットの誤削除を防ぐ」→ Recycle Bin（保持ルール）
S3 Select／Glacier Select／S3 Batch Operations／S3 Inventory B: 頻出
1オブジェクト内をSQLで絞る＝S3 Select（※新規顧客向け提供終了、試験知識として）、数十億オブジェクトの一括処理＝Batch Operations、全オブジェクトの一覧レポート＝Inventory
- S3 Select：CSV／JSON／Parquet（GZIP／BZIP2可）の1オブジェクトに対しSQLで行・列を絞って取得→転送量・クライアント処理を削減（AWS公称：最大400%高速／80%安）。Glacier Select＝Flexible Retrievalのアーカイブに同様（取り出しジョブとして）。※S3 Selectは2024/7以降新規顧客に提供終了（既存顧客は継続可）。現行の代替＝Athena／S3 Object Lambda。試験の選択肢に出たら従来どおり「1オブジェクト内の絞り込み」で解く
- 複数オブジェクト横断・結合・集計→Athena。S3 Selectは「1オブジェクトの一部だけ」
- Batch Operations：マニフェスト（S3 InventoryレポートまたはCSV）に対して一括でコピー／タグ置換／ACL／Object Lock保持／Glacier復元／Lambda呼び出し（任意処理）。完了レポート、IAMロールで実行。既存オブジェクトの暗号化変更（コピー→SSE-KMS）の定番
- S3 Inventory：バケット（プレフィックス）内の全オブジェクトとメタデータ（サイズ、暗号化状態、ストレージクラス、レプリケーション状態、Object Lock）を日次／週次でCSV／ORC／Parquet出力。LIST APIより安く、Athenaで分析・Batch Opsの入力に
- 隣接（スレッド既出）：Storage Lens＝組織・バケット単位の集計ダッシュボード（可視化のみ）、Storage Class Analysis＝アクセス頻度からIA移行を推奨、Object Lambda＝GET時に加工
引っかけ
- 「巨大CSVから条件に合う行だけ取得して転送量を減らす」→ S3 Select（Athenaは複数オブジェクトの分析用、EC2で全件取得は無駄）
- 「既存の全オブジェクト（数億件）をSSE-KMSに再暗号化・タグ付け」→ Batch Operations（デフォルト暗号化設定は新規のみ、Lambdaで1件ずつは非効率）
- 「暗号化されていないオブジェクトの一覧を定期取得」→ S3 Inventory（Storage Lensはバケット単位の集計で個別オブジェクトは出ない）
- 「Glacierアーカイブ内のCSVから一部だけ」→ Glacier Select（Athenaは直接Glacierを読めない）
Amazon ECR と App Runner B: 頻出
ECR＝コンテナレジストリ（拡張スキャン＝Inspector、ライフサイクルポリシー、クロスリージョンレプリケーション）。App Runner＝コンテナWebアプリを最小設定で公開
- ECR：プライベート／パブリック（ECR Public Gallery）レジストリ。IAM認証（12時間トークン）、保存時KMS暗号化、イメージタグ不変性（上書き防止）
- スキャン：基本（プッシュ時／手動、OSパッケージ）／拡張（Inspector連携、OS＋言語パッケージ、継続的・自動再スキャン）
- ライフサイクルポリシー：古い／タグなしイメージを自動削除→ストレージコスト削減。レプリケーション：クロスリージョン／クロスアカウントで自動複製（マルチリージョン展開・DR）
- プライベートpull：VPCエンドポイント（ecr.api、ecr.dkr）＋S3ゲートウェイエンドポイント（レイヤーはS3）→NAT不要。プルスルーキャッシュでDocker Hub等を経由キャッシュ
- ECSのロール：タスク実行ロール＝エージェントがECRからpull・CloudWatch Logsへ書込・Secrets取得／タスクロール＝コンテナ内アプリがAWS APIを呼ぶ権限
- App Runner：ソースリポジトリまたはECRイメージからビルド・デプロイ・HTTPS・ロードバランス・自動スケール（同時リクエスト基準）まで全自動。VPCコネクタでRDS等プライベートリソースへ。ECS／EKS／ALBの設計不要＝最小運用負荷
引っかけ
- 「FargateタスクがECRからイメージをpullできない」→ タスク実行ロールの権限（ecr:GetAuthorizationToken等）、またはプライベートサブネットならNAT／VPCエンドポイント（タスクロールではない）
- 「コンテナイメージの脆弱性を継続的に検出」→ ECR拡張スキャン（Inspector）（GuardDutyはランタイム脅威、Macieはデータ）
- 「レジストリ容量・コストが増え続ける」→ ライフサイクルポリシー（手動削除は運用負荷）
- 「コンテナ化したAPIを最小の設定・運用で公開、スケール自動」→ App Runner（EKS／ECS＋ALBは設計・運用が重い）
VMware Cloud on AWS C: たまに
vSphere／vSAN／NSXをAWSベアメタル上でそのまま運用＝7Rの「Relocate」。VMを変換せず移行。EC2化するならMGN
- VMware（Broadcom）が提供・運用するSDDCをAWSベアメタル（i3／i4i）上で稼働。既存のvSphere VMをHCX／vMotionで変換なし・ツール・スキルそのままで移行（Relocate）。※2024/5以降はBroadcomからの直接購入のみ（AWSによる再販は終了）、試験の知識はそのまま有効
- 用途：DC撤去・契約満了の短期移行、VMware Site RecoveryによるDR、季節需要のキャパシティ拡張。S3／RDS／DX／ELBなどAWSサービスとネイティブ連携
- 7R対応：Rehost＝MGN（VM→EC2、スレッド既出）／Relocate＝VMware Cloud on AWS／Replatform（例：DB→RDS）／Repurchase（SaaS）／Refactor／Retain／Retire
- 移行ツール：Application Discovery Service（エージェント／VMware向けエージェントレスコレクター）→Migration Hubで進捗集約→MGN／DMS／DataSync
- 対比：Outposts＝オンプレにAWS／VMware Cloud on AWS＝AWSにVMware。AWS BackupはオンプレVMware VMのバックアップにも対応
引っかけ
- 「vSphere環境を変更せず、既存の運用ツール・スキルを維持してAWSへ」→ VMware Cloud on AWS（MGNはEC2に変換しvCenter管理から外れる）
- 「VMwareのVMをAWSネイティブ（EC2）にリフト&シフト」→ MGN（VMware Cloud on AWSはVMwareのまま）
- 「オンプレVMware VMのバックアップをAWSに」→ AWS Backup（VMware対応）またはStorage Gateway（DRSは復旧用）
おわりに
前の回: 第5回
早見表と他の回への目次は 第 1 回 にまとめています。