Alright, let’s talk about the two flavors of SSM Parameter Store: Standard and Advanced. Think of them as the difference between a reliable, no-frills sedan and a souped-up performance model with all the bells and whistles. One gets you from A to B just fine for most trips, while the other is for when you’re hauling something sensitive or need to go really, really fast.

The core distinction boils down to three things: storage size, cost, and advanced features. Let’s cut through the marketing-speak.

Standard Tier: The Workhorse

This is the free tier. Let me say that again: it costs you absolutely nothing. For this reason alone, it should be your default choice for probably 90% of your parameters. Here’s what you get:

  • Storage: Up to 4 KB of data per parameter value. For a secure string (like a database password) or a plain string (like a configuration flag), this is almost always enough. If you’re trying to stuff an entire XML SOAP response in there, you’re using the wrong tool, my friend.
  • Throughput: This is the big limitation. Standard tier parameters have a much lower throughput limit. The official docs will give you a wishy-washy “up to X transactions per second” line, but the real-world takeaway is: don’t use a Standard parameter for something that will be accessed thousands of times per second by your application code. It’s for boot-time configuration, occasional database connection strings, and things of that nature.

Creating a standard parameter is what you’re probably already used to. Here’s how you do it via the CLI:

# Plain string
aws ssm put-parameter \
    --name "/my-app/dev/database-schema" \
    --value "users_v3" \
    --type String \
    --tier Standard

# Secure string (uses KMS encryption)
aws ssm put-parameter \
    --name "/my-app/prod/database-password" \
    --value "s3cr3tSq1rr3l!" \
    --type SecureString \
    --key-id alias/aws/ssm \
    --tier Standard

Notice I didn’t have to specify --tier Standard; it’s the default. I just added it for clarity. The --key-id flag is optional for SecureString; omitting it defaults to the AWS-managed SSM key (alias/aws/ssm), which is perfectly fine for most use cases.

Advanced Tier: For When You Mean Business

You pay for this tier ($0.05 per advanced parameter per month, last I checked). So why would you ever use it? Two compelling reasons:

  1. Larger Parameter Values: Need to store a larger chunk of data, like a RSA private key or a hefty JSON blob? Advanced parameters support values up to 8 KB. That’s double the capacity.
  2. High-Throughput Needs: This is the killer feature. Advanced parameters are designed for high-scale, low-latency access. If you have an application that needs to fetch a parameter on every request without blowing through limits or adding latency, you want Advanced tier.

The other neat trick up its sleeve is Parameter Policies. These are life-cycle policies that can automatically delete or expire parameters after a set time. This is fantastic for temporary credentials, one-time tokens, or any other ephemeral secret you don’t want to forget to clean up.

# Creating an Advanced tier parameter with a life-cycle policy
aws ssm put-parameter \
    --name "/my-app/temp/api-token" \
    --value "eyJhbGciOiJSUzI1NiIsIn..." \
    --type SecureString \
    --tier Advanced \
    --policies '{"Expiration": {"Type": "NoChange", "Version": "1.0", "Attributes": {"Duration": "48"}}}'

That policy will automatically delete this parameter after 48 hours. Brilliant for automation scripts.

The Crucial “Gotcha”: Tier Migration

Here’s the part AWS doesn’t highlight enough, and it’s a real head-scratcher of a design choice: You cannot directly update a Standard parameter to Advanced.

Read that again. It’s absurd, but true.

If you create a parameter as Standard and later realize you need the throughput or size of Advanced, you cannot simply change its tier in-place. The official, clunky workaround is to create a new Advanced parameter and then update your applications to reference the new name. It’s a hassle and a potential point of failure.

Best Practice: Think hard upfront. If there’s even a remote chance a parameter will need high-throughput access (e.g., it’s going to be fetched in a Lambda function’s hot path), just start with Advanced. The minuscule cost is worth avoiding the migration nightmare later. For everything else, happily and confidently use the free Standard tier.