【SAA-C03】直前チートシート (4/6) セキュリティ・アプリケーション統合・分析

この記事の位置づけ

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

セキュリティ・ID・ガバナンス

最大配点の分野。読み方：①IAMは「明示的Deny＞上限（SCP/境界）＞Allow」の評価順で消去 → ②「誰を認証するか」で Identity Center／Cognito／ロールを選ぶ → ③暗号化は「鍵を誰が持つか・監査できるか・リージョン」 → ④検出・監査系は1対1対応表で即答。「MOST secure」＝ロール＋一時認証情報・最小権限・プライベート経路・KMS。

IAMポリシー評価ロジック（明示的Deny・上限・リソースポリシー）　A: 毎回級

「誰が・何を・どの条件で」を決める土台。明示的Denyはどこにあっても勝つ。

• 評価順：明示的Deny ＞ SCP/RCP ＞ アクセス許可境界 ＞ セッションポリシー ＞ IDベース／リソースベースのAllow → 何もなければ暗黙のDeny
• 同一アカウント：IDベース or リソースベースのどちらかにAllowがあれば可（和集合）。クロスアカウント：両方にAllowが必要（積集合）
• SCP・アクセス許可境界＝権限の「上限」で、許可は付与しない → 有効権限＝IDポリシー ∩ 境界 ∩ SCP
• リソースベースポリシーの例：S3バケットポリシー、KMSキーポリシー、SQS/SNS/Lambda/Secrets Manager、API Gatewayリソースポリシー（送信元IP・VPCエンドポイント・アカウントで「どこから」を制限＝S3バケットポリシーのAPI版）
• 頻出条件キー：aws:SourceIp／aws:MultiFactorAuthPresent／aws:PrincipalOrgID（自組織のみ）／aws:SecureTransport（HTTPS強制）／aws:SourceVpce／s3:x-amz-server-side-encryption／aws:SourceArn・aws:SourceAccount（混乱した代理対策）
• IAMはグローバル。ユーザー5,000/アカウント、アクセスキー2つ/ユーザー、グループのネスト不可、EC2は1インスタンス1ロール（インスタンスプロファイル）
• IAM Access Analyzer：外部公開されたリソース（S3・IAMロール・KMS・SQS・Lambda等）と未使用アクセスを検出、ポリシー検証。未使用アクセスキーはIAMの認証情報レポート（Access Analyzerとは別機能）でも確認可
• ルートユーザー：日常利用しない・MFA必須・アクセスキーは作らない（あれば削除）

ポリシー種別の役割

種類	付け先	役割
IDベース	ユーザー/グループ/ロール	何ができるか（Allowを付与）
リソースベース	S3・KMS・SQS・Lambda・API GW等	誰がこのリソースを使えるか（Principal必須、クロスアカウント可）
アクセス許可境界	ユーザー/ロール	最大権限の上限（付与しない）
SCP	OU/アカウント（Organizations）	アカウント全体の上限（管理アカウントには効かない）
セッションポリシー	AssumeRole時	一時認証情報をさらに絞る

引っかけ

• 「Allowしたのに拒否される」→ どこかの明示的Deny・SCP・境界を疑う（IAMポリシーを足しても解決しない）
• 「OUに直接IAMポリシーを付ける」は不可 → SCP。「SCPで許可したから使える」も誤り（IAM側のAllowも必要）
• 「HTTPSを強制」→ aws:SecureTransport が false をDeny。「自組織以外を拒否」→ aws:PrincipalOrgID
• 「サードパーティに権限委任」→ ロール＋ExternalId（IAMユーザーを発行する選択肢は不正解）

IAMロール／STS／クロスアカウント　A: 毎回級

「アクセスキーを配らない」が正解の型。ロール＋一時認証情報が常に最セキュア。

• EC2/Lambda/ECSからのAPI呼出し → IAMロール（インスタンスプロファイル／実行ロール／タスクロール）。コード・AMI・環境変数にアクセスキー埋込みは常に不正解
• STS：AssumeRole（クロスアカウント・ロール切替）／AssumeRoleWithSAML（社内AD等SAML IdP）／AssumeRoleWithWebIdentity（Google・Facebook・Cognito）／GetSessionToken（MFA付き一時認証情報）
• 一時認証情報：ロールセッション15分（900秒）〜最大12時間（ロールの最大セッション時間設定1〜12時間、既定1時間）、自動失効。ロールチェーンは最大1時間
• クロスアカウント＝信頼ポリシー（誰がAssumeできるか）＋アクセス許可ポリシー（何ができるか）。コンソールは「ロールの切替」
• 混乱した代理（Confused Deputy）対策：サードパーティ→ExternalId、AWSサービス→aws:SourceArn／aws:SourceAccount
• ECS：タスクロール（コンテナ内アプリの権限）とタスク実行ロール（ECRプル・ログ出力）は別物。EC2起動タイプのインスタンスロールとも別
• IMDSv2（セッショントークン必須）でSSRF経由の認証情報窃取を防ぐ → 起動テンプレートで必須化

引っかけ

• 「EC2からS3へ最もセキュアに」→ IAMロール（アクセスキーを置く選択肢は全部消す）
• 「他アカウントのS3に書き込み」→ 相手のバケットポリシーで許可＋自分側IDポリシーで許可、またはロールをAssumeRole
• 「発行済みの一時認証情報を即時無効化」→ 手動失効は不可 → 信頼ポリシー変更 or aws:TokenIssueTime 条件のDeny（セッションの取り消し）
• 「コンテナのIAM権限をEC2インスタンスロールに付ける」は最小権限違反 → タスクロール

IAM Identity Center（旧AWS SSO）／SAML 2.0／SCIM　A: 毎回級

従業員が1つのIDで複数AWSアカウント＋SaaSにSSO。Organizations前提・無料。

• 前提：AWS Organizations。IDソースは①内蔵ディレクトリ ②AWS Managed Microsoft AD／AD Connector ③外部IdP（Okta・Microsoft Entra ID・Google Workspace）
• 認証＝SAML 2.0（ログインの証明）、ユーザー同期＝SCIM（作成・更新・削除の自動プロビジョニング）。役割が違い、片方で片方は代替できない
• 許可セット（Permission Set）＝IAMポリシーの入れ物。「許可セット×グループ×アカウント」で割当 → 各アカウントにIAMロールとして展開される
• ユーザーポータル（1つのURL）からアクセス可能なアカウント一覧。CLIは aws configure sso で一時認証情報
• SaaSアプリ（Salesforce・Box等）へのSSOも提供。Identity Center自体は追加コストなし
• 「各アカウントにIAMユーザーを個別作成」は非効率で不正解になりやすい

SAML 2.0 vs SCIM（引っかけの本丸）

項目	SAML 2.0	SCIM
役割	認証（ログインの証明）	プロビジョニング（ユーザー/グループ同期）
動くタイミング	ログインのたび	IdP側でユーザー変更のたび
無いとどうなる	ログイン不可	ユーザー作成・削除が手動（退職者が残る）
覚え方	入口の証明書	名簿の自動更新

引っかけ

• 「退職者のアクセスを即座に失効」→ SCIM（IdP側で削除→AWS側も自動同期）。SAMLだけだと名簿は手動運用
• 「社内AD／既存IdPのアカウントでAWSコンソールにログイン」→ SAMLフェデレーション（Identity Center）
• 「従業員SSOにCognito」は誤り（Cognitoは不特定多数のアプリ利用者向け）

Cognito／Directory Service（誰を認証するか）　A: 毎回級

従業員→Identity Center、アプリ利用者→Cognito、Windows/AD→Directory Service。

• Cognitoユーザープール＝認証。サインアップ/サインイン・MFA・パスワードポリシー・ソーシャル/SAML IdP連携・JWT発行・Hosted UI。API Gateway／ALBリスナーのオーソライザーになる（アプリ改修なしで認証追加）
• Cognito IDプール＝認可。ユーザープールや外部IdPのトークンをSTS一時認証情報に交換 → S3/DynamoDBへ直接アクセス。ゲスト（未認証）アクセス可
• 課金：ユーザープールはMAU課金（無料枠あり）、IDプールは無料
• AWS Managed Microsoft AD：AWS上の本物のAD。オンプレADと信頼関係、FSx for Windows／RDS SQL Server連携、ドメイン参加・グループポリシー
• AD Connector：オンプレADへのプロキシ。ユーザーをAWSに複製しない・キャッシュなし
• Simple AD：Samba互換の小規模スタンドアロン（信頼関係不可）

認証基盤の使い分け

誰を	サービス	ポイント
従業員→複数AWSアカウント	IAM Identity Center	SAML＋SCIM、許可セット
Web/モバイル利用者（数百万）	Cognito ユーザープール＋IDプール	認証＝ユーザープール、認可＝IDプール
既存Windows AD資産	Managed Microsoft AD／AD Connector	複製する／しない
アカウント間の単発アクセス	IAMロール＋STS AssumeRole	信頼ポリシー＋ExternalId

引っかけ

• 「モバイルアプリのユーザーがS3へ直接アップロード」→ ユーザープール（認証）＋IDプール（一時認証情報）。IAMユーザー配布は不正解
• 「オンプレADの認証をそのまま使い、AWS側にADを複製しない」→ AD Connector
• 「Windows EC2をドメイン参加・ADトラスト・FSx連携」→ Managed Microsoft AD
• ユーザープール＝「誰か」、IDプール＝「AWSに何ができるか」。混同したら消去法で切る

Organizations／SCP／Control Tower／RAM／StackSets／Firewall Manager　A: 毎回級

マルチアカウント統制の道具箱。「上限＝SCP」「土台＝Organizations」「自動構築＝Control Tower」「配布＝StackSets／Firewall Manager」。

• Organizations：OU階層、一括請求（ボリューム割引合算、RI／Savings Plans共有）、組織の証跡（CloudTrail）、Config／GuardDuty／Security Hub／Macieの委任管理者
• SCP：権限の上限（許可は付与しない）。管理アカウントには効かない、メンバーアカウントのrootには効く。既定FullAWSAccess。例：特定リージョン禁止、CloudTrail無効化禁止。RCP（2024年11月〜）＝リソースポリシー側の上限
• Control Tower：ランディングゾーン自動構築（管理＋監査＋ログアーカイブアカウント）、ガードレール（現称コントロール：予防＝SCPで実行不可／発見＝Configで検知・通知／プロアクティブ＝CloudFormationフック）、Account Factoryで標準構成のアカウント払出し。内部でOrganizations・StackSetsを利用
• RAM（Resource Access Manager）：サブネット（VPC共有）・Transit Gateway・Route 53 Resolverルール・License Manager設定を複製せず共有
• CloudFormation StackSets：1テンプレートを複数アカウント×複数リージョンへ一括展開。サービスマネージド型＋Organizationsで、新規アカウントがOUに入ると自動展開。ネストスタック（1スタック内の部品化）とは別物
• Firewall Manager：セキュリティ設定そのもの（WAF/Shield Advanced/SG/Network Firewall/DNS Firewall）を組織に配布・自動修復。SCPは権限の上限で、ルールの中身は制御しない

マルチアカウント統制の4兄弟

目的	サービス
権限の上限を組織全体で定める	SCP（Organizations）
マルチアカウント環境をゼロから自動構築	Control Tower
CloudFormationテンプレートを複数アカウント/リージョンへ	StackSets
WAF/Shield/SG/Network Firewallルールを組織へ一括強制	Firewall Manager

引っかけ

• 「OU全体で特定サービス／リージョンを禁止」→ SCP。「特定ユーザーに許可」→ IAM。「SCPで拒否したのにIAMで許可すれば通る」は誤り
• 「新規アカウントを標準構成で自動払出し」→ Control Tower（Account Factory）。「既存環境に共通テンプレートを配る」→ StackSets
• 「アカウント間でサブネットを共有」→ RAM（VPCピアリングではない）
• 「請求をアカウント間で按分」はOrganizationsではできない → コスト配分タグ

KMS（キー種別・エンベロープ暗号化・マルチリージョンキー）　A: 毎回級

暗号化「鍵」の管理。問われるのはキー種別ごとにできること・監査・コスト・リージョン。

• キー種別：AWS所有（無料・見えない）／AWS管理 aws/xxx（無料・年1回自動ローテ・キーポリシー変更不可）／カスタマー管理（月$1＋API料金、キーポリシー可、ローテ手動or自動、削除可）
• カスタマー管理キーの自動ローテ：既定365日、90〜2,560日で設定可（オンデマンドローテも可）。削除は7〜30日の待機期間（既定30日）で取消可 → まず「無効化」で代用
• エンベロープ暗号化：KMSキー→データキー生成（GenerateDataKey）→データはデータキーで暗号化→暗号化済みデータキーをデータと一緒に保存。KMS直接暗号化は4KBまで。KMSキーはKMSの外に出ない・エクスポート不可
• キーポリシーがアクセス制御の起点（既定はアカウントrootを許可しIAMポリシーを有効化）。クロスアカウント利用＝キーポリシー＋相手のIAMポリシー。グラント＝一時的な権限委譲
• KMSキーはリージョン固有 → 暗号化スナップショットの別リージョンコピーは転送先リージョンのキーで再暗号化。暗号化AMI/スナップショットの他アカウント共有はカスタマー管理キーのみ（AWS管理キーでは不可）
• マルチリージョンキー：プライマリ＋レプリカで同じキーマテリアル・同じキーID（mrk-〜）。キーポリシー・管理・CloudTrailはリージョンごとに独立。「CRRした暗号化データをリージョン障害時に別リージョンで復号」の解
• 全API呼出しがCloudTrailに記録 → 「誰がいつ鍵を使ったか監査」はKMS（SSE-S3では監査不可）
• インポートしたキーマテリアル（BYOK）：有効期限設定可、自動ローテ不可（オンデマンドローテ・再インポートは可）

KMSキー種別（最頻出）

種類	料金	ローテーション	キーポリシー変更	削除
AWS所有キー	無料	AWS任せ	不可	不可
AWS管理キー（aws/s3等）	無料	自動・年1回	不可	不可
カスタマー管理キー	月$1＋API	手動/自動（既定1年、90〜2,560日）	可	可（7〜30日待機）

引っかけ

• 「キーポリシー変更・他アカウント共有・削除制御」→ すべてカスタマー管理キー限定（AWS管理キーでは不可）
• 「AccessDenied」の典型原因＝KMS権限不足（S3権限に加えて kms:Decrypt が必要）
• 「DBパスワードを保存・自動ローテ」→ KMSではなくSecrets Manager（KMSは鍵、値は保存しない）
• 「KMSキーは他リージョンでそのまま使える」は誤り（マルチリージョンキーを除く）

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

「誰が鍵を持つか」「監査できるか」「コスト」で4方式を選ぶ。

• SSE-S3：S3管理のAES-256、無料、2023年1月〜新規オブジェクトの既定。鍵使用の監査不可
• SSE-KMS：KMSキー、キーポリシーで制御、CloudTrailで鍵使用を監査。読むにはS3権限＋kms:Decrypt。KMS API課金とリクエスト上限あり。DSSE-KMS＝二層暗号化
• SSE-C：顧客がリクエストごとに鍵を送る（HTTPS必須）。AWSは鍵を保存しない
• CSE（クライアントサイド）：アップロード前に自分で暗号化（AWS Encryption SDK等）。AWSは平文も鍵も見ない
• S3バケットキー：SSE-KMSのKMS呼出しをバケット単位の短期キーで使い回し、KMSリクエスト料金を最大99%削減。有効化後の新規オブジェクトのみ（既存はCopyObjectで再暗号化）。CloudTrailのKMSログはオブジェクトARN→バケットARNになり件数も減る
• 暗号化・HTTPSの強制：バケットポリシーで s3:x-amz-server-side-encryption 条件を満たさないPUTをDeny／aws:SecureTransport が false をDeny
• レプリケーション先も暗号化方式を揃える（SSE-KMSはレプリケーションロールにKMS権限が別途必要）

S3暗号化4方式

方式	鍵の管理者	監査	特徴
SSE-S3	AWS	不可	無料・既定
SSE-KMS	KMS（カスタマー管理キー推奨）	CloudTrailで可	API課金 → バケットキーで削減
SSE-C	顧客（リクエストごと）	—	HTTPS必須、AWSは鍵を保存しない
CSE	顧客（アップロード前）	—	AWSは平文を見ない

引っかけ

• 「オンプレに保管する鍵で保存時暗号化」→ SSE-C＋CSE（公式サンプル問題5）。SSE-S3/SSE-KMSは鍵がAWS内なので不正解
• 「鍵の使用を監査したい」→ SSE-KMS一択。「SSE-KMSでKMS料金が高い」→ バケットキー（SSE-S3に変える提案は監査要件を落とす）
• 「最も細かい鍵制御」→ カスタマー管理キー（aws/s3 のAWS管理キーではない）

S3アクセス制御（バケットポリシー／BPA／署名付きURL／OAC／アクセスポイント／Object Lambda）　A: 毎回級

「バケットポリシー＋ブロックパブリックアクセス」が現代の正解。ACLは無効化がデフォルト。

• ブロックパブリックアクセス（BPA）：アカウント／バケット単位で公開を強制遮断。新規バケットは既定ON。ACLは既定で無効（Object Ownership＝バケット所有者強制）→ ACLを使う選択肢は原則不正解
• バケットポリシー：リソースベース（20KB）。条件でIP（aws:SourceIp）・VPCエンドポイント（aws:SourceVpce）・組織（aws:PrincipalOrgID）・HTTPS・暗号化を制御。Denyはrootにも効く。クロスアカウント＝バケットポリシー＋相手側IAMの両方
• 署名付きURL：発行者の権限で期限付き（CLI/SDKはIAMユーザー署名で最大7日、コンソールは最大12時間）ダウンロード/アップロード。ロールの一時認証情報で発行するとその期限で失効。CloudFront署名付きURL（1ファイル）／Cookie（複数ファイル）と区別
• CloudFront経由のみ許可 → OAC（旧OAI）＋バケットポリシーでCloudFrontのみ許可＋BPA。別ドメインのJavaScriptからS3へ → バケットにCORS設定（公式サンプル問題4）
• アクセスポイント：共有バケットに用途別の入口（独自DNS名・独自ポリシー・VPC限定）。有効権限＝バケットポリシー∩アクセスポイントポリシー。Multi-Region Access Point＝複数リージョンのバケットを1エンドポイントに
• S3 Object Lambda：GET/LIST/HEAD時にLambdaでその場加工（PIIマスキング・形式変換・リサイズ）。元データ不変・加工コピー不要・アクセスポイント上に構築。PUTは対象外
• IAM Access Analyzer for S3で外部公開バケットを検出。バージョニング＋MFA Deleteで誤削除対策（バージョニングは停止のみ、無効化不可）

引っかけ

• 「特定サイトからのみ画像参照」→ バケットポリシーのReferer条件 or CloudFront＋OAC。「他アカウントに一時的にファイルを渡す」→ 署名付きURL（IAMユーザー作成やACL公開ではない）
• 「バケットポリシーで実行(execute)権限を公開」のような存在しない権限は不正解の目印（サンプル問題4のD）
• 「バケットポリシーが肥大化・チームごとに権限分離」→ アクセスポイント。「取得時にPIIをマスキング」→ Object Lambda（加工済みコピーを別バケットに保存は不正解）
• 「Object LambdaでPUTを加工」は不可（GET/LIST/HEADのみ）

Secrets Manager／Parameter Store／ACM　A: 毎回級

「ローテーション」と出たらSecrets Manager、「安く設定値」ならParameter Store、「証明書」はACM。

• Secrets Manager：シークレット保存＋自動ローテーション（RDS/Aurora/Redshift/DocumentDBはLambda組込み）、最大64KB（65,536バイト）、KMS暗号化、クロスアカウント共有・リージョン間レプリケーション、有料（シークレット単位＋API）
• Parameter Store（Systems Manager）：階層的な設定値／SecureString（KMS）。スタンダード4KB無料、アドバンスト8KB有料。ネイティブの自動ローテーションなし
• ACM：パブリック証明書を無料発行・自動更新、ELB／CloudFront／API Gateway／App Runnerに紐付け。CloudFront用はus-east-1で発行。インポート証明書は自動更新されない。AWS Private CA（旧ACM Private CA）で内部証明書
• 認証情報はコード・環境変数にハードコードしない → IAMロール＋Secrets Manager/Parameter Store。RDS IAM DB認証（15分有効トークン、MySQL/MariaDB/PostgreSQL）でパスワード不要
• Secrets ManagerもParameter StoreもKMSで暗号化して保存（KMS＝鍵、Secrets Manager＝値）

Secrets Manager vs Parameter Store

—	Secrets Manager	Parameter Store
自動ローテーション	あり（RDS等ネイティブ）	なし（Lambda自作）
サイズ	64KB	標準4KB／アドバンスト8KB
料金	有料	標準は無料
用途	DB認証情報・APIキー	設定値全般・軽いシークレット

引っかけ

• 「DBパスワードを自動ローテーション」→ Secrets Manager（Parameter Storeは不可）
• 「コスト最小で設定値を保存」→ Parameter Storeスタンダード（無料）
• 「証明書の自動更新」でサードパーティ証明書を手動インポートする選択肢は不正解。EC2に直接置くよりALB/CloudFrontでTLS終端＋ACMが「運用負荷最小」

WAF／Shield／Firewall Manager／Network Firewall　A: 毎回級

L7攻撃＝WAF、DDoS＝Shield、組織一括＝Firewall Manager、VPC境界＝Network Firewall。

• WAF：Web ACLをCloudFront／ALB／API Gateway／AppSync／Cognitoユーザープール／App Runner／Verified Accessにアタッチ。SQLインジェクション・XSS・IPセット・地理制限・レートベース（評価ウィンドウ1/2/5/10分、既定5分のリクエスト数、ブルートフォース緩和）・マネージドルール。NLB・EC2直接は不可
• Shield Standard：全顧客に無料・自動、L3/L4 DDoS（SYNフラッド・UDPリフレクション）を緩和
• Shield Advanced：月額3,000USD（1年コミット）、L7検知、Shield Response Team 24/365、DDoS起因のスケーリング費用払戻し、保護対象リソースのWAF基本料金込み。保護対象：CloudFront・ALB/NLB・EIP・Global Accelerator・Route 53
• Firewall Manager：前提Organizations。WAF／Shield Advanced／SG／Network Firewall／Route 53 Resolver DNS Firewallのポリシーを全アカウント・OU・タグ単位に強制。新規アカウント・新規リソースにも自動適用、非準拠を可視化・自動修復
• Network Firewall：VPC単位のマネージドFW（ステートフル/ステートレス、Suricata互換IPS、ドメインフィルタ）。専用サブネットに置きルートで流す
• GWLB：サードパーティ製FW/IDSアプライアンスを透過的に挿入（GENEVE 6081）。自社製品を使いたい場合

WAF vs Shield

—	WAF	Shield Standard	Shield Advanced
層	L7（HTTP）	L3/L4	L3/L4＋L7
料金	Web ACL・ルール課金	無料・自動	月額3,000USD（1年コミット）
主な効果	SQLi/XSS/レート制限/地理制限	一般的なDDoS緩和	SRT対応・コスト保護・WAF込み

引っかけ

• 「SQLインジェクション／XSS」→ WAF。「DDoSによるコスト急増を補償」→ Shield Advanced（Standardでは不可）
• 「NLBにWAFを付ける」選択肢は誤り → 前段にALB/CloudFront
• 「複数アカウントのWAFルールを統一」→ Firewall Manager（各アカウント手動は不正解）。単一アカウントなら素のWAFで十分
• 「特定ドメインへのアウトバウンドを制限」→ Network Firewall（SGはドメイン指定不可）。「特定IPをブロック」→ NACL or WAFのIPセット（SGはDeny不可）

検出・監査系（GuardDuty／Inspector／Macie／Detective／Security Hub／Security Lake）　A: 毎回級

「何を検出するか」の1対1対応。脅威＝GuardDuty、脆弱性＝Inspector、PII＝Macie、集約＝Security Hub。

• GuardDuty：脅威検出。CloudTrail・VPCフローログ・DNSログ・S3データイベント・EKS監査ログ・RDSログイン等をMLで分析。エージェント不要、マルウェア保護。検出→EventBridge→Lambda/SNSで自動対処
• Inspector：EC2・ECRコンテナイメージ・Lambdaの脆弱性（CVE）とネットワーク到達性を継続スキャン
• Macie：S3内のPII・クレジットカード番号など機密データをMLで検出・分類
• Detective：GuardDuty等の検出結果の根本原因をグラフで調査・可視化
• Security Hub：複数アカウント・複数サービスの検出結果を集約（ASFF形式）、CIS／PCI DSS／AWS基礎ベンチマークを自動チェック。Configが前提
• Security Lake：セキュリティログ（CloudTrail・VPCフローログ・Route 53・Security Hub・サードパーティ）をOCSFに正規化して自分のS3に集約。Athena/QuickSight/SIEMで分析、Lake Formationで権限管理
• 委任管理者アカウントで組織全体を一元化（GuardDuty/Security Hub/Macie/Inspector）。AWS Artifact＝SOC/PCI/ISOレポート取得、Audit Manager＝監査証拠の自動収集

検出系サービス1対1対応

問われ方	サービス
脅威・不正アクセス・侵害の兆候	GuardDuty
OS/コンテナ/Lambdaの脆弱性	Inspector
S3の機密データ発見	Macie
検出結果の調査・根本原因	Detective
検出結果の集約・ベンチマーク	Security Hub
生ログの一元集約（OCSF正規化）	Security Lake

引っかけ

• 「不審なAPI呼出し・マイニング・侵害」→ GuardDuty／「CVE」→ Inspector／「S3のPII」→ Macie／「根本原因」→ Detective／「集約ダッシュボード」→ Security Hub
• 「複数ソースのログを統一フォーマットで長期保存し独自分析」→ Security Lake（Security Hubは検出結果の要約で、生ログ基盤ではない）
• 「InspectorでS3の個人情報」「GuardDutyで脆弱性スキャン」は役割違いで誤り

CloudTrail／Config／Config Aggregator／Resource Explorer　A: 毎回級

「誰がAPIを呼んだか」＝CloudTrail、「設定がどう変わった・準拠か」＝Config、「今どこに何があるか」＝Resource Explorer。

• CloudTrail：管理イベントは既定で記録、データイベント（S3オブジェクト操作・Lambda呼出し）は別途有効化（有料）。イベント履歴90日無料、長期はS3へ証跡、ログファイル整合性検証（SHA-256ダイジェスト）で改ざん検知、Insightsで異常なAPI増加を検知
• 組織の証跡（Organization trail）：管理アカウント/委任管理者から全メンバーアカウントのイベントを1つのS3に集約。メンバー側で無効化不可
• 証跡ログの保護：KMS暗号化＋別アカウントのS3（MFA Delete／Object Lock）＋整合性検証の組合せ
• Config：リソース設定の履歴・変更タイムライン・関連リソース。Configルールで準拠評価（例：SGで0.0.0.0/0の22番を検出）、SSM Automationで自動修復、コンフォーマンスパック
• Config Aggregator：複数アカウント・複数リージョンのConfigデータと準拠状況を集約アカウントに集める。Organizations連携で全アカウント自動集約
• Resource Explorer：アカウント内・リージョン横断でリソースをキーワード検索。各リージョンにインデックス＋1つの集約インデックス。Organizations経由でマルチアカウント検索。設定履歴や準拠は見ない

監査3兄弟＋検索

問い	サービス
誰が・いつ・どのAPIを	CloudTrail
設定の変更履歴・準拠状態	Config（＋Aggregatorで横断）
今どこに何があるか	Resource Explorer
性能・状態・ログ監視	CloudWatch

引っかけ

• 「S3バケットを誰が削除したか」→ CloudTrail／「SGルールが変更された履歴」→ Config／「CPU使用率でアラート」→ CloudWatch
• 「オブジェクト単位のS3アクセス記録」→ CloudTrailデータイベント（既定オフ）or S3サーバーアクセスログ
• 「複数アカウントのリソースをまとめて検索」→ Resource Explorer。「コンプライアンス違反を横断チェック」→ Config Aggregator（検索ではない）
• 「SGが継続的に準拠しているか監視」→ Configルール（Trusted Advisorは一時点のチェック）

CloudHSM／KMSカスタムキーストア／XKS　B: 頻出

「鍵の実体をどこに置くか」の3段階。管理主体を自分側に寄せるほど可用性の責任も自分に。

• KMS標準：AWS管理のマルチテナントHSM。ほぼ全ての暗号化ニーズはこれ（運用負荷ほぼゼロ）
• CloudHSM：シングルテナント専有HSM、FIPS 140-2 Level 3（hsm1.medium）／FIPS 140-3 Level 3（hsm2m.medium・現行推奨）。AWSも鍵の中身に触れない。VPC内クラスタ（HAには複数HSM）、バックアップ・パッチ・可用性は自分で管理。Oracle TDE・独自PKI・KMS非対応アプリ向け
• KMSカスタムキーストア：KMSのAPI・IAM・CloudTrailを使いつつ、鍵の実体をCloudHSMクラスタに置くハイブリッド
• XKS（External Key Store）：鍵の実体をAWS外（オンプレHSM・他社鍵管理）に置く。「クラウド事業者にも鍵を渡さない」最も厳しい規制向け。外部インフラの可用性・レイテンシに依存

鍵の実体の置き場所

—	KMS	CloudHSM	XKS
鍵の実体	AWS管理HSM（マルチテナント）	専有HSM（シングルテナント）	AWSの外（オンプレ/他クラウド）
運用負荷	ほぼゼロ	クラスタ管理が必要	外部インフラ次第
用途	標準的な暗号化	規制で専有HSM必須、Oracle TDE	鍵をAWS外に置く規制

引っかけ

• 「専用ハードウェア／FIPS 140 Level 3／鍵の単独管理権」→ CloudHSM（KMSではない）
• 「KMSのAPIのままCloudHSMで鍵を保持」→ カスタムキーストア。「鍵を物理的にAWS外に」→ XKS
• CloudHSM/XKSは「KMSより信頼性が高い」わけではない。規制要件を満たす選択（運用負荷最小ならKMS）

WORM（S3 Object Lock／Backup Vault Lock）　B: 頻出

「ガバナンス＝権限があれば外せる」「コンプライアンス＝誰も外せない（rootも）」。名前も思想も共通。

• S3 Object Lock：バージョニング必須（既存バケットにも有効化可、有効化後は解除・バージョニング停止不可）。保持期間（Retention）＋リーガルホールド（期限なし・解除まで読み取り専用）
• Governanceモード：s3:BypassGovernanceRetention を持つユーザーは解除・短縮可。Complianceモード：保持期間中はrootもAWSも削除・短縮不可
• Backup Vault Lock：ChangeableForDays を指定→コンプライアンス（猶予は最短3日、経過後は誰も解除不可）、省略→ガバナンス（IAM権限で解除可）。MinRetentionDays／MaxRetentionDays（最大36,500日）の範囲外のジョブは失敗
• どちらもロック前の既存オブジェクト／リカバリポイントには遡及しない（新規分から適用）
• S3 Glacier Vault Lock：Glacierボールトのポリシーを不変化する旧来の仕組み

ガバナンス vs コンプライアンス

—	ガバナンス	コンプライアンス
解除	特権（s3:BypassGovernanceRetention／IAM）で可	保持期間中は誰も不可（root含む）
猶予期間	なし	Backup Vault Lockは最短3日
目的	社内統制・誤操作防止	法令・規制、ランサムウェア

引っかけ

• 「規制で7年間誰にも消させない／ランサムウェア対策」→ Complianceモード（Vault Lockも同様）
• 「誤削除は防ぎたいが管理者は解除できるように」→ Governanceモード
• 「即座に不変になる」は誤り。Backup Vault Lockは最短3日の猶予後に確定
• 「誤削除防止」だけならバージョニング＋MFA Delete、「改ざん・削除不可の証明」ならObject Lock

保存時／転送時の暗号化パターン　B: 頻出

保存時＝KMS統合、転送時＝TLS（ACM）／VPN。「既存の非暗号化」は必ずスナップショット経由。

• 保存時：S3（SSE）、EBS（作成時にKMS指定、アカウント既定暗号化を有効化）、RDS/Aurora（作成時のみ）、DynamoDB（既定で暗号化）、EFS（作成時）、Redshift、SQS/SNS（SSE）、CloudTrailログ・CloudWatch Logs・Secrets Manager
• 既存の非暗号化EBS/RDS → スナップショット→暗号化コピー→復元（実行中の直接暗号化は不可）。暗号化RDSの非暗号化レプリカは不可、暗号化スナップショットから復元したものは必ず暗号化
• 転送時：ALB/NLB/CloudFront/API GatewayでTLS終端（ACM証明書、SNIで複数証明書）。S3は aws:SecureTransport でHTTPS強制。EFSはTLSマウント、RDSはSSL/TLS接続
• CloudFrontフィールドレベル暗号化：機密フィールドをエッジで公開鍵暗号化しオリジンまで秘匿。CloudFront用ACM証明書はus-east-1
• Direct Connectは既定で暗号化されない → DX上にSite-to-Site VPN、またはMACsec。Site-to-Site VPNはIPsecで暗号化される

引っかけ

• 「既存RDSを設定変更で暗号化」は不可 → スナップショット経由。EBSも同様
• 「DXは暗号化されている」は誤り。「転送中の暗号化」と問われたらTLS／IPsec VPN
• 「暗号化スナップショットを別アカウントに共有」→ カスタマー管理キーで暗号化しキーも共有（AWS管理キー・パブリック共有は不可）
• 「EC2に証明書を直接置く」よりELB終端＋ACM自動更新が「運用負荷最小」の型

アプリケーション統合・分析・ストリーミング

「保持するか／順序が要るか／複数が同じデータを読むか／再生が要るか／内容で振り分けるか」の5軸でメッセージング系を、「S3に直接SQL＝Athena・カタログ/ETL＝Glue・権限＝Lake Formation・可視化＝QuickSight（現 Amazon Quick Suite の Quick Sight）・検索＝OpenSearch」で分析系を即答する。A→B→Cの順に眺め、tableは比較の決め手だけ確認する。※SQS/SNS/Kinesis のメッセージ上限は 2025〜2026 年に拡張されたが、試験問題は旧上限（256KB／1MB）前提の可能性が高いので両方覚えておく。

SQS（標準／FIFO・可視性タイムアウト・DLQ）　A: 毎回級

疎結合の基本部品。プロデューサー→キュー→コンシューマー（プル型）でバーストを吸収し、DBやワーカーを守る

• 数値：メッセージ最大 1MiB（2025-08 に 256KB→1MiB へ拡張。試験教材の多くは 256KB 前提）／超は S3＋Extended Client Library で最大2GB／保持 既定4日・60秒〜14日／遅延キュー最大15分／バッチ最大10件
• 可視性タイムアウト：既定30秒・最大12時間。処理時間より短いと二重処理 → 延長 or ChangeMessageVisibility
• ロングポーリング：WaitTimeSeconds 最大20秒 → 空レスポンス減でコスト減・レイテンシ減
• DLQ：maxReceiveCount 超過で隔離 → 分析・再処理（Redrive）。FIFO キューの DLQ は FIFO
• FIFO：名前は .fifo、順序保証＋厳密に1回処理、MessageGroupId が順序単位、重複排除ID（5分窓）、300 API 呼出/秒（バッチで3,000 msg/秒、高スループットモードで最大 70,000 API 呼出/秒（リージョン依存））
• 標準：ほぼ無制限スループット、少なくとも1回配信（重複あり）、ベストエフォート順序 → 処理は冪等に
• ASG 連携：ApproximateNumberOfMessagesVisible（÷インスタンス数＝バックログ）でワーカーを増減
• 暗号化 SSE-SQS（既定）/SSE-KMS、アクセスポリシーでクロスアカウント、VPC エンドポイント対応、Lambda はイベントソースマッピングでポーリング

標準キュー vs FIFO キュー

項目	標準	FIFO
配信	少なくとも1回（重複あり）	厳密に1回処理
順序	ベストエフォート	MessageGroupId 単位で保証
スループット	ほぼ無制限	300 呼出/秒（バッチ3,000 msg/秒・高スループットモードで最大70,000 呼出/秒）
名前	任意	.fifo で終わる
用途	疎結合・バッファ	注文・取引など順序必須

引っかけ

• 「DB が書き込みバーストに追いつかない・ダウンタイム不可」→ SQS でバッファ＋ワーカー（DB 拡大・ElastiCache・Multi-AZ ではない：公式サンプル問題7）
• 「順序・重複なし」→ FIFO、「最大スループット」→ 標準（FIFO は既定 300 呼出/秒の上限）
• 「同じメッセージが複数回処理される」→ 可視性タイムアウトを処理時間より長く（標準では完全排除不可 → 冪等化）
• S3 イベント通知の宛先は標準 SQS のみ（FIFO 不可）

SNS とファンアウト　A: 毎回級

Pub/Sub のプッシュ配信。1トピック→多数サブスクライバーへ同時通知、メッセージは保持しない

• サブスクライバー：SQS／Lambda／HTTP(S)／Email／SMS／モバイルプッシュ／Data Firehose。メッセージ最大 1MiB（2026-09-18 に 256KB→1MiB へ拡張。試験は 256KB 前提と考えてよい）
• ファンアウト定石：SNS→複数 SQS→各ワーカーが独立処理（画像を同時にサムネ化・分析・保存）。各キューのアクセスポリシーで SNS からの SendMessage を許可
• フィルタポリシー：メッセージ属性（＋本文）で購読者ごとに配信を絞る → 購読側で捨てるより安い
• FIFO トピック：順序付きファンアウト。サブスクライバーは SQS（FIFO／標準）のみ（Lambda は SQS 経由、Email/SMS/HTTP は不可）、メッセージグループ・重複排除あり
• 保持しない：配信失敗は再試行後に消える → 「後で処理」「バッファ」は SQS を挟む。サブスクリプション DLQ（SQS）も設定可
• 通知の基本形：CloudWatch アラーム→SNS→Email/SMS/Lambda。大量マーケティングメールは SES
• KMS 暗号化、クロスアカウント／クロスリージョンの SQS 購読可

引っかけ

• 「1つのイベントを複数システムが独立に処理」→ SNS→SQS ファンアウト（SQS 単体だと1コンシューマーしか受け取れない）
• 「メッセージを保持して後で処理」→ SQS（SNS は保持しない）
• 「大量ユーザーへメール配信」→ SES（SNS Email は通知用途）
• 「イベントの中身で細かくルーティング／SaaS 連携／cron」→ EventBridge（SNS のフィルタは属性ベースの簡易版）

SQS／SNS／EventBridge／Kinesis 使い分け（合言葉）　A: 毎回級

メッセージング4兄弟。「保持・順序・複数消費・再生・内容ルーティング」のどれが要件かで即決

• SQS：プル型、1メッセージ1コンシューマー、消費後削除、再生不可 → 非同期タスク・バッファ・デカップリング
• SNS：プッシュ型、1対多、保持なし → 通知・ファンアウト
• EventBridge：内容（JSON 属性）でルールルーティング、SaaS 連携、cron、アーカイブ&再生 → イベント駆動のハブ
• Kinesis Data Streams：複数コンシューマーが同じデータを順序付きで読む、保持24h〜365日で再処理可 → リアルタイム分析・ログ・クリックストリーム
• Amazon MQ：既存 JMS/AMQP/MQTT アプリを改修なしで移行（新規は SQS/SNS）
• 組合せ定番：SNS→SQS（ファンアウト）、EventBridge→SQS/Lambda/Step Functions、Kinesis→Lambda/Firehose→S3

メッセージング4サービス比較

項目	SQS	SNS	EventBridge	Kinesis Data Streams
型	プル（キュー）	プッシュ（Pub/Sub）	ルールで振分け	プル（ストリーム）
保持／再生	最大14日／消費で削除	なし	アーカイブ&再生	24h〜365日／再生可
消費者数	1メッセージ1消費者	多数	1ルール最大5ターゲット	複数（拡張ファンアウト）
順序	FIFO のみ	FIFO トピックのみ	なし	パーティションキー単位
合言葉	バッファ・疎結合	通知・ファンアウト	内容ルーティング・SaaS・cron	リアルタイム分析・ログ

引っかけ

• 「順序保証・重複なし」→ SQS FIFO。「リアルタイム・再処理・複数コンシューマー」→ Kinesis。「疎結合・バッファ」→ SQS 標準
• 「既存のメッセージブローカー（ActiveMQ/RabbitMQ）」→ Amazon MQ（SQS/SNS は API 互換でない）
• 「Lambda から Lambda を直接連鎖」は不正解 → Step Functions か SQS/EventBridge を挟む

EventBridge（イベントバス・ルール・Scheduler・Pipes）　A: 毎回級

旧 CloudWatch Events。イベントを内容ベースのルールで振り分ける「配送センター」＋スケジューラ

• バス3種：デフォルト（AWS サービスのイベント＋PutEvents）／カスタム（アプリ・チームごとに分離）／パートナー（Zendesk・Datadog 等 SaaS）
• ルール：イベントパターン（prefix・数値・anything-but 等）または スケジュール（rate/cron、最小1分）。1ルールに最大5ターゲット（引上げ不可）
• ターゲット：Lambda・SQS・SNS・Step Functions・Kinesis・ECS タスク・API Gateway・他アカウント/他リージョンのバス・API Destinations（外部 SaaS の HTTP）
• 入力トランスフォーマー：InputPath で値を抜き出し InputTemplate で整形 → ターゲット向けに詰め替え
• EventBridge Scheduler：数百万スケジュール、1回限り・タイムゾーン・柔軟時間枠、270 超のサービスをユニバーサルターゲットで直接呼出し（目安）
• EventBridge Pipes：ポイントツーポイント。ソース（SQS/Kinesis/DynamoDB Streams/MSK/MQ）→フィルタ→エンリッチ（Lambda 等）→ターゲット をコードなしで
• アーカイブ&再生、スキーマレジストリ、配信失敗は既定 最大24時間・185回再試行（指数バックオフ）＋DLQ（SQS）
• クロスアカウント集約：各アカウントのバス→監視アカウントのバスへ転送（バスのリソースポリシーで許可）

引っかけ

• 「イベントの中身（属性）で送り先を細かく振り分け」→ EventBridge（SNS はトピック単位）
• 「Zendesk/Datadog 等 SaaS のイベントを取り込む」→ パートナーイベントバス
• 「定期実行（cron）で Lambda 起動」→ EventBridge（Scheduler）。CloudWatch Events は旧名
• 「GuardDuty/Config の検出→自動対処」→ EventBridge→Lambda/SNS/SSM Automation

Kinesis Data Streams vs Data Firehose vs MSK　A: 毎回級

ストリーミング三択。「自分で処理・再生」→Streams、「溜めるだけ・運用最小」→Firehose、「Kafka」→MSK

• Data Streams：シャード＝書込1MB/秒・1,000レコード/秒、読取2MB/秒（共有、GetRecords はシャードあたり5回/秒）。レコード最大 10MiB（2025-10 に 1MB→10MiB へ拡張。試験教材の多くは 1MB 前提）。保持 既定24時間〜最大365日、再処理可
• Streams モード：プロビジョンド（シャード数管理・分割/結合）／オンデマンド（自動スケール・GB 課金）。順序はパーティションキー（シャード）単位
• Streams コンシューマー：Lambda（イベントソースマッピング）／KCL（DynamoDB にチェックポイント）／Firehose／Managed Service for Apache Flink（旧 Kinesis Data Analytics for Apache Flink。旧「Kinesis Data Analytics for SQL」は 2026-01 に廃止、SQL は Flink Studio で）
• ProvisionedThroughputExceeded → ホットシャード。シャード分割・パーティションキー分散・指数バックオフ（KPL で集約）
• Firehose（Amazon Data Firehose、旧 Kinesis Data Firehose）：サーバーレス・シャードなし・自動スケール、バッファ（サイズ 1〜128MiB（既定5）／間隔 0〜900秒（既定300、0＝ゼロバッファリング））でニアリアルタイム、保持・再生なし
• Firehose 宛先：S3・Redshift（S3 経由 COPY）・OpenSearch・Splunk・HTTP エンドポイント・Datadog 等・Snowflake・Apache Iceberg テーブル（S3 Tables）。Lambda 変換、JSON→Parquet/ORC 変換・圧縮、動的パーティショニング、失敗レコードは S3 退避
• Firehose ソース：Direct PUT／Kinesis Data Streams／MSK／CloudWatch Logs／IoT。DynamoDB は直接ソース不可（Kinesis Data Streams for DynamoDB 経由）
• MSK：マネージド Apache Kafka（MSK Serverless／MSK Connect）。既存 Kafka 資産・エコシステム前提、長期保持・大きなメッセージ設定可。Kinesis Video Streams＝カメラ映像→Rekognition

Kinesis Data Streams / Data Firehose / MSK

項目	Data Streams	Data Firehose	MSK
遅延	リアルタイム（〜ms）	ニアリアルタイム（バッファ、0秒設定も可）	リアルタイム
容量管理	シャード／オンデマンド	不要（自動）	ブローカー／Serverless
保持・再生	24h〜365日・可	なし	設定次第・可
消費者	自作（Lambda/KCL/Flink）	宛先へ自動配信	Kafka コンシューマー
合言葉	カスタム処理・複数消費者	S3/Redshift/OpenSearch へ流し込み	既存 Kafka

引っかけ

• 「S3/Redshift/OpenSearch へ最小運用でロード」→ Firehose（Streams＋自作コンシューマーは過剰）
• 「ミリ秒のリアルタイム・複数アプリで同時消費・再処理」→ Data Streams（Firehose はバッファ遅延あり・保持なし）
• Firehose の宛先に DynamoDB／RDS は不可（Lambda 経由）
• 「保持期間は最大24時間」は古い → 現在は最大365日（既定24時間）

API Gateway　A: 毎回級

マネージド API の玄関。「タイプ選択・誰が呼べるか・どれだけ呼べるか・どこへ繋ぐか」の4点で出る

• REST API（全部入り：API キー・使用量プラン・キャッシュ・リクエスト検証・WAF・プライベート）／HTTP API（最大約70%安・低レイテンシ・JWT オーソライザー、機能限定）／WebSocket API（双方向：チャット・通知）
• 認可：IAM（SigV4）／Cognito オーソライザー（ユーザープール JWT）／Lambda オーソライザー（独自トークン）／リソースポリシー（送信元 IP・VPC エンドポイント・アカウント＝「どこから」）／API キー＋使用量プラン（識別と流量制御、認証ではない）
• スロットリング：トークンバケット、アカウント既定 10,000 req/秒・バースト 5,000（新しいリージョンは 2,500／1,250、引上げ可）、超過は 429。階層はアカウント→ステージ→メソッド（メソッドが最優先）、使用量プランで顧客ごと
• キャッシュ：ステージ単位、TTL 既定300秒（0〜3,600秒）、暗号化可 → 同一データの頻繁アクセスでバックエンド負荷とコスト削減
• 統合：Lambda／HTTP／AWS サービス直接（SQS・Kinesis・DynamoDB・Step Functions）／モック／VPC Link（REST→NLB、HTTP API→ALB/NLB/Cloud Map）。統合タイムアウト既定29秒（2024-06 からリージョン／プライベート REST API は29秒超へ引上げ可、代わりにアカウントのスロットル枠が減る場合あり）、ペイロード10MB
• エンドポイント：エッジ最適化（CloudFront 経由・グローバル）／リージョン／プライベート（Interface VPC エンドポイント execute-api 経由のみ＋リソースポリシーで aws:SourceVpce 指定）
• ステージ（dev/prod・ステージ変数）、カナリアリリース（一部トラフィックだけ新版へ）、マッピングテンプレート（VTL）でリクエスト/レスポンス変換
• WAF は REST API のステージにアタッチ可（HTTP API は不可）。カスタムドメイン＋ACM（エッジ最適化は us-east-1 の証明書）

REST / HTTP / WebSocket API

項目	REST API	HTTP API	WebSocket API
用途	フル機能	軽量プロキシ・低コスト	双方向リアルタイム
認可	IAM/Cognito/Lambda/リソースポリシー	IAM/JWT/Lambda	IAM/Lambda
API キー・使用量プラン	あり	なし	なし
キャッシュ／WAF	あり／あり	なし／なし	なし／なし
VPC Link	NLB	ALB/NLB/Cloud Map	—

引っかけ

• 「特定のオンプレ拠点 IP／社内からのみ」→ リソースポリシー（オーソライザーは「誰か」しか見ない）
• 「コスト最優先のシンプルな Lambda プロキシ」→ HTTP API。「API キー・使用量プラン・キャッシュ」→ REST API
• 「バックエンドが29秒超」→ 非同期化（SQS／Step Functions）が定石（リージョン/プライベート REST なら引上げも可だが試験は非同期化を選ぶ）。「Lambda 同時実行超過」も 429
• 「プライベートサブネットの ALB/NLB 配下へ」→ VPC Link（VPC ピアリングや公開 IP ではない）

Athena と Glue（Crawler・Data Catalog）　A: 毎回級

S3 データレイクの基本セット。Glue がカタログ化/ETL、Athena が S3 に直接 SQL

• Athena：サーバーレス（Trino/Presto ベース）、S3 に標準 SQL、スキャン量課金 1TB あたり約5USD（目安）。Glue Data Catalog をスキーマに使用、結果は S3 へ
• Athena のコスト/性能改善：列指向 Parquet/ORC＋圧縮＋パーティション分割（パーティション射影）→ スキャン量削減。ワークグループでクエリ単位のスキャン上限・課金分離
• Athena 定番：CloudTrail・VPC フローログ・ALB/CloudFront ログ・S3 アクセスログを S3 のまま分析。フェデレーテッドクエリで RDS/DynamoDB 等も（Lambda コネクタ）
• Glue：サーバーレス ETL（Spark／Python シェル／ストリーミング）、DPU 時間課金。ジョブ・トリガー・ワークフロー、ジョブブックマークで増分処理
• Glue Crawler：S3/JDBC をスキャンしてスキーマとパーティションを推定 → Data Catalog にテーブル登録（スケジュール実行可）
• Glue Data Catalog：Hive メタストア互換の中央メタデータ。Athena／EMR／Redshift Spectrum／Lake Formation が共有
• 周辺：Glue Studio（GUI で ETL）、DataBrew（ノーコード整形）、Glue Data Quality、Glue Schema Registry（ストリーム用）
• 定番フロー：S3 生データ → Crawler → Catalog → Glue ジョブで CSV→Parquet → Athena/QuickSight

引っかけ

• 「S3 のログをたまに SQL で分析、サーバー管理なし」→ Athena（EMR/Redshift クラスターは過剰）
• 「Athena のコストを下げる」→ Parquet 変換＋パーティション（インスタンス増ではない）
• 「CSV→Parquet 変換」→ Glue（ストリーミングなら Firehose の変換）
• 「オブジェクトのごく一部だけ取り出して転送量削減」→ S3 Select（Athena は複数オブジェクト横断）

Step Functions（Standard vs Express）　B: 頻出

サーバーレスのワークフロー（ステートマシン）。Lambda 連鎖・分岐・並列・再試行・待機を定義で管理

• ステート：Task・Choice（分岐）・Parallel・Map（配列反復、Distributed Map で S3 大規模並列）・Wait・Pass・Succeed/Fail。Retry/Catch でエラー処理
• Standard：最長1年、厳密に1回、状態遷移数で課金、実行履歴を保持（90日） → 長時間・人手承認・監査向け
• Express：最長5分、少なくとも1回（非同期）／最大1回（同期）、実行回数×時間×メモリ課金、高頻度（IoT・ストリーム処理）。ログは CloudWatch Logs
• 統合パターン：Request Response／Run a Job（.sync：Batch・ECS・Glue の完了待ち）／Callback（.waitForTaskToken：人手承認・外部応答待ち）
• 200 超のサービスと直接統合（SDK 統合）→ Lambda を挟まず DynamoDB/SQS/SNS を呼べる。ペイロード上限256KB
• SWF は旧世代 → 新規は Step Functions

Standard vs Express ワークフロー

項目	Standard	Express
最長実行	1年	5分
実行セマンティクス	厳密に1回	少なくとも1回（非同期）／最大1回（同期）
課金	状態遷移数	実行回数＋時間＋メモリ
履歴	コンソールで参照（90日）	CloudWatch Logs
用途	長時間・承認・監査	高頻度・短時間・ストリーム

引っかけ

• 「複数 Lambda の順次実行・状態管理・再試行・長時間待機」→ Step Functions（Lambda から Lambda を直接呼ぶ設計は不正解）
• 「1年待つ承認フロー」→ Standard。「毎秒数万件の短い処理」→ Express（5分制限）
• 「Lambda 15分超の長処理を分割・調整」→ Step Functions＋Batch/Fargate

ファンアウトパターン（SNS→SQS／Kinesis 拡張ファンアウト）　B: 頻出

1入力→複数出力の分岐設計。「1イベントを複数システムへ」と「同じストリームを多数コンシューマーが低遅延で読む」は別物

• SNS→複数 SQS：1トピックに複数キューを購読、各キューが独立したペースで処理・失敗しても他に影響なし。フィルタポリシーで宛先絞り込み
• EventBridge でも類似可（1ルール5ターゲット、複数ルールで拡張）。内容ルーティングが要るなら EventBridge
• Kinesis 標準コンシューマー：シャードあたり読取2MB/秒を全コンシューマーで共有（GetRecords ポーリング、遅延 約200ms〜（コンシューマー5つで約1,000ms））
• Kinesis 拡張ファンアウト：コンシューマーごとに専用2MB/秒/シャード、HTTP/2 プッシュ（SubscribeToShard）で約70ms、追加課金、ストリームあたり登録コンシューマー最大20（オンデマンド Advantage モードは50）
• S3 イベント→複数処理：S3→SNS→SQS 群、または S3→EventBridge（複数ルール）
• DynamoDB 変更→複数消費者：Kinesis Data Streams for DynamoDB（保持最大1年・複数コンシューマー）が DynamoDB Streams（24時間・Lambda 直結向け）より有利

引っかけ

• 「Kinesis で複数コンシューマーの読み取り性能／レイテンシ」→ 拡張ファンアウト（シャード追加ではない）
• 「1イベントを複数の疎結合システムへ」→ SNS→SQS（SQS 単体は1消費者で消える）
• 「順序付きファンアウト」→ SNS FIFO→SQS FIFO

Amazon MQ　B: 頻出

ActiveMQ／RabbitMQ のマネージド版。既存メッセージングアプリを「改修なし」で移行する受け皿

• 対応プロトコル：JMS・AMQP・MQTT・OpenWire・STOMP（業界標準 API）。SQS/SNS は AWS 独自 API
• HA：ActiveMQ はアクティブ/スタンバイ（別 AZ、EFS 共有ストレージ）、RabbitMQ はクラスターデプロイ（マルチ AZ）
• VPC 内に配置（セキュリティグループ必要）、ブローカーインスタンスサイズを選ぶ → SQS/SNS ほど無限にはスケールしない
• 使いどころ：オンプレの ActiveMQ/RabbitMQ からのリフト&シフト、レガシーアプリの疎結合維持

引っかけ

• 「既存の JMS/AMQP/MQTT アプリをコード変更なしで」→ Amazon MQ（SQS/SNS は API が違うので改修必要）
• 「新規のクラウドネイティブなキュー／無制限スケール／運用最小」→ SQS/SNS（MQ ではない）

Lake Formation（＋ブループリント）　B: 頻出

S3 データレイクの「ガバナンス層」。Glue Data Catalog 上でテーブル・列・行・セル単位の権限を一元管理

• 権限モデル：DB／テーブル／列／行／セル単位（データフィルタ）。IAM だけでは困難な細粒度制御
• 一度付与すれば Athena・Redshift Spectrum・EMR・QuickSight・Glue から統一的に効く（分析サービス横断）
• LF-Tags（タグベースアクセス制御）：大量テーブルへの権限をタグでまとめて付与
• クロスアカウント共有：RAM 経由で Organizations 内の他アカウントにカタログ／データを共有
• ブループリント：取り込みワークフローの雛形。Database snapshot（一括）／Incremental database（増分）／Log file（ALB・CloudTrail ログ）。裏で Glue のクローラ＋ジョブ＋ワークフローが自動生成
• 役割分担：Glue＝カタログ化/ETL、Lake Formation＝その上のアクセス制御・ガバナンス。Security Lake などのデータレイク権限にも利用

引っかけ

• 「特定の列・行だけ特定ユーザーに、複数分析サービス跨ぎで」→ Lake Formation（IAM/バケットポリシーでは列・行は不可）
• 「単に S3 バケットへのアクセス制御」→ IAM/バケットポリシーで十分（Lake Formation は過剰）
• 「RDS からデータレイクへ定期増分取り込み（Lake Formation 文脈）」→ Incremental database ブループリント
• ブループリント＝取り込み自動化であり、アクセス制御機能ではない

OpenSearch Service（全文検索・ログ分析）　B: 頻出

旧 Elasticsearch Service。転置インデックスによる全文検索・ログ分析・可視化（OpenSearch Dashboards）

• 用途：アプリ内検索（あいまい検索・関連度順）、ログのリアルタイム検索・可視化、セキュリティ分析。旧 Kibana＝OpenSearch Dashboards
• 取り込み経路：Data Firehose の宛先／CloudWatch Logs サブスクリプションフィルタ／DynamoDB Streams→Lambda／OpenSearch Ingestion
• 構成：VPC 内配置、マルチ AZ、専用マスターノード、UltraWarm／コールドストレージで古いログを安く保持。OpenSearch Serverless あり
• アクセス：きめ細かなアクセス制御（IAM／Cognito 連携）、保存時・転送時暗号化
• 定番組合せ：DynamoDB（正本）＋OpenSearch（検索）、Firehose→OpenSearch→Dashboards（ログ分析）

引っかけ

• 「ログをリアルタイムに検索・可視化」→ OpenSearch（Athena は S3 上の SQL でリアルタイム性なし）
• 「商品のあいまい検索・関連度順」→ OpenSearch（RDS の LIKE／DynamoDB では困難）
• OpenSearch は検索インデックスでありプライマリ DB ではない → 正本は DynamoDB/RDS/S3 に置く
• 「Elasticsearch」「Kibana」は旧名称（選択肢に混在する）

EMR　B: 頻出

Hadoop／Spark／Hive／Presto／HBase のマネージドクラスター。既存ビッグデータジョブの移行と超大規模バッチ向け

• ノード：プライマリ（マスター）／コア（HDFS＋処理）／タスク（処理のみ）。タスクノードに Spot で大幅コスト削減、コアはオンデマンド
• ストレージ：EMRFS（S3、永続・クラスター停止後も残る）vs HDFS（ローカル・一時）。データは S3 に置き一時クラスターを使い捨てる定石
• EMR Serverless（クラスター管理不要）／EMR on EKS／マネージドスケーリング／インスタンスフリート（複数タイプ・Spot 混在）
• 一時（トランジェント）クラスター＝ジョブ完了で終了しコスト最小、長時間稼働クラスター＝常時分析
• Glue との違い：Glue＝サーバーレスで簡易 ETL、EMR＝フレームワーク・OS まで制御・既存 Spark/Hadoop コード資産

引っかけ

• 「既存の Hadoop/Spark ジョブを移行」→ EMR（Glue は独自ジョブ）
• 「S3 のデータにアドホック SQL・運用最小」→ Athena（EMR は過剰）
• 「EMR のコスト削減」→ タスクノードに Spot＋一時クラスター＋S3（EMRFS）

QuickSight（現 Amazon Quick Suite／Quick Sight）／AppFlow／Data Exchange　B: 頻出

可視化＝QuickSight（2025-10 に Amazon Quick Suite へ発展、BI 機能は「Quick Sight」）、SaaS 連携＝AppFlow、サードパーティデータ購読＝Data Exchange

• QuickSight（現 Quick Sight）：サーバーレス BI・ダッシュボード、SPICE インメモリエンジンで高速、ユーザー/セッション課金、ML Insights・埋め込み分析・行レベルセキュリティ。試験の選択肢は「QuickSight」表記のまま
• QuickSight データソース：Athena・Redshift・RDS/Aurora・S3・OpenSearch・Salesforce 等。DynamoDB は直接不可（Athena コネクタ経由）。VPC 内 DB には VPC 接続
• AppFlow：SaaS（Salesforce・Slack・ServiceNow・SAP 等）⇔ AWS（S3・Redshift 等）をノーコードで双方向転送。トリガー：オンデマンド／スケジュール／イベント。マスキング・フィルタ・検証の変換、PrivateLink 対応
• Data Exchange：サードパーティ提供データセットを購読 → S3／Redshift／API で受領（データのマーケットプレイス）
• 転送手段の整理：DB→DMS、ファイル→DataSync、SFTP→Transfer Family、SaaS→AppFlow

引っかけ

• 「Salesforce のデータを S3/Redshift へ定期取込、コード不要」→ AppFlow（Lambda 自作や DMS ではない）
• 「可視化・ダッシュボード」→ QuickSight（Athena は SQL エンジン、可視化は別）
• AppFlow（SaaS 連携）と AppSync（GraphQL）は別物

AppSync　C: たまに

マネージド GraphQL API。1リクエストで複数データソースをまとめて取得、サブスクリプションでリアルタイム配信

• データソース：DynamoDB・Lambda・Aurora（Data API）・OpenSearch・HTTP・EventBridge。リゾルバーで結線
• リアルタイム：GraphQL サブスクリプション（WebSocket）でプッシュ配信 → チャット・共同編集・ライブダッシュボード。GraphQL 不要の Pub/Sub なら AppSync Events（Event API）
• オフライン同期：モバイルアプリ（Amplify DataStore）と相性
• 認可：API キー／IAM／Cognito ユーザープール／OIDC／Lambda オーソライザー。サーバー側キャッシュあり
• API Gateway との違い：REST（エンドポイント単位）vs GraphQL（クライアントが必要なフィールドを指定）

引っかけ

• 「GraphQL」「リアルタイム同期・サブスクリプション」「オフライン対応モバイル」→ AppSync（API Gateway REST ではない）
• 「WebSocket で双方向」だけなら API Gateway WebSocket API も候補 → 「GraphQL」の文言で AppSync

ペイロード変換：EventBridge 入力トランスフォーマー vs API Gateway マッピングテンプレート　C: たまに

どちらも「送る前に中身を詰め替える」機能。イベント・ルール文脈なら前者、API リクエスト/レスポンス文脈なら後者

• 入力トランスフォーマー：ルール→ターゲット直前に整形。InputPath（JSONPath で値抽出）＋InputTemplate（新しい形に組立）。片方向
• 用途：EC2 状態変化イベントから ID と状態だけ抜き出し Slack 通知文に整形、Lambda が期待する入力形式に合わせる
• マッピングテンプレート：API Gateway の統合リクエスト／統合レスポンスで VTL により変換。XML⇔JSON、バックエンド形式とクライアント形式の差異吸収。双方向
• 似た機能：Firehose の Lambda 変換（ストリーム）、Step Functions の InputPath/ResultSelector（ワークフロー内）

入力トランスフォーマー vs マッピングテンプレート

項目	EventBridge 入力トランスフォーマー	API Gateway マッピングテンプレート
場面	非同期のイベント配信	同期 API 呼出し
方向	ルール→ターゲットの片方向	リクエスト/レスポンス双方向
記法	JSONPath＋テンプレート	VTL
目的	イベント整形	インターフェース差異の吸収

引っかけ

• 「イベント・ルール・ターゲット」の語 → EventBridge 入力トランスフォーマー
• 「API・リクエスト/レスポンス・VTL」の語 → API Gateway マッピングテンプレート
• HTTP API はマッピングテンプレート非対応（REST API の機能）

おわりに

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

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