Estimate Secrets Manager API calls per month (GetSecretValue volume)
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
This page is the Secrets Manager API-call measurement workflow, not the bill-boundary page: the goal is to turn CloudTrail evidence, process starts, cache refreshes, hot-path fetches, and retry behavior into a defendable monthly request model.
If you are still deciding which line items belong inside the Secrets Manager bill, go back to the pricing guide first.
Evidence pack before you estimate anything
- CloudTrail or equivalent evidence: the fastest starting point for operation counts and top callers.
- Process-start data: deploys, pod churn, task launches, and cold starts that explain request bursts.
- Cache refresh behavior: how often long-running services refresh secrets outside startup.
- Hot-path fetch checks: whether any service still calls Secrets Manager inside request or job loops.
- Incident windows: retries, restart storms, or throttling periods that should stay separate from baseline.
Method 1: measure and scale (best)
- Pick a representative window (7–30 days).
- Count Secrets Manager API calls (total and by operation if possible).
- Scale to monthly: calls/month ≈ calls/window × (30 / days in window).
- Split by environment (prod vs non-prod) because churn patterns differ.
If you only have peak/incident data, don’t use it as your baseline—store it as a separate peak scenario.
Method 2: model from runtime behavior (good when you can’t measure yet)
In many systems, Secrets Manager calls happen at process start. That means you can model calls from starts/month:
- Starts/month ≈ avg running instances × restarts per instance per month
- Calls/start ≈ secrets fetched per start (often multiple secrets)
- Calls/month ≈ starts/month × calls/start
How to estimate “starts/month” in common platforms
- Kubernetes: pods/day × (restarts + deploy rollouts) × containers fetching secrets
- ECS: task launches/day × secrets per task definition (plus redeploy churn)
- Lambda: cold starts roughly track concurrency and traffic burstiness (don’t assume one start/day)
A common multiplier: a single pod may have multiple containers, each fetching the same secrets.
Separate baseline demand from spike behavior
- Baseline demand: normal process starts, planned refreshes, and stable service counts.
- Deploy-driven spikes: rolling deploys, scale-outs, and cold starts that are real but not baseline.
- Retry-driven spikes: timeouts, auth failures, and transient issues that multiply requests.
- Hot-path fetch inflation: secrets fetched per request or per job loop, which is a measurement red flag and an optimization target.
If you suspect hot-path fetch, estimate calls as app requests × secret fetches per request and keep that scenario separate from normal startup-driven behavior.
Worked example (structure)
- Average running pods: 200
- Pod restarts + deploy rollouts: 3 starts/pod/month
- Secrets fetched per start: 4
- Baseline calls/month ≈ 200 × 3 × 4 = 2,400 calls/month
- Peak scenario: incident causes 5× restart churn → 12,000 calls/month equivalent for that period
Turn calls into cost
Use the Secrets Manager cost calculator with secrets/month and calls/month (and your $ per 10k pricing).
How to validate and attribute (so you can fix the real driver)
- Use CloudTrail event history to find top callers and operations (GetSecretValue dominates in many systems).
- Compare “calls per start” across services; one misconfigured service often dominates total calls.
- Re-check deploy/incident windows; retries and restarts are common spike explanations.
When the estimate is good enough to hand off
- Go back to Secrets Manager pricing if you still are not sure whether the cost belongs to secret-months, API requests, or an adjacent service.
- Move to Secrets Manager cost optimization when the request model is stable enough that caching or refresh changes can be measured against it.
Next steps
Sources
- AWS Secrets Manager pricing
- Retrieving secrets (API usage context)
- CloudTrail event reference (for attribution workflow)