birdpixyさんの投稿一覧
読み取りリクエストが「予測しにくい」とはいっても、設問では 「緩やかな増減」 と書かれています。
DynamoDB Auto Scalingは、プロビジョンドモードで読み取り/書き込みキャパシティ、またはその両方を自動調整できます。
つまり、書き込みは固定的にプロビジョニングし、読み取りだけAuto Scalingで追従させるという設計が可能です。
・緩やかな増減の場合：
Auto Scaling のスケーリング遅延（アラーム発火→反映まで数分）でも十分追従できる → プロビジョンド + Auto Scaling が有効
・突発的な増減がある場合：
Auto Scaling が間に合わずスロットリングが起きる → オンデマンドが有効
ポイントは設問の
データはオンプレミスからファイルベースのアプリケーションを使用して、低遅延でS3バケットへアクセスできる必要がある。
という要件にあります。
DataSyncの場合：
アプリケーションのアクセス先はオンプレミスのストレージであり、DataSyncはオンプレミスのストレージとS3バケットの間でデータを同期します。
オンプレミスアプリケーション
↓
オンプレストレージ
↓
（同期）
↓
S3バケット
DataSyncはデータ移行・同期サービスであり、アプリケーションからS3バケットへアクセスするための仕組みは提供しません。
Storage Gatewayの場合：
アプリケーションはStorage Gatewayが提供するファイル共有（NFS/SMB）を経由して、S3バケットにアクセスします。
オンプレミスアプリケーション
↓
（ファイルゲートウェイ）
↓
S3バケット
ファイルゲートウェイはローカルキャッシュを利用して低遅延アクセスを実現できるため、設問の要件と一致します。
SNSの暗号化はSNSが実行しますが、KMSの認可は「リクエストの主体（Lambda実行ロール）」も含めて評価されるため、Lambda側にもKMS権限が必要です。
SNSのサーバーサイド暗号化（SSE）では、メッセージがトピックに到達した時点で暗号化されます。
この暗号化処理の流れは以下のようになっています。
1.Lambda関数がSNSにパブリッシュする
2.SNSがメッセージを受け取る
3.SNSがKMSに対してデータキー生成を要求
4.データキーでメッセージを暗号化して保存する
3でKMSを呼び出すのはSNSですが、その呼び出しが許可されるかどうかは、SNSプリンシパルおよびパブリッシュを行ったプリンシパル（＝Lambda実行ロール）の両方の権限に基づいて判定されます。そのため、Lambda実行ロールにKMSカスタマーマネージドキーの利用を許可する権限が必要です。