DEV Community: Aparna Krishnamoorthy

Scaling Parameter Store reads for production workloads

Aparna Krishnamoorthy — Thu, 23 Jul 2026 19:33:35 +0000

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:

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.
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:

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.
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.
Deployments, restarts, or autoscaling events produce bursts of reads. You can absorb these predictable spikes, so a routine deployment doesn't fail.
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.
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!

Improving operational resilience by decoupling code deployments from feature activation using AWS AppConfig feature flags

Aparna Krishnamoorthy — Wed, 13 May 2026 14:31:22 +0000

Shipping quickly isn’t the hard part anymore. The hard part is recovering when something goes wrong.
A lot of teams still release features the same way: deploy code and whatever’s in that deployment goes live immediately. It’s simple, and it works — until it doesn’t. Because when a feature causes problems, you don’t just turn off the feature. You end up rolling back the entire deployment. That means waiting, coordinating, and sometimes introducing new risk just to undo the last change.
That’s a heavy price to pay for something that should be lightweight.

*Where the risk actually comes from *
The issue isn’t deployments themselves. It’s the fact that feature activation is tightly coupled to them. When those two things are tied together, every release becomes an all-or-nothing event. A small issue can impact your entire user base, and recovery depends on how quickly you can redeploy or roll back. That’s where Mean Time to Resolution starts to creep up—not because the fix is complicated, but because the mechanism to apply it is. It also makes it difficult to test safely in production. You either release to everyone or no one, which isn’t much of a choice.

Separating deployment from release
A more resilient approach is to treat deployment and feature release as two different concerns. You can deploy code whenever you want, but keep new functionality inactive until you explicitly turn it on. That control layer is what feature flags provide.

Using AWS AppConfig on Amazon Web Services, feature state becomes configuration rather than code. Your application checks that configuration at runtime and decides which path to execute.
That one change removes the need to redeploy just to change behavior.

What changes in practice
Instead of hardcoding whether a feature is on or off, your application asks AWS AppConfig for the current state and responds accordingly. The flow is straightforward: the application retrieves configuration, evaluates the relevant flag, and executes the appropriate logic.
Here’s a simple example. Imagine you’re introducing a new checkout flow.
Your configuration might look like this:

{
    "version": "1",
    "flags": {
        "enableNewCheckout": {
            "name": "Enable new checkout experience",
            "attributes": {
                "version": { "constraints": { "type": "string" } }
            }
        }
    },
    "values": {
        "enableNewCheckout": {
            "enabled": true,
            "version": "2.0"
        }
    }
}

That lives in AWS AppConfig, not in your codebase.

To retrieve it at runtime, use AWS AppConfig Agent. The agent is an Amazon-managed process that retrieves configuration data from AWS AppConfig in the cloud. It caches configuration data locally and asynchronously polls the AWS AppConfig data plane for updates. This approach keeps configuration data readily available to your application while reducing latency and cost.
Although you can retrieve configuration data by calling the APIs directly, using the agent is the recommended approach. It improves application performance and simplifies configuration management.

With your configuration profile stored in AWS AppConfig and the agent running in your compute environment, using the configuration is just a conditional in your application logic:

const application_name = "MyDemoApp";
const environment_name = "MyEnvironment";
const config_profile_name = "MyConfigProfile";


async function loadFlag(flag_name) {
    // retrieve a single flag's data by providing the "flag" query string parameter
    // note: the configuration's type must be AWS.AppConfig.FeatureFlags
    const url = `http://localhost:2772/applications/${application_name}/environments/${environment_name}/configurations/${config_profile_name}?flag=${flag_name}`;
    const response = await fetch(url);
    return await response.json();
}


export async function handleCheckout(req, res) {
  const enableNewCheckoutFlag = await loadFlag("enableNewCheckout"); // {"enabled":true,"version":"2.0"}


  if (enableNewCheckoutFlag.enabled) {
    return newCheckoutFlow(req, res);
  }


  return legacyCheckoutFlow(req, res);
}

That small shift—moving the decision out of your deployment and into runtime configuration—gives you a surprising amount of control.

Reducing mean time to resolution with gradual deployments
One of the less obvious benefits of feature flags is how they change how quickly you understand and resolve issues, not just how you prevent them.
When you roll out a feature gradually using AWS AppConfig, you’re effectively turning a production release into a controlled experiment. Instead of exposing 100% of users at once, you start with a small segment and watch what happens. That alone shortens the feedback loop. If something is wrong, you’ll see it earlier—and in a much smaller slice of traffic. But the real impact on mean time to resolution comes from the combination of three things working together:
First, reduced scope. If only 5% of users are impacted, you’re not dealing with a full-scale incident. That lowers urgency just enough to make debugging more methodical instead of reactive.
Second, clearer signal. When a change is introduced gradually, it’s easier to correlate cause and effect. You’re not sifting through noise from a full deployment—you’re looking at a controlled change with a defined rollout window.
Third, faster reversal. If metrics start trending in the wrong direction, you don’t need to redeploy or coordinate a rollback. You stop the rollout or revert the configuration. Integration with Amazon CloudWatch or monitoring platforms like DataDog and New Relic (using custom extensions) allow you to define guardrails. If key metrics cross a threshold, AWS AppConfig can automatically roll back to a known good configuration without waiting for someone to step in.
Put together, gradual deployments don’t just reduce blast radius—they reduce the time it takes to understand, isolate, and resolve issues in the first place.
AWS AppConfig also supports pre-deployment syntax and functional validation through integration with AWS Lambda. Pre-deployment validation reduces the chance of a bad configuration making it into production in the first place.

Operational feature flags that make a difference
Once you start using feature flags, it’s tempting to think of them only in terms of user-facing features. In practice, some of the most valuable flags are operational—they exist purely to give you more control during incidents or high-risk changes.
A simple but powerful example is an operational toggle or kill switch. Instead of rolling back an entire service, you can disable a specific capability that’s causing issues. This is especially useful for integrations or newly introduced dependencies where failure modes aren’t fully understood yet.
Another common pattern is traffic shaping. You can route a percentage of requests to a new code path, a new backend, or even a different region. If something looks off, you dial it back immediately. This gives you a level of control that traditional deployments don’t offer.
You can also use flags to control fallback behavior. For example, if a downstream dependency starts failing, a flag can switch your application into a degraded mode—serving cached data, skipping non-critical steps, or simplifying responses. That kind of switch can be the difference between a partial degradation and a full outage.
There’s also value in flags that control operational safeguards. Rate limiting thresholds, retry behavior, or timeout values can all be externalized into configuration. Instead of pushing a code change during an incident, you adjust behavior in real time.
Finally, some teams use feature flags to control observability itself. Increasing logging, enabling additional metrics, or turning on debug paths can all be done dynamically. When paired with validation via AWS Lambda, you can safely introduce these changes without risking malformed configurations.
None of these flags are particularly complex on their own. What matters is that they give you options when things aren’t going smoothly.
And that’s really the point: operational resilience isn’t just about preventing failures—it’s about having enough control to respond effectively when they happen.

When this starts to matter
This approach becomes especially valuable once you’re deploying frequently or operating systems where uptime really matters. If you’ve ever had to rush a rollback, or sit through a tense deployment wondering if something might break, you’ve already felt the limitations of tightly coupled releases.
Decoupling feature activation from deployment doesn’t eliminate failures, but it makes them smaller and easier to recover from.

Most teams focus on improving how they deploy code. Fewer spend time improving how they release features. Using AWS AppConfig shifts that focus. It gives you a way to control behavior independently of deployments, which in turn makes your system more resilient and your releases less stressful. It’s not a massive architectural overhaul. It’s a small change in where decisions are made.

But it has a disproportionate impact on how safely you can move.

For more information, see the AWS AppConfig User Guide.