Parameter Store Advanced Tiers and SecureString

AWS Systems Manager Parameter Store is a hierarchical store for configuration data and secrets. It allows you to store values such as passwords, database connection strings, license codes, and AMI IDs as parameters. Parameters can be referenced in AWS CloudFormation templates, EC2 user data scripts, Lambda functions, and other AWS services via Systems Manager APIs. The service is fully managed, highly scalable, and provides a secure way to decouple configuration from application code.

Parameter Store offers 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 AWS account and region. The Advanced tier is not free; it costs $0.05 per parameter per month (plus API usage charges), supports parameters up to 8 KB, and allows up to 100,000 parameters per account and region. Advanced-tier parameters also support policies such as expiration notifications and automatic rotation (via integration with AWS Secrets Manager).

Parameter Store supports three parameter types:

SecureString is the only type that provides encryption at rest. When you create a SecureString parameter, Parameter Store uses the specified KMS key to encrypt the value. When you retrieve the parameter, if you have the necessary KMS decrypt permissions, Parameter Store decrypts the value and returns it in plain text. If you do not have decrypt permissions, the API call fails. This ensures that secrets are never stored in plain text and access is tightly controlled.

When you create a SecureString parameter, the following steps occur: 1. You provide the parameter value (e.g., a password) and specify a KMS key ID (or use the default aws/ssm key). 2. Parameter Store calls KMS to generate a data key (a symmetric encryption key) using the specified KMS key. KMS returns two versions of the data key: a plaintext copy and an encrypted copy. 3. Parameter Store uses the plaintext data key to encrypt the parameter value using AES-256-GCM (Galois/Counter Mode). It then discards the plaintext data key from memory. 4. The encrypted parameter value is stored alongside the encrypted data key (which is stored as part of the parameter metadata). 5. When you retrieve the parameter, Parameter Store first checks that you have ssm:GetParameter permission. Then it calls KMS to decrypt the encrypted data key (requiring kms:Decrypt permission on the KMS key). Once decrypted, Parameter Store uses the plaintext data key to decrypt the parameter value and returns it to you.

This envelope encryption approach ensures that the actual encryption key is never stored in plain text and that each parameter can be encrypted with a unique data key. The KMS key itself is used only to encrypt the data key, not the parameter value directly.

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

Creating a SecureString parameter using the AWS CLI:

aws ssm put-parameter \
    --name "/prod/db/password" \
    --value "MySecretPassword123!" \
    --type SecureString \
    --key-id alias/my-custom-key \
    --tier Advanced \
    --tags Key=Environment,Value=Production

Retrieving a parameter value (decrypted):

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

Listing parameters with pagination:

aws ssm describe-parameters --max-results 50

Adding a policy to an Advanced parameter:

aws ssm add-tags-to-resource \
    --resource-type "Parameter" \
    --resource-id "/prod/db/password" \
    --tags Key=Expiration,Value=2025-12-31

Note: Policies are attached via aws ssm tag-resource but the policy itself is a JSON string in the Tags parameter. The correct command uses put-parameter with --policies:

aws ssm put-parameter \
    --name "/prod/db/password" \
    --value "newpassword" \
    --type SecureString \
    --tier Advanced \
    --policies '[{"Type":"Expiration","Version":"1.0","Attributes":{"Timestamp":"2025-12-31T23:59:59Z"}}]'

Advanced-tier parameters support three policy types: 1. Expiration: Automatically deletes the parameter after a specified timestamp. Useful for temporary credentials. 2. ExpirationNotification: Sends an Amazon CloudWatch Events (now Amazon EventBridge) event before expiration. You can configure a number of days before expiration (e.g., 7, 14, 30 days) to trigger notifications. This allows you to set up automated responses like sending an email via SNS or invoking a Lambda function to rotate the secret. 3. NoChangeNotification: Sends a notification if the parameter has not been modified for a specified number of days. This helps detect stale configuration.

These policies are only available for Advanced-tier parameters. Standard-tier parameters have no policy support.

The SAA-C03 exam often asks you to choose between Parameter Store and Secrets Manager, or between Standard and Advanced tiers. Typical scenarios:

Parameter Store Advanced tier can be linked to Secrets Manager for automatic rotation. You create a parameter of type SecureString and specify a Secrets Manager secret ARN as the source. When the secret rotates, the parameter value updates automatically. This is useful for services that cannot directly use Secrets Manager but can read Parameter Store. However, you still pay for both the parameter and the secret.

Parameter Store itself does not support automatic rotation of secrets. Only Secrets Manager provides built-in rotation for RDS, Redshift, DocumentDB, and other services. If you need rotation, you must either use Secrets Manager directly or implement a custom rotation solution (e.g., Lambda function triggered by EventBridge).

| Feature | Standard | Advanced | |---------|----------|----------| | Cost | Free | $0.05/parameter/month | | Max parameters per account/region | 10,000 | 100,000 | | Max parameter size | 4 KB | 8 KB | | API throughput | 40 calls/sec | 100 calls/sec | | Parameter policies | Not supported | Supported (Expiration, ExpirationNotification, NoChangeNotification) | | Integration with Secrets Manager for rotation | No | Yes (via reference) | | Prorated billing | N/A | Per hour |

To verify a SecureString parameter is encrypted: 1. Use aws ssm get-parameter --name <name> (without --with-decryption). The response will show Type: SecureString and Value: ****. 2. Use aws ssm get-parameter --name <name> --with-decryption to see the plaintext value. If you lack kms:Decrypt, you get an access denied error. 3. Check CloudTrail events for PutParameter and GetParameter to audit access.

Parameter Store is a versatile tool for managing configuration and secrets. The SecureString type provides encryption at rest via KMS, and the Advanced tier adds policies and higher limits. For the SAA-C03 exam, focus on understanding the differences between Standard and Advanced, the encryption process, and when to use Parameter Store vs. Secrets Manager. Master the IAM and KMS permissions required for SecureString access, as this is a common exam trap.

A large e-commerce company runs hundreds of microservices on ECS Fargate. Each service needs database credentials for a different database (e.g., product catalog, user profiles). They use Parameter Store to store each database password as a SecureString parameter under a hierarchical path like /dev/prod-catalog/db/password. The services retrieve the password at startup and cache it in memory. The company uses the Standard tier because they have fewer than 10,000 parameters and the passwords are under 4 KB. They use a customer managed KMS key per environment (dev, test, prod) to isolate access. The IAM roles for each service are scoped to only their path using ssm:Recursive and kms:Decrypt on the specific key. This setup is cost-effective (free tier) and secure. However, they faced a problem when a developer accidentally stored a 5 KB TLS certificate in a Standard tier parameter, causing an error. They had to either move to Advanced tier or store the certificate in S3. The lesson: always check the size limit.

A financial services company needs to store API keys for third-party payment gateways that expire every 90 days. They use Advanced-tier SecureString parameters with an Expiration policy set to 90 days from creation. They also attach an ExpirationNotification policy to send a CloudWatch event 7 days before expiration. This event triggers a Lambda function that generates a new API key from the provider and updates the parameter. The company has 500 such parameters, so the cost is $25 per month (500 * $0.05). They chose Advanced tier because they need the policy support and the higher API throughput (100 calls/sec) during peak hours. Without the expiration policy, they would have to manually track and rotate keys. A common mistake is forgetting to set the Expiration policy when creating the parameter, leading to stale keys. They use AWS Config rules to detect parameters without expiration tags.

A manufacturing company uses AWS for analytics but also has on-premises servers that need to access configuration data. They use Systems Manager Hybrid Activations to register on-premises servers as managed instances. These servers run the SSM Agent and can access Parameter Store parameters. They store the connection string for an on-premises database as a SecureString parameter. The on-premises servers have an IAM role (via a service role) that includes ssm:GetParameter and kms:Decrypt. They use the Standard tier because they have only a few parameters. A challenge was ensuring the on-premises servers had the correct KMS key permissions, as they had to include the key policy to allow the IAM role to decrypt. Misconfiguration led to 'AccessDenied' errors during decryption. They resolved it by using the default aws/ssm key initially, then later migrating to a custom key with proper policies. The key takeaway: test permissions thoroughly in a non-production environment.