Managing Parameter Store throughput
Parameter Store throughput defines the number of API transactions per second (TPS) that Systems Manager can process. The throughput setting applies to the Parameter Store as a whole rather than an individual API. By default, Parameter Store is configured with a standard throughput quota that is often suitable for low- to moderate-volume workloads. For higher-volume workloads, you can enable higher throughput, which increases the maximum number of supported transactions per second for your account and Region. You can enable and disable higher throughput as needed.
Throughput quotas in Parameter Store
The following table lists the transaction limits for different API categories using default and higher throughput. API actions include AWS console usage, AWS CLI commands, and application reads. For more information on quotas and rate limits, see AWS Systems Manager endpoints and quotas.
| API actions | Default throughput | Higher throughput |
|---|---|---|
| GetParameter, GetParameters, and GetParametersByPath | 40 TPS shared across all three API actions combined |
GetParameter: 10,000 TPS;
GetParameters: 1,000 TPS;
GetParametersByPath: 100 TPS
|
| DeleteParameter and DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters, GetParameterHistory, LabelParameterVersion, UnlabelParameterVersion, and PutParameter | 3 TPS |
10 TPS |
In this context, a transaction is one API action for an account in a single Region. For example, the following command creates a single transaction.
aws ssm get-parameter --name "/myapp/prod/log-level"
The API actions can be distributed among applications. For example, each of the following scenarios reaches the default throughput limit of 40 TPS:
-
1 application makes 40
GetParametercalls per second. -
10 applications make 4
GetParametercalls per second. -
40 applications make 1
GetParametercall per second.
A throughput limit applies to all APIs within a category. For example, the following combination of simultaneous parameter calls for an application meets the default limit of 40 TPS for parameter retrieval APIs:
-
GetParametermakes 25 calls per second. -
GetParametersmakes 10 calls per second. -
GetParameterByPathmakes 5 calls per second.
The DescribeParameters calls have a separate throughput limit. An application can make the preceding calls while also making 3 DescribeParameters calls per second
without exceeding the overall limit for standard throughput.
If your production requests exceed a throughput limit during standard operation or planned periods of high traffic, use the following optimization techniques.
Optimizing throughput in Parameter Store
When Parameter Store receives multiple requests for parameters in a short interval, your application can experience throttling. For example,
CloudWatch Logs or your application logs show ThrottlingException or RateExceeded errors raised by the SDK
when it calls GetParameter, GetParameters, or GetParametersByPath. In other cases, application logic
successfully retries API calls, but application latency increases. The result can be application outages, suboptimal user experience, failed deployments,
complex workarounds, and lost developer time.
Multiple factors can lead to your application hitting Parameter Store quota limits, including the following:
-
Your application scales out quickly because of a spike in traffic. For example, your application normally runs on 5 Amazon EC2 instances. When traffic increases suddenly, Amazon EC2 Auto Scaling launches 50 more instances. If each instance reads parameters when it starts, the combined requests can exceed the default request limit.
-
Your container service starts many tasks at the same time. For example, an Amazon ECS service might start many replacement tasks during an update, and each task might read settings from Parameter Store when it starts.
-
Your Lambda functions receive many requests at the same time. For example, Lambda might start many function environments to handle the increased traffic. Each function environment might read parameters when it starts.
-
Your build or release process reads many parameters in a short time interval. For example, a build job might read settings for several applications or environments.
-
Your application reads many parameters by path. For example, your application repeatedly reads all parameters under
/myapp/prod/instead of reading only the specific parameters it needs. These repeated requests can exceed the default request limit.
You can address Parameter Store throttling in the following complementary ways:
-
Reducing throughput
Your application might be retrieving more data than it needs or retrieving it in an inefficient way.
-
Enabling higher throughput
You can increase application resilience by increasing throughput quota for a specified Region and account. You can enable and disable the higher-throughput setting at any time for periods of high traffic. For production workloads that regularly generate throttling errors, consider enabling the setting permanently.
Reducing throughput in Parameter Store
Whether you use standard or higher throughput, review the frequency and type of calls to Parameter Store. In some cases, you can reduce the number of requests without changing your parameters. Because cost is determined based on usage rather than on a subscription or tier model, the result is fewer billed API interactions.
-
Cache parameter values in your application instead of reading the same values on every request.
For example, if your application reads
/myapp/prod/log-levelmany times per minute, the application can read the value once and reuse it for a short period of time. This technique reduces repeated calls to Parameter Store. Choose a shorter reuse period for values that change often, and a longer reuse period for values that rarely change. -
Use GetParameters when you know the names of multiple parameters.
For example, instead of making separate GetParameter calls for the parameters
/myapp/prod/database/host,/myapp/prod/log-level, and/myapp/prod/vendor/merchant-id, you can retrieve a list of these parameters in a singleGetParametersrequest. -
Avoid reading more parameters than your application needs.
If your application needs only a few known parameters, use
GetParameterorGetParametersinstead of repeatedly reading an entire path such as/myapp/prod/. Use GetParametersByPath when your application needs a group of parameters under a path. When you use higher throughput, theGetParameterquota is 100x the quota forGetParametersByPath. -
Spread out parameter reads when many resources start at the same time.
For example, if many Amazon EC2 instances or Amazon ECS tasks start during an update, avoid having every resource read parameters at exactly the same time. The quotas are per-second. Where possible, read parameters once and cache their values to the application, or add a small delay so that requests do not all occur in the same second.
-
For Lambda functions, consider using the AWS Parameters and Secrets Lambda Extension.
The extension can store parameter values locally for reuse by the function. This technique can reduce the number of calls to Parameter Store and can also reduce the time needed to retrieve parameter values. For a sample walkthrough of this technique, see Using the AWS Parameter and Secrets Lambda extension to cache parameters and secrets
.
Increasing throughput
For higher-volume workloads, you can enable higher throughput. This setting increases the maximum number of supported transactions per second for your account and Region, at a cost. Consider higher throughput in the following scenarios:
-
Your application has a temporary need for higher throughput.
For example, a webstore might read parameters more often during a weekend sale. You can enable higher throughput before the sale begins, and then return to standard throughput after the sale ends. You can enable or disable higher throughput at any time from the Parameter Store Settings page or by using the AWS CLI.
-
Your production application regularly retrieves parameters concurrently and runs into throttling issues.
Concurrent retrieval can happen when multiple instances, containers, functions, or build jobs read parameters from Parameter Store at the same time. Examples include the following:
-
Your application scales out quickly. For example, your application normally runs on 5 Amazon EC2 instances. When traffic increases suddenly, Amazon EC2 Auto Scaling launches 50 more instances. If each instance reads parameters when it starts, the combined requests can exceed the default request limit.
-
Your container service starts many tasks at the same time. For example, an Amazon ECS service might start many replacement tasks during an update, and each task might read settings from Parameter Store when it starts.
-
Your Lambda functions receive many requests at the same time. For example, Lambda might start many function environments to handle the increased traffic. Each function environment might read parameters when it starts.
-
Your build or release process reads many parameters in a short time interval. For example, a build job might read settings for several applications or environments.
-
Cost considerations for higher throughput
For the higher throughput option, additional charges apply. For current Parameter Store API pricing and examples, see
AWS Systems Manager Pricing
Charges are based on Parameter Store API interactions. An API interaction is defined as an
interaction between an API request and an individual parameter. For example, if a single GetParameter request returns 10 parameters,
this request counts as 10 Parameter Store API interactions for billing purposes.
Consider a scenario where you want to switch to higher throughput for a short period of increased traffic. Your webstore holds a weekend sale and
makes 1,000,000 Parameter Store API interactions during the sale. If the cost for higher throughput in this example is
$0.05 per 10,000 API interactions, the total additional cost is approximately $5. You can switch back to standard throughput
at the end of the sale and stop incurring costs.
Combining throughput and parameter tiers
Throughput operates independently of parameter tiers. Whereas parameter tiers control storage limits and feature availability, throughput settings control request volume. To meet performance and scale requirements, you can use tiers and throughput together.
For example, to support simple and low-load applications, you can use standard parameters with default throughput. To support large-scale, high-frequency access patterns, you can combine advanced parameters with higher throughput. In general, increasing throughput is necessary when your application exceeds default TPS limits (for example, during bursts of concurrent reads or writes), regardless of which parameter tier you use.
For more information about maximum throughput and other Parameter Store quotas, see AWS Systems Manager endpoints and quotas.
Changing the throughput setting in Parameter Store
The following procedures describe how to use Systems Manager to change the number of transactions per second that Parameter Store can process for the current AWS account and AWS Region. You can change the setting at any time.
