AWS Parameter store

As an noob application developer (many many years ago), I was accustomed to storing configuration information and sometimes even passwords (yikes!) in “property” files which we checked into Git. The arguments I heard were, “oh but the Git repo is Private” or “Its just dev environment, whats the worst that could happen?” or my favorite “We inherited the app this way and we don’t have the bandwidth to change things”. Problem is Private repos sometimes become public, dev environment configs get copied over to production and non-functional backlog keeps growing and vulnerabilities never get fixed which result in systems getting hacked.

There are several tool available these days that let you store config information and expose them via API. Some of the popular services include Consul, Zookeeper, etcd and of course AWS Parameter store. I’ve personally used both Consul and AWS Parameter store and see myself leaning towards Parameter store. Its not like I dislike consul, in fact I do like having all my app’s config in one yaml file and it does much more than store key-value pairs. But having to host it separately has led to some unnecessary heart burn.

What is AWS Systems Manager Parameter Store (SSM)?

Here’s an example of basic app architecture when using parameter store

AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data management and secrets management. You can store data such as passwords, database strings, Amazon Machine Image (AMI) IDs, and license codes as parameter values. You can store values as plain text or encrypted data. You can reference Systems Manager parameters in your scripts, commands, SSM documents, and configuration and automation workflows by using the unique name that you specified when you created the parameter.

The key point in the above except from AWS doc is “hierarchical storage”. In order to store config key-value in SSM, you need to maintain a hierarchy that makes sense to you. It could be /env/app-name/module-name or /app-name/env/module-name or whatever suits your use-case.

Standardize! Have a unique format across the organization that everyone adheres to. You can use that format to search easily. This has helped us to scale safely. Once all your parameters follow the same standard pattern, then all these individual key-value pairs be easily clubbed into one “config file” similar to something you might used to in Consul.

Some Useful CLI Queries to help you search

One of the most helpful Command API call is the get-parameters-by-path

aws --region us-west-2 ssm get-parameters-by-path --path /store-front/qa --recursive --max-items 10

get-parameters-by-path is a paginated operation. Multiple API calls may be issued in order to retrieve the entire data set of results. You can disable pagination by providing the — no-paginate argument. When using — output text and the — query argument on a paginated response, the — query argument must extract data from the results of the following query expressions: Parameters

If your organization has managed to standardize the hierarchy of the parameters, the get-parameters-by-path call like the one above can fetch all the parameters under your application’s (store-front) qa environment in a json or output text format.

Secure and access controlled parameters

AWS SSM Parameter Store normally keeps your sensitive information, so restrict permissions are required to improve your security of the application. Each Parameter Store has a unique Resource ARN per account and region, so you can easier to define role and policy base on the hierarchy of the parameter store.

{
     "Version": "2012-10-17",
     "Statement": [
        {
             "Effect": "Allow",
             "Action": [
                  "ssm:DescribeParameters"
             ],
             "Resource": "*"
        },
        {
             "Effect": "Allow",
             "Action": [
                  "ssm:GetParameters"
             ],
             "Resource": "arn:aws:ssm:us-east 2:123456789012:parameter/prod-*"
        }
    ]
}

Pricing

AWS Systems Manager Parameter Store consists of standard and advanced parameters. Standard parameters are available at no additional charge. When you create advanced parameters, you are charged based on the number of advanced parameters stored each month and per API interaction. Charges for parameters stored for less than a month are prorated on an hourly basis.

Pricing — Parameter Storage
   Standard : No additional charge
   Advanced : $0.05 per advanced parameter per month
Pricing — API Interactions
   Standard : No additional charge
   Advanced : $0.05 per 10,000 Parameter Store API interactions

All in all, SSM Parameter store is a solid option for saving your configuration key-value and in most cases a no brainer, especially if you like keeping your services under a single AWS umbrella.