You can definitely retrieve multiple values, stored as k/v pairs at once with SSM parameter store.

https://docs.aws.amazon.com/cli/latest/reference/ssm/get-par...

Just use the --recursive option.

I'm of the opinion that AWS just doesn't like people using SSM Parameter store w/ KMS encryption as the main solution b/c they realized too late that they missed an opportunity to charge money for it.

I’d rather they charge for it. They need some incentive to keep developing it, and parameter store is frankly atrocious.

If you're using path prefixes you can retrieve all of them easily using the AWS SDK[1,2].

One of the things that we do is to prefix all of our SSM keys with a prefix based on the service name (for example, `example-api/`) and fetch them by path rather than individually.

[1] https://docs.aws.amazon.com/sdk-for-go/api/service/ssm/#SSM....

[2] https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SSM....

Yeah, the prefixes are killer too because they work well so with IAM. So you if you have multiple teams sharing an AWS account, you can also prefix by team name and limit decryption rights to those users and their resources.

The only downside is that the path is limited to 5 items IIRC. Which you can actually get to pretty fast with stuff like:

/team/service/environment/keyParent/keyChild

"environment" above would be like "prod" or "dev".

I didn't know about the limit although you might be able to get it bumped?

In my experience we haven't had any issues getting to that limit but we only ever use 1 level of depth (the service) and each environment has it's own AWS account so there is no path for environment.

Each service has a IAM Role with an IAM Policy attached that gives it access to all of the keys under the service path.

A way to fix the team prefix (what if 2 teams actually need access to that secret?) would be to not have it in the path but use roles that teams can assume to get access to those secrets.

Yeah, I personally find using separate AWS accounts for dev/test/stage to be a bit of a PITA overall, prefer to isolate those resources via VPCs & IAM policies in an umbrella non-prod account, but definitely see how that would simplify other aspects of setup.

The path limit isn't a huge issue, just something you have to design around up front. As you mentioned in another comment, no reason you can't store a JSON or something in the string if you need deeper nesting.

For secrets needing to be shared between teams I'd just create a different prefix in the place of team, like /shared/, and grant access appropriately. Or just use no team prefix at all and make it accessible if it's for everyone.

But it's quite nice that the service is flexible enough to be useful for a variety of use cases / infrastructure setups.

VPCs are not a substitute for accounts. Most AWS resources must have unique names across the account like lambdas, SQS queues, sns topics etc.

When you have one account you end up prefixing/suffixing resource names for different environments. It gets to be really ugly.

Not a problem. Just deploy with CloudFormation and it will give you unique names for your resources automatically. You can use the same template for everything and filter by the stack tags it auto adds. Still way easier than dealing with creds, billing, and monitoring for 3 different non-prod accounts. Though I admit that the new aws organizations feature has made the billing setup stuff a little easier.

Make your value a JSON string, problem solved ¯\_(ツ)_/¯