AWS costs: Secrets Manager vs Parameter Store - $0.40/secret decided

AWS Secrets Manager costs $0.40 per secret per month plus $0.05 per 10,000 API calls, with no volume discount and no permanent free tier. AWS Systems Manager Parameter Store is free for standard parameters and $0.05 per parameter per month for advanced ones — and here's the part almost nobody expects: rotating a secret, however often you do it, doesn't add a cent to that $0.40, because AWS explicitly does not charge you for creating new secret versions.

Jake found this page because his bookkeeper asked why last month's AWS bill had a $6.02 line item he didn't recognize. He runs a two-location phone repair and resale shop, and somewhere along the way one of his developers wired up Secrets Manager to hold the database password for the inventory system, an API key for the payment processor, and SSH keys for the two EC2 boxes that run the point-of-sale backend. Six dollars a month felt small until he multiplied it by "however many more of these things get added later," and that's a completely reasonable thing to want to understand before it happens, not after.

This post walks through exactly what AWS charges for each service, using AWS's own published pricing and its own worked examples — not estimates from a calculator site, not a vendor's marketing page for a competing secrets manager. By the end you'll know which one to use for which kind of secret, what it will cost you at your actual scale, and the traps that turn a "free" Parameter Store setup into a service ticket six months later.

What AWS Secrets Manager actually charges you for

Secrets Manager has exactly two billing meters, and AWS states this plainly on its own pricing page: you pay based on the number of secrets stored and the number of API calls made. There are no upfront costs, no long-term contracts, and no minimum fees. That's the whole model.

Storage: $0.40 per secret, per month. This is prorated hourly, so a secret that only exists for six hours doesn't cost you a full month — AWS's own example shows the math as $0.40 × (1 hour ÷ 720 hours in a month) to get the hourly rate. A secret you mark for deletion stops being charged once it's flagged, even during the recovery window.

API calls: $0.05 per 10,000 requests. Every GetSecretValue, PutSecretValue, DescribeSecret, and similar call counts toward this meter. At that rate, one API call costs half a thousandth of a cent — it takes real volume before this line shows up as more than pocket change on a bill.

Rotation doesn't cost what people assume it costs

This is the part worth sitting with, because it runs against the intuition most people bring to this topic. If Secrets Manager rotates your database password every week, doesn't that mean you're storing more secrets, and paying more? No — and AWS's own pricing documentation says so directly: rotating a secret creates a new version of that same secret, and you are not charged for creating new versions. The $0.40 covers the secret regardless of how many times its value changes underneath it.

What rotation does add, separately, is the cost of the Lambda function that performs the rotation. For most managed database and service integrations, Secrets Manager uses a Lambda function behind the scenes to do the actual credential swap — and that function runs under standard AWS Lambda pricing, billed on its own, not folded into the $0.40. For a rotation that runs weekly and finishes in a couple of seconds, this typically amounts to a fraction of a cent per month, but it is a separate line item you should expect to see, not a mystery charge.

The two ways rotation actually works underneath

AWS's own CloudFormation reference for Secrets Manager rotation resources describes two rotation strategies, and which one you use changes how many secrets you're really paying for. In single-user rotation, the same database user's password is updated in place — one secret, one credential, straightforward. In the alternating-users strategy, Secrets Manager rotates between two separate database user accounts, which requires a second "superuser" secret with elevated privileges to perform the swap. AWS's documentation is explicit that you have to create this superuser secret yourself and reference its ARN inside the JSON of the secret being rotated, so that the rotation Lambda function can find it.

The cost implication is easy to miss: the alternating-users strategy means two secrets exist where you might have expected one — the working credential and the superuser credential used to rotate it — and both are billed at $0.40/month like any other secret. If you're budgeting rotation-enabled secrets at "one secret, $0.40" across the board, check which rotation strategy is actually configured before you finalize that estimate, because alternating-user rotation on a handful of databases quietly doubles the secret count for just those credentials.

What Parameter Store actually charges you for

Parameter Store, part of AWS Systems Manager, splits parameters into two tiers, and the pricing difference between them is the whole story here.

Standard parameters: no additional charge. You can store up to 10,000 standard parameters per AWS account per Region at no cost for the storage, and standard-throughput API interactions with them are also free. There's a real ceiling — 4 KB of data per parameter — but for a password, an API key, a connection string, or almost anything you'd normally call a "secret," 4 KB is more than enough room.

Advanced parameters: $0.05 per parameter per month. You get a bigger size limit (8 KB), a higher count ceiling (100,000 per account per Region), and support for parameter policies like automatic expiration — but you pay for it, and the charge is prorated hourly the same way Secrets Manager's is.

API interactions on advanced parameters, or on standard parameters if you turn on higher throughput: $0.05 per 10,000 interactions. AWS defines an interaction very specifically — if one GetParametersByPath call returns ten parameters, that's ten interactions, not one. This matters if your application pulls back a whole hierarchy of settings in a single call; the bill counts each parameter in the response, not each API request.

Parameter policies are an Advanced-only feature, and they're the other reason people upgrade on purpose. AWS's API reference for PutParameter documents an Expiration policy that automatically deletes a parameter once it reaches a date you set — useful for a temporary credential you want AWS to clean up rather than trusting a human to remember. Standard parameters can't carry this policy at all; if automatic expiration is something you want, that requirement by itself is a legitimate reason to pay the $0.05, independent of size or count.

Who can actually read these values, and how that affects your bill indirectly

Cost and access control aren't separate conversations here, because the way you lock down a secret changes what it costs to operate. Both services use IAM policies as the primary gate — a role or user needs secretsmanager:GetSecretValue to read a secret, or ssm:GetParameter (and kms:Decrypt if it's a SecureString) to read a parameter. Neither service exposes anything by default; access is opt-in through policy, the same as every other AWS resource.

Where they diverge is in resource-level sharing. Secrets Manager supports resource-based policies directly on a secret, letting you grant a different AWS account read access to that one specific secret without touching IAM in the calling account at all — useful if a partner team in another account needs one credential and nothing else. Parameter Store's advanced-tier parameters support a comparable cross-account sharing capability, but standard parameters don't; if your architecture depends on cross-account access to a specific value, that's one more reason a given item might need to live on the paid side of Parameter Store, or in Secrets Manager, rather than as a free standard parameter.

The indirect cost angle: every additional IAM policy, resource policy, or KMS key involved in reaching a secret is another thing your API calls have to satisfy, and every failed permission check still counts as a billed API call on both services. A misconfigured policy that causes an application to retry a `GetSecretValue` call in a loop won't bankrupt you at $0.05 per 10,000 calls, but on a Parameter Store setup where you've deliberately avoided enabling higher throughput to stay in the free tier, a retry storm is exactly the kind of thing that can push you into charges you didn't plan for. Watch your CloudWatch error rates on these calls, not just your success count.

Cross-account access adds one more permission layer worth knowing about before you design around it. When a secret is encrypted with a customer managed KMS key and you need to replicate it, decrypt it, or share it into another account, AWS's own troubleshooting documentation for Secrets Manager replication notes that the calling identity needs kms:Decrypt permission on the source key, and separately needs kms:GenerateDataKey and kms:Encrypt permission on the destination key if you're re-encrypting with something other than the default managed key. None of this changes the $0.40 figure, but it does mean a cross-account secret typically takes two IAM policies and a KMS key policy to actually work, not one — plan the access model before you plan the budget line.

Secrets Manager vs. Parameter Store: the decision table

Ethan's version of this, the one he gives Jake in about thirty seconds: "If you need it to rotate itself or it plugs straight into RDS, pay the forty cents. If it's a config value or a key you're comfortable rotating by hand twice a year, don't pay anything." Here's the fuller breakdown behind that rule of thumb.

What this actually costs at your scale

Numbers on a pricing page are abstract until you see them applied to a real setup. AWS publishes four worked examples for Secrets Manager on its own pricing page, and they're worth walking through because they show how much the API-call side of the bill actually matters — or doesn't.

Scenario	Secrets stored	Monthly Secrets Manager cost
Small production app (1 load balancer, 4 servers, 1 database, weekly rotation)	15 secrets	$6.02
Mid-size org, ~$40K/month AWS spend, moderate usage	1,500 secrets	$604.50
Larger org, ~$250K/month AWS spend, heavier usage	10,000 secrets	$4,060.00
High-volume ephemeral tokens (1-hour lifespan, 5M/month)	5,000,000 short-lived secrets	$2,850.00

Look at the pattern across those first three rows: the storage line ($0.40 per secret) dominates every single one of them. In the 10,000-secret example, storage is $4,000 of the $4,060 total — the API calls are almost a rounding error even at 12 million calls a month. That's the honest takeaway: for typical usage, Secrets Manager's real cost driver is how many secrets you have, not how often you call them. The exception is the fourth row, where the secrets themselves are so short-lived (an hour each) that you're effectively paying an hourly rate on millions of them — a workload pattern that almost never applies to a small business, but matters if you're building something like a custom microservice-to-microservice auth token system.

Now put Parameter Store next to that same 15-secret example. If Jake's dev had stored those 15 credentials as standard parameters instead — assuming none needed automatic rotation — the storage cost would be $0, and the only charge would come from enabling higher-throughput API interactions, which most small setups never need to turn on. The tradeoff he'd be making is doing that weekly password rotation by hand, or scripting it himself, instead of letting Secrets Manager handle it.

Catching a runaway bill before the invoice arrives

You don't have to wait for a monthly statement to find out your secret count or your API call volume crept up. AWS's own Secrets Manager documentation points to two tools built for exactly this: Amazon CloudWatch, which you can use to monitor estimated Secrets Manager charges as they accrue rather than after the billing period closes, and AWS Cost Anomaly Detection, which flags unexpected spend shifts across services automatically. Neither costs anything extra to turn on for this purpose, and both give you a chance to notice "someone provisioned 400 secrets in a test environment and forgot to clean them up" while it's still a small number instead of a line item that surprises finance three weeks later.

Tagging is the other half of this. Both services let you attach tags to individual secrets and parameters — team, environment, project — and those tags flow into AWS Cost Explorer if you've activated them as cost-allocation tags. For an account with more than a handful of secrets, tagging by environment (so you can immediately see what "staging" is costing versus "production") is the difference between a five-minute investigation and an afternoon of digging through the console one secret at a time when the bill jumps.

How to estimate your own monthly bill before you commit

You don't need a spreadsheet model to get a workable estimate. Do this before you provision anything:

1. Count your secrets, not your applications. Two SSH keys per server, one database credential per database, one API key per third-party integration — add them up individually. This is the number you multiply by $0.40.
2. Decide which ones genuinely need scheduled rotation. A database password that many services connect to is a strong candidate. A one-off API key for a service you check twice a year usually isn't.
3. Route the "needs rotation" group to Secrets Manager and everything else to Parameter Store Standard. This single split is where most of the real-world savings come from — you're not choosing one service for the whole account, you're choosing per secret.
4. Estimate your daily API call volume per secret. If your app refreshes a database connection pool every hour, that's roughly 24 calls a day per credential — multiply by 30 for the month, then by $0.05 per 10,000.
5. Add it up and sanity-check it against AWS's own examples above. If your number looks nothing like the closest matching scenario, you've probably mis-counted a secret or an API call somewhere — go back and check before you provision.

The costs that don't show up on the pricing page's first glance

Cross-Region replicas

If you replicate a Secrets Manager secret to a second Region for disaster recovery or low-latency regional access, that replica is a real, separate secret in AWS's eyes — and AWS's own documentation for the replication feature points you directly back to the Secrets Manager pricing page for what a replica costs, rather than treating it as a free extension of the primary. Practically, that means a secret you replicate to three Regions is billed on the same per-secret basis in each of those Regions. If your architecture calls for multi-Region secrets, budget for that multiplier up front — it's easy to design a three-Region failover setup and then be surprised that your secrets bill tripled along with it.

Advanced parameters you didn't mean to create

Parameter Store will silently upgrade a parameter from Standard to Advanced tier if you do any of the following: exceed 4 KB in the value, attach a parameter policy such as an expiration date, or — this is the one that catches people off guard — if your account already has more than 10,000 standard parameters and you create a new one. AWS's own API documentation for PutParameter spells this out explicitly. Once a parameter becomes Advanced, you cannot downgrade it back to Standard without recreating it, because the system would truncate the value and drop any policies, causing data loss. If you're trying to stay on the free tier, watch your parameter count as it approaches 10,000, and check your value sizes before you paste in a certificate or a large JSON blob.

Rotation's Lambda function

Covered above, but worth repeating as a line item: the Lambda function Secrets Manager uses to rotate a secret is billed under standard Lambda pricing, separately from the $0.40. For a normal weekly rotation this is negligible, but if you configure very frequent rotation — say, hourly — on a secret with a rotation function that takes several seconds to run, that adds up in Lambda invocation and duration charges in a way the $0.40 figure doesn't hint at.

Customer managed KMS keys

By default, Secrets Manager encrypts a secret with the AWS managed key aws/secretsmanager, and AWS's own documentation is explicit that there's no cost for using that managed key. If you switch to a customer managed KMS key instead — which you'd typically do to share a secret across accounts, or to control and rotate the key yourself — you take on standard KMS pricing for that key and for every encrypt/decrypt request it services, on top of the $0.40 per secret. It's a legitimate and sometimes necessary choice, but it's an add-on cost, not something bundled into the base secret price.

Multi-account and CloudFormation: how each service behaves at organization scale

Neither service exists in isolation once you're managing more than one AWS account, and the way each one fits into infrastructure-as-code matters for the "hidden effort" side of the cost equation, even when the dollar figure stays the same.

Secrets Manager has first-class CloudFormation support through the AWS::SecretsManager::Secret resource, including a ReplicaRegions property that lets you define cross-Region replicas — with or without a customer managed key per replica — directly in a template, and an AWS::SecretsManager::RotationSchedule resource that wires up rotation, either by pointing at an existing Lambda function or by generating one from a hosted rotation template AWS maintains for common database engines. If your team already manages infrastructure as code, this means enabling rotation is a template change, not a manual console click someone has to remember to repeat for every new database.

Parameter Store's organization-scale story is different: standard parameters have no cross-account sharing mechanism at all, while advanced parameters do support shareability across AWS accounts. If your multi-account setup needs one team's parameter readable by another account's workload, that requirement alone can be the deciding factor that pushes a parameter into the paid Advanced tier, independent of its size or how often you rotate it.

Moving a secret from Secrets Manager to Parameter Store (or the reverse)

There's no built-in "migrate" button between the two services — they're separate products with separate APIs — so this is a manual, deliberate move rather than a setting toggle. Here's the sequence that avoids an outage:

1. Retrieve the current value from the source service. Use GetSecretValue for Secrets Manager or GetParameter (with decryption if it's a SecureString) for Parameter Store. Do this once, and don't paste the value anywhere it will be logged.
2. Create the equivalent entry in the destination service with the same value, using a naming convention your application can find. If you're moving to Parameter Store, choose the Standard tier explicitly unless the value or policy needs force you into Advanced.
3. Update your application's IAM permissions so it can read from the new location — this is the step people forget, and it's the one that actually causes downtime if skipped.
4. Update the application code or configuration to read from the new source, and deploy that change to a non-production environment first if you have one.
5. Confirm the application is reading successfully from the new location, then delete the old entry. For Secrets Manager, deletion has a recovery window by default, so this isn't instantly irreversible — you have a buffer if something goes wrong.

If you're moving a database credential that has automatic rotation configured in Secrets Manager, moving it to Parameter Store means you are taking on the responsibility of rotating it yourself from that point forward — Parameter Store has no equivalent scheduled-rotation feature. Don't make this move for a credential you actually need rotated regularly unless you have a separate automation ready to replace what you're giving up.

When neither AWS service is the right call

Worth acknowledging honestly rather than pretending the choice always stays inside AWS: if you're running a genuinely multi-cloud setup — secrets that need to be readable from AWS, another cloud provider, and on-premises servers with one consistent access model — a third-party secrets manager can be the simpler operational answer, at the cost of adding another vendor, another bill, and another system to keep patched and monitored. That's a real tradeoff, but it's outside the scope of what either AWS service is trying to solve, and it's the kind of decision that hinges on your specific multi-cloud footprint more than on the $0.40-per-secret question this post is answering. If your infrastructure lives entirely in AWS, that added layer is very rarely worth taking on just to avoid a line item this small.

When paying $0.40 is genuinely the right call

Ethan's take: "People treat the forty cents like it's the whole decision, and it almost never is. The decision is whether you want AWS rotating this credential for you, automatically, forever, or whether you're volunteering to remember to do it yourself." That framing is closer to the real tradeoff than a pure price comparison.

Secrets Manager earns its cost in three specific situations. First, native rotation for Amazon RDS, Redshift, and a handful of other AWS-managed databases — Secrets Manager can rotate the actual database user's password and update the secret in the same operation, using a Lambda function AWS provides a template for. Building that yourself against Parameter Store is possible, but you're writing and maintaining the rotation logic instead of configuring it. Second, cross-Region replication for secrets that a multi-Region application needs available with low latency in more than one place — Parameter Store has no built-in equivalent. Third, any secret where a compliance requirement mandates a documented, scheduled rotation cadence with an audit trail; Secrets Manager's rotation history and CloudTrail integration give you that out of the box.

Outside of those three, Parameter Store Standard is very often the more sensible default, not because Secrets Manager is overpriced, but because you're not using the features that justify its price.

Working through Jake's actual bill

Back to the $6.02 that started this. Jake's setup has exactly the shape of AWS's own "production-scale web application" example: a load balancer, a couple of web servers, an app server, and one database, with SSH keys per instance and five database credentials rotated weekly. That's 15 secrets at $0.40 each — $6.00 — plus a few thousand API calls a month for SSH logins and the weekly rotation cycle, adding roughly two cents. Nothing about that bill is wrong or bloated; it's the expected cost of a small production setup that wants its database password rotated automatically.

Where Jake could trim it, if he wanted to: the two SSH keys stored per server aren't things Secrets Manager needs to rotate on a schedule the way the database credentials do. Moving those four SSH key secrets to Parameter Store Standard would drop his Secrets Manager count from 15 to 11, cutting $1.60 off the storage line — not a dramatic saving at this scale, but the same logic applied across a fleet of 50 servers instead of 2 turns into real money, and it's the same principle either way: match the service to whether the secret actually needs scheduled rotation.

Is Parameter Store Standard actually secure, or just cheap?

This is the honest question underneath a lot of the price comparison, and it's worth answering directly instead of dodging it. Parameter Store supports a SecureString type that encrypts the value using AWS KMS, the same encryption service Secrets Manager uses under the hood. Stored as a SecureString, a database password in Parameter Store is encrypted at rest the same way it would be in Secrets Manager. The gap isn't encryption strength — it's the surrounding lifecycle tooling: rotation scheduling, versioned rotation history tied to a database's actual user account, and cross-Region replication. If your real question is "will this leak," the answer is that a SecureString parameter is not the weak link. If your real question is "will this get rotated without anyone remembering to do it," that's where Secrets Manager's built-in scheduling earns its cost.

Frequently asked questions

Is Parameter Store really free?

Standard-tier parameters are free for storage, with no additional charge for standard-throughput API interactions either, according to AWS's own Systems Manager pricing page. You only start paying if you move a parameter to the Advanced tier or explicitly enable higher throughput on Standard parameters. For most small teams storing configuration values and secrets under 4 KB, Standard-tier Parameter Store costs nothing on an ongoing basis.

What's the actual cost difference for around 50 secrets?

Fifty secrets in Secrets Manager, assuming modest API usage, runs roughly $20/month in storage alone, plus a small amount for calls. The same 50 items as Standard-tier Parameter Store parameters cost $0, assuming none exceed 4 KB. The gap at this scale is the price of the rotation and replication features Secrets Manager provides — if you don't use those features on all 50, splitting them between the two services based on which ones actually need rotation is usually the better move than putting everything in one or the other.

Does rotating a secret in Secrets Manager cost extra?

Not for the storage side — AWS explicitly does not charge for creating new secret versions, which is what a rotation does. What does incur a separate charge is the Lambda function that performs the rotation, billed under normal AWS Lambda pricing rather than the Secrets Manager meters. For typical rotation schedules this is a very small amount, but it's a real, separate line item.

Can I use Parameter Store for database credentials safely?

Yes, encrypted as a SecureString it's stored using AWS KMS, the same encryption mechanism Secrets Manager relies on. What you give up is native, scheduled rotation of the database user's password — Parameter Store won't log into your RDS instance and change the password for you the way Secrets Manager's rotation Lambda templates can. If you're comfortable rotating that password on your own schedule, or your compliance requirements don't demand automatic rotation, Parameter Store is a valid, secure choice for it.

What happens if I go over 10,000 standard parameters?

According to AWS's own API reference for PutParameter, once your account already has more than 10,000 standard parameters in a Region, any new parameter you create is automatically placed in the Advanced tier and billed at $0.05/month, even if it's small and has no special policy attached. If you're approaching that count, plan for the cost of the overflow before you hit the ceiling, not after.

Are advanced parameters worth $0.05/month?

They're worth it specifically when you need what they provide: values over 4 KB, more than 10,000 total parameters, or parameter policies such as automatic expiration. Outside of those needs, there's no reason to pay for Advanced — Standard does everything most secrets and config values require, at no cost.

Does Parameter Store support automatic rotation like Secrets Manager?

No. Parameter Store has no built-in scheduled-rotation feature comparable to Secrets Manager's. You can build your own rotation using a scheduled Lambda function and the PutParameter API, but you're responsible for writing and maintaining that logic yourself — it isn't a checkbox the way it is in Secrets Manager.

What counts as an "API call" for billing purposes?

For Secrets Manager, it's each individual API request — GetSecretValue, PutSecretValue, DescribeSecret, and similar operations each count once. For Parameter Store, AWS counts by "interaction," which is per parameter returned, not per request — a single call that retrieves ten parameters in one response counts as ten interactions on your bill, according to AWS's own pricing documentation.

Is there a free tier for Secrets Manager in 2026?

There's no service-specific free trial anymore for accounts created on or after July 15, 2025. Instead, new accounts get up to $200 in general AWS Free Tier credits that can be applied to Secrets Manager along with other eligible services, available for six months after account creation. Accounts created before that date may still have had the older 30-day Secrets Manager-specific trial.

How much does replicating a secret across regions cost?

AWS's own documentation for Secrets Manager replication points you directly to the standard Secrets Manager pricing for what a replica costs — it isn't a free extension of the primary secret. Practically, treat a replica in each additional Region as its own priced secret and budget for that when you design a multi-Region setup.

Can I migrate an existing Secrets Manager secret to Parameter Store to save money?

Yes, but it's a manual process — retrieve the value, recreate it in Parameter Store, update your application's IAM permissions and code to read from the new location, then delete the old secret. Only do this for secrets that don't rely on Secrets Manager's automatic rotation, since Parameter Store has no equivalent — you'll be taking over that responsibility yourself.

What's the maximum size of a secret vs. a parameter?

A Secrets Manager secret value can be up to 64 KB, per AWS's API reference for CreateSecret. A Standard parameter tops out at 4 KB, and an Advanced parameter at 8 KB. If you need to store something larger than 8 KB — a certificate bundle, for instance — neither Parameter Store tier will hold it, and Secrets Manager's 64 KB ceiling is the one that fits.

Does Secrets Manager charge me for secrets I've marked for deletion?

No. AWS states this directly: secrets marked for deletion are not charged, even during the recovery window before permanent deletion completes. If you're cleaning up old secrets to trim your bill, marking them for deletion stops the charge immediately rather than waiting for the recovery window to expire.

Is Parameter Store Standard secure enough for production credentials?

As a SecureString, yes — the encryption is handled by AWS KMS, the same service backing Secrets Manager. What you're not getting is scheduled rotation, cross-Region replication, or native database credential rotation. Security-wise, the value sitting in Parameter Store isn't weaker; the lifecycle management around it is thinner.

Will fetching a secret at Lambda cold start hurt performance versus using an environment variable?

Fetching from either Secrets Manager or Parameter Store at cold start adds a network call your function wouldn't otherwise make, and each of those calls counts toward the respective API-call billing meter. Neither service publishes a guaranteed latency figure for this call, so we won't invent one here — if cold-start latency is a hard requirement for your workload, that's a performance question worth testing in your own environment, separate from the cost question this post covers.

Which one should Jake use for his phone shop's POS system credentials?

Split it by whether the credential needs to rotate. His inventory database password, which multiple services connect to and which benefits from a scheduled rotation, fits Secrets Manager's native RDS-style rotation well. His payment processor API key and the SSH keys on his two EC2 boxes — items he'd typically rotate manually if at all — cost him nothing sitting in Parameter Store Standard. That split, not an all-or-nothing choice of one service, is what keeps a small shop's secrets bill close to what it needs to be rather than what it defaults to.

Revision note. Written September 2026, covering current published AWS pricing for Secrets Manager and Systems Manager Parameter Store, including the post-July 2025 Free Tier credit model. This will need a revisit if AWS changes either service's per-unit pricing or the parameter tier limits. If you've been staring at an AWS bill trying to figure out where a mystery secrets-management charge came from, hopefully this gets you to an actual number instead of a guess.Happy learning.!