第1回 問題集（全般）

正解: B. AWS OrganizationsのSCP（サービスコントロールポリシー）でec2:RunInstancesをus-east-1以外で拒否する

正解の根拠・詳細解説

SCPはAWS Organizationsの組織単位（OU）またはアカウントに適用され、メンバーアカウントのすべてのIAMエンティティ（ルートユーザー含む）に対して上限を設定します。個別のIAMポリシーは各アカウントで管理が必要なため非効率です。AWS Configは検出はできますが予防ではありません。Permission BoundaryはIAMエンティティの最大権限を設定しますが、組織全体への一括適用には不向きです。

正解: A. AWS Control Tower

正解の根拠・詳細解説

・CAWS Control TowerはLanding Zoneを自動構築し、ガードレール（必須・強く推奨）を自動適用してアカウントを安全にプロビジョニングします。AWS Organizationsは Control Towerの基盤として、アカウントの階層管理・SCPの適用・一括請求を提供します。この2つが組み合わさることで、ガバナンスの効いたマルチアカウント環境が実現できます。

正解: B. AWS Transit Gatewayを中央ハブとして使用し、全VPCをアタッチする

正解の根拠・詳細解説

VPCピアリングは推移的ルーティングをサポートせず、N個のVPCをフルメッシュ接続するにはN×(N-1)/2の接続が必要です（50VPCなら1,225接続）。Transit Gatewayはハブアンドスポーク型で、各VPCをシンプルにアタッチするだけで相互通信が可能になり、マルチアカウント・マルチリージョンに対応し、AWS RAMを通じてアカウント間で共有できます。

正解: B. アカウントBにIAMロールを作成し、アカウントAをプリンシパルとしたSTS AssumeRoleを使用する

正解の根拠・詳細解説

クロスアカウントアクセスのAWSのベストプラクティスは「ロールの引き受け（AssumeRole）」です。アカウントBにIAMロールを作成し、信頼ポリシーでアカウントAのプリンシパルを指定します。アカウントAのIAMエンティティはsts:AssumeRoleを呼び出して一時的な認証情報を取得し、アカウントBのリソースへ最小権限でアクセスできます。ルートユーザーの認証情報共有は絶対に避けるべきです。

正解: B. AWS Resource Access Manager（RAM）でTransit Gatewayを組織全体または指定アカウントと共有する

正解の根拠・詳細解説

AWS RAM（Resource Access Manager）を使用すると、Transit Gatewayを他のAWSアカウントや組織全体と共有できます。共有されたTransit Gatewayに各アカウントのVPCをアタッチするだけで接続が完成します。これにより単一のTransit Gatewayで集中管理でき、運用負荷を最小化できます。VPCピアリングはTransit Gatewayを中継しないため、スケーラビリティに限界があります。

正解: B. AWS Directory ServiceのAD Connectorを使用してオンプレミスADへのプロキシとして機能させる

正解の根拠・詳細解説

AD Connectorは既存のオンプレミスActive Directoryへのプロキシとして機能し、ADのデータをAWSに同期・コピーしません。オンプレミスADを変更せずにAWSサービスへのSSO、WorkSpacesのAD認証、IAMロールマッピングが実現できます。AWS Managed Microsoft ADは新しいADを作成するため、既存ADとの双方向信頼設定が必要です。IAMユーザーの個別作成は管理負荷が高く推奨されません。

正解: A. OktaのSAMLメタデータをもとにIAM SAMLプロバイダーを作成する

正解の根拠・詳細解説

・CSAML 2.0フェデレーションの設定には：①OktaのSAMLメタデータXMLファイルを使用してIAM SAMLアイデンティティプロバイダーを作成する、②そのSAMLプロバイダーを信頼ポリシーのプリンシパルに指定したIAMロールを作成する（sts:AssumeRoleWithSAMLアクション）、の2つが必要です。これによりOktaで認証されたユーザーが対応するIAMロールを引き受けてAWSコンソールにアクセスできます。

正解: B. AWS OrganizationsでOrganization Trailを作成し、セキュリティアカウントのS3バケット（S3 Object Lock有効）に集約する

正解の根拠・詳細解説

Organization TrailはAWS Organizations全体にCloudTrailを一括有効化し、管理アカウントで一元管理できます。ログをS3 Object Lock（WORM: Write Once Read Many）を有効にしたバケットに保存することで改ざんを防止できます。ログファイルの整合性検証（Log File Validation）を有効にすることも重要です。S3レプリケーション方式は各アカウントの管理が必要で運用負荷が高くなります。

正解: B. GuardDutyの委任管理者（Delegated Administrator）としてセキュリティアカウントを指定し、組織全体でGuardDutyを自動有効化する

正解の根拠・詳細解説

GuardDutyの委任管理者機能を使用すると、管理アカウントが指定したアカウント（通常はセキュリティアカウント）から組織全体のGuardDutyを一元管理できます。新規アカウントへの自動有効化、全アカウントの検出結果の集約が可能です。手動での各アカウント設定や招待状方式は、新規アカウント追加時に手動対応が必要で運用負荷が高くなります。

正解: B. Terraformコードでアカウントプロビジョニングを自動化・バージョン管理でき、カスタマイズ可能なアカウントカスタマイゼーションフレームワークを提供する

正解の根拠・詳細解説

AFT（Account Factory for Terraform）は、Terraformを使ってControl Towerのアカウントプロビジョニングを自動化するフレームワークです。アカウント作成リクエストをTerraformコードで管理でき、GitOpsワークフローに統合可能です。Account Customizationsでアカウントごとのカスタム設定（IAMロール、Config Rules等）をコードで管理できます。コンソール操作のみでは実現できない自動化と再現性を提供します。

正解: B. IAM Permission Boundary（アクセス許可の境界）を使用して、開発者が作成できるロール/ユーザーの最大権限を制限する

正解の根拠・詳細解説

Permission Boundary（アクセス許可の境界）は、IAMエンティティ（ユーザー/ロール）に設定できる管理ポリシーで、そのエンティティが持てる最大権限を定義します。開発者に「Permission Boundary付きでのみロール作成可能」という権限を付与することで、開発者が作成するロールは必ずPermission Boundaryの範囲内に制限されます。これにより権限昇格を防ぎながら開発者の自律性を確保できます。

正解: B. AWS Config Aggregatorをセキュリティアカウントに作成し、組織全体のアカウントとリージョンを集約ソースとして追加する

正解の根拠・詳細解説

AWS Config Aggregatorを使用すると、複数のAWSアカウントとリージョンの設定データとコンプライアンスデータを1か所に集約できます。AWS Organizations全体を集約ソースとして指定すると、新規アカウントも自動的に集約対象になります。集約ビューからリソースのインベントリ確認・コンプライアンス状況の監視・非準拠リソースの特定が一元的に行えます。

正解: B. Direct ConnectのバックアップとしてサイトツーサイトVPN（IPSec）をフェイルオーバー用に設定する

正解の根拠・詳細解説

最もコスト効率の良いDirect Connectの冗長化は、バックアップとしてサイトツーサイトVPNを設定する方法です。Direct Connect正常時はDirect Connect経由、障害時にはVPNへ自動フェイルオーバーします（BGPメトリックで制御）。2本目のDirect Connect専用回線は高コストですが最高可用性が必要な場合に使用します。同じlocationへの複数VIF設定は物理回線の障害に対応できません。

正解: B. SCPはrootユーザーを含む全IAMエンティティに適用されるため、アクションは拒否される

正解の根拠・詳細解説

SCPはAWS Organizationsのメンバーアカウント内のすべてのIAMエンティティ（rootユーザーを含む）に適用されます。これはSCPの強力な特徴の一つです。ただし、管理アカウント（マスターアカウント）自体にはSCPは適用されません。つまりメンバーアカウントのrootユーザーはSCPによって制限を受けますが、管理アカウントのrootユーザーはSCPの影響を受けません。

正解: A. AWS OrganizationsのAll Featuresが有効になっている

正解の根拠・詳細解説

・DAWS Firewall Managerを使用するための前提条件は：①AWS Organizations内で「すべての機能（All Features）」が有効になっていること、②Firewall Manager管理者アカウントが組織の管理アカウントまたは委任管理者として指定されていること、③対象アカウントがAWS Organizationsのメンバーであること、です。なお、WAFおよびShield Advancedポリシーの場合はAWS Configも必要ですが、Network Firewallポリシーのみに対しては必須ではありません。

正解: B. アカウントBのEventBridgeイベントバスにリソースベースポリシーを設定し、アカウントAのルールからクロスアカウントでイベントを送信する

正解の根拠・詳細解説

EventBridgeはクロスアカウントのイベント配信をネイティブにサポートしています。受信側アカウント（アカウントB）のカスタムイベントバスにリソースベースポリシーを設定して送信元アカウント（アカウントA）からのputEvents権限を許可します。送信側ではイベントルールのターゲットとしてアカウントBのイベントバスARNを指定します。この方法はSNS/SQSを介するより直接的でイベント駆動アーキテクチャをシンプルに構築できます。

正解: B. Security Hubの委任管理者アカウントを設定し、組織全体での自動有効化と集中管理を構成する

正解の根拠・詳細解説

Security Hubには組織統合機能があり、委任管理者アカウントを指定することで組織全体のセキュリティ調査結果を集約管理できます。「組織アカウントの自動有効化」設定により、新規メンバーアカウントにも自動的にSecurity Hubが有効化されます。GuardDuty、Inspector、Macieなど複数のAWSセキュリティサービスの検出結果が自動的に集約され、CIS AWS Foundations BenchmarkなどのセキュリティスタンダードへのコンプライアンスもSecurity Hubから一元確認できます。

正解: B. S3バケットにIAMポリシーのaws:PrincipalOrgIDとs3:prefix条件キーを組み合わせて、アカウントごとにプレフィックスを分けてアクセス制御する

正解の根拠・詳細解説

S3バケットポリシーでaws:PrincipalOrgIDを使用して組織メンバーのみアクセスを許可し、さらにs3:prefixとaws:PrincipalAccount条件キーを組み合わせることで、各アカウントが自分のプレフィックス（例：s3://datalake/accountID-123/）にのみアクセスできるきめ細かなアクセス制御を実現できます。これは単一バケットで管理を集約しながら、アカウントごとのデータ分離を実現するベストプラクティスです。

正解: B. 強制ガードレールは自動的に全OUに適用され無効化できない。強く推奨されるガードレールは有効化は任意

正解の根拠・詳細解説

Control Towerのガードレールには3種類あります。①強制ガードレール（Mandatory）：ランディングゾーンのすべてのOUに自動適用され、無効化不可。例：CloudTrailの組織全体の有効化。②強く推奨されるガードレール（Strongly Recommended）：有効化は任意だが、AWSのベストプラクティスに基づく推奨設定。③選択的ガードレール（Elective）：特定の要件に応じて選択的に適用。ガードレールはSCP（予防的）またはAWS Config Rules（発見的）として実装されます。

正解: B. Route 53 Resolverのインバウンドエンドポイント（オンプレ→AWS）とアウトバウンドエンドポイント（AWS→オンプレ）を作成する

正解の根拠・詳細解説

Route 53 Resolverを使ったハイブリッドDNS統合では：①インバウンドエンドポイント（VPC内にENIを作成）：オンプレミスDNSからのクエリをRoute 53に転送。オンプレミスのDNSサーバーにRoute 53プライベートホストゾーンへのフォワードルールを設定します。②アウトバウンドエンドポイント：AWSからオンプレミスDNSへのクエリ転送。リゾルバールールでオンプレミスのドメインをオンプレミスDNSにフォワードします。この両エンドポイントの組み合わせで双方向のDNS解決が実現します。

正解: B. アカウントBのS3バケットで「バケットオーナー強制（Bucket owner enforced）」オブジェクトオーナーシップ設定を有効にして、ACLを無効化する

正解の根拠・詳細解説

「バケットオーナー強制」設定を有効にすると、バケット内のすべてのオブジェクトのオーナーが自動的にバケットオーナー（アカウントB）になります。ACLが無効化されるため、オブジェクトのオーナーシップ問題が根本的に解決されます。これはS3のクロスアカウントアクセスにおける推奨設定です。Aの方法はアップロードのたびに追加手順が必要で根本解決ではありません。

正解: B. S3:GetObjectのみが許可される

正解の根拠・詳細解説

IAMポリシー評価ロジック：許可はSCP・IAMポリシー・リソースポリシーの「積（AND）」です。SCP：S3全て許可、IAMポリシー：GetObjectのみ許可、バケットポリシー：PutObjectのみ許可。GetObjectはSCP○・IAMポリシー○・バケットポリシー×（明示的な許可なし）ですが、バケットポリシーがない場合はIAMポリシーが優先されます。同一アカウントの場合、バケットポリシーがPutObjectのみ許可していてもIAMポリシーでGetObjectが許可されていればGetObjectは実行可能です（IAMポリシーとバケットポリシーはOR評価）。SCPはその上限を設けます。

正解: B. AWS Control TowerのAccount Customizationsまたはアカウント作成イベントをEventBridgeでキャプチャしてStep FunctionsとCloudFormation StackSetsで自動化する

正解の根拠・詳細解説

EventBridgeでOrganizationsの「CreateAccountResult」イベントを検出し、Step FunctionsワークフローでCloudFormation StackSetsを使用して新規アカウントにセキュリティリソースを自動デプロイする方法が最もスケーラブルです。AWS Control TowerのAFT（Account Factory for Terraform）やAccount Customizationsも同様の自動化を提供します。手動スクリプトや定期確認ではリアルタイム性と確実性が不足します。

正解: B. SAML属性マッピングでlocaleまたはpreferredLanguage属性が適切に設定されていない

正解の根拠・詳細解説

IAM Identity CenterはSAMLアサーション内の属性を使用してユーザー属性を設定します。コンソールの言語設定はユーザープロファイルに保存されますが、毎回リセットされる場合はSAMLアサーションで言語/ロケール属性が送信されていないかマッピングが間違っている可能性があります。Microsoft Entra IDのエンタープライズアプリケーション設定でSAML属性マッピングを確認し、preferredLanguageやlocale属性を正しく設定することで解決できます。

正解: A. スナップショットの「共有」設定でアカウントBのIDを指定して共有する

正解の根拠・詳細解説

・BRDSスナップショットのクロスアカウント共有には：①スナップショットの共有設定でアカウントBのIDを指定する（またはパブリック共有）、②スナップショットがKMSカスタマーマネージドキー（CMK）で暗号化されている場合、そのKMSキーのキーポリシーにアカウントBのプリンシパルへのkms:Describekey・kms:CreateGrant権限を追加する必要があります。AWSマネージドキーではクロスアカウント共有はできないため、CMKを使用する必要があります。

正解: A. 開発OUと本番OUに別々のSCPを適用してEC2タイプとEBSタイプを制限する

正解の根拠・詳細解説

SCPはOU単位で異なるポリシーを適用できるため、OUごとに必要な制限を設定できます。ec2:RunInstancesアクションにaws:RequestedRegionやec2:InstanceTypeの条件キーを使用してインスタンスタイプを制限できます。EBSボリュームタイプの制限にはec2:VolumeType条件キーを使用します。AWS Config Rulesは検出・通知はできますが予防的制御（起動そのものを阻止）はできません。SCPは組織全体に一貫して予防的制御を提供します。

正解: B. SCPでaws:RequestedRegion条件を使用してEUアカウントのOUではEUリージョン（eu-*）以外のリソース作成を拒否する

正解の根拠・詳細解説

SCPのaws:RequestedRegion条件キーを使用することで、組織内の特定のOUまたはアカウントで使用できるAWSリージョンを強制的に制限できます。「eu-west-1、eu-central-1等のEUリージョン以外を拒否」するSCPをEU向けOUに適用すれば、rootユーザーを含む全ユーザーがEU域外にリソースを作成できなくなります。これはデータ主権要件の技術的保証として有効で、個別IAMポリシー管理より確実です。

正解: B. Route 53 Profilesを使用してプライベートホストゾーンをAWS RAMで複数アカウントのVPCと共有する

正解の根拠・詳細解説

Route 53 Profiles（2024年機能）を使用すると、プライベートホストゾーン・リゾルバールール・DNS Firewallポリシーをプロファイルとして定義し、AWS RAMを通じて複数アカウントのVPCと共有できます。VPCをプロファイルに関連付けるだけで、共有されたプライベートホストゾーンが自動的に使用可能になります。ホストゾーンの複製は管理コストが高く、更新時の一貫性維持が困難です。

正解: A. メンバーアカウントでAWS Configが有効化されていない

正解の根拠・詳細解説

組織適合パック（Organization Conformance Pack）は、対象メンバーアカウントで既にAWS Configが有効になっていることが前提です。AWS Configが無効なアカウントには展開できません。管理アカウントからはConfig自体の有効化は行われず、Configレコーダーが設定・有効化されている必要があります。展開前に全対象アカウントでConfigが有効化されているか確認し、必要であればCloudFormation StackSetsで先にConfigを有効化します。

正解: B. Systems Manager Quick Setupを使用してOrganizations全体にSSMエージェント、パッチポリシー、インベントリ収集を一括設定する

正解の根拠・詳細解説

AWS Systems Manager Quick Setupは、マルチアカウント・マルチリージョン環境全体にSSMの設定を一括適用できる機能です。AWS Organizationsと統合されており、指定したOUや全組織に対して：SSMエージェントの自動インストール・更新、EC2インスタンスへのIAMロール付与、パッチマネージャーポリシーの設定、インベントリ収集の有効化を自動実行します。これにより数百のアカウントへの手動設定作業を排除できます。

正解: B. Compute Savings Plans（EC2・Fargate・Lambda対応、リージョン・インスタンスタイプ変更可）

正解の根拠・詳細解説

Compute Savings Plansは最も柔軟なSavings Plansで：①EC2（全インスタンスタイプ・全リージョン）、AWS Fargate、AWS Lambda対応。②リージョン・インスタンスファミリー・OS・テナンシー変更に自動適用。③AWS Organizationsの一括請求ファミリー全体で自動共有。EC2 Instance Savings Plansはより高い割引率ですが特定のインスタンスファミリーとリージョンに限定されます。Compute Savings Plansは66%割引（リザーブドインスタンス比で少し低いですが柔軟性が大幅に高い）。

正解: B. Warm Standby（DR環境を最小構成で常時稼働させてフェイルオーバー時に拡張）

正解の根拠・詳細解説

DR戦略の比較：①Backup & Restore：最安価だがRTO数時間〜数日。②Pilot Light：コアのみ稼働でRTO 1時間程度。③Warm Standby：最小構成で常時稼働、RTO数分〜15分、コスト中程度。④Multi-Site：最高可用性だが高コスト。RTO 15分・RPO 1時間の要件にはWarm Standbyが最適です。Pilot LightはRTOが15分以内に収まらない可能性があり、Multi-SiteはRTO要件を満たしますが過剰投資になります。

正解: C. Amazon DynamoDB Global Tables（マルチリージョン・マルチアクティブ）

正解の根拠・詳細解説

世界5拠点でデータの読み書き（マルチアクティブ）が必要な場合、DynamoDB Global Tablesが最適です。Global Tablesはマルチリージョン・マルチアクティブ（全リージョンで読み書き可能）を提供し、リージョン間のレプリケーション遅延は通常1秒未満です。Aurora Global DatabaseはWrite操作を1つのプライマリリージョンのみ、Aurora Limitless（プレビュー）を除き複数リージョンでの書き込みには対応していません。DynamoDBはサーバーレスでスケーラビリティも優れています。

正解: B. Amazon SNSトピックへイベントパブリッシュし、各サービスがSQSキュー経由でサブスクライブするFan-outパターン

正解の根拠・詳細解説

SNS→SQS Fan-outパターンは：①注文サービスはSNSトピックにイベントを1回パブリッシュするだけ（疎結合）。②各ダウンストリームサービス（在庫・支払い・通知）はそれぞれ独自のSQSキューでSNSをサブスクライブ。③各サービスは独立してSQSからメッセージを処理（サービス障害が他に波及しない）。④SQSのデッドレターキュー（DLQ）で失敗メッセージを安全に処理。Step Functionsは同期オーケストレーションで障害時に全フローが停止する可能性があります。

正解: A. Amazon API Gateway（REST API）+ Lambda + AWS WAF + API Keyによる使用量プラン

正解の根拠・詳細解説

API Gatewayは：①APIキー管理・使用量プラン（レート制限・バースト制限）のネイティブサポート。②AWS WAFとの統合（OWASP Top 10対策のマネージドルールグループ）。③Lambdaとのネイティブ統合でサーバーレスAPIを構築。④デフォルトのクォータ調整で大量トラフィックに対応。秒間10万リクエストはAWS Supportへのクォータ増加リクエストで対応可能。ALBはAPIキー管理機能がなく、追加実装が必要です。AppSyncはGraphQL専用です。

正解: A. Amazon ECS + AWS App Mesh（Envoy Proxyサイドカー）+ AWS X-Ray

正解の根拠・詳細解説

AWS App Meshは、サービスメッシュとしてEnvoy Proxyをサイドカーとして各コンテナに注入し、相互TLS・トラフィックシェーピング（重み付けルーティング・サーキットブレーカー）・オブザーバビリティ（X-Rayとの統合でトレーシング）を提供します。ECSとEKS両方で使用可能です。VPC LatticeはAWS管理のサービスネットワーキングレイヤーですが、サービスメッシュのようなきめ細かいトラフィック管理機能は異なります。

正解: B. Amazon Kinesis Data Streams → Kinesis Data Analytics（Apache Flink）→ Lambda → SageMakerエンドポイント

正解の根拠・詳細解説

リアルタイム（10秒以内）処理のベストアーキテクチャ：①Kinesis Data Streamsは大量データを低レイテンシ（数秒）でストリーミング収集。②Kinesis Data Analytics（Managed Apache Flink）はリアルタイムウィンドウ集計・異常検知前処理を10秒以内で実行可能。③Lambdaで前処理したデータをSageMakerの不正検出エンドポイントに送信。SQSはバッチ処理向きで高スループットリアルタイム処理には不適切。Firehose→S3→Glueはバッチ処理でレイテンシが分単位になります。

正解: A. S3バケットの保存時暗号化（AES-256またはSSE-KMS）を有効化する

正解の根拠・詳細解説

・DHIPAA準拠に最も重要な要素：①技術的保護措置：PHIの保存時暗号化（SSE-KMS推奨）、転送時暗号化（TLS）、アクセスコントロール（IAM最小権限）。②管理的保護措置：AWSとのBAA（Business Associate Agreement）の締結。HIPAAの対象となるサービスでPHIを処理・保存するには、AWSとBAAを結ぶ必要があります。S3のパブリックアクセス遮断も重要ですが、BAAなしではHIPAA準拠は成立しません。リージョン制限はHIPAAの要件ではありません。

正解: B. Auto ScalingグループにScheduled Scaling（月末前の予定スケールアウト）と動的スケーリングポリシーを組み合わせる

正解の根拠・詳細解説

予測可能なピークパターンには、Scheduled Scaling（月末の日時でEC2をプリウォーム）と動的スケーリング（実際のトラフィックに応じた追加スケール）の組み合わせが最適です。ScheduledスケーリングでAuto Scalingグループのmin/max/desiredを月末前に増加設定し、CloudWatchアラームベースの動的スケーリングで実際の負荷に対応します。Predictive Scalingも有効です。常時大型インスタンス稼働は過剰コスト、SQSバッファリングはリアルタイム性が損なわれます。

正解: A. Sagaパターン（各サービスのローカルトランザクションを連鎖させ、失敗時は補償トランザクションで巻き戻す）

正解の根拠・詳細解説

Sagaパターンは分散トランザクションの管理に適したパターンです。各マイクロサービスはローカルトランザクションを実行してイベントをパブリッシュします。次のサービスがイベントをトリガーに処理を進め、途中で失敗した場合は補償トランザクション（元の処理を打ち消す逆処理）で整合性を回復します。AWS Step Functionsを使ったオーケストレーション型SagaやEventBridgeを使ったコレオグラフィ型Sagaで実装できます。共有データベースはマイクロサービスの独立性を損ないます。

正解: C. 両方にElastiCache for Redis（Serverless）を使用する

正解の根拠・詳細解説

実際には両方にElastiCache for Redis（Serverless）を使用することが最も実用的です。Redis Serverlessは：①製品カタログ：TTLなしのシンプルなキャッシュとして利用可能。②セッション：TTL設定（EXPIRE）でセッション期限管理、データ型（Hash）でセッション情報の構造化。③フェイルオーバー・レプリケーション・バックアップのフルマネージドサポート。ただし問題文の意図として、Memcachedはシンプルキャッシュ、Redisは高機能という使い分けを理解することが重要です。

正解: B. SageMaker訓練ジョブのS3入力モードを「Pipe Mode」に設定してS3から直接ストリーミング

正解の根拠・詳細解説

SageMakerのPipe Modeは、訓練データをS3から訓練インスタンスへストリーミングしてリアルタイムに供給します。データを全コピーせずに訓練を開始できるため、スタートアップ時間が短縮され、ストレージコストも不要です。大規模データセットに特に効果的です。FSx for LustreはS3と自動同期できる高性能ファイルシステムですが、初期同期に時間がかかります。EBSへのコピーはインスタンスタイプの容量制限があります。

正解: B. AWS Secrets ManagerのシークレットをPodにマウントするために、Secrets Store CSI Driverとサービスアカウントへのインラインポリシー（IRSA）を使用する

正解の根拠・詳細解説

EKSのベストプラクティス：①IRSA（IAM Roles for Service Accounts）でPod単位のIAMロールを割り当て（最小権限）。②Secrets Store CSI Driver（AWS版：secrets-store-csi-driver-provider-aws）を使用してSecrets ManagerまたはSSMパラメータストアのシークレットをPodのファイルシステムとしてマウント。③シークレットの自動ローテーションに対応（Secrets Manager側でローテーション→CSI Drriverが同期）。ノードのインスタンスプロファイルに広い権限を付与すると全Podが同じ権限を持ち最小権限原則に違反します。

正解: B. Amazon CloudFrontでHTMLページを積極的にキャッシュ（TTL 1分）し、オリジンにはALB+Auto Scalingを使用する。静的アセットはS3+CloudFrontで配信する

正解の根拠・詳細解説

ニュースサイトのトラフィックスパイク対策：CloudFrontはグローバルに450以上のエッジロケーションを持ち、同一コンテンツへのリクエストをキャッシュすることでオリジンへの到達リクエストを大幅に削減します（キャッシュヒット率90%以上を目指す）。HTMLをTTL 1分でキャッシュするだけで、50万リクエスト/秒でもオリジンへは5万リクエスト/秒程度に削減できます。静的アセット（CSS/JS/画像）はS3からCloudFront経由で配信するとオリジンサーバーの負荷をほぼゼロにできます。

正解: B. AWS CloudTrailでKMS APIコール（Decrypt、GenerateDataKey等）を記録し、CloudWatch Logsに配信して異常なキー使用をアラート設定する

正解の根拠・詳細解説

KMS CMKの全ての暗号化API呼び出し（Encrypt、Decrypt、GenerateDataKey、ReEncrypt等）はAWS CloudTrailに自動記録されます。CloudTrailログをCloudWatch Logsに配信してメトリクスフィルターとアラームを設定することで、異常なキー使用（大量のDecryptコール、予期しないプリンシパルからのアクセス等）をリアルタイムに検出できます。これがKMSキー使用の監査に関するAWSのベストプラクティスです。S3アクセスログはS3操作のみを記録し、KMS呼び出しの詳細は含まれません。

正解: A. AWS IoT Core → Kinesis Data Streams → Kinesis Data Analytics（リアルタイム）+ Kinesis Firehose → S3（長期保存）→ Athena（長期分析）

正解の根拠・詳細解説

IoTデータパイプラインのベストプラクティス：①AWS IoT Core：100万台のデバイスからの安全なMQTT/HTTPS接続。②Kinesis Data Streams：秒間100万件のスループットに対応。③Kinesis Data Analytics（Flink）：直近1時間のリアルタイムウィンドウ分析。④Kinesis Firehose：S3への自動バッチ配信・圧縮・暗号化。⑤S3 Intelligent-Tiering：アクセスパターンに応じた自動ストレージ階層化でコスト最適化。⑥Athena：S3上のデータをサーバーレスSQLで長期分析。RDSは大量IoTデータの保存に不向きです。

正解: C. AWS Fargateタスク（ECS）に移行してコンテナで長時間バッチを実行する

正解の根拠・詳細解説

Lambdaの最大タイムアウトは15分で変更不可です。最小の変更でLambdaの制約を回避するには：最も実用的な方法はAWS Fargate（ECS）への移行です。FargateはLambdaと同様にサーバーレスでコンテナを実行でき、タイムアウト制限がなく、必要なメモリ・CPUを柔軟に設定できます。EventBridgeやSQSから起動可能で、Lambdaからの移行コストが比較的少ないです。Step FunctionsのWaitForTaskToken パターンも有効ですが、処理の分割・状態管理のリファクタリングが必要です。

正解: B. Amazon Aurora PostgreSQLのロジカルレプリケーション → AWS DMS（継続的レプリケーション）→ Amazon Redshift

正解の根拠・詳細解説

30秒以内の低遅延レプリケーションにはAWS DMS（Database Migration Service）の継続的レプリケーション（CDC: Change Data Capture）が最適です。Aurora PostgreSQLのWAL（Write-Ahead Log）からリアルタイムに変更を取得し、Redshiftに継続的に適用します。DMS継続的レプリケーションの遅延は通常数秒〜30秒程度です。Glueジョブの5分スケジュールは遅延要件を満たせず、S3エクスポートは毎時で問題外です。

正解: B. LambdaからDynamoDB呼び出しにエクスポネンシャルバックオフ付きリトライ、Circuit BreakerパターンをAWS Lambda PowerToolsで実装する

正解の根拠・詳細解説

DynamoDBスロットリング時の耐障害性向上：①エクスポネンシャルバックオフ付きリトライ：スロットリングエラー（429）時に待機時間を指数的に増加させながらリトライ（AWS SDKはデフォルトでこれを実装）。②Circuit Breakerパターン：連続失敗時に一時的にDynamoDB呼び出しをスキップしてフォールバックレスポンスを返す。③AWS Lambda PowerToolsのUtilityとして実装可能。④DynamoDB DAXを追加してキャッシュ層を設けることも有効。タイムアウト延長はユーザー体験を悪化させます。

正解: C. Amazon Neptune（グラフデータベース）でフォロー関係をグラフとしてモデリングする

正解の根拠・詳細解説

「フォロー関係」「友達の友達」「レコメンデーション」はグラフ構造のユースケースです。Amazon NeptuneはグラフデータベースでGremlin（プロパティグラフ）とSPARQL（RDF）をサポートし、「AのフォロワーをフォローしているユーザーでBがまだフォローしていない人」などの複雑なグラフトラバーサルを効率的に処理できます。RDSの再帰JOINは深いグラフ探索で指数的に遅くなります。DynamoDBは親子関係の1:Nには適しますが、複雑なグラフトラバーサルには向いていません。

正解: B. AWS Global Accelerator の標準アクセラレータ

正解の根拠・詳細解説

Global Accelerator は Anycast IP を使用してユーザーを最寄りのエッジロケーションに誘導し、AWS バックボーンネットワーク経由で最適リージョンにルーティングします。ヘルスチェックに基づく自動フェイルオーバーも提供します。Route 53 レイテンシルーティングはDNS TTLの遅延があり即時フェイルオーバーが難しいです。CloudFront はHTTPコンテンツ配信向けで、TCP/UDP任意トラフィックには不向きです。

正解: A. Lambda 関数のリザーブド同時実行数を設定する

正解の根拠・詳細解説

リザーブド同時実行数（Reserved Concurrency）を設定すると、その関数に割り当てられる同時実行数の上限を制限できます。これにより他のワークロードへの影響を防ぎます。超過分は SQS キューに残り（スロットリング）、後続処理でリトライされます。プロビジョンド同時実行数はコールドスタート対策で同時実行上限とは異なります。

正解: B. Amazon EKS with Fargate

正解の根拠・詳細解説

EKS（Elastic Kubernetes Service）はマネージドKubernetesサービスで、既存のKubernetesマニフェストをそのまま使用できます。Fargate と組み合わせることでノード管理が不要になりインフラ負担を最小化できます。ECS はAWS独自のオーケストレーターでKubernetesとの互換性がありません。App Runner はシンプルなWebアプリ向きで、複雑なKubernetesワークロードには不向きです。

正解: B. AWS WAF + CloudFront + AWS Shield Advanced + DRT サポート

正解の根拠・詳細解説

Shield Advanced はL3/L4/L7の大規模DDoS保護を提供し、DDoS対応チーム（DRT）のサポートと攻撃によるスケーリングコストの払い戻しが受けられます（コスト転嫁）。WAF でOWASP Top 10対策、CloudFront でエッジでのフィルタリングが可能です。Shield Standard はL3/L4のみ対応で自動保護は限定的です。

正解: B. Aurora Serverless v2

正解の根拠・詳細解説

Aurora Serverless v2 は Aurora 互換のリレーショナルデータベースで、ACU（Aurora Capacity Units）単位でほぼ即時にスケールアップ・ダウンします。最小 ACU を 0 に設定するとアイドル時にほぼ無料になります。DynamoDB は NoSQL であり複雑なSQL処理が苦手です。RDS は事前プロビジョニングが必要でアイドル時のコストが発生します。Redshift は OLAP 向けでリアルタイム OLTP には不向きです。

正解: B. Amazon Macie を有効化 → EventBridge ルール → SNS 通知

正解の根拠・詳細解説

Amazon Macie は機械学習を使って S3 内の PII（個人識別情報）を自動検出する専用サービスです。検出結果は EventBridge イベントとして発行されるため、EventBridge ルールで SNS に転送しセキュリティチームへ通知できます。カスタム Lambda + Comprehend も技術的には可能ですが、Macie は S3 PII 検出に特化しており運用コストが低く正解として最適です。

正解: B. Systems Manager Change Manager で変更テンプレートと承認ワークフローを設定する

正解の根拠・詳細解説

Systems Manager Change Manager は運用上の変更を安全に管理するためのサービスです。変更テンプレートに承認者を設定し、変更リクエストが作成されると承認フローが開始されます。承認者の記録、変更履歴、変更ログが自動的に保管され、コンプライアンス要件を満たします。Patch Baseline の自動承認無効化だけでは承認ワークフローや履歴記録ができません。

正解: B. Amazon Inspector v2

正解の根拠・詳細解説

Amazon Inspector v2 は EC2（SSM Agent 経由でエージェントレス対応）、Lambda 関数、ECR コンテナイメージのソフトウェア脆弱性（CVE）と設定ミスを継続的にスキャンします。Inspector v1 と異なり手動スキャン不要です。GuardDuty は脅威検出（不正アクセス、マルウェア）が主目的で脆弱性スキャンではありません。Security Hub は各サービスの結果を集約するSIEMライクなサービスです。

正解: B. 地域コードを Distribution Key、日付列を Sort Key に設定する

正解の根拠・詳細解説

Distribution Key（分散キー）はテーブルのデータを各ノードに均等に分散し、JOINのシャッフルを削減します。Sort Key（ソートキー）は列の値で物理的にデータを並べるため、範囲フィルター時にブロックスキャンをスキップ（ゾーンマップ活用）できます。日付範囲フィルターには Sort Key が非常に効果的です。Concurrency Scaling は同時実行数の問題には有効ですが、単一クエリのスキャン改善には寄与しません。

正解: B. セッションデータを ElastiCache（Redis）に外部化する

正解の根拠・詳細解説

セッションデータを ElastiCache（Redis）に外部化するのがベストプラクティスです。どのインスタンスにルーティングされてもセッションデータを共有できます。スティッキーセッション（A）も機能しますが、スケールインでインスタンスが削除された場合にセッションが失われるリスクがあります。本番環境ではセッションの外部化（B）が推奨されます。

正解: B. データを Apache Parquet 形式に変換し、日付でパーティション分割する

正解の根拠・詳細解説

Athena は S3 のスキャンデータ量に応じて課金されます。Parquet 形式は列指向圧縮形式でスキャンデータ量を大幅に削減（CSV比で最大87%削減も可能）します。パーティション分割により WHERE 句の日付フィルターでスキャン対象ファイルを絞り込めます。この2つの組み合わせがAthenaクエリ最適化の定番です。Partition Projection を併用するとパーティションメタデータ管理が不要になります。

正解: A. Amazon Connect + Transcribe + Comprehend

正解の根拠・詳細解説

Amazon Connect はコールセンターサービスです。Amazon Transcribe が音声をリアルタイムでテキスト化（文字起こし）し、Amazon Comprehend がテキストの感情分析（Sentiment Analysis）とエンティティ分類を行います。Polly は音声合成（テキスト→音声）で逆方向です。Rekognition は画像・動画認識サービスです。Comprehend Medical は医療特化版です。

正解: B. VPC Flow Logs を S3 または CloudWatch Logs に送信し、Athena または Insights でクエリする

正解の根拠・詳細解説

VPC Flow Logs は VPC 内の IP トラフィック（送信元IP、送信先IP、ポート、プロトコル、バイト数、パケット数、許可/拒否）を記録します。S3 に送信して Athena でクエリするか、CloudWatch Logs Insights でインタラクティブに分析できます。CloudTrail は API コール記録であり、ネットワーク通信の詳細は記録しません。GuardDuty は機械学習による異常検知で、詳細な通信ログ分析ではありません。

正解: B. 注文処理：Standard Workflow、イベント処理：Express Workflow（非同期）

正解の根拠・詳細解説

Standard Workflow は最大1年間の実行が可能で、実行履歴を完全に保存し、人間による承認（waitForTaskToken）パターンに対応します。長時間・高信頼性処理向けです。Express Workflow（非同期）は最大5分の高スループット処理向けで、1秒あたり10万件以上の実行が可能です。CloudWatch Logs への記録は可能ですが実行履歴は永続保存されません。コストは Express の方が大幅に安いです。

正解: B. Lambda Nitro Enclaves を使用して分離された暗号化計算環境で処理する

正解の根拠・詳細解説

Nitro Enclaves は EC2/Lambda から完全に分離された Trusted Execution Environment（TEE）を提供します。処理中のデータはエンクレーブの外部（Lambda コード含む）からアクセスできません。暗号化アテステーションにより処理環境の正当性を証明できます。環境変数の KMS 暗号化やネットワーク暗号化は保存・転送中の保護であり、処理中（In-Use）の暗号化ではありません。

正解: B. MediaLive + MediaPackage + CloudFront

正解の根拠・詳細解説

AWS Elemental MediaLive はリアルタイムライブ映像エンコーダー（トランスコーダー）です。MediaPackage はリアルタイムにHLS/DASH/CMAF等にパッケージングし、DRM 保護も提供します。CloudFront でグローバル配信します。MediaConvert（D）は VOD（Video on Demand）向けで、ライブリアルタイムには対応していません。Elastic Transcoder は旧世代サービスで新規利用は非推奨です。

正解: B. AWS Compute Optimizer

正解の根拠・詳細解説

AWS Compute Optimizer は機械学習を使って EC2、Auto Scaling グループ、Lambda、ECS on Fargate のリソース使用状況を分析し、最適なインスタンスタイプや設定を推奨します。CPU とメモリ（CloudWatch エージェント要）の両方を分析します。Trusted Advisor のコスト最適化は低使用率インスタンスの検出ができますが、推奨タイプの精度が低いです。Cost Explorer の Right Sizing も類似機能ですが Compute Optimizer の方が詳細です。

正解: B. AWS Instance Scheduler on AWS ソリューションをデプロイする

正解の根拠・詳細解説

AWS Instance Scheduler on AWS は AWS が提供するソリューション（CloudFormation テンプレート）で、複数の EC2・RDS インスタンスのスケジュール管理をタグベースで一元管理できます。タイムゾーン対応、複数アカウント対応と運用性が高いです。Lambda+CloudWatch Events（A）も機能しますが個別スクリプト管理が必要です。Auto Scaling Scheduled Action（C）はスケールイン・アウトで停止には別途設定が必要です。

正解: B. S3 ライフサイクルポリシーで各ストレージクラスへの移行ルールを設定する

正解の根拠・詳細解説

S3 ライフサイクルポリシーは経過日数に基づいてオブジェクトを別のストレージクラスへ自動的に移行（またはExpire削除）するルールを設定できます。Standard → Standard-IA → Glacier Instant Retrieval → Glacier Deep Archive の段階的移行が設定可能です。Intelligent-Tiering は自動最適化ですがアクセスパターンが明確な場合はライフサイクルポリシーの方が予測可能なコストになります。

正解: B. バッチ処理開始時にインスタンスにスケールイン保護を設定し、完了後に解除する

正解の根拠・詳細解説

インスタンスレベルのスケールイン保護をバッチ処理開始時に API（set-instance-protection）で設定し、処理完了後に解除するのが最適です。処理中のインスタンスのみ保護されます。全インスタンスへの保護（A）は Auto Scaling が機能しなくなります。Lifecycle Hook（D）は保護ではなく通知と一時停止で、最大48時間しか延長できません。

正解: B. AWS X-Ray でサービスマップとトレースを分析する

正解の根拠・詳細解説

AWS X-Ray はアプリケーションのリクエストをエンドツーエンドでトレースし、各サービス間のレイテンシをサービスマップとして可視化します。P99 などのパーセンタイルレイテンシの分析、エラー率の確認、ボトルネックの特定に最適です。X-Ray SDK をアプリに組み込むか、X-Ray デーモン/Distro for OpenTelemetry を使用します。CloudWatch Logs は構造化ログの分析に有効ですが、分散トレーシングのような自動可視化は提供しません。

正解: A. AWS Systems Manager Patch Manager with Patch Baseline

正解の根拠・詳細解説

SSM Patch Manager は Patch Baseline（承認ルール）とメンテナンスウィンドウを組み合わせてパッチを自動適用します。パッチ適用前後のスナップショット取得もサポートし、Patch Baseline でテスト・本番環境を分けた段階的展開も可能です。Patch Compliance レポートで未パッチインスタンスを特定できます。Config ルールはコンプライアンス評価のみで自動修復（Remediation）には追加設定が必要です。

正解: B. RDS Performance Insights でトップ SQL を分析する

正解の根拠・詳細解説

RDS Performance Insights はデータベース負荷をグラフで可視化し、どの SQL クエリが最もデータベースをビジー状態にしているかを特定できます。DB Load（AAS）を SQL 別、待機イベント別、ユーザー別に分解して表示します。追加エージェント不要で、RDS のオプションとして有効化できます（一部 DB エンジンは無料）。General Log は全クエリを記録するため I/O への影響が大きいです。Enhanced Monitoring は OS メトリクスです。

正解: C. Compute Savings Plans（1年、全額前払い）

正解の根拠・詳細解説

Compute Savings Plans はインスタンスファミリー・リージョン・OS・テナンシーを問わず EC2・Lambda・Fargate すべてに適用可能で最大66%割引です。インスタンスタイプ変更に完全対応します。EC2 Instance Savings Plans（D）は特定リージョン内のインスタンスファミリーへの適用に限定されますが割引率は最大72%と高めです。Standard RI はインスタンスタイプ変更が困難で、Convertible RI は変更可能ですが割引率が低くなります。

正解: B. CloudWatch Logs のメトリクスフィルターでカスタムメトリクスを作成しアラームを設定する

正解の根拠・詳細解説

CloudWatch Logs メトリクスフィルターを使うと、ログストリームから特定のパターン（エラー文字列等）をマッチさせてカスタムメトリクスを自動作成できます。このカスタムメトリクスに CloudWatch アラームを設定して SNS に通知できます。Lambda 組み込みメトリクスの Errors（A）はハンドルされた例外のみを計測し、カスタムエラーはカウントされません。Kinesis + Athena はリアルタイムアラートには不向きで構成が複雑です。

正解: B. AWS Config Rules（s3-bucket-public-read-prohibited など）+ Systems Manager Automation で自動修復

正解の根拠・詳細解説

AWS Config Rules は設定変更をトリガーに継続的に評価し、非準拠リソースを検出します。Remediation Actions（SSM Automation ドキュメント）を関連付けることで非準拠を自動修復できます。例えば s3-bucket-public-read-prohibited が非準拠になったら SSM Automation でパブリックアクセスブロックを自動設定できます。SCP（D）は予防的制御であり既存バケットの違反検出・修復には対応しません。

正解: B. AWS Trusted Advisor

正解の根拠・詳細解説

AWS Trusted Advisor はセキュリティ、コスト最適化、パフォーマンス、耐障害性、サービス制限の 5 カテゴリについて事前定義のベストプラクティスチェックを実行します。IAM 認証情報の有効期限切れ、S3 バケットのパブリックアクセス、低使用率 EC2 インスタンス等をすぐに確認できます。追加設定不要です（一部チェックはビジネス/エンタープライズサポートが必要）。Config は継続的設定管理、Security Hub はセキュリティ集約、Well-Architected Tool は手動レビューです。

正解: B. AWS Budgets でコスト予算を作成し、アクション（SNS 通知 + IAM ポリシーの切り替え）を設定する

正解の根拠・詳細解説

AWS Budgets はコスト・使用量・RI・Savings Plans のカバレッジに対して閾値アラートを設定できます。Budget Actions 機能を使うと、閾値超過時に IAM ポリシーの適用（サービスアクセス制限）や EC2/RDS のインスタンス停止を自動実行できます。80% と 100% の2段階アラートも設定可能です。CloudWatch Billing アラームは通知のみで自動アクションはできません。SCP はコスト制限機能を持っていません。

正解: B. AWS Lambda Power Tuning ツールで各メモリ設定の実行時間・コストを計測する

正解の根拠・詳細解説

AWS Lambda Power Tuning は Step Functions で実装されたオープンソースツールで、Lambda 関数を異なるメモリ設定で並列実行し、実行時間・コスト・最適ポイントをグラフで可視化します。コスト最適・速度最優先・バランス重視の3つの最適化戦略を選択できます。CloudWatch に Lambda のメモリ使用率メトリクスは標準では存在しません（カスタムメトリクスが必要）。

正解: C. gp2 から gp3 に変更して IOPS を独立して設定する

正解の根拠・詳細解説

gp3 は gp2 の後継ボリュームタイプで、IOPS（最大 16,000）とスループット（最大 1,000 MiB/s）をストレージ容量と独立して設定できます。バースト機構に依存しない安定したベースライン IOPS が得られます。gp3 は同スペックで gp2 より約 20% コスト低減します。io1/io2（B）はさらに高 IOPS が必要な場合向けでコストが高いです。gp2 のサイズ増加はコスト増加につながりバースト解消の根本解決ではありません。

正解: B. パスパターン別にキャッシュ動作（Cache Behavior）を設定し、ユーザー固有パスの TTL を 0 にする

正解の根拠・詳細解説

CloudFront はパスパターンごとに個別のキャッシュ動作（Cache Behavior）を設定できます。共有コンテンツパス（例：/api/public/*）には適切な TTL を設定し、ユーザー固有パス（例：/api/user/*）の Cache Behavior で最小/最大/デフォルト TTL を 0 に設定することでキャッシュをバイパスできます。Lambda@Edge は必要以上に複雑です。

正解: B. Auto Scaling を有効化して最小キャパシティを下げる

正解の根拠・詳細解説

DynamoDB Auto Scaling（Application Auto Scaling）を有効化し、最小 RCU/WCU を夜間・週末に見合った値に設定します。これにより Provisioned モードのメリット（予測可能なコスト）を維持しつつ、アイドル時のコストを大幅削減できます。On-Demand（A）はスパイク対応に優れますが、大量アクセス時には Provisioned Auto Scaling より割高になる場合があります。トラフィックパターンが予測可能なためAuto Scalingが適切です。

正解: B. ElastiCache for Redis（シングルスレッド、データ構造豊富）

正解の根拠・詳細解説

Redis はソート済みセット（Sorted Sets / ZSETs）をネイティブデータ構造として提供しており、リアルタイムランキングに最適です。Redis Cluster による水平スケールも可能で、セッション管理にも対応します。Memcached はシンプルなキャッシュに特化し、リスト・ハッシュ・ソート済みセット等の高度なデータ構造をサポートしません。ランキング機能には必ず Redis を選択します。DAX は DynamoDB 専用のキャッシュです。

正解: B. パーティションキーを見直してシャード間に均等に分散する

正解の根拠・詳細解説

ProvisionedThroughputExceededException が「書き込み量は変わらないはず」で発生する場合、ホットパーティション（特定シャードへのデータ集中）が原因の可能性が高いです。パーティションキーが偏ると一部シャードの書き込み上限（1MB/s）を超えます。パーティションキーにランダムサフィックスを追加したり、より分散するキーを選択することで解消できます。シャード増加（A）は根本原因が偏りの場合は解決しません。

正解: A. Aurora Replica を作成しカスタムエンドポイントを設定して分析クエリをルーティングする

正解の根拠・詳細解説

Aurora は最大 15 台のリードレプリカをサポートし、カスタムエンドポイントを使って特定のレプリカグループにトラフィックを向けられます。分析専用レプリカ（例：r5 大メモリインスタンス）を作成し、カスタムエンドポイントで分析アプリからのクエリをそちらに向けることでプライマリへの影響を排除できます。Redshift（B）は有効ですが追加コストと ETL パイプラインが必要です。

正解: C. AWS Snowball Edge を使って物理デバイスでデータを輸送する

正解の根拠・詳細解説

Snowball Edge は 80TB（Storage Optimized）のデータを物理デバイスで輸送できます。100Mbps での 50TB 転送は約 46 日かかりますが、Snowball Edge なら数日で配送・取り込みが完了します。DataSync（A）と Transfer Acceleration（D）は帯域幅の制約を受けます。Direct Connect（B）は開通まで数週間〜数ヶ月かかりインフラコストが高いです。大量データの初回一括転送には Snowball が最適です。

正解: B. EC2 Fleet の Capacity-Optimized 戦略で複数インスタンスタイプを指定し、チェックポイント機能を実装する

正解の根拠・詳細解説

複数のインスタンスファミリー・タイプを指定した EC2 Fleet（または Auto Scaling グループ）で Capacity-Optimized 配分戦略を使うと、キャパシティが最も多いプールから起動され中断確率が低下します。さらにチェックポイント（中間状態の保存）を実装することで中断時に途中から再開できます。Spot Block（C）は最新の AWS では非推奨になっており新規では使用できません。多様なインスタンスタイプを使うことが Spot 中断耐性の基本です。

正解: B. SQS デッドレターキュー（DLQ）を設定して最大受信数超過メッセージを隔離する

正解の根拠・詳細解説

SQS デッドレターキュー（DLQ）は maxReceiveCount（最大受信回数）を超えたメッセージを自動的に別のキューに移動します。これにより毒メッセージ（Poison Pill）をメインキューから隔離し、調査・再処理ができます。Lambda Destination（A）はイベントソースマッピングの失敗時に機能しますが、Lambda 同期呼び出しのみ対象でSQSトリガーの場合は SQS DLQ が正しい仕組みです。

正解: B. EFS Lifecycle Management を有効化して低アクセスファイルを EFS-IA に自動移行する

正解の根拠・詳細解説

EFS Lifecycle Management を有効化すると、指定日数（7/14/30/60/90/180 日）以上アクセスされていないファイルを自動的に EFS-IA（Infrequent Access）ストレージクラスに移行します。EFS-IA は Standard の約 85% 安価です。アプリからのアクセスパスは変わらず透過的で、アクセス時は自動的に Standard に戻せます。設定はコンソールから数クリックで完了し、最小変更・最大効果の方法です。

正解: B. WAF のログを Kinesis Data Firehose 経由で S3 に送り Athena でクエリする

正解の根拠・詳細解説

AWS WAF のフルログを有効化すると、すべてのリクエスト（許可・ブロック・カウント）の詳細（URI、IP、ヘッダー、マッチしたルール等）をログ出力できます。Kinesis Data Firehose 経由で S3 に送り、Athena でクエリすることで詳細なアクセス分析が可能です。CloudWatch メトリクス（C）はカウント数のみで詳細情報がありません。ALB アクセスログ（D）はWAFのどのルールがブロックしたか記録しません。

正解: B. Network Load Balancer（NLB）

正解の根拠・詳細解説

Network Load Balancer（NLB）は TCP/UDP/TLS プロトコルをサポートします。固定 IP アドレス（Elastic IP の割り当て可能）を提供し、TLS ターミネーションも対応しています。ALB は HTTP/HTTPS のみでUDP非対応、固定IPもありません。GWLB はサードパーティアプライアンス（IDS/IPS 等）の展開に特化しています。CLB は旧世代で非推奨です。UDP + 固定IP + TLS の組み合わせは NLB の典型的なユースケースです。

正解: A. AWS Secrets Manager に認証情報を格納し自動ローテーションを設定する

正解の根拠・詳細解説

AWS Secrets Manager は RDS の認証情報自動ローテーション機能をネイティブに提供しています（Lambda 関数を自動生成）。Lambda からは GetSecretValue API で実行時に認証情報を取得します。ローテーション時に RDS のパスワードも同時に更新されます。Parameter Store（C）は自動ローテーション機能がなく手動設定が必要です。環境変数（D）はコードデプロイなしにローテーションできません。

正解: B. Organizations の SCP に aws:RequestedRegion Deny ポリシーを設定してルートまたは OU に適用する

正解の根拠・詳細解説

SCP（Service Control Policy）は Organizations 内の全アカウントに対して横断的に最大権限を制限できます。SCP に “Deny” + Condition “aws:RequestedRegion: NotStringEquals us-east-1/ap-northeast-1” を設定してルートまたは OU にアタッチすることで、全メンバーアカウントでの他リージョンリソース作成を禁止できます。IAM ポリシー（A）は個別アカウント管理が必要です。Config（C）は事後検出で予防ではありません。

正解: B. できない（SCP の Deny は継承され、子 OU の Allow で上書きできないため）

正解の根拠・詳細解説

SCP は継承チェーンで評価され、親レベルの Deny は子 OU の Allow ポリシーで上書きできません。IAM の評価ロジックと同様に「明示的 Deny は常に優先」されます。Root OU の SCP Deny は全子 OU・全アカウントに伝播します。管理アカウント（Management Account）は SCP が適用されない唯一の例外です（D は正確には管理アカウントに限り SCP 制限を受けません）。

正解: B. AWS Resource Access Manager（RAM）

正解の根拠・詳細解説

AWS Resource Access Manager（RAM）はサブネット（VPC Sharing）、Transit Gateway、Route 53 Resolver ルール、License Manager 設定、カスタム AMI などを Organizations 内の他アカウントや特定アカウントと共有できます。VPC Sharing では他アカウントが共有サブネットに自分のリソースをデプロイできます。VPC Peering はネットワーク接続であってリソース共有ではありません。StackSets はリソースのデプロイで共有ではありません。

正解: B. AWS Well-Architected Tool を使用してワークロードレビューを実施する

正解の根拠・詳細解説

AWS Well-Architected Tool は AWS Well-Architected Framework の 6 本の柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）に基づいてワークロードを評価します。質問への回答により高リスク（HRI）・中リスク（MRI）が特定され、改善推奨事項が提示されます。APN パートナーとの共有も可能です。無料で利用でき、定期レビューのベースラインとして最適です。

正解: B. コスト配分タグ（Cost Allocation Tags）を全リソースに付与し、有効化する

正解の根拠・詳細解説

コスト配分タグ（Cost Allocation Tags）を AWS コンソールで有効化すると、タグのキー・バリューが Cost Explorer の フィルタリング軸として利用できます。例えば “Department: Engineering” タグを EC2・S3・RDS 等に付与し有効化することで部門別コストを把握できます。IAM タグポリシー（C）はタグ付けを強制する仕組みですが、コスト配分タグの有効化とは別の設定です。併用が理想的です。

正解: B. EC2 Instance Metadata Service で Spot 中断通知をポーリングし、ALB のドレインを開始する

正解の根拠・詳細解説

Spot 中断通知は IMDS（Instance Metadata Service）の /latest/meta-data/spot/termination-time をポーリングすることで取得できます。通知取得後に ALB の Connection Draining（登録解除の遅延）を開始して進行中リクエストを完了させ、その後インスタンスを終了します。EventBridge（CloudWatch Events）でも spot-interruption を検出できますが（C）、ALB からのドレイン開始とセットで実装する（B）が完全な解です。

正解: C. 安定稼働：Standard RI または EC2 Instance Savings Plans、頻繁に変更：Compute Savings Plans

正解の根拠・詳細解説

安定稼働ワークロードには Standard RI（最大72%割引）または EC2 Instance Savings Plans（最大72%）が最大割引率を提供します。インスタンスタイプを頻繁に変更するワークロードには Compute Savings Plans（最大66%）がインスタンスファミリー・リージョン・OS に関わらず適用され最も柔軟です。Convertible RI（B）は変更可能ですが手動交換が必要で Savings Plans より柔軟性が低いです。

正解: C. S3 Intelligent-Tiering（アクセスパターン自動最適化）

正解の根拠・詳細解説

S3 Intelligent-Tiering はアクセスパターンが不明・変動するオブジェクトに最適です。頻繁アクセス層・低頻度アクセス層・アーカイブ層の間でオブジェクトを自動移動し、最適なコストを実現します。検索料金（取り出し料金）がかからず、自動移行の管理コストも不要です。Standard-IA（B）は低アクセスが確実なオブジェクト向けで、頻繁アクセス時はコストが高くなります。One Zone-IA はデータ耐久性が標準より低く重要データには不向きです。

正解: B. リードレプリカを作成してレポートクエリをオフロードし、プライマリを小さいインスタンスに変更する

正解の根拠・詳細解説

リードレプリカにレポートクエリをオフロードすることで、プライマリ（OLTP）への影響がなくなります。プライマリは OLTP のみの小さいインスタンスに変更することでコスト削減もできます。Multi-AZ の解除（A）は高可用性を失うリスクがあり推奨されません。RI への変更（C）はコスト削減には有効ですが性能問題を解決しません。B は性能とコストの両方を改善する最善策です。

正解: B. S3 VPC エンドポイント（Gateway タイプ）を作成して S3 アクセスを NAT Gateway から切り離す

正解の根拠・詳細解説

S3 Gateway VPC エンドポイントは無料で作成でき、S3 へのトラフィックを VPC 内部（AWS バックボーン）でルーティングします。NAT Gateway を経由しないため NAT Gateway のデータ処理料金（$0.062/GB）が不要になります。S3 へのアクセスが多い場合、大幅なコスト削減が期待できます。DynamoDB も同様に Gateway エンドポイントが使用可能です（どちらも無料）。

正解: B. S3 をオリジンとした CloudFront ディストリビューションを構成する

正解の根拠・詳細解説

CloudFront を S3 の前に配置すると、キャッシュヒット時は S3 からデータを取得せず、CloudFront エッジから直接配信されます。S3 のアウトバウンド転送費用（$0.09/GB〜）より CloudFront のアウトバウンド費用（$0.085/GB〜）の方が安く、キャッシュヒット率が高ければ大幅なコスト削減が可能です。また S3 への Origin アクセスは無料です。Transfer Acceleration（A）は転送を高速化しますがコスト削減効果はありません。

正解: B. Lambda のアーキテクチャを arm64（Graviton2）に変更する

正解の根拠・詳細解説

Lambda の arm64（AWS Graviton2）アーキテクチャは x86_64 に比べて同等以上のパフォーマンスで約 20% コストが低減されます。ほとんどの場合、ランタイム設定の変更とデプロイパッケージの再ビルドのみで移行可能です（コンテナイメージは ARM 向け再ビルドが必要）。Java、Python、Node.js 等で広く対応しています。Lambda Power Tuning で事前検証することを推奨します。

正解: A. Fargate の Spot CapacityProvider を使用する

正解の根拠・詳細解説

ECS Fargate Spot は標準 Fargate より最大 70% 安価です。中断耐性があるバッチ処理には最適です。Fargate の場合、インフラ管理不要の利便性を維持したまま Spot 価格を利用できます。AWS Batch（D）も有効ですが、既存の ECS Fargate 構成からの変更コストが大きいです。ECS の Fargate Spot CapacityProvider を設定するだけで既存の ECS 構成をほぼそのまま使えます。

正解: B. Step Functions Express Workflow（非同期）に移行する

正解の根拠・詳細解説

Step Functions Express Workflow は Standard Workflow と比べて大幅に安価です。Standard は 1,000 状態遷移あたり $0.025 なのに対し、Express は 100 万リクエスト $1.00 ＋期間料金と、大量の短時間ワークフローに圧倒的に有利です。Express Workflow（非同期）は最大 5 分の実行、最大 10 万 TPS に対応します。CloudWatch Logs への記録で実行履歴の代替も可能です。

正解: C. DynamoDB TTL（Time To Live）を設定する

正解の根拠・詳細解説

DynamoDB TTL は各アイテムに Unix タイムスタンプ属性を設定するだけで、期限切れアイテムを自動的に削除します。追加コストなし、DynamoDB の書き込みキャパシティを消費しません。設定も簡単で最もシンプルな解決策です。削除は厳密な即時削除ではなく（通常 48 時間以内）、期限切れアイテムはクエリ結果から自動フィルタリングされます。Lambda による定期削除（A）は余分なコストと複雑さが発生します。

正解: B. 90 日後 S3 Standard-IA → 1 年後 S3 Glacier Deep Archive → 7 年後 Expire（S3 Lifecycle Policy）

正解の根拠・詳細解説

S3 Glacier Deep Archive は最も安価なストレージクラス（Standard の約 23 分の 1）で、7 年などの長期コンプライアンス保管に最適です。S3 ライフサイクルポリシーで Standard → Standard-IA → Glacier Deep Archive の段階的移行と 7 年後の Expire（削除）を自動設定できます。取り出し時間は 12〜48 時間ですが、アクセスがほぼない場合は問題ありません。

正解: B. Compute Optimizer の推奨事項を確認し、非本番環境から段階的に適用する

正解の根拠・詳細解説

Right Sizing のベストプラクティスは Compute Optimizer 等のツールで詳細な推奨事項を取得し、開発・テスト環境から段階的に適用することです。CPU 以外にもメモリ・ネットワーク・ディスク I/O も考慮する必要があります。一括変更（A）はメモリやネットワーク要件を見落とすリスクがあります。全 Spot 化（C）はステートフルワークロードでは中断リスクがあります。単純な停止（D）は必要なサービスへの影響が出ます。

正解: B. Managed Node Groups（EC2 ベース、Spot 使用可）

正解の根拠・詳細解説

バッチ処理でリソース使用量が予測困難な場合、Managed Node Groups + Spot インスタンス（Karpenter や Cluster Autoscaler を活用）が柔軟なスケーリングと大幅なコスト削減（最大 70% 削減）を実現します。Fargate（A）は Pod 単位でリソースを正確に指定する必要があり、予測困難なバッチには過少/過剰プロビジョニングになりやすいです。また Spot は Fargate に対応しており（Fargate Spot）、ECS では有効ですが EKS Fargate では Spot は利用不可です。

正解: B. AWS Storage Gateway（File Gateway）をオンプレミスに配置する

正解の根拠・詳細解説

AWS Storage Gateway の File Gateway はオンプレミスに VM/物理アプライアンスとして配置し、SMB/NFS インターフェースを提供します。バックエンドは S3 で、頻繁にアクセスされるファイルはローカルキャッシュに保存されレイテンシが低減します。オンプレミスアプリは既存プロトコルのまま使用でき、移行コストが最小です。DataSync はデータ移行ツールで継続的アクセスには向きません。

正解: A. 初回：Snowball Edge 複数台、継続同期：DataSync

正解の根拠・詳細解説

200TB を 1Gbps で転送すると約 19 日かかります（ネットワーク効率を考慮するとさらに長くなります）。Snowball Edge（80TB × 3 台等）で物理輸送する方が短期間で完了します。初回移行後の差分同期は AWS DataSync が最適です。DataSync はオンプレミスの SMB/NFS/HDFS から S3・EFS・FSx への増分転送を自動化し、帯域幅制御も可能です。

正解: B. Redshift クラスターの Pause/Resume 機能をスケジュールで設定する

正解の根拠・詳細解説

Redshift の Pause/Resume 機能を使うと、一時停止中はコンピュートノードの費用が発生しません（ストレージのみ課金）。週次バッチ前に Resume、完了後に Pause をスケジュールすることで、使用時間（週10時間）のみの課金になります。Redshift Serverless（A）も使用時のみ課金ですが、移行コストが発生します。既存クラスターを維持したまま最小変更でコスト削減できる（B）が最優先です。

正解: A. Reserved Nodes（1 年・全額前払い）を購入する

正解の根拠・詳細解説

ElastiCache Reserved Nodes を 1 年・全額前払いで購入すると、On-Demand 比で最大 55% のコスト削減ができます。継続稼働が確定している本番環境の定常ワークロードには Reserved Nodes が最もコスト効率が高いです。Serverless（B）は使用量に応じた課金で、常時高使用率の場合は Reserved より割高になることがあります。ノードタイプ変更（C）はパフォーマンスへの影響があります。

正解: B. CloudWatch Logs のロググループの保持期間を 7 日に設定する

正解の根拠・詳細解説

CloudWatch Logs のロググループに保持期間（Retention Period）を設定すると、期間経過後のログは自動削除されます。CloudWatch Logs のストレージコストは保存量に比例するため、7 日の保持期間設定でほぼすべてのデバッグログが削除されコストが大幅削減されます。設定は数クリックで変更可能です。ログレベル変更（A）はデプロイが必要で、デバッグ用途を失います。

正解: A. Transfer Family の代わりに S3 の署名付き URL をパートナーに発行する

正解の根拠・詳細解説

S3 の事前署名付き URL（Presigned URL）を使えば、Transfer Family のサーバーアップタイムコストなしに外部パートナーへのファイルダウンロード・アップロードアクセスを提供できます。URL には有効期限を設定でき、IAM 権限も不要です。ただしパートナーが SFTP プロトコル必須の場合はこの方法は使えません。AWS Transfer Family は SFTP が必須の場合は最善ですが、SFTP にこだわらない場合は Presigned URL が最もシンプルでコスト効率がよいです。

正解: B. Organizations の一括請求（Consolidated Billing）で RI/Savings Plans の共有を有効にする

正解の根拠・詳細解説

Organizations の一括請求（Consolidated Billing）を使用すると、RI と Savings Plans の割引がデフォルトで組織全体に共有されます。あるアカウントが購入した RI の余剰キャパシティは、同一組織内の他アカウントのインスタンスに自動適用されます。RI 共有の無効化（特定アカウントを分離する）も Organizations コンソールから設定可能です。管理アカウントでの一括購入（C）も有効ですが、B がより自動的です。

正解: B. AWS Application Auto Scaling で統一的にスケーリングポリシーを管理する

正解の根拠・詳細解説

AWS Application Auto Scaling は EC2 以外の多数のサービス（DynamoDB、ECS、Aurora レプリカ、Lambda プロビジョンド同時実行数、SageMaker エンドポイント等）のキャパシティを統一的に管理する API です。ターゲット追跡ポリシー・ステップスケーリングポリシー・スケジュールドスケーリングを各サービスに対して設定できます。AWS Auto Scaling（D）は Application Auto Scaling を内部で使用しており、EC2 Auto Scaling グループとの統合ビューを提供します。

正解: B. Amazon EventBridge Scheduler でスケジュールを作成する

正解の根拠・詳細解説

Amazon EventBridge Scheduler（2022年リリース）はサーバーレスのスケジューラーで、Lambda・SQS・Step Functions など 270 以上のサービスをタイムゾーン指定・Cron/Rate 式で柔軟にスケジュール実行できます。EventBridge Rules（A）より高度なスケジューリング機能（1回限り実行、柔軟なウィンドウ等）を提供します。SAP-C02 の試験では最新サービスが出題されることが多く、EventBridge Scheduler を選ぶのが現代的アプローチです。

正解: A. クラウドの財務管理を実施する（コストを可視化し責任を明確にする）

正解の根拠・詳細解説

・CAWS Well-Architected Framework コスト最適化の柱の設計原則は次の 5 つです。①クラウドの財務管理を実施する、②消費モデルを採用する（使用した分だけ支払う）、③全体的な効率を達成する、④差別化につながらない重労働に費用をかけない、⑤費用を分析・帰属させる。B（全て Glacier）は可用性とパフォーマンスを無視した極端な対応です。D（全て RI）は変動ワークロードに対して過剰投資になります。