AWS Systems Manager Parameter Store

AWS Systems Manager Parameter Store is a fully managed, serverless capability of AWS Systems Manager that provides secure, hierarchical storage for configuration data and secrets. It allows you to store strings, lists of strings, or secure strings (encrypted with KMS) as parameters. You can reference these parameters from various AWS services (EC2, Lambda, CloudFormation, CodePipeline) and from your application code using the AWS SDK or CLI.

Before Parameter Store, developers often hard-coded configuration values (database URLs, API keys) in code or configuration files, leading to security risks and operational overhead when values changed. Parameter Store centralizes configuration, enables versioning, audit trails via CloudTrail, and fine-grained access control with IAM. It is designed for use cases where you need to store up to 10,000 parameters (Standard tier) or up to 100,000 parameters (Advanced tier) with higher throughput and larger parameter sizes.

When you create a parameter, you specify: - Name: A unique, hierarchical name (e.g., /myapp/prod/db_url) - Description: Optional text - Type: String, StringList, or SecureString - Value: The actual data (up to 4 KB for Standard, 8 KB for Advanced) - Tier: Standard (free, 10,000 params, 40 API calls/sec) or Advanced (paid, 100,000 params, 100 API calls/sec, parameter policies) - Data Type: text or aws:ec2:image (for AMI IDs)

For SecureString, you can specify a KMS key. If you use the default AWS managed key (aws/ssm), no additional cost. You can also use a customer managed key. The encryption happens at rest; in transit, all API calls use TLS.

Parameter Store stores parameters in a highly durable, replicated backend (multiple Availability Zones). When you retrieve a parameter, you specify the name and optionally a version. The service returns the value and metadata (ARN, version, last modified date). The service integrates with CloudTrail to log all API calls (GetParameter, PutParameter, DeleteParameter, etc.).

- Parameter Name: Max length 2048 characters. Must begin with a forward slash for hierarchy (/). Case-sensitive. Supports aws: prefix for AWS managed parameters (e.g., /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2). - Parameter Value: Standard tier max 4 KB (4096 characters). Advanced tier max 8 KB (8192 characters). For larger values, use S3 and store the reference. - Parameter Policies (Advanced tier only): - Expiration: Sets a TTL (e.g., 30 days) after which the parameter is automatically deleted. - ExpirationNotification: Sends events to CloudWatch Events before expiration (e.g., 15, 7, 1 days before). - NoChangeNotification: Sends events if the parameter hasn't been modified for a specified time (e.g., 30 days). - Throughput: Standard tier: 40 transactions per second per AWS account per region. Advanced tier: 100 transactions per second. You can request a throughput increase via Service Quotas. - Versioning: Each update increments the version number. Standard tier retains up to 100 versions; Advanced tier retains up to 100,000 versions. You can retrieve a specific version or the latest. - Labels: You can assign up to 10 labels per parameter (e.g., prod, latest). Labels are mutable and can be moved across versions. - Hierarchy: Use slash-delimited names to create a tree structure. IAM policies can grant access to a subtree (e.g., /myapp/prod/*). - CloudTrail: All Parameter Store API calls are logged. GetParameter calls are not logged by default (you must enable Data Events). - CloudWatch Events: Parameter Store can emit events when parameters are created, updated, deleted, or when policy notifications trigger.

AWS CLI examples:

# Create a parameter (String)
aws ssm put-parameter --name "/myapp/dev/db_url" --value "jdbc:mysql://localhost:3306/mydb" --type String

# Create a SecureString parameter with default KMS key
aws ssm put-parameter --name "/myapp/prod/db_password" --value "MySecretPassword123" --type SecureString

# Create a parameter with Advanced tier and expiration policy
aws ssm put-parameter --name "/myapp/temp/token" --value "temporary" --type String --tier Advanced --policies "[{\"Type\":\"Expiration\",\"Version\":\"1.0\",\"Attributes\":{\"Timestamp\":\"2025-12-31T23:59:59Z\"}}]"

# Retrieve a parameter (latest version)
aws ssm get-parameter --name "/myapp/dev/db_url"

# Retrieve a parameter with decryption (for SecureString)
aws ssm get-parameter --name "/myapp/prod/db_password" --with-decryption

# Retrieve parameters by path (hierarchy)
aws ssm get-parameters-by-path --path "/myapp/prod" --recursive

# List parameters
aws ssm describe-parameters

# Delete a parameter
aws ssm delete-parameter --name "/myapp/dev/db_url"

SDK Example (Python):

import boto3

ssm = boto3.client('ssm', region_name='us-east-1')

# Get a plaintext parameter
response = ssm.get_parameter(Name='/myapp/dev/db_url')
value = response['Parameter']['Value']

# Get a SecureString parameter (decrypt)
response = ssm.get_parameter(Name='/myapp/prod/db_password', WithDecryption=True)
secret = response['Parameter']['Value']

# Get parameters by path
response = ssm.get_parameters_by_path(Path='/myapp/prod', Recursive=True)
for param in response['Parameters']:
    print(param['Name'], param['Value'])

While both services store secrets, Parameter Store is optimized for configuration data with lower cost (free tier for Standard) and simpler API. Secrets Manager is better for secrets that require automatic rotation, cross-region replication, and fine-grained access with resource-based policies. The exam often tests when to use each: use Parameter Store for non-sensitive config (DB URLs, feature flags) and for secrets with low rotation frequency; use Secrets Manager for database credentials, API keys that need rotation, or when you need to share secrets across accounts.

Access to parameters is controlled by IAM policies. You can restrict access based on parameter path, name, type, and version. Example policy:

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

Use aws:SourceArn and aws:SourceAccount conditions to prevent cross-service confused deputy problems.

Standard tier: Free (up to 10,000 parameters, 40 API calls/sec). Advanced tier: $0.05 per parameter per month, plus $0.05 per 10,000 API calls (first 10,000 free per month). SecureString encryption with default KMS key is free; using a customer managed key incurs KMS costs.

Scenario 1: Microservices Configuration Management

A company runs 50 microservices on ECS Fargate. Each service has environment-specific configuration (database URLs, API endpoints, feature flags). Previously, they used environment variables in task definitions, but updating a value required redeploying the service. They migrated to Parameter Store: each service retrieves its configuration from a hierarchical path like /myapp/{service_name}/{environment}/. For example, the 'user-service' in production reads from /myapp/user-service/prod/db_url. They use the Advanced tier for the production environment to support parameter policies (e.g., expiration for temporary credentials). The IAM role for each ECS task definition has a policy granting ssm:GetParameter and ssm:GetParametersByPath on the service-specific path. This allows them to update configuration without redeployment: they change the parameter value, and the service picks it up on the next read (they implement a 5-minute cache with refresh). They also use CloudWatch Events to trigger a Lambda function that sends a notification to the team when a critical parameter changes.

Scenario 2: Securing Database Credentials

A web application uses RDS MySQL. The database password is stored as a SecureString in Parameter Store under /myapp/prod/db_password. The application (running on EC2 with SSM Agent) retrieves the password at startup using the AWS SDK with WithDecryption=True. The EC2 instance profile has permissions to ssm:GetParameter and kms:Decrypt on the specific KMS key. They rotate the password manually every 90 days by updating the parameter. For audit, they enable CloudTrail data events for GetParameter to log all access to the secret. They also set a NoChangeNotification policy to alert if the password hasn't been rotated in 80 days. One common misconfiguration: granting ssm:GetParameter on * instead of the specific parameter ARN, which would allow access to all parameters in the account.

Scenario 3: Sharing AMI IDs Across Accounts

A DevOps team manages a golden AMI pipeline. The latest AMI ID is stored in Parameter Store as a String with name /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 (AWS managed). They also store custom AMI IDs in /myapp/ami/latest. In CloudFormation templates, they use {{resolve:ssm:/myapp/ami/latest}} to automatically use the latest AMI when launching EC2 instances. This eliminates hard-coded AMI IDs and ensures instances always use the approved image. They also use aws:ec2:image data type to validate that the value is a valid AMI ID. One challenge: if the parameter is deleted accidentally, the next CloudFormation deployment fails. They mitigate this with a backup parameter and a Lambda function that replicates the value to another region for disaster recovery.