haru453さんの投稿一覧

どの問題を指しているのかわからないので、どのような構成を想定しているのか判断できませんが、画像IDをS3のオブジェクトキーに含める方法や、データベースに画像IDとS3の保存先を登録する方法が考えられるのではないでしょうか。

ご質問の意図を正確に捉えられていない可能性がありますが、選択肢3は、予算超過をきっかけにLambda関数を実行し、そのLambda関数でリソースを停止する構成です。AWS Budgetsの予算アクションを使わず、Lambda関数を別途使用しているため、効率的な方法ではないと解説されています。

一方、Lambda関数を使わず、Budgets用のIAMロールを通じてSCPを適用する構成が選択肢1と2であり、こちらが正解です。

「暗号化されていないデータベースインスタンスに対して、暗号化を有効化する設定はない」という選択肢については、解説の上部にある「暗号化を行う場合はデータベースの作成時に指定し、作成した後に暗号を有効化することはできません」という部分が該当しているのではないでしょうか。

AWS公式ドキュメントでも、既存の暗号化されていないRDS DBインスタンスに対して、あとから直接暗号化を有効にすることはできないと説明されています。暗号化するには、スナップショットを作成し、そのスナップショットのコピーを暗号化して、暗号化されたスナップショットから新しいDBインスタンスを復元します。
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-remediate-unencrypted-amazon-rds-db-instances-and-clusters.html

私も最初は、読み取りリクエスト数が予測しにくいので、オンデマンドモードではないかと思いました。
ただ、問題文には「緩やかな増減」とあるため、急激なスパイクではなく、Auto Scalingで対応できる変動を想定しているのだと思います。
また、オンデマンドモードではRCUやWCUを個別に固定したり、一部だけにAuto Scalingを設定したりすることはできないため、選択肢の中では、プロビジョンドモードで読み取りキャパシティユニットにAuto Scalingを設定する構成が最も適切、ということになるのではないかと。

どれも正しいように見える、という気持ちは分かります。
ただ、「〜な気がする」で判断するとブレやすいので、公式の定義で確認するのが確実だと思いますよ。
公式ページを見ていただくと分かると思いますが、今回の解説の分類で問題ないと思います。
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/the-pillars-of-the-framework.html

② リソースの容量を事前に推測するのではなく、需要に応じて動的にスケールする
→ 信頼性の設計原則「容量を推測しない」に該当します。

③ 障害シナリオをシミュレーションし、リスクを特定して影響を予測する
→ 運用上の優秀性の設計原則「障害を予測する」に該当します。