SSM Parameter Store for Configuration

AWS Systems Manager Parameter Store is a fully managed, serverless service that provides a centralized store for configuration data and secrets. It is designed to decouple configuration from application code, allowing you to manage values like database connection strings, license keys, AMI IDs, and feature flags separately from your application logic. Parameter Store is part of the AWS Systems Manager suite and integrates deeply with other AWS services such as EC2, Lambda, CloudFormation, and CodePipeline.

Before Parameter Store, administrators often hardcoded configuration values into application code, configuration files, or environment variables. This approach led to several problems: security risks (secrets exposed in code repositories), operational overhead (updating values across multiple environments), and lack of auditability. Parameter Store solves these by providing:

When you create or update a parameter, Parameter Store stores the value in a highly available, encrypted database within the AWS Region. The service automatically replicates data across multiple Availability Zones for durability. When a client (e.g., an EC2 instance via SSM Agent) requests a parameter, it sends an API call to the Parameter Store endpoint. The service validates the caller's IAM permissions, retrieves the parameter, and returns it. If the parameter is encrypted, the service returns the ciphertext; the client must then use KMS to decrypt it. Parameter Store supports two tiers: Standard and Advanced. The Standard tier is free, with a maximum parameter size of 4 KB and a limit of 10,000 parameters per account per Region. The Advanced tier costs a small fee, supports parameters up to 8 KB, allows up to 100,000 parameters per account per Region, and provides policies for expiration and notification.

To interact with Parameter Store, you typically use the AWS CLI, SDK, or the AWS Management Console. Common CLI commands include:

Create a parameter:

aws ssm put-parameter \
    --name "/myapp/dev/db/url" \
    --value "jdbc:mysql://localhost:3306/mydb" \
    --type String

Create a SecureString parameter using a custom KMS key:

aws ssm put-parameter \
    --name "/myapp/prod/db/password" \
    --value "MyP@ssw0rd!" \
    --type SecureString \
    --key-id "alias/my-kms-key"

Retrieve a parameter (with decryption for SecureString):

aws ssm get-parameter \
    --name "/myapp/prod/db/password" \
    --with-decryption

Retrieve multiple parameters by path:

aws ssm get-parameters-by-path \
    --path "/myapp/prod/" \
    --recursive \
    --with-decryption

List parameters:

aws ssm describe-parameters

Delete a parameter:

aws ssm delete-parameter \
    --name "/myapp/dev/db/url"

Label a parameter version (Advanced tier):

aws ssm label-parameter-version \
    --name "/myapp/prod/db/url" \
    --parameter-version 2 \
    --labels "production-release"

import boto3
ssm = boto3.client('ssm')
parameter = ssm.get_parameter(Name='/myapp/db/url', WithDecryption=True)
url = parameter['Parameter']['Value']

Parameters:
  DBPassword:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /myapp/prod/db/password

Advanced tier parameters support policies that automate lifecycle management. Policies are JSON documents attached to a parameter. For example:

{
  "Type": "Expiration",
  "Version": "1.0",
  "Attributes": {
    "Timestamp": "2025-12-31T23:59:59Z"
  }
}

You can also set a notification policy that sends an SNS notification when a parameter expires or is about to expire. Policies are immutable once created; you must delete the parameter and recreate it to change the policy.

Access to Parameter Store is controlled by IAM. Actions such as ssm:GetParameter, ssm:PutParameter, ssm:DeleteParameter, and ssm:DescribeParameters are used. For SecureString parameters, you also need kms:Decrypt permission on the KMS key. IAM policies can restrict access to specific parameter paths. Example policy that allows read access only to parameters under /myapp/prod/:

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

Note that the resource ARN for parameters uses parameter/ after the account ID (e.g., arn:aws:ssm:us-east-1:123456789012:parameter/myapp/prod/*).

A large e-commerce company runs hundreds of microservices across multiple AWS accounts and regions. Each microservice needs to connect to a different database. Previously, each service had its own configuration file with hardcoded credentials, leading to security vulnerabilities and operational overhead when passwords rotated. The company implemented Parameter Store with a hierarchical structure: /ecommerce/{env}/{service}/db/{credential}. They used SecureString for passwords and granted each service's IAM role access only to its own path. For example, the order service in production could only read parameters under /ecommerce/prod/order/. Rotation was automated via a Lambda function that updated the parameter and sent an SNS notification. This reduced secret exposure and simplified credential rotation. The main challenge was throttling: with thousands of services calling GetParameter at startup, they hit the default 1,000 TPS limit. They resolved this by implementing client-side caching with a 5-minute TTL and requesting a limit increase to 5,000 TPS.

A media streaming company uses Auto Scaling groups with custom AMIs. They need to ensure all new instances launch with the latest approved AMI. They store the AMI ID as a plaintext String parameter at /infrastructure/ami/latest. A CI/CD pipeline updates this parameter whenever a new AMI is approved. The Auto Scaling group's launch template references the parameter using a dynamic reference: {{resolve:ssm:/infrastructure/ami/latest}}. When the parameter is updated, the Auto Scaling group automatically uses the new AMI for new instances. This eliminates manual updates to launch templates and ensures consistency. The company uses the Advanced tier to set an expiration policy on the parameter, automatically deleting old AMI IDs after 90 days. A misconfiguration occurred when an engineer accidentally deleted the parameter, causing new instances to fail to launch. They recovered by restoring the parameter from a backup of the value and re-creating it. Now they use IAM policies that require MFA for deletion and enable CloudTrail alerts.

Parameter Store is designed for high availability and low latency. However, at scale, consider the following: - Throttling: Default 1,000 TPS for GetParameter. Use caching and batch retrieval (GetParameters) to reduce calls. - Parameter size: Standard tier limits values to 4 KB. If you need larger values, use Advanced (8 KB) or store data in S3 and reference the S3 URI. - Cost: Standard tier is free for parameters and API calls. Advanced tier costs $0.05 per parameter per month and $0.05 per 10,000 API calls. Monitor costs if using many Advanced parameters. - Cross-account access: Use resource-based policies or IAM roles to share parameters across accounts. For example, use a central account to store parameters and grant cross-account access via IAM.