Secrets Manager、Parameter Store 的差異 — 初學者向解說

結論

AWS Secrets Manager 與 AWS Systems Manager Parameter Store 兩者都可以管理應用程式的設定值與機密資訊。

不過，各自擅長的領域不同。

• 資料庫密碼、API 金鑰等需要輪替的機密資訊，使用 AWS Secrets Manager
• 環境變數、端點 URL、輕量設定值，使用 Parameter Store
• 若是以 SecureString 加密的輕量值，Parameter Store 也可列為候選

在 AWS 考試中，題目出現「自動輪替」時，優先考慮 AWS Secrets Manager。

比較表

初學者向解說

AWS Secrets Manager 是管理機密資訊的服務。

Lambda
↓ 執行時取得
Secrets Manager
↓
DB password / API key

不在應用程式原始碼中寫入密碼，而是在執行時取得。

Parameter Store 是管理設定值的功能。

Lambda
↓ 執行時取得
Parameter Store
↓
/prod/api/base-url
/prod/app/log-level

可以用階層結構管理各環境的設定值。

考試會問到的重點

AWS Secrets Manager 較容易成為正解的情境

• 想要儲存資料庫認證資訊
• 想要安全地儲存 API 金鑰
• 需要機密資訊的自動輪替
• 想要消除被寫死的認證資訊
• 想在 AWS Lambda 執行時取得機密資訊

Parameter Store 較容易成為正解的情境

• 想要儲存應用程式的設定值
• 想要以階層管理各環境的參數
• 想要管理 URL、ARN、環境名稱等
• 想用 SecureString 處理輕量的加密參數
• 想從 AWS CloudFormation 或 AWS Lambda 參照設定值

實務上的使用區分

管理 DB 密碼的情境

使用 AWS Secrets Manager。

RDS password
↓
Secrets Manager
↓
Lambda / ECS / EC2

適合需要自動輪替與稽核的機密資訊。

管理 API 基本 URL 的情境

使用 Parameter Store。

/prod/api/base-url = https://api.example.com
/dev/api/base-url = https://api-dev.example.com

適合並非機密、但各環境會變動的設定值。

在本專案中的位置

本專案的 MVP 階段不將機密資訊直接寫入程式碼。

前端使用 .env.local，但不會提交到 Git。

未來若在正式環境處理外部 API 金鑰或 JWT_SECRET，會考慮 AWS Secrets Manager 或 Parameter Store。

常見的誤解

誤解 1:把所有東西都放進 AWS Secrets Manager

AWS Secrets Manager 擅長機密資訊管理，但若連單純的設定值也全部放入，成本與管理會變重。

將設定值歸 Parameter Store、機密資訊歸 AWS Secrets Manager，較容易整理。

誤解 2:認為 Parameter Store 放什麼都安全

Parameter Store 的 String 與 StringList 是明文設定值。

要儲存機密資訊時，使用 SecureString，或考慮 AWS Secrets Manager。

誤解 3:把機密資訊直接寫進環境變數

在本地開發時，有時會使用 .env.local。

不過，正式環境的運維需要不讓機密資訊外流到程式碼或 GitHub 的設計。

相關用語

• AWS Secrets Manager
• AWS Systems Manager
• AWS Key Management Service
• AWS Lambda
• AWS Identity and Access Management

相關題目

• CLF 模擬題列表

總結

AWS Secrets Manager 與 Parameter Store，以用途區分會更容易判斷。

• AWS Secrets Manager:機密資訊、認證資訊、自動輪替
• Parameter Store:設定值、環境變數、輕量的 SecureString

在 SAA-C03 中，此比較會從安全設計與運維設計兩個面向被詢問。