AWS 認定ソリューションアーキテクト – プロフェッショナル WEB問題集

正解：D

この問題のポイントは、「高可用性」「耐障害性」「セキュリティ」を満たしつつ、「最もコスト効率よく」実現する方法を選ぶことです。

まず Direct Connect 単独では暗号化されていないため、転送中のデータを暗号化する仕組みが必要です。一般的には Direct Connect と Site-to-Site VPN を併用するハイブリッド構成（いわゆる DX + VPN 冗長化） が推奨されます。AWS のベストプラクティスとしても、専用線が障害で停止した場合のバックアップ経路として Site-to-Site VPN を利用することが案内されています。 Site-to-Site VPN をバックアップ経路として追加すれば、Direct Connect がダウンした際に VPN 経由で AWS と通信が可能になります。また VPN は IPsec により暗号化されるため、セキュリティ要件も満たします。コスト的にも追加の回線敷設は不要で、最も費用対効果の高い解決策です。よってこれが正解です。

正解：B

この問題の重要な要素は以下です。

1. 動画ファイルサイズは最大 4 GB データベースに直接保存するのは非効率かつパフォーマンスに悪影響を与えます。特に base64 エンコードされた文字列として TEXT カラムや DynamoDB 項目に格納するのは適切ではありません。
2. 急速なスケーリングが必要 動画の保存・配信にはスケーラブルなオブジェクトストレージが求められます。Amazon S3 はこの要件に最適です。
3. アプリケーションのパフォーマンスに影響を与えないこと 大容量データをデータベースに保存するとクエリ性能が低下しますが、S3 を利用すればストレージはデータベースから分離され、パフォーマンスへの影響を避けられます。

ユーザープロファイルなどの構造化データは DynamoDB に保存し、大容量動画は S3 に保存します。DynamoDB 項目には S3 のキー（オブジェクトの場所）を保持すればよく、これが最もスケーラブルでコスト効率の良い設計です。

正解：A

問題の要件

• 復旧目標時点（RPO）100分以内で削除データを復元できること。
• デフォルトバックアッププランは「1日1回」であり、RPO は 最大24時間 → 不適切。
• Amazon EFS は ポイントインタイムリカバリ（PITR） をサポートしていない。
• Amazon EFS のバックアップ間隔は 最小で1時間（30分は不可）。

1. RPO 100分の要件を満たす
   • 1時間ごとのバックアップであれば、最悪の場合でも「直近のバックアップから60分以内」の復元が可能です。
   • 100分以内の復元要件を余裕をもって満たします。
2. AWS Backup が公式にサポートする設定
   • AWS Backup のスケジュールは cron 式で最小「1時間ごと」まで可能です。
   • 30分間隔はサポートされないため、B のような「30分バックアップ」は不可能。
3. KMS 暗号化環境での適切な設定
   • Amazon EFS は KMS キーで暗号化されているため、AWS Backup から復元・バックアップ操作を行うには KMS キーへのアクセス権限が必須です。
   • キーポリシーを更新して、バックアップに使用する IAM ロール（またはサービスリンクドロール）が KMS キーを利用できるようにするのは正しい手順です。
4. 実現可能性とコスト効率
   • A の構成は AWS Backup がサポートしている標準機能のみを利用するため、追加のコストや複雑なオーケストレーションが不要。
   • 運用負荷を最小化しつつ、RPO を確実に達成できるため、最も現実的かつコスト効率の高い解です。

正解：D

この要件を満たすためには、**「MFA が有効であることを示すコンテキストを持つ一時的な認証情報で S3 API を呼ぶ」**必要があります。通常の長期アクセスキー（Access key ID/Secret access key）で CLI から直接 S3 を呼んでも、MFA の検証結果は自動的には API リクエストに伝播しません。したがってポリシー側で aws:MultiFactorAuthPresent（または aws:MultiFactorAuthAge）を条件に「MFA なしは拒否」をかけたうえで、ユーザーは MFA デバイスのワンタイムコードを用いて sts:GetSessionToken を呼び出し、一時的なセッショントークン（SessionToken を含む三点セット）を取得し、そのプロファイルで S3 を操作します。これによりリクエストに「MFA が存在する」というコンテキストが付与され、S3 のアクションが許可されます。 このフローをそのまま示しているのが D です。グループに「MFA がなければ S3 を拒否」のポリシーを付け、STS で MFA 付きの一時クレデンシャルを取得して使う、というのが AWS のベストプラクティスです。

（参考実装のイメージ）

1. ユーザーは aws sts get-session-token --serial-number <MFAデバイスARN> --token-code <6桁コード> を実行して一時認証情報を得る。
2. 返ってきた AccessKeyId/SecretAccessKey/SessionToken をプロファイルに設定し、そのプロファイルで aws s3 cp ... などを実行する。
3. IAM（もしくはバケット）側のポリシーで Condition: {"Bool": {"aws:MultiFactorAuthPresent": "true"}} を満たすため、S3 操作が許可される。

正解：B

この問題のキーポイントは以下の通りです。

1. コード変更を伴わない移行（Rehost/リフト&シフト）
   • アプリケーションをリファクタリング（A, D）する選択肢は「コード変更が不要」という要件に反します。よって除外。
2. インフラ管理をしたくない
   • EC2 に移行した場合（C）は OS/ミドルウェア/パッチ適用などを運用側が管理しなければなりません。よって「インフラ管理不要」という要件に反します。
3. Elastic Beanstalk の特性
   • Elastic Beanstalk は Windows/.NET Framework アプリケーションをサポートしており、アプリケーションをそのままデプロイ可能。
   • オートスケーリング、ヘルスチェック、パッチ適用、インフラ管理を抽象化してくれるため、ユーザーはアプリケーションに集中できます。
   • Windows Web Application Migration Assistant を使えばオンプレミスの IIS で動いているアプリケーションを最小限の変更で Beanstalk に移行可能。

以上から、最小の移行時間でコード変更不要、かつインフラ管理を回避できるのは Elastic Beanstalk への移行（B）です。