AWS Secrets Manager vs. SSM (Systems Manager Parameter Store)

AWS has a lot of services. This can sometimes be confusing when assessing what services should be used in a solution. For example, many of my customers ask about the difference between AWS Secrets Manager and Systems Manager Parameter Store due to the similarities of the two services. This is very understandable. However, while the basic use cases may seem to have some overlap, there are a few key differences to keep in mind.

1. Secrets Manager should be remembered by its name; secrets are quite important here. The point of AWS Secrets Manager is to encrypt by default your secrets and also rotate secrets for security's sake. You are not storing plaintext here; you are storing passwords and API keys that need to be decrypted for programmatic usage. Think database passwords for RDS. As such, this service costs more by default in comparison to SSM.
2. Systems Manager Parameter Store (SSM) is similar in some ways but has a different focus. It is made to store multiple types of configuration parameters, so parameters, configuration settings, and Amazon Resource Names (ARNs) should live here; it could be a path to another resource or an AMI ID that is used across the organization. Yes, even secrets can be stored if configured appropriately, but that's not the default behavior. What's really cool is that SSM can even call Secret's Manager through the GetParameter and GetParameters APIs!

That's the high-level summary. Obviously, there is a lot more detail that I could cover here, but I suggest you go to AWS's official documentation to look at the FAQS for SSM and AWS Secrets Manager in depth if you want to know more.

Just remember to ask yourself "Do I have a secret that needs to be rotated and not break my application?" If it's a yes, tell yourself to put that item in AWS Secrets Manager. You can even call it through SSM when needed by referencing the parameter like /aws/reference/secretsmanager/mysecretname!