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カスタマーマネージドキーの利用を許可する権限が必要です。
https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-plan-file-systems.html
AWS公式にもS3AとHDFSを使用すると書いてありました。
Amazon EMR および Hadoop は通常、クラスターを処理するときに以下のうち少なくとも 2 つのファイルシステムを使用します。HDFS と S3A は、Amazon EMR で使用される 2 つの主なファイルシステムです。
EMR-7.10.0以降、EMRからS3への接続はEMRFSからS3Aがデフォルトになったようですので、教科書の情報が古いのだと思います。
https://docs.aws.amazon.com/ja_jp/emr/latest/ReleaseGuide/emr-s3a-migrate.html
問題文冒頭の「S3バケットに対して」が「特定のIAMユーザーからのみアクセスを許可したい場合」にかかっているのか、「定義する」にかかっているのかがわかりにくく感じました。
うーん、「S3バケットに対して」が「特定のIAMユーザーからのみアクセスを許可したい場合」にかかっていても「定義する」にかかっていてもどちらでも意味は通じるので、特に違和感はありませんでした。
ちなみに実際の試験は、合格体験記でもよく言われているように機械翻訳したような不自然な日本語なので、もっと分かりにくいですよ。
以下のドキュメントによるとDynamoDBはソースとして使用できるようなのですが、AWS SAA-CO3の範囲では、当サイトの回答解説のように考えるのが良いのでしょうか。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html
下記の記述のことでしょうか？
DynamoDB などの NoSQL プラットフォーム、Amazon Simple Storage Service (Amazon S3) などの低コストの
ストレージプラットフォームにより提供されるマネージド データウェアハウスに移行できます。
「DynamoDBなどのNoSQLプラットフォーム（中略）により提供されるマネージドデータウェアハウスに移行できます」なので、ソースとして使用できるとは書いてないようです。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Sources.html
こちらのDMSのソース一覧にも記載がありません。
DynamoDBのクロスリージョンバックアップはAWS Backupの機能を使用するので、DynamoDB自体に備わっている機能ではないということではないでしょうか。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/backuprestore_HowItWorksAWS.html
DynamoDBに備わっているオンデマンドバックアップやポイントインタイムリカバリ（PITR）はどちらも同一リージョン内限定です。
マルチAZ DBクラスターの場合、スタンバイインスタンスがリードレプリカを兼ねているので、プライマリインスタンスに対して追加のリードレプリカを作成できます。
ただ、マルチAZ DBクラスターのリードレプリカ作成可能数までは書いていませんでした。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multi-az-db-clusters-create-instance-read-replica.html
例えば悪意のある不正なドメインからのリクエストも受け付けてしまうなど…
ワイルドカードを使う対象が自ドメイン（アクセス先）なので、悪意のある不正なドメイン（アクセス元）からリクエストを受け付けることはないですが、自ドメインで公開を想定していないサブドメインへのアクセスが可能になるリスクはあります。
例えば「web1.example.com」「web2.example.com」を公開していたとして、「*.example.com」のカスタムレコードを作成した場合、「test.example.com」のようなテスト用のサブドメインなどにもアクセス可能になってしまうということです。
私個人の経験ですが、AWSにおける暗黙の了解みたいなもので本番用＝1年以上の長期運用という読み取りを要求されることはありますね。
一般的にも本番用だけど運用期間が数か月の方が例外だと思うので、そのようなシチュエーションのときは何らか補足があると思いますよ。
問題の参考URLに、Shield Advancedの保護対象が記載されてるAWS公式ページがありましたよ。
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/ddos-advanced-summary-protected-resources.html
ワイルドカードの有無と関係なく、API Gatewayで独自ドメイン（カスタムドメイン）名を作成できます。
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-custom-domains.html#wildcard-custom-domain-names
逆にRoute 53は独自ドメイン名のDNSレコードを登録して名前解決をするサービスであり、作成はできないと思うのですが…。
そうですね、移行後のEC2やLambdaの費用と、オンプレのアプリやツールが稼働しているサーバーのランニングコストを天秤にかけたり、実はDirect Connectの契約費用で苦しんでいて、今すぐにでも解約したいという事情があるのかもしれないとか考えると、昼も眠れなくなってしまいますね。
設問の「インターネットからHTTP（80番ポート）でアクセスできるようにしたい」は「インターネット上のクライアント（ユーザー）からEC2上のWebサーバーにHTTPアクセスをしたい」と読めます。
つまり、以下のような一連の通信フローを成立させる必要があります：
[クライアント] → HTTPリクエスト → [EC2インスタンス]
[クライアント] ← HTTPレスポンス ← [EC2インスタンス]
上記の通信を許可するためには、インバウンド通信のHTTPリクエストを許可することで、アウトバウンド通信のHTTPレスポンスも許可されるセキュリティグループを使用するのが正解ということです。
実際にパーティションプレイスメントグループを作成しましたところ
手順1 パーティション数を指定してグループを作成する
手順2 EC2インスタンス作成時に所属するグループおよびパーティションを選択する
でしたので、②に近いと思います。
データベースのパスワードを暗号化してLambda関数に格納する方法は、AWS公式でも提示されているので、試験にも出る可能性があると思います。
https://aws.amazon.com/jp/lambda/faqs/
Q: 機密情報を環境変数に格納できますか?
データベースのパスワードなどの機密情報については、AWS Key Management Service を使用してクライアント側で暗号化し、
この暗号化した値を環境変数に暗号文として格納することをお勧めします。
これらの値の復号化では、AWS Lambda 関数コードにロジックを含める必要があります
継続してだと処理中のデータを引き継ぐイメージをする人が多いのではないでしょうか
解説に、SQSキューで処理中のデータを引き継ぐと書かれてあります。
スポットインスタンスは利用中にインスタンスが中断する可能性がありますが、Amazon SQSキューでリクエストを中継しているので、
万が一処理中にインスタンスが中断してもSQSキューに保持されているメッセージは失われず、別のインスタンスで処理を再開できます。
・問題の要件では「コスト最適化」や「効率の良い実装」「効率の良い運用」などは求められていない。
要件として明記されていないとしても、AWSが出題する試験である以上、AWS Well-Architectedフレームワークに準拠したソリューションが求められているはずです。
・一方で、リクエストの処理時間は記載されておらずLambdaの処理時間(15分)で処理しきれるかは不明
上記のことから、LambdaではなくFargateの方が適切かと考えたのですがこの考えの誤っているところはどこでしょうか。
誤答解説にもある通りFargateだとコンテナ化する手間が発生します。
処理時間の記載はありませんが、リクエストが大量に発生する可能性があるWebアプリケーションの処理時間が15分を超えるとはあまり考えられにくいです。
メタ的なことを言ってしまえば、処理時間が15分以上だからLambdaが誤りである問題の場合は要件に処理時間が15分以上と書いてありますし、Fargateが正解である問題の場合は大抵要件にコンテナと書いてあります。
ありとあらゆる想定をすることは実務ではリスク管理の点で有効ですが、処理時間が書いてないからLambdaが誤りという免許の学科試験のような引っ掛け問題の可能性を考えていると試験時間が足りなくなる恐れがあります…