導入
データベースのパスワードやAPIキーをアプリのコードやコンテナイメージに直接書いてしまう——これはCLFでも触れた典型的なアンチパターンです。SAAでは「どちらの管理サービスを使うべきか」まで判断できる必要があります。
説明
パスワードやAPIキーなどの機密情報（シークレット）は、コードに直接書かず専用サービスで一元管理します。AWSには目的の異なる2つのサービスがあります。
| サービス | 主な用途 | ローテーション | コスト |
|---|---|---|---|
| Secrets Manager | DB認証情報など、定期的な自動ローテーションが必要なシークレット | 自動ローテーションに標準対応（RDS等と連携） | 有料（保存数・API呼び出しに応じて） |
| SSM Parameter Store | 設定値やシークレットの一元管理（ローテーションの仕組みは自前で用意） | 標準では非対応（Standard利用なら基本無料） | 無料枠が大きい（Standard） |
flowchart LR
APP["アプリケーション"] -- "実行時に取得" --> SM["Secrets Manager<br/>（自動ローテーション）"]
APP -- "実行時に取得" --> PS["Parameter Store<br/>（設定値/シークレット）"]
SM -. ローテーション .-> RDS["RDS"]
判断の軸は「自動ローテーションが必要かどうか」です。RDSのマスターパスワードのように、定期的に自動で変更してセキュリティを保ちたい場合はSecrets Manager一択です。一方、変更頻度の低い設定値やAPIキーで、コストを抑えたい場合はParameter Storeが適しています。
具体例
同じアプリの中でも、機密情報の性質でサービスを使い分けます。
- RDSのマスターパスワード → Secrets Manager … DBパスワードは、漏洩リスクを下げるため30日ごとに自動ローテーションしたい。Secrets ManagerはRDSと連携して、新パスワードの生成→DBへの反映→保管を全自動で回してくれる。アプリは実行時に最新のパスワードを取りに行くだけ。
- アプリの環境設定値（機能フラグ、エンドポイントURL、APIキー）→ Parameter Store … これらは頻繁には変わらず、自動ローテーションも不要。Parameter Store（Standard）なら基本無料で一元管理でき、コストを抑えられる。
どちらも共通するのは「コードに直書きしない」こと。設定ファイルにパスワードを書いてイメージに焼き込むのは典型的なアンチパターンです。判断は「自動ローテーションが要件か？」の一点——Yesなら多少高くてもSecrets Manager、Noでコスト重視ならParameter Store。問題文からこの一語を探すのが勝ち筋です。
読んでみよう
「パスワードをコードに埋め込んでいる」という記述があれば、それだけで設計ミスのサインです。「自動ローテーションが要件にあるか」を問題文から探し出せれば、Secrets ManagerとParameter Storeのどちらが正解かはすぐに判別できます。