正解：A
S3 Transfer Accelerationは、CloudFrontのエッジロケーションを利用してS3へのアップロードを高速化する機能です。この問題のポイント：
- 高速インターネット接続あり：Snowballのような物理転送は不要
- 最も迅速に集約：CloudFrontエッジ経由で最適化ルートを使用
- 運用の複雑さ最小：単一バケットへの直接アップロードで構成がシンプル
- マルチパートアップロード：大きなファイルを分割して並列転送
他の選択肢について：
B. CRRはリージョン間レプリケーションに時間がかかり、中間バケット管理が複雑です。
C. Snowballは高速インターネットが既にある環境では非効率で、物理デバイスの輸送時間がかかります。
D. EBSスナップショット経由の転送は運用が極めて複雑で非効率です。
正解：C
Amazon Athenaは、S3に保存されたデータを標準SQLで直接クエリできるサーバーレスのインタラクティブクエリサービスです。この問題に最適な理由：
- サーバーレス：インフラのプロビジョニング不要
- JSON、CSV、Parquetなどのフォーマットをネイティブサポート
- オンデマンド課金：クエリスキャン量に応じた従量課金で、アイドル時のコストゼロ
- 最小の運用オーバーヘッド：既存のS3データをそのまま活用、アーキテクチャ変更不要
他の選択肢について：
A. Redshiftはデータロードが必要で、常時稼働コストがかかり、オーバーヘッドが大きいです。
B. CloudWatch LogsはS3上のログ分析用ではありません。
D. EMR Sparkクラスターは複雑で、シンプルなオンデマンドクエリには過剰です。
正解：B
AWS Snowball Edgeは、大容量データをインターネット経由ではなく物理デバイスで転送するサービスです。70TBという大容量データに最適な理由：
- ネットワーク帯域幅を最小化：物理デバイスで配送するためインターネット帯域を消費しない
- 迅速な転送：70TBをインターネット経由だと数週間〜数ヶ月かかるが、Snowballなら数日で完了
- Snowball Edge Storage Optimized：80TBまでのストレージ容量を提供
- オフライン転送：セキュアで信頼性が高い
他の選択肢について：
A. AWS CLIでのアップロードは70TBだとネットワーク帯域を大量消費し、時間もかかります。
C. S3 File Gatewayはインターネット経由でアップロードするため帯域幅を消費します。
D. Direct Connect接続の設定には数週間かかり、迅速さの要件に反します。
正解：A
Amazon CloudFrontは、静的・動的コンテンツの両方を配信できるCDNサービスです。この問題の最適解である理由：
- 複数オリジン対応：1つのCloudFrontディストリビューションに複数のオリジン（S3、ALB）を設定可能
- 静的コンテンツの加速：S3オリジンの静的ファイルをエッジでキャッシュ
- 動的コンテンツの加速：ALBオリジンへの動的リクエストもCloudFront経由で最適化ルートを使用
- パスベースのオリジン振り分け：例えば
/static/*→ S3、/api/*→ ALB - シンプルな構成：Route 53のエイリアスレコードをCloudFrontに向けるだけ
他の選択肢について：
B/C/D. Global AcceleratorとCloudFrontの組み合わせは過剰設計で、S3の静的コンテンツ配信にはGlobal Acceleratorは不向き（CloudFrontが専用）。構成が複雑でコストも高くなります。
正解：C
Amazon Aurora + マルチAZ + Aurora Auto Scaling（Aurora Replicas）は、高可用性と自動スケーリングの読み取りパフォーマンスを両立する理想的なソリューションです。主な特徴：
- マルチAZデプロイメント：複数AZにわたる高可用性とフェイルオーバー
- Aurora Replicas（最大15個）：読み取り専用レプリカで読み取りワークロードをスケール
- Aurora Auto Scaling：CloudWatchメトリクス（CPU使用率や接続数）に基づいてレプリカを自動追加/削除
- MySQL互換：既存のMySQL 8.0アプリケーションをそのまま移行可能
- 高性能：MySQLの最大5倍のスループット
- ストレージ自動拡張：最大128TBまで自動拡張
他の選択肢について：
A. Redshiftはデータウェアハウスで、OLTPワークロードには不適切です。
B. シングルAZのRDSは高可用性要件を満たしません。
D. ElastiCache Memcachedはキャッシュで、永続的なトランザクションデータベースではありません。
正解：B
Amazon QuickSightは、AWSのサーバーレスBIサービスで、この問題に最適な理由：
- 複数データソースサポート：S3、RDS、Redshift、Athena、Auroraなどに直接接続
- ダッシュボード共有：QuickSight内のユーザーとグループに権限を付与可能（IAMロールではない）
- 行レベル・列レベルのセキュリティ：ユーザーごとにデータアクセスを制御
- サーバーレス：インフラ管理不要
- SPICE（インメモリエンジン）：高速な可視化
他の選択肢について：
A. QuickSightのダッシュボードはIAMロールではなくQuickSightユーザー/グループに共有します。IAMロールは共有対象として適切ではありません。
C/D. GlueとAthenaでのレポート生成＋S3配置は、動的な可視化や細かいアクセス制御には不向きで、QuickSightの方が目的に合致します。
正解：D
EBS Fast Snapshot Restore（FSR）は、スナップショットから作成されたEBSボリュームに対して初回アクセス時の遅延なく完全なパフォーマンスを即座に提供する機能です。この問題の最適解である理由：
- 通常のEBSスナップショット復元：初回アクセス時にブロックがS3から遅延ロード（Lazy Load）されるため、最初のI/O性能が低下
- FSR有効時：
- スナップショットが事前に「初期化済み」状態
- ボリューム作成直後から完全な I/O パフォーマンスを発揮
- 一貫した高I/Oパフォーマンスの要件を満たす - 独立したクローン：新しいEBSボリュームは本番から独立、変更は本番に影響しない
他の選択肢について：
A. インスタンスストアは一時的ストレージで、本番データの永続性・耐久性に不適切です。
B. EBSマルチアタッチでは本番と同じボリュームを共有し、テスト環境の変更が本番に影響します。
C. 「復元する前にアタッチ」は論理的に誤りで、FSRなしでは初回アクセスが遅いです。
正解：D
完全サーバーレスアーキテクチャ（S3 + CloudFront + API Gateway + Lambda + DynamoDB）は、この要件の最適解です：
- S3 + CloudFront：静的コンテンツをエッジで配信、ミリ秒のレイテンシー
- API Gateway + Lambda：
- 自動スケーリング（数百万リクエスト/時間に対応）
- サーバー管理不要
- 従量課金で24時間だけのイベントに最適 - DynamoDB：
- 1桁ミリ秒のレイテンシー
- 自動スケーリング（オンデマンドキャパシティ）
- フルマネージド - 最小の運用オーバーヘッド：サーバー・OS・スケーリングの管理不要
他の選択肢について：
A. S3には注文データ（動的トランザクション）は保存できません。
B. EC2 + RDSはスケーリング管理が必要で、運用オーバーヘッドが大きいです。
C. EKSは複雑でオーバーキル、運用オーバーヘッドが最も大きいです。
正解：C
Amazon Kinesis Data Streams + Lambda + DynamoDBの組み合わせが、ニアリアルタイム処理と複数コンシューマーへの配信の要件に最適です：
- Kinesis Data Streams：
- リアルタイムデータストリーミング
- 複数のコンシューマーが同じストリームから並列消費可能
- データは最大365日保持 - Lambda統合：機密データを自動的にフィルタリング
- DynamoDB：1桁ミリ秒のレイテンシーで文書データ取得（「ドキュメントデータベース」要件）
- ニアリアルタイム：ミリ秒単位の遅延で処理
他の選択肢について：
A. DynamoDB Streamsは他のアプリケーションに共有するには制限があり、「ルール」での機密削除もDynamoDBの機能ではありません。
B. Kinesis Data Firehoseはバッチ処理（最短60秒）で「ニアリアルタイム」ほど低遅延ではありません。また、Firehoseは複数コンシューマーの並列消費に最適化されていません。
D. バッチ処理 + S3は「ニアリアルタイム」の要件を満たしません。
正解：C
Amazon CloudFrontは、S3静的ウェブサイトの配信高速化に最適なCDNサービスです。主な特徴：
- 400+エッジロケーション：世界中のユーザーに最も近い地点からコンテンツ配信
- キャッシング：静的コンテンツをエッジでキャッシュして高速配信
- 低レイテンシー：ユーザーに最も近いエッジからの配信で遅延最小化
- S3との統合：OAI/OACでセキュアな統合
- コスト効率：S3からの転送料金節約 + エッジキャッシュによる転送量削減
他の選択肢について：
A. S3バケットの全リージョン複製は莫大なストレージコストと複雑な管理が必要です。
B. Global AcceleratorはS3をバックエンドとして直接サポートしていません（Application/Network Load Balancer、EC2、Elastic IP向け）。また、静的コンテンツ配信にはCloudFrontが適切です。
D. S3 Transfer Accelerationはアップロードを高速化する機能で、ユーザーのダウンロードレイテンシー削減には不向きです。