4 ms·
We’ve been using SSM parameter store to store our secrets (as secure strings). To manage access in a more granular manner we use a namespace approach where the
by laurentl 8y ago
We’ve been using SSM parameter store to store our secrets (as secure strings). To manage access in a more granular manner we use a namespace approach where the parameters are prefixed with the service or API they’re attached to, or “global” if they’re meant for everyone. Each service has read rights for <service>-* and global-* parameters. We use a python library called SSM-cache to cache values locally and avoid the cost of a look-up each time.
I’ve recently seen secret manager and I first thought it was a rebranding of SSM PS. A quick google search seems to indicate that this is more or less the case at the moment, but the service will probably pick up new features as it matures.
- gtsteve 8y agoThere is no additional charge for SSM parameter store but rate limits apply (and I can't find out what they are). I have read accounts from people on HN who work on large AWS accounts who have been bitten by this. The secret manager bills per request, so presumably that means they'll happily serve as many requests as you want. It also has some nice tooling around cycling secrets. It's an important distinction when choosing which one to work with. To contribute an additional idea not seen in this topic yet - my application predates both these services so it just reads from a JSON file in an s3 bucket that is encrypted at rest. It works just as well as all the above.
- dmlittle 8y agoYou should look into getParamtersByPath instead of getParameters. You should be able to get past the rate limits for quite some time (we haven't hit the getParamtersByPath limits yet)