咨询：数据库配置在AWS Parameter Store的存储方式选择

Great question! Both approaches are valid in AWS Parameter Store, but which one you pick depends on your needs around permissions, update workflows, and how your applications consume the configuration. Let’s break down the pros and cons of each:

Option 1: Store all configs in a single entry (JSON dictionary) #

You can absolutely store your database config as a single parameter (e.g., key: /database/config, value: {"databaseUser": "user", "databasePassword": "password", "databaseName": "name", "databaseHost": "host"}). Just make sure to use the SecureString type if any of the values are sensitive (like the password) to encrypt them at rest.

Pros: #

• Simplified management: You only have one parameter to create, update, and track.
• Fewer API calls: Your application can fetch all configs in a single GetParameter call instead of four separate ones.
• Logical grouping: Keeps related configs tied together, which makes sense for a single database connection setup.

Cons: #

• No granular updates: To change just the database password, you’ll have to re-upload the entire JSON blob—risky if you accidentally mess up other values.
• Limited permission control: You can’t grant access to just the databaseUser without granting access to the entire config (including the password). This is a problem if different services/roles need different subsets of the config.
• Size limits: Parameter Store has a 4KB limit for both String and SecureString types. For a small set of DB configs this isn’t an issue, but it could become a problem if you add more parameters later.

Option 2: Store as four separate entries #

Create individual parameters like /database/user, /database/password, /database/name, /database/host. Use SecureString for the password, and String for the non-sensitive values.

Pros: #

• Granular permissions: You can grant a read-only service access to /database/user, /database/name, and /database/host without letting it see the password.
• Targeted updates: You can change just the password (or any single parameter) without touching the others, reducing the risk of mistakes.
• Scalability: It’s easier to add new parameters (like /database/port) later without restructuring existing configs.

Cons: #

• More API calls: Your app will need four GetParameter calls (or a single GetParametersByPath call using the /database/ prefix) to fetch all configs.
• Slightly more overhead: You have four separate parameters to manage instead of one, though using a consistent prefix helps with organization.

Recommendation #

• Go with a single JSON entry if: All your configs are used by the same application/role, you don’t need granular permissions, and you want to minimize API calls and management overhead. Just remember to encrypt the entire JSON with SecureString since it contains sensitive data.
• Go with separate entries if: You need to restrict access to individual parameters, anticipate updating values independently, or might expand the config set later. This is the more flexible approach for most production scenarios.

Pro tip: Regardless of which option you choose, use a consistent, hierarchical naming convention (like /database/...)—it makes it easier to manage parameters in bulk and apply IAM policies to entire path prefixes.

内容的提问来源于stack exchange，提问作者alionthego