Scaling Parameter Store reads for production workloads

Consider an order-processing service running on Amazon ECS Fargate during a weekend sale. Under normal conditions, 20 tasks read configuration values from Parameter Store at startup. As traffic increases, the service scales to 200 tasks, causing many tasks to request the same parameters at nearly the same time. If these requests exceed the available throughput, new tasks can start slowly or fail, potentially delaying or interrupting customer orders.

When an application exceeds the available quota, its logs can show a ThrottlingExceptionor RateExceeded error from GetParameter, GetParameters, or GetParametersByPath. To diagnose such issues, you can check the error source in application logs, or trace the relevant API calls in CloudTrail. Then compare the timing against a known scaling or deployment event. Throttling or latency issues that cluster around this event are a strong signal that concurrent parameter requests caused the bottleneck.

You can address Parameter Store throughput issues in the following complementary ways:

1. Enable higher throughput. Increase the quota so that production workloads handle concurrent reads during normal operation and scaling events. The cost is based on usage. For example, a workload generating approximately 456,000 parameter interactions for a 60-hour sale costs about $2.28.
2. Optimize read patterns. Reduce unnecessary API traffic by retrieving only the parameters the application needs and caching values that it reads repeatedly.

Enabling higher throughput raises the quota for each API action in a single account in a single Region. Throughput for SecureString parameters might be further limited by AWS KMS.

API action	Default quota	Higher-throughput quota
GetParameter	Shared 40 TPS	10,000 TPS
GetParameters	Shared 40 TPS	1,000 TPS
GetParametersByPath	Shared 40 TPS	100 TPS

Improving application resilience by enabling higher throughput

Consider enabling higher throughput in the following scenarios:

1. Parameter Store is part of a production request path, not a one-time deployment. A higher quota ensures configuration requests don’t become a bottleneck at runtime.
2. Many instances, containers, or Lambda functions read parameters within the same window. Higher throughput lets your fleet scale without individual instances competing for a shared, undersized quota.
3. Deployments, restarts, or autoscaling events produce bursts of reads. You can absorb these predictable spikes, so a routine deployment doesn't fail.
4. Usage regularly approaches or exceeds the default 40 TPS quota. By proactively increasing your quota, you eliminate bottlenecks instead of waiting for them to recur under heavier load.
5. You want more throughput but don’t want to redesign the system. Enabling the higher-throughput setting increases your quota immediately without touching your infrastructure or application.

When you enable higher throughput, you increase the request quota for your AWS account and Region.

The cost of higher throughput is $0.05 per 10,000 parameter interactions. A request that retrieves multiple parameters counts as one interaction for each parameter returned.

An order-processing example
Assume that our order-processing service runs 20 tasks under normal conditions. During a promotional event lasting 60 hours (6 p.m. Friday to 6 a.m. Monday), it scales to 200 tasks for the duration of the sale. To limit stale values, each task refreshes the database endpoint, inventory service, and order dead-letter queue parameters every 5 minutes as follows:

• 200 tasks × (60 hours × 12 refreshes per hour) = 144,000 refresh calls.
• 144,000 calls × 3 parameters each = 432,000 parameter interactions.
• A Lambda function handling checkout cold starts approximately 8,000 times during traffic bursts, creating 24,000 additional interactions.

The result is approximately 456,000 parameter interactions for the 60-hour sale. With higher throughput enabled, the application avoids throttling errors caused by hitting quota limits. At $0.05 per 10,000 interactions, the total additional cost is $2.28.

Because the higher-throughput setting is billed on usage, you can enable it before an anticipated traffic spike and disable it afterward. If your application is throttled during normal production workloads, however, consider enabling higher throughput as a permanent setting.

Enabling higher throughput in the AWS console and CLI

A throughput setting applies at the account and Region level. It takes effect for all applications reading from Parameter Store in the specified scope.

In the console, increase throughput by choosing Systems Manager > Parameter Store > Settings.

In the AWS CLI, run the following command to enable higher throughput, replacing the AWS Region and account ID with your own.

shell
aws ssm update-service-setting \
  --setting-id arn:aws:ssm:us-east-1:123456789012:servicesetting/ssm/parameter-store/high-throughput-enabled \
  --setting-value true

Optimizing read patterns

Optimizing how your application retrieves parameters is an operational best practice. If your application retrieves only necessary parameters and caches values that it reads repeatedly, it reduces latency and uses throughput more efficiently.

Avoid retrieving more than your application needs. Parameter hierarchies are a useful way to organize configuration values. For example, you can group parameters for a checkout application as follows: /prod/checkout/db-host, /prod/checkout/inventory-service-endpoint, and /prod/checkout/order-dlq-arn. It’s tempting to use GetParametersByPath to retrieve an entire subtree when your application knows the specific parameters it needs.

`# Gets the subtree, including parameters your app might not need`
`aws ssm get-parameters-by-path \
  --path "/prod/checkout/" \
  --recursive \
  --with-decryption`

With higher throughput enabled, GetParametersByPath is limited to 100 TPS, compared to 1,000 for GetParameters and 10,000 for single-parameter GetParameter calls. With default throughput, all three share the same 40 TPS pool. If your application knows its parameter names, requesting them directly means that your application is less likely to hit the quota.

`# Retrieves only the parameters your app actually needs
aws ssm get-parameters \
  --names "/prod/checkout/db-host" "/prod/checkout/inventory-service-endpoint" "/prod/checkout/order-dlq-arn" \
  --with-decryption`

As a best practice, remove unused parameters from a hierarchy. You prevent GetParametersByPath calls from returning parameters that the application doesn’t need and can reduce the paginated requests for larger hierarchies.

Cache parameter values in the application. Many configuration values don’t change often enough to justify reading them on every request. If your application reads the same parameter many times per minute, read it once and reuse the value for an appropriate period. For example, use a short reuse window for values that change often and a longer one for values that don’t.

The following sample code defines a get_parameter() function. You can call this function every 10 seconds for a specific parameter. The first call after the five-minute TTL expires retrieves the latest value from Parameter Store and updates the cache.

`import time
import boto3

ssm = boto3.client("ssm")
_cache = {}
TTL_SECONDS = 300  # how long to trust a cached value

def get_parameter(pname):
    now = time.time()
    if pname in _cache:
        value, cached_at = _cache[pname]
        if now - cached_at < TTL_SECONDS:
            return value

    response = ssm.get_parameter(Name=pname, WithDecryption=True)
    value = response["Parameter"]["Value"]
    _cache[pname] = (value, now)
    return value`

Spread out reads when many resources start at the same time. A common source of throttling is simultaneous startup. This occurs when many EC2 instances or ECS tasks read the same parameters within the same second during deployment or scaling. You can avoid concentrating the read burst by reading parameters once and passing the values to the application, or by staggering reads with a slight delay.

For Lambda functions, consider the AWS Parameters and Secrets Lambda Extension. The extension caches parameter values locally for reuse across invocations. This reduces both the number of calls to Parameter Store and the latency of retrieving values.

Summary

Your application logs might show ThrottlingException or RateExceedederrors from GetParameter, GetParameters, or GetParametersByPath. The results of throttling can be outages and degraded customer experience.

Enabling the higher-throughput setting removes the risk of hitting an API quota during production. You can enable it before an anticipated event and disable it afterward, or leave it on permanently. For most production workloads, the operational benefit of resilience outweighs the modest cost.

You can also address latency by optimizing read patterns. For example, you can replace a GetParametersByPath call with GetParameters, or cache values in your application. The combination of higher throughput and optimized reads helps make your application more resilient when multiple tasks run concurrently.

Questions? Comments? Leave them below!